JeeH 5.3.0
March 9, 2024
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. -
There is an example of building and running code in RAM, see
examples/f439n144/
. This may come in handy to avoid wearing out flash memory, but more importantly it loads faster which can speed up running many tests in succession. -
A new
logf()
function has been added, with printf-style formatting args, which sends its output to the ITM. This output only appears when a debugger has been set up to capture it. The output goes through a second virtual USB communication channel, at the rate of 1.5 .. 2 Mbps. This speed matters because ITM is a polled mechanism, i.e. thelogf
function can take some time to complete. Thelogf
function is useful for drivers and tasks, which cannot use aprintf
based on DMA-UART (as it relies onSys::call
).
This release also made me aware of some of JeeH’s current shortcomings:
- The core is too large, even a simple LED blinker will pull in the standard
printf
code (to be able to generate some post-mortem info on a hard-fault). - JeeH assumes that everything will be based on multi-threading, but with the new async task model, async-/task-only designs may become just as useful.
- Tests are too brittle: most of the output includes timing details with millisecond resolution, and this tends to change (and break tests) as the implementation evolves.
- The boundary between core functionality and platform-specific implementation code is fuzzy. It’s all-ARM and all-STM32 so far, yet the source code is split somewhat arbitrarily.
- Perhaps most importantly: it’s not easy enough to run tests and catch
regressions. Right now, a few fairly simple tests are broken due to changes
to
Sys::call
and threads.
Where to go from here? I’m not sure yet: perhaps a major “spring-cleaning” step is needed …
Onwards!