Changing the embedded programming paradigm - designing small connected devices with .NET Micro Framework

by Torsten Katschinsky, Field Applications Engineer, Future Electronics (Germany)

READ THIS TO FIND OUT ABOUT: Utilising code re-use with .NET Micro Framework. The productivity benefits of managed code in embedded applications.

Traditionally, embedded products have been resource-constrained, stand-alone devices. In this world, every design project was a discrete event, and there was no benefit to be gained from sharing code across multiple projects. Torsten Katschinsky, Field Applications Engineer, Future Electronics (Germany) explains.

For certain embedded developers, the traditional model is becoming outdated. Embedded devices are often now connected in various ways, and families of devices are expected to interoperate and share certain functions. For instance, a handheld medical diagnostic device might share data storage and communications functions and protocols, as well as peripheral device drivers, with fixed equivalents and with a central server. There might also be several variants of each device.

This is a new world for the embedded developer. Time-to-market and developer productivity are crucial. Code re-use across multiple devices, therefore, becomes absolutely essential. Yet while developers in the computing world can use C – a high-level programming language which can be used over a wide range of platforms - in the embedded world designers have to struggle with device drivers for on-chip peripherals, and stack support for Ethernet and USB, that are different on every hardware platform.

Microsoft’s .NET Micro Framework (.NET MF) provides a solution to this problem. .NET MF offers a small, efficient implementation of the computing world’s .NET runtime, and is thus aimed at smaller devices (see Figure 1). Indeed, .NET MF's small memory footprint, of around 300kB, means that it can often run on a device’s on-chip memory.

Using this framework, the engineer can write hardware-independent application code in the form of managed code in an objectorientated environment. At the same time, by using .NET MF an OEM gains access to the world’s largest pool of application developers.

Another advantage of .NET MF is that engineers can stay in the same Microsoft tool chain from server level to the smallest devices. In fact, it helps to reduce development cost and timeto- market across a whole family of end products through:

• code re-use with other parts of the solution
• the use of a higher-level language, normally C#
• compliance with .Net Framework and .NET Compact Framework

In terms of target hardware platforms, ARM7 and ARM9 are supported by .NET MF now. Support for ARM Cortex is in development, and XScale devices will be able to run .NET MF later in 2008.

Developers who want to start using .NET MF should consider the i.MXS development kit from Freescale Semiconductor. The kit, which features the ARM920T-based i.MXS applications processor, is approved by Microsoft for use with .NET MF. It includes a 2.5-inch colour LCD panel, a USB interface and an expansion socket for Bluetooth and other modules.

It must be noted that if an application needs hard realtime capability, .NET MF is not the right choice. Real-time applications require a specialist embedded RTOS, Windows CE or a version of Linux with real-time performance such as that provided by MontaVista Software.

 

 

The .NET difference: object-based representation of hardware

Microsoft’s .NET family of products introduces an approach that will be unfamiliar to most embedded engineers. So what are the most noticeable differences?

One crucial aspect of .NET MF is that it lets the developer work in the MS Visual Studio 2007 environment. .NET MF itself can be downloaded free of charge from the Microsoft website. Once installed, .NET MF support can be found in Visual Studio, including an emulator. Thus, developers coming from the .NET computing arena will use the same tool for embedded programming with .NET MF. This includes the powerful GUI, editor, class browser and debugger.

It is not only the tool environment that will be different. Every embedded software designer knows how to implement a bit manipulation on a GPIO port. For example, to read a certain bit from a GPIO port, the designer has to read the GPIO data register, mask the corresponding bit, and test whether the bit’s value is 0 or 1.

In .NET MF, hardware is treated completely differently. The hardware is represented as objects, removing the need to create bit masks in order to implement functions. Instead, an instance of an object is created to set or get a certain property.

As an example, consider a GPIO object. .NET MF offers two objects for implementing an input or output port. When creating an instance of this object, some parameters have to be set, such as the pin to use as Cpu.Pin type, a Boolean value indicating whether or not a glitch filter on this signal should be used, and the resistor mode configuration for input ports defined as PullUp, PullDown or None. A class member method (Read or Write) will allow writing to and reading from the configured GPIO pin.

For example, consider switching an LED connected to Pin 1 on or off depending on the position of a switch connected to Pin 2. When creating the port object instance, .NET MF will connect this to the correct underlying device. The value of the .NET approach to development is that this class will work on any device.

The simplest method for setting the LED is to poll the appropriate port, but in embedded applications, the most efficient technique for setting the LED would often be to use interrupts to monitor the status of the external switch. In .NET MF this is a remarkably easy task.

In the code example shown (see Figure 2), an InterruptPort and a parameter indicating the trigger mode is created. This is identical to the process for enabling an interrupt source in conventional programming.

Now, in order to connect the interrupt port to the corresponding handler, an understanding of the .NET MF concept of delegates is required. A delegate is a reference to a method in an instance of a class. An event-object in .NET MF contains a list to which this delegate instance can be added. When this event occurs the delegate knows the method to call.

Back to the InterruptPort: this object implements the event handler OnInterrupt that maintains a list of delegates that are bound to its event, in this case, the port pin interrupt. The only requirement is to add the delegate to this handler.

Porting to a different hardware target involves nothing more than a global change to the definition of mSwitchPin and mLEDPin to new values. In other words, apart from the pin selection for the switch input and the LED, all the code will be the same for any hardware target.

The engineer does not need to deal with bits, hardware settings or interrupt vectors; all of this is hidden by .NET MF. The treatment of serial interfaces is just as simple.

 

 

For the sake of clarity, the code example (see Figure 2) illustrates a simple function. However, the principle of object-oriented programming implemented in C# applies just as much to real applications that use advanced features in .NET MF such as threading and synchronisation.

 

.NET MF gives engineers the freedom to work with Visual Studio, the professional and powerful tool that developers writing PC, PDA and smartphone applications use.

By writing managed code, every application can be made almost totally independent of any hardware target. Porting an application from one hardware platform to another involves just two simple changes: to the target settings, and to the transport interface that deploys the managed code to the target device.

Further, the integrated emulator in Visual Studio means that the developer can begin writing code before the target hardware is complete, which promises to dramatically cut product development time.

In the past, there was perhaps some justification to the embedded world’s resistance to development models and OSs derived from the computing world. But in .NET MF, Microsoft has delivered a true smallfootprint runtime that meets the dauntingly high standards of stability required by embedded applications.

The productivity benefits to be gained from the use of managed code, the power of Visual Studio and the access it gives to a vast universe of Microsoft application developers all help to make a compelling case for .NET MF in embedded applications. Finally, Microsoft appears to have a product that will make inroads into the true embedded market.