JeeH supports a limited form of multitasking. There is only a single stack: there are no threads to suspend or resume, but also no need to allocate separate stacks to each one. This single stack expands downwards with the rest of unused RAM available for heap allocation. Just as in any single-tasking bare-metal application.
...Musings
It's been a while
Goodbye threads, hello workers
The big picture in JeeH is still not right: I don’t like the way device drivers
run in an exception-centric “handler” mode, whereas the rest of the application
uses “thread” mode. This distinction was needed to provide atomic guards around
certain parts of JeeH’s core data structures. This also affects the app-supplied
lowestPower
and resumePower
functions, used to enter sleep modes “when there
is no work”. It’s a bit odd that we need to be in a special mode when …
idling!
JeeH 6.1.0
JeeH version 6.1.0 release notes and highlights:
This is a minor release. I’m pushing this release out to prepare for some new ideas - mostly aimed at reducing overhead and complexity, and at improving JeeH’s low-power capabilities.
The current low-power design lets JeeH decide when to enter a low-power mode,
based on jeeh::lowestPower
and jeeh::resumePower
functions which can be
tweaked for a specific scenario. One problem is that these two functions have to
run in “handler” mode, i.e. as exceptions, which has very specific “rules of
engagement”. Another more pressing problem is that this code is simply … not
working correctly in all cases!
JeeH 6.0.0
JeeH version 6.0.0 release notes and highlights:
This is a major new release of JeeH. A lot of things have changed:
-
Now you see them, now you don’t: tasks are gone again. The routing of task messages was too complex. Threads are unchanged. Messages can still be sent to threads and to device drivers.
-
Instead of waiting for messages coming back as reply, the sender can now set up a callback method, which is called when the reply is received. For this to work, a thread needs to have
...while (true) sys::recv();
as its main loop. There is a (template) function to store a callback into a message:
Four ways to SPI
One of the problems I want to address in JeeH, is how to best interface with peripherals: built-in as well as connected via a common bus, e.g. I2C or SPI. There are two sides to this: talking to built-in hardware via device registers, and talking through built-in hardware to a connected module / chip.
Hardware register access #
Talking to the built-in hardware is a matter of reading and writing the
hardware registers at specific addresses. This is already solved in JeeH with
the use of IoReg<...>
definitions. To configure the “B” port of the GPIO
hardware in an STM32 for example, JeeH defines a GPIOB
object (a constant type
really) which can be referenced as an array. Here’s how to set its pin 8 high:
To buffer or not to buffer
The DMA-based UART driver in JeeH is an interesting example of the interaction between hardware, memory use, and blocking behaviour.
Reading data #
In JeeH, the way to read bytes from the UART is to send a message to its device
driver, and wait for its reply. The mTag
field is 'R'
, with the mLen
and
mPtr
field starting off as zero. The driver uses a small ring buffer
internally, which is filled in via DMA as bytes arrive. The CPU is not involved.
The next task is Tasks
As mentioned in my previous Threads vs Async I/O musings, threads are no longer the main concurrency mechanism I’m after, tasks are. Threads are still present in JeeH (and they actually work), but I’m not so keen on having to allocate stacks for each thread, nor on deciding up front how large they need to be.
So what is a task? #
Tasks are a bit different. I’m using the same sys::send
and sys::recv
mechanism for them as threads and device drivers, but they run as part of the
thread which created them. Sending a message to a task behaves as if the
message is sent to its owning thread and then forwarded to that specific task.
JeeH 5.4.0
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.
...
Spring cleaning
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.