JeeH version 5.4.0 release notes and highlights:

This is mostly to consolidate what there is, to prepare for a new v6 series of releases (the reason is described in this post - in short: I want to redo the tasks-vs-threads design and the test automation).

Changes in v5.4.0:

• More work on a RAM-based test runner, using openocd to upload the code.

• Explore more ways to send test output through ITM/SWO, which avoids the need to dedicate a UART to this. It relies on PB3 being connected to the ST-Link, which is the case on most Nucleo and Discovery boards from STM.

Looks like it’s that time of year again: I’m ripping apart what I have in JeeH 5.3 and reconstructing it in a different way. Perhaps it’s just madness, but I have two reasons to do this: 1) the task/thread design is too messy and 2) the way I can add and run tests is too tedious.

Tasks vs threads #

The first issue was unavoidable, once I figured out that tasks should not be an add-on to a threaded system, but exactly the other way around: threads are a special kind of task. Threads are tasks with their own stack, which can therefore be suspended and resumed. Tasks can’t: they either run to completion or they act on their “owning thread’s” behalf, i.e. they suspend their thread with them, if needed. This change puts tasks first, and optionally adds threads and context switching when needed. Then again, the reality is a bit more complex: there is in fact always one thread, the main() app code. It’s just that there’s no context switching involved until at least a second thread is created (with sys::fork(), as before). To support this, JeeH must be given an extra stack for interrupts, exceptions, and system calls, so that it can use ARM’s PSP + MSP dual stack approach (as before) and use PendSV for context switching.

JeeH version 5.3.0 release notes and highlights:

This release brings a number of major changes:

• Tasks have been renamed to Threads … because that’s what they really are.

• And with that out of the way: a new Task type has been added, to support asynchronous processing, i.e. an “async/await” style of doing work which does not run in a separate thread. This reduces overhead and avoids the need for a separate stack. A task in JeeH is a bit like a crossover between a thread and a driver: you can send it messages, but like a driver it runs to completion (i.e. until it returns) and is not allowed to block or suspend. For details, see the Threads vs Async I/O article.

It was a mistake in JeeH to call something a Task when it really is a Thread, so I’ve decided to rename them everywhere in the code and in the documentation. Threads are separate execution contexts, each with their own stack. And that’s what’s in JeeH right now.

Threads #

Threads are a bit of a double-edged sword: yes, you can nicely modularise different parts of an application this way, especially in the context of a µC where lots of external events and interrupts are going on. But on a single-CPU system (i.e. all but the most extensive ARM Cortex µCs) they still need to run one at a time. There is no real parallelism going on. The inconvenience of threads is that each one needs to have its own stack area, each sized to handle peak memory needs, even though most of it will not be used at the same time. It can be quite wasteful, especially on a RAM-constrained µC.

JeeH version 5.2.0 release notes and highlights:

This is the most extensive release so far, with new SDIO and Ethernet drivers. Everything is still highly experimental, but the main pieces of the multitasker puzzle are starting to fit together quite nicely. Using lightweight messages as the main vehicle for communication between tasks and drivers works really well and allows pacing the different pieces of an application.

The driver model helps decouple the different layers, as illustrated by the eth driver and net worker task: neither one needs knowledge of the other (their code can be included in either order). All the net worker needs is the id of the eth driver to communicate with it. Conversely, the eth driver has no knowledge whatsoever of the protocol stack implemented in net.

Musings ≠ weblog. The jeelabs.org site used to be my old weblog. For a fairly long time I posted there on a daily basis. Lots of topics I wanted to write about, as I discovered Arduino’s, the whole field of “physical computing”, and then went on to produce and sell JeeNodes, JeeLinks, JeePlugs, etc. It was great fun while it lasted, but at some point I ran out of fuel.