Articles

Turning JET into a live system – Jun 1, 2017 – The previous article about the redesigned JET model mentioned Folie as sitting between a USB interface and MQTT, presumably to publish received RF messages on MQTT, and to subscribe to an MQTT topic so commands will be picked up and sent out over RF. But that’s not quite how Folie works right now. The current version of Folie is aimed at interactive command-line use, for directly-attached µC nodes, and hopefully soon also for remote RF nodes.
Redesigning the JET model – May 31, 2017 – The JET project (JeeLabs Embello Toolkit) is the continuation of the earlier HouseMon project (in turn the successor of JeeBus). It’s been a slow starter, but definitely not shelved. The JET “Hub” has been running for the past few years here at JeeLabs - dutifully collecting monitoring data from two different sensor networks, saving log files, and forwarding messages to MQTT. The “Hub” was implemented with the assumption that a single process should be kept running at all times, with various “Packs” started and stopped on demand, as child processes.
Interactive Forth over RF? – May 25, 2017 – Since Mecrisp Forth uses the serial port as its interactive console, the most direct way of connecting to a µC board is as follows (double-line arrows represent wired connections): When using some widely available low-cost STM32F103 boards with built-in USB port, we can in fact simplify this considerably by using a USB console driver instead of that FTDI adapter: But what if we could also re-apply the same trick using wireless radio modules?
Meet the new RF73 driver – May 24, 2017 – There’s a new wireless radio driver in town for the JeeNode Zero and other µC boards running Mecrisp Forth. It’s called RF73 but it is in fact intended to be used with the RFM70, RFM73, and RFM75. These are low-cost 2.4 GHz wireless modules made by HopeRF, the same supplier as for RFM12 and RFM69. These modules are derived from designs created by Silicon Labs. The current rf73.fs code is still very young, and not quite ready for general use.
Multi-platform development – May 18, 2017 – The title of this article is perhaps a bit misleading: it’s not just about developing code which needs to run on different platforms, it’s also about using different programming languages. Over the years, here at JeeLabs s/w development has always been about more than getting stuff working on one CPU: we want display and control tied to our laptops and mobile devices. With µCs which collect and exchange data, multi-platform development is inevitable.
Think, upload, rinse, repeat – May 17, 2017 – As often mentioned, Forth enables an interactive development approach: you enter commands on the µC itself, and things get done right away. No make, no compile step, no uploads. But that’s an over-simplification, because it ignores the fact that most code needs to be written and saved to file. Unless truly one-off of course, and you don’t care about losing the source code once it has run. But usually, we really can’t develop a meaningful application on just the µC.
Generated code & performance – May 12, 2017 – Let’s look at how the tricks in the previous article end up in code, and their performance effects. First the trace.fs utility, which needs to insert special calls at the start and end of each word: : a 2 . ; ok. see a 20000394: F847 str r6 [ r7 #-4 ]! 20000396: 6D04 20000398: 2602 movs r6 #2 2000039A: B500 push { lr } 2000039C: F244 movw r0 #434F 2000039E: 304F 200003A0: 4780 blx r0 --> .
Let's trace, profile, and patch – May 11, 2017 – Although Mecrisp Forth “compiles” source code to machine language, it’s not really a compiler in the traditional sense, as with say C or C++. In Forth, the compilation process and runtime execution are deeply intertwined. Words like “:”, “if”, “while”, and even “(” + “)” comments are special in the sense that they affect the compilation process, but they’re still “words”, i.e. bits of functionality which can be defined (and re-defined) in Forth itself - even on-the-fly!
Simple Mecrisp Forth utilities – May 10, 2017 – The default message shown after a reset of Mecrisp Forth is this prompt: Mecrisp-Stellaris RA 2.3.6 for STM32F103 by Matthias Koch Nothing else, no hint that you can start entering commands. With a board.fs file from Embello loaded, we get an extra line with some useful status information (and an “ok.”): Mecrisp-Stellaris RA 2.3.6 for STM32F103 by Matthias Koch 64 KB <g6s> 32212433 ram/flash: 17024 19456 free ok. But the fact remains that the “ok.
F103 + USB = Swiss Army Knife – May 5, 2017 – The USB driver for STM32F103 has been around for months and it’s proving to be very stable and usable. The current Mecrisp release now includes it, and there’s an F303 port available. The original code and inspiration for this driver came from Eckhart Köppen’s early CoreForth implementation. While changes and a whole lot of head-scratching was needed, his code was proof that implementing a serial port driver in Forth was worth trying, and ulitmately: doable!
Folie is growing up... slowly – May 4, 2017 – Folie, the “Forth Live Explorer” is starting to shape up. Here’s a summary of what it’s about: a front end for Mecrisp Forth, i.e. a terminal emulator like picocom or Tera Term easily find (ctrl-R) and re-enter previous commands (up-/down-arrow) send source files to Mecrisp Forth as if they had been literally typed in (!send) expand include directives in the source code with the file(s) they refer to The above will work with any serial connection, both RS232 and USB, as well as with a network connection via ser2net.
Mecrisp Forth's memory use – May 3, 2017 – The Blue Pill is a widely available and extremely low-cost STM32F103-based µC board which has an amazing amount of features and plenty of memory onboard: 64K flash and 20K RAM. In C/C++, the way development works is to run a cross-compiler, as made widely popular with the Arduino IDE. The central development flow is then as follows: edit source code on your Win/Mac/Lin laptop, desktop, RasPi, etc run the compiler, fix reported compilation errors upload the generated binary code to the µC and run it rinse and repeat… Not so with a self-hosted development environment like Mecrisp Forth, where incremental and on-board development is used: instead of building an application from scratch, and uploading it, you grow your application in small steps and in a bottom-up fashion.
Troubleshooting the EZ-Retro – Apr 30, 2017 – Here is the eZ80 chip, hand-soldered on the new EZ-Retro v2 PCB: The trouble is: something is very wrong: with my lab power supply set to 3.3V and a 30 mA maximum current limit, the voltage drops to 0.06V - whoops! This low voltage points to a short, since there’s not even a diode drop left. This was actually the second build. In the first one, I had already mounted everything at the same time - which is a nice act of optimism, but not such a great idea for a non-trivial new and untested PCB …
EZ-Retro v2, now with a PCB – Apr 29, 2017 – As mentioned earlier, the EZ-Retro project could use a PCB for a more compact and robust setup. There is a nice F103 board variant (search for “STM32F103C8T6 ARM Minisystem Development Board STM32“ on eBay), with suitable headers and optional µSD on the back: A benefit of this board, is that the schematics are also available (see the 3rd image). So let’s create a PCB for it! All the design files are on GitHub, and here is the schematic of this new “EZ-Retro v2” design, fully dominated by that gigantic 144-pin eZ80 chip, of course:
Taking it further with i3 – Apr 28, 2017 – This article is about the i3 window manager (and also, further down below, Ranger): Its main distinguishing feature is that is uses tiling as visual layout mechanism. While the mouse and floating/overlapping windows can still be used relatively easily, i3 is really geared towards keyboard use: for switching focus around and creating new windows, but even for moving windows (i.e. panes) around or resizing them. In addition to carving up the screen into panes/tiles, there are also multiple screens, to set up multiple visual contexts.
Why Vim is very different – Apr 27, 2017 – Ah, the smell of editor wars. Arguments collide. Opinions galore. Lots of heat, so little light… This article was not written for the sake of argument. I just want to highlight why I keep coming back to vim, decade after decade. Or rather, I’ll defer to a great 36-min video by Chris Toomey: Trust me, there is something very fundamental going on in vim’s edit-vs-type distinction, which none of Sublime Text, Atom, or even Emacs editors seem to be capitalising on.
The limits of Mac and Mouse – Apr 26, 2017 – It all started with recent kernel panics on my MacBook Pro laptop, almost every night, causing me to revisit my setup and choice of technologies. For the record: I’m very attached to my 2014-era “MBP”, its high-quality build, performance, portability, and battery life, as well as tons of superb apps for browsing, email, drawing, archiving, searching, etc. The 2880 x 1800 “Retina” display is incredible. I’ve scaled it back to 1920x1200, but the way this works is that internally rendering then happens at 3840 x 2400 (i.
The virtual floppy jukebox – Apr 16, 2017 – Times sure have changed: a fingernail-sized 2 GB µSD card of a few dollars can now easily store over a thousand 1.44 MB floppy disk images, while being quicker than the fastest hard drive from the glory days of CP/M (and MS-DOS, for that matter). A lot of software has been created for CP/M, most of it now relegated to historical archives, such as this one. These were the early days of modems, file exchanges, and BBS’es.
A µSD, slave SPI, and DMA – Apr 15, 2017 – Connecting an SD card to a Blue Pill was described in a recent article. With the sdcard.fs code, it’s as simple as calling sd-init, and then sd-read / sd-write for accessing 512-byte blocks. And since the eZ80 includes an SPI hardware device, we can also use SPI between the eZ80 and the Blue Pill, which - most conveniently - happens to have two SPI interfaces. By letting the eZ80 be the master, we can use very simple byte-by-byte transfers, and keep all the slave SPI complexity on the Blue Pill’s side.
We'll need a BIOS for CP/M – Apr 14, 2017 – The minbios.z80 code used so far only has the minimal functionality needed to get CP/M off the ground. Well… slightly more, to be precise: it can see 256 KB of RAM as virtual disk A: and 256 KB of flash memory as (read-only) virtual disk B:. There is no persistence. There are no applications to run at all, in fact - not even the standard CP/M utilities such as STAT and PIP, for example.
Bootstrapping CP/M via simh – Apr 13, 2017 – The next step is actually more of a giant leap: building a working CP/M system from scratch… This can’t be done in one go. Let’s start as simply as possible - which is already pretty steep: decide how to structure the system tracks for booting implement a flash loader to copy things to RAM implement a minimal BIOS which does console I/O and reads the virtual flash disk compile this assembly code using a Z80 assembler build a CP/M disk image which contains the CCP BDOS, and our newly crafted BIOS convert the resulting bytes to instructions we can send to PokeMon connect to the eZ80 and write this data into its flash memory reset and enter terminal mode… The CCP (Console Command Processor) and BDOS (Basic Disk Operating System) are part of the CP/M distribution, and need not be changed other than to assemble the code to reside in a specific address range in memory, i.
PokeMon, the eZ80 monitor – Apr 12, 2017 – Out of the factory, the eZ80 is totally ignorant: it comes with 256 KB of empty flash memory. This reads as $FF, which corresponds to the “RST 38h“ instruction, a one-byte call to address $0038 (mixed $-vs-h notations are used for hex numbers: “$” in Forth, “h” for Z80). Left alone, the eZ80 will continuously execute this instruction, cycling through its address space since the stack pointer will be constantly decremented.
Minimal requirements for CP/M – Apr 7, 2017 – Even a minimal EZ-Retro setup is very powerful compared to CP/M systems of the 1970’s, costing thousands of dollars, drawing hundreds of Watts, and placed in Boring Bulky Boxes. So let’s start planning the CP/M configuration for our little USB-powered variant, eh? The internal 256 KB flash memory can be used as read-only virtual disk. Since eZ80 starts up in flash when it comes out of reset, the system tracks are the logical place for bootstrap code.
A truly minimal eZ80 setup – Apr 6, 2017 – To check that the eZ80 chip works, we only need to connect it to the Blue Pill with 6 wires: +3.3V and ground (the eZ80 runs at 3.3V, but it has 5V-tolerant I/O pins) a two-wire “Zilog Debug Interface” (ZDI), which is a bit like JTAG, but simpler a clock signal to drive the eZ80 (anything from DC up to 50 MHz) a reset signal - not strictly necessary, but convenient See the README for the exact connections used in this project.
EZ-Retro: system overview – Apr 5, 2017 – The EZ-Retro project is about creating a Z80-compatible board capable of running CP/M and based on the eZ80F91 microcontroller from Zilog - it looks like they’re still in business, BTW! That’s “EZ” as in “easy”, with an apology up front for deviating from the Queen’s English… The Zilog Z80 was a highly successful microcomputer design, which has stood the test of time. It introduced a huge number of innovative features, back in the 1970’s.
Tying SPI and DMA together – Mar 31, 2017 – If you consider µCs to be incapable of any “serious” data handling, then you’ll be in for a treat. The following design was created for an upcoming project, which needs a fairly high-speed path for handling requests and transferring 512-byte blocks of data to and from an SD card. One option is to act as a slave-side SPI device. Here’s how SPI works, courtesy of Wikipedia: Note that the master drives the clock which causes both shift registers to exchange each bit.
Interrupts, tamed at last – Mar 30, 2017 – Before going into interrupts, why they’re needed, and why they are tricky, let’s first look into an example which does not use interrupts: writing a pass-through USB-to-serial application. Note that many of the observations and issues that follow apply to any procedural language! Here’s a simple loop to pass characters from the UART to USB, and from USB to the UART: : run uart-init 19200 uart-baud begin uart-key? if uart-key emit then key?
SD cards with FAT files – Mar 29, 2017 – Those little plastic µSD-to-SD card adapters, of which you may have a bunch lying around since they are often included with new µSD cards, make excellent µSD card sockets: There are many libraries (in C for the Arduino, for example) which support accessing SD cards from an embedded µC. These all rely on a well-known feature of these cards of supporting SPI: The only tricky bit is getting them into that mode.
Stay busy, but also sleep a lot – Mar 24, 2017 – One of the examples in the multi.fs code contains this little gem: : sleep ( -- ) [ $BF30 h, ] inline ; \ WFI Opcode, enters sleep mode task: lowpower-task : lowpower& ( -- ) lowpower-task activate begin eint? if \ Only enter sleep mode if interrupts have been enabled dint up-alone? if ( ." Sleep " ) sleep then eint then pause again ; It’s a task which gets called periodically, like every task in the cooperative multi-tasker, and then checks if it’s the only enabled task, i.
Sometimes, timers are easier – Mar 23, 2017 – Multi-tasking is a great mechanism, but there is a drawback: each task needs its own stack. In the case of Forth, it’s even worse because each task needs both a return stack and a data stack. In its current configuration, multi.fs is set to 64 elements on each stack, which translates to a whopping 512 bytes of RAM needed (plus about 20 bytes for the task descriptors) - per task!
Let's try out the multi-tasker – Mar 22, 2017 – There’s been a multi-tasker hiding in the Embello repository for some time now. It’s a small variation of the one provided as part of the Mecrisp distribution, also on GitHub. The multi-tasker lets us do multiple things at once, or more precisely: it can quickly switch between tasks, each with their own data and return stacks, and their own program counter. The result is that you can write a thread of code as if nothing else is of interest… as we’ll see.
Setting up the Pi software – Mar 10, 2017 – To turn the Raspberry Pi into a general-purpose uploader / debugger for ARM STM32 chips, we need to set up some software. First of all - the OS. DietPi is a very practical little distribution these days. It’s minimal, well-supported, offers a simple way to manage lots of popular applications and to configure or update the system itself. All console driven, through simple old-fashioned text menus. Underneath this all sits a standard Debian 8.
Every possible connection – Mar 9, 2017 – The Raspberry Pi does not really need an introduction: Linux plus some tinkering pins - who could possibly ask for more? It has all the features needed to create a flexible and powerful programming / debugging tool for microcontrollers. It can even run entire toolchains for cross-compiling for a wide variety of these µCs. One tricky aspect, which is probably the main stumbling block if you’ve ever looked into trying out things with a 32-bit ARM-based µC, is how to get the software onto those chips.
Faster uploads through SPI – Mar 8, 2017 – It turns out that a ROM-based serial upload with Folie takes about 22 seconds for a standard Embello install (Mecrisp + always/board/core). While this is fine for occasional re-flashing, it adds quite a delay for production, i.e. when an image needs to be loaded onto each new board. But the STM32L05x series µCs has another trick up its sleeve: The ROM boot loader also checks for SPI requests on pins PA4.
Several years on a coin cell? – Mar 5, 2017 – So far, the power consumption of the rotary encoder node has been optimised by taking the current draw from 5.0 mA to 45 µA - that’s an estimated coin cell battery life of 6 months. Unfortunately, this is where diminishing returns start to kick in. To progress beyond this point requires rethinking the node’s logic. We need to put the µC into a really low-power mode, in such a way that it’ll still wake up every time that control dial is touched.
Making an always-on device – Mar 4, 2017 – It’s all nice and well, but a JeeNode Zero which needs to remain tethered to a host to set it up after each reset is not very useful. Fortunately, this can be fixed using a simple recipe: add these two lines at the start of the source file: <<<core>>> compiletoflash add this line at the end, assuming that the main routine is called read-enc: : init init unattended read-enc ; That’s it.
Cutting the rotary cord – Mar 3, 2017 – Before moving on to the topic of this article, let’s figure out the problem that came up in the previous one, where adding an OLED display made the rotary encoder readout unreliable. The problem is caused by the OLED’s display update code, which takes some time: lcd-init ok. : a micros 1234 shownum micros swap - . ; ok. a 48444 ok. That’s about 48 milliseconds to update the display. Over half of this time is caused by the way digits are drawn on the display, which uses a very crude approach: pixel by pixel drawing (!
Connecting a rotary encoder – Mar 2, 2017 – This exploration is about connecting a rotary encoder switch for use as an infinitely adustable up/down controller. The basic idea is that there are two switches inside, which generate pulses. In the simple rotary knobs, these two switches are open in the “click” position, and closed in a very specific way in between click positions (also known as “detents”). Note that this article isn’t about “here’s a library, plug it in and you’re done”, but a summary of the steps taken to make it work in Forth on a JeeNode Zero, gradually improving the code and making it do more things.
Post-mortem of a bug – Mar 1, 2017 – As everyone knows, the later a bug shows up in production, the more trouble it is to fix… A while ago, a batch of fresh JeeNode Zero rev4 boards was assembled, in itself the result of quite a bit of experimentation, design work, writing code, trying out things, rearranging the pins - and all of that across a couple of iterations. Revision 4 is intended to be very close to the “final” design of the JeeNode Zero, and the only way to figure out those last details is to get it out there and push it further.
How all those JNZs are tested – Feb 25, 2017 – One of the requirements of the JeeNode Zero rev4, is that each one has to be tested and then end up with the proper software loaded onto it. The obvious way to do this is to connect each board over FTDI after assembly, but since the headers are not soldered on at this stage, some sort of temporary hookup trick s needed. Meet Fiddy, a 3D-printed clip which turns 6 “pogo pins” into a clip that can easily hold a PCB:
Setting up a remote node – Feb 24, 2017 – To try out RF communications, we need to go through a number of steps: hook up two JeeNode Zero boards, so we can develop on both in parallel work out the code needed for the receive and send nodes lower the average power consumption of the send node install the send code in flash so it can run unattended add a coin cell, and turn the sender into a standalone unit as a bonus, we’ll also update the node with a modified version Let’s jump right in… by the end of this one article, you’ll have it all.
Installing more drivers in flash – Feb 23, 2017 – An application written in Mecrisp Forth consists of a number of different parts: The Mecrisp kernel itself: this is 20 KB of Matthias Koch’s hand-crafted assembly code, turning a µC into a Forth compiler / engine, with over 300 pre-defined “words”. Compiled code, stored in flash memory - these will always be present on power-up. Compiled variables, buffers, and code, stored in RAM - variables will be reset to their initial values on power-up and after each reset, but any code in RAM will be gone.
Getting started with a JNZ – Feb 22, 2017 – One of the features of the JeeNode Zero, is that it takes minimal effort to get started: hook it up via any USB serial interface, using any terminal emulator you like, and you’re all set to go. Here’s a PL2303-based USB interface, connecting power (+5V/GND) and serial pins (RX/TX): On the host side, you need a terminal emulator, such as Picocom or putty which can connect to a serial port and deal with lines coming back from the JNZ, ending in LF instead of CR+LF.
The JNZ rev4 PCBs are in! – Feb 18, 2017 – The PCB panels are in! They are produced by PCBcart, and arranged as 10 x 3 units: With a nice blue soldermask + gold plating, just like all the other official boards from JeeLabs. And here’s a close-up of the metal stencil, which will be used to apply solder paste: A first test has been successful, but further testing will be needed to make sure that everything works as intended: all the pins properly connected, no shorts, correct silkscreen labels, etc.
A new documentation site – Feb 17, 2017 – There’s quite a bit of new Forth code in the embello repository on GitHub, and more being added all the time - so it’ll become increasingly important that this code gets documented. There are many tools to do this. To match the rest of JeeLabs, the preferred solution is a static site - that way access can be snappy, page overhead stays low, and local copies are easy to use.
Sending multiple values – Feb 16, 2017 – The previous article showed how to send a value wirelessly from one node to another, as text. While it’s a good example to start off with due to the simplicity, this doesn’t really scale. It’s tedious to build up text packets, they lead to larger packet payloads, and this all adds to the complexity on both ends. It’s better to send binary data, using an encoding which compresses small values a little (which also happens with ASCII: small integers take fewer bytes).
Analog over wireless – Feb 15, 2017 – Let’s put the JeeNode Zero to work a bit, i.e. let’s repeatedly measure an analog voltage through its ADC, send the results over to another node via the radio, and display the received readings. We’re going to need a test setup with two wireless nodes. Something like this, for example: The top unit is an F103-based Blue Pill with an RFM69 on top, and a SerPlus on the left for programming (it can also be used directly over USB when a USB-enabled Mecrisp is installed).
A board made for tinkering – Feb 10, 2017 – “Sans paroles” - instead of a thousand words, here is a picture of the new JeeNode Zero rev4:
Making the silkscreen useful – Feb 9, 2017 – The JeeNode Zero takes a different approach from most other boards: components are placed on what is considered the bottom of the PCB, with the top free for extensive silk screen labels. Here is the bottom side of the JeeNode Zero rev4: And here is the top, with as much information squeezed in as possible: (both of these images were rendered by the excellent open-source pcb-stackup utility) As you can see, most of the information needed to use this board in a project is clearly labeled and documented on the PCB, so you won’t have to search for additional docs in many cases.
A few design changes in rev4 – Feb 8, 2017 – There are not really that many changes from rev3 to rev4 of the JeeNode Zero. The main one was to extend the main header by one more pin, and to move the radio module to other pins so that all of PA0..PA7 are now free to use - these have the most fexibility for general use (up to eight 1 Msps 12-bit ADC’s!), and also bring out the DAC (D-to-A converter), which is on PA4.
Performance and I/O toggling – Feb 3, 2017 – With all those source lines being sent to Mecrisp, it’s time to look a little more under the hood. Let’s start by pointing out that this article focuses on an STM32F103 µC running at 72 MHz, which is an ARM Cortex M3. Performance figures for the JeeNode Zero’s STM32L052 µC will differ, because it runs at a lower clock speed and because it’s a “simpler” ARM Cortex M0+. Many Forth implementations use a “threaded interpreter” design, but Mecrisp is different in that it compiles Forth directly to ARM machine code.
Forth over USB on STM32F103 – Feb 2, 2017 – Mecrisp Forth and its GitHub mirror make a wonderful interactive environment for a range of powerful ARM-based 32-bit µCs. There are a gazillion low-cost STM32F103-based boards available on eBay and AliExpress, such as this one, for example - often called the “Blue Pill”: But… out of the box, Mecrisp Forth only supports a serial port as console. Wouldn’t it be nice if we could load an extended version of Mecrisp Forth onto this board, which does console I/O over USB?
Using Linux instead of a SerPlus – Feb 1, 2017 – Uploading code to an STM32 ARM µC is a bit of a chicken-and-egg problem. The traditional setup uses JTAG (or more likely: 2-wire SWD), but this requires a JTAG programmer such as an ST-Link or a Black Magic Probe. As you will know by now, all STM32 µC’s also include a serial boot loader in ROM, which requires toggling the RESET and BOOT0 pins in just the right sequence. You can do this manually, but that can become very tedious after a few times.
Goodbye 2016, and hello 2017! – Jan 1, 2017 – Many very surprising things have happened (or failed to be resolved) in the world in 2016. But as far as this weblog is concerned, it can be summarised as: 52 weekly posts, 92 articles. 2016 A year ago, I wrote about my New Year’s resolutions for 2016. Commitments … tricky stuff! Resolutions, like most intentions, are easy to make. Looking back to see how they ended up after a year is another story.
Remote development over WiFi – Dec 31, 2016 – There’s a fascinating option for the JeeNode Zero, called the esp-link by Thorsten von Eicken. He also created a little board with a switching regulator, the ESP8266, and an FTDI header, and calls that a “WiFi-link”. The result is essentially like a “BUB/SerPlus over WiFi”: The esp-link firmware turns the ESP8266 into a transparent bridge from WiFi to FTDI serial, with the ability to control the DTR and RTS signals (RTS reuses the CTS pin next to GND for this purpose, just like the modified BUB and the SerPlus).
A high-resolution sensor node – Dec 30, 2016 – The JeeNode Zero is intended as sensor node in a Wireless Sensor Network. This requires: a sensor we can read out periodically, such as the BME280 being able to sleep with a very low current, as recently described the ability to run the node unattended, i.e. without FTDI cable formatting and sending the collected sensor readings over RF So far, all development has been performed through FTDI. To run unattended, we’ll need to cut that umbilical cord and make the node start up by itself from a battery.
Ultra low-power and coin cells – Dec 29, 2016 – Let’s explore the current consumption of a JeeNode Zero a bit and see how we can reduce it. The following measurements were all made with a low-cost Voltcraft VC170-1 multimeter, in series with the +5V power feed from SerPlus to JNZ - using the 400 mA range for now: power consumption, running just the Mecrisp core: 4.75 mA Once we load the always.fs, board.fs, and core.fs code in flash, and reset the board, power consumption will go up, because init in board.
Hey, there's a radio in there! – Dec 28, 2016 – The Forth driver for the RFM69 on the JeeNode Zero is in flib/spi/rf69.fs. It is normally included in core.fs and therefore always available from flash memory. It’s very simple to use: call rf-init to intitialise the RFM69 module, and then call either rf-recv to poll for new incoming packets or rf-send to send out a single packet. The current driver does not use any interrupt pins, so only the RFM69’s 4 SPI pins plus power need to be hooked up.
JNZ testing and availability – Dec 25, 2016 – At the time of writing this (end Dec 2016), there have been three prototyping rounds for the new JeeNode Zero. The current “rev3” board is getting close to the intended final release - the STM32L052 µC is a good choice, and due to STM’s impressive chip compatibility, the same PCB can be used with a variety of other lower-cost or higher-performance chips. There’s an optional CR2032 coin cell holder on board, which sets the stage for a very small self-contained Wireless Sensor Node.
Taking the JNZ rev3 for a spin – Dec 24, 2016 – Let’s make the JeeNode Zero do some simple things. Like blinking LEDs in a continuous loop: The code for this was actually written step by step, and later saved in a file called ex/leds.fs: forgetram \ configure one pin as push-pull output : out ( pin -- ) OMODE-PP swap io-mode! ; \ configure all the LED pins as outputs : setup PA0 out PA1 out PA2 out PA3 out PA4 out PA5 out ; \ turn one pin on for 100 milliseconds : blip ( pin -- ) dup ios!
This node speaks Forth (and C) – Dec 23, 2016 – If you’ve been following the weblog for a while, you may have noticed that there’s a strong Forth wind blowing nowadays at JeeLabs. The JeeNode Zero is designed for use with Forth. Setting up a Mecrisp Forth unit is very simple if you use the latest release of Folie, i.e. version 2.8 or later, since it includes all the necessary firmware: $ folie Folie v2.8 ? Select the serial port: 1: /dev/cu.
Some specs and comparisons – Dec 22, 2016 – To get an idea of the differences between the original JeeNode v6 and the new JeeNode Zero, we can first of all view them side by side: No more through-hole parts - there are almost no µCs available anymore in the easy-to-socket Dual Inline Plastic (DIP) package. The pins of a TQFP chip are 0.8 mm apart, less than a third of the 0.1” standard breadboard grid. With a little experience it’s still quite doable to solder these by hand, but you’ll need a fine-tipped soldering iron, tweezers, flux, wick, and patience.
Working on the JeeNode Zero – Dec 21, 2016 – The JeeNode v6 was created several years ago, to combine the convenience of the then-still-upcoming Arduino IDE with low-power wireless communictation: It all worked – and still works – really well, with over half a dozen nodes running at JeeLabs, sending out a bunch of sensor readings every minute or so. Due to their ultra low-power sleep mode, these nodes tend to run unattended for one to two years on 3 AA batteries.
Cutting the serial cord, sort of – Dec 19, 2016 – There’s a hardware USB device peripheral in every F103 chip. It has been quite a long journey, but the code is now finally at a stage where it can be used as serial console for Mecrisp Forth. You will need the Folie utility, version 2.7 or later, a Blue Pill which will be re-flashed, and a way to do so over serial or SWD - such as a second Blue Pill, configured as SerPlus unit:
Making an LED blink (and fade) – Dec 18, 2016 – Just like C-based code benefits from a runtime library with utility functions, Forth can benefit from a set of pre-defined words to talk to the hardware peripherals built-into every F103 µC. This utility code has been written from scratch for Mecrisp Forth, the STM32F1 series of µC’s and some of it also for other STM32 variants. It’s still experimental, but working out nicely. All the code lives in the embello area on GitHub, in a folder called explore/1608-forth/flib/:
Let it burn, then press CTRL-C – Dec 17, 2016 – We’re about to try out Forth on real hardware. The implementation used here at JeeLabs is Mecrisp Forth by Mattias Koch. It’s fully open source (GPL3), it’s well-supported, it’s robust, it’s available on a range of platforms, and it’s documented (very concisely, as usual in Forth). There’s a firmware image of Mecrisp Forth for F103 built into Folie, which makes it easy to get started. If you’ve been using Folie, you’re just 3 steps away from installing Forth on a Blue Pill.
Polish notation and tiny words – Dec 16, 2016 – Ok, so what is this “Forth” thing like, as programming language? One way to answer this question, is to point to the Forth in 7 easy steps article, published a while back on this weblog. Go ahead and read it, it’ll definitely give you a first impression. Forth was invented by Charles Moore, an independent thinker who is clearly not bound by “mainstream conventions”. Here’s an interview with him about Forth.
Peeling off layers of complexity – Dec 15, 2016 – As you know, compilers generate code. They take one or more source files and turn them into an executable. In the case of embedded software development, the compiler is actually a cross-compiler because it’s not generating code for the machine it’s running on (your laptop), but for the attached board (a little “target” microcontroller). The generated code is simply a chunk of binary data - gibberish, as far as we humans are concerned.
Stop staring at that screen! – Dec 14, 2016 – Embedded software development can usually be characterised by the following diagram: In other words: a “host” computer with a cross-compiler, where you enter code, compile it, and upload it to a “target” system which by itself does not have the processing power and memory to handle such a “toolchain”. Maybe you’ll also be using a “debugger” which lets you single-step, set breakpoints, and view variables values and raw memory on the embedded µC.
Fancy serial with a SerPlus – Dec 12, 2016 – So far, to upload new code to a Blue Pill, you had to change a jumper, press reset, perform the upload, change the jumper back, and press reset again - this will quickly become very tedious! So why not let the host computer do this? What we need is a way to control the RESET and BOOT0 pins of the ARM µC. Reset is easy, and can be done in way similar to the Arduino: tie it to DTR (“Data Terminal Ready”), and have the host computer control this “modem control” pin.
Hooking up an RFM69 radio – Dec 11, 2016 – It’s time to step things up a bit. Let’s create a wireless node, with an RFM69 attached to an F103 µC, and then see if we can make it sing… We’re going to need two nodes, if we want to actually test packet transmission and reception. Here is one node, hacked together with a Blue Pill and some fancy soldering: The connections to the radio module are as follows, apart from +3.
LED blinks and serial echoes – Dec 10, 2016 – Compiling software for the F103 is very easy but – as so often – does take a little preparation. In this case, we will need set up a few build files and make sure they are correct for the F103. But first, let’s create a new directory and “chdir” into it: mkdir ~/myf103apps cd ~/myf103apps Then you need these 3 files, which can all be downloaded from GitHub: Makefile.include - contains a few settings to select the F103 rules.
We need a toolchain and library – Dec 9, 2016 – Now that the connections and uploading have been dealt with, let’s turn to generating code. First of all, we need a C/C++ compiler: this one. GCC is now at version 5.0, but 4.8 is also fine (there have been some issues with 4.9 on ARM Cortex, it’s perhaps better to avoid that one…). You could just go ahead and download from the links mentioned above, but there’s another way - which might not require a download at all if you’ve already been working with Arduino or JeeNode boards.
USB serial is a good way to go – Dec 8, 2016 – Note: let’s use “F103” as shorthand to avoid typing “STM32F103C8T6” all the time The F103 has a built-in ROM-based boot loader, so there’s no risk of ever damaging it, but it’s quite limited since it can only deal with a serial connection on the USART1 pins (PA9 for TX and PA10 for RX). There is no way to reflash an empty or messed-up F103 from USB. In addition, every ARM chip has either JTAG hardware built-in, or its low-pincount variant, called SWD.
Let's start with a Blue Pill – Dec 7, 2016 – If you search for “stm32f103c8t6 board” on eBay, you will get lots of hits for what is essentially a single product, to be called the “Blue Pill” from now on: The price of these boards is absolutely incredible, you could get 10 of these for the same price as an official Arduino Uno. At these prices, which are lower than the official price quoted for the µC chip alone, it’s really tempting to permanently include one in every project.
USB serial in Forth, progress! – May 28, 2016 – A while back, an article was posted about the lack of USB on STM32F103 µCs, when it comes to Mecrisp Forth, that is. Unfortunately, getting the built-in USB device-mode hardware working is quite a challenging task. Not only is the USB protocol fairly complex - the actual USB interface hardware on that particular model STM µC is in fact ridiculously messy! It has all the appearances of a rushed-to-market design, just to get that USB feature shipping!
Using a buffered serial console – May 27, 2016 – Mecrisp Forth comes with a serial-port command line interface. This makes both tinkering and uploading new code a breeze, but it’s nevertheless a fairly limited setup: no input buffering: if characters come in while the code is busy, they can get lost no output buffering: sending any text to the console will block until all data is sent the greeting sent to USART1 cannot be changed or redirected (at least in Mecrisp 2.
The need for multitasking – May 26, 2016 – With an increasing number of sensing and reporting activities taking place on the JeeLabs Energy Monitor (JEM) prototype, things are starting to become a bit more complicated. How can we deal with such a multitude of tasks, each with their own timing requirements? The traditional (or perhaps one should say: modern?) answer to this is to include a Real-Time Operating System, which has built-in task switching and can offer some hard guarantees on how quickly a task can be triggered to run on specific external events.
Parsing P1 smart meter info – May 25, 2016 – The smart meter at JeeLabs looks like this: It’s a Landis & Gyr E350, which monitors all power coming into the house and going out (when solar PV production exceeds local consumption). There’s an RJ12 jack on the bottom right, with serial data coming out at 9,600 baud (newer units send at 115,200 baud). Every 10 seconds, a “telegram” of information is sent out, which looks something like this: /XMX5XMXABCE000046099 0-0:96.
Simple variable packet data – May 20, 2016 – Until now, most of the wireless sensor nodes here at JeeLabs have been using a simple “map C/C++ struct as binary” approach as payload format. The advantage of this is that it simplifies the code in C (once you wrap your mind around how structs and binary data are stored in memory, that is) - but it’s also a bit C-specific, compiler-dependent, and not truly flexible. With Forth now taking over both sides of the wireless RF link, it’s time to revisit this approach.
Frequency aliasing in ADCs – May 19, 2016 – This is a pure sine wave, captured by the ADC + DMA code, as described previously: The plot above consists of 800 samples, sampled 40 µs apart, i.e. at 25 kHz - for a total of 32 ms. A quick calculation would seem to indicate that we’re seeing 1.6 cycles of a 50 Hz sine wave. Except that it’s not… the incoming signal used here was a 24,950 Hz sine wave!
Tracking pulses w/ interrupts – May 18, 2016 – There are three pulse counters for measuring power at JeeLabs - one for solar PV production and two for the kitchen stove and the rest, respectively: These generate 2000 pulses per kWh, that’s one pulse per 0.5 Wh, and are optically isolated. Reading them out is super simple: add a 1 kΩ series resistor and power them from 3.3V .. 5V. The result is a series of clean “1” pulses, each 100 ms long (there’s no contact bounce).
Some µC speed measurements – May 13, 2016 – Not long ago, Ken Boak very generously donated one of his assembled PCB designs to JeeLabs: This is a break-out board for the STM32F746VG, an ARM Cortex M7 CPU with floating point and a whopping 1 MB flash + 320 KB RAM, all in a 100-pin SMD package. Lots of I/O hardware, including USB and Ethernet, lots of analog I/O with three ADCs capable of millions of samples per second each, and a dual DAC.
Great ADC/DMA performance – May 12, 2016 – For the “JEM” JeeLabs Energy Monitor, we’re going to need to put the ADC on the Olimexino’s STM32F103 to some serious work: the goal is to acquire 4 ADC channels at 25 Khz each, so that we can capture a full cycle of the 50 Hz AC mains signal with a resolution of 500 samples, as well as collecting the readings of up to three current transformers. Since AC mains voltage is being sampled via the negative peaks of the incoming 9V AC supply, we really only get half cycles, with flat segments in between.
When an input pin isn't one – May 11, 2016 – The article about the ESP-Link ended with what turned out to be an ominous note, in hindsight: There’s still a buglet in this setup: the “reset” word leads to a runaway loop of “Unhandled Interrupt 00000003” - but this can be recovered through […] Something really strange was happening: toggling the DTR pin from the ESP-Link did correctly reset the Olimexino but doing a software reset sent the Olimexino into a tail spin And here were the crazy bits:
Measuring AC supply voltage – May 5, 2016 – With the JeeLabs Energy Monitor prototype hooked up in the meter cabinet, it’s now very easy to explore things a bit. One interesting test is to look at the analog signal from the AC power supply + divider, which is connected to pin PA0. Here is some code which samples that signal and prints it out until a key is pressed: : a1 +adc begin pa0 adc . key? until ; a1 4029 4031 4030 4030 [.
A remote console w/ ESP-Link – May 4, 2016 – The ESP-Link is a clever project, which turns an ESP8266 WiFi module into a transparent serial link - sort of a wireless FTDI interface. Thorsten not only created a really powerful software package for this, he also built a few prototypes to turn this into a small “BUB-like” package: Here’s the schematic of what’s on this board: An ESP8266 and a switching regulator to bring the 5V down to 3.3V, basically.
Reading out the pulse counters – Apr 29, 2016 – Unfortunately, progress on pulse input recognition has been a bit slow - partly due to unrelated “time sinks” - so this will be an overview of some other details of the JeeLabs Energy Monitor. The mounting bracket was 3D-printed from a design on Thingiverse, with these parameters: pcb_width = 53.5; pcb_length = 53.5; pcb_height = 2; slisse = 1; pcb_bottom_margin = 10; wall_width_thick = 2.5; wall_width = wall_width_thick-slisse; box_height = 16; This custom-sized “clip” holds the Arduino-shaped board nicely, with room for the LiPo battery.
Powering from an AC source – Apr 28, 2016 – Ok, we have a name: “JeeLabs Energy Monitor” - and we have a board to use: the Olimexino-STM32. As mentioned before, that board has a number of convenient features for this project. Then again, any other board can be used - most differences are minor, and there is a huge variety to choose from. Even the “F103” µC family is not really important. Since the F103 is mature, and this is a low-end 128K flash / 20K RAM unit, most other µC’s should be fairly easy to port to.
Energy monitor requirements – Apr 27, 2016 – The meter cupboard is - as one would expect - the place where lots of energy-related matters come together. Here is the situation as of early 2016 at JeeLabs: Note: that “JeeLabs Energy Monitor” is wishful thinking and vapourware at the moment. There is also an FTTH internet modem, feeding an ethernet cable going upstairs to the FritzBox wireless router. And lots of wiring, no longer used: a splitter feeding TV and radio signals into four different cables, with sockets at various places in the house (replaced by a single DVB-T receiver in the living room), as well as a maze of old telephone wires.
A new design, moving to 32-bit – Apr 22, 2016 – With one of the two main energy metering nodes out of order, it’s becoming more urgent now to implement a replacement. It would be a shame to break the cycle, after some 8 years of data collection, all logged and waiting for future visualisation. There are quite some signal sources, more than a simple JeeNode w/ ATmega328 can easily handle. Given the recent focus on STM32F103-based boards, it should come as no surprise that this has also been picked as base for the new node.
And then the JeeNode stopped – Apr 21, 2016 – Unfortunately, the USB power supply is not all that got damaged by the water leak: There’s a blueish sludge on the RJ12 jack. Presumably some copper salt caused by humidity and corrosion. This is a little JeePlug board on top of a JeeNode, which is used to detect pulses from three different 2000 pulse/kWh counters. This is what it looked like three and a half years ago: The Arduino IDE based code it was running is on GitHub.
Water and electricity don't mix – Apr 20, 2016 – The hot water tap in the kitchen at JeeLabs is provided by what’s called a “close-in boiler” in the Netherlands: a small 7L electrical boiler, sitting under the kitchen sink and hooked up with two reinforced flexible hoses, similar to the ones often used in showers. The rubber in these hoses is probably high-grade, but their normal lifetime is rated at 10 years. At JeeLabs, they were 19 years old and decided to start spraying, as you can see in this close up:
Better speed and sensitivity – Apr 15, 2016 – First off, let’s find out how that last single op-amp circuit works in practice. The chip used is an LMC6484 quad CMOS op-amp with extremely high input impedance. Since it’s also rail-to-rail on both inputs and outputs, the Vs+ positive supply can be 5V and the negative Vs- supply can be -5V, as generated by the TC7660S negative voltage generator (it’s a small DIP-8 package which only needs two 10 µF capacitors to work).
Op-amp parameters explained – Apr 14, 2016 – It can’t be shown often enough - the most elegant building block in electronics: In an ideal op-amp … the V+ and V- inputs have infinite resistance there is zero current into and out of both V+ and V- if V+ is above V-, however slightly, then Vout will be Vs+ if V- is above V+, however slightly, then Vout will be Vs- when V- is V+, Vout will be halfway between Vs+ and Vs- the gain of the amplifier is infinitely large when V+ and V- change by the same amount, Vout stays the same as long as in-/outputs are within Vs+ and Vs-, changes to Vs+ and Vs- have no effect the behaviour is identical for any frequency, temperature, and time span Back on earth, things are a bit less rosy.
Slowed-down by the slew rate – Apr 13, 2016 – Let’s re-visit the voltage meter for a moment - the actual circuit used in the next test differs in a few resistor values, but it’s still essentially the same as the triple op-amp setup described earlier. Here are the two main op-amps involved (omitting the 3rd one, used for the reference voltage): Let’s inject a 10 KHz square wave into this circuit, and see how it behaves: The input signal is shown at the top, in purple.
Let's measure ± 20V @ 11MΩ – Apr 10, 2016 – So much for theory and design. Here’s a built-up version of the voltmeter: It was built as add-on for the RF Node Watcher, here’s the side view of this sandwich: Everything was built with through-hole parts, the LM324 and LT1413 op-amp chips (quad and dual, respectively) were mounted on the bottom, to provide easy access to all their pins from the top and allow simple experimentation & soldering. The ST232C chip was mounted in a free spot, with the 4x 0.
Fixing the offset problem – Apr 9, 2016 – There is still a fairly serious flaw in our little voltmeter setup: its Vin input is not at ground level. It’s connected via Z1 and Z2 to that 2.4V or so virtual ground we just created, and when Vin is not connected to anything, it will read as 2.4V instead of 0V. More importantly, this means that when we connect this to a circuit-under-test, it is likely to influence that circuit by injecting a bit of current.
Op-amps and virtual ground – Apr 8, 2016 – The voltage-divider-tied-to-3.3V trick allows shifting the level of an input voltage to another range. But there are a few issues with it. The first one is that we still cannot measure anything above 3.3V this way. Regardless of the values of Z1 and Z2, higher voltage would cause Vout to rise above 3.3V: not good for the ADC. We could consider combining two voltage dividers, i.e. the first to reduce the voltage swing, feeding the second one for level shifting, but generally that’s not a good idea:
Measuring negative voltage – Apr 7, 2016 – The task to be tackled here is measuring voltage ranging from +N to -N Volt with an ADC input which needs to be kept in the range 0 to 3.3V. There are numerous resources all over the web which solve this puzzle. The focus here is to help you get some intuition, and not just to come up with a solution and its “explanation”. If this is new for you: hang in there.
The limitations of the ADC – Apr 6, 2016 – The Analog-to-Digital-Converter (ADC) we all know from Arduinos and other µCs is a marvel of integration and electronics engineering. Able to measure at rates of over a million samples per second (depending on the µC), you can just select an I/O pin, start an ADC conversion, wait briefly, and then you get a reading back - usually either 0..1023 for a 10-bit ADC or 0..4095 for a 12-bit ADC, representing input signals from 0.
Adding the RFM69 module – Apr 1, 2016 – The last step to create a wireless node is to hook up the RFM radio. Here is what we’re after: There are 4 signals and 2 power pins to connect (more can be added later, for pin interrupts): RFM69CW STM32F103 BOTH SSEL (NSS) PA4 +3.3V SCLK PA5 GND MISO PA6 MOSI PA7 And here is the other side, all hooked up with thin “Kynar” wirewrap wire in this case:
A new serial tool: vive la Folie! – Mar 31, 2016 – UPDATE Jan 2017: this article still describes Folie v1. All the links below have now been changed to point to Folie v2. The usage of v2 has changed a bit, see GitHub and this page. Working with embdded µC boards involves quite a few steps: apart from the hardware itself, you need to connect to it and figure out how to upload code, of course. But you also think about the development cycle and revision control.
Preparing for serial re-flashing – Mar 30, 2016 – The STM32F103 µC chips all have a ROM-based boot loader on board. Most chips variants can only be re-flashed via USART1, using the PA9 and PA10 pins, so we will need to connect to that serial port initially - even if the board is intended to be used only over USB or RF later on! This is the “Blue Pill” board which will be used in this example: Boards like these are very common, low-cost, and easy to find (on eBay, for example).
Forth in 7 easy steps – Mar 24, 2016 – Forth is a simple language, with simple rules and a simple execution model. It’s also self-hosted and interactive - you can type this at the prompt: 1 2 + .<cr> What you’ll get as response is this (details may differ, everything below is for Mecrisp Forth): 1 2 + . 3 ok.<lf> ^^^^^^^^^^^ added by Forth All code is parsed into a sequence of “words”, which is anything between whitespace. The above code consist of 4 words: 1, 2, +, and .
USB on STM32F10x µCs – Mar 23, 2016 – Every µC from the STM32F10x family has hardware built-in to support USB. The earlier (i.e. smaller) STM32F103’s have a more limited implementation that more recent models. There are some really strange design choices in it - they look like a rushed-to-market implementation: there’s a 512-byte buffer where everything USB-related happens, but this memory must be accessed as 256 16-bit words on 32-bit address boundaries, i.e. there’s a gap every 2 bytes some registers live on the APB1 bus like the rest, others live inside this “Packet Memory” some bits in the registers can’t be set directly, only toggled - this means you have to read the current value, determine what to toggle (via XOR), and then send those toggle bits (while carefully keeping others in a do-nothing state) Having seen some FPGA designs recently, it’s clear that this is caused by the two different clock domains of the µC on the one hand (normally 72 MHz) and the USB hardware on the other (48 MHz, but not necessarily synchronised).
JET and Forth, some thoughts – Mar 18, 2016 – The JET project is about “creating an infrastructure for home monitoring and automation” (it’s actually considerably more, but this is a big-enough bone to chew on already…). Note that JET is not about individual µCs or boards, it’s about managing an entire set of nodes, warts and all, and heterogenous from the start. JET is about bringing together (and bridging) lots of technologies, and about interfacing to existing ones as well.
The lack of USB support – Mar 17, 2016 – Those pictures you’ve been seeing in recent articles, with over a dozen boards by now, all have the same configuration in common: boards with a USB port on them, connected and powered through anything but that USB port… There is some value in this hookup - in fact, either this or an SWD-based setup using a Black Magic Probe or an ST-Link is required to be able to upload the core Mecrisp Forth 2.
Diving deep into STM32F103's – Mar 16, 2016 – Mecrisp Forth 2.2.2 has been flashed onto a new series of boards here at JeeLabs, all with an STM32F103 µC, but of different sizes and with different features on-board. Haoyu Core Board One Well, it’s called a HY-STM32F1xxCore144 Core/Dev Board, but “Core Board One” sounds nicer: This board has a µC with a huge number of pins in a 144-TQFP package, most of which are brought out on 0.1” headers (two dual-row 30-pin, for a total of 120).
Reading ADC samples via DMA – Mar 12, 2016 – Now that we have seen how to push out values to the DAC without CPU intervention… can we do the same for acquiring ADC sample data? The answer is a resounding “yes, of course!” And it’s not even hard, requiring less than two dozen lines of code (full details on GitHub): : adc1-dma ( addr count pin rate -- ) \ continuous DMA-based conversion 3 +timer +adc adc drop \ perform one conversion to set up the ADC 2dup 0 fill \ clear sampling buffer 0 bit RCC-AHBENR bis!
The amazing world of DMA – Mar 11, 2016 – There are a lot of features hiding in today’s microcontrollers - even the STM32F103 series includes some very nice peripherals: 2 to 3 A-to-D converters, sampling up to a million times per second on the larger devices: dual D-to-A converters, with 3 µS rise times 2 to 3 hardware SPI interfaces, supporting up to 18 Mbit/s 2 to 5 universal serial ports, some of them supporting up to 4.5 Mbis/s That’s a lot of data, once you start using these peripherals.
LCDs need a lot of bandwidth – Mar 10, 2016 – So far, we have created two display implementations for Mecrisp Forth: a 128x64 OLED display, connected via (overclocked) I2C, and a 320x240 colour LCD, connected via hardware SPI clocked to 9 MHz. While quite usable, these displays are not terribly snappy: the OLED display driver uses a 1 KB ram buffer, which it sends in full to the OLED whenever “display” is called - this currently requires about 60 milliseconds
The Dime-A-Dozen collection – Mar 9, 2016 – One attraction of the STM32F103 series microcontrollers, is that there are lots of them available on eBay at ridiculously low prices. There are many variants of this µC, with flash memory sizes from 64K to 512K (and beyond, even), and with anything from 36 pins to 144 pins. If you search on eBay for “stm32f103 board”, the first one that might pop up is perhaps this one: Here are a few more, all running Mecrisp Forth 2.
Talking to a 320x240 colour LCD – Mar 4, 2016 – Now that we have a fast SPI driver, we can tackle a more ambituous task of driving a 320x240 colour LCD display. In this example, we’ll use the HyTiny board with this 3.2” display, because the two can be connected via a simple 12-pin FPC cable (included with the display). When you do the math, you can see that there’s a lot of data involved: 240 x 320 x 16-bit colour (max 18-bit) requires 153,600 bytes of memory (172,800 bytes in 18-bit mode).
Much faster SPI with hardware – Mar 3, 2016 – Unlike an USART-based serial port, SPI communication is not timing-critical, at least not on the SPI master side. Since the data clock is also sent as separate signal, slowdowns only change the communication rate. That’s why SPI is so easy to implement in bit-banged mode, as shown here. But software implementations are always going to be slower than dedicated hardware. So here’s a hardware version which drives the clock at 9 MHz, 1/8th the CPU’s 72 MHz master clock:
Buffered serial port interrupts – Mar 2, 2016 – Mecrisp only implements the minimal serial interface required, i.e. USART1 with polled I/O. This is very limited, because the serial port has no buffering capability: if we don’t poll it often enough (over 10,000x per second for 115200 baud!), we risk losing incoming input data. The standard solution for this is interrupts: by enabling the RX interrupt, we can get the data out in time for the next one to be processed.
Starting Forth on an STM32F1 – Feb 27, 2016 – Here is what we’re after, as Forth Development Environment (would that be an “FDE”?): There are a number of steps needed to use Mecrisp-Stellaris Forth in your own projects (for these articles, we’ll be focusing on the STM32F103 µC series with 64..512 KB flash memory): getting the Mecrisp core “flashed” onto the microcontroller setting up a convenient connection between your laptop and the µC board streamlining the iterative coding cycle as much as possible Note that this is in some way quite similar to hooking up an Arduino or JeeNode, and developing software for it through the Arduino IDE.
I/O, ADCs, OLEDs, and RFM69s – Feb 26, 2016 – Software development in Forth is about “growing” the tools you need as you go along. Over time, you will end up with a set of “words” that are tailored for a specific task. Some words will end up being more reusable than others - there’s no need to aim for generality: it’ll happen all by itself! Digital I/O Let’s start with some examples for controlling GPIO pins on an STM32F103:
DSLs and expressiveness – Feb 25, 2016 – The KEY design choice in Forth is its dual data- and return-stack. Forth is a stack-oriented programming language. Another characterisation is that Forth is a concatenative language. Here’s what this means: Data is manipulated on a stack - this example pushes “1”, then “2” on the stack, then applies the “+” operation on those two values, replacing them with their sum, and ends by running the “.” operation which pops-and-prints the top of the stack, i.
Forget what you know, please – Feb 24, 2016 – In the beginning, there were computers. Programmed with wires, then with binary data (the “stored-program” computer), then with assembly language, and from there on, a relentless stream of new programming languages. Today’s web browsers all “run” JavaScript. Here’s a summary of that evolution again, in terms of technology: wires: just hardware circuits and manually inserted patch cords, yikes! binary data, i.e. “machine code”: a very tedious and low-level way of programming assembly: symbolic notation, macros, you have to keep track of all registers in your head Fortran, Cobol, Algol, Pascal, C: yeay, it gets compiled for us!
Some amazing software feats – Feb 20, 2016 – The introduction of the PDP-8 series was a disruptive, game-changing event, in that it made computers available to a large group of scientists, engineers, and tinkerers. For the first time, more or less, you could walk into a room, sit down at a teletype, and start programming. No more “batch jobs” and “reserving” time on a huge, scarce, over-booked, expensive machine. Instructions and memory The PDP-8’s instruction set is very well documented elsewhere.
Hey PDP-8, meet Raspberry Pi! – Feb 19, 2016 – If you would like to experience for yourself how a computer such as a PDP-8 looks and feels, there are several possible avenues to choose from: get in touch with a museum, friend, or hobbyist who has “The Real Thing”, and see if you can get a demo or schedule a session look for old equipment dumps, maybe some company, university, or individual wants to give, sell, or lend such a machine to you get hold of schematics, spare parts, and go try and build one yourself, possibly re-using any original parts available to you download a software simulator for the computer model you’re interested in, and have a go at running this virtual environment design your own emulation, possibly adding some fancy lights and switches to make it more realistic and tangible than a software-only emulation look for a kit and build it yourself, knowing that others have done the same, with support from the kit maker and/or other builders who went before you This article is about that last option.
Computer peripherals in 1965 – Feb 18, 2016 – Ok, so now we have our computer. How does it interface to the real world? How do we talk to it? How do we tell it what to do? Do we login to it? Or is it all about switches and blinkenlights? No tablets, no LCDs, no video screens, no internet yet, no Ethernet yet, no local area networks! The main interface was the teletype, a big and noisy hardcopy printer, keyboard, paper tape reader, and paper tape punch, all in one.
Inside the PDP-8 hardware – Feb 17, 2016 – In 1965, computing history was made when DEC introduced a new computer, called the PDP-8. It was the start of a long series of incrementally improved models, later to be followed by the even more successful and ground-breaking PDP-11 series, and then the VAX. It’s a fascinating story, because so many technological trends of that time have shaped what we now use on a daily base, from laptops, to mobile phones, to watches.
A new web front-end design – Feb 13, 2016 – JET is going to need a web interface. In fact, it’s likely that a major part of the total development effort will end up being poured into this “front-end” aspect of the system. After many, many explorations, a very specific set of tools has been picked for this task, here at JeeLabs. It’ll all be JavaScript-based (ES6 as much as possible), since that’s what web browsers want. But unlike a number of earlier trials and actual builds of HouseMon, this time we’ll go for a fairly plain approach: no CoffeeScript and … no ClojureScript.
JET development mode setup – Feb 12, 2016 – Since JET is intended to remain always-on, at least as far as the hub is concerned, we need to be a little careful how we introduce changes. The way to do this in JET, is to treat the whole system as one, whereby development simply happens to be inactive some of the time: The hub, and all the interfaces and JetPacks it has been told to activate, will continue to run no matter what (unless they crash or fail in some other way, evidently).
System requirements for JET – Feb 11, 2016 – One of the main design goals for JET, is that it must run well on very low-power Linux boards. The reasoning is that you really don’t need much computing power at all to manage all the data flows involved with home monitoring and automation. It’s a very slow kind of real-time system, with at most a few events per second, and most of the time nothing else to do than collecting the incoming sensor data for temperature / light / door / motion sensors, etc.
The JET data store, take 2 – Feb 10, 2016 – This article supersedes this one - but it’s probably still useful to read that original article first. While many of the design choices remain the same, the API has changed a bit. The description below matches what is currently implemented on GitHub and included in the latest release. Terminology and semantics What hasn’t changed, is the way the data store is tied into MQTT. The hub listens for messages matching “!
Distributed node functionality – Feb 6, 2016 – Just to avoid any possible confusion: the case made in the previous article for “centralised node management” is not meant to imply that nodes need to operate in a centralised fashion! This is where design and development are really distinct from the decisions on what remote nodes (wireless as well as wired) actually do. We may well want to design a home automation infrastructure where a light-switch node sends out a signal when pressed, only intended for another node in the same room, controlling a lamp attached to it.
Centralised node management – Feb 5, 2016 – There are a number of ways to avoid the long-term mess just described. One is to make the target environments aware of source code. For example by running a Basic / Forth / JavaScript / whatever interpreter on them - then we can work on the target environment as with a regular development platform: the source stays on the target, and whenever we come back to it, we can view that code and edit it, knowing that it is exactly was has been running on the node before.
Creating a long-term mess – Feb 4, 2016 – So you’ve set up a Wireless Sensor Network, i.e. 2 or more “nodes”, talking to each other via RF. This being a JeeLabs article, let’s say you’re using a JeeNode, JeeLink, or other ATmega/tiny-based board with an RFM12 or RFM69 wireless radio module - or perhaps some self-made variation, using some neat flashy ARM µC. Everything is working fine. Great! And as time passes, you add more nodes. Fun! Some nodes are just like the previous one, for example a “Room Node” to monitor temperature, humidity, motion, and light levels in a room, and some nodes are different, such as an OOK Relay, or a LED Node to control LED strips, or … whatever, you get the idea.
From crontab to systemd – Feb 3, 2016 – The crontab “@reboot” approach mentioned in the hub’s installation guide has as benefit that it’s very easy to do, without the risk of messing up anything serious, because it doesn’t involve “sudo”. It also should work on just about any system - cron has been around for a long time. But if you’re willing to do just a little more work, there’s actually a more flexible mechanism in recent Linux distributions, called systemd: it will take care of starting and stopping a service, all its output logs, and catching any runaway or otherwise failing launches.
Using the built-in database – Feb 1, 2016 – (This information has been superseded by a newer design with an updated API) The “database” built into JET/Hub is set up as a general-purpose key-value store - i.e. persistent data storage which can’t store or retrieve anything other than (arbitrary) data by key. Whereby the keys are treated as a hierarchical structure separated by forward slashes (“/”). This database looks very much like an ordinary file system, and also very much like an MQTT topics hierarchy.
Hub configuration guide – Jan 31, 2016 – The JET/Hub process has two types of configuration settings: startup configuration, such as how to connect to MQTT and the name of the data store run-time configuration, such as which serial ports to open, and which packs to launch Command-line options Since the hub is intended to run virtually “indefinitely” once started, only very few configuration settings are specified via command-line options, and any changes will require a hub restart:
How to install JET/Hub – Jan 30, 2016 – Installation… ah, the “joys” of modern computing! 1. Prerequisites To try out JET, you need: a Raspberry Pi, Odroid, OLinuXino, or similar ARM-based Linux board a working Linux setup on your particular board, e.g. Raspbian or Ubuntu the ability to login on your system via SSH over the network some basic familiarity with Linux and the “shell” command line a link to the latest JET release on GitHub: here it is … a bit of patience to skim through this setup guide (yep, go right ahead!
Timestamps and logging – Jan 29, 2016 – Keeping track of time across different systems is not as straightforward as it might seem: every clock has its own notion of time, and always drifts around to a certain extent. There’s an entire community around the challenge of trying to keep track of time as accurately as possible. In an absolute sense, you can’t actually win in this game - it’s very Heisenberg-like, in that there will always be some uncertainty, even if only at the femtosecond level!
Connecting to serial ports – Jan 28, 2016 – The main mechanisms for communicating between devices around the house in JET are via serial communication and via Ethernet (LAN or WLAN) - often in the form of USB devices acting as virtual serial interfaces. For simple radio modules used for a Wireless Sensor Network, we can then use a USB or WiFi “bridge”. Other (less common) options are: I2C and SPI hardware interfaces, and direct I/O via either digital or analog “pins”.
An introduction to JET/Hub – Jan 27, 2016 – This is the start of a series describing “JET v4”, and in particular the “hub” subsystem. JET is a system which is intended to bring together all the home monitoring and automation tasks here at JeeLabs, for the next 10 years… As mentioned before - and as its name indicates - “JET/Hub” is the centrepiece of this architecture. It’s the switchboard which sits between the various (and changing) components of the system, including: from serial ports, bridges to Wireless Sensor Networks, and directly-attached I/O hardware, to software-based functionality, e.
Architecture: it's all about data! – Jan 22, 2016 – Code vs. data… there are many ways to go into this oh so important dichotomy. Here is a famous quote from a famous book, now over four decades old (as you can tell from its somewhat different terminology, i.e. flowcharts <=> code, tables <=> data): Show me your flowcharts, and conceal your tables, and I shall continue to be mystified; show me your tables and I won’t usually need your flowcharts: they’ll be obvious.
Ongoing software development – Jan 21, 2016 – Ok, with those (somewhat vaguely-defined) requirements down, how do we even start to move in this direction? Well, we’re going to have to make a number of decisions. We will need to build at least one program / app, of course, and we’re going to need to run it on some hardware. In a product setting (which this is not!), the steps would involve one or more people planning, designing, implementing, and testing the product-to-be.
JET, as seen from 9,144 meters – Jan 20, 2016 – The JET project name is an acronyn for “JeeLabs Embello Toolkit”. And with that out of the way, please forget it again and never look back. A few more acronyms will be explained when the subsystems are introduced - none of them particularly fancy or catchy - it’s just because we can’t move forward without naming stuff. Names and terms will be introduced in bold. As will become clear, this is a long-term project, but not necessarily a big one: this is not about creating a huge system.
Side-stepping the 0.06" mistake – Jan 14, 2016 – As mentioned before, the one thing standing between an Arduino and convenient protoyping, is that horrid 0.06” mis-alignment of one of its headers. No longer - meet this almost-too-trivial-for-an-article “Bridge Fifity-Fifty” (BFF) adapter: Bridge, because that’s all it does - and Fifty Fifty, because that is its size in millimeters. This is a simple pass-through board to convert in either direction between the Arduino shield header layout, and a layout suitable for numerous prototyping boards with a “sea of holes” on a 0.
A base board for the Hy-Tiny – Jan 13, 2016 – There are many Arduino “shields” out there, i.e. boards which fit on top of the Arduino Uno and compatibles. Even for one-off prototypes, it may make sense to use this form-factor, as it allows you to re-use a setup with a different µC board underneath (but watch out for 3.3V/5V issues!). This could be convenient with STM’s low-cost “Nucleo” boards - letting you switch to a different µC if the current one runs out of steam, or doesn’t have all the needed peripherals after all.
Keeping track of lab supplies – Jan 8, 2016 – There’s this nasty thing with electronics: There Are So Many Kinds Of Tiny Little Components! If you’re into hardware and building circuits, you’ll quickly find out that not only are there so many different resistors, capacitors, semiconductors, chips, sensors, LEDs, actuators, fasteners, wires, and so on… some of those SMD parts are also minuscule! - way too easy to lose track of. At JeeLabs, there are now about a hundred cardboard boxes filled with little plastic envelopes, mostly from DigiKey, but more and more also ordered directly from China:
Squashing tons of source code – Jan 7, 2016 – And then came internet, open source software, and public code repositories… Never before has it been possible to access so much software, of all kinds, in any programming language, for any application, and of all qualities & complexities. Even if not of immediate use “as is”, source code is a phenomenal resource - for knowledge, development ideas, engineering tricks, clever hacks - or simply to learn what others have done and how they have done it.
Sh(r)edding those CDs & DVDs – Jan 6, 2016 – If you’ve been around for a while, taking in the wonders of “personal computing” as it happened, then you’ll probably also have collected lots of disks with bits on them over the years. It started with floppies, from 8” to 3.5”, and then moved quickly to CD-ROMs and data DVD’s. Piles of them. Boxes and boxes. As part of some magazine, or even being a magazine. Here at JeeLabs there were over 500 of them, and that was after a large cleaning session about a decade ago!
My New Year's resolutions – Dec 31, 2015 – It’s that time of year again - the last day of 2015. Another year gone by. A new one waiting in the wings. In an increasingly connected and technocratic world. Time for making plans. Energy For 2016, my resolution is to reduce our dependence on energy and natural resources further still. The “JeeLabs household” has been a net producer of electricity for the past two years, but there’s still progress to be made:
Preparing for a new weblog – Dec 30, 2015 – Now that the WordPress-powered JeeLabs weblog has been replaced by a static set of pages, we need a way to continue adding new weblog posts and articles. The current approach is clearly an unsustainable “hack”: there’s still a copy of WP running the original weblog on a local VM, from which a new snapshot is tediously being created once a week. Luckily, there are many dozens of static website generators to choose from these days.
Great visibility, no cloud in sight – Dec 25, 2015 – Here is some wonderful art called “Nimbus-Probe” by Berndnaut Smilde, a Dutch artist: A cloud, captured inside a house - how very appropriate for this article! With the completion of the recent server migration, and some related changes, JeeLabs is now officially no longer “in” the cloud, i.e. there is no internet server “out there”, involved in serving the JeeLabs.org and JeeLabs.net websites. Well, up to a point, of course: there is still an ISP in the equation, providing connectivity, the routing of all traffic, and the DNS service.
Temporary post-HouseMon script – Dec 24, 2015 – With the original Mac Mini server now decommissioned, this also marks the end of the HouseMon installation here at JeeLabs. In this case, it was the older 0.7.0 release - based on Node.js and written in CoffeeScript - HM 0.7 has served us well, and now it’s gone… Unfortunately, there is no practical replacement for HouseMon at the moment - yet it sure would be a shame to lose all new readings still coming in from over a dozen wireless sensor nodes.
Getting the most out of rsync – Dec 23, 2015 – The rsync utility is an amazing workhorse tool: it synchronises file system trees in a very efficient manner, only sending changes in data. Which is particularly useful across a network connection, as it can save dramatically on I/O bandwidth and speed up the whole process, often by several orders of magnitude when compared to a full copy. Perhaps even more impressive, is that rsync knows how to send changes between binary files when some parts of the data have moved up or down in the file.
Why doesn't this dream setup exist? – Dec 18, 2015 – The beauty of an all-static website, is that it’s all data, and that it is fully defined by a set of files on the disk. By copying it, or restoring it to some previous state, we can instantly adjust the appearance of the website. No databases to launch, and no application servers. You would think that static websites are limited-purpose. But what is a weblog, or even a discussion forum, other than a set of pages which occasionally changes during the day?
Effortless fallback server – Dec 17, 2015 – All hardware breaks, occasionally. In the case of a server - it’s usually the storage which fails eventually, be it SD cards, eMMC, an SSD, or a rotating disk (remember those?). The new server setup at JeeLabs relies completely on a single Odroid XU4 in a CloudShell. What if it breaks, gets hacked, stolen, or otherwise ceases to work? Here’s the backup plan: we set up a second server, with fairly modest hardware, and we keep it around for when things turn sour.
VMs are OUT, Odroid is IN – Dec 16, 2015 – There are three main internet-facing web servers for JeeLabs - the weblog (jeelabs.org), the community site (jeelabs.net), and the shop (jeelabs.com). The shop is hosted elsewhere and managed by Digital Smarties, the other two have been running each in a separate VM. This has been the setup until now: one VM running Nginx for serving some static data and as reverse proxy for the rest one VM running WordPress, Apache, PHP, and MySQL - for the weblog one VM running Redmine, Apache, Ruby On Rails, and MySQL - for forums & wikis Note that three VMs help to cleanly compartmentalise these different systems.
TFoC - A wide performance range – Dec 12, 2015 – (This article is part of the The Fabric of Computing series - “in search of simplicity”) It’s a tricky business to try and define what constitutes the fabric & essence of computing. But it’s probably reasonable to say that computing is where physics and information meet: a transistor is not a computing device (but it can be used to create one) likewise, a logic gate is not a computer, but it sure forms part of it a software package (of any kind) is not a computer, but it does run on it So where does the FPGA fit in?
The language(s) of FPGAs – Dec 11, 2015 – First off: this is not going to be an introduction to VHDL or Verilog, the two languages normally used to define the configuration of an FPGA. There are books for that, it’s a huge field, and yours truly isn’t really versed enough in either of them… not yet, anyway. Let’s simply explore this whole domain a bit. Enough to get a feel for what’s involved. At the most basic level, you might expect a structural definition of the entire circuit, i.
Building a MultiComp-based Z80 – Dec 10, 2015 – Let’s see if we can build an FPGA-based system. The biggest challenge is that everything involved is completely different from software and hardware design. It’s a new ball game! We will need: some hardware (evidently, an FPGA is still a chip, just a different one) a design, this is essentially the schematic and wiring diagram a software tool chain to “synthesise” the design into a “bit stream” a way to upload that bit stream into the FPGA a connection between the FPGA and the outside world a healthy dose of curiosity, concentration, and time… There are too many unknowns and new aspects to this to tackle it all at once.
Move over, John von Neumann – Dec 9, 2015 – Computers do their work one step at the time. Over, and over, and over, and over again. The breakthrough came when not only the data they manipulate but also the instructions that drive their actions were stored in memory. You take data from memory, you “process” them in some way, and at times you also put something back. Most of it used to be about doing arithmetic - nowadays it’s more about pushing bits around in interesting ways than true “computation”.
TFoC - The Fabric of Computing – Dec 6, 2015 – So what is it with computing with limited resources? How can kids with enough time on their hands, a dose of ingenuity, and access to very limited (in today’s terms) computers create all sorts of software which fits and runs in 2000 to 8000 bytes of memory? While everything we build today with something like the Arduino IDE takes at least that much before we even start adding our own code?
JavaScript in a 128 KB µC – Dec 5, 2015 – As final entry in this episode of “fitting an interpreter into a 128K STM32F103”, there is one other very interesting development to consider. It’s called the Espruino project. Sure enough, we can fit this JavaScript interpreter into a µC with 128 KB flash and 20 KB RAM, albeit with not too much room to spare: $ HYTINY_STM103T=1 RELEASE=1 make 2>&1 | head Generating platform configs Generating pin info Generating JS wrappers WRAPPERSOURCES = src/jswrap_array.
Altair BASIC via 8080 emulation – Dec 4, 2015 – Some of this retrocomputing emulation goes quite far. Some emulators running code for these old machine can generate a video out signal - with an entire community around the computers people used to tinker & play with in their youth. See RetroPie, for example. Let’s not go there for now, but we could try an emulation of a more general-purpose low end machine, from the 1970..1980’s era. Such as this clunky beast, called the Altair 8800:
Creating a virtual 6502 chip – Dec 3, 2015 – Ok, we’ve seen Tiny BASIC, and how it turned a µC into a complete, albeit limited, programming environment. It took a mere 17 KB of flash memory. Now watch this: [emu6502] 10496 bytes 6502 EhBASIC [C]old/[W]arm ? Memory size ? 15615 Bytes free Enhanced BASIC 2.22 Ready The code running on the Hy-Tiny STM32F103 uses some more resources, in particular because now the interpreter context grabs 16 KB RAM for emulation:
Tiny Basic with room to spare – Dec 2, 2015 – One of the first tricks we teach a microcontroller (any computer really), is to raise its level of abstraction, by programming it in a “higher level language”. All computers are really awkward at birth: they only understand machine code, i.e. streams of bytes & numbers. Nobody does that anymore, there just wouldn’t be enough hours in a day to get anything done. Instead, we use tools like gcc and the Arduino IDE.
Developing in JavaScript for STM32 – Nov 29, 2015 – Last in this little series is another language: JavaScript. There is a mini-implementation of JavaScript called Espruino which can operate in even more cramped environments than Lua (and MicroPython, another language environment for the embedded world). Espruino runs on boards created via crowdfunding - the latest being the Espruino Pico. This is an absolutely tiny USB-stick like board, with a fairly powerful STM32F401 µC: But Espruino is also the name of the JavaScript environment itself, which is fully open source and embraces many other µCs, including the STM32F103 on the ARMinARM.
Developing in Lua for STM32 – Nov 28, 2015 – Lua is a very interesting small programming language, in the same way as Perl, Python, Ruby, and Tcl are - i.e. a dynamically-typed “scripting language”. Here’s the blurb: Lua combines simple procedural syntax with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection, making it ideal for configuration, scripting, and rapid prototyping.
Developing in C/C++ for STM32 – Nov 27, 2015 – Let’s now use the ARMinARM setup to try out a few of the included example programs. CMSIS The CMSIS library is supplied by STM, as ARM partner and µC manufacturer: $ cd arminarm/src/CMSIS_StdPeriph/examples/leds/ $ make mkdir -p build/src/ arm-none-eabi-gcc -c -O0 -g -Wall -I. -mcpu=cortex-m3 -mthumb [...] [...] $ arminarm -f build/leds.bin flashing build/leds.bin using stm32flash [...] Wrote and verified address 0x08005a64 (100.00%) Done. Resetting device... done. That’s it, the red LED should now be flashing (occasionally, you may have to reset the STM32F103 chip before it lets you flash new code onto it, using: “arminarm -r”).
A plethora of tools on the Pi – Nov 26, 2015 – The ARMinARM code is available on GitHub, and is a major convenience for this particular approach. Just get a reasonably fresh install of Raspbian running and you should be all set to install lots of tools, by following that README on GitHub. The “setup” tool does all the hard work, and not only does it install all sorts of software, it also contains the logic to update to newer versions over time:
ARMinARM can set you free! – Nov 25, 2015 – Software development for ARM µCs can be done in many ways. There is the Arduino IDE, and the Arduino-STM32 project specifically for STM32 microcontrollers, but there are more ways to skin this cat. One part of the work needed to get there, is to get the proper toolchain installed. Another piece of the puzzle is how to hook up the chip for development. The ARMinARM board by OnAndOffables deals with both.
The HY-Tiny can also act as BMP – Nov 20, 2015 – As last example in this “let’s make an ARM programmer” series, the HY-TinySTM103T: It’s a great little STM32 board with a nice set of features: 128 KB flash, 20 KB RAM, the usual mix of peripheral interfaces, and a little programming + debugging header at the bottom. We’re going to turn the one below (on the right) into a Black Magic Probe: … which can then be used to program and develop code on the one on the left!
From eBay "C8" µC to BMP tool – Nov 19, 2015 – Next in line in the “let’s create an ARM programming tool” series is this little board: It’s basically a breakout for the “STM32F103C8T6” chip (yes, it does take getting used to). That’s 64 KB of flash and 20 KB of RAM memory - (just) enough to run the BMP software. Here’s a little PCB for it (also off to a prototype run at the time of this writing): This board goes on top.
Use any STM Nucleo as programmer – Nov 18, 2015 – The Nucleo boards by STMicroelectronics cover a fascinating range of STM µC’s, and are provided for non-commercial use at very low cost. It’s a great way to get started, because they include a built-in “ST-Link V2.1” programmer: Actually, the programmer is the only part we’re interested in here. That’s why any Nucleo board will do here. You could saw the bottom part off (can’t break it easily, unfortunately). The first thing to do is remove those two jumpers.

(see the Archive for older entries)