How to select your hardware
The .NET Micro Framework (NETMF) has opened up embedded software development to a large new audience of existing .NET developers. There are also a number of current embedded software developers who are trying out NETMF for the productivity and flexibility that it provides. For these groups, the question of what processor to select and what development board to use can be difficult until they have a little more experience with NETMF and the options that are available. We get asked this frequently enough that I decided to write down some of the guidance that we commonly share when asked.
Development board selection
There are a number of development boards that support NETMF and more coming on a consistent basis. As quickly as we know about them, they are listed here. We have selected a high level set of criteria help you start your selection. These include whether the latest version of NETMF is supported, whether wired and wireless communication is supported, whether USB is supported and whether a display (with or without touch) is supported. This is not expected to be a complete list of interesting characteristics but rather a set to help narrow your own deeper evaluation. If other general criteria would also be useful, please let us know.
These boards tend to have plenty of memory for almost any NETMF application. (In general, these boards are much more expensive than your eventual product hardware platform because they are completely general and have enough memory, IO, and other components to support virtually any reasonable application.) There are also a few specialized boards like the Crossbow Imote that are targeted at sensor network applications. There is a full range of the processors represented in this set of development boards. The boards differ on the kinds of IO supported, the hardware peripherals available and the library support for additional drivers. You should be able to find something that will support your application comfortably here. (Some development boards are built around modules. I will discuss the tradeoffs there a little later.)
The good news with development board selection in that, with the exception of applications that make extensive use of some aspects of a development board that are only available on that board, it is very easy to move from one board to another. This means that with a few hours work, you can try your application on different processor families or different clock speeds within a family or other configuration differences.
Memory requirements
It is very common for people to ask how much memory is needed to run their application on NETMF. This is a very difficult question to answer in advance because we have seen simple applications run in 10s of K of RAM and applications with large screens and multiple bitmaps take megabytes. The overhead of the base platform is about 200K of Flash and 30K of RAM. Everything else depends on what your application requires. Starting in version 4.1, you will be able to use reflection to get the size of each assembly. The other part of the equation is the number/size of objects that your application creates. You can see how to assess your needs there in the next section on the emulator.
Aside from the requirements of your application, the Porting Kit and Solution Wizard offer you the ability to create a version of the runtime that exactly fits your needs. If you have no UI, you can leave out all the code needed to support that. If you don’t need TCP/IP, you can leave that out.
Leveraging the emulator
The emulator is a great way to start your software development immediately – even before you have selected your development board or your eventual product platform. (When you do get you development board, many include an emulator that is specific to their boards which is cool.) Besides this benefit, the emulator can help you narrow your processor selection down. You can do this by configuring the emulator to match some of the candidate configurations. If you are using the Microsoft Emulator that comes with NETMF, look at the file named Microsoft.SPOT.Emulator.Sample.SampleEmulator.exe.emulatorconfig to see how this works. This is the configuration file for the Microsoft Emulator. The emulator that you get from your hardware vendor will have a different name, generally with the ‘emulatorconfig’ extension.. This is an XML file (so it is easy to manipulate) that contains the definitions for things like the amount of RAM that the emulator will let the application use:
<RamManager>
<Size>8388608</Size>
</RamManager>
or the display metrics:
<LcdDisplay id="mydisplay">
<Width>320</Width>
<Height>240</Height>
<BitsPerPixel>16</BitsPerPixel>
</LcdDisplay>
What this means is that if you want to see how often garbage collection will run if you have 256K RAM or what your UI looks like in 16 bit per pixel, you can easily run it in the emulator with those constraints. Each of these is referred to as an emulator component and the sample emulator does not demonstrate all the things that can be configured. (Anything not specified is given a default value.) Jens Kuhner’s book (Expert .NET Micro Framework) has nearly 100 pages on the emulator including listings of all the settable components.
Processor selection
There are a number of processor options available already and that number is growing continually. The right processor for you application is something that we typically defer back to the developers because it is so specific to your experience and your application needs. There are currently three broad architectures supported: ARM, ADI Blackfin, and Renesas SH2. Other architectures are ‘in the works’. Within ARM, we have ARM7, ARM9, and Cortex M3 and Cortex M1 (coming soon) processors from several silicon vendors supported. All of these processors have their specific strengths and configurations. For example, the Blackfin is a DSP so it may be more useful if you have some sort of analog signal to process. The Cortex processors use a more compact instruction set so we are seeing a smaller footprint and better execution speeds. The SH2 has a great deal of static RAM onboard.
Below these high level capabilities, there is a vast range of internal configurations like LCD controller, the amount of on-board memory, the IO supported, MMU, cache, speed, power management, and more. This is where it really pays to work with the distributor and/or silicon vendor to determine what is the right solution for you application and your budget.
The .NET MF can execute code from NOR flash and/or RAM and can run on processors with all internal SRAM/FLASH to ones with all external NAND/SDRAM. The Porting Kit supports scattering the image executable code across any selected media and address range. In general systems with a cache or internal SRAM perform noticeably faster.
The managed application code is treated as data as it is interpreted. It is typically not an advantage to place the managed application and system libraries code in a fast media. Instead it is beneficial to place the executable native code, both for the drivers and the managed runtime in fast media.
Modules Vs Chips
Development boards come in two configurations – they are either a processor on a PCB with a number of supporting components and external connection points or they are a module (with the processor and components) mounted on a PCB with a number of external connection points. This may seem like a small difference but it is important in defining your eventual path from development board to product. After you have developed your application on a development board without a module and you are ready to move onto your product hardware platform, you will work with someone to define a PCB specific to your needs with the processor, components, and connectivity that you need and you will have to find a way to generate the firmware for this new hardware configuration (see Porting availability below). If you have a development board based on a module, this can be much easier. You already have the processor and components and you just need to mount the module and expose the IO connections that you are using. This part of the process with therefore be quicker and less expensive. There is a tradeoff though. Remember we talked about the development boards being more expensive because they are general? These modules are general too so by using a module, you miss an opportunity to reduce the cost in manufacturing each of your devices. You are trading time to market and upfront cost against a per unit cost. Obviously, only you can make that tradeoff for your business.
Port availability
The managed code application is abstracted from the underlying hardware. This is why it is easy to try your application on several development boards if you wish. There is no free lunch however and at some point, the runtime needs to be glued to the specific underlying hardware (unless you are using one of the modules mentioned above). This is done through the ‘port’ (or Board Support Package(BSP)). All of the development boards include the firmware needed to run NETMF on them so you don’t need to worry about ports in selecting a board to start work on. The firmware that these boards run is specific to that board though. It works with that specific LCD (if there is one). It works with that specific memory configuration. Without a predefined module, it is very unlikely that your product platform will be identical to the development board. You should be able to make something much cheaper to manufacture but this means that there will also be porting work to do to adapt the runtime to your eventual hardware. Let’s look at what the options are to do this because it does have implications on your hardware selection.
Where to get the initial port
There are three places to get the initial port from. There are a number of ports included in the NEWMF Porting Kit. These are mostly ports that have been done by the silicon vendors and given back to Microsoft to distribute with NETMF. These ports are usually samples showing the ports to the development boards so they are not a bad place to start. There are also 3rd parties who have done ports that they will license out to you as a starting point. Again, these ports are usually to the development boards. The final option is to do the port yourself. This requires full embedded driver development chops but if you are up to that, you can take the platform to any processor that you want.
How to get porting work done
After you have the source for the initial port identified, there is work to adapt it to your eventual product hardware platform. There are a number of service providers listed here under Porting and Consulting Services who can help you. There is also the option of doing it yourself if you are comfortable with embedded driver development.
Hopefully this helps answer some of the questions that arise about hardware as you start your first NETMF project. Please let us know if there are any additional questions so that we can improve this description.