Embedded development has historically been a distinct skillset from development for the desktop, servers, and web. While the same programming models and tools can be used in desktop, server, web, and even cloud applications, embedded
software development required developers with specialized skills often using different languages and tools. With embedded applications increasingly moving to standard operating environments and with more and more of these embedded devices being connected to
networks of other devices and PCs, servers, and the cloud, the need to use more modern programming models becomes compelling. The ‘hard’ distinction between embedded software development and other forms of development is going away for many applications.
(Before someone gets upset with me, I am not suggesting that all embedded applications can be addressed with this technology. There are many embedded devices with more stringent response requirements, cost requirements, other requirements, that will continue
to need specialized skills. However, there are many applications for which it will work and there are also future designs on the table for managed code systems that will continue to shrink the size of this specialized group over time while Moore’s law continues
to enable more devices to run powerful processors. In the mean time, the applications that can take advantage of the modern programming model and tools can garner a faster time to market and much more flexibility in the resulting application.)
The .NET Micro Framework (NETMF) extends the .NET programming model and tool chain that is the used on the desktop and on web apps and elsewhere to embedded devices. This enables embedded developers to take advantage of the productivity and flexibility of the
desktop application tools. It also enables current .NET developers to now work on devices. At the most recent PDC, I spoke with a .NET developer whose company had turned down an interesting project because it required including a device in the solution. He
was excited to see that was no longer a problem. I am also working on a case study with another .NET solution provider who has just successfully finished their first device application as part of a larger solution. I’d like to explore how .NET can now be used
in device applications to help introduce .Net developers to applications on devices and remove any hesitation they may have from trying this. The best way to do this is by demonstration.
This is the first in a series of articles intended to demonstrate that, with modest .NET programming skills, you can create compelling devices. In this series, I will go through the process of creating an embedded application that includes a rich user interface,
integration of physical sensors (ie writing drivers) and connectivity with the ‘cloud’ to show that .NET skills are sufficient to enable this. I will write the application, including the drivers in C# using .NET MF version 4.1 (just released in Beta) and Visual
Studio 2010. This will not be an introduction to Visual Studio or NETMF. Instead, it will be an exploration, as I actually build the device, of how it was done, what challenges I encounter and how they are overcome. (If you want an overview of the development
environment, I suggest in a great book by Jens Kühner book “Expert .NET Micro Framework”.)
The device that I have elected make is a bicycle computer. I picked this project because it will include all the parts that I am looking for: integration with peripheral sensors, a rich user interface, and connectivity with web services to track your workouts.
The best part is that anyone who has ever ridden a bicycle has the necessary domain expertise to evaluate (and comment on) the usefulness of the device and the design decisions.
The design objective is to make a commercially viable device although much of the commercialization process (plastics, manufacturing, and actual business case) are outside the scope of this article. I will make decisions based on making an admittedly high end
bicycle computer with attention to power consumption and bill of materials cost. In the end, we can assess whether there is a reason to bring it to market.
The computer will have a rich, touch based user interface, a full range of sensors, and a direct connection for uploading ride data to a host. The Rich user experience will include the ability to configure the device through a settings screen, to start, pause,
resume, and end a ‘ride’, and to see that ride data in both an instantaneous view (what is happening now) and an aggregate view (what has happened over the entire ride). The ride data includes information about speed, cadence, distance, incline/elevation gain
(I am not sure which at this point), time of day, elapsed time, and temperature. Finally, there is a data menu for managing the data associated with the ride – saving it locally or connecting to a web service to share out the ride data. I will not spend too
much time on the web service that the computer connects to as that could be a huge undertaking involving aggregating data for individuals or to compete with your friends which has little to do with the point of this blog series. For an example of what this
service could be, take a peek at www.BikeJournal.com.
As I mentioned, the display will be a touch screen. This is a critical decision because it will increase the cost of the device dramatically because of the cost of the display that supports touch but it will allow us to give the rider an interface that they
can control with simple gestures. This is not only an ease of use feature but potentially a safety issue allowing the user to keep their hands and eyes where they belong as much as possible. The display that I am starting with is also a color display. This
incurs additional cost as well as reducing the contrast. Time permitting; I may switch to a monochrome display to test out that decision. With the hardware abstraction provided by the .NET Micro Framework, that kind of flexibility is easily achieved.
Development Board Selection
Starting with our original idea of a device, I am not sure yet what the final device will look like (color vs monochrome screen, elevation gain vs incline,…), what sensors will work for me, how much memory my application will need, what size battery it will
require, and so much more. I am clearly not ready to design and order the hardware for my device. In fact, I may have to get very far down the path on developing my application before I can commit to an initial hardware design. NETMF helps with this by supplying
you with a extensible emulator that allows you to build things like your UI without any hardware. You can put the idea in front of others very early in the process. But for testing the range of sensors I am considering, we need some hardware. So, we will start
with a general purpose development board and work on that until our hardware needs are well defined and we can design our actual product hardware.
The application requirements defined above drive the development board selection. There are several pieces of good news through. First, there are a large number of development platforms to select from and they can be found here. We know already that we want
Version 4.0/4.1 firmware support, wireless connectivity, a touch screen, GPIO, SPI, and maybe I2C. That still leaves us a number to choose from. The second piece of good news is that the underlying hardware is largely abstracted by the system. With the exception
of any board specific features that you take advantage of, it is easy to move from one platform to another. That means that you can start out with an ARM7, try the ADI Blackfin, and eventually end up on an SH2 without having to re-write your application. The
third piece of good news is that 4.1 contains some new features that will assist us in determining the memory requirements of our application once it has been completed. For a broader discussion of hardware selection, visit the .netmf.com technical article
on the subject. For this project, I am starting with the GHI Embedded Master EMX board.
There are no ringers involved here. I am no ‘embedded’ programmer. In fact, I do not program for a living any more – not for the last 20 years. If this project turns out a complete embedded device, then a real programmer will have no problems that they cannot
overcome. I do have a partner in this who is more of a hard-core cyclist and is my application expert as well as an amateur tinkerer himself.
You have a part in this too. I could write a book on this process but instead, I will keep the articles a few pages each. Your questions and suggestions will drive what is in those few pages so it will be as interesting to you as you make it. Join us on this
project and see how you, as a .NET developer, can now create embedded applications.
In the next installment, we will start mapping out the project and the displays.