/ FAE ROUNDTABLE
How to get the best from free software
Embedded software is complex. The time it takes to write code can be shadowed by the effort needed to make it ready for production. Using open-source software, or software freely provided by semiconductor suppliers, can help with the first part of that equation. But not all free software is ready for production.
Avnet asked four experienced software engineers how they approach embedded software development using free or open-source software. What should OEMs be aware of when using free software? What can they do to simplify software integration? And how can they ease the process of developing software robust enough for production?
What’s wrong with free software?
Most semiconductor vendors now offer development kits or evaluation boards. Those with programmable or software-configurable devices will also provide a software development kit (SDK). The SDK will either be written for the vendor’s own software tool chain or integrated development environment (IDE), or the vendor will endorse the use of a third-party tool chain or IDE.
An SDK can be essential for getting a proof of concept up and running. It can also be used as the basis for further development. But developers need to exercise caution and be aware of the possible limitations.
"There’s a variety of approaches to solving that, but it’s certainly a common problem."
Participant bios
Josef Holzmayr
Head of Developer Relations, Mender Read Bio
Philip Ling
Senior Technology Writer, Avnet Read Bio
Phil Robinson
Deputy General Manager, Witekio Read Bio
Konrad Weihmann
Software Design Engineer, Avnet Embedded Read Bio
Detlev Zundel
FAE, Embedded Software, EBV Elektronik Read Bio
New challenges for silicon vendors
Hardware vendors are working hard to make SDKs that support their own evaluation and development kits. This is manageable when the ecosystem is small or for codebases that are not complex.
But a lot of embedded software now relies on open-source code such as Linux. This brings a new dimension to the challenge for silicon vendors. They must now develop code that complies with the project. Often this can demand greater investment from the silicon vendor.
“We see hardware manufacturers becoming software manufacturers without wanting to be software manufacturers.”
System-level decisions
Although so much of the functionality in modern electronic products is defined by software, that software still runs on hardware. Often it is the hardware platform that will drive the sale. The hardware vendor will develop software to help get the hardware designed in.
This can be a difficult time for developers. They need to invest some time in looking at the software support they can expect if they choose that vendor’s hardware solution. Although this can be a challenge, it is also the right time to make some system-level decisions early in the design cycle.
“I strongly believe that hardware vendors writing code are doing it for one reason only: to sell hardware.”
Focus on differentiation
This dependence between hardware and software is changing the balance of decision making. There are strategic choices to be made—both at the hardware and the software level—between technologies that differentiate your product and those that do not.
Some of our experts, even those focused on providing hardware, are encouraged to see more software engineers being involved in the decision-making process when selecting hardware.
This has not been the case in the past. All hardware decisions would be made by hardware engineers. OEMs are now realizing how important and advantageous it is to involve software engineers at the system level.
“Software people are now involved in the process of selecting hardware.”
The CI/CD paradigm
With over-the-air updates (OTA) now commonplace, it is fair to say that modern electronic products are never finished. The software must be maintained throughout the product’s lifecycle, with OTA updates issued when necessary.
This continuous integration with continuous delivery paradigm is not present in the hardware domain, at least not in the same way. For this reason, choosing what software to use in a project, whether it is open-source, free or paid-for, has long-term implications.
“Be familiar with the software base you are using.”
What are the challenges around software integration?
The right software, wherever it comes from, can provide a faster route to proof of concept (PoC). Moving from PoC to production means integrating all the software elements and, perhaps more importantly, testing them.
Although the application will dictate the amount of confidence an OEM needs in the software’s robustness, the effort required to integrate and test software can easily outweigh the time it takes to write the code.
“The effort needed to test shouldn't be underestimated.”
Software is a moving target
Writing and testing functional code is one aspect of product development. Building the software framework, particularly using an open-source project, is another.
This creates a moving target, actually a number of moving targets, as Josef Holzmayr from Mender explains.
“It’s not just a moving target; it’s a plethora of moving targets.”
Open source comes with complexity
When choosing to use open-source projects, the embedded sector must contend with the baseline of complexity this introduces.
Using a comprehensive software platform will provide a lot of commodity functionality, which is often why OEMs will choose it. However, that freedom to use the software comes with a hidden penalty.
“A fairly simple Yocto build has 1,500 packages.”
Software dependencies
Software builds for embedded products are multilayered. This is a consequence of using an open-source platform that is already quite complex. But it could also be a result of a cultural change among developers.
Some software developers are more willing to create dependencies instead of writing extra code. Although this can be seen as a structured approach to programming, it can also increase complexity. Could this be a generational shift in the way we develop embedded software? One of our experts thinks it is.
“If I compile a small example and it is pulling in 100 dependencies, I try to imagine who is checking all of this?”
What’s the problem with writing all your own code?
For some embedded systems, it may still be viable to write the entire codebase in-house. But connectivity continues to change the landscape. One of the reasons why engineers like open-source projects—Linux being the most popular—is because it provides a lot of the communication stacks needed in modern systems.
The design effort needs to be focused on the differentiating elements, not those that can be seen as commodity. As more of the functionality needed by embedded products becomes commoditized, free- and open-source software will become more appropriate.
“The companies have to focus on the differentiating properties of their devices.”