Quote:
Originally Posted by team1165wins
That is pretty nice for this. Also, the cRIO needs to continuously interrupt, reducing performance. Sending a Pulse through a PWM means that the cRIO will need to wait for the signal to send before it can do the next thing. This processor can have a core doing it in realtime. The microcontroller has i2c so it can be easily interfaced through the WPILib C++.
|
Interrupts don't exactly work that way.
There are many ways to do something. The MPC5500/5600 I mentioned earlier has dedicated hardware to time outputs (eMIOS and eTPU) so the processor only has to set them up at init and write a memory mapped register to set the value. The eTPU can even run timing-critical code on it's internal processor, without interaction with the PowerPC. The cRio uses an FPGA to do something similar, neither method requires an interrupt at all.
On a normal processor supporting interrupts, it would be common to generate PWM using a timer interrupt. You could setup the timer to interrupt when you next need to service some IO thing, go on and do other things, and interrupt back when it's time to do something again. All of this assumes the micro dosen't have PWM generation in hardware, most can do it using timers, the propeller has nothing resembling hardware PWM generation.
The purpose of an interrupt on micro programming without a pre-emptive OS is to provide a method to pre-empt the running task to deal with an important event (usually IO or clock related) allowing the running task to go on with it's buisness on a single faster core. There's not very much inherintly inefficient about the interrupt if the code is written well. When you can prioritize interrupts, it's common to run fast code in a low-priority ISR as a basic pre-emptive system.
An embedded microprocessor is frequently surrounded by peripherals which can do a LOT of things in hardware and only signal interrupts when they are needed or wanted. The propeller has none of these, and has to do everything in software. It will spend most of it's time doing these mundane IO tasks which are usually done in hardware, including waiting for events instead of using interrupts, which is exactly how it is designed to work. This means it will spend many clock cycles waiting for timing or spinning until it's ready, where an interrupt driven processor could use those clock cycle to do useful other things and interrupt back when it needs service again.