Now that you know why Microsoft developed the .NET Micro Framework, let’s take a look at how it works.
Introducing the Bootable Runtime Environment
The .NET Micro Framework does not require an underlying operating system and can run directly on the hardware. It provides the following services that are usually provided by an operating system:
• Boot code
• Code execution
• Thread management
• Memory management
• Hardware I/O
However, the .NET Micro Framework is not a full-featured operating system; it’s a bootable runtime environment tailored for embedded development. That’s how the .NET Micro Framework can run directly on the hardware without an underlying operating system. Nonetheless, the .NET Micro Framework can still use an underlying operating system and its services; the extensible emulator running on Windows is an example of that.
Architecture
As I said, the .NET Micro Framework is not a full-featured operating system but a bootable runtime environment tailored for embedded development; it consists of the four.
User Code Layer
The topmost layer is the user code layer. This layer consists of your managed application written in C#. Your application can use your reusable class libraries shared with other projects.
Base Class Library Layer
The next layer is the .NET Micro base class library layer, which provides a subset of the common .NET libraries and domain-specific extensions, such as libraries for touching the hardware, simple drawing, complex graphical user interfaces, and networking.
The .NET Micro Framework provides a subset of the full .NET Framework base class library (BCL). Microsoft tried to stay in line with the full .NET Framework class library wherever possible. If the functionality or interface of a class deviates from the full .NET Framework, that class or interface was moved to the new namespace Microsoft.SPOT.
The .NET Micro Framework base class libraries use a mix of managed and native code. The
class libraries do not contain native code. The native methods are built into the runtime environment and are used to perform time-critical tasks or access hardware.
TinyCLR
The TinyCLR layer consists of three components:
• Hardware abstraction layer (HAL): The HAL is tightly coupled to the hardware and provides functions to access the hardware and peripherals. When running on an operating system, the HAL provides functionality by using the services of the underlying OS.
• Platform abstraction layer (PAL): The PAL provides additional abstractions of the HAL, such as timers and memory blocks.
• .NET Micro Framework CLR: The CLR consists of the execution engine that manages code at execution time. The managed type system ensures strict type safety. The CLR also contains the garbage collector, which is responsible for automatically freeing unused memory blocks, and the internal native methods called by the base class library. In addition, there is a boot loader that loads and starts the TinyCLR.
Hardware Layer
The hardware layer consists of the actual hardware platform. This is either the target device (microprocessor and peripheral) or the hardware emulator running on a Windows PC.
Compiling for the .NET Micro Framework
In .NET, compilers, such as the C# compiler, transform the source code to assemblies—executables (.exe files) and libraries (.dll files)—containing the common intermediate language and metadata for a self-describing code. The CLR then executes the managed code.
The .NET Micro Framework uses a special variant of the common intermediate language (CIL) optimized for size. A global, shared string table for text and metadata such as type, method, and field names is used to reduce ROM and RAM usage on the devices.
Therefore, the .NET Micro Framework metadata processor tool generates the optimized portable executable files (pe-files) to be deployed out of the managed .NET assemblies. Visual Studio and the .NET Micro Framework plug-in hide all these steps from you. You will not see that the metadata processor is used, but you should know that Visual Studio actually deploys special optimized assemblies that the .NET Micro Framework CLR will interpret.
Currently, the .NET Micro Framework supports only Visual C#. Theoretically, every .NET language compiler could be supported because the metadata processor parses common .NET assemblies that each .NET compiler should be able to generate. In practice, Visual Basic uses a special Visual Basic runtime library that has not yet been ported to the .NET Micro Framework. An article at www.christec.co.nz/blog/archives/317 describes how to compile Visual Basic code manually without using the runtime library on the command-line shell.
Target platforms
Currently, the .NET Micro Framework runs on ARM7 and ARM9 chipsets and also on the Blackfin processor, from Analog Devices. The extensible emulator is another port of the CLR on X86 processors; it uses an underlying operating system, such as Windows XP or Vista.
Platform Porting
The .NET Micro Framework separates all code that interfaces with the hardware in the hardware and platform abstraction layers (HAL and PAL). Theoretically, porting to a new platform seems like it ought to be an easy task, but it is complex and requires a complete understanding of the hardware being used. In practice, a full porting effort will be done by hardware platform vendors rather than by individual embedded developers.
Microsoft provides a porting kit and porting workshops. The porting kit includes the source code for a reference HAL and PAL implementation. The porting kit requires a porting agreement along with payment of an associated fee. The chipset itself is not so important when programming with the .NET Micro Framework because the code is processor independent. There are several platforms available that provide all the peripheral hardware supported by the .NET Micro Framework. The devices vary only in display and networking support. This is an active area of development, and we will certainly see interesting new platforms in the future.
Native Code Interoperability
You can accomplish a lot with managed code and the .NET Micro Framework runtime library, but sometimes advanced scenarios can require increased performance for a time-critical algorithm or to access resources that cannot be reached with managed code. The .NET Micro Framework therefore supports native code interoperability. Native interoperability allows you to implement your own methods in native code with C/C++ and call them from managed code. To do so requires a porting kit. The great news is that the porting kit is included with most Microsoft Developer Network (MSDN) subscriptions and will be offered at no cost due to a new licensing model that is in progress at time of this writing. Steve Maillet has a good, practical tutorial about using native interoperability with the .NET Micro Framework at http://blogs.msdn.com/netmfteam/pages/using-interop-in-net-micro-frameworkv3-0.aspx. Microsoft also provides a porting kit-related forum called microsoft.public.dotnet.framework.microframework.porting.
Highlights of the .NET Micro Framework (3.0)
Version 3.0 of the.NET Micro Framework includes many significant features that are sure to facilitate programming micro devices, including:
• The ability to program with the C# programming language
• The Microsoft Visual Studio 2008 development environment (the Express Edition is ffree)
• Development boards staring at $100 and QVGA LCD displays starting at $350
• Modules available starting at $30
• Rapid prototyping and debugging with the extensible emulator
• Live debugging directly on the devices
• General purpose input/output (GPIO) ports
• Serial ports
• Serial peripheral interface (SPI) bus
• Inter-integrated circuit (I²C) bus
• Ethernet with TCP/IP and UDP sockets
• Wireless LAN
• Secure network connections with secure sockets layer (SSL)
• Web services on devices with DPWS, including code-generation tools
• LCD displays
• User interfaces with simplified Windows Presentation Foundation–style classes
• Stylus and touch panel
• Battery control
• Monotone Piezo speaker
• Data persistence in the flash memory
• USB-device capable
• File system for example on SD-cards
• Pulse width modulation (provided indirectly by hardware manufacturer’s own API)
• USB host (provided indirectly by hardware manufacturer’s own API)
• Controller area network (CAN) bus (provided indirectly by hardware manufacturer’s own API)
Source of Information : Apress Expert Dot NET Micro Framework 2nd Edition (09-2009)
Introducing the Bootable Runtime Environment
The .NET Micro Framework does not require an underlying operating system and can run directly on the hardware. It provides the following services that are usually provided by an operating system:
• Boot code
• Code execution
• Thread management
• Memory management
• Hardware I/O
However, the .NET Micro Framework is not a full-featured operating system; it’s a bootable runtime environment tailored for embedded development. That’s how the .NET Micro Framework can run directly on the hardware without an underlying operating system. Nonetheless, the .NET Micro Framework can still use an underlying operating system and its services; the extensible emulator running on Windows is an example of that.
ArchitectureAs I said, the .NET Micro Framework is not a full-featured operating system but a bootable runtime environment tailored for embedded development; it consists of the four.
User Code Layer
The topmost layer is the user code layer. This layer consists of your managed application written in C#. Your application can use your reusable class libraries shared with other projects.
Base Class Library Layer
The next layer is the .NET Micro base class library layer, which provides a subset of the common .NET libraries and domain-specific extensions, such as libraries for touching the hardware, simple drawing, complex graphical user interfaces, and networking.
The .NET Micro Framework provides a subset of the full .NET Framework base class library (BCL). Microsoft tried to stay in line with the full .NET Framework class library wherever possible. If the functionality or interface of a class deviates from the full .NET Framework, that class or interface was moved to the new namespace Microsoft.SPOT.
The .NET Micro Framework base class libraries use a mix of managed and native code. The
class libraries do not contain native code. The native methods are built into the runtime environment and are used to perform time-critical tasks or access hardware.
TinyCLR
The TinyCLR layer consists of three components:
• Hardware abstraction layer (HAL): The HAL is tightly coupled to the hardware and provides functions to access the hardware and peripherals. When running on an operating system, the HAL provides functionality by using the services of the underlying OS.
• Platform abstraction layer (PAL): The PAL provides additional abstractions of the HAL, such as timers and memory blocks.
• .NET Micro Framework CLR: The CLR consists of the execution engine that manages code at execution time. The managed type system ensures strict type safety. The CLR also contains the garbage collector, which is responsible for automatically freeing unused memory blocks, and the internal native methods called by the base class library. In addition, there is a boot loader that loads and starts the TinyCLR.
Hardware Layer
The hardware layer consists of the actual hardware platform. This is either the target device (microprocessor and peripheral) or the hardware emulator running on a Windows PC.
Compiling for the .NET Micro Framework
In .NET, compilers, such as the C# compiler, transform the source code to assemblies—executables (.exe files) and libraries (.dll files)—containing the common intermediate language and metadata for a self-describing code. The CLR then executes the managed code.
The .NET Micro Framework uses a special variant of the common intermediate language (CIL) optimized for size. A global, shared string table for text and metadata such as type, method, and field names is used to reduce ROM and RAM usage on the devices.
Therefore, the .NET Micro Framework metadata processor tool generates the optimized portable executable files (pe-files) to be deployed out of the managed .NET assemblies. Visual Studio and the .NET Micro Framework plug-in hide all these steps from you. You will not see that the metadata processor is used, but you should know that Visual Studio actually deploys special optimized assemblies that the .NET Micro Framework CLR will interpret.
Currently, the .NET Micro Framework supports only Visual C#. Theoretically, every .NET language compiler could be supported because the metadata processor parses common .NET assemblies that each .NET compiler should be able to generate. In practice, Visual Basic uses a special Visual Basic runtime library that has not yet been ported to the .NET Micro Framework. An article at www.christec.co.nz/blog/archives/317 describes how to compile Visual Basic code manually without using the runtime library on the command-line shell.
Target platforms
Currently, the .NET Micro Framework runs on ARM7 and ARM9 chipsets and also on the Blackfin processor, from Analog Devices. The extensible emulator is another port of the CLR on X86 processors; it uses an underlying operating system, such as Windows XP or Vista.
Platform Porting
The .NET Micro Framework separates all code that interfaces with the hardware in the hardware and platform abstraction layers (HAL and PAL). Theoretically, porting to a new platform seems like it ought to be an easy task, but it is complex and requires a complete understanding of the hardware being used. In practice, a full porting effort will be done by hardware platform vendors rather than by individual embedded developers.
Microsoft provides a porting kit and porting workshops. The porting kit includes the source code for a reference HAL and PAL implementation. The porting kit requires a porting agreement along with payment of an associated fee. The chipset itself is not so important when programming with the .NET Micro Framework because the code is processor independent. There are several platforms available that provide all the peripheral hardware supported by the .NET Micro Framework. The devices vary only in display and networking support. This is an active area of development, and we will certainly see interesting new platforms in the future.
Native Code Interoperability
You can accomplish a lot with managed code and the .NET Micro Framework runtime library, but sometimes advanced scenarios can require increased performance for a time-critical algorithm or to access resources that cannot be reached with managed code. The .NET Micro Framework therefore supports native code interoperability. Native interoperability allows you to implement your own methods in native code with C/C++ and call them from managed code. To do so requires a porting kit. The great news is that the porting kit is included with most Microsoft Developer Network (MSDN) subscriptions and will be offered at no cost due to a new licensing model that is in progress at time of this writing. Steve Maillet has a good, practical tutorial about using native interoperability with the .NET Micro Framework at http://blogs.msdn.com/netmfteam/pages/using-interop-in-net-micro-frameworkv3-0.aspx. Microsoft also provides a porting kit-related forum called microsoft.public.dotnet.framework.microframework.porting.
Highlights of the .NET Micro Framework (3.0)
Version 3.0 of the.NET Micro Framework includes many significant features that are sure to facilitate programming micro devices, including:
• The ability to program with the C# programming language
• The Microsoft Visual Studio 2008 development environment (the Express Edition is ffree)
• Development boards staring at $100 and QVGA LCD displays starting at $350
• Modules available starting at $30
• Rapid prototyping and debugging with the extensible emulator
• Live debugging directly on the devices
• General purpose input/output (GPIO) ports
• Serial ports
• Serial peripheral interface (SPI) bus
• Inter-integrated circuit (I²C) bus
• Ethernet with TCP/IP and UDP sockets
• Wireless LAN
• Secure network connections with secure sockets layer (SSL)
• Web services on devices with DPWS, including code-generation tools
• LCD displays
• User interfaces with simplified Windows Presentation Foundation–style classes
• Stylus and touch panel
• Battery control
• Monotone Piezo speaker
• Data persistence in the flash memory
• USB-device capable
• File system for example on SD-cards
• Pulse width modulation (provided indirectly by hardware manufacturer’s own API)
• USB host (provided indirectly by hardware manufacturer’s own API)
• Controller area network (CAN) bus (provided indirectly by hardware manufacturer’s own API)
Source of Information : Apress Expert Dot NET Micro Framework 2nd Edition (09-2009)
|
|
0 comments
Post a Comment