In my
last post, I presented the beginnings of a plan to connect an iRobot Create to an iCop SPARK computer running Windows Embedded CE R2.0. Now it's time to dive in and get some code loaded onto the iCop machine, then see if I can talk to the Create using the commands listed in the Create Open Interface.
Before I get started with Windows Embedded, I want to verify that I can talk to the Create using a known-good source, my desktop computer. I think this is an important debug step. Even though I'd like my software to run properly the first time, the truth is that it may require debugging before it functions correctly. I can simplify this debug task and verify that the Create serial interface is working by connecting it to my development PC and reading the boot message after power-on:
Once I've done that, I'm confident that I can establish a connection between the Create and my PC or the iCop box with my Windows Embedded program, and I can be confident any communications problems are a result of my poorly written program!
I already have Visual Studio 2005 and Windows Embedded CE6.0 R2 installed on my development computer, so I'm almost ready to connect the iCop computer. There is one more step required to fully configure the development computer so that I can begin Windows Embedded development. The different SPARK boards have a variety of processors and peripherals and thus require a unique software library and configuration set to allow Visual Studio 2005 to generate compiled code appropriate for the given low-level hardware. This unique library and configuration set is called a "board support package" for the obvious reasons. Each SPARK board vendor supplies a board support package that can be downloaded and installed for a specific board.
Now I'm ready to create and install the operating system and my application onto my iCop board!
I followed the directions in David Shoemaker's post series to get my Windows Embedded CE installation working to the point of running a simple application. There are four posts focused on getting going:
Things went well until I plugged my iCop machine into my development PC using a null modem cable and ethernet crossover cable. I was expecting to see bootloader information show up in my COM1 debug console as described by
David's Device Setup post, but I got nothing. Time to debug the debugger! My desktop development machine has two com ports built in. It’s very convenient to use one as a debug/download port and the second as application communication and command port. Using two null-modem cables (that should have come with my iCop box but were purchased locally instead!) I connected COM1 on my PC to COM1 on the iCop box, then did the same for COM2 of both machines. This way I capture any serial data from the iCop box. The Windows Embedded IDE supposedly has a built-in terminal emulator, but I was unable to locate it and chose to use Hyperterminal instead. I started two instances of Hyperterminal with settings of 38,400 baud, 8N1. It’s helpful to plug the null-modem cable in between COM1 and COM2 to make sure the serial cable is indeed a null-modem cable. Typing in one console, the entered text appears in the other, verifying functionality. I then hooked up my null modem cable to COM1 on the iCop box and expected to see boot messages, but saw nothing...
Actually, this isn’t too big a deal. I had no problems establishing the ethernet connection, following the instructions I found in the tutorials. After resetting the iCop box and creating a connection to it using Visual Studio, I was able to download the runtime image to the iCop box.
Again, following the tutorials, I built my first application, a simple “Hello World” demo:
I compiled and downloaded this program and crossed my fingers… and got "Hello World"!
Next week, I will take my working hardware and basic working code and add serial input/output to communicate with the iRobot Create.
Stay tuned!