In my previous post, I described how I was able to program an iCop eBox to transmit date using an XBee wireless link. The program was written in Visual C++ and executed serial port commands to send data to a host computer. I had previously set up the XBees to communicate at 115,200 baud, but the Visual C++ serial port configuration defaults to 9600 for the baud rate. I was able to find sample code for It was relatively straightforward to add code to my program that changed to baud rate to the desired value.
That’s when things got a little strange. I noticed that every time I ran my program, it would hang after the serial transmission. I also found that the program would crash if I tried to send more than 16 characters. There’s a long list of possible causes for these crashes, and I started to debug them one by one. The important part of this story is the outcome. Honestly, debugging can be unpleasant. I like a good challenge and have always enjoyed solving puzzles, but that’s not how I wanted to be spending my time with the SPARK projects. So back to the outcome of the story. After taking many small steps backwards in the debugging process, I finally managed to make a huge leap forward, out of programming darkness. I now have a Visual Basic program running on my iCop eBox, and it’s sending and receiving data from another computer using XBee transceivers.
Why is this great? That’s a fair question.
The promise of Windows Embedded CE 6.0 is that I can use low cost, low power x86 compatible computers to run sophisticated, real-time, fault tolerant programs. Also, developing these programs is facilitated by a well designed set of high level programming languages with extensive libraries and comprehensive debugging tools.
That’s the promise, but what’s the reality? If you’ve followed my previous projects, you’ll get a feel for what was required to get to this point. The learning curve can be steep, and there are many places to get off track. I’ve been frustrated by the lack of a simple “quick setup”, a starting point with pre-configured BSP, OS image, basic application, and download tools. After spending several days making small corrections to the BSP, tweaking the components included in the OS image, and rebuilding it, which takes 30 minutes or more on my PC mind you, I finally found the right combination of settings. That would have been a moment of pure joy, except it happened at 3am when I really wanted to be asleep, and I don’t think it should require as much effort as it did to get to this point. This might be just a difference in philosophy, but I find it interesting that the book I used to learn how to develop for the Analog Devices Blackfin introduces the reader to hands-on programming on page 9. The book recommended to me which I’ve been using to develop in Windows Embedded CE doesn’t begin to cover programming until chapter 10, 197 pages in. I will say that this book, Microsoft Windows Embedded CE 6.0 by Samuel Phung, has been a huge help. I might have had more confidence if the author looked a little happier.
Microsoft really has a good tool in Windows Embedded CE, but with some small improvements, it could be a great tool for the do-it-yourself and robot communities. Developers who are just getting started should be able to focus on application development, and not worry about the BSP or OS image, at least initially.
As for me, onwards and upwards. Now I’ve got something that I can work with. I can rapidly develop and deploy code and a GUI. I also have working XBee code. For my next post, I’ll add some features to my program to actually control a device using the XBee and Windows Embedded CE.