In this chapter there are two case studies describing how real-world projects were built using the .NET Micro Framework. The individuals who built these projects discuss the design considerations and tradeoffs as well as development issues that arose and they way they dealt with them, and offer anecdotes about their experiences. The projects showcased here were chosen to illustrate two ends of a wide spectrum of applications made possible by the .NET Micro Framework.
Who: Steve Maillet, CTO, EmbeddedFusion
Web site: http://www.embeddedfusion.com
We created EmbeddedFusion to provide integrated hardware, software, and training products, and to reduce the development time and cost for customers designing embedded devices. We've built a .NET Micro Framework development kit, Tahoe, using our Meridian CPU Freescale i.MXS processor, RAM, flash memory, and various interfaces such as I2C, serial peripheral (SPI) and serial.
We wanted a great "hands-on" lab for a number of conferences, including the Microsoft Mobile and Embedded Developer's Conference 2007 (MEDC 2007). We wanted something that could meet the following criteria:
Exciting-has to meet the "wow" factor expected by MEDC organizers
High stickiness factor-not stale, boring, or easily forgotten; something people would talk about and remember years later
Demonstrate multiple aspects of the .NET Micro Framework
Demonstrate capabilities of our products
Demonstrate best practices for software implementation
Inspire new ideas for products utilizing our CPUs (specifically, the Tahoe development kit), and the .NET Micro Framework
These were some pretty tough marching orders I handed down to the development team, but they rose to the challenge! After a number of rounds, the usual stale and boring ideas were tossed out, and we started to think outside the hexahedron. We eventually came up with the idea of attaching a three-axis accelerometer to our development platform to make a modern-day twist on the classic ball-in-maze game we played with as kids. That is, use the accelerometer to provide input to a software game that moves a graphical ball around a maze rendered on the screen. The general excitement among our staff for this particular project and a number of other follow-on ideas was a clear indicator we'd hit the mark for the criteria set out for it.
We had been toying with the idea of implementing a bootable runtime ourselves before we learned Microsoft was doing it. Ultimately, we created our development kit around the .NET Micro Framework because we like it.
Most of our engineers come from a long history of embedded systems, from using dedicated microcontrollers like the venerable 8051 to the variations on the PIC Microcontrollers. Clearly, these processors worked well, and they have stood the test of time. Unfortunately, the times are changing and end users demand more graphical interfaces for some systems (in color, no less!), and rich communications and connectivity to desktop PCs and back-end servers for others. With these new demands the old processors are harder, and thus more expensive, to use. Furthermore, the development experience with them is anything but ideal. The continuation of Moore's Law has made good 32-bit RAM cores readily available at very competitive prices, so the time was ripe for something completely different to make life easier for developers.
The .NET Micro Framework dramatically simplifies the development process for embedded applications and thus brings overall costs down. To really understand how much easier it is, I looked back to a handheld device I wrote the firmware for many years ago. The device was a photon-counting luminometer, with an 8 × 15 text LCD, a 4-by-4 set of buttons, a serial port for data uploads, some sensors for detecting that the photon-counting chamber was closed, and flash for firmware updates. (Of which we're proud to say there were only three in the more than 10-year history of the device, only one of which was a bug fix!) Originally, the device took about 4 to 6 months of development. Creating the firmware for the luminometer included designing and implementing a usable text-based user interface (UI), like a set of modal dialog boxes, that was easily translated into different languages (for example, no hard-coded text strings anywhere, and the language data was easily edited by nontechnical types but still remained within the 8 × 15 character limit of the display). In addition to the UI, the firmware included the drivers for the serial port, the serial protocols for uploading data to the PC and downloading firmware and language updates, and the routines for updating the flash.
That's a good bit of functionality to stuff into an 8051! So I thought about it and asked: Given all that, how long would it take to implement the firmware if we redesigned the hardware using our Meridian CPU with the .NET Micro Framework already on it? I realized it would take just a few weeks, including testing! Heck, the first pass to get core functionality for the scientists developing the logical parts of the product would be only a couple of days at most the first time (a developer experienced with the .NET Micro Framework could get the core functionality and a basic UI going in one afternoon). This does not account for time spent fixing hardware problems, because that's a factor no matter what processor and run-time you use, although with a CPU that already runs the .NET Micro Framework, even that time is dramatically shortened.
Someday, I'll actually go back and rewrite and build that device to prove the case. What's important is the recognition of how much a CPU with the .NET Micro Framework already on it can change the development process for small, simple, single-task devices with or without a UI. This recognition inspired the creation of the Meridian CPU (Figure 11-1) and the Tahoe development board (Figure 11-2).
Figure 11-1: Meridian CPU.
Figure 11-2: Tahoe development board.
The Tahoe development kit allows easy expansion of peripherals because it provides headers to access all the pins of the CPU and allow ourselves and our customers the ability to get really creative and try new design ideas by either hand-wiring or using simple rapid prototype boards to plug in to the Tahoe. Although surface-mount technology has certainly improved electronics from the standpoint of size and power consumption, it's made things more complex for early prototyping and experimentation. Development systems like Tahoe with the .NET Micro Framework help to bring the prototyping process back to the days when you could wire things up manually in an afternoon, instead of laying out a printed circuit board PCB and sending it off for a high-priced, small-run, fast-return prototype board. Although it's not quite that simple anymore, we can get a lot closer with the .NET Micro Framework.
The design started with the criteria listed previously, in particular with the Tahoe development kit. We needed something that was functionally complete and served to illustrate best practices for the platform. We'd seen too many lab demos in the past that just focused on one little thing out of context from the big picture and were, quite frankly, boring. We wanted something that was not only in context but was the complete big picture on its own. The trick was to come up with a big picture that was easily comprehended in a 90-minute demonstration. Thus, we chose the ball-in-maze game. Time was of great importance because we had only a few weeks from content approval for the MEDC event to when we had to submit the completed lab documents for the conference attendees to work through. At this point, the accelerometer hardware didn't exist yet, and we still had other customer work to do, making the conditions for this project very stressful!
The .NET Micro Framework emulator proved its worth in the short time frame. To test out the game in a more realistic way, we created custom emulator components that could emulate the accelerometer. We had our Tahoe platform to test performance of the animation on the real device. We also "faked" the accelerometer with some buttons on the real hardware before we had everything in place to use the real thing, but that wasn't very reflective of the more analog nature of the accelerometer. Thus, right from the start, the design required a good deal of flexibility with regard to the source of input data to the system. To that end, we took easy advantage of the component-based nature of C# and the .NET Micro Framework. Figure 11-3 shows the emulator we created.
Figure 11-3: Tahoe ball-in-maze emulator.
In creating the application code, we used a component-based design approach to isolate the differences in the development (buttons, simple emulation, real accelerometer) to a single interface for all of the devices. We then used a class factory design pattern for creating instances of the actual acceleration input device. That is, the creation of the driver components for the buttons, simple emulated accelerometer, or the real accelerometer was contained in a single class factory. The class factory uses conditional compilation flags that are set in the Microsoft Visual Studio 2005 project system to create a specific device instance and return the common interface to it for the application to use. Thus, the application needed only to deal with the common interface and the class factory, without worrying about which particular device was providing the input data. This isolation allows complete software development without real hardware. Thus, parallel development was possible when experimenting with things like the UI frame-rate performance and algorithms such as maze generation, collision detection, and simulated physics (of the ball moving and colliding with the walls).
With parallel development and testing of the main application independent of hardware, we actually completed the application before the first accelerometer add-on board arrived. We were even able to implement a significant portion of the driver for the I2C interface to the actual accelerometer used on the board, thanks to the extensible emulator. Unfortunately, as is often the case, the datasheet didn't describe reality in a nice, clean fashion, so the device driver for the chip didn't "just work" the first time. We did eventually figure out what the manual was trying to say (or more precisely, didn't say), and we fixed the driver to just work. That was a fun day, because we finally got to play with our new" toy." Without the .NET Micro Framework, the emulator, and the existing Tahoe development platform, we could not have made the system work in the time frame we had.
Working with the .NET Micro Framework was a real joy. The Visual Studio 2005 integrated development environment (IDE) and tools made life quite easy; IntelliSense and the extensible project and item wizards allowed us to further extend the system with our own Tahoe development kit and wizards, making developing applications and drivers even easier. No IDE we've ever used even comes close to what we were able to accomplish in just a few weeks with Visual Studio.
Besides the Visual Studio IDE, the .NET Micro Framework itself makes life easier by providing access to low-level system functionality like GPIOs and interrupts directly in C#. We were able to quickly whip up a variety of different approaches to a single problem to compare them for performance and other factors.
The ease of use of Visual Studio, the C# language, and the .NET Micro Framework Libraries cut the development effort by significant amounts. The fact that you can just connect the test device's board to the PC with USB and download or debug applications instantly from inside the Visual Studio is a huge benefit to updating flash memory via the Joint Test Action Group (JTAG) interface or other such techniques. Just hit the Start Debug button and the IDE compiles the code, downloads it to flash, resets the device to load, and starts debugging it! Could any embedded developer ask for more? (I think we all know that the answer to that is: Yes! We can always think of new things to add!)
This particular project is not intended to be an actual, so there wasn't much of a need to change to shipping mode from development. However, if we really took it to a product, we'd simply lay out a new board to contain the Meridian CPU, the accelerometer, a battery with a power switch and USB charging circuit, plus an appropriate case and voila! We'd have a product! Moving to production is an easy migration path when the CPU you developed on is available for production with the .NET Micro Framework already on it.