9 replies to this topic

[phil]

This is not meant to be a criticism. Just a little testing to see what the basic capabilities of the device and the /net MF are.

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.

Phil

Attached Files

•  ScopeRun.jpg   1.45MB   77 downloads
•  timing.txt   4.84KB   19 downloads
•  Program.cs.txt   1.86KB   25 downloads

[Chris Walker]

Hi phil, Thanks for taking the time to do this and for the excellent feedback. You are correct... .NET MF C# code isn't really meant for doing things like decoding microsecond-level IR waves. For that, you'd want to write a native code (C++) driver--and then you can do all the logic to use the received message in managed (C#) code. That's a similar strategy to what has been done on the desktop as well (drivers in C++, application logic in C#). We're also looking at ways to enable users to introduce native C++ code to their application without having to compile it into the firmware. More on that as it develops... Chris P.S. A few advanced optimizations you can do in your code: 1. When making timing measurements, I would highly recommend using the Stopwatch class we provide when possible...and not the DateTime.Now logic. Here is the Stopwatch class: http://forums.netdui...topwatch-class/ 2. In your RC_In_OnInterrupt function, try combining the read and write functions into one command (so that you're not allocating unnecessary variables on the stack just to hold a value). Try PulseOut.Write(!PulseOut.Read()); 3. In your RC_In_OnInterrupt function, see what happens to your timing when you remove all the logging/diagnostics code. use one line of code there (the PulseOut.Write(!PulseOut.Read()); line) and see what happens on the oscilloscope.

[CW2]

Phil, what build configuration have you measured - Debug or Release?

[CW2]

1. When making timing measurements, I would highly recommend using the Stopwatch class we provide when possible...and not the DateTime.Now logic.

IMHO there is a slight inaccuracy when using Stopwatch in the interrupt handler: as phil already pointed out, interrupt handlers are queued, so Stopwatch returns the time when the interrupt handler is being executed and not when the event that triggered the interrupt occured - that time is passed to the handler via its last DateTime parameter. Thus, I would suggest to use

static void RC_In_OnInterrupt(uint data1, uint data2, DateTime time)
{
  ms = time.Ticks;
  ...
}

Note: I have found optimization in .NET Micro Framework to be rather tricky - the optimization target is CIL, not assembly language. Thus, the usual "how the C# code gets compiled into native assembly" way of thinking does not work here (unlike in 'full' .Net Framework), and the actual performance depends on TinyCLR internals - which are sometimes surprising. Then comes ILDASM and measure, measure, measure...

[Chris Walker]

IMHO there is a slight inaccuracy when using Stopwatch in the interrupt handler: as phil already pointed out, interrupt handlers are queued, so Stopwatch returns the time when the interrupt handler is being executed and not when the event that triggered the interrupt occured - that time is passed to the handler via its last DateTime parameter.

Great point.

[phil]

Phil, what build configuration have you measured - Debug or Release?

Release. But the code is not at all optimised, as Chris pointed out.Though some experiments I've done suggest that there is no difference between write(read) and var=read; write(var). It all comes down to the way it gets optimised by the compiler. I'll have to figure out how to look at the IL .. my better half is an IL / .Net expert.

The really interesting thing for me is the way the MF queues interrupts. It makes sense, but it just seems wrong! :^)

In any case, I'm taking this to it's logical conclusion. I'll put a full blown RC6 IR decoder code set up here or somewhere else as the result of this little experiment. I love algorithms, and RC6 is a nasty little IR protocol. Manchester encoding is such a mean invention! :^)

[Chris Walker]

Another interesting fact is that you can compile the Netduino firmware as "RTM" instead of "Release"...and it'll strip out the Visual Studio hooks and debugger code. Then your code will run even faster. But this usually designed for production devices--not for deploy/debug scenarios. Thanks for contributing the decoder, phil.

[CW2]

Though some experiments I've done suggest that there is no difference between write(read) and var=read; write(var). It all comes down to the way it gets optimised by the compiler.

IMHO C# compiler does very good job here.

I'll have to figure out how to look at the IL ..

RedGate Reflector (originally created by Lutz Roeder) is very powerful tool (with numerous add-ins) that can display IL, among other things - just set "IL" language in Options dialog. Additionally, Microsoft's ILDASM is included in the SDK (installed with Visual Studio or available for download on MSDN), usually located in %Program Files%\Microsoft SDKs\Windows\v#.#\bin.

[krst]

Another interesting fact is that you can compile the Netduino firmware as "RTM" instead of "Release"...and it'll strip out the Visual Studio hooks and debugger code. Then your code will run even faster. But this usually designed for production devices--not for deploy/debug scenarios.

Thanks for contributing the decoder, phil.

How would you do this?!

[CW2]

How would you do this?!

There are three firmware configurations controlled by the value of 'Flavor' build system property - you just executed msbuild ... /p:flavor=RTM instead of /p:flavor=Release (or Debug). Please note this is related to the firmware build, you need .NET Micro Framework Porting Kit. The various build properties are described in its documentation.