Embedded software design programming permeates all corners of our modern lives. Any time you pick up your phone or access a web page you are sifting through the hard work of software engineers.
Countless products today have some combination of electronics incorporated in them, and many of these have some level of software applications that enable them to function.
Yet the process for developing embedded systems that keeps the digital cogs turning is a little different than the processes used to create the physical product.
When you build a wooden garden shed there are many tools that can be used. You can nail a frame together with a nail gun or a manual hammer. Beyond that, there are a couple variations to the way you frame the shed, but ultimately there are a limited number of ways to pull it off, otherwise, you risk your shed falling down.
Embedded Software Design Doesn’t Play by the Same Rules
There are many languages that software can be written in, many high-level tools that can be used to compose code.
Ken Oakeson is a software developer and is an expert on cloud computing operating systems. A large component of what Oakeson does is to help educate clients on the variety of languages that can be used on a project as well as the challenges with each.
An important task for embedded system design programmers is helping clients decide which code language is best for a given project. Because just like physical materials and fabrication processes, programming languages and the tools selected to develop a program are very important.
- Will it run on your platform of choice?
- What tools are available? Editor, compiler, debugger?
- Are drivers available? Bluetooth? TCP/IP? CAN Bus? RS-232?
- What APIs will you use? Facebook authentication? Dropbox file storage? Google search?
- What reference implementations are available? For example, did Microchip show you how to use their board with samples on GitHub?
“For me, software development is often starting with an overwhelming task and then breaking it down into achievable pieces,” Oakeson said. “Then tackling those pieces with a design and development approach that delivers the functionality, but is also usable, from a user’s perspective, testable, maintainable, extensible, efficient with resources (CPU, network, storage).”
Oakeson said in recent years programming language has become less important with the help of new tools such as editors that help with autocomplete code, online references such as Stack Overflow. However, the class of programming language is still very important. So strongly typed versus loosely typed and compiled versus interpreted.
It can be tricky for programmers to get the code working. Tiny, difficult to identify errors can cause the program to behave in unexpected ways, or not perform in the desired manner. When it comes to code there is more than one way to skin a cat, but ultimately there is one desired end result the programmer is striving for.
Additionally, code that is written correctly and functioning properly may experience huge differences in performance by being manipulated. This is a huge contrast from physical products which, if not built in a certain way, simply won’t work.
In a recent project, where the device drivers used a proprietary firmware. The product had a screen which gave the user outputs to the equipment it was hooked up to. The team was able to get the code working correctly, however, it was “choppy” and the screen didn’t give real-time data in a way that the team thought was very good.
After some work, Dave Bohan, a software engineer for SGW, found he could get the display to smooth out and look much better by changing some lines of code that were already in the system. After some experimentation, Bohan was able to actually eliminate some lines of code without disturbing the output of the program. This resulted in a final product that gave the desired performance and looked good doing it too.
Just like with physical products, sometimes it’s not enough that it works. It needs to meet a certain level of performance.
It may come as a surprise for some, but embedded software design often follows the same sort of prototyping process. The first program for a product may lack features the final product is meant to have, or it may just serve to prove that a certain feature works. Later iterations may contain more features, more complexity, and the outputs may look more like the final product is supposed to look.
Sometimes people think embedded software design is a component that a programmer can grind out in a single run. Ironically, it is usually the opposite. More complex software, like big budget video games, is built in a way that is actually more similar to the way a Formula 1 team builds a car. Certain programmers will specialize in one aspect of the software and add their contribution to the final product.
Next time you’re thinking about software, or taking some time to unwind with your Xbox, take a moment to look up some of the details under the hood. The level of complexity and the size of the team that built the software may surprise you.