Dela via

.NET Micro Framework on top of another OS

  • Artikel

One unique thing about the .NET Micro Framework is that it is a .NET virtual machine that runs directly on the metal. We did this so that it could be as small and performant as possible for the current architecture. However, there are a number of users who have elected not to run MF on the metal but rather to port it onto another operating system or kernel. This kind of port is fully supported in the Micro Framework.  In fact, there are two porting layers in the architecture. One is the low level Hardware Abstraction Layer (HAL) layer that supports drivers to the hardware. For example, this is where you would plug the Micro Framework directly into the Serial Controller on your board. There is also a higher level of porting interfaces that calls into the HAL. This is the Platform Abstraction Layer (PAL). To continue our previous example, if you want to run the Micro Framework on an OS, you write an interface to the serial interfaces in the OS or kernel rather than directly to the Serial Controller.   architecture

Currently, a significant number of the ports that are done are placing the Micro Framework on another operation system. Why would you do that? Here are a couple of potential reasons.

  • Support for existing libraries or other OS features: Perhaps you have some features in your OS that you are dependent on or there is some piece of code that is already integrated with your existing operating environment which you can’t or don’t want to re-implement in managed code. With the Interop features that were added to MF, you don’t need to rewrite everything in managed code. You can integrate the native code implementations into your managed code applications. In fact, I really like our Interop feature implementation. The native code seamlessly becomes like a part of the existing Namespaces and you call into it like you would any managed code function.

Another example is real-time support. As you know, the .NET Micro Framework is not real-time. Frequently, the real-time requirements of an application are very isolated. By porting MF onto a small kernel or RTOS, you can run your real-time code in that environment and still have the .NET Micro Framework as a highly productive application environment for the rest.

  • Migration strategy: You may actually plan to migrate all your code to managed code but do you need to do everything today? What if you added the Micro Framework as a process on the existing platform and wrote you managed code over time taking advantage of that code already running on the existing OS? No problem.

I’ve seen both of these cases. They both take advantage of the flexibility of the porting experience in MF. Tell me about your reasons for porting to an OS or conversely for porting MF onto the metal? That way we can understand what might be missing from the platform that we should have on our roadmap.

 

Colin Miller

Product Unit Manager

Comments

  • Anonymous
    April 17, 2009
    The comment has been removed

  • Anonymous
    April 19, 2009
    Another approach I see is to provide a "sandboxed" version of the .NET runtime. I work mostly on Windows CE and sometimes you may need to add some programming features to a device. Currently you can provide an SDK for native or managed development (using the compact framework), but in this way you may add features to the standard libraries and classes but not remove them. If you allow an application to run on your device (to provide a custom UI, for example), it will be able to access the filesystem, devices, CPU time etc. and also to call almost any OS API using interop. If you want to provide only limited programming features (like you have with MIDLets in Java) inside a "sandbox", to allow development of custom UIs or "plugins", the Microframework may be a suitable solution. In this way the developers can use a familiar programming language and environment and the device manufacturer can control what third party applications can or can't do in a more granular way.

  • Anonymous
    April 22, 2009
    The comment has been removed

  • Anonymous
    April 27, 2009
    I hear you on real-time.  While there are a number of applications that dont need real-time, it will be a problem for many others.  All that I can say at present is that we have some thougths on the subject.  In the mean time, a nubmer of our customers are looking at MF on an RTOS as a solution.  

  • Anonymous
    April 27, 2009
    Interesting suggestion.  My question back is: do you want to be able to block APIs at the application level that you are using at the lower levels?   In the porting kit, the Solutions Wizard allows for pulling some unnecessary funcitonality out of the image.  This is primarily to reduce the footprint but could be used to limit the interfaces available to the application.  

  • Anonymous
    April 27, 2009
    Re: the extensiblity of the porting kit.  Yes - there are two kinds of porting tasks.  With the porting kit itself, you are resticted to the supported toolchains.   We recognize that this is not enough for everyone and we are working with a nubmer of silicon vendors on extending our reach. There is also a general solution to this in the works.  

  • Anonymous
    April 27, 2009
    RE - sandboxing Someone on the team pointed out that I probably misinterpreted your comment - That your idea was to run MF on CE to support a more controlled access to underlying funcitonality.  That is in deed an interesting idea and something that could be done with today if there is a need.  

  • Anonymous
    April 30, 2009
    I'm seeing it as an interesting way to run .Net code within linux-based RFID readers, where MONO may not be suitable.

  • Anonymous
    May 04, 2009
    The comment has been removed

  • Anonymous
    May 09, 2009
    I understand that you can remove some functions, like you can do in CE using Platform Builder, but my idea of "sandboxing" is to allow some features but limit their usage. For example you can use the filesystem, but you can access only a specific subtree, or you can draw on the display but only inside a limited area, etc. Hosting the MF inside an application (or at the OS level) may allow this kind of implementations and the MF could be used as a sort of "super-scripting engine" inside application, allowing them to be customized using .NET instead of traditional scripting languages but still keeping the scripting features limited to prevent stability/security issues. Currently you can build the MF in a way that is compatible with CE own binaries? I supposed that using other toolchains would prevent that.

  • Anonymous
    June 03, 2009
    I am wondering - does anybody know where there exists port of the .NET micro framework for Windows CE?

  • Anonymous
    January 06, 2010
    Are there are any updates regarding previous questions pertaining to running Micro Frameworks on top of VxWorks using a PowerPC processor? I would like to understand the suitability of the current MS porting kit to this task, and a rough delineation of the major tasks involved. If there are companies that want to collaborate in this area I would be interested in starting some exploratory dialog. My objective is to leverage the realtime capabilities of VxWorks and our legacy code including TCP/IP, HTTP(s) while adding managed code applications and web services capabilities through Micro Frameworks.

  • Anonymous
    January 06, 2010
    Quinoa, If your PowerPC chip supports Little endian mode AND your VxWorks build does as well, you should be able to do that port with the V4.0 porting kit. If not, you will need to wait. OK, "need" is a bit strong, you could modify the source to support big-endian systems, but that would be a massive amount of work and the .NET MF team has already said they are working on that so why not let them get it done for you! Once Big-endian support is included in the core it should be possible to port to any 32 bit processor.

  • Anonymous
    December 03, 2010
    Please, can you privide us a step by step guide on how to port the .NET Micro Framework on top of Linux for ARM ? Thanks.

  • Anonymous
    December 06, 2010
    Hi Auto,    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".

  • Anonymous
    January 31, 2012
    Hello, Is there a list anywhere of OS's that .NET Micro framework has been ported to ? Thanks

  • Anonymous
    September 17, 2012
       MF全称Microsoft® .NET Micro Framework，是微软推出的一个微型.Net框架，微型到什么程度呢？它自身就可以是一个操作系统OS，它编译出来的程序，就可以直接跑在硬件上，当然，也可以在别的嵌入式系统（如UCOS）上用它，MCU才不管什么操作系统呢，找到第一条指令就开始执行，到哪算哪。有了它，我们就可以直接用VisualStudio C#写嵌入式程序。不过也有几点不足：性能上据说中等，跑图形界面时需要较大内存（MCU内SRAM比较小，一般64K~512K，可以外扩4M），只能用.Net的很少的一部分类库    MF的核心原理就是通过特殊的C#编译器把你写的代码编译成为ARM指令集。它的类库里面可能看不到方法实现，因为那不重要了，反正都是为了编译成为ARM调用指令。    MF也算是一个中间件，跨在C#和硬件之间，所以微软MF团队必须为不同的MCU写不同的MF类库实现，可以看做是Windows上的驱动程序。尽管都是ARM架构，但是ARM也有各种子架构，然后不同公司实现的MCU产品，内部包含的东西也不尽相同，所以得分门别类的实现。这个过程叫做Porting（我们一般说把MF给Port到STM32上去）。    从v4.0开始，微软就把MF开源了（http://netmf.codeplex.com/）。不过默认并不支持STM32，那么就得自己Port了。那可是一项非常庞大的工程。现在最新版本是MF v4.2，里面带有一个STM32的Porting模板，有兴趣的同学可以逐步尝试。    因为.Net Micro Framework功能强大，并且能从C#.Net的PC开发快速进入，它几乎适用于所有嵌入式场合。支持.Net Micro Framework的产品成本，可以低到30元，甚至更低。    经过实际测试发现，.Net Micro Framework固件最小可以达到250k左右，那么在512k的单片机MCU上完全没有问题。比如STM32F103ZET6和VET6就有512k Flash和64k RAM，除了可以烧入.Net Micro Framework固件，还可以写入较复杂的.Net Micro Framework应用程序，而这两种芯片零售价仅20元左右。 Microsoft® .NET Micro Framework简介 newlifex.com/showtopic-53.aspx

  • Anonymous
    September 17, 2012
    可以低到30元（RMB不是US）