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.

At some point, it might have been worth considering writing everything in C/C++, from the embedded µC to say a central Raspberry Pi, with server-side rendering of pages (as is still the model for PHP). But we’ve all seen the benefit of running something other than C on the server, and of course the browser world has been completely taken over by JavaScript. With rich “single-page applications” (SPA) taking over more and more of the user experience. And for good reason: we get astonishingly powerful and intuitive user interfaces (and eye-candy…).

It might seem that writing at least the server- and client-side using the same language is a good way forward. IOW: NodeJS on the server and JavaScript in the browser. And while JavaScript on a µC is definitely feasible, it’s not a convincing match in terms of performance and code size.

Meteor is one well-known example which tries to merge server- and client-side development, to the point that you can develop both sides as a single system, sharing code as much as possible.

There are some caveats with that approach: 1) developing in the same language on both sides ignores the fact that they deal with completely different problems (and that staying in the same context can actually be very confusing!), and 2) even NodeJS is a bit hefty for low-power Linux boxes such as Raspberry Pi or CHIP (it tends to fill up RAM when running for months on end).

So if JavaScript 1) can’t be avoided in the browser, 2) is not a great fit for low-power central always-on servers, and 3) doesn’t fit on low-end remote µC nodes, what’s the alternative?

My choices

Here’s the solution I’ve been moving towards for quite some time now:

1. Use Forth or C/C++ for remote embedded µCs
2. Use the Go language on the server side (it was actuallymade for that purpose)
3. Use JavaScript or a language which generates JavaScript in the browser

Both Forth and C/C++ fit easily, even on small µCs. They are both compiled code, so they don’t waste time running an interpreter. And they both go all the way down to the bare metal, so that full control of all the embedded hardware is always possible.

Go could be called “modern C/C++ for servers”: garbage collected, modern interface-based composition, and channels plus “goroutines” to tame multi-threading and asynchronous tasks. Without the race-condition risks that usually come with threads and interrupts. As bonus, it’s trivial toproduce stand-alone executables in Go for over a dozen platform / OS combinations.

And JavaScript… needs no explanation. Browsers dig JavaScript, period.

To borrow and re-purpose a phrase fromClojureScript somewhat:

• Forth and C/C++ scale downwards
• Go gets (parallel) work done
• JavaScript reaches

Which brings me to the main topic of this article: how to deal with all this, as a developer?

My setup

The answer is: with a bit of care, the entire development process can be streamlined to a very comfortable level. Here’s what it comes down to (a lot of this is personal preference, of course):

• Laptop - everything can be done with a single laptop (Win/Mac/Lin, your pick)
• Source code - all source code is tracked in git for total recall and tamper-proof storage
• Collaboration - use GitHub orGogs (self-hosted) for repositories and issue tracking
• Forth - source code in Git, µC interface using Folie and… look ma, no toolchain!
• C/C++ - the usual suspects: Arduino,STM32duino,libopencm3 - a plethora of choices
• Go - source code in Git, cross-compile to ARM with GOOS=linux GOARCH=arm go build
• JavaScript - probably via ClojureScript withReagent (i.e.React wrapper) andFigwheel

I very much prefer to work on Mac, although I’ve been using Linux (and Unix) longer than I can remember, and feel very much at home on its command line (GUIs are another story: too inconsistent and quirky for my tastes). Here’s the screen layout I use most often on my laptop:

For purely text-based work, I’m still considering using thei3 window manager, on a screen of its own in Linux. But as soon as browsers and other GUI tools are involved, the Mac has my vote.

There are two ways to run Linux on this same machine:

• Docker for Mac uses macOS’s newnative“Hypervisor” framework. It’s as close as you can get to running Linux code with macOS managing the machine and the GUI. There is no need to install a VM like VirtualBox, Parallels, or VMware - a fascinating trend!

• Running a Virtual Machine is the more traditional way to run macOS and Linux in parallel, with the ability to integrate a Linux GUI into the Mac’s. This leads to a more pure Linux setup.

In both cases, it’s easy to call into Linux using SSH and have it show up in a terminal window on the Mac side, as shown in the blue box above. Both can be configured to share areas of the underlying macOS file system, so you don’t have to copy stuff across - you can just “cd” to the right place. Source code can be edited on macOS and Linux will see the changes, and vice versa.

A virtual machine could also be used to run Windows (at the same time, if you have enough memory), but there’s little incentive for me to go there - other than to try out a Go application built for Windows, perhaps (using“GOOS=windows go build”).

Virtual machines have come a long way, at least with Parallels Desktop for Mac version 12. And it shows - on the USB side, for example: when plugging a USB device into the laptop, you can choose whether to connect it to macOS or to one of the running VMs. This now works so well that where FTDI caused infinite grief (in the form of kernel panics!) for many years, all of these issues go away when the device is tied to the Linux VM, making it do things the Mac (or rather: FTDI) never got right, like controlling both the DTR and the RTS pins over a serial USB link.

As a result, I can now launch Folie on Linux, while working on the Mac laptop, and all is well: Ctrl-C to reset the attached µC and “!u 6” to upload Mecrisp to a JeeNode Zero - \o/ - yeay!

Another aspect of Linux is that it can run qemu-user-static, which can launch an ARM-based executable on Intel hardware. This offers an astonishingly transparent form of emulation: once installed, Linux will automatically recognise the ARM file format and insert the Qemu layer.

Quite a convenient setup, all in all: macOS, Linux, Windows even, and the ability to run ARM executables, like the Linux build of Mecrisp Forth. All on one laptop, using a single file system.

Docker example

To give you an idea of what Docker can do, let’s create a “container” withqemu-user-static and Mecrisp for Linux (i.e. ARM), which will be launched every time we fire up the container:

$ cat Dockerfile
FROM ubuntu
RUN apt-get update
RUN apt-get install -y qemu-user-static
ADD mecrisp-stellaris-linux mecrisp
CMD "./mecrisp"
$

With that Dockerfile, and a copy of mecrisp-stellaris-linux in the current dir, we can do:

$ docker build .
Sending build context to Docker daemon 63.49 kB
Step 1/5 : FROM ubuntu
---> ebcd9d4fca80
Step 2/5 : RUN apt-get update
---> Running in 3c06495691ab
Get:1 http://archive.ubuntu.com/ubuntu xenial InRelease [247 kB]
[...etc...]
Step 3/5 : RUN apt-get install -y qemu-user-static
---> Running in e1651fff44b9
Reading package lists...
[...etc...]
The following NEW packages will be installed:
binfmt-support libpipeline1 qemu-user-static
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 7879 kB of archives.
After this operation, 86.1 MB of additional disk space will be used.
[...etc...]
Step 4/5 : ADD mecrisp-stellaris-linux mecrisp
---> 88249491f198
Removing intermediate container 2148b8a50044
Step 5/5 : CMD "./mecrisp"
---> Running in 5e75eef61d34
---> 11e4ed2299dd
Removing intermediate container 5e75eef61d34
Successfully built 11e4ed2299dd
$

Lets give it a friendlier name:

$ docker tag 11e4ed2299dd mecrisp

The result is a “container” image, which is Docker’s terminology for a snapshot of the state after the above process completes (i.e. a download plus apt-get to install qemu-user-static). Now that we have such an image, we can launch the Mecrisp setup almost like any other application:

$ time docker run -it --rm mecrisp
Mecrisp-Stellaris RA 2.3.6 for Linux by Matthias Koch

real    0m1.203s
user    0m0.015s
sys     0m0.013s

That’s really all it takes: just over a second to bring up a Ubuntu context (within the Mac!), launch Mecrisp (emulating the ARM code via Qemu), stop the whole process again (since I typed ctrl-d right away), and clean everything up. Should also work on Docker for Windows.

So now there’s a way to try out Forth code from the Mac command line - look ma, no hands!

There’s a new wireless radio driver in town for the JeeNode Zero and other µC boards running Mecrisp Forth. It’s calledRF73 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 currentrf73.fs code is still very young, and not quite ready for general use. Part of this is due to the fact that the RFM7x’s use a slightly different routing model: each unit has the ability to receive data on 6 specific addresses, and is meant to be used in a 1:6 mesh topology. What this means is that the RF12/69’s idea of node IDs and net groups is slightly different. It’s going to take a little more head scratching to map the RF73 to a reasonably generic model and API.

The RFM7x’s can receive packets up to at most 32 bytes, but they do have 3 buffers, so more packets can be in-transit as the driver works its way through the send and receive data. This is important because the maximum data rate of these modules is a whopping 2 Mb/sec: you can send and receive a lot of data with these, plenty for audio and text streams over 115,200 baud.

The flip side (yes, everything is a trade-off), is that the range of the RFM7x is only 5..10 meter, especially indoor and when there are walls involved. Fine for a room, not for an entire house.

Here is the setup which was used to develop this first iteration of the RF73 driver:

(these are older “v1” versions of the JeeNode Zero, each with an RFM70 mounted on them)

The Quad Serial shown above is a 4-port FTDI interface, with support for the DTR + RTS pins needed to reset and re-flash attached µC boards. A custom-made plug-in board converts the header pinouts to four standard 6-pin FTDI ports, as used by JeeNodes and many others.

Writing a wireless driver from scratch and debugging it can be a challenge: you have to figure out which side of the RF link is not working. Without aMixed-Domain Oscilloscope, it’s hard to tell what’s going on (even that high-end scope is not capable of capturing 2.4 GHz, by the way!).

There already was an older driver written in C++, with a test program for two LPC824-based boards, and they were happily exchanging test messages. In that context, with known valid packets flying around, the first coding task was simply a matter of picking up those messages.

After that, things went fairly smoothly, leading to a138-line driver written in Forth, which can send and receive individual 1..32-byte packets. Almost half of that code is for initialisation.

The RFM7x series has one very interesting feature: there’s an optional “auto-ack” mechanism, whereby the receiver immediately sends an ACK on proper reception, with the sender timing out and retrying a few times if it doesn’t see that ACK. Very much like the Easy Transmission mechanism implemented in software for the RF12 driver inJeeLib, but now all in hardware.

The performance with a 2 MB/s data rate and optional fast ACKs is quite impressive:

• sending a 10-byte packet without ACK takes some 300 µS
• sending that same packet and waiting for the ACK takes ≈ 500 µs

With ACKs, you get a reliable communication channel, since transmission errors lead to retries and much lower error rates. There will be a delay with retries, up to 60 ms with the maximum 4 ms timeout using 15 retries. Failures are still possible, of course - just considerably less likely.

The RFM7x modules are very similar to the nRF24L01 (and maybe even compatible on-air?). Both have been widely used in RF-based wireless audio headsets, for example.

So there you go: a new choice, for when you need more speed and can live with a lower range. And the JeeNode Zero already includes the proper footprint for these RFM7x’s on its PCB.

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?

This requires an extra µC on the “central” side to bridge between USB and RF, but it would add the ability to talk to one or more remote wireless nodes - interactively!

Note that such a central bridging node plays more or less the same role as an FTDI adapter, but using an RF-based packet link instead of the FTDI’s 6-wire hookup.

Here is a hacked-up central node based on theHyTiny board and some free-style soldering:

The above concoction is currently being used for development and testing, although a JeeNode Zero with FTDI would also work. Some bugs and puzzles still remain, but we’ll get there…

An RFM70 module is being used here, because its built-in auto-ack mechanism helps greatly to simplify initial development. The RF console will be ported to RFM69 once everything works.

There are some interesting uses for such an RF-based console driver in Mecrisp: perhaps most importantly, it enables remote configuration and debugging, especially in combination with the multitasker to keep both the interactive console and the application code running in parallel.

This RF link capability can also be used to upload new code or reload the on-board application.

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.

But recent experience with Folie points to a much more practical design, with one process per external interface instead of this single monolithic hub. The always-on role can easily be taken over by the MQTT message broker, i.e. Mosquitto - which is widely use in today’s IoT…hype?

The Mosquitto background task consumes very few resources and can be kept running 24 / 7, acting as central switchboard and message exchange. Great for a low-end Linux board.

Mosquitto 1.4.8 and later include two major new features: 1) WebSocket support and 2) a built-in web server for static files. These can offer aperfect mechanism for rich and responsive web applications, together withPaho for MQTT message streams andReact for the user interface.

The core JET system is trivial to set up: install Mosquitto from whatever package manager you use (recent versions are available via apt-get on Linux, or homebrew on Mac, for example).

Since MQTT is based on TCP/IP sockets, its clients can be located anywhere on the network.

You can configure SSL-secured connections where needed - it’s all well-documented and very easy to set up. And here is how to activate the built-in HTTP server with WebSocket support:

listener 9001
http_dir /var/www/mosquitto
protocol websockets

Mosquitto supports listening on multiple ports and can restrict access to MQTT’s “topic tree”. These features are useful to expose only a subset of all your messages to the outside world.

What about the rest of JET?

Well… that’s mostly a matter of launching instances of Folie for each hardware interface, plus additional tasks to perform functions such as logging, database storage, and rule automation.

Each of these can then publish its results to MQTT and subscribe to specific MQTT topics (or wildcard topics) to be notified of events as they occur. There you go: messaging in action!

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. As the name says, a Forth Live Explorer:

At some point, we’ll want to collect incoming data and to send out commands to specific nodes. This is a perfect task for MQTT - as always-on“message broker” between various processes:

Since MQTT is network based, it does not need to be running on the same machine as Folie.

But Folie is more than a front-end for Mecrisp Forth. It’s also able to send entire source files (and recursively expand further included files), it can upload new firmware to an STM32-based µC via its ROM boot loader, and it can connnect to a Telnet server such as ser2net oresp-link.

The question is: how to create a structure which supports gradual development and growth?

Because JET is not about installing a system, configuring it, and then just“letting it run”. What we need, is a design which lets us add features as the need arises - perhaps downloaded from the net, because somebody else had some neat idea, or else built ourselves as custom add-on.

Just like a city, JET should be able to grow organically, over a very long time, and evolve in ways which cannot be predicted up front: i.e. infra-structure which must be solid and stable.

In JET, MQTT is the only fixed point in the system (along with naming choices for its topics and the message format). Everything else can be changed and replaced over time in case anyone comes up with a clever new way of doing things. With a bit of topic-prefix planning, a single MQTT instance can in fact support multiple approaches running in parallel.

But Folie v2 isn’t quite usable as is: it’s based on direct interactive use (great for development) and not really meant to be used unattended, when some parts of our setup are becoming useful and solid enough to keep them running all the time (e.g. some wireless sensor nodes).

This is about to change. The next major revision of Folie will allow both production mode and development mode to be mixed (and switched) as needed, using a new pass-through mode:

Note that Folie will continue to fully support the original development style, i.e. as interactive console front end for Mecrisp Forth µC nodes, both directly attached and via RF. What’s new, is that Folie v3 now adds SSH to the mix (both as server and as client), due to some terrific recent work by Thorsten von Eicken, who also re-factored the original code to prepare for changes like these (while keeping the !send and !upload functionality fully intact).

Since MQTT can be configured to use SSL connections, this creates anetwork-savvy context for all JET and JeeNode Zero development, which supportsprivate and secure connections from a development machine, including source code uploads and remote re-flashing.

The intended use is for a small Linux board such as a Raspberry Pi, Odroid, or CHIP to run MQTT and one or more instances of Folie, each talking to their own µC via a USB interface. All development access then takes place from your own cosy development machine, with your favourite code editor, version control tools, and personal backups.

And yet it’s still fully adjustable - nothing prevents you from setting up everything on a single laptop, plugging the µC board into USB, and doing everything off-line, i.e. anywhere you like.