OK, the title is a mouthful and sounds a lot like a boring conference paper. Hear me out.
Micro-controllers are the cheap and prolific computing device of the day. There’s the Arduino, ESP32, Blink, Feather, Micro:Bit, and so many more. While the Raspberry Pi is great, rarely is all of it capability needed and these micro-controllers at often 1/10th the cost.
One big difference with the micro-controller is that it’s a “do one thing” compute process. Or is it?
Thanks to timers and pseudo interrupts, the micro-controller can almost do multi-threading. The “almost” is because it’s up to the developer to do some extra work to make it possible.
Here is where a class I took in college – back in the dark ages of silicon – gets some new life.
Backstory: when I was at WPI, studying biomedical engineering and nearly flunking out, I decided I’d take a computer course. The only one available that semester was FORTRAN. (The C programming course was full.) The FORTRAN course was taught by the same professor who taught the Fire Systems program and one of his pet projects was the Fire Analysis Simulation software. So, he obviously taught the FORTRAN students how the simulator code worked.
In the old simulator program, they used an ordered list of objects which were just a timestamp and a keyword. The keyword represented what was to occur When the clock reached the timestamp.
This same model works amazingly well on today’s micro-controllers.
Rather than perform a delay() when a piece of code needs to pause, just add a node to the list with the future time the code should resume. Then return execution back to the main loop to allow something else to process.
It’s not perfect but it’s very efficient and does a pretty good job at simulating a real multi-threaded environment.
This thread dispatch model is unnecessary for very simple micro-controller projects but will be helpful for anything that has sensors, inputs, and outputs … basically every project.