4 ms·

I have a couple of Arduino projects that do 5 or more simultaneous things. Temperature sensors busy with a conversion, A/D converters taking readings, timers ti

I have a couple of Arduino projects that do 5 or more simultaneous things. Temperature sensors busy with a conversion, A/D converters taking readings, timers ticking, serial ports being watched for characters and so on. You can speak of "hard realtime" but all of this stuff works just fine in a polled fashion, just get through your main loop quickly and don't block on anything. With nothing much to do the main loop cycles 5-10K times per second even on simple AVR328. And then you have readable, easily maintained code without gnarly interrupt handling, realtime threads and all that. Need microsecond level hard realtime performance? Then don't do that. Though my superficial reading is that you can partly escape from the Arduino environment to do that too, without having to give up all of it. Need microwatt level power consumption? Then definitely learn to program the bare metal. I haven't had to, yet. Here's one of my less complex Arduino projects but the only one finished to a "show it off" quality. Realtime? Too limited by the Arduino paradigm? You be the judge.. https://github.com/MarkusWandel/battery-tester https://github.com/MarkusWandel/battery-tester I have to say, to get practical use out of the Arduino, you have to unlearn the "delay" function. If you never block on the main loop, you can do anything.

bsder 5y ago
> You can speak of "hard realtime" but all of this stuff works just fine in a polled fashion Erm, hard real time quite often is purely polled. Interrupts introduce a lot of non-determinism that polling completely sidesteps.
- rcxdude 5y ago
  Really depends on your requirements. One important distinction is that hard-realtime doesn't necessarily mean low-latency or low-jitter. It just means that failing to meet a deadline is a failure of the whole system. You are right that absent other demands on the processor, polling can usually offer the lowest-latency, lowest-jitter response from a system.
rcxdude 5y ago
Yeah, you can usually get away with super-loops in Arduino (YMMV depending on the libraries you want to use and your latency requirements). It's conceptually simple but creates a lot of complexity in the code you're writing (you basically wind up writing ad-hoc schedulers for each piece of logic you write). For simple tasks (especially with relatively simple control flow), it can be good enough and the ease of writing it can make it the best approach. As the complexity of your system grows it becomes less and less readable and maintainable.

bsder 5y ago

> You can speak of "hard realtime" but all of this stuff works just fine in a polled fashion Erm, hard real time quite often is purely polled. Interrupts introduce a lot of non-determinism that polling completely sidesteps.

rcxdude 5y ago
Really depends on your requirements. One important distinction is that hard-realtime doesn't necessarily mean low-latency or low-jitter. It just means that failing to meet a deadline is a failure of the whole system. You are right that absent other demands on the processor, polling can usually offer the lowest-latency, lowest-jitter response from a system.

rcxdude 5y ago

Yeah, you can usually get away with super-loops in Arduino (YMMV depending on the libraries you want to use and your latency requirements). It's conceptually simple but creates a lot of complexity in the code you're writing (you basically wind up writing ad-hoc schedulers for each piece of logic you write). For simple tasks (especially with relatively simple control flow), it can be good enough and the ease of writing it can make it the best approach. As the complexity of your system grows it becomes less and less readable and maintainable.