Introduction to the .NET Micro Framework

As I mentioned in an earlier posting I have started to become interested in Microsoft’s latest EMCA Common Language Infrastructure (CIL) implementation, aka the .NET Micro Framework.

The .NET Micro Framework is designed for devices where even the .NET Compact Framework requires too many system resources to be feasible. It’s original design specification was to run on a custom ARM7 ASIC running at 27Mhz with 512KB ROM, 384 KB RAM and 8KB EEPROM, without an form of Operating System.

Operating Environment
One feature that makes the .NET Micro Framework unique is it’s ability to optionally run on hardware directly without the need for a traditional operating system. This is achieved by providing two levels of integration within the porting kit utilised to port the .NET Micro Framework to a new device. An OEM may decide to provide support for the .NET Micro Framework, by hooking in at one of two levels, depending upon the capabilities of their device:

  • Platform Adoption Layer (PAL) – This layer is a high level interface which provides a set of high level primitives such as timers, memory management and data structures. These are typically features provided by a host operating system, leading to a reasonably transparent PAL being developed by the OEM.
  • Hardware Abstraction Layer (HAL) – If no host operating system is in use on the target device, the OEM can utilise a standardised PAL, which hooks into the functionality provided by a hardware abstraction layer. The HAL provides a standardised interface to low level hardware features such as GPIO signals, interrupt handlers and power management etc, which the PAL uses to implement it’s own OS like functionality.

Implementing a Hardware Abstraction Layer can lead to the situation where the .NET Micro Framework is running directly on the CPU as the only “process”.

Compilation Process
Another unique feature of the .NET MIcro Framework, is that it has no Just In Timer (JIT) compiler. The framework instead interperts the MSIL bytecode, in a similiar manor to Mono’s mint interpreter.

Similar to the Java Micro Edition platform, the standard bytecode format utilised on the desktop is not understood by a .NET Micro Framework device. Instead, as part of the compilation process, the bytecode is passed through a pre-verification and optomisation stage, which produces an optimised representation of the bytecode understood by the .NET Micro Framework device.

Hello World – Software Developer style
The traditional first program for a software developer learning a new language or development environment is to write an application which simply prints “Hello World” and then exits. This tradition has it’s roots in an example provided in a book called “The C Programming Language” and was apparently sourced from a 1974 Bell Laboratories internal memorandum written by Brian Kernighan (one of the book’s authors).

Within the Visual Studio 2005 environment for the .NET Micro Framework, a Hello World application may be written as follows:

using Microsoft.SPOT;
 
namespace HelloWorldApplication
{
  public class Program
  {
    public static void Main()
    {
      Debug.Print("Hello World!");
    }
  }
}

The Microsoft.Spot.Debug class is somewhat similiar to the System.Diagnostics.Debug class present in the full framework in its intent.

The Debug.Print method can be utilised to emit a string to the standard output stream, which by default is routed to the Visual Studio IDE from the development board while debugging an application.

This code sample is fairly similiar to that produced by the Micro Framework Console Application project wizard within Visual Studio 2005. The main difference being that the project wizard emits code which utilises a string resource to store the string, this aids in internationalisation of the application.

Hello World – Hardware Engineer style
The equvialent to a “Hello World” application for a hardware engineer bringing up a new microprocessor based board is to flash a LED connected to a GPIO pin.

using System.Threading;
using Microsoft.SPOT.Hardware;
 
namespace HelloWorldApplication
{
  public class Program
  {
    public static void Main()
    {
      // The LED is hooked up to GPIO Pin 1. The second parameter
      // within the constructor indicates to set the pin to logic high
      // initially
      OutputPort led = new OutputPort(Cpu.Pin.GPIO_Pin1, true);
 
      while (true)
      {
        // Sleep for 5 seconds (5000 ms)
        Thread.Sleep(5000);
 
        // Toggle the state of the LED
        led.Write(!led.Read());
      }
    }
  }
}

NOTICE: If you attempt to run this sample application on actual hardware, you may need to alter the GPIO Pin assignment to suit your hardware, and add a reference to a device specific assembly.

The Microsoft.Spot.Hardware.OutputPort class accesses a specified pin on the physical hardware and can toggle the pin between the high and low logic levels.

The Read() method queries the pin for it’s current state, while the Write(bool) method allows the user to explicitly set the pin’s current state. For those familiar with traditional Micro-controller firmware development, you will notice that the hardware is accessed in an abstracted sense, where all the bit twiddling typically required to set or reset a single GPIO pin is hidden behind the scenes. This makes for a nice portable application, but is not suitable in applications which need precise real time functionality etc.

Trivia
I initially wondered why the .NET Micro Framework related classes were in namespaces starting with Microsoft.SPOT. SPOT which is an acronym for “Smart Personal Object Technology”, was the Microsoft Research project which initially produced the technology that became the .NET Micro Framework. The Microsoft SPOT group developed a range of devices, with the most well known probably being the smart watch.

One of the proof of concepts the research team produced was a tiny CLR to allow a managed software development environment for their projects. They named the initial namespaces after their group, since this was a technology for internal use only. When it was decided to commercialise the .NET Micro Framework as a seperate product, they decided to keep the namespaces, since a number of internal and external projects were already using them and it helped with backwards compatibility.

I also assume this is why what appears to be the first publically available version of the .NET Micro Framework is versioned as version 2.

One Response to “Introduction to the .NET Micro Framework”

  1. I just found the following website which is quiet an interesting high level (consumer orientated) overview of the Microsoft SPOT enabled products -http://www.msndirect.com/

Leave a Reply