I am trying to port the .NET Micro Framework to an embedded operating system (ARM9 based). During the last weeks I did a lot of research in this topic in the internet and the porting kit documentation. The porting kit documentation is a bit disappointing to me, it seems unstructurized and out of date. No good microsoft quality I think.
What I have reached at the moment:
[ulist]build.dirproj in the topmost directory of the porting kit is buildable.[/ulist]
[ulist]The existing “template codebase” solution was cloned as recommended in the porting to os section in the official documentation.[/ulist]
[ulist]The cloned solution is buildable.[/ulist]
So the existing firmware(with operating system) has a linker script and I want to add the MF. Is there a need to change the scatterfile of the NativeSample (=scatterfile_tools_gcc.xml)? Or simply add NativeSample.axf to the firmware linker script?
In my opinion the next task is to fill the PAL stubs with the OS calls. Ist this true? How do I identify these calls?
As far as I know there is no book describing the porting process?
Is it more difficult than porting to real hardware? I thought it saves a lot of work because the hardware initialization is already done. So we need to fill only the PAL functions and some HAL functions but not all…
Is my assumption correct?
Of course there is a lack of performance compared to bare metal operation. That won’t be the problem. My goal is to make it runnable even though it is slowly…
At the moment I have problems what functions are really needed in order to get NativeSample running. In the documentation there is a list when doing a bare metal port, not for OS. I think with the underlying OS some functions will be obsolete.
If you already have an operating system at your disposal, then rather go for .Net Compact Framework (which runs on Windows CE) or Mono (which can run on embedded Linux distros).
The beauty of Compact Framework is that you can run the Exe on a “regular” PC with no modification - which is great for initial debugging.
On the NETMF side, the emulator is an example of an environment where NETMF is running “on an O/S”. I guess it should be possible to get hold of the source code for the emulator itself and port that to where you need it. It creates an execution environment for the NETMF CLR to run and abstracts the hardware layer through the O/S.
NETMF very quickly gets specific to a piece of hardware - so it really wants to run “on the metal”. I’ve always wondered if there would be a NETMF version for x86 that could run on an old Pentium motherboard we all have laying around. That would be interesting to me. Running NETMF on top of an O/S, not so much
In my case the operating system is mandatory so the discussion of porting to real hardware does not exist.
Debugging this operating system is already possible!
Mono is not the right choice we have no Windows CE as operating system.
Do you think analyzing the source code of the emulator could be my entry point for doing the port?
In my opinion the “netmflinux-6162” (.NET Micro Framework for Linux) example would do the same. In other words I have already started analyzing there. Is there anything to be said against it?
I don’t think porting netmf to an OS is the right thing to consider; the idea behind netmf is that it runs on bare metal, and it manages the hardware. You want a higher order product to run on an OS. I certainly suspect that nobody else has done this or looked at this so you’re unlikely to get many pointers from the field here, so like realizer has done, the best you could expect is some rational discussion on pros and cons as well as some web searching for you.
@ realizer
I meant the same link you already mentioned. It ist no Linux it is a proprietary inhouse development which is linux like. More details concerning OS are not allowed, sorry :
Micro Framework could give us official paid support in case we us in our products.
Would Mono be that easier?
@ Gus
The operating system handles several communication layers at the moment. Building Micro Framework on top would ensure us that there is only a different “presentation layer”. The rest lasts unchanged.
Hardware is ARM9 so this shouldn’t be the problem. At the moment we stuck in linking the firmware .elf and the Micro Framework elf to on system. In my opinion the scatterfile.xml of the microframework must fit to the the linkscript of the existing firmware.
Are you expecting fundamental limits we do not consider at the moment?
So allow me to speculate on a fictitious device here… just for fun
Maybe you are building an triple-core telekinetic diffribulator. It is a handheld device for a medical professional that can do remote resurrections.
You need a custom O/S because even though the chip is based on ARM7, it has a unique 3D core architecture that no commercial operating system currently can handle. The processors are also scaled down to improve the flux capacitor life, so running a resource hungry O/S like Windows CE is not an option. Android is also not really suitable because it requires very high precision real-time control of the telekinetic transfer tubes and that is done with very specialised drivers on the proprietary O/S.
Being a modern device, you really want to give it a nice UI and a platinum case. It just sells better. Android is “too heavy” for what you’re looking for - because all you really need is a flashy LCD and one button on the device. What it must do however is to plot the energy transfer graph on the screen so the doctor don’t go and overdo it.
Ok, so where do all this technology fit in?
Your proprietary O/S already understands the hardware and is specialised for the function, but it has no UI and lacks the nice features of file system support, TCP/IP networking and XML parsing which are must-haves today.
.Net MF looks perfect for thise things, but it really was meant to run on a wristwatch… It just can’t handle the TTT hardware.
So basically I get why you’d want to do this (I think). Put a nice light framework over an existing, specialised piece of hardware.
I really only browsed through the NETMF source code, but there are things like the Interpreter and the porting kit helps you to replace stubbed functions with real implementations on a target board. This means it must be possible to stub those stubs with calls into your operating system instead of calling directly into the metal. How, I don’t know, but being the rocket scientist you clearly are, I’m sure you’ll figure it out
I can’t take you through a port step by step in this forum but there is a chapter on porting to an OS in the porting kit documentation. Look for “Porting onto an Operating System”.
I’m hooked on to this porting thing now. I just read Gus’ book and will probably try a port compile this weekend. Looks like for metal work you port the HAL and on an O/S you port PAL.
[quote]the goal of the micro framework is to run the .net libraries on a small processor without an operating system.
the goal of mono is to run the .net libraries on a non-windows operating system.
I think mono is exactly what you need, but you might have the trim capabilities, just like the MF group did, to fit it into a small processor.[/quote]
As our project is commercial we are interested in official MS support. Altough we know that commercial applications will result in license costs.
[quote]So basically I get why you’d want to do this (I think). Put a nice light framework over an existing, specialised piece of hardware.
I really only browsed through the NETMF source code, but there are things like the Interpreter and the porting kit helps you to replace stubbed functions with real implementations on a target board. This means it must be possible to stub those stubs with calls into your operating system instead of calling directly into the metal. How, I don’t know, but being the rocket scientist you clearly are, I’m sure you’ll figure it out Smiley[/quote]
The rocket scientist will stick to browse the code.
Maybe the so called experts here is recommended the same
Please back to topic…
I read your link already a time ago. We have the same reasons as mentioned there.
The chapter of porting is known to me. Personally this Microsoft documentation is very weak, especially in the porting to an OS topic…
Gus’ book, did I overlook something?
Porting the PAL is also my opinion but e.g. NativeSample has no clear distinction between HAL and PAL in the source code. What’s your opinion?
Under Targets there are Native ports, for bare metal, and there are OS ports. There are currently two ports, one for Windows and one for Blackfin OS. Maybe that is a start?\
It does look a lot simpler. You only need to provide an “adaption” layer. That will convert MF driver calls to the OS driver calls.
