3 ms·

Interrupt-based designs are bad for real time, for the reasons you give. Instead you want to use techniques like polling and static scheduling, where every proc

Interrupt-based designs are bad for real time, for the reasons you give. Instead you want to use techniques like polling and static scheduling, where every process gets a fixed time slice. This reduces the variability and improves fidelity to your model, since you know at every point what processes are running.

occultist_throw 9y ago
Easy to say that interrupts are bad.. But when you need to know of a pin change, rising or falling IRQ, interrupts are the only game here. And not only that, but if we were to do the timeslice strategy, then we need that slice to be at least 2x more than the fastest input for that pin. I would think with that strategy, you'd be servicing "slice-interrupts" more than anything else. I'll stick with writing ISR's that are only a few commands and do my work outside the ISR's, as standard in industry now. Now, on a related topic, if they're discussing getting the system to a 10us timing, that would be useful in using Linux as a 3d printer controller directly, rather than an Atmel or STM32 chip. But those requirements of what needs turned off seems pretty onerous, unfortunately.
Too 9y ago
Interrupt analysis is a core element for designing a real time system. High speed data interfaces don't always work good with polling. In theory it's actually quite easy, from the data sheets you can find out or configure the max frequency an interrupt can occur, then you just multiply that frequency with the WCET of your interrupt routine, assume it will always happen and deduct that time from your main loop time budget.
zurn 9y ago
IO interrupts and scheduling based surprises were a pretty small part of the list, though.
jacquesm 9y ago
The trick to this is to do the absolute minimum required in the interrupt routine and to push the rest of the work to a regular piece of software that gets scheduled at the right priority due to the interrupt having been processed. Doing actual work in an interrupt routine is a non-starter in a real time environment.

occultist_throw 9y ago

Easy to say that interrupts are bad.. But when you need to know of a pin change, rising or falling IRQ, interrupts are the only game here. And not only that, but if we were to do the timeslice strategy, then we need that slice to be at least 2x more than the fastest input for that pin. I would think with that strategy, you'd be servicing "slice-interrupts" more than anything else. I'll stick with writing ISR's that are only a few commands and do my work outside the ISR's, as standard in industry now. Now, on a related topic, if they're discussing getting the system to a 10us timing, that would be useful in using Linux as a 3d printer controller directly, rather than an Atmel or STM32 chip. But those requirements of what needs turned off seems pretty onerous, unfortunately.

Too 9y ago

Interrupt analysis is a core element for designing a real time system. High speed data interfaces don't always work good with polling. In theory it's actually quite easy, from the data sheets you can find out or configure the max frequency an interrupt can occur, then you just multiply that frequency with the WCET of your interrupt routine, assume it will always happen and deduct that time from your main loop time budget.

zurn 9y ago

IO interrupts and scheduling based surprises were a pretty small part of the list, though.

jacquesm 9y ago

The trick to this is to do the absolute minimum required in the interrupt routine and to push the rest of the work to a regular piece of software that gets scheduled at the right priority due to the interrupt having been processed. Doing actual work in an interrupt routine is a non-starter in a real time environment.