JeeH 5.3.0

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. the logf function can take some time to complete. The logf function is useful for drivers and tasks, which cannot use a printf based on DMA-UART (as it relies on Sys::call).

This release also made me aware of some of JeeH’s current shortcomings:

1. 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).
2. 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.
3. 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.
4. 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.
5. 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!