EMBEDDED FIRMWARE DESIGN

Unlike with a PC or Android device, the programming language for every microcontroller is different.

At RioSH we provide firmware design and manufacture of custom embedded systems in India mostly for embedded devices based on processors from STM32 and PIC32, and we take care to properly structure and annotate our code so that it can be easily updated or reused for the next generation of the device, even when a different engineer takes over years later.

RIOSH GOOD PRACTICES FOR EMBEDDED FIRMWARE DESIGN

RioSH works for Western B2B companies which expect to sell and upgrade a device (-family) for many years to come, and for which robustness is of critical importance. So we work really hard to ensure we deliver Reliable Firmware though a Reliable Process.

Among coders, it is a well know reality that more than 70% of FW development time is spent refining and debugging code, as many unforeseen events will inevitably arise from the firmware interacting with the hardware. The easier it is to read the code, the faster we can find the bugs. Quality code not only assures the robust functionality of the product but also speeds up the time to market.

WE ENSURE OUR FIRMWARE RELIABILITY THROUGH 5 MAIN INITIATIVES

RIOSH GOOD PRACTICES FOR EMBEDDED FIRMWARE DESIGN

1. Focus on coding in C for STM32 & PIC32

For quality and price/performance we strongly favor STM32 and PIC32, (see Electronic Product Architecture) and while we do develop in other languages (Javascript, Python, Lua, C++) during prototyping or PoC (Proof of Concept) stages, we have found that there’s nothing as efficient, robust, well studied and optimized for MCU’s like C. Having such a narrow focus means we turn away a lot of interesting projects, but it makes us really good and efficient in what we do.

2. Use generally accepted Firmware Coding standards

At RioSH we follow Steve McConnells’ principles and adhere to most of the Linux Kernel coding style.  All our source code is internally audited against our checklist of 107 firmware coding principles, at least once per quarter. Projects receive internal scores and priority ratings for refactoring. Most of our designs allow for user-friendly or OTA (Over The Air) Firmware upgrades.

3. Team build up and cross-training

We have at least 4 electronics engineers on each project, two acting as FW developers, one as HW developer and one for QA. Two FW engineers may sound redundant but in practice, it increases efficiency by 30% to 100% due to faster debugging.

Some of the toughest bugs are at the interplay between Hardware and Firmware, and we have found that multidisciplinary training really helps problem-solving. Even if an engineer is 100% dedicated to FW, he will receive training on PCB design, PCB troubleshooting, RF, EMC and manufacturing, even mechanical design, so he is aware of the challenges and opportunities of adjacent disciplines.

4. Quality Assurance: Design For Testing

QA is not about lots of testing, it’s beginning with the end in mind. We carefully and methodically define a matrix of requirements and their test procedures, so that code is compliant enough such that most testing becomes unnecessary.

By ensuring a high level of test-ability throughout development and production, we speed up validation and industrialization of our designs.

5. Documentation

At a high level, we document every project through internal Evernote-based wikis.

The most important elements of our documentation are:

– Well-built readme files for every repository, including all necessary instructions to review, compile and test the code

– Repositories management

Effective version control is a storyline which depicts the evolution and decision-making path of a project, as well as the user manual for reusable code. All source code is Doxygen compatible and all releases are properly tagged so automatic changelogs are created. We believe in the advantages of following git-flow, enforce conventional commits and implement a slightly modified flavor of semantic versioning.

WHY ROBUST FIRMWARE SPEEDS UP YOUR TIME TO MARKET

Producing accessible code written following standard practices means that our engineers work more efficiently, and your engineers and third parties can easily explore and understand our code. This speeds up communication and problem solving, enhancing Time To Market.

Our standards ensure not only reliable code but also a reliable coding environment; if one engineer is unable to continue, another engineer can easily take over their work. In this way, we can avoid serious delays.

Asian countries are not especially known for their prowess in firmware development. Part of this may be due to the fact that for consumer electronic devices like phones the life cycle is often just 6 months, so most coders are scrambling to slap some code together to get it to work Cha-Bu-Duo “more or less OK“.  This is why RioSH has most of its firmware written by our engineers in (or from) our office in Colombia. Being in the US time-zone also facilitates cooperation with our North American clients.

×
×

Cart