Embedded Trends and Tech to Watch in 2021

2021 will be a breakout year for RISC-V.

We’ve seen R&D groups at large customers dabble with RISC-V to see if they want to base a platform on it, and we’ve seen smaller customers start to use it. A few large companies have really committed to using it in at least some business units.

While part of the RISC-V trace specification was ratified this past February, there will still be a few tweaks made in 2021. Ultimately, you’ll see a good deal of high-quality debug information like live instruction trace, interrupt visibility, power usage, and other metrics that can be fed through the debug port.

Amongst other things, this will truly empower embedded developers to produce their applications more quickly because they will be able to identify bugs and bottlenecks in their code more easily. I think trace will really take off and I predict it’s going to help turn RISC-V into a major player as far as architectures go.

The automotive and medical markets will continue to grow and drive unprecedented innovation among embedded software developers.

I think we will continue to see automotive grow like gangbusters as autonomous driving pushes the envelope further and further. Leases on cars are way up, mostly because people want the latest and greatest tech and therefore don’t want to buy a car to keep right now. That’s fueling quite a bit of growth in the industry, not to mention the electrification of vehicles.

The huge number of systems needed to make those a reality and the communication between them are going to make embedded developers more cognizant of operating in a complex system. That will put even more focus on testing and code quality.

In addition, I think that medical will see quite a bit of growth thanks to the pandemic. Many people are still asking, why does it take so long to get a vaccine? Why isn’t our testing faster and cheaper? What’s going to happen with the next round of disease?

How will this impact embedded developers? They will be making smaller, more portable devices to diagnose infections instead of having to send things off to a large-scale lab. In my mind, the moon-shot would be to have devices that could take a virus profile, which would then get uploaded into a database. Such a database would be used in a handheld device that can give you positive or negative results against that profile in seconds. It would take a lot of creativity, but I think embedded developers are already at the forefront of making that a reality. However, it’s going to be more so in 2021.

We’ll probably have to take that in stages, making detection smaller and cheaper. Thus, we can have one lab unit per testing site that can only detect COVID-19 and possibly a few other conditions. Ideally, it would be able to detect the next pandemic by making the detector reprogrammable. It’s easy to say and hard to do, but embedded developers are incredibly creative, and they’re going to figure out how to do it!

Continuous integration/continuous deployment will be driven by the rapid growth of the IoT, 5G, AI, and cloud/edge computing.

The biggest impact of this growth, which will continue in 2021, is the trend of continuous integration/continuous deployment. Teams are pushing out software updates faster than ever. This requires a rigorous set of tools to inspect code quality for potential pitfalls and automated testing to verify that the software conforms to the software specifications.

The tricky part is capturing all of the requirements in these types of tests to make sure that what gets pushed out doesn’t break things or make a system unreliable. That’s why continuous integration inspects source code to make sure it conforms to safe and reliable coding practices. Then it subjects the code to a rigorous battery of tests designed by the QA engineers to make sure that it’s doing the right things. The push to deliver things faster is really tricky in embedded software; if you get something wrong, it can render the system inoperable.

As such, the biggest impact stemming from the rapid growth of the IoT, 5G, AI, and cloud/edge computing on embedded software development in 2021: The continued focus on improving quality, yet still delivering faster. Interestingly, it’s so subtle that most people won’t realize the critical impact it will have.

Development tools will help companies address the challenges of time, but only if they have technical expertise behind them.

Without a doubt, the biggest challenge most companies face is time: time-to-market, time to recoup investment, etc. Based on what I said earlier, development tools that help improve code quality are going to be key to saving time—even more so in 2021 than in previous years.

However, equally important is having support that you can depend on to help you when you’re under a time crunch: Why is this interrupt not triggering? Why am I hard-faulting in this use case, and more importantly, where is it occurring in the code? Is this a bug in the compiler tool, and if so, how do I get around it?

There’s an old axiom that time is money, and when you have to read through reams and reams of webpages to find small nuggets to help you get a fix or workaround, it costs quite a bit of money as well as time. Likewise, if your code isn’t running fast enough for your needs, you wind up hand-optimizing it which can cost oodles of time. Sometimes people resort to writing assembler code, which usually isn’t very portable, plus the code gets messy and makes static analysis of the source less effective.

When you use quality development tools, it puts the onus of addressing these problems on the tools and not on you. Plus, when you run into issues, you have technical experts you can call for help. Therefore, you spend a little more money up front, but you save a lot of time and money in the end analysis. 

Fundamental development practices like code quality will continue to evolve.

As we mentioned, development practices are continually improving because more of them are becoming automated. In ye olden days, the only folks doing automated testing to any appreciable degree were developers of applications in the functional safety realm. Now we see automated testing rolling out even to consumer devices. It’s evident that subjecting code to more formalized and automated testing puts more eyes on the code.

It used to be that code inspections were rare. As long as your code didn’t have bugs, you could be as sloppy as you wanted, putting spaghetti code here, there, and everywhere. With automated continuous integration, you can’t get away with that anymore. You’re forced to write your code using best practices, and if you don’t, everyone can see it in the output of the continuous integration system.

As people find new and better ways to add to automated testing, it will force people to use local copies of code analysis while they’re desk-checking their code and before it goes into a formal build. They will want to know if their code is going to pass muster before everyone else sees the continuous integration output.

Studies like the ACM paper, which we cited in a white paper by IAR Systems, have shown that the sooner you put that kind of feedback in front of a developer, the more seriously they treat it. If you leave it as part of a nightly build process where the developer gets feedback the next day, such issues are treated less seriously due to the “survivor effect.” But as the checking gets more rigorous, people are going to want to check their own code more quickly. 

Improving the experience and quality of the entire development processes: Documenting code adequately and accurately will be more essential than ever before.

I can’t begin to tell you how many times I see code that includes few if any comments. Usually developers who do this claim that their code is “self-documenting.” I’ve heard that term quite a bit, but I think it’s like the unicorn in the embedded development community—I hear about it all the time, but I’ve never actually seen it.

Developers need to do a thorough job documenting their code not only for anyone who will review or maintain their code, but also for themselves. Six weeks from now, when someone finds a bug in that section of code, you’re going to spend lots of time trying to remember what you were thinking when you wrote that section. If you had just taken a few extra minutes to clarify your thought process in the comments, you wouldn’t be in that pickle.

I’ve also heard developers claim that by making their code abstruse with a paucity of comments to document it, they’re increasing their own job security. I think that’s just silly; you’re making it harder for yourself and everyone else. Job security comes in being able to do your job so well that a company has no reason to want to replace you. And when you mentor other people in how your code works, you increase your value to your colleagues.

I’ve never been a fan of what we called “400-pound brain syndrome” at one of my previous employers, where one person has all the knowledge of how something works and guards it jealously. Share your knowledge; that’s your true value to a company. It makes your development experience better while helping everyone else around you.

>> Electronic Design Resources
.. >> Digital Editions
.. .. >> Top Stories of the Week
.. .. .. >> 2021 Electronic Design Forecasts