> using threads for embedded development

Reminds me of something -

I used to work for an embedded shop where they used exception-like error handling that was implemented through some basic C macro fuckery. It made the code markedly more succinct, had next to zero overhead and it was just a fantastic piece of work in general. 20 years later and I still remember it fondly.

You can think of it as the reactor pattern. You only have one physical CPU so all you are doing is churning through callback-based event handlers.

The callbacks in this case might be the literal interrupt handlers (in which case your dispatcher "loop" is actually the hardware). Or else you make your interrupt write a little bit of state that then gets dispatched by your actual event loop.

Either way, you write responsive software by doing everything in short-running callbacks.

I find it amusing that (some) sophisticated GUI and server framework for big computers re-invent this.

One important difference is that in the MCU world interrupt handlers need to be really short and fast, because often various classes of interrupts are blocked from occurring while an interrupt handler is running. A common pattern is for the interrupt handler to just set some bits to say “this occurred” and return. The bits are then checked and handled in the main loop.

> doing everything in short-running callbacks

We call them "interrupt handlers." :)

It's amusing how you and alexhutcheson both corrected me in opposite directions.

For reasons Alex explains, interrupt handlers have to be really minimal. So you often use them to set state that makes the main loop branch off into the "real" handler.

But even then, you often don't want to wait a long time in that handler either. That too becomes a short-running event handler (though not necessarily a callback). Just not as extremely short running as it would have to be if did it in the interrupt handler.

> My guess is following: some people will put in doubt the rationale of using threads for embedded development as such.

I'm reading through the comments here and it is difficult to even address some of them, because there is apparent confusion as to the meaning of the word "thread".

In embedded you often do not need or even want threads. What you need is a way to deal with events (mostly interrupts) without losing your sanity. A reasonable approach is to have a state machine that reacts to events, and all interrupt handlers only inject events into the state machine. The state machine is the only "thread" that runs: the CPU runs it until its done processing the current event, and then goes to sleep. Interrupt handlers do as little as possible, basically just drop events into a queue (or even a single slot) for the state machine to process.

This works fine for simple state machines, but quickly gets tedious and complex, especially if you have tasks that involve several sequential events (initialize peripherals, setup ADC, read from ADC, calculate parameters, setup an output device based on parameters computed from ADC reads).

A very good way to hide the state machine is to use CSP (you might have seen it in the Go language or in Clojure as core.async). This lets you write the same thing using certain primitives (channels, blocking and non-blocking reads and writes). Note that until this point this has nothing to do with threads! Clojure's core.async works just as well in Clojurescript, which compiles down to JavaScript and runs in a single thread!