17 replies to this topic

[Johan Kohler]

First of all, thank you for bringing us so much power and simplicity for such a low price, I have sometimes wanted a bit more power than what the Arduino has, and this seems to give exactly that. Here is my question. Is it possible to call native ARM code from the C# code somehow? Sometimes you need a bit of extra umph. Right now I need it for Fast Fourier Transforms.

[Chris Walker]

Is it possible to call native ARM code from the C# code somehow?

Hi Johan, welcome to the forums!

There are two possible ways to do this.

Today:
Netduino is open source, so we provide the source code. You can create a managed component with raw C++ behind it and then compile it in. If you'd like, I can point out some references on how to do this.

Future:
It's totally possible to load unmanaged (native C++) code at runtime. After all, we'd just need to move the microcontroller's "instruction pointer" to the right place. There are some issues with playing nice in the threading model, giving people power that can come back to bite them, etc. But perhaps we can come up with a good way to handle these as a community--and then build a way to deploy and run unmanaged code into a future firmware release. That would be really cool.

Chris

[Johan Kohler]

Creating a managed component might be the most appropriate for my problem. One more question, and I think I know the answer to this one. Is it possible to debug the native code I add in msdev?

[Chris Walker]

Is it possible to debug the native code I add in msdev?

C++ code is compiled and debugged through the C++ compiler/debugger (GCC, etc.; we use RVDS and RVICE here)--not Visual Studio. You'd need an ARM dev board with JTAG to really dig in and debug that.

That said, you could do some simple things to debug: flash the LED, write data out via a serial port, write data out into the MFDeploy debug stream, etc. That's actually how we do a lot of our debugging...it's so much quicker and simpler than using RVICE and JTAG.

Chris

[CW2]

It's totally possible to load unmanaged (native C++) code at runtime. After all, we'd just need to move the microcontroller's "instruction pointer" to the right place. There are some issues with playing nice in the threading model, giving people power that can come back to bite them, etc. But perhaps we can come up with a good way to handle these as a community--and then build a way to deploy and run unmanaged code into a future firmware release. That would be really cool.

GHI Electronics have developed 'Runtime Loadable Procedure' (RLP) [^] for their ChipworkX module - this may be a good starter...

[Chris Walker]

GHI Electronics have developed 'Runtime Loadable Procedure' for their ChipworkX module - this may be a good starter...

Thanks for the link! Yes, something along those lines would be good. I'll see what we can pull together (if someone in the community doesn't come up with something clever first).

Chris

[rfterry]

What is the basic "heartbeat" of the Netduino when runing in the managed dot.net environment? Or does the concept of a "heartbeat" even make sense. I noticed that when I commented out the 250ms delays in the blinking LED C# program that the maximum blink rate seemed to be about 8.3kHz. That's quite a reduction from an ARM running with a 48MHz CPU speed. For many many applications the convenience of having the debugger and the C# IDE overshadows the need for speed. I'm just wondering what are the speed metrics in the managed environment? Thanks

[CW2]

I'm just wondering what are the speed metrics in the managed environment?

Please have a look at the following article (pictures are at the bottom), which contains some measurements along with code hints - it is for a different micro (~100 Mhz), but you can get the idea - at least until someone provides the exact results for Netduino...

Bonus interesting facts:

• Thread switch interval (time slice, quantum) is 20 ms,
• Thread.Suspend() does not stop the thread immediately (it runs until its time slice expires),
• When the CLR calls into any custom interop (i.e. native) code, all managed code threads are suspended

Sources
Using Interop in the .NET Micro Framework V3.0,
Thread Management In the .NET Micro Framework

Edited by CW2, 12 August 2010 - 06:29 PM.

[Klop]

There are two possible ways to do this.

Today:
Netduino is open source, so we provide the source code. You can create a managed component with raw C++ behind it and then compile it in. If you'd like, I can point out some references on how to do this.

Future:
It's totally possible to load unmanaged (native C++) code at runtime. After all, we'd just need to move the microcontroller's "instruction pointer" to the right place. There are some issues with playing nice in the threading model, giving people power that can come back to bite them, etc. But perhaps we can come up with a good way to handle these as a community--and then build a way to deploy and run unmanaged code into a future firmware release. That would be really cool.

Chris I'm looking for a way to do this. Can you tell me how to create a managed C++ component and then compile it in.
Is there support for running unmanaged native C++ code in the current firmware?

Thanks.

[Chris Walker]

Hi Klop,

Check out this Adeneo article. It's actually pretty simple to create a managed code component with P/Invoked C++ behind the scenes.

The only drawback to the current method is that you need to compile your tweaks into the firmware. We're working on a "runtime deployment" scenario for native code...but that will only be a subset of what you can do today. The native interop described in that article gives you full power and deep integration capabilities.

Chris

[Klop]

Hi Chris, Thank you very much for the link to the article.

[Klop]

Hi Chris, Do you think you can help me with choosing or creating the right porting kit solution for my interop solution. The article you linked to suggest not to use the SolutionWizard and just use a, I suppose, "default" solution? Can you maybe point me in the right direction? If I try using the SolutionWizard I get a treeview from which I have to select all kinds of options and I'm not sure which options to choose. Thanks.

[Chris Walker]

Hi Klop, We edit the files by hand, as it's generally more flexible. If you follow the example and look at the SecretLabs.NETMF.Hardware libraries in the Netduino firmware source code, that should give you a pretty good template. The instructions for the SolutionWizard are in the C:\MicroFrameworkPK_v4_1\Documentation\RCLPort.chm file...although they may be a little sparse. Perhaps we should all start a Wiki article and everyone can pitch in their insights and experiences? There are some changes coming in .NET MF 4.2 which add a GUI around more of the customization process... Chris

[Klop]

Hi Klop,

We edit the files by hand, as it's generally more flexible. If you follow the example and look at the SecretLabs.NETMF.Hardware libraries in the Netduino firmware source code, that should give you a pretty good template.

The instructions for the SolutionWizard are in the C:\MicroFrameworkPK_v4_1\Documentation\RCLPort.chm file...although they may be a little sparse. Perhaps we should all start a Wiki article and everyone can pitch in their insights and experiences?

There are some changes coming in .NET MF 4.2 which add a GUI around more of the customization process...

Chris

Hi Chris,

Can you tell me why it is necessary to link and build your native C++ code into the MF framework. Why not just link it with the Netduino firmware from you guys. Am I missing something or have I completely got it all wrong?

Thanks.

[Chris Walker]

Can you tell me why it is necessary to link and build your native C++ code into the MF framework. Why not just link it with the Netduino firmware from you guys. Am I missing something or have I completely got it all wrong?

The Netduino firmware is a superset of the .NET Micro Framework. You can certainly link additions to the object files that make up the Netduino firmware--but that's more or less the same thing as compiling it in.

We are designing an option to let you deploy native code as part of a Visual Studio solution--but that will be a limited subset of functionality compared to what you can do with the current method.

Chris

[Klop]

The Netduino firmware is a superset of the .NET Micro Framework. You can certainly link additions to the object files that make up the Netduino firmware--but that's more or less the same thing as compiling it in.

We are designing an option to let you deploy native code as part of a Visual Studio solution--but that will be a limited subset of functionality compared to what you can do with the current method.

Chris

That sounds very cool. When do you think you will release this? Was that with the upcoming MF 4.2 release sometime in "august"?

[Chris Walker]

That sounds very cool. When do you think you will release this? Was that with the upcoming MF 4.2 release sometime in "august"?

It's largely a community project, although we're steering it and contributing as well. No definitive timeframe and it will come in "test pieces", but we'd like to start testing some concepts later this summer.

Chris

[fxmaker]

Hi, The last response here was almost a year ago. How is the project coming? That is, dynamically loading native unmanaged code? Thanks