Embedded software and the key to product success
Embedded software, when done right, can aid a product’s success but when it is done wrong it can cause all kinds of problems.
What is embedded software?
Traditional software is written for conventional computers. Typically with a keyboard and monitor.
Embedded software is written for devices that usually lack a keyboard and monitor. For example, heating control, remote sensors, wearables, IoT.
Embedded systems typically lack resources such as memory, computing power, and are limited by the total power they can use. For example battery operated.
What to consider with embedded software development
Some of the things to look to help you embed software successfully.
Version control
Can you come back later to an older version to amend the code?
Version control or versioning is important for several reasons. The main reason being that if there is a problem with the coding at any stage you can go back to a previous version.
If your versions of the code are not clearly defined this can have serious time implications in locating a problem in the coding later.
Related blog: Using Version Control for software and hardware
Infield updates
Do you expect your customers to make updates themselves?
Infield updates or infield programming considers whether it is acceptable for someone to service the product themselves. For example, with a mobile phone it is expected that people will be able to easily update their own device. Whereas for code on embedded devices people would expect to never need to update it themselves.
Power efficiency in software coding
Does your product require low power coding?
You can achieve low power consumption by writing the code in such a way that it turns off all the peripheral functions when they are not in use. For example, turning off led lights when they are not needed.
In rare cases you may require high power coding. For example if you wish for the device to constantly be in use, but this is rarely the case. Even for 24 hr use devices there will be background tasks you want to shut down.
There is a big difference between always being on and always actively doing something.
Some devices can be coded to mine bitcoin in their spare time or for other uses such as donating unused computer time.
An example of how computers can utilise unused time look at sites like CUDO donate that allow you to donate your idle computer time to your favourite charity.
Related Blog: How to design for low power
Different types of coding
Do you need bare-metal software, RTOS or full operating systems?
Bare-metal software Definition
Bare-metal is single purpose, coding to do one thing such as a temperature control system.
RTOS (Real Time Operating System) versus Bare-metal? What’s the difference
An RTOS has multiple purposes but is usually fixed. With multiple events happening in a time managed way. RTOS code may choose to do tasks in a different order (see response times) and process many events asynchronously.
Full operating systems Benefits
Full operating systems have multiple purposes, but you can arbitrarily decide what you want to do when. You can also push things further, for example in home automation we can re-programme automated systems to do more upgrades and extra features. However one con is it can be harder to guarantee the response time of a task.
Response times with an RTOS or full operating systems
Some software is designed to optimise tasks by priority order.
For example, if you send a text on a phone, you do not expect a response straight away so modern phones can get away with sending your text within a second or so but completes other critical items first.
As tech products continue to become more complex, coding is moving more towards RTOS and full operating systems.
Older mobile phones used to be able to get away with using RTOS where you had to wait for a text to fully send to complete another phone tasks, nowadays more full operating systems are expected.
Related service: software and firmware development
After market applications
Home automation products often add on applications after purchase. For example, they might work with Siri, Google or Alexa to name a few. You and a family member can often use different applications at the same time from different rooms.
Using linting to avoid software bugs in embedded systems
What is linting used for in software?
Linting is a software technique to automatically check for coding mistakes.
You can create an automated script to run and check the code of errors as a rule checker (like spell check on a word document).
Code linters are programs that perform static analysis on your code. They check your code for common mistakes and bad coding style/practices thus helping you catch errors before compilation/interpretation forcing you and your team to keep a consistent code style within a project.
Software Security – What You Need To Know
Software security is the art of checking that code cannot be exploited, used or run in another way, outside of its intended use. This depends largely on the application and the risks involved in misuse. These risks can be related to reputational damage, loss of valuable data (or data privacy breaches) or could have other far-reaching issues.
1. No software is 100% secure.
Software security should be considered as a sliding scale. You can embed software intended to stop the average person from changing it, but you can take the chip off from the hardware and read the code straight off that chip. This means someone with an electronics engineering background can utilise that code.
You can go one step further and encrypt the chip and move the goalposts for the hacker so to speak. The key to decoding the embedded software will always be in the hardware but you can create a needle in the haystack situation, to hold potential hackers at bay for longer.
You cannot make software within a product ‘unhackable’ but you can use coding to ‘hide’ the access. The more secure you want to be the more you will need to pay due to the coding time need. You have a trade-off which depends on the device and the risks involved “do we care that people are going to break in and find out how it works?”
An example would be launching a satellite. You can pay ten times the cost to ensure that your satellite is only offline for 1 hour a year instead of 1 day a year, but you will still get that 1 hour offline regardless of your investment statistically.
2. Signed releases
When you share a software update, particularly with the public where there is a lot of opportunity for hacking to cause a problem and this is where code signing becomes important.
In essence your embedded system can require a software update to be signed by the manufacturer before applying the update ensuring that no one has tampered with the software update.
3. Retaining information for previous releases
Not all software gets updated at the same time particularly when software patches are involved and the user is tasked with the update. This means when doing a release with several versions in one go you need to consider revisions and patching for all the previous updates to prevent a software bug from a few years back causing havoc again.
Embedded Software Development Consultancy
Ways we help with software development at Ignys for typical projects
After the hardware side has been finalised, we use board bring up which is relatively simple code which checks that each function works properly for example checking an LED light turns off and on again.
We then write the board support package with a hardware abstraction library to make it easier for higher level modules to interface with the hardware. For example, ‘turn on an LED on the GPO, right now port number and pin number,’ board support package ‘turn on red LED’. Software can then use this command to call on the function and this is part of the hardware abstraction.
We then write device interface modules such as writing to an SD card, talking to a temperature sensor (or additional sensors), writing code that knows how to talk to that particular chip and then write applications which will put this all together.
We can also do code reviews.
Software code reviews
Software code reviews look at the code to check if it is the right standard and quality.
Is the code ambiguous for example and are there edge cases?
What is an example of an edge case?
An example of an edge case would be a signal on a railway track that is programmed to close on the left if a train approaches from the left and to close on the right when a train approaches from the right. But what does it do when trains approach from both sides? Therefore, edge cases are important otherwise the programme will become confused and potentially break. The implications of an edge case occurring once the product is in the field can range from frustrating for the customer to serious consequences.
Related blog: What are edge cases and corner cases and how to tackle them
We can also help with:
- Software architecture – Adding structure to the code. Software architecture explains how your systems work so they can be understood better.
- Revision of software – Similar to a software code review where the coding can be revised, for example for low power efficiency.
- Software Unit testing – Each software module and procedures are tested individually to check they can be used without software bugs emerging.
- Regression testing – This checks that changes or additions to the software haven’t led to any breaks in the code that can lead to bugs.
- Modularity – This process decouples the system into related clusters to make it easier to edit the code later.
How to define good software code?
A top way to consider if coding is good is this, can someone else read it?
Do not just write code that works, write it so someone else can code it. Can someone who looks at the code after you read it and then edit, change and manipulate it?
The problem with no-one understanding your code is it makes it very hard to fix it if there is a software bug later and this makes the code far less sustainable.
Where to find embedded software development support
We have a team of embedded software developers and hardware engineers ready to help on your projects.
Speak to our software development team now to bounce ideas and check our availability for project start dates.
Talk to Ignys
Authorship Daniel Szlamp:
Daniel Szlamp is an embedded electronics engineer at Ignys. This blog was written with his deep knowledge of software development. Dan works closely with our team of software engineers and hardware design team-mates. They share their knowledge helping customers through the software development process. Our developing team is expanding with a Project Management position added into the mix in Autumn 2021. You can read more about our embedded software engineers and more about our software development company and electronics design expertise here.
Software Development Tips
Dive into these software tech articles