In the last episode, I advocated a little bit for Forth on microcontrollers being a still-viable development platform, not just for industry where it’s usually seen these days, but also for hackers. I maybe even tricked you into buying a couple pieces of cheap hardware. This time around, we’re going to get the Forth system set up on that hardware, and run the compulsory “hello world” and LED blinky. But then we’ll also take a dip into one of the features that make Forth very neat on microcontrollers: easy multitasking.

To work!

Hardware

Mecrisp-Stellaris Forth runs on a great number of ARM microcontrollers, but I’ll focus here on the STM32F103 chips that are available for incredibly little money in the form of a generic copy of the Maple Mini, often called a “STM32F103 Minimum System Board” or “Blue Pill” because of the form-factor, and the fact that there used to be red ones for sale. The microcontroller on board can run at 72 MHz, has 20 kB of RAM and either 64 or 128 kB of flash. It has plenty of pins, the digital-only ones are 5 V tolerant, and it has all the usual microcontroller peripherals. It’s not the most power-efficient, and it doesn’t have a floating-point unit or a DAC, but it’s a rugged old design that’s available for much less money than it should be.

Similar wonders of mass production work for the programmer that you’ll need to initially flash the chip. Any of the clones of the ST-Link v2 will work just fine. (Ironically enough, the hardware inside the programmer is almost identical to the target.) Finally, since Forth runs as in interactive shell, you’re going to need a serial connection to the STM32 board. That probably means a USB/serial adapter.

This whole setup isn’t going to cost much more than a fast food meal, and the programmer and USB/serial adapter are things that you’ll want to have in your kit anyway, if you don’t already.

You can power the board directly through the various 3.3 and GND pins scattered around the board, or through the micro USB port or the 5V pins on the target board. The latter two options pass through a 3.3 V regulator before joining up with the 3.3 pins. All of the pins are interconnected, so it’s best if you only use one power supply at a time.

Firmware: The Forth System

Go get the super-special Hackaday-edition Mecrisp Forth package from GitHub. Included in the “ROMs” directory is a Forth system that’ll work for the demos here. I’ve loaded in a decent base from [jcw]’s excellent Embello Forth libraries as well, providing things like easy GPIO configuration, delay functions, and so on. There are many more libraries available, and we’ll look into them next time when we need them.

The coolest thing about using a Forth system is that very little support software is needed at all — the Forth interpreter compiles its own code, and you interact with it over the serial terminal. Everything happens inside the microcontroller. The one hurdle, then, is getting Forth onto the chip. In the old days, this used to be done by toggling in the bytes manually, and Forth is actually small enough that literally bootstrapping it this way is possible. But you already bought that chip programmer, right?

[Texane]’s ST utilities are the easiest way to get Forth onto your chip. Download them from GitHub, and build it yourself or try your luck with your distro’s package manager. (Windows folks, you’re not left out either. Although that binary hasn’t seen updates in a while, it’ll do.)

Connect up the programming wires in the obvious fashion, and issue the magic commands st-flash erase and st-flash write mecrisp-stellaris-hackaday-edition.bin 0x8000000 . In five seconds, you’ll be ready to rumble.

GND — GND

SWCLK — CLK

SWSIO — DIO

Having to buy a programmer is a hassle if you don’t have one, but it will make the rest of your life easier, and getting one is as simple as clicking “pay” and waiting. Our own [Al Williams] (no relation) has a recent article on using the same software for debugging C or Arduino code with GDB, so it’s worth your time to set this up.

Software

Put the programmer away for now and connect to the STM32 over serial; the default baud rate should be 115,200. If you haven’t unplugged power yet, you might need to hit the reset button on the STM32 board. If all went well, you’ll be greeted by a familiar skull-and-cross-wrenches. Mecrisp is expecting a linefeed at the end of lines, so if you’re sending LF+CR, you’ll be effectively hitting return twice.

A9 TX — Serial RX

A10 RX — Serial TX

GND — GND

[jcw]’s folie is a nice, multi-platform serial terminal emulator for this application. What it does that your normal terminal program doesn’t is allow you to re-enter a command line with the up-arrow, which makes fixing mistakes much, much easier than re-typing a long command. It also automatically includes other files, which I made extensive use of in building the binary for this article. You don’t need to run folie , but I bet you’ll like it.

Hello World

Now it’s “Hello World” time. If you’re new to Forth, here comes an extremely selective introduction. Type 2 2 + and hit enter. It says ok. . That’s reassuring, right? Now type . (read “dot”) and it will print out the not-surprising result. Dot is the first of a few global Forth shorthands that you’ll want to internalize. Most commands with a dot print out their results immediately. .s (dot-ess) prints out the stack contents, for instance. Two more idioms that we’ll see a lot of are @ for getting a variable or reading an input and ! for setting a variable or output. Read these as “get” and “set” in your head when scanning Forth code.

Next, let’s see how to write a function. : starts a function definition and ; ends it. So : four 2 2 + ; defines a function that adds two and two together. (And compiles it in real time!) You can then turn around and call this function immediately. four .s will show you that our function has left the sum of two and two on the stack. In this sense, functions in Forth aren’t really functions. They don’t take explicit arguments or return explicit values. They just operate on whatever data is on the stack, and leave the results there too. That’s why Forth functions are called “words”. I’ll be sticking to this convention from now on.

Here, finally, is “Hello World”: : hw ." Hello, World!" cr ;" Strings are a little strange in Forth, largely because of the way the language is parsed — the compiler reads up to a space and then executes what it has found, so there has to be a space between the print-a-string command ( ." ) and the first character that you want to print. The print command scans forward until it finds a closing " , though, so you don’t need an extra space there. cr sends a carriage return. Type hw at the prompt. Hello, World!

Blinking LEDs

Even though serial text input and output is so easy in Forth, blinking an LED is the traditional “hello world” of microcontrollers, so it’s time for some GPIO. Because the system is already configured for this particular microcontroller board, turning an LED on is as easy as typing led.on at the prompt. Want to turn it off? led.off . Manual blinking will get old pretty quickly, though, so let’s write a blink word. : blink led.on 100 ms led.off 200 ms ; will do the trick. Try blink blink blink . See my blink demo code for elaboration. (More on ms in a few thousand milliseconds.)

The details of the GPIO initialization are hidden in core/Hackaday/LED.fs and in Embello’s stm32f1/io.fs respectively. Digging through, you’ll see the standard initialization procedure: the particular pin is set as output by flipping some bits in the STM32’s peripheral control registers. [jcw] has defined a bunch of these, making setting a pin as output, with the push-pull driver, as easy as PC13 OMODE-PP io-mode! . (Remember the “!” means set the value in a variable or register.)

To configure pin PA7 for ADC input: PA7 IMODE-ADC io-mode! . Testing buttons, using the built-in pullup or pulldown resistors: PA3 IMODE-PULL io-mode! and then set the output to pull up or down using true PA3 io! or PA3 ios! . You’ll then be able to read the button state with PA3 io@ (“io get”) later on.

GPIO on the STM32 chips is very flexible, and if you want to get deep into the configuration options in the datasheet, you can set all of this fairly easily using [jcw]’s io.fs code. For instance, io.all prints all of the GPIO registers and their values, which is a great help for interactive debugging. That said, there’s some room here for a more user-friendly hardware-abstraction layer, if you want to contribute one.

Multitasking on the Quick

So now we’ve got a blinking LED and serial-port printing “Hello World”. Not a bad start, and both of these make good use of Forth’s interactivity: the LED only lights up when you type blink . One of the chief virtues of Forth, for me, is the ease of going between interactive testing of words like this, and then deploying the functionality in a working system. One reason is that almost all Forths support simple cooperative multitasking. Here’s what I mean.

First, let’s loop our blink function so that we don’t have to type so much. : bb begin blink again ; creates a function, bb for “bad blink”, that will run forever. The problem with “run forever” in Forth is that you never get back to the interpreter’s command line without physically pressing the reset button, and then everything you were working on in RAM is lost.

Instead, let’s blink in a loop with a way out. : gb begin blink key? until ; creates a function that will run our blink command until there’s some input from the keyboard — the return key is pressed. This particular looping construct is very useful for testing out functions that you’d like to run continuously, without hanging the system. Keep it in mind.

Once we’ve tweaked our blink function to run just the way we want it, let’s create a background task so it can blink unattended.

task: blinktask : blink& blinktask activate begin blink again ; multitask blink&

Briefly, the task: word creates some memory space for our blinking background task that we’re calling blinktask . The function blink& does the work in the background. blink& starts off by declaring that it will use the blinktask task context, and that it should start off running. Then it goes into an endless blinking loop from which it never leaves. multitask turns multitasking on, and blink& executes our task. Run it, and the LED blinks while you can still interact with the console. Sweet. Type tasks and you’ll see that there are two active: one is our blinker and the other is the interactive interpreter.

But how does the blink task know when to yield to other simultaneous processes? In Forth, the word pause yields from the current context and moves on to the next, round-robin multitasking. The ms function, among others, contains a pause command, so what looks like a blocking delay in a single-task setup ends up playing fantastically well with your other tasks.

The nice thing about cooperative multitasking is that you control exactly when there’s going to be a context switch, which can help eliminate glitches that you’ll find in preemptive systems. The downside is that you’re responsible for remembering to pause your functions now and then, and you have to verify the timing yourself. Of course, this is a microcontroller, and you have the ARM’s quite rich internal interrupt controller to play with as well.

The real point of multitasking on micros in Forth is that it makes a great workflow for writing, testing, and deploying little daemons: functions that want to be “always on”. First, write the function that does the action once. Second, test it in a loop with an escape hatch. Third, once it’s working, remove the escape and make a background task for it. You can then turn it on and off using idle and wake , even from within other tasks. See Mecrisp’s multitask.txt, the source, for more details.

What’s Next?

So far, we’ve set up Mecrisp-Stellaris, with additional libraries from Jeelabs’ Embello Forth framework, and run some quick demos. If this has piqued your interest, I’ll take you on a walkthrough of building some real software next time. There’s a lot more to say about the way that Mecrisp handles the nuances of flash versus RAM, inputs and outputs, and the practice of interactive development. Some of the really freaky aspects of working in Forth will raise their funny-shaped heads, and we’ll learn to love them anyway.