6 replies to this topic

[osno]

It would be amazing if we could do the following: Have a solution with a C native project that compiles ARM and a Netduino MF project. Deploy both to the device. In the netduino code, use p/invoke (the DLLImportAttribute) to call methods in the C native project. Is this even a possibility? I'd love to help implement that in Visual Studio if it's possible. Regards, J

[Chris Walker]

Hi osno, It would be really cool to do it that way. In the meantime, native code interop is fully supported by .NET Micro Framewrok--but you need to load the native code on your Netduino as part of its core firmware (and then interact from C# code). Here's a good example: http://adeneo-embedd...-framework.html Chris

[osno]

It sounds incredibly difficult so I'll have to try it! Is it possible (theoretically) to modify the bootloader so you can deploy native code? If it is, I'll love to help integrating it to Visual Studio. And btw, will this solve the main issue with .Net MF, which is speed? Meaning, can I do speed-sensitive stuff in native code and complex logic in managed code and expect it to work? Thanks, J

[Chris Walker]

Hi osno, You can certainly do speed-sensitive stuff in native code and complex logic in managed code. The one thing to be aware of is that it's fairly easy to write functions in native code. But if you want to do threading or callbacks or interrupt-driven code in the background, you'll need to work with the .NET MF's continuations/threading/interrupt systems. If you want to deploy 100% native code (skipping .NET MF completely), just short the 3.3V pin header to the ERASE pad (that little gold pad just below and to the right of digital pin D0). Then unplug and reattach your Netduino. To flash pure native code, you can use Atmel SAM-BA. This is also how you'd reflash TinyBooter back onto the board. Chris

[osno]

SAM-BA sounds scary right now, so I think I'll skip it. What I can do is: var secondLoopThread = new Thread(SecondLoop); secondLoopThread.Start(); where SecondLoop is an infinite loop in an extern method. Will that work? My goal is to have a DEMUX looping through several outputs every 100-200ns, so I can provide the illusion of a single output driving many outputs at the same time. For instance, have 16 LEDs and be able to turn on any combination of them with just 4 GPIO pins in the Netduino. So the logic for which LEDs to turn on will be in .Net, and the loop for turning them on and off will be in native. .Net is too slow to reliably provide this illusion. Regards, j

[Chris Walker]

osno, Multithreading is cooperative in .NET MF (rather than preemptive like on the PC). Bascially, .NET MF steals back execution from a thread if that thread is taking more than ##ms to execute. If a native code function never returns (in any thread), .NET MF is unable to switch execution back to another thread. But if you set up a timer interrupt that would reliable callback every ##ms, you'd be fine. That's significantly more complicated though. Chris

[Innovactive]

We recently posted an updated guide to Interop programming on netmf.com forum.

Please take a look here. Be sure to read whole thread for useful info!