Providence, Rhode Island is home to many larger than life characters. One that has special meaning for me, and is arguably one of the most iconic characters, is New England Pest Control's giant blue mascot, Nibbles Woodaway. I've always found programming fun and interesting, but the true challenge for me is trying to figure out why a program doesn't work the way I want, and then figuring out how to fix it. I often find myself thinking about the exterminators at New England Pest Control celebrating their profession with a monster sized termite while I dive into the nooks of my programs to eliminate bugs that prevent proper execution (and eat into my sleep schedule!)

Last week, I set up my iCop SPARK hardware and got a simple "Hello World" program running. That process took some time, but wasn't too difficult. Of course, sending text to a console window is not very useful for controlling my iRobot Create. I need to add serial send and receive functionality to my code in order to control the robot. So this week I put together a simple program designed to send and receive characters over the serial port.

The first step was to decide what kind of application framework I wanted to use. Windows Embedded CE code development looks a lot like any other Windows code development using Visual Studio 2005. Applications can be written using Visual C++, Visual Basic, or C#. I found several good native-code application examples for controlling the serial interface written in Visual C++, and decided to start there. The code looks fairly simple:



I built the program and downloaded the image to the iCop computer. This time, I noticed something interesting. The iCop computer uses COM1 (on the iCop box, not to be confused with COM2 on the host PC) as a serial debug monitor by default. My previous attempts to observe the debug text stream were fruitless and I just got a blank screen. This time I got continuous output from the iCop box, a reassuring sign that the maching was functioning and the serial ports were accessible.



I couldn't easily find reference material to decode the meaning of the serial debug output, but this was solid confirmation that at least COM1 worked. My program is designed to use COM2 as the serial interface to the iRobot Create, so I made no attempt to disable the debug output. It is useful to know that something is happening while code is being downloaded or the system is restarting.

All was good until I tried to run the program. As expected, the console output read:

"Creating CE_Demo.txt file V0.0018"

But the next line read:

"file write open errors"

This was not what I was hoping for, so I put on my exterminator's hat and went searching for the bug. The first thing I did was switch the program com port to COM1, since I know it works, even though it is used by the debug output. This time, I didn't have any problems opening, writing, closing, opening, reading, and closing the port. That was a good sign, but I still didn't see any output on my host computer, where I had a second terminal window (in addition to the debug terminal) open to watch for messages sent from my program. Thinking that COM1 would be blocked by the debug monitor, I looked for a way to disable it and use COM1 for program communications. This is easier said than done. There is a parameter file, "platform.reg" which controls the configuration of the ports:



Unfortunately I didn't see any key that tied the debugger to a specific port. For now, the bug search continues. Any ideas? Let me know. Otherwise, stay tuned until next week for more!