I wanted to explore the interrupt latency (time from when something happens at a pin until an interrupt from that pin is serviced) and timing capabilities would be.
I set up an ordinary IR receiver and fed it directly to the D7 pin. I took D2 and set it as an output. I attached both pins to a digital storage oscilloscope and wrote a simple little program that would:
- React to the input pin changing
- change the output pin to match
- record the time the event happened and the pin state
There is a little method to then print out the timing measurements in microseconds and the state values. I then pointed an RC6 remote (a windows media centre remote) at the IR receiver and recorded the measurements and the scope output.
It looks like the latency is quite predictable (I didn't expect that) but the timing looks like 1 millisecond resolution is about the best I can achieve (I did expect better than that). The RC6 protocol is about the hardest one to decode, using an initial 2.7ms start bit (recorded fine by the netduino) followed by half bit Manchester encoded data. Each half bit is only 444 us, and that was just too short for the device to measure.
Interestingly, the MF seems to queue the interrupts. If I change the attached program to use the timestamp included in the event handler then the timing values will be correct (400 & 800 ms), though it does not change the delay effects. In that case it can be used to decode the IR signals. I might actually make a project out of that for interest's sake. Queuing interrupts ins kind of weird for an old embedded engineer like me. It's going to take some getting used to.
The program, the scope shot and the output are attached. The yellow trace id the IR receiver output, the blue is the D2 output from the netduino. I'm interested in any comments... if you think I made some huge blunder, please let me know.