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 with B2B companies that expect to sell and upgrade a device for many years to come, and for which robustness is of critical importance. So we work really hard to ensure we deliver Reliable Firmware through 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 & NRF52
For quality and price/performance, we strongly favor STM32, PIC32 and NRF52, (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
All our source code is internally audited against our checklist of 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, and 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 that most testing becomes unnecessary.
By ensuring a high level of testability throughout development and production, we speed up the 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 that depicts the evolution and decision-making path of a project, as well as the user manual for reusable code.
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.