June 6, 2011 at 10:22.NET Micro Framework: Porting at a Glance
The previous article aroused some interest. Many different questions were asked, but most of them concerned porting. This topic deserves a separate full-fledged book and it is not easy to briefly cover it. But I'll try.
For people who decide to do porting, Microsoft provides a special tool: .Net Micro Framework Porting Kit . It is a collection of source codes and configuration files from which the CLR can be compiled. The build system is based on MSBuild. Currently, compilation is started only from the command line. Virtually no graphics are provided. The only exception is the SolutionWizard utility, which allows you to configure port projects. There is also no support for development environments. Roughly speaking, ports are written almost in a notebook. But in the near future the situation should change for the better.
Before talking about porting, it’s very important to understand how the .Net Micro Framework works internally. In a previous article, I briefly talked about the architecture .Net Micro Framework, then I will consider it in more detail. The documentation for the .Net Micro Framework Porting Kit has this picture:
This is a 4-layer .Net Micro Framework architecture. The same documentation says (in my free translation) the following:
This layer contains the microprocessor and other components that make up your hardware platform. Currently, the .NET Micro Framework can be run on processors of architectures such as ARM7, ARM9, Cortex, XScale, ARC, and ADI Blackfin.
In addition, it is possible to run .Net Micro Framework on top of the operating system. Of course, in this case, the “iron” does not disappear anywhere. Just interaction with the hardware will occur through the operating system API. This is how the emulator included with the .NET Micro Framework Platform SDK works . It is nothing more than the .NET Micro Framework for Windows port.
This layer consists of 3 components:
• .NET Micro Framework common language runtime (CLR);
• Hardware abstraction layer (HAL);
• Platform abstraction layer (PAL).
The .NET Micro Framework CLR runtime (TinyCLR) is a subset of the .NET Framework CLR. TinyCLR differs from the “large” CLR in that it has been specially redesigned for use in small embedded devices.
The .Net Micro Framework Porting Kit comes with the TinyCLR source code. These codes are a hardware-independent library that can be compiled by different compilers for different architectures.
TinyCLR interacts with the underlying hardware through HAL and PAL. Both HAL and PAL consist of a set of functions called from TinyCLR. These functions are written in C ++. It is clear that the functions of HAL are very closely related to the hardware. Functions included in PAL, on the contrary, are designed so as not to depend on the hardware implementation.
Many HAL and PAL functions form pairs. They are used together to perform a specific task. TinyCLR calls the PAL function, which in turn uses the HAL function to access the hardware.
In addition, the so-called Bootstrap code is included in the HAL. After powering up, this code initializes the hardware and then launches TinyCLR.
TinyCLR continues to download and is engaged in high-level initialization. Bootstrap code performs its tasks using functions from the HAL and special assembler inserts.
The .NET Micro Class Class Library is an object-oriented collection of types that developers use when writing embedded applications. This may include third-party types. For example, developers of debug boards add classes for working with peripheral devices located on these boards.
This level contains the applications that you create for your devices. To date, the only development language for such applications is C #.
Thus, the main task of porting is to write functions and configurations of the HAL level. Now let's see how this is done.
Each port within the .Net Micro Framework Porting Kit represents a Solution. Solution, in turn, consists of several Projects. There are 5 types of Projects in total:
• NativeSample
• PortBooter
• TinyBooter
• TinyBooterDecompressor
• TinyCLR
NativeSample is a simple “Hello, World” project. The main task in its implementation is to write enough HAL functions to display the string "Hello, World" in the debug console.
Portbooter- port loader. It allows you to flash new versions of TinyCLR during the development and debugging of the port. The implementation of this project requires the addition of new HAL functions to those already written for NativeSample. This is a transitional project to prepare for the implementation of the following projects.
TinyBooter is the .NET Micro Framework bootloader. At the moment of power-up, it performs all the necessary initialization and starts TinyCLR. In addition, it allows you to flash new versions of TinyCLR. During the implementation of this project, several new features are added to the HAL.
TinyBooterDecompressor is a special add-in designed to minimize the physical size of TinyBooter. TinyBooter is stored in an archived form and when it is turned on, it is unpacked and loaded using TinyBooterDecompressor.
TinyCLR is, in fact, the runtime itself. Getting a functioning TinyCLR is the goal of porting. In the process of working on this project, the remaining HAL functions are added. TinyCLR includes TinyBooter.
Thus, by implementing these projects in turn, you create a HAL layer.
Creating a new Solution begins with the SolutionWizard. This utility allows you to create a Solution from scratch, make a new Solution on the basis of the existing one (clone) and edit the existing one.
In the process, SolutionWizard allows you to select the so-called Features that will be included in the Solution. Features are the functional properties of .Net Micro Framework. For example, there are Features such as I2C, UART, SD, etc. Thus, if you do not need some .Net Micro Framework features, then you can simply not include them in the project, thereby reducing the physical size of TinyCLR.
Each Feature is implemented by a set of Libraries , which are combined intoLibrary Categories . Library is a separate MSBuild project that implements its task. Actually, Library and include the source code. Since there may be many implementations of the same task (for example, for different processors), there may also be many Library . That is why they are combined into Library Categories . The default implementation of the Library Category is stub Library . This is such a Library, in which place all functions are stubs. It does not carry any functions and is needed only to ensure the operation of the linker, even if there is not a single normal implementation. All of these components can refer to each other.
Thus, the following link is obtained:
Feature -> Set of Library Categories -> One of the Library that implements each category.
Understanding this “mess” is not easy. To at least somehow make it clear, let's look at this picture:
At first glance, it does not become clearer. Let's try to figure it out.
Here's the implementation of Feature I2C. Feature are yellow, Library Category are green, Library- blue, and the Stub Library - black. Also on the diagram there are the following types of relationships:
• Depend - depends on;
• Associate - associated with;
• Realise - implements;
• Stub - Library with stubs.
You can see from this picture that Feature I2C is implemented by three Library Categories: I2C_CLR, I2C_PAL, I2C_HAL. In addition, it still depends on another Feature Hardware. Each Library Category corresponds to one of the levels in the Runtime Component Layer .
Category I2C_CLR is implemented by the Library I2C and I2C_Stub. Category I2C_PAL implemented by LibraryI2C_pal and I2C_pal_stubs. The most interesting thing we see in the implementation of I2C_HAL. Here, in addition to stub Library , there are 5 more libraries for different processors.
So, for each Library Category associated with the Feature selected earlier , SolutionWizard allows you to select one Library . You can choose one of the existing ones, select stub if it is not needed at the moment, or you can generate a template for the new Library .
Since the number of Library Categoryabout a hundred, then the majority of the choice SolutionWizard takes upon itself. However, you can adjust this choice. In addition, you can choose the projects that will be included in the Solution.
The result of the SolutionWizard is either a new Solution, or changes to an existing Solution.
Next, code writing and compilation begin directly.
I reviewed the most common concepts and principles for creating .Net Micro Framework ports. Then begin the particulars that are beyond the scope of this article. For example, working with MSBuild, memory allocation, implementation features of specific functions, etc. I will write about this to everyone in the following articles.
1. Introduction
For people who decide to do porting, Microsoft provides a special tool: .Net Micro Framework Porting Kit . It is a collection of source codes and configuration files from which the CLR can be compiled. The build system is based on MSBuild. Currently, compilation is started only from the command line. Virtually no graphics are provided. The only exception is the SolutionWizard utility, which allows you to configure port projects. There is also no support for development environments. Roughly speaking, ports are written almost in a notebook. But in the near future the situation should change for the better.
2. .NET Micro Framework Architecture
Before talking about porting, it’s very important to understand how the .Net Micro Framework works internally. In a previous article, I briefly talked about the architecture .Net Micro Framework, then I will consider it in more detail. The documentation for the .Net Micro Framework Porting Kit has this picture:
This is a 4-layer .Net Micro Framework architecture. The same documentation says (in my free translation) the following:
Hardware layer
This layer contains the microprocessor and other components that make up your hardware platform. Currently, the .NET Micro Framework can be run on processors of architectures such as ARM7, ARM9, Cortex, XScale, ARC, and ADI Blackfin.
In addition, it is possible to run .Net Micro Framework on top of the operating system. Of course, in this case, the “iron” does not disappear anywhere. Just interaction with the hardware will occur through the operating system API. This is how the emulator included with the .NET Micro Framework Platform SDK works . It is nothing more than the .NET Micro Framework for Windows port.
Runtime component base
This layer consists of 3 components:
• .NET Micro Framework common language runtime (CLR);
• Hardware abstraction layer (HAL);
• Platform abstraction layer (PAL).
CLR
The .NET Micro Framework CLR runtime (TinyCLR) is a subset of the .NET Framework CLR. TinyCLR differs from the “large” CLR in that it has been specially redesigned for use in small embedded devices.
The .Net Micro Framework Porting Kit comes with the TinyCLR source code. These codes are a hardware-independent library that can be compiled by different compilers for different architectures.
HAL and PAL
TinyCLR interacts with the underlying hardware through HAL and PAL. Both HAL and PAL consist of a set of functions called from TinyCLR. These functions are written in C ++. It is clear that the functions of HAL are very closely related to the hardware. Functions included in PAL, on the contrary, are designed so as not to depend on the hardware implementation.
Many HAL and PAL functions form pairs. They are used together to perform a specific task. TinyCLR calls the PAL function, which in turn uses the HAL function to access the hardware.
In addition, the so-called Bootstrap code is included in the HAL. After powering up, this code initializes the hardware and then launches TinyCLR.
TinyCLR continues to download and is engaged in high-level initialization. Bootstrap code performs its tasks using functions from the HAL and special assembler inserts.
Class library layer
The .NET Micro Class Class Library is an object-oriented collection of types that developers use when writing embedded applications. This may include third-party types. For example, developers of debug boards add classes for working with peripheral devices located on these boards.
Application layer
This level contains the applications that you create for your devices. To date, the only development language for such applications is C #.
Thus, the main task of porting is to write functions and configurations of the HAL level. Now let's see how this is done.
3. Solutions in the .NET Micro Framework Porting Kit
Each port within the .Net Micro Framework Porting Kit represents a Solution. Solution, in turn, consists of several Projects. There are 5 types of Projects in total:
• NativeSample
• PortBooter
• TinyBooter
• TinyBooterDecompressor
• TinyCLR
NativeSample is a simple “Hello, World” project. The main task in its implementation is to write enough HAL functions to display the string "Hello, World" in the debug console.
Portbooter- port loader. It allows you to flash new versions of TinyCLR during the development and debugging of the port. The implementation of this project requires the addition of new HAL functions to those already written for NativeSample. This is a transitional project to prepare for the implementation of the following projects.
TinyBooter is the .NET Micro Framework bootloader. At the moment of power-up, it performs all the necessary initialization and starts TinyCLR. In addition, it allows you to flash new versions of TinyCLR. During the implementation of this project, several new features are added to the HAL.
TinyBooterDecompressor is a special add-in designed to minimize the physical size of TinyBooter. TinyBooter is stored in an archived form and when it is turned on, it is unpacked and loaded using TinyBooterDecompressor.
TinyCLR is, in fact, the runtime itself. Getting a functioning TinyCLR is the goal of porting. In the process of working on this project, the remaining HAL functions are added. TinyCLR includes TinyBooter.
Thus, by implementing these projects in turn, you create a HAL layer.
4. Solution Wizard and project components
Creating a new Solution begins with the SolutionWizard. This utility allows you to create a Solution from scratch, make a new Solution on the basis of the existing one (clone) and edit the existing one.
In the process, SolutionWizard allows you to select the so-called Features that will be included in the Solution. Features are the functional properties of .Net Micro Framework. For example, there are Features such as I2C, UART, SD, etc. Thus, if you do not need some .Net Micro Framework features, then you can simply not include them in the project, thereby reducing the physical size of TinyCLR.
Each Feature is implemented by a set of Libraries , which are combined intoLibrary Categories . Library is a separate MSBuild project that implements its task. Actually, Library and include the source code. Since there may be many implementations of the same task (for example, for different processors), there may also be many Library . That is why they are combined into Library Categories . The default implementation of the Library Category is stub Library . This is such a Library, in which place all functions are stubs. It does not carry any functions and is needed only to ensure the operation of the linker, even if there is not a single normal implementation. All of these components can refer to each other.
Thus, the following link is obtained:
Feature -> Set of Library Categories -> One of the Library that implements each category.
Understanding this “mess” is not easy. To at least somehow make it clear, let's look at this picture:
At first glance, it does not become clearer. Let's try to figure it out.
Here's the implementation of Feature I2C. Feature are yellow, Library Category are green, Library- blue, and the Stub Library - black. Also on the diagram there are the following types of relationships:
• Depend - depends on;
• Associate - associated with;
• Realise - implements;
• Stub - Library with stubs.
You can see from this picture that Feature I2C is implemented by three Library Categories: I2C_CLR, I2C_PAL, I2C_HAL. In addition, it still depends on another Feature Hardware. Each Library Category corresponds to one of the levels in the Runtime Component Layer .
Category I2C_CLR is implemented by the Library I2C and I2C_Stub. Category I2C_PAL implemented by LibraryI2C_pal and I2C_pal_stubs. The most interesting thing we see in the implementation of I2C_HAL. Here, in addition to stub Library , there are 5 more libraries for different processors.
So, for each Library Category associated with the Feature selected earlier , SolutionWizard allows you to select one Library . You can choose one of the existing ones, select stub if it is not needed at the moment, or you can generate a template for the new Library .
Since the number of Library Categoryabout a hundred, then the majority of the choice SolutionWizard takes upon itself. However, you can adjust this choice. In addition, you can choose the projects that will be included in the Solution.
The result of the SolutionWizard is either a new Solution, or changes to an existing Solution.
Next, code writing and compilation begin directly.
5. Conclusion
I reviewed the most common concepts and principles for creating .Net Micro Framework ports. Then begin the particulars that are beyond the scope of this article. For example, working with MSBuild, memory allocation, implementation features of specific functions, etc. I will write about this to everyone in the following articles.