Bicycle Computer #1 – Introduction
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.
System Requirements
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.
The players
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.
Comments
Anonymous
June 01, 2010
Hello, You say that you are using the GHI Embedded Master EMX board. I'm using the same bard with the 4.0 firmware version. But when I try to deploy a MF 4.1 project to my device I get the next error: Error 1 Cannot deploy the base assembly 'mscorlib', or any of his satellite assemblies, to device - USB:EMX twice. Assembly 'mscorlib' on the device has version 4.0.1681.0, while the program is trying to deploy version 4.1.2459.0 How did you manage to make it to work? ThanksAnonymous
June 02, 2010
GHI has not released their 4.1 compatible firmware yet. However, you can run a 4.0 project in NETMF 4.1 because of the new multi-targeting feature. (In fact you can still run 3.0 projects as well). If you go into the Application tab of the Project Properties sheet, you can specific that the target framework is version 4.0 and you should be fine. You will be deploying a 4.0 project. You will not have access to the 4.1 features until GHI finishes their firmware update.Anonymous
June 02, 2010
Ok. Then, I can't use the new features in my board. I imagined it could be that way. So, the only thing I can do is to wait GHI to release a new firmware version. Thank you very much for your answer, it will prevent to keep me on finding a solution!Anonymous
June 02, 2010
4.0 has almost everything you could want so you can still make a cool app on the platform in the mean time. Enjoy.Anonymous
June 02, 2010
Yes, it has almost everything I could want... but the Dpws stack of 4.1 version. Would it be possible to build 4.1 Dpws libraries to use them in my 4.0 device? Any guidelines? Thanks.Anonymous
June 03, 2010
There is DPWS support in 4.0 - we just polished it, did some compatibility testing with the Windows test suites, and added samples. You can start with the 4.0 libraries and then move as soon as GHI has the update. I think that woudl be easier - it hopefully will be soon.Anonymous
June 13, 2010
The online marketplace for cars and trucks is huge and confusing, you would generally have to have one search to find a place to sell your car, another search to purchase your car, and yet another to find parts and supplies or maintenance/repair information.i like to read this post and always find helpful information from your blog. thanksAnonymous
June 17, 2010
The source code for this project is now available at: netmfbikecomputer.codeplex.com