Live data from Hacker News

Introducing multitasking to Arduino

blog.arduino.cc

31–40 of 88 posts

Re: Introducing multitasking to Arduino

#31
post #25

We've done quite a bit of experimentation with adding preemptive multitasking support to non-hard real time software running on MCUs at my current company. After a lot of head banging and dead ends, I've come to the conclusion personally that the embedded community could really use an implementation of the POSIX threading APIs or some meaningful subset thereof for various platforms. They're already standardized, well…

This is the direction a lot of RTOSs go, for example Zephyr (https://docs.zephyrproject.org/3.0.0/guides/portability/posi...) and FreeRTOS (https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_POSIX/i...).

Re: Introducing multitasking to Arduino

#32

A couple years ago, I managed a summer/afterschool program that introduced thousands of kids (age 8-18) to the Arduino. When we would set up a software abstraction to simplify multitasking (something that came up often with more advanced students), we set up something like this: int time = 0; int max_period = 10000; void loop() { if (time % 100 == 0) { everyTenthSecond(); } if (time % 1000 == 0) { everySecond(); } //…

I wonder if it's possible to just interleave statements from k different (loop) functions? Then it would seem mostly equivalent to an arduino at 1/k Clock speed. I think it's not possible to interleave instructions per se (because of registers?), but a compiler should be able to figure out the correct instructions of statement interleaving. This should eliminate problems with blocking.

Anyone know if a barrel-processor microcontroller exists? Propeller is sort of that way at least regarding main memory access.

Re: Introducing multitasking to Arduino

#33

Earlier quoted context omitted.

That is spiritually what their Scheduler library is doing, as mentioned in the article. Which works for a lot of things just fine until one task begins to overrun its time slice or just hangs. And then you're looking into preemption. But if you're overruning an AVR micro maybe it's time to take the training wheels off and move up to a larger system.

> move up to a larger system I'll take this one step further and suggest that beginners not start with the AVR, but instead with a Blue/Black pill (STM32) or ESP32. Leave the AVR for the more advanced people who are trying to squeeze every penny out of a project (even there, in many cases STM32 will cost less!!!). I visit the arduino.cc forums at least once every day and the things that beginners want to do these day…

I hear ya, I think we're just in a different era now. Users can wrap their head around a precooked framework that's ready to go and only needs a few API calls to make something happen. Beyond that? That's homework and homework sucks.

FreeRTOS really isn't that large of a leap forward, in fact when it's done right on your target platform it's just a few API calls as well. But it means wrapping your head around a lot of detailed concepts (stack size? semaphores?) when all you want to do is light up that string of RGB LEDs.

Re: Introducing multitasking to Arduino

#34

Earlier quoted context omitted.

That is spiritually what their Scheduler library is doing, as mentioned in the article. Which works for a lot of things just fine until one task begins to overrun its time slice or just hangs. And then you're looking into preemption. But if you're overruning an AVR micro maybe it's time to take the training wheels off and move up to a larger system.

> move up to a larger system I'll take this one step further and suggest that beginners not start with the AVR, but instead with a Blue/Black pill (STM32) or ESP32. Leave the AVR for the more advanced people who are trying to squeeze every penny out of a project (even there, in many cases STM32 will cost less!!!). I visit the arduino.cc forums at least once every day and the things that beginners want to do these day…

It's funny - I stepped away from electronics when I started college and in the first few years out of it just due to not having enough free time. About a 10 year period.

I come back and now AVR is old and slow and ARM is hot stuff. All it took was the tooling becoming nearly free. No more $500 ISP programmers, just USB DFU boot.

Re: Introducing multitasking to Arduino

#35

Earlier quoted context omitted.

That is spiritually what their Scheduler library is doing, as mentioned in the article. Which works for a lot of things just fine until one task begins to overrun its time slice or just hangs. And then you're looking into preemption. But if you're overruning an AVR micro maybe it's time to take the training wheels off and move up to a larger system.

> move up to a larger system I'll take this one step further and suggest that beginners not start with the AVR, but instead with a Blue/Black pill (STM32) or ESP32. Leave the AVR for the more advanced people who are trying to squeeze every penny out of a project (even there, in many cases STM32 will cost less!!!). I visit the arduino.cc forums at least once every day and the things that beginners want to do these day…

I agree- I think just about everybody should start with an ESP32 instead of an Arduino. I still use the Arduino API when programming the ESP32 (due to the large amount of compatible drivers) but I've also installed FreeRTOS and ported zork. I am embarassed to say I also got C++ STL working on an AVR with 8k of ram- enough to allocate a std::vector of length 2.

Re: Introducing multitasking to Arduino

#36

I see an opening for a very good set of tutorials on how to avoid all the pitfalls. [edit] - Actually... they have some good points, I just worry about someone thinking they can just "sprinkle threading" into their code, and failing to understand that in doing so they change the laws of physics of the code.

I find that Rust-like rules (&T across threads and &mut T within a thread, restricting cross-thread mutation to &Mutex and &AtomicT, global variables are treated as shared) are the best approach I've seen so far to general multithreading (as opposed to structured subsets like message passing or structured concurrency, which I haven't explored as much). However I'm unsure if mutexes are incompatible or unnecessary with the majority of single-core Arduinos with cooperative multitasking, and treating global data as shared is a pain on embedded and binding them to a specific thread is not a problem Rust has solved yet (you'll have to find your own solution).

Re: Introducing multitasking to Arduino

#37

Nice, but pointless addition to an old processor. ESP32's are cheap and readily accessible and they come with FreeRTOS running already. If I absolutely need to multitask on a Mega328 Arduino, I use the protothreads library. But really, for anything heavy, I'll turn to an ESP32 or an STM32. Use the right tool for the job!

In 2022 Arduino has several baords, many of which are NOT using atmega 328. Some of them have multi-core Arm chips, some of them have risc-v (not sure if they have any of those as multi-core though). There are already people running FreeRTOS on those. Not sure why you would dismiss multitasking on those as "useless".

Even on an AVR, you can implement lightweight cooperative scheduling with low resource consumption. That gives you many of the benefits of an RTOS with less risk of creating heisenbugs. Arduino should have broken free of its main-loop architecture long ago.

Re: Introducing multitasking to Arduino

#38

A couple years ago, I managed a summer/afterschool program that introduced thousands of kids (age 8-18) to the Arduino. When we would set up a software abstraction to simplify multitasking (something that came up often with more advanced students), we set up something like this: int time = 0; int max_period = 10000; void loop() { if (time % 100 == 0) { everyTenthSecond(); } if (time % 1000 == 0) { everySecond(); } //…

http://www.calgaryfieros.com/OSGdocs/ECM-hacking.html

The GM engineers used a similar approach:

> The ECM hardware generates a periodic interrupt at 160 Hz. (Where have we seen that number before?) The entire ECM program operates off of this one interrupt. Except for some initialization code, there is no non-interrupt level code. In fact, the interrupt service routine never returns, it simply cleans the return address off the stack and waits for the next interrupt. There are no other interrupts in the ECM. This means that fully autonomous hardware generates all the high speed signals like the fuel injector and ignition pulses.

> At each tick of the 160 Hz, various tasks are performed. Some are done every tick. Others only on just odd or just even ticks. There are also 16 tasks, one of which is performed each tick. Every tenth of a second, all 16 tasks will have been completed. In general, this means that the ECM cannot adjust engine performance faster than 10 times a second. Perhaps this explains the engine surging at low rpm that many list members have complained about.

Re: Introducing multitasking to Arduino

#40

Earlier quoted context omitted.

> move up to a larger system I'll take this one step further and suggest that beginners not start with the AVR, but instead with a Blue/Black pill (STM32) or ESP32. Leave the AVR for the more advanced people who are trying to squeeze every penny out of a project (even there, in many cases STM32 will cost less!!!). I visit the arduino.cc forums at least once every day and the things that beginners want to do these day…

It's funny - I stepped away from electronics when I started college and in the first few years out of it just due to not having enough free time. About a 10 year period. I come back and now AVR is old and slow and ARM is hot stuff. All it took was the tooling becoming nearly free. No more $500 ISP programmers, just USB DFU boot.

yea, usb dfu, better tooling and the price is nearly interchangeable. heck, small PDIPs are sometimes more expensive and less stocked
Post reply on HN