The scenario:

You’ve been assigned the task of designing and producing an embedded device. You’ve been given time, cost and size constraints that impact your design. An initial analysis of the requirements leads you to the conclusion that a 32-bit processor with a relatively small amount of RAM and Flash are required. A bit of research shows that an ARM processor with 2MB of external Flash and 2MB of external RAM will meet your cost and size constraints.

Historically, you would select a SoC or a processor, memory components, and other required peripherals and design a system around them. This system would require a certain amount of low level coding to initialize it and get it ready to accept an application; that coding may be developed in a higher level language, such as C or C++.

Another option that is becoming more and more popular is an embedded module, such as the Digi ConnectME or the EmbeddedFusion Meridian. Although a bit costlier, these modules come with RAM, Flash, and a host of other peripherals. An advantage of these modules is they make PCB design easier, and typically come with an embedded OS, giving you immediate access to an API for your application. The net effect is your hardware design time is shortened and you only have to code in higher level languages, such as C or C++.

Application development is influenced by two primary factors, platform development environment, and language. There are many development platforms available, two of the most popular being Microsoft Visual Studio and the Open Source Eclipse platform. The most common programming languages for embedded development are C, C++, and Managed Code (Microsoft .NET and JAVA).

C is a low level language that gives the developer full control over the hardware, but at a price. It is not object orientated, there are few provisions for code re-use, and there are no built-in protections against common programming errors, such as null pointers, memory leaks, or bad assignments (= instead of == for example).

C++ is an improvement over C, being object oriented and promoting better code sharing and re-use, but it still has the drawback of letting a developer do things unwittingly that they really should not do, resulting in unexpected behavior. Application robustness is typically a function of how much pre-release testing you can afford.

Managed code raises the bar. Most programming errors and many of the programming tasks required by an application are common among all applications. This provides an opportunity for a managed code platform that provides a rich feature set comprised of these common requirements, and a chance to put in protection mechanisms that guard against these common mistakes. Historically, limits on processor speed and memory size have blocked the adoption of these managed code platforms for small embedded device development. Although available to the desktop development community for years, embedded developers have not been able to enjoy the advantages of these advanced platforms.

Recent increases in processor sizes and speeds, and declines in processor and memory costs make it possible to move these advantages into the embedded development space.

For years, application developers have realized the advantages of the Microsoft .NET platform. Because of the rich set of libraries and the protected managed programming environment, application development and test cycles are significantly reduced.

Today these same advantages are available to embedded application developers in three distinct offerings:

  • For large embedded devices that are not generally resource constrained, Microsoft Windows XP and the .NET framework are available, weighing in at around a 200MB footprint
  • For small devices, such as PDAs, Smart Phones, Navigation systems, there is Windows CE and the Compact Framework, with a footprint around 12MB
  • For smaller, more resource constrained embedded devices, Microsoft introduced the .NET Micro Framework, weighing in with a footprint of less than 0.5MB or 500KB.

The remainder of this article discusses this third offering, Microsoft’s newest, the .NET Micro Framework.

.NET Micro Framework

The .NET Micro Framework got its start as a Microsoft Research project to provide a managed runtime in the Smart Personal Objects Technology (SPOT). One SPOT initiative was called AuxDisplay, which evolved into “SideShow”, the external display devices found on newer Windows Vista equipped laptop computers. Early successes with this managed runtime platform indicated the value of the platform in extending the Microsoft embedded solutions offerings. The platform was re-labeled the “.NET Micro Framework,” and was launched publicly at Embedded World in February 2007.

The goals of the platform were

  • Size: The .NET Micro Framework platform had to fit into and run on a minimum amount of Flash and RAM. Because of the direction of the embedded industry towards 32 bit processors, it was determined the .NET Micro Framework would require a 32 bit processor. In the 32 bit processor environment, 1MB – 2MB of flash memory are typically considered “small.” The.NET Micro Framework goal of size was realized by fitting the platform and runtime into less than 0.5MB of flash memory.
  • Managed execution environment: The core of the .NET Micro Framework is a Common Language Runtime (CLR). All application execution is owned, managed, and controlled by the CLR. Unlike .NET on Windows XP or Compact Framework on Windows CE, the .NET Micro Framework does not require a hosting operating system.
  • Consistent tool chain experience: Code development and debugging in Visual Studio, replicating the development experience found on the desktop and in larger embedded device development.
  • A consistent .NET development experience. Where applicable, .NET Micro Framework classes and methods have the same signature as those found on the desktop.

Additionally, the platform had some non-goals

  • Real Time: Because the platform is a managed environment, and there is an automatic garbage collector that reclaims unused memory, it is not possible to have a determinant system. The garbage collector can fire at any time and has a high priority, so there is no way to guarantee a fixed interval response to some event. That being said, the Micro Framework is fast enough for all but the most stringent real time requirements.
  • Direct access to the hardware: The Micro Framework provides a managed application execution environment. In order to manage the environment, it is important that the platform is the only thing that can modify hardware resources. All memory modification requests, and peripheral accesses, and any other hardware access must go through the platform. Managed Application access to hardware or peripherals is accomplished through managed drivers.
  • Extreme performance: If your product is using a processor that is barely capable of meeting your requirements in terms of speed, then it probably is not a good Micro Framework candidate. The Micro Framework provides a managed, interpreted environment. This management injects some system overhead that will have performance impact when compared to a non-managed environment.
  • 100% parity with the Desktop .NET framework: The Micro Framework is a subset of the .NET Framework. In order to keep the size as small as possible, a number of design decisions were made. .NET assemblies that do not make sense in the very small embedded device space were not included in the Micro Framework. Some assemblies that were ported were trimmed down to minimize their foot print. Some of this trimming can cause behavior that is unexpected. For example, Since “ABCD” == “ABCD” works as expected when comparing two strings, it was decided to not implement the String.Equals() method. The following line: String.Equals(“ABCD”,”ABCD”) would return false because what you are really calling is Object.Equals() and although the strings are the same, the objects containing them are not. There are also assemblies added to add functionality not applicable to the desktop, such as classes to manage GPOI pins, or SPI and I2C busses.

Using the .NET Micro Framework

There are 3 ways to develop hardware that uses the Micro Framework:

  1. The easiest and quickest way is to select a processor component that has had the Micro Framework ported to it. This is the turnkey solution that has all the processor initialization code already done for you. The advantages of this approach are a simpler PCB layout, and only managed code development in Visual Studio. You never have to use a different development environment. There are several off–the-shelf components available and links to them can be found on the Microsoft .NET Micro Framework web site.
  2. A second alternative is to develop your design based on a reference design that has had the Micro Framework ported to it. This is similar to #1, but you have a bit more control over the layout and peripherals.
  3. Port the Micro Framework to your hardware. This is the most flexible option, but it is also the most complicated. In addition to doing the system initialization yourself, you would be responsible for developing the Micro Framework HAL that interfaces the Micro Framework to your hardware. The good news, should you select this option, is Microsoft has trained a number of porting partners, who are available should you need their services.

Additional Advantages

Hardware Abstraction: The virtual machine abstracts the hardware from the application. Any changes to the hardware are localized, and are more easily managed without destabilizing the entire application.

Extensible Emulator: With the Micro Framework, you are provided a fully extensible emulator. This emulator allows you to write an extension to fully emulate your hardware, giving you the opportunity to fully develop, test and debug your embedded application – without having the hardware! There are three primary pieces involved:

  1. Your Micro Framework application that will ultimately run on your device
  2. The Emulator Engine, included with the Micro Framework SDK
  3. A Windows Desktop application (Winform Application) that represents your device. This application can be as simple or as elaborate as you like. This application can have winform buttons that represent physical buttons or switches on your device, a text box or picture box representing an LCD display, radial buttons representing LEDs, etc. Using common controls it is easy to represent SPI, COMM, I2C, or any other busses, peripherals, or components on your device.

There is a small amount of XML that you write in order to tell the emulator engine what hardware component is represented by what windows application component. Creating emulator extensions is documented in the Micro Framework SDK.

Debugging: With the Micro Framework, your development and debugging environment is Visual Studio. Using Visual Studio, you deploy code to your device, and can debug that code while it is running on the device. The Micro Framework supports TCPIP, USB, and Serial (COMM) connections to your device.


The .NET Micro Framework gives you the option of developing your embedded applications in a managed environment. This managed environment, along with available off-the-shelf components provides you with tools that will help give you exceptionally short development cycles. Your development cycle can be further shortened by using the Micro Frameworks’ extensible emulator for you application development in parallel with your hardware development. An added benefit of this parallel development approach is it allows you to validate your hardware architecture much earlier in the development cycle, where changes are still relatively inexpensive.

This article was written by Jim Mateer, Program Manager for the .NET Micro Framework for Microsoft (Redmond, WA). For more information, contact Mr. Mateer at This email address is being protected from spambots. You need JavaScript enabled to view it. , or visit http://info.hotims.com/10974-440.