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. ...
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. ...
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. ...
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. ...
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. ...
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. ...
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. ...
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. ...
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). ...
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. ...