3 ms·
You can implement hard real-time scheduling using polling instead of interrupts, which is usually faster anyway. It just changes how you measure your tolerance,
by qppo 6y ago
You can implement hard real-time scheduling using polling instead of interrupts, which is usually faster anyway. It just changes how you measure your tolerance, since nothing is instantaneous, ever.
- ChuckNorris89 6y agoThis! Automotive hard real time is polling based.
- qppo 6y agoI think most things are trending that direction, even in soft/non real-time. How fast can an interrupt respond these days anyway, a dozen microseconds?
- ianhowson 6y agoNanoseconds if you can respond inside the interrupt handler ('top half' in Linux.) Microseconds to milliseconds with significant variability if you need to be scheduled ('bottom half'.)
- jacquesm 6y agoAnd that only if your codepath is deterministic. Linux can do pretty funny stuff at times. I've run a plasma cutter under Linux on a run-of-the-mill VIA SBC, it was actually pretty easy: just make a program setuid root, use that to disable interrupts after you've read all your data in and then just go wild on polled and precision timed IO until you're done. Re-enable interrupts and return as if nothing ever happened.
- joshvm 6y agoYep, more that actually being able to turn interrupts off is a barrier to doing real time work on desktop OS's, for example. Even if you can disable them globally (I think on the Pi you can with some low level C), but stuff goes wonky quickly e.g. if the WiFi soc doesn't get serviced. It's a good lesson to play with polling versus interrupts on a micro. Susprising just how many cycles it takes to jump into the ISR.