July 30, 2020 | 4min read
What Rules to Follow When Working on an Embedded Systems Project?
Embedded system is a combination of hardware and software. In simple words it’s a mini-computer with peripherals that control the sensors, and it usually has one specific function (for example to open a door). Modern embedded systems usually contain System on a Chip— an integrated chip that contains a microcontroller, RAM memory, Flash memory, input/output ports etc.
If you have specific, custom project requirements that you can’t achieve with a simple mobile app—embedded systems are perfect. For example, you want to measure the acceleration in some vehicle. Of course, your phone can do that, but if you add additional constraints like small size, dustproof ability or even cost it often makes much more sense to go for a custom, small, embedded system to do that. Embedded systems projects give you more freedom: you don’t have to rely only on the phone’s set-up functionality—you can, for example, make your wearable screen work and look however you want. Additionally, very often an embedded device connects (via BLE, Bluetooth, Wifi etc.) with a mobile app, which serves as an extension or additional interface for your product.
Here’s what you should look out for in your development team for an embedded system project:
- They know a lot of hardware platforms, like Embedded Linux, STM32, nRF, ESP32 and others.
- They are experienced in the newest standards of C/C++ language.
- They can use real-time operating systems (e.g. FreeRTOS).
- They provide holistic design of the complex embedded software architecture.
- If that’s what your project requires—they are capable of delivering end-to-end IoT projects (embedded software, mobile apps, connectivity, backend).
- They are aware of software profiling and optimization tools.
- They can optimize power consumption of your device.
- They offer hardware prototyping and hardware debugging.
- They are skilled in developing connectivity solutions (WiFi, BLE, Bluetooth Classic).
- Do code reviews—Seems obvious, but in the embedded systems engineering world code reviews are sometimes still being forgotten. Which is a shame, because code reviews can save you a lot of money and time. It allows developers to pick up on the early, significant bugs and fix them before the code is released. The costs of fixing the bug after the release are way bigger than doing it in the development phase. Code reviews also give space for less experienced developers to learn from the senior ones.
- Write automated tests—Because by definition embedded products are a combination of hardware and software—it’s harder to test the whole solution. In case of a mobile app you can click through it and usually quickly tell if something is working or not. With an embedded project setting a complete test environment can be difficult (e.g. when it has to be able to send/receive data from far away). Since testing the whole system is challenging, it’s important to focus on the test-driven development approach—writing a test first and then the functionality, developing and testing as you go and not leaving it for the end of the process. The dream here would be an automated testing framework for testing the whole embedded system (both hardware and software), which for now is within the budget and capabilities of only huge enterprises.
- Set up Continuous Integration—Thanks to continuous integration, every added change or code update in the repository will automatically kick off unit tests. Again, this will give your developers some peace of mind as well as save you time and money later on.
- Get debugging skills—You should have in your team people who know how to diagnose hardware issues, as not all problems are caused by firmware. The right experts will audit and debug your device or prepare a detailed report for your hardware provider of what is wrong.
One of the main requirements our clients come to us with is the possibility to update firmware remotely, once the product is on the market. It’s a challenging task if you want it to be done in a secure way. It’s best to start designing a firmware update procedure at the beginning of the project—sometimes, you may even use a solution already prepared by your chip vendor. However, this becomes harder the bigger the embedded system you’re dealing with is (if you have few MCUs and the firmware has to be updated on all of them). It can be tricky to make sure that all of the components are updated successfully and that you have a way to roll back in case of failure.
If you have any questions on embedded systems or you’re starting an embedded project yourself and looking for the right partner—get in touch!
Lead Software Engineer