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.