It's good to have a hobby ...
By tpm on Apr 25, 2009
Inspired by Tom Igoe's excellent articles in volume 14 of make magazine, called "Wireless Motion Sensing Made Easy", I've been playing with XBee 802.15.4 modules. These are Zigbee wireless endpoints in the form of little $20 circuit board modules that can can encode both digital and analog inputs to allow you to easily build various kinds of wireless sensor endpoints into wireless sensor networks. Here's one of mine next to a dime. You can see the fractal patterns on the 2.4GHz chip antenna at the top.
I used an XBee Explorer board from sparkfun.com that connects (another) XBee radio to any USB port using the FTDI FT232R serial chip to create a self-contained base station. You can see the mini USB socket at the front - and the other end of the cable I use plugs into a regular USB port on most computers. Here's my base station fully assembled!
My initial experiments were done on a Mac because I don't have a (physical) Windows machine, and so that was the path of least resistance to follow the make article and to be able to use the associated resources. Though I was pained that I had to use Windows to run the firmware updater for my XBee radios, I was thoroughly cheered up by the fact that I was able to use VirtualBox to host XP to do the update.
After I got things to work, I poked around the sparkfun site to look at some of the other things those guys have, as well as other sites, and I began to realize that the FT232R chip was pretty widely used as an interface device - though of course there are many similar devices out there in the same vein. So, I wondered just how hard it would be to put together a USB driver for opensolaris to support the chip. Particularly after I'd switched my everyday laptop back to opensolaris -- a few weeks before 2008.11 was released -- and I really wanted to see if I could get my XBee hobby going on my opensolaris laptop instead.
After a bit of noodling on the opensolaris Writing Device Drivers book , and applying the usual technique of creating a driver by cloning another driver in the same category from the opensolaris code base, it turned out to be a lot easier than I'd expected. I got a prototype working after a couple of Sunday afternoons. And after a few minor skirmishes with Java, I got the Processing development and runtime environment to work on opensolaris, and I was able to get the 3-axis wireless accelerometer I'd built to work over XBee via my usbftdi(7D) driver. Tom's XBee code now worked just as well as it worked on MacOS.
Hopefully I'll get a chance to write more about motion sensors, the other software components I had to tweak, and my experiences with getting Processing working on opensolaris in future posts.
Originally, I thought this was all just for me to experiment with, but after I happened to mention that I had this working to a couple of people at Sun, it turned out that a few of them had been experimenting with this device in various contexts, or they knew someone who had, and they all asked me to put it in the opensolaris distribution. In fact, as I poked around, I found that a number of other interesting embedded items were using the FT232R as an interface e.g.:
- The host interface for the open source Arduino electronics prototyping platform e.g. the Duemilanove.
- A breakout board and other items related to sensor technologies including miniature GPS receiver modules.
- A USB device in a "stick" form-factor containing a high quality random number generator from a different supplier.
Though it's a slight diversion from the story here, I can't resist posting a picture of a miniature GPS receiver attached to an FT232R breakout board. The green board on the left holds the complete GPS receiver; the small oblong on the extreme left is another chip antenna. The red board is the sparkfun FT232R breakout board.
Yes, that's a transparent Lego element taped to the breakout board -- a bit of double-sided tape holds it nicely -- though of course it's upside down in this picture, so you can't actually see the chip, or get a clear look at the mini USB connector that is slightly protruding on the right hand side. Obviously this is kludged together from prototyping boards, so it's a lot larger than it needs to be. I've removed the other Lego elements I use to protect the circuitry from harm so that you can see the receiver more clearly. I'll try and write some more about my experiences with the GPS software that talks to this hardware in yet another post.
Meanwhile, back from that diversion ... so as I began to realize just how handy this little interface chip was, what started as a "holiday project" and a Sunday afternoon hobby suddenly seemed a bit too useful for the device driver it to simply stay at home. Not because it directly addresses Sun's core mission around computing infrastructure, or has anything particularly to do with virtualization (my day job), but because it's fun, and fun encourages adoption, and adoption further expands the use of opensolaris into new domains. But in the end, the thing that pushed me into making the driver be part of the product was a real business opportunity involving support for the random number generator "stick" above.
And so my hobby intruded on my day job more than I originally planned, because on Easter Sunday afternoon, I integrated support for that device in the form of the usbftdi device driver into build 113. You can find the driver source code by looking for uftdi_dsd.c and usbser_uftdi.c using opengrok on opensolaris.org. Please send me code review comments -- especially if you find bugs.
In the past few years, I've spent more and more of my time on planning, architecture and oversight of other projects, and what code I have written has been integrated as part of the work of a project team i.e. someone else dealt with the responsibility of getting the work signed off and integrated. So from a code review, legal review, ARC review, documentation, the RTI process, the joy of testing, and of course the vagaries of the builds and my unfamiliarity with mercurial, it was good to be reminded of what an engineer has to go through to get working code delivered. And fixing, in build 114, a bug in the package I'd integrated in build 113 also reminded me of how difficult it is to get everything right first time. Since this wasn't my day job, i.e. it was a continually interrupted background task, it took a lot longer to get this done than I expected, which contributes, I think, to the feeling that I climbed a small mountain!
It was a very useful experience to me both in terms of finding a couple of issues that I'm going to try and improve in the process, as well as simply recalibrating my sense of what's involved in the details of getting OS technology delivered. It's all too easy when managing software projects to dismiss every problem as a SMOP (a simple matter of programming). And of course the simple sanity-inducing joy of working on bugs, finding solutions to them, and making the code base a better place was welcome too. For example, I found and fixed a bug with the generic USB serial support in opensolaris that caused any lwp issuing some of the slightly more obscure ioctls to simply hang, I added more termio ioctl decoding to truss, and upped the highest speed serial port a serial device can support to 921600 baud.
Of course I also had help: thanks to the USB team in Beijing -- Strony Zhang and Lin Guo -- Lin was particularly helpful for both code review and by patiently helping me do the right thing with warlock; to Jim Carlson for code review and advice on the opensolaris serial port architecture; to John Downing, and Mary Ding for help with testing; to John Weeks for trying the driver out with Wiring on his Arduino board; to Jerry Gilliam and Mike Sullivan for RTI and packaging review. And thanks to Patricia Levinson for fixing and integrating my somewhat approximate manpage.
Summing all this up, as of build 113 opensolaris has support for devices that use the FT232R interface and its clones. Plug one of these devices into a USB port and, like any other USB serial device, it will show up as /dev/cua/number and behave like a terminal device. Have fun with it!Technorati Tags: virtualbox, xbee, arduino, opensolaris.