Home > On-Demand Archives > Keynote Presentations >
The Embedded Frontier: Modern Trends and Practices
Jacob Beningo - Watch Now - Duration: 01:41:37
Embedded systems development has dramatically changed over the last decade. Navigating today's trends and where you need to be tomorrow can impact whether you’ll be successful or struggle to deliver your products on time. The latest trends can lead to best practices that help you develop more reliable embedded devices faster and within customer budgets.
In this session, we will explore the current state of the embedded software industry, the trends, and the practices that are helping teams be successful. We will look at the dynamics between C, C++, and Rust adoption. The impact that AI and ML are having on how we develop and debug embedded systems. We’ll look at changes to how systems are architected and the improvements in build systems and lifecycle processes that help teams manage complexity.
Attendees will walk away, understanding where the industry is at today, where it’s going, and the changes they need to make to stay up to date.
Topics covered in this talk will include:
- Programming Language Trends
- AI & ML Development Techniques
- Lifecycle Automation with DevOps and CI/CD
- Build Systems and Configuration
- Testing and simulation
- Modern Software Architectures
On second thought, look in the EOC archive and you will see some talks I did on Reusable Firmware and a Driver Techniques workshop I did.
Those would be some possible "free" resources for you to check out too. (Free being you already paid for them!).
Thanks for the question.
Unfortunately, I don't have a public one that I could point to other than what is in my Embedded Software Design Book in Chapter 13, Configurable Firmware Techniques
Thanks, that was a great keynote and Q&A! I would certainly agree that when you think you’ve learnt something, then it all changes and there’s always more to learn im our industry!
The list of positives from AI was useful. I had only thought of using it for generating code. How can firms leverage AI to do all this, without risking leaking all their valuable IP? When I tried ChatGPT to solve a problem for me, I had to think up a contrived example and do it from my own non-work computer just to be sure.
Your discussion and then questions from Ali about top-down design was something I’ve never thought about before. I can see the real advantages in focussing on what adds value to the customer. I can imagine them having difficulty visualising the end product though. They want to hold it, push buttons etc, even though the top-down design could be demo’d on a laptop.
I think one of the reasons these modern practices haven’t truely taken off in the embedded world is maybe the human element. We tend to do things how they’re always done, because it’s what we know. Not everyone reads textbooks, blogs, attends conferences or want to spend time exploring new tools and practices, so there’s an inertia to change. We book work to a project and focus on requirements, which doesn’t allow time to stop and think if there are better ways. Every time I read about your proper HAL, I wish I’d have gone down that route so I could stop debugging on target!
Thanks for the comment and great observations!
There are ways to use ChatGPT and other generative AI's where they don't take your input and use it elsewhere. You typically don't use the Web interface but pay for access to the backend API's that allow you to write your own apps and protect your business data.
As far as the HAL goes, it's never too late to put one in place! You might have to create a wrapper or make some other adjustments, but decoupling it can be well worth the effort! (and a fun project).
Hello Jacob, very interesting talk! Thank you very much! I would appreciate that if you could provide your perspectives on why rust language is the main contender for embedded system, but not other languages like C#, Go, or Swift.
You're welcome!
I think it's definitely between C/C++ and Rust. Although right now it really is a C/C++ "game".
Thanks for the keynote, Jacob!
My question:
In my team, we have new developers, and most of them are interns. Thinking about our developments, we intend to write a manual with good practices and design partners. For you, what's the best way that we can do this? What's the most important that we can't forget?
Thanks.
You're welcome.
Having a document like that is a great thing to do. To get things moving fast, I would use generative AI to give me a rough draft and rough outline that could then be filled in and edited. It's usually far faster to edit than to create something from scratch.
I wouldn't forget to document what your design philosophy and goals are. If that's clear, then even if someone doesn't read the document, they should have an idea of what principles to use to design and write the code.
Thanks for this very informative and wide-topic talk, Jacob.
The top-down approach yields many advantages over the bottom-up in the current context. I have a question on the design/implementation of the interface. Indeed, it is usually straightforward to extract the core function from a device (GPIO_on / GPIO_off), while factorizing the initialization/configuration is much more complicated. I see two possible approaches move initialization in the application code or do the initialization inside the component.
Each implementation has a custom configuration/initialization function in the first case. This can be called from the application code, so you can pass around a ready-to-use component instance. This approach has the disadvantage of moving platform-specific code in the application layer (even if in a very confined way).
The other approach is to hide the initialization/configuration inside the component, hidden behind a generic "init" method. This hides away specific code but makes components less flexible to use since they are bound to specific hardware resources.
What approach do you suggest?
Thank you.
Thanks for the question.
With most of this, unfortunately, the answer is that it depends. What you are trying to achieve, goals for design, etc, come in to play to trade-off which approach will work the best for you. It may even change from one project to the next.
There is a third approach where use approach one but hide the details behind API's in your application code so that the application still doesn't know the low-level objects or details.
14:16:30 From Keith J to Everyone: Agreed that the top down approach to modern software architecture is a great/better way to go. The problem I've found with it is management then believes you're closer to being done/release than you are 14:17:29 From Eric to Everyone: Reacted to "Agreed that the top ..." with 👏 14:18:07 From Caio J. B. V. Guimaraes to Everyone: Reacted to "Agreed that the top ..." with 👏 14:18:36 From Caio J. B. V. Guimaraes to Everyone: Hi, Jacob! Where could I find solid resources regarding these last three slides? 14:18:50 From Andrew MacIsaac to Everyone: Reacted to "Agreed that the to..." with 👏 14:19:14 From Raul Pando to Everyone: add 👏 14:19:20 From SA to Everyone: Reacted to "Agreed that the top ..." with 👏 14:24:33 From Michael to Everyone: add 👏 14:25:16 From Ali to Everyone: Regarding top down approach, how does one approach it when the whole organization is still very hardware dependent. Say they don't have simulators? The end customer is actually management, they want to be shown some shiny stuff, yet are completely not transparent of what is going in the Sprint. Typical management would say that we aren't close to be completing requirements, just show and tell. What are your thoughts? 14:26:04 From . to Everyone: Reacted to "Agreed that the top ..." with 😂 14:26:47 From Ali to Everyone: Reacted to "Agreed that the top ..." with 😂 14:27:45 From Michael to Everyone: remove 👏 14:33:16 From ever to Everyone: Reacted to "Agreed that the top ..." with 😂 14:33:16 From Eric to Everyone: That was quite a LOT of stuff in 90' … thanks! 14:33:29 From Ali to Everyone: Reacted to "That was quite a LOT..." with 👍 14:34:14 From Junnan Pan to Everyone: could you please explain a little bit about the concept of microservice 14:35:45 From . to Everyone: How to avoid and manage tech debt when racing to finishline and release to customer? 14:37:20 From Ali to Everyone: Thanks Jacob, great insight. Unfortunately, most dont have any devs writing business logic. Same devs are doing both and that is where it gets messy. I like the idea of adopting a hybrid approach 👍 14:38:17 From Ali to Everyone: Reacted to "How to avoid and man..." with 👍 14:40:03 From ever to Everyone: yea agree on all of those top down aproach .... extra note on "containers news" I have seen some development for microcontrollers using a JavaVM to develop microcotroller code on Java that allows a "digital twin like" on your PC. Similar to Androidstudio. you can move your "business logic development" from one uC to another uC faster while simulating everything on the PC. The look and feel help to decide faster if moving in the right way 14:41:42 From Aaron Edis to Everyone: Does Rust have capabilities similar to the STL in C++? Does C++ have the safety features that Rust is known for? 14:44:25 From BobF to Everyone: Regarding 'HIL' (Hardware-In-the-Loop), have any majors developed HIL boards, apart from common 'Dev' boards, possibly generic to some extent? 14:52:45 From Keith J to Everyone: Getting requirements/specifications from stakeholders is a challenge and the quite often change after the fact.. The top down as you call it is really a way to help get something in their view to help develop specs. 14:53:30 From Mike to Everyone: Could you share a good configuration management example (C and C++)? 14:53:36 From Eric to Everyone: What is "Frankenstein"? https://hackaday.com/2014/03/29/frankenstein-the-open-source-engine-control-unit/ 14:53:57 From Junnan Pan to Everyone: Reacted to "What is "Frankenstei..." with 👍 14:59:45 From Junnan Pan to Everyone: Reacted to "How to avoid and man..." with 👍 15:00:16 From BobF to Everyone: Reacted to "What is "Frankenst..." with 👍 15:00:53 From Shilpa to Everyone: Reacted to "How to avoid and man..." with 👍 15:04:42 From Shilpa to Everyone: Reacted to "What is "Frankenstei..." with 👍 15:07:22 From Eric to Everyone: Imho not C is the problem but bad programmers. I've seen multiple malloc(sizeof(int)); in a voting machine. 15:08:49 From Mike to Everyone: Replying to "Could you share a go..." Will do. Thanks 15:12:09 From Junnan Pan to Everyone: where can we find your slides? 15:12:37 From Junnan Pan to Everyone: thanks 15:13:01 From Eric to Everyone: Great, thanks! 15:13:18 From Andrew MacIsaac to Everyone: Thank you! 15:13:19 From Lyden Smith to Everyone: Thank you Jacob!
Thanks for the talk! Could you share a good configuration management example (C and C++)?