Developing Firmware for Embedded Systems does not only take a lot of knowledge about software development but also some about hardware development. So designing hardware and firmware goes hand in hand. Basti, one of our hardware developers already shared his top five tips on prototyping hardware with you, so now it is time for Josh and his team to list their top five tips on how to develop a prototyping firmware.
-
Make use of tools
As simple as this one might seem but using tools is one of the most valuable things. There are many tools out there that simplify firmware development. An integrated development environment can do a lot of good things for you. The IDE can auto-complete your code, show the documentation of your classes while you are using it, organize the build process, auto-format your code, highlight your code so it gets more readable and much more. All these things make developing a bit more efficient and most importantly they automate the less pleasant parts of embedded system development. -
Know your operating system
If you are using an operating system of any kind you need to have a decent idea of what it is doing. Have a look at how tasks and schedules work, check your configurations, get an overview of how inter-process communication works, so your code will not produce any strange errors and crashes from using unprotected global variables. -
Check in with other embedded developers
You are not the only embedded developer out there. Remembering this can spare you a lot of time and work. Check public source controls such as github, gitlab, source forge, only to list a few, for libraries that you need before you write your own. If you need something, there is a high chance that someone will have written it, and probably nicer and better than you would have on a time crunch. But keep an eye on licensing before you start using libraries. Another helpful step is to let your code be reviewed by another developer. -
Start writing your code top-down
Graphically working out your code allows you to discuss more complicated parts of it. One possibility is using Unified Modelling Language. One of our preferred software tools Mermaid does support some UML diagrams for github and gitlab. Tag these diagrams on your current branch. But even putting just labeled squares on a piece of paper and connecting them with arrows will help you structure your thoughts and get some clarity. After having a module wise overview of how things should work, start writing the headers, then the source code. If one module uses stuff from another module, add it to the header and use it like it was already implemented, your future self will have to bother with how it works.
Two rules of thumb:
– Separate out classes if it makes sense. Immediately create an own header and source file for it. One class represents one abstract construct of something you define!
– Use meaningful names for variables and functions. One function does one thing it describes in its name. No more, no less. The user should not have to bother about how your function works! -
Use source and version control
Source control is extremely useful when you are not the only one developing the firmware. Everyone involved will know what the latest version is, you can easily branch and merge code. But even if you are working alone, source control can help you by providing a window into the past, aka being an infinite “STRG”+”Z”.
Learn how to handle rebases and merges as well as using git flows. Try this before you start using it on an actual project, but it will spare you the tremendous pain of constantly having to refix and reimplement stuff you are sure you already had done.
All these tips may sound very simple but, in the end, you will have developed a lovely code that works and is easily adjustable later on. The more time you spend at the design phase the less backtracking you have while developing the code. Like everything in life, practice makes perfect. With these tips in mind, have fun developing and hopefully these can spare you some frustration.