.NET Micro Framework: Porting in Brief
The last article caused a certain interest. Many different questions were asked, but most of them touched porting. This topic is worthy of a separate full-fledged book and briefly illuminate it is not easy. But I'll try.
For people who decide to do porting, Microsoft supplies a special tool: .Net Micro Framework Porting Kit . It is a set of source codes and configuration files from which you can compile the CLR. The build system is based on MSBuild. At the moment compilation is started only from the command line. Virtually no graphic tools 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, the 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 is built inside. In the last article, I briefly talked about the .Net Micro Framework architecture, and here I’ll look at it in more detail. In the documentation for .Net Micro Framework Porting Kit there is such a picture:
')
This is a 4-layer architecture. Net Micro Framework. 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 such as ARM7, ARM9, Cortex, XScale, ARC, and ADI Blackfin.
In addition, it is possible to run the .Net Micro Framework on top of the operating system. Of course, in this case the “iron” does not disappear anywhere. Simply interaction with the hardware will occur through the operating system API. This is how the emulator, which is part of the .NET Micro Framework Platform SDK , works. It is nothing like the .NET Micro Framework port for Windows.
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 (TinyCLR) runtime is a subset of the .NET Framework CLR. TinyCLR differs from the “big” CLR in that it has been specially redesigned for use in small embedded devices.
The .Net Micro Framework Porting Kit comes with TinyCLR source codes. 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 "iron". The functions included in PAL, on the contrary, are designed so as not to depend on the hardware implementation.
Many functions of HAL and PAL 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 power-up, this code initializes the hardware and then launches TinyCLR.
TinyCLR continues to load and is engaged in high-level initialization. Bootstrap code performs its tasks using functions from HAL and special assembler inserts.
The .NET Micro Framework class library is an object-oriented type collection that developers use when writing embedded applications. This may include third-party types. For example, developers of debug boards add classes to work with peripheral devices located on these boards.
This level contains the applications you create for your devices. To date, the only language for developing 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 is a Solution. Solution in turn consists of several Projects. In total there are 5 types of Projects:
• NativeSample
• PortBooter
• TinyBooter
• TinyBooterDecompressor
• TinyCLR
NativeSample is a simple “Hello World” project. The main task in its implementation is to write a sufficient number of HAL functions in order to output the string “Hello, World” to the debugging console.
PortBooter - port loader. It allows you to flash new versions of TinyCLR during the port development and debugging process. Implementing this project requires adding 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 a .NET Micro Framework loader. At the time of power-up, it performs all the necessary initialization and launches TinyCLR. In addition, it allows you to flash new versions of TinyCLR. In the process of implementing this project, several new features are added to HAL.
TinyBooterDecompressor is a special add-on designed to minimize the physical size of TinyBooter. TinyBooter is stored in an archived form and when turned on, it is unpacked and loaded using TinyBooterDecompressor.
TinyCLR is actually the execution environment itself. Getting a working TinyCLR is the goal of porting. In the process of working on this project, the remaining HAL functions are added. TinyCLR includes TinyBooter.
Thus, implementing these projects in turn, you create a HAL layer.
Creating a new Solution begins with SolutionWizard. This utility allows you to create a Solution from scratch, make a new Solution based on an existing (clone) and edit an existing one.
In the process, SolutionWizard allows you to select the so-called Features that will be included in the Solution. Features are functional properties of the .Net Micro Framework. For example, there are features such as I2C, UART, SD, etc. Thus, if you do not need some features of the .Net Micro Framework, 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 into Library Categories . Library is a separate MSBuild project that implements its task. Actually, the Library and include the source code. Since there can be many implementations of the same task (for example, for different processors), there can also be many libraries . That is why they are integrated into the Library Categories . The default implementation of the Library Category is the stub Library . This is such a Library , in which there are stubs in place of all functions. It does not carry any functions and is only needed to ensure the work of the linker, even if there is no normal implementation. All these components can refer to each other.
Thus, it turns out the following bunch:
Feature -> Library Kit Categories -> One Library that implements each category.
To understand this "mess" is not easy. To at least somehow be clear, look at this picture:
At first glance it does not become clearer. Let's try to figure it out.
Here is the implementation of Feature I2C. Feature are colored yellow, the Library Category is green, the Library is blue, and the Stub Library is black. Also on the diagram there are the following types of links:
• Depend - depends on;
• Associate - associated with;
• Realize - implements;
• Stub - Library with stubs.
This picture shows that Feature I2C is implemented by three Library Category : 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 .
The I2C_CLR category is implemented by the Library I2C and I2C_Stub. The I2C_PAL category is implemented by the Library I2C_pal and I2C_pal_stubs. The most interesting thing we see in the implementation of I2C_HAL. Here, besides the stub Library , there are 5 more Library for different processors.
So, for each Library Category associated with the previously selected Feature , SolutionWizard allows you to select one Library . You can choose one of the existing ones, choose a stub if it is not needed at the moment, or you can generate a template for the new Library .
Since the number of Library Category is on the order of hundreds, most of the selection SolutionWizard takes on. However, you can correct this choice. In addition, you can select projects that will be included in the Solution.
The result of SolutionWizard is either a new Solution or a change in an existing Solution.
Next begins writing code and compilation.
I reviewed the most common concepts and principles for creating .Net Micro Framework ports. Next come the particulars that go beyond the scope of this article. For example, working with MSBuild, memory allocation, features of the implementation of specific functions, etc. I will write about this to all in the following articles.
1. Introduction
For people who decide to do porting, Microsoft supplies a special tool: .Net Micro Framework Porting Kit . It is a set of source codes and configuration files from which you can compile the CLR. The build system is based on MSBuild. At the moment compilation is started only from the command line. Virtually no graphic tools 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, the ports are written almost in a notebook. But in the near future the situation should change for the better.
2. Architecture .NET Micro Framework
Before talking about porting, it’s very important to understand how the .Net Micro Framework is built inside. In the last article, I briefly talked about the .Net Micro Framework architecture, and here I’ll look at it in more detail. In the documentation for .Net Micro Framework Porting Kit there is such a picture:
')
This is a 4-layer architecture. Net Micro Framework. 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 such as ARM7, ARM9, Cortex, XScale, ARC, and ADI Blackfin.
In addition, it is possible to run the .Net Micro Framework on top of the operating system. Of course, in this case the “iron” does not disappear anywhere. Simply interaction with the hardware will occur through the operating system API. This is how the emulator, which is part of the .NET Micro Framework Platform SDK , works. It is nothing like the .NET Micro Framework port for Windows.
Runtime Component Layer
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 (TinyCLR) runtime is a subset of the .NET Framework CLR. TinyCLR differs from the “big” CLR in that it has been specially redesigned for use in small embedded devices.
The .Net Micro Framework Porting Kit comes with TinyCLR source codes. 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 "iron". The functions included in PAL, on the contrary, are designed so as not to depend on the hardware implementation.
Many functions of HAL and PAL 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 power-up, this code initializes the hardware and then launches TinyCLR.
TinyCLR continues to load and is engaged in high-level initialization. Bootstrap code performs its tasks using functions from HAL and special assembler inserts.
Class Library Layer
The .NET Micro Framework class library is an object-oriented type collection that developers use when writing embedded applications. This may include third-party types. For example, developers of debug boards add classes to work with peripheral devices located on these boards.
Application layer
This level contains the applications you create for your devices. To date, the only language for developing 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 is a Solution. Solution in turn consists of several Projects. In total there are 5 types of Projects:
• NativeSample
• PortBooter
• TinyBooter
• TinyBooterDecompressor
• TinyCLR
NativeSample is a simple “Hello World” project. The main task in its implementation is to write a sufficient number of HAL functions in order to output the string “Hello, World” to the debugging console.
PortBooter - port loader. It allows you to flash new versions of TinyCLR during the port development and debugging process. Implementing this project requires adding 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 a .NET Micro Framework loader. At the time of power-up, it performs all the necessary initialization and launches TinyCLR. In addition, it allows you to flash new versions of TinyCLR. In the process of implementing this project, several new features are added to HAL.
TinyBooterDecompressor is a special add-on designed to minimize the physical size of TinyBooter. TinyBooter is stored in an archived form and when turned on, it is unpacked and loaded using TinyBooterDecompressor.
TinyCLR is actually the execution environment itself. Getting a working TinyCLR is the goal of porting. In the process of working on this project, the remaining HAL functions are added. TinyCLR includes TinyBooter.
Thus, implementing these projects in turn, you create a HAL layer.
4. Solution Wizard and Project Components
Creating a new Solution begins with SolutionWizard. This utility allows you to create a Solution from scratch, make a new Solution based on an existing (clone) and edit an existing one.
In the process, SolutionWizard allows you to select the so-called Features that will be included in the Solution. Features are functional properties of the .Net Micro Framework. For example, there are features such as I2C, UART, SD, etc. Thus, if you do not need some features of the .Net Micro Framework, 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 into Library Categories . Library is a separate MSBuild project that implements its task. Actually, the Library and include the source code. Since there can be many implementations of the same task (for example, for different processors), there can also be many libraries . That is why they are integrated into the Library Categories . The default implementation of the Library Category is the stub Library . This is such a Library , in which there are stubs in place of all functions. It does not carry any functions and is only needed to ensure the work of the linker, even if there is no normal implementation. All these components can refer to each other.
Thus, it turns out the following bunch:
Feature -> Library Kit Categories -> One Library that implements each category.
To understand this "mess" is not easy. To at least somehow be clear, look at this picture:
At first glance it does not become clearer. Let's try to figure it out.
Here is the implementation of Feature I2C. Feature are colored yellow, the Library Category is green, the Library is blue, and the Stub Library is black. Also on the diagram there are the following types of links:
• Depend - depends on;
• Associate - associated with;
• Realize - implements;
• Stub - Library with stubs.
This picture shows that Feature I2C is implemented by three Library Category : 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 .
The I2C_CLR category is implemented by the Library I2C and I2C_Stub. The I2C_PAL category is implemented by the Library I2C_pal and I2C_pal_stubs. The most interesting thing we see in the implementation of I2C_HAL. Here, besides the stub Library , there are 5 more Library for different processors.
So, for each Library Category associated with the previously selected Feature , SolutionWizard allows you to select one Library . You can choose one of the existing ones, choose a stub if it is not needed at the moment, or you can generate a template for the new Library .
Since the number of Library Category is on the order of hundreds, most of the selection SolutionWizard takes on. However, you can correct this choice. In addition, you can select projects that will be included in the Solution.
The result of SolutionWizard is either a new Solution or a change in an existing Solution.
Next begins writing code and compilation.
5. Conclusion
I reviewed the most common concepts and principles for creating .Net Micro Framework ports. Next come the particulars that go beyond the scope of this article. For example, working with MSBuild, memory allocation, features of the implementation of specific functions, etc. I will write about this to all in the following articles.
Source: https://habr.com/ru/post/120674/
All Articles