Our experience is that many embedded software development projects are made unnecessarily difficult by the lack of open specifications of the underlying hardware. The lack of documentation prevents the open source community from developing robust and easily integratable drivers for that hardware. Instead, what we find is that much driver and software feature development is done behind closed doors, with binary drivers being common for newly released chipsets.
We believe that the problem is twofold. First, in selecting a hardware platform for a next generation product, the quality and availability of open specifications and software drivers is (in our experience) rarely a major factor. Instead the determining factors are cost and the promised feature set of the new SoC. Secondly, whereas available development time before deployment is usually very scarce, when a deployed system exhibits unstable behaviour there is usually no limit to the resources that will be spent on tracking down the bugs responsible. This is in essence a budgeting problem, where robust driver development is being starved for the benefit of chasing down bugs in deployed systems.
Our view is that we can only build a stable system by understanding the parts that it's composed of and ensuring that they are indeed robust. We feel that the only way to do that is study comprehensive hardware documentation and preferably preexisting, peer-reviewed, driver implementations. A major benefit of this approach is that time spent on learning the details of the hardware platform is cumulative, whereas chasing random bugs in a system we don't really understand does not in a meaningful way lead to learning over time.
While we rarely are the ultimate arbiters of hardware selection and development budgeting, we make it our mission to influence those decision makers that are wherever we can. Our view is that if we don't take every opportunity to push for a better development model, no one else will do it either. It's the developers themselves that struggle daily with implementations that are difficult to understand, not higher level management. Therefore the responsibility of advocating for a better way of building products lie with the developers themselves.
To summarize, we believe that the the open source development model holds the potential for achieving more stable products with less mysterious bugs after deployment. To fully utilize the potential of this model, we advocate always using the chipsets with the best available documentation and open source driver support, even if that chipset looks slightly more expensive at the outset. If open source drivers are not available, we think that the time and effort to develop them should be invested before deployment as time spent here will pale in comparison to what would otherwise be spent on debugging an unstable system in the field. It's our view that this approach will in the long run result in both happier customers and developers as both parties gain a deeper understanding of the systems they are building and using.
We believe that the best customers for us are technology intensive companies with at least some technically proficient staff of their own. We prefer to deploy full time consultants on longer time frames to supplement the existing technical organization of the customer. We're always curious to learn more about new customers and their products. If you are a prospective customer and would like to know more, please send us an email at info@embeddednation.com.
When recruiting, we are first and foremost looking for people who are passionate about hacking and tinkering with hardware and software. We think of ourselves as lucky to be able to work daily with development that we would do anyway in our spare time. In addition, we want our consultants to have a history of demonstrated technical and professional ability. If that sounds like you, we'd love to hear from you. Send us an email where you include your CV at careers@embeddednation.com.
Userspace interface between Broadcom DECT kernel driver and Asterisk channel for the Iopsys software platform. Assignment ranged from initial prototype to full scale deployment in several markets.
Software infrastructure for mass production of secure boot enabled Broadcom hardware. Assignment included visits to factory in China for hands-on integration with production systems.
Modification of boot loader to add support for NAND flash memory.
Integration of proprietary Linux kernel with the OpenWrt distribution. Assignment included responsibility for overall software architecture for future products for customer. Worked closely with top management of customer company to ensure project quality and timely delivery.
Upgrade and maintenance of an Astersik telephony server for two medium-sized companies. Responsible for both hardware and software platform.
Developed an MDB (Multi Drop Bus) to USB converter to be used in a text messaging payment solution for vending machines. Assignment included both hardware and software development.
Developmen of a proof-of-concept for a router middleware based on an open source distribution for routers.
Modification of boot loader to enable port of a commercial router middleware to new hardware. Added support for AES-encryption.