Whatever you end up doing, just remember – the moment you leave the CLR, you’re running on bare metal. The managed environment does not sit on top of some sort of RTOS or anything like that – just a very thick HAL/PAL. So, if you call a native function, it will execute and when it’s finished, it will return to the CLR.
If you’re feeling adventurous…
Personally, I prefer interops over RLP in almost every case, and in your project especially, it sounds like a perfect use for interop code. The idea is simple:
Go ahead and create a managed C# class with all the methods you’ll be using. Pretend you’re going to write it all in C#.
before any function you need to run natively (just declare the function – don’t implement it)
Build your library in Visual Studio and copy the files in the \stubs folder to an appropriate place in the port. (Probably DeviceCode\Drivers if your code is processor-independent; otherwise, in the \DeviceCode\Targets folder for your processor).
Implement your function by editing the stub.
Add a reference to the project in the Solution.
This is trickier to do on the FEZ Panda, which isn’t an open-source board, however, if you’re not using any other GHI Premium features, you could grab the open-source NETMF port for it here: http://usbiziopen.codeplex.com/, set up the build environment, and develop your application using interops.
Whenever anyone starts talking about thread synchronization and semaphores, it’s a good sign that they’d rather get the job done right instead of hack something together. Getting the porting kit environment set up takes some time (and lots of reading), but once it’s set up, you’ll easily be able to develop interop assemblies that jump around between managed and native code.
There’s a good wiki tutorial here: