Real-time programming with .NETMF and Netduino

I recently purchased a digital LED strip that I use with my Arduino Mega and it works fantastically.  The protocol that it uses is highly timing dependent so the retailer says that it cannot be used with the Netduino.  Of course, I take this as a challenge and I want to get it working on the Netduino for a lot of reasons but I know there are several issues that I'm going to run into related to timing.

First, the garbage collector will destroy the protocol if it runs while I'm updating the strip.

Second, as far as I can tell there's no guarantee that my code won't get interrupted by another piece of code while it is running.

The code really will consist of setting a line high or low, waiting a very specific period of time, and then setting it high or low again.  Repeat over and over for a few milliseconds and then we can go back to executing regular code.

So... what I want to know is:

- Is it possible to stop the garbage collector?  I can do allocationless programming as some people have suggested but I want to know if there is a way to guarantee that the GC won't run.

- Is it possible to tell the Netduino or the .NETMF that only one thread can run for a short period of time?  Sort of like a critical section that will do all of the timing dependent code.

- Are there other .NETMF gotchas that might cause the timing to be imperfect?

- Will this just require me to write native code?  If so, that's no big deal but I'd rather start there if these other ideas aren't practical rather than bang my head against a wall for a few days while I come to that realization.

Thanks,

Tim

I don't think you can fiddle with the GC that way, except to force it to happen

Microsoft.SPOT.Debug.GC(true)

(I don't know what happens with 'false', the doc is not explicit).

But...  usually those strips are SPI, no?  It the protocol truly that unusual?

Hi Tim!

You say the Netduino should toggle a pin - do you think using PWM would be an option? This would "run" in the background and won't be affected by anything else since it's performed purely in hardware. It sounds to me a little like you are trying to do bit banging - if so, why not use actual hardware SPI or I2C or whatever it is?

I was under the impression that the GC won't run when the CPU is busy, but if you use Sleep() to do the timing between ON and OFF, then the GC might start working during the sleep state. You could try doing busy wait instead to prevent the GC from interrupting.

To my knowledge, no other threads should be running unless you've explicitly started them yourself. If you are running several threads and would like for one of them not to be disturbed while performing a time critical task, there are means of synchronization. You can do mutual exclusion of certain code sections using the lock function. The lock function can be used like this:

class foo{    private object _sync = new object();        void mutually_exclusive_routine()    {        lock(_sync)        {            // there can be only one thread here        }    }}

This will only prevent other threads from entering the same code section. If you have references to the threads you can issue a Pause() on each of them and then do Resume() when you're done. You might also want to take a look at the ManualResetEvent and the AutoResetEvent classes respectively - these can be use to put other threads in a wait state at any number of places in your code.

Writing native code involves setting up an ARM tool chain, modifying the firmware source code, adding your own functionality, creating an interface so that it can be accessed from managed code, compiling the firmware, tuck it into a DFU file and then flashing it onto your Netduino. Obviously, it's quite doable as several forum members are doing it with great success but for most of us, it would be quite a project in it self 

I don't think you can fiddle with the GC that way, except to force it to happen

Microsoft.SPOT.Debug.GC(true)

(I don't know what happens with 'false', the doc is not explicit).

 

But...  usually those strips are SPI, no?  It the protocol truly that unusual?

Yes, these particular strips are not SPI.  They are a proprietary 1-wire protocol (I don't think they are truly Dallas 1-wire).  SPI requires 4 wires so I'm sure this is different although I wish I was wrong!

It is this model:

http://www.adafruit.com/products/1138

PWM won't work in this case either since it isn't a steady state of on/off that I need but really a protocol where I'll be changing the state to transmit the RGB values in a very timing specific way.

I'll start looking into native code.  Are there any tutorials on how to get started?  I've written plenty of low level stuff before just not on the Netduino so I'm not terribly worried about it.

Thanks,

Tim

...this model:

http://www.adafruit.com/products/1138

...

I'll start looking into native code. Are there any tutorials on how to get started? I've written plenty of low level stuff before just not on the Netduino so I'm not terribly worried about it.

...

interesting strip, I'm jealous.  Didn't have time to rummage through the docs, but I take it at your word, that it's a funky serial protocol.

OK, native code.  Here's what I do know:

*  coincidentially, I wrote a wiki article on how to set up to build the netduino firmware with the gcc toolchain.  You can start with that, or use the expensive non-free RVDS which is what is used for the official build.  GCC requires some setup effort (which is why I wrote the article), and RVDS will work out-of-box.

*  Once you can compile the firmware, then its time to make the new stuff.  I believe that what you are going to make is an 'interop assembly', that exposes some .Net stuff to your app, and interfaces with native code that controls your hardware.  I italicize 'believe' because there may be other approaches that are useful that I haven't thought of -- I don't consider myself a .net-anything guru, haha.  Anyway, making on of the interop assemblies is on my to-do list anyway for part of my current work, so I'be be interested in hearing about your experience, and maybe even helping in some way.

-dave