We recently kicked off Gangplank Labs over at Gangplank and for the last month or so I have been working with the Arduino microcontroller, XBee wireless, Epilog Laser Engraver/Cutter and a slew of sensors. I do not have a background in Electrical Engineering and have never really played with the embedded side of development other than the Basic Stamp starter set when I was younger, so I dove head first into this relying on my experience in software development. That got me off to a good start, but I hit road blocks I had long ago forgotten about.
In this day and age of cheap processors, cheaper ram and even cheaper storage all on a virtual machine out in the ether of the internet it is easy to lose site of some of the problems experienced in the past and even easier to over come those problems by throwing more “power” at them to improve performance. Well, that luxury doesn’t exist in the embedded world. Yes things have gotten better and cheaper, but they still have a larger impact on your design than spinning up an instance with Amazon AWS. That was my first problem, the program has to fit on a limited and fixed storage device. I couldn’t just keep including libraries to make development easier. I had to get selective, creative and sometimes even roll my own. I found myself reading the source of the libraries in much more detail than say a gem I would include in a Rails app.
Then there was the actual design. Not just the case design, but the actual hardware and component design. Being new to the space, I am unfamiliar with all the different chips and design patterns available and that showed. Once I maxed out my available inputs and outputs on the Arduino I had to once again get clever. Fortunately, I had a few people around I could tap on the shoulder and they pointed me down the right path. The problem here is that I have to order what I need and wait for it to ship to me (and I am very impatient). The first couple of times this was ok, but then every time I would iterate over the design and find a better solution I would have to place an order and wait. This caused me two unexpected pain points. It was starting to increase the cost unnecessarily and it was starting to delay the project. Being used to downloading and purchasing digital licenses had spoiled me. A little more design and planning up front could have save me a couple of weeks and a few bucks.
Updates are also not as easy. This is a lot closer to desktop development, but even they still have it easier. If you want to auto update that means increasing your cost to include an ethernet or wifi chip onto your device which could put it out of the affordable price range. This really means updates have to be performed like a good ole firmware update. Download the update, connect the device, click run and pray you don’t brick your device. QA is very important here. Test, test, test and test. Not unit tests, I mean hands on field tests. Once you release the device to another party you have no guarantee you will ever get to patch a bug that is in it. Not to mention what if it was hardware and not software causing the bug?
What did I learn? Slow down and think about how my design impacts project more thoroughly. Be selective and include only what you need. There is not enough room for the kitchen sink. And test, test test. Make sure everything is working as planned and is stable.
I would recommend any developer out there grab their team and a few Arduinos. Create a couple fun project ideas that take additional hardware, pair up and go implement them like you would in your software development world. Let the issues come up, deal with them and then think about how it differs from your development world. After your little retrospective see if there is anything you could bring back to your development team that could help you improve your process.
