Introducing .Net Micro Framework

The first time we heard about the .Net Micro Framework was about a year ago at a conference on embedded technology. At that time, my colleague and I were thinking about a new platform for our embedded development, and therefore decided to take a closer look at .Net Micro Framework. Since then, we have pretty deeply studied this platform. And although not everything is so smooth there, still .Net Micro Framework proved to be very convenient and useful in our work. In this article I will explain why.

Our previous development was based on the uPSD3234 microcontroller. In principle, everything was fine until we ran into a problem familiar to many developers of embedded devices. ST Microelectronics, the manufacturer of microcontrollers, unexpectedly announced that the entire series, which includes our uPSD3234, will be discontinued within six months. It turned out that we had wasted a year of work. I had to look for a new platform. The uPSD3234 architecture is already outdated, and a lot of code has been written, so porting it to a new processor with a different architecture was difficult and pointless. In the end, we decided to make a new device from scratch. I immediately wanted to get such “charms” as OOP and exception handling, because the 21st century is in the yard. And most importantly - as little as possible binding to hardware implementation, to avoid new problems.

And here .Net Micro Framework came into view. The general purpose of this platform is the execution of .Net code on a 32-bit microcontroller without an operating system. Since 2010, Microsoft has made .Net Micro Framework a free open-source project. Before that, they took deductions for use. Currently, the development is based on the Internet community, but under the leadership of Microsoft.

We really liked the idea of ​​writing code for the microcontroller in C # in Visual Studio. The convenient and powerful IDE and managed code promised a lot of advantages: garbage collectors, multithreading, exception handling, OOP, etc. If you want XML - take it, you want Ethernet with TCP / IP - take it, you want an LCD with a touch panel and gesture recognition - take it. And most importantly, the code written for the .Net Micro Framework is not tied to any hardware platform.

But for all the charms you have to pay. Of course, managed code runs a little slower than usual. Of course, because of the metadata, the amount of code increases. All this leads to a rise in the cost of hardware. Well, of course, .Net Micro Framework requires porting if we want to use our hardware platform, which is not so fast. There are ready-made boards, but for mass production they are expensive, and they need to be imported from abroad.

We started the work like this: The




photo in the header of the article is a debug board from Embedded Artists. The .Net Micro Framework port for this board is provided by Microsoft for free, but it was not so easy to launch it. But after the successful launch of the port with the deployment of applications, there were no problems. In the photo, for example, the sample application "Puzzle".

The main problem with porting is extremely scarce documentation. It seems that it says what and how, but after reading it is still little understood.

The entire .Net Micro Framework is divided into several layers: The



two upper layers (user applications and system libraries) are written in managed code. This is what we see in Visual Studio. The hardware layer is the hardware itself. Well, the TinyCLR layer is the code execution environment itself.

TinyCLR is divided into 3 parts:
1) CLR - here everything relates to the execution of managed code, typing, garbage collection, etc.
2) PAL (Platform Abstraction Layer) - Classes and functions for working with general abstractions, such as counters, timers, input-output. These classes are the same for all hardware platforms.
3) HAL (Hardware Abstraction Layer) - Classes and functions of the day of work directly with the "hardware".

Porting is the process of creating a HAL for a particular hardware platform. The code is written in stages, gradually increasing functionality. The main goal is to implement a basic set of functions to run the CLR. The rest of the code is written as needed. Once you understand how and what should work, this process turns into a routine.

As for the port for the Embedded Artists board, we encountered two problems:
1) The code that came in the delivery was for some reason with errors. For example, Baud Rate for UART was not calculated correctly.
2) memory allocation. We spent a lot of time to understand what and where should be flashed. Although this information applies to any other port.

In general, in the end, everything was not so scary. Starting from scratch, we were able, together in a few months, to make a port on our board based on ARM7. The cost of the new board increased by only $ 5 compared to the board based on uPSD3234. We also did not notice performance problems. Of course, there were still some minor difficulties, but they were quickly resolved thanks to communication with .Net Micro Framework developers on the community forum.

Now we have completely transferred our development to .Net Micro Framework. I hope our experience will be useful to someone. If anyone is interested, then I can write several more detailed articles.

Update:
Continued: .NET Micro Framework: Porting Summary