Architecture
The .NET Micro Framework consist of several loosely coupled layers that leverage and build upon one another to form the complete framework. The following layer diagram illustrates the basic layers and their relationships to one another:
- Physical hardware
- CPU Support layer (CPU)
- Hardware Abstraction Layer (HAL)
- Operating System (OS)
- Platform Abstraction Layer (PAL)
- Common Language Runtime (CLR)
- Interop
- Base Class Libraries
The physical hardware is, generally speaking up to the system designer. The .NET Micro Framework is portable to any 32 bit micro controller with a reasonably modern C++ compiler. Based on popular demand the framework is currently built and tested for ARM Cortex-Mx micro-controllers. However, other processors are plausible. In fact the emulator that ships with the SDK is actually a port of the framework on top of Microsoft(R) Windows. Furthermore, third parties can, and have, built support for other processor architectures including big-endian as well as little-endian architectures:
- ADI BlackFin
- SuperH 2
- ARMv6
The .NET Micro Framework does not require or use any virtual memory or Memory Management Unit (MMU), though if you have one in your hardware there are sometimes advantages to enabling it. (i.e. Many of the ARM7 and ARM9 micro architecture based SoCs required enabling the MMU to get the performance benefits of caching)
The CPU support layer provides a thin abstraction over base functionality for a CPU/SoC. Especially timers and the interrupt controller.
This layer, as the name implies is responsible for abstracting out the hardware from the rest of the system. In effect it serves the role of an OS in providing Device Drivers for the rest of the system. If you have a full OS with its own driver model then a FULL HAL is usually not necessary. (The Windows port for the emulator uses a minimal HAL with most of the abstraction coming from the underlying OS)
Generally speaking the .NET Micro Framework does not require an OS. However, as of v4.4 the updated port of the lwIP network stack requires a minimal pre-emptive thread scheduler and basic synchronization primitives. While the support is portable to just about any micro controller scale threading kernel the currently tested implementation is the CMSIS-RTX implementation from ARM.
The PAL is responsible for abstracting the differences between using a full OS or a FULL HAL or various combinations of the options for abstracting the hardware. It provides a consistent lower level API surface for the rest of the runtime to work on.
The CLR contains the core of the run-time including the interpreter engine, the overall type system support as well as the garbage collector and managed heap.
The interop layer is an extensible set of native code libraries that enable managed code libraries to expose functionality that is ultimately implemented in the native code of the system (much like P/Invoke does on the Mobile and desktop variants of the .NET Runtime).
These are the standard .NET Assemblies that are part of the framework. These provide the base types like strings and collections along with more advanced support such as networking etc...