Look, Ma! No RTOS! Getting to Know Microsoft .NET Micro Framework

Wouldn’t it be nice to have an off-the-shelf platform that was ready to be programmed with your custom application? No need to spend a big budget to develop the hardware and adapt firmware from some OS vendor, where documentation and support is lacking in both areas. Maybe simply control some I/O and send information to a screen or over a serial connection. Best of all, wouldn’t it be nice to write the application using tools that you already have and in a known programming language? Well, this is the concept behind the Microsoft .NET Micro Framework. Program using C# in Visual Studio and download your application to a device that already has the firmware running on a feature-rich system running a 32-bit RISC processor.

Microsoft’s latest offering for embedded developers, the Microsoft .NET Micro Framework (.NET MF), addresses the needs of smart, small-footprint devices for such applications as robotics, security systems and simple interfaces. Built from the ground up, .NET MF exposes hardware like GPIO, I2C, SPI, Serial, etc. and allows developers to write C# applications in Visual Studio to access that hardware directly. The footprint is about 1 Mbyte so it is much smaller than Windows CE. As with any new technology, there are always a number of questions.

What is .NET Micro Framework?

The .NET Micro Framework consists of a TinyCLR that allows developers to write managed code (C#) applications in Visual Studio. CLR means Common Language Runtime. The CLR is an agent that manages code at execution time, providing core services such as memory management, thread management, exception handling and debug services, while also enforcing strict type safety and other forms of code accuracy that promote application security and robustness.

The TinyCLR is a smaller footprint implementation of the full CLR used in .NET Framework or the CompactFramework. For .NET MF, the TinyCLR sits directly on top of a Hardware Abstraction Layer (HAL), which makes it possible to port .NET MF to different processors. Currently, it supports ARM7 and ARM9 processors. .NET MF has been ported to the Cirrus Logic 93XX series, FreeScale i.MXS, Atmel AT91SAM9 and the NXP LPC2000. .NET MF consists of four layers: Application, Class Library, Runtime Component and Hardware (Figure 1).

Application Layer: The top layer simply consists of the managed application you write in Visual Studio. These applications are specific to the hardware that you are writing them for. Even though Visual Studio and .NET support different languages, C# is the only language currently available to write .NET MF managed code applications.

Class Library Layer: The class libraries are the re-usable objects that you can use when writing applications. Communication libraries, I/O access, storage and support for Windows Presentation Foundation are available.

TinyCLR: This layer consists of three components. The TinyCLR is the interpretive engine that handles all the processing of the applications. The HAL and the PAL control the underlying system hardware. Both the HAL and the PAL are groups of C++ / assembly functions called by the CLR. The HAL is the component that can be modified to support different processors and different hardware configurations. It contains some bootstrap code, as well as the drivers that make up the system. The HAL can also be adapted so .NET MF can run on different hardware platforms or on an operating system.

Hardware Layer: The hardware layer contains the microprocessor and the microprocessor support and I/O devices. Currently, .NET Micro Framework only runs on ARM7 and ARM9 RISC processors. There is also an independent boot loader known as TinyBooter that loads the TinyCLR into memory. Although the TinyCLR can be booted directly, the TinyBooter is used so that it can also update the TinyCLR code, when desired.

How Does This All Work?

Probably the first question that most designers will ask is, “What is the processing architecture?” First of all, the .NET Micro Framework is NOT a real-time kernel or OS. Windows CE is Microsoft’s real-time embedded operating system. The TinyCLR is not deterministic, and interrupts are currently not preemptive.

.NET MF is really an embedded CLR or managed code engine. Only a single application can run at a time, but the application supports multiple threads. The .NET MF has a scheduler that manages priorities, time slices and interrupt routines. Threads at the same priority run in a round robin with 20 millisecond time slices. The time slice interval cannot be changed. Interrupts are not preemptive, but an interrupt routine activated by an outside event will run after the currently running process has completed its 20 ms time slice or if the process has gone to sleep.

For application development, the developer needs Visual Studio 2005 and the .NET Micro Framework SDK. The SDK provides an emulator to test applications, but most developers will want to get started on real hardware.

There are several board vendors and IC manufacturers that offer generic development platforms. For example, SJJ’s EDK supports EMAC’s iPac-9302, which is a production-ready platform that has the .NET Micro Framework onboard. All the developer has to do is write a C# application in Visual Studio and download it to the board. The .NET MF stores the application in flash. When the .NET MF boots, it either finds an application in flash to run, or it waits for a new download. The developer can continue to download different test applications, which will overwrite any previous application in flash.

Developing a .NET MF application in Visual Studio is no different than any other application development. The application can be remotely debugged using the Visual Studio Debugger while it is running on the hardware. Multiple break points can be set, variables can be set in the watch, and you can step line-by-line through the application.

.NET MF applications can directly control I/O like SPI, GPIO, I2S, I2C and LCD output. Because it is .NET and most of the code is based on predefined classes, the number of lines of code are few compared to other solutions, which require developing the whole OS and device drivers plus the application.

As you can guess .NET MF development is like the popular Basic Stamp or Java Stamp solutions, but instead of running on simple PIC processors, .NET MF runs on high-speed ARM7 or ARM9 processors with faster code execution and a wealth of I/O to address most applications. Even though .NET MF doesn’t feature real-time, deterministic capability, its performance is fast enough for many small embedded systems. Many education and research facilities are using off-the-shelf .NET MF platforms to quickly prototype systems for testing because traditional porting of the embedded OS takes too much time.

If you want to build your own board, then you will either have to get the .NET MF porting kit from Microsoft to port the TinyCLR to the hardware or have one of the .NET Micro Framework porting partners perform the port. The porting process is like any low-level embedded development. The startup code has to be developed, the device drivers have to be created, etc., but once the port has been completed, application development comes right back to Visual Studio. A full .NET MF built from scratch still uses the standard two-path development process: Use a .NET MF development board to start on the application development, while the custom hardware and port are being completed.

Besides the low-level I/O support, .NET MF has graphical support based on the new Windows Presentation Foundation (WPF) architecture found in Windows Vista. Developers can create a rich graphical interface using WPF.

SideShow devices are the most common .NET MF platform to support graphics. SideShow is a defined platform and application that runs on top of .NET MF. An LCD and a few buttons for navigation are needed to run SideShow. Figure 3 is the SideShow Device Simulator used for testing applications and gadgets. The layout of the simulator is very similar to various embedded controller interfaces. Although touch screen support is not currently supported, it is possible to create a custom solution or overlay.

What Is Supported Now and in the Future?

We mentioned earlier that .NET MF exposes GPIO, I2C, SPI, Serial, etc. These I/O are the core for the first release of .NET MF. Other I/O like ADC and PWM can be custom added by OEMs and exposed as virtual COM ports interfaces.

Probably the most important addition is networking support. For .NET MF to be truly considered for embedded devices, TCP/IP support has recently been added. .NET MF devices can communicate over the network using simple socket communications. A socket server and client are provided in the SDK. There is also support for Devices Profile for Web Services (DWPS). Simply put, a .NET MF platform running a Web service (DPWS) application can be easily detected/discovered by a PC, which invokes the Web service functionality each device provides.

There are already a few commercial devices that use the .NET Micro Framework technology such as the SPOT/Smart watch and the Windows Vista SideShow display. There also already are a few remote control solutions using .NET MF and SideShow. Beyond these applications, .NET Micro Framework serves as an appropriate platform for deeply embedded applications where smart control is needed. Interface for exercise equipment, home theater control, basic robotic controls, inexpensive software solution for pin pads, pallet tracking systems, industrial control interfaces/communication, security systems and environmental controls are just a few of the applications for which .NET MF can provide the right support.

Windows CE and Windows XP Embedded have addressed the needs for many high-end embedded systems. There are many low-end devices that are becoming smarter and friendly to use. .NET Micro Framework offers the right features, functionality and development tool support to address these smart solutions.

SJJ Embedded Micro Solutions
San Diego, CA.
(858) 485-1059.