
004 - François Baldassari
Chats with James Podcast
Evolving Embedded Systems Engineering Practices
This chapter explores the evolution and challenges of embedded systems development, focusing on a significant meeting that shaped software engineering practices. It emphasizes the transition towards a software-oriented approach and the critical role of tools like continuous integration and testing in both safety-critical systems and consumer devices.
00:00
Transcript
Play full episode
Transcript
Episode notes
Speaker 2
And it's funny to think that, you know, two years ago, we hopped on planes and spent a day cooked up in a house dreaming about embedded systems. That seems like a far away notion. I think that meeting you was also eye-opening for us. For a while at Pebble, we felt a little lonely, to be honest, because we'd been thinking of embedded development as really a software engineering discipline. I think this is because we had a unique point of view. We were working on a device that, yes, ran on a STM32 microcontroller, but fundamentally the work that we did was higher level software. There was a graphical user interface that was quite complicated. We had a layering system. We had different ways to handle, you know, you could show bitmaps, you could show fonts, you could show all kinds of complex kind of graphics. It had really kind of, you know, complex SDK that allowed people to write third party software, right? Like the idea of hot loadable third party software running in an STM32. It was a little, you know, we were pushing it a little bit. And in fact, many of the primitives that you need to build a good sandbox were hard to find on a microcontroller. But we made it work. And so because we were doing all this very software-y stuff, we had the needs of a software team. We were, you know, were doing continuous integration. We were shipping updates every couple of weeks because we had new features, new APIs to ship for SDK, bugs to fix. And we were really following a cadence and a software engineering development practice that was closer to that of a mobile engineer than to that of a hardcore firmware engineer that's bringing up a board and implementing a driver for a sensor. And so I think that's why we've been thinking about how do we adopt more of these best practices and how do we avoid reinventing the wheel and adopt what the mobile guys and the web people have figured out without, you know, and to make ourselves more productive. And so when I met you and we got together with Heiko, Brad and Toma, it really did feel like all of a sudden there were other people thinking about this. And perhaps there might be other people would be interested to hear about this. And so that was really exciting to me. And I think we laid the ground for some interesting stuff, talking about build systems, talking about continuous integration, unit testing, hardware in the loop tests versus emulated tests versus pure software tests. We talked about architecting before you start coding. We talked about what rigorous software engineering in this embedded context might look like. And I still refer to those notes regularly. It's been a huge source of inspiration.
Speaker 1
And it's interesting because I came at that from a very different side of things. So my experience up to that point had largely been in safety critical with a little bit of IoT work, I think, by the time that we were talking. And a lot of the practices that we talked about were kind of the expectation of what you do when you ship a quality piece of avionics, because for safety critical applications, you need to have that level of robust testing and things like that. And I think that was one of those really interesting things where we came to the same set of needs as software developers, where from an avionics perspective, you're doing it to ensure quality and robustness and things like that. But from a consumer device perspective, you're doing it for security and reliability and speed of iteration and things like that. But it was interesting because we had shared the same experiences with, you know, how much can a simulator accelerate your development, the ability to not be tied to a specific piece of hardware while you're rapidly iterating on software, or how powerful is it to have, you know, remote control commands so that you can trigger unusual behaviors on your device or make sure that your device is going to respond to certain stimulus in ways that are predictable without having to generate that ridiculous stimulus that might be really hard to do with physical units and things like that. So it was really refreshing to see that. And I had been coming from an area of working with, especially after I left one company, I I was working with different engineers who had different levels of experience and embedded. And it was sort of like going back to the stone age. And I think we talked about this while we were meeting. It was, you get that experience when you're on an embedded development team, or I suppose just a software development team in general that has these mature practices and things like that. And then you can go to some other team who's still shipping really excellent things and like a company who is still delivering on these things. And sometimes you feel like you're walking back into the stone age because they don't have CI, they don't have testing, they don't have simulators, they don't have these kinds of things. And even though they're shipping these really amazing practices, you walk in and you're going, why are you using rocks to build this stuff? You know what I mean?
Speaker 2
Yeah.
James chats with François Baldassari to discuss embedded systems, engineering practices (and where the industry is lacking), and the social side of improving the skills of embedded systems teams.