RSS
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 and it was relatively straightforward to add code to my program whichchanged the baud rate to the desired value.
Then 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 such 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 these 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 so great? That's a fair question. Read on at the SPARK site for the answer!
I think your hardships started with Visual Basic, it's a terd, especially when trying to work with peripherals. Still, a cool project so far. I like embedded windows for several of the same reasons you have endeavored down this path. Keep up the articles!
Reply to this comment
My guess is the program was hanging because the serial buffer was overflowing. You probably need flowcontrol turned on in both the host and xbee. Xbees have a data-out buffer of 100 bytes i think.. so it might be a baud rate mis-match too.
VB is great for mashing together a small gui app. But i'd urge you (and anyone!) to avoid it like the plague to prevent you from becoming too invested and locked in. When you try to develop your app into something larger, you'll quickly run into limitations. Moving from VB to C# would probably be the easiest migration path for you. Plus that opens up linux for you with Mono.. though System.IO.Ports in mono is... horrid atm.
Reply to this comment
I had been thinking it was a buffer problem as well. That would have been easier to troubleshoot. It was actually changes I made to the board support package and registry settings that caused the problem. In the process of trying to disable serial debugging on COM1 and also enable COM2, I must have done something bad to the BSP. When I swapped interrupts for COM1 and COM2, I was able to get COM1 sort of working. When I also did a clean install of the BSP, I got a fully functioning COM1.
I agree with your thoughts on VB. I wanted to start with tested code and get it up and running fast. I was working from Samuel Phung's CE book at http://www.embeddedpc.net/, and the sample code was in VB.
Reply to this comment
If you want to get even more extreme, take a look at API mode. It's a little more complicated but also more powerful.
Reply to this comment