Is there anyway I could re-use existing C code libraries in my project. The work that would be involved in translating them in C# would be enormous.
is it possible to use existing c code with NETMF ?
#1
Posted 25 May 2013 - 09:06 PM
#2
Posted 27 May 2013 - 01:07 PM
If you build your firmware, and make an 'interop assembly', you can expose an interface to your code to NetMF applications. The firmware ultimately is C/C++ itself. In this way it is conceptually similar to making a JNI
Beyond that, it will depend on what your existing code does (e.g. library/system dependencies). Is it, say, purely mathematical (like signal processing), or systemic (like, some custom network protocol). The former should be readily doable, because it's probably not coupled to any dependencies, and the latter could be a challenge because it is (ostensibly to the sockets api for example).
#3
Posted 27 May 2013 - 01:40 PM
Is there anyway I could re-use existing C code libraries in my project. The work that would be involved in translating them in C# would be enormous.
I've ported lots of code from C to C# and found it to be a very straight forward (almost mechanical) process even though it has not always been my own code to begin with. Many things can be taken care of with simple search and replace.
There are some converters out there but I have no idea if they're any good - but they should at least be able to do the "no brainers" for you:
http://lmgtfy.com/?q=convert+C+to+C%23
#4
Posted 27 May 2013 - 02:52 PM
I would love it if there was some "non very painful" way to directly run un-managed "C" code on the netduino. That is, I do not want to have to compile the kernel (and buy a $2K compiler).
For me, I'm not talking about code converted to C# and crawling through the simplistic (to save space) NETMF interpreter.
Then, I could do "similar" things like when I run an embedded processor on an FPGA. There, I have the FPGA do the fast stuff and the processor do the I/O.
For the netduino, I'd love to be able to do fast stuff and just pass parameters/info between the fast "C" module, and the C# I/O handler.
If you build your firmware, and make an 'interop assembly', you can expose an interface to your code to NetMF applications. The firmware ultimately is C/C++ itself. In this way it is conceptually similar to making a JNI
Any chance that you know of a thread or web page that gives more detail on how to do that for the netduino?
BTW, for others that don't know JNI=Java Native Interface.
Thanks!
#5
Posted 27 May 2013 - 03:41 PM
#6
Posted 27 May 2013 - 03:47 PM
I would love it if there was some "non very painful" way to directly run un-managed "C" code on the netduino. That is, I do not want to have to compile the kernel (and buy a $2K compiler).
...
one of my many mini-projects for firmware mods is to support something like this:
* a section of flash is reserved into which compiled 'native' funcs are deployed
* a common, simple, c# interop is used to thunk to them
* and some modded libs like CRT to thunk to the impl that is already there in firmware
so, you would build/link your C(++)/asm, ultimately making a hex file, than you then flash into the 'native deployment area'. but you wouldn't have to mess with the firmware itself.
I was hoping to do this personally so that I can more easily do experiments rather than building firmware or going through the chore of making an interop for each case. And, yes, gcc et al. But I suspect this will take a bit of work to make it robust.
..Any chance that you know of a thread or web page that gives more detail on how to do that for the netduino?
BTW, for others that don't know JNI=Java Native Interface.
I think GHI has some cursory info. They also have a dll-esqu approach to native code integration, called a Runtime Loadable Procedure (RLP), but I'm not in love with it because it loads the code into RAM, which for me is already much too precious, but the concept is interesting and could be useful for some surgical cases. Alas, I cannot even get their firmware to flash on the board I do have (they deploy firmware with mfdeploy, which has never worked for me), and when I force the issue by making a dfu, the system was so unstable that I couldn't even deploy a blinky to it, so I have put their stuff on the back-burner until I can manufacture some non-existent free time....
Edit: you inspired me to goog, and I found these links which looks promising from an interop implementation perspective but I haven't studied it yet...
http://blogs.msdn.co...ework-v3-0.aspx
http://informatix.mi...ls/Interop.aspx
Coincidentally I'm updating my firmware source repository right now, so maybe I'll put forth a few minutes to make a stub interop assembly to try out the process....
#7
Posted 27 May 2013 - 04:40 PM
@ziggurat29
The links look interesting.
Thanks!
#8
Posted 28 May 2013 - 01:39 AM
[font="arial, sans-serif;"]Thanks all for your responses. So my understanding of the conclusion is that the only way to use C code with the NETFM platform is to add it to the firmware. I understand why but at the same time I can’t but think that it is a weakness of the platform. There is a lot of very good open source code out there and it is a pity to be cut off from it. And if the solution is to tinker with the firmware, that somehow defeats the purpose of using a platform like NETFM, which is designed to allow to remain at a high level of abstraction![/font]
#9
Posted 28 May 2013 - 02:46 AM
Its a pretty common desire, and it is a bit of a shame that there isn't some 'native code dll' notion out-of-box to make it easy; but, sometimes you have to do things yourself, and at least we do have the source! And gcc!
Today, since I coincidentally was udpating source and verifying my build, I thought 'why not try out the process of making an interop', and so I did, so I'll write up the experience forthwith. I'll try to make the example small, but more meaningful than my 'return 42;' that I used in my test; maybe I'll implement a Peek and Poke to directly read/write addresses like we did in BASIC of yore...
#10
Posted 28 May 2013 - 05:42 PM
This would be very helpful and appreciated !
#11
Posted 29 May 2013 - 10:54 AM
probably this weekend when I can get some free time to write it up and proofread it.
FYI for testing I did implement a 'peek' and 'poke' method allowing bit fiddling from managed code; I used it to activate and use the chips's hardware RNG in my little test.
as to whether the interop approach will work well for you, that might depend on what your legacy code is doing.
#12
Posted 30 May 2013 - 10:35 PM
Well I did try to post to the wiki, but I can't seem to log into it anymore. I was able to in Jan, but not today, alas. I have had some fun frobbing the various machine registers, such as the RNG, and 'device serial number', so perhaps the wiki will get resolved and I can share the process....
#13
Posted 01 June 2013 - 02:47 PM
Well, I never could get into the wiki to post my article "Building an Interop Assembly for Netduinio Plus 2", so I'm going to attach it here.
There are two files,
1) BuildingInteropAssemblyForNetduinoPlus2.zip
contains the article and all the source, projects, etc.
2) demopeekpokefirmware.dfu
optional, contains a pre-built firmware image with the sample interop in case you want to play a bit without going through the trouble to build.
The sample project is simple, but a bit useful since it lets you read and write to arbitrary memory locations. Since the hardware is memory mapped, you can play with features not normally accessible; for instance, in the demo, I use the on-chip hardware random number generator, and also read the chip's unique serial number.
Anyway, hopefully its useful to someone, and I'll move it to the wiki if that ever gets fixed.
Attached Files
#14
Posted 01 June 2013 - 04:03 PM
Well, I never could get into the wiki to post my article "Building an Interop Assembly for Netduinio Plus 2", so I'm going to attach it here.
There are two files,
1) BuildingInteropAssemblyForNetduinoPlus2.zip
contains the article and all the source, projects, etc.
2) demopeekpokefirmware.dfu
optional, contains a pre-built firmware image with the sample interop in case you want to play a bit without going through the trouble to build.
The sample project is simple, but a bit useful since it lets you read and write to arbitrary memory locations. Since the hardware is memory mapped, you can play with features not normally accessible; for instance, in the demo, I use the on-chip hardware random number generator, and also read the chip's unique serial number.
Anyway, hopefully its useful to someone, and I'll move it to the wiki if that ever gets fixed.
Wow, great write up and examples!
THANKS!
#15
Posted 01 June 2013 - 04:14 PM
Thanks a lot.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users