9 ms·

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 abstract

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(); } // ... time = (time + 1) % max_period; } This `loop` assumes functions are perfectly non-blocking, which obviously is not always true, but works well for 99% of actual use cases. If keeping accurate time is required, the student would compare `time` with the elapsed millisecond time since the last loop invocation, adjust accordingly, and check for any periodic functions that weren't executed in that period. It gets tedious quite fast. If I had to imagine a solution, it would be to simply have an easy way to enter parameters to the JS-equivalent of `setTimeout` and `setInterval`.

joezydeco 4y ago
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.
- jgerrish 4y ago
  Don't be too quick to dismiss the "training wheels" of AVR. While ARM and RISC-V may have beefier processors, and will probably be migrated to or adopted, AVR has a lot going for it. First, a common AVR board like the Arduino Uno has built-in peripherals like a temperature sensor. You can build something out of the box without buying external items. If your target market is cheap educational, that's key. Second, it offers basic microcontroller features like power management, external interrupts, serial and other stuff. It provides a terrific cheap platform to understand managing interrupts and concurrency safely in your language of choice. Which can be applied to the bigger boards. Finally, memory constraints require careful thinking through code. I'm not going to implement a full standard library on an Arduino AVR, so what do I bring with me?
- HeyLaughingBoy 4y ago
  > 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 :-)
  - joezydeco 4y ago
    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.
    - RealityVoid 4y ago
      Stack size is a thing on Arduino as well.
  - Teknoman117 4y ago
    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.
gnramires 4y ago
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.
- Teknoman117 4y ago
  Anyone know if a barrel-processor microcontroller exists? Propeller is sort of that way at least regarding main memory access.
  - seabird 4y ago
    Padauk makes them (or at least did), and calls them FPPAs. These are the same folks that brought you those infamous 3-cent-at-single-quantities OTP microcontrollers, so they're probably not for the faint of heart, but what you're asking for has been done.
    - retrac 4y ago
      Some of those 3 cent microcontrollers are actually barrel processors! They have multiple sets of registers (only two on the cheapest) and rotate through them with each clock. Useful for implementing an SPI or UART thread alongside the main task, for example. The SDCC open source C compiler targets some of those chips now, too.
- NavinF 4y ago
  You can do that, but it's not very useful in practice and really breaks down when you want to do something more compute intensive that needs all the registers/cache. Multicore MCUs like the ESP32 are pretty cheap ($2 1pc pricing) so if you really care about realtime performance it makes more sense it do realtime on one core and schedule slower work to be done on the other core.
_whiteCaps_ 4y ago
http://www.calgaryfieros.com/OSGdocs/ECM-hacking.html 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.
- primitivesuave 4y ago
  This is awesome, thank you (and to the other HN commenters) for providing so much valuable perspective as always.
jldugger 4y ago
This basically how all of arduino "works". It was quite shocking to see this after working on embedded systems in grad school that used interrupt driven microcontrollers for low power situations to see a while (true) in the core arduino main.c edit: but it makes sense from the perspective of a education and hobbyist needs to take the simplest option that could work
dandelany 4y ago
I’ve made some fun projects with Espruino - where you can literally use setTimeout/setInterval and it will even sleep the uC until it hits the the timeout :)
- petra 4y ago
  So it simply manages both multitasking and power management?
inamberclad 4y ago
Hell, I did that for a prototype product once. Combined it with a state machine and wrote the entire thing to be nonblocking. Worked great.
- primitivesuave 4y ago
  Really appreciate you sharing this - I used to downplay the real-world application of these kinds of methods ("if you were making a real product you'd have a priority queue and a scheduler and so on") so if I ever teach kids again I'll let them know that people out there build real things like this.

joezydeco 4y ago

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.

jgerrish 4y ago
Don't be too quick to dismiss the "training wheels" of AVR. While ARM and RISC-V may have beefier processors, and will probably be migrated to or adopted, AVR has a lot going for it. First, a common AVR board like the Arduino Uno has built-in peripherals like a temperature sensor. You can build something out of the box without buying external items. If your target market is cheap educational, that's key. Second, it offers basic microcontroller features like power management, external interrupts, serial and other stuff. It provides a terrific cheap platform to understand managing interrupts and concurrency safely in your language of choice. Which can be applied to the bigger boards. Finally, memory constraints require careful thinking through code. I'm not going to implement a full standard library on an Arduino AVR, so what do I bring with me?
HeyLaughingBoy 4y ago
> 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 :-)
- joezydeco 4y ago
  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.
  - RealityVoid 4y ago
    Stack size is a thing on Arduino as well.
- Teknoman117 4y ago
  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.

gnramires 4y ago

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.

Teknoman117 4y ago
Anyone know if a barrel-processor microcontroller exists? Propeller is sort of that way at least regarding main memory access.
- seabird 4y ago
  Padauk makes them (or at least did), and calls them FPPAs. These are the same folks that brought you those infamous 3-cent-at-single-quantities OTP microcontrollers, so they're probably not for the faint of heart, but what you're asking for has been done.
  - retrac 4y ago
    Some of those 3 cent microcontrollers are actually barrel processors! They have multiple sets of registers (only two on the cheapest) and rotate through them with each clock. Useful for implementing an SPI or UART thread alongside the main task, for example. The SDCC open source C compiler targets some of those chips now, too.
NavinF 4y ago
You can do that, but it's not very useful in practice and really breaks down when you want to do something more compute intensive that needs all the registers/cache. Multicore MCUs like the ESP32 are pretty cheap ($2 1pc pricing) so if you really care about realtime performance it makes more sense it do realtime on one core and schedule slower work to be done on the other core.

_whiteCaps_ 4y ago

http://www.calgaryfieros.com/OSGdocs/ECM-hacking.html 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.

primitivesuave 4y ago
This is awesome, thank you (and to the other HN commenters) for providing so much valuable perspective as always.

jldugger 4y ago

This basically how all of arduino "works". It was quite shocking to see this after working on embedded systems in grad school that used interrupt driven microcontrollers for low power situations to see a while (true) in the core arduino main.c edit: but it makes sense from the perspective of a education and hobbyist needs to take the simplest option that could work

dandelany 4y ago

I’ve made some fun projects with Espruino - where you can literally use setTimeout/setInterval and it will even sleep the uC until it hits the the timeout :)

petra 4y ago
So it simply manages both multitasking and power management?

inamberclad 4y ago

Hell, I did that for a prototype product once. Combined it with a state machine and wrote the entire thing to be nonblocking. Worked great.

primitivesuave 4y ago
Really appreciate you sharing this - I used to downplay the real-world application of these kinds of methods ("if you were making a real product you'd have a priority queue and a scheduler and so on") so if I ever teach kids again I'll let them know that people out there build real things like this.