We embedded people are concerned about meeting all those stringent deadlines as well as debugging our systems which steadily increase in complexity. I’ll write some of my thoughts concerning those topics and some more in a series of articles. Send me your comments and questions. I’ll post the most interesting ones here.
But now let’s start talking about bugs.
By Robert Berger
Development Cycle
Last time we talked about the development cycle. Does the good old waterfall still work for you or do you use Agile methods with continuous integration?
Many tools end up as shelfware and some contracts to get those tools require you to give your first born. What I’m talking about here can be done with free tools. I really hope you do use a bug tracking system, a version control system and some documentation system. If not have a look at bugzilla [1], git [2] and wiki [3].
If you want to be fancy you can hack a bit the web interfaces and create some integration between those tools. It has already be done for cvs/svn-bugzilla-wiki [4]. There are good and bad tools. Make sure you define your development environment so people know which tools should be used what for and how. I usually devide teams into framework people and developers. The framework people are in charge of toolchain, bootloader, kernel, board bringup, customizations. The deveopers develop the application and maybe some drivers.
In case of many different platforms and a common code base I use a single place for the sources and this is exported to what I call build hosts. You will also need some nfs export or somehting similar which the targets can mount in order to try new versions of your software. The cross toolchains have usually dependencies on the host OS so you might end up with many different Linux distros. A developer will just mount the sources from his workstation, which can be pretty much everything from Linux to BSD to OSX to Windows. It really does not matter.
A developer can use his preferred tools, although I believe that Windows is just in the way if you develop for Linux. In order to build a developer just opens an ssh session to a buildhost and toolchain, libraries and header files are already awaiting him/her. The most important tool is most likely your editor, but to get firmware out of the door to your customer you should ask yourself if your build is reproduceable for the lifetime of your product. We’ll see next time how this can be achieved?
References
[1] http://www.bugzilla.org/
[2] http://git-scm.com/
[3] http://www.mediawiki.org/wiki/MediaWiki
[4] http://oss.segetech.com/integration.html
Author
Robert Berger consults and trains people all over the globe on a mission to help them create better embedded software. His specialties are trainings and consulting in the broad field of Embedded Software from small Real-time Systems to multi-core Embedded Linux. You can contact Robert here:
mailto:ed-pee@reliableembeddedsystems.com