9 ms·
I'd think, if you need rapid, real time response to external signals, you don't use interrupts, since then you usually need it to be deterministic as well. Eit
by guenthert 3y ago
I'd think, if you need rapid, real time response to external signals, you don't use interrupts, since then you usually need it to be deterministic as well. Either use 'nother micro, a spare core, given specialized hardware (e.g. the PRUs in TI's sitara MCUs, the PIO of RP2040, P8X32A) or roll your own (these days probably using FPGAs).
- SomeoneFromCA 3y agoYou are wrong, as polling always introduces jitter (due indeterminacy of the event arriving moment between the last entry to the polling loop and the comparison operation). If you want really precise timing while reacting to external event is to sit in "halt" state, with interesting interrupts enabled.
- deleted 3y ago[deleted]
- ddingus 3y agoAnother micro = big BOM cost increase Another core = overall device cost likely unnecessary. Both blow the power budget up. Regarding determinism, relative to what? An interrupt will, or can be very consistent relative to the signal. Polling jitters relative to the same signal. That may not be desirable. Now, I did see you mention a Propeller chip! The first chip worked as you describe and it is beautiful. There are good reasons why interrupts were added to the second generation chip. They are mostly the reasons found in this discussion. I was a part of the P2 development. We had a TON of discussion on this topic. Fascinating. Let me share an observation: Many interrupt systems end up overloaded. One ends up writing a mini operating system to manage all the desired outcomes! And that can be a mess for sure. In the P2 chip, a couple things were done to help with all that: One is a priority and event system. Events trigger interrupts, and those break the program flow due to early implementation choices made that simplified the chip and made the power budget sane. There are three priority levels and 16 events that trigger on incoming signals as well as on chip events and other core on chip. The other was polling modes so one can wait and employ whichever mode made the most sense. Finally, interrupts happen after instructions complete. Doing this came with some controversy! But, it seriously simplified the chip and helped to draw the lines where the developer has choices to make and good options to make them.
- deleted 3y ago[deleted]