Small and simple, the iCOP eBox is a fanless x86 computer with solid state storage.

I began my second SPARK project with plans to control my iRobot Create with an iCOP computer and Windows Embedded CE 6.0R2. There were many project design lessons reinforced by my first SPARK project, and I applied those to lessons my second SPARK project. Even though I was working with powerful tools, Windows Embedded CE and the SPARK kits are complex systems. It is important to start with very simple expectations, get the basic components to function, and then design in complex features. With this focus on simplicity, I set about writing Windows Embedded code for the Create. After tracking down the necessary documentation for the Create's programming interface, I started with a simple "Hello World" program, and documented the process here. My next step involved sending and receiving data over the iCOP computer's serial port. Very quickly, I found myself editing registry code to enable the serial port for application use. Why did I need to do that and what were the results? The answers to those questions require a discussion of several intermediate steps which bring clarity to the structure and design of a Windows Embedded CE application.

I have noticed that most of the embedded computing development systems that I've worked with are either configured to run on a very specific set of hardware, or require customization. This makes perfect sense to me. As a developer, I want to know that my programs will have an appropriate memory footprint. Some tools, like the Basic Stamp, have a development system and firmware that are fixed and specific to a particular embedded controller. Windows Embedded can be targeted to fairly wide range of hardware. To ensure applications can be deployed on a given set of hardware and without the overhead of unused modules, Windows Embedded requires that hardware manufactures provide a “board support package” to connect hardware with low-level software functionality like serial port input and output. Windows Embedded also requires the developer to customize the operating system for a given application so that unneeded code is not included in the code development process. To simplify this process for a number of generic applications, a design wizard is provided:



Individual components can also be specified using the wizard:



The customized OS is then downloaded to the target. After being downloaded, I can create and run applications like my "Hello World" program on the iCop computer. But what if I want to switch certain features on and off? For example, I want to use the serial port for communications not debugging, and I don't want to build a new operating system image every time I want to make a change such as this. These settings can be configured by changing registry settings. Also, I can override registry settings by changing registry source code. This brings me back to the my iRobot Create project. The iCop computer has two serial ports. I've written a program that communicates with the Create using COM2, and uses COM1 for debug. COM2 gives me invalid handles whenever I try to open it for communication. Since I can see that COM1 works, can I override the debug function and use COM1 for communication instead of debug? The answer appears to be "yes". The following code shows where serial port debug is defined:



So now I've solved the serial communication mystery, right? Unfortunately my code and various demo programs I've found still don't work. I'm beginning to suspect a hardware issue, so it's back to the drawing board and debug console!