Introduction to .Net Micro Framework

The first time we heard about the .Net Micro Framework about a year ago at a conference on embedded technologies. At that time, my colleague and I were pondering on the topic of a new platform for our embedded development, and therefore we decided to look more closely at the .Net Micro Framework. Since then, we have studied this platform fairly deeply. And although not everything is so smooth there, the .Net Micro Framework platform turned out to be very convenient and useful in our work. In this article I will tell why.



Our previous development was based on the uPSD3234 microcontroller. In principle, everything was fine until we encountered a problem familiar to many developers of embedded devices. ST Microelectronics, a manufacturer of microcontrollers, unexpectedly declared that the entire series, which includes our uPSD3234, will be discontinued within six months. It turned out that we had spent a year of work in vain. I had to look for a new platform. The uPSD3234 architecture is already rather outdated, and a lot of code has been written, so transferring 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. Immediately I wanted to get such "charms" as the PLO and exception handling, because the XXI century is in the yard. And most importantly - as little as possible binding to the hardware implementation, to avoid new problems.



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

')

We really liked the idea of ​​writing code for a C # microcontroller in Visual Studio. A convenient and powerful IDE and managed code promised a lot of advantages: garbage collectors, multithreading, exception handling, OOP, etc. 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 higher hardware costs. And of course, the .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 work like this:









The photo in the header of this 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 start 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 poor documentation. There seems to be written what and how, but after reading it is still not enough that is clear.



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







The top two layers (user applications and system libraries) are written in manageable 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 concerns the execution of managed code, typing, garbage collection, etc.

2) PAL (Platform Abstraction Layer) - Classes and functions for working with common 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 working directly with the "iron".



Porting is the process of creating a HAL for a specific hardware platform. The code is written in stages, gradually increasing the functionality. The main goal is to implement a basic set of functions for running 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, we faced two problems:

1) The code that came in the delivery was for some reason with errors. For example, the Baud Rate for the UART was not calculated correctly.

2) Memory allocation. We spent a lot of time to understand what and where should be stitched. 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 to our ARM7-based board. The cost of the new board increased by only $ 5 compared to the uPSD3234 base. We also did not notice any performance problems. Of course, there were still some minor difficulties, but they were quickly resolved by communicating with the .Net Micro Framework developers in the community forum.



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



Update:

Continued: .NET Micro Framework: Porting in Brief