You have a vague notion of what firmware is. You know that it is essential to make your product work, but you do not know exactly what goes on behind it. Embedded software is indeed what gives life to your
You have a vague notion of what firmware is. You know that it is essential to make your product work, but you do not know exactly what goes on behind it. Embedded software is indeed what gives life to your
You have a vague notion of what firmware is. You know that it is essential to make your product work, but you do not know exactly what goes on behind it.
Embedded software is indeed what gives life to your product. It’s what makes it work and work well. It is what will dictate its main functions.
But how do you build embedded software? What are your choices?
Is there a better way?
Then come on board with us. On the agenda: presentation of the different possible solutions, determining criteria for building your embedded software and strategy to adopt for efficient and well thought-out updates!
Let’s get started!
The firmware is the embedded software that allows the product to function. But also and above all, to make it evolve infinitely thanks to updates that you can carry out remotely, and (all) this without needing to replace the product or to review its design.
This software is ported to a microprocessor or microcontroller.
The firmware is what enables the devices to perform their basic functions, such as:
Being able to predict the maintainability of your product is where the power of firmware lies. With it, it brings infinite possibilities.
It is thanks to the deployment of updates that the product can continue to adapt over time to its users. Updates are essential because they allow :
The firmware is embedded software which is therefore responsible for animating the electronic object throughout its life.
The number of connected products currently in use is constantly increasing exponentially. These products are often beyond the reach of manufacturers. Physical updates are too restrictive, too expensive and too time-consuming, and have therefore been largely discarded in favour of remote updates or Over The Air (OTA) updates.
The first step of an OTA update is the generation of the embedded software. After adding the necessary functionalities or correcting bugs, a compilation is launched, either manually by the developer or automatically by the continuous integration tools.
The executable is then transferred to the target product and programmed, i.e. written into the memory of the microcontroller or microprocessor.
Firstly, it is the environment of your product that will be decisive in deciding the communication protocol.
It is then the functionality requirements of your product that will guide you when choosing the firmware.
The choice of communication protocol
Depending on the environment of your product, its needs and constraints will guide you in the choice of the communication protocol.
Does the product need to communicate with other products? Or other devices (smartphones, gateways, etc.)?
What is the amount of data to be transmitted?
How often should it send data?
What is the communication range of my object?
What is the latency required for data transmission?
What is the expected cost of data communication?
To learn more about this topic and how to choose your communication network for your smart product, you can review this webinar:
You have two choices depending on what you want your product to do. Opting for a microcontroller or for a microprocessor.
In a nutshell, the functionalities of your product will determine this choice.
The microcontroller
The microcontroller will allow your product to have a specific function. With a dedicated application or repetitive tasks.
Choosing a microcontroller also saves space on the board in terms of components, as all the resources needed for its operation are directly integrated (memory, RAM, etc.).
Another strong point of the microcontroller is its low power consumption. This criterion can be a determining factor in the design of your product because you can be sure of powering the product to power the product over the long term with a small battery.
The MCU firmware also has an optimised size, which is advantageous during OTA (remote) updates as there are less data to transfer.
It is also usually the cheapest option.
The microprocessor
There are several reasons why you should choose a microprocessor.
Firstly, your product is more intelligent and needs to perform complex tasks, such as image or video processing. These are therefore often tasks for which the product will require a very high computing capacity and memory.
In short, this is often the option that will come to mind if you plan to develop :
As a result, these products also consume more energy.
Moreover, unlike the microcontroller, the components that enable it to function are external components that you have to think about adding: memory, RAM, cooling system, etc.
It is often a suitable choice for more expensive products.
The Linux operating system
By choosing to use a microprocessor, we must then move towards an operating system that we will use as a link between our hardware and our application. On a microprocessor, the choice often turns to Linux.
Linux depends on an open-source community, which means that there are many resources for the chosen component. It is an operating system in its own right.
Here is a comparison table that summarises the differences between these 2 media for the firmware:
The choice of the king
It can happen that sometimes we put on the same board a processor (with a Linux OS) and a microcontroller. It can be useful to combine the two in the case where one model is not sufficient for the needs of my product.
For example, in the case of a product that would have a lot of data to process and transfer to the cloud but could not run on battery alone. The microprocessor will be used to manage the data processing and the link with the cloud while the microcontroller will satisfy the autonomous battery operation by controlling the power supply of the microprocessor.
Considering needs and constraints – Questions to ask
In a nutshell, here are the questions to ask yourself:
What are the functionalities of my product?
Do I have space constraints on my electronic board?
What are the power supply options? Does it have to be stand-alone or can it be plugged into the mains?
How long does it need to run or how long does it need to be standalone?
Am I limited in the cost of my product?
Do I need a cloud system to centralise the data collected?
What are the communication constraints of my product? Do I need a relay (a gateway)?
> To learn more about the role of a gateway, we advise you to read this article.
Do I want to do artificial intelligence? Or image or video processing?
All these questions will naturally lead you to one or the other solution (or both…!).
In order to implement an effective and qualitative OTA update, the strategy must be well-designed.
Security
There are 3 elements to consider in order to ensure that the updates are secure:
– How do you ensure that the server you authenticate with to send the binary is reliable?
– Once you have ensured that the server is reliable, you must also remain vigilant so as not to compromise the secrets of the binary. Be sure to encrypt the binary to keep it confidential.
– Finally, it is also necessary to ensure that the binary has been transmitted and that there has been no impact on the integrity of the data (loss or other).
Communication
To be able to carry out OTA updates successfully, it is also necessary to think about what the communication protocol implies for my product:
Firstly, who will communicate the binary to my product?
Is it a remote server containing the binaries to be updated, before transmitting them to my product? My product is directly connected to the network (4G,…)?
Is it a gateway associated with a short-range protocol (BLE, Zigbee) that will be the relay to the product?
Do we have an estimate of the binary size? If it is large, only certain communication protocols will be able to ensure the desired update time.
The memory
Lastly, here are the points that will allow me to size the memory of my product:
Should my product continue to function during the update?
Is it possible to save the current version if the new update does not work? In this case, a capacity that allows 2 applications to run in parallel in the memory should be provided.
How do I save information about the current status of my product during updates, shutdowns and restarts? This information is very important and should always be kept (how long it has been running, how many times it has restarted,…). Make sure you do not reset this information.
In short, the firmware is the brain that will drive your product. If the choice of platform is naturally made according to the needs defined by your product, the update strategy must be thought out beforehand.
From now on, you have the keys to design your OTA update strategy or to give directions to your service provider who will accompany you on this subject.
Un peu de lecture
Des articles, des podcasts, des webinars… et surtout des conseils pratiques ! En bref, une collection de ressources pour mener à bien votre projet.
