21–30 of 88 posts
[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.
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(); } //…
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.
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 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.
I'm crappy at embedded development but isn't it pretty normal to handle "multitasking" with interrupts instead of using an event loop?
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 understood/used, and aren't that hard to implement on an MCU.
Of course, there would probably be some semantics that wouldn't make sense to or may not be possible to implement on MCUs, and there would be work required to support different cores, but these tradeoffs seem better to me than reinventing the wheel and probably needing to make the same tradeoffs at some point down the line with a ground up new API.
For Arduino, exposing POSIX APIs wouldn't be very user-friendly. But wrapping something more user-friendly around them seems like a maintainable and extensible path for the project and community.
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(); } //…
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.
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 days is far more advanced than what they would have attempted even 10 years ago. It gets very difficult trying to explain how to do things on an AVR that would be much easier on a processor with far more resources. String vs char* is one of those.
Hell, I don't know why we're even telling beginners to code in C++ in 2022.
My downvoted comment that boils down to "just use an ESP32 and get FreeRTOS along for the ride" is in this vein. The reality is that beginners have a lot of trouble wrapping their heads around writing nonblocking code using timers and something like a FreeRTOS thread is a much simpler concept to explain.
Rant over :-)
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…
source: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...
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…
Threads are already supported by esp-idf on esp32 source: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...