Embedded system design with open source software: doing it right
Software development is challenging. Embedded software development targeting the newest breed of devices is even more challenging. The additional hurdles faced in this sector of technology are largely down to the rapidly escalating lines of code being deployed inside devices that must deliver a more consist look and feel to conventional PC user interfaces if they are to find commercial success.
The complexity of software systems design within the embedded space can escalate rapidly given the potential breadth of obstacles faced in typical deployment scenarios. Modeling software programming architecture in this sector poses additional challenges to those faced in a traditional PC- or server-based development environment, due to the 'locked in' nature of the software when it is a the post-deployment stage inside of a device.
Before exploring the potential of open source software (OSS) for your embedded device development, you need to ask yourself why you have chosen this route as opposed to any proprietary platform or toolset.
Test for OSS robustness
Have you chosen OSS for embedded to try and save costs - and if so have you accounted for the full costs of provisioning for support and service when this becomes necessary? Is it to work with bleeding edge open source products that might offer the greater power and flexibility you need for a complex embedded deployment? If so, has the code in question been enhanced and evolved enough to offer some reasonable level of robustness?
What you need to remember is that integrating software on hardware is tougher with embedded than it is with desktop systems because there is just so much variety in terms of the hardware itself. What we are talking about here is the provisioning you will need to make for drivers as well as considerations higher up in the software stack.
If you have a collection of binary drivers they may not necessarily work. To fix this, you need the source code for re-fitting the drivers to get them to work on your hardware. Even when you have a working proprietary driver on one hardware configuration, it might not work on a later version. With open source software you have a chance to fix these issues. But with proprietary binaries you need to ask the vendor to fix the issue, which might delay your project considerably. This also goes for the complete software stack, including the UI layer.
What development methodology works best?
Most industry commentators would not propose that an Agile or Extreme programming methodology would work best for the embedded space, as these models typically work more effectively for lighter weight applications. In this space, the use of iterative development models provides an arguably more rapid system build as the project progresses towards the end game, i.e. enabling a shorter time to market.
An embedded GUI is different
An embedded GUI might not look like a desktop application at all. An embedded application is often task-driven with a simplified input mechanism, either via touch screen or a limited keyboard. The screen size is often much smaller than a desktop and you don't get a desktop mouse. This changes the whole user experience, impacting the overall design of your application.
You will most likely run your application development on a PC, emulating the embedded device. If you decide to use an application framework such as Qt, running the application might also work fine on a PC. But you should plan and design the application for the task at hand, making the user experience good for a smaller screen with touch screen or a limited keyboard.