#009 - Real-World Lessons in Embedded Security, AI, and Systems Development with Shawn Prestridge

Curious about the future of embedded systems? In this episode, Jacob Beningo is joined by Shawn Prestridge from IAR Systems to tackle the pressing challenges developers face today. From real-world insights into AI’s role in embedded devices to the overlooked pitfalls of security in connected systems, Shawn shares practical lessons learned from his decades in the field. Whether you’re interested in how AI can transform your development process, or you're navigating the complexities of modern code quality and security, this conversation offers actionable strategies that every embedded developer needs. Don't miss this chance to learn from the cutting edge of embedded systems development.

Transcript

Jacob (00:01.853)
Welcome back to the Embedded Frontier podcast. I'm Jacob Beningo. And with me today, I have Sean Prestridge from IAR. So Sean, how's everything going today?

Shawn (00:11.246)
Ah, can't complain. Sun shining, beautiful spring day here in Dallas. Uh, you know, excited to get out and ride my, my bike around the neighborhood. So.

Jacob (00:21.435)
Excellent, excellent. So, so maybe for Michigan, let me be jealous. How warm is it over there right now?

Shawn (00:28.014)
Uh, it's actually going to get up to about 80 today. So being early March, this is a little bit warmer than what we normally have, but it's, it's not too wide of the mark. So, uh, it's, uh, it's been beautiful spring days for the last week. So just really excited for the cycling season to start.

Jacob (00:33.021)
Thank you.

Jacob (00:48.285)
Yeah, we've had we got lucky with a rare 70 degree temperature a couple days ago and now we're back into the mid forties, which is still really nice for spring in March here in Michigan.

Shawn (00:59.15)
Yeah, especially in Michigan, near the Detroit area, I can imagine.

Jacob (01:05.693)
Yep, exactly. So we've been able to have a nice mild winter. But in any event, one of the things I think that we can do to kick things off here a little bit, I know people will be interested to learn a little bit more about you. I know we've, gosh, we've probably been interacting now for, I don't know, probably somewhere between seven and 10 years, to be completely honest. I think probably the first time I became aware of you actually was probably at like an Arm TechCon or something. They used to have, you know, advertising IR sessions.

your face used to be plastered on there as, hey, come to your session on C, C++. And I was like, oh man, I got to go and meet this guy and hear what he has to say. And that's probably the first introduction to you. And then since then, obviously, we've had conversations and stuff like that. But why don't we let you give a little bit of an introduction about yourself.

Shawn (01:52.75)
Yeah, sure. Those were some scary posters. I'd walk in and go, oh my God, I can't believe anybody would, this is going to scare people off from the talk. But yes, as you said, my name is Sean Prestridge. I'm from Dallas, Texas, and I have numerous degrees from Southern Methodist University. And I also have been working.

I started my career working at Texas Instruments in the Educational and Productivity Solutions Group, which is a fancy euphemism for calculators, which is ironically the thing that most people know TI for, but I actually did work in that group for approximately 10 years. But I've spent the last, gosh, going on 16 years now working at IAR systems.

Jacob (02:21.723)
you

Jacob (02:36.441)
All right.

you

Shawn (02:43.15)
And I am the US field applications engineering manager for IAR systems. But you know, I'm an old school manager that I actually do the job function of the people that I manage as well. So I'm not just one of these people that pushes paper, you know, I'm actually out there actively doing it and helping my team and whatnot. And it's, it's been a fun and an amazing experience and.

For those of you who are not as familiar with IAR systems, we are the world's most experienced embedded C compiler company. So we started in 1983 on the 8051 architecture. And over the years, we've supported over 40 different architectures. And I think the number of active architectures that we still support is somewhere around 15. So.

We've got compilers for the old Z80 and whatnot that aren't considered active products anymore. But ARM, MSP430, 8051, ABR, ABR32, RX, RL78, RH850, there's just a number of architectures that we support now. And one of my favorite parts of the job, as you alluded to, is...

being able to get out and meet customers and talk to people and see some of the cool things that they're doing with technology and feeling a little bit of ownership when I see them doing cool stuff and knowing that they're using our technology to help develop that. You feel like you have a very tiny part in hand in helping them bring that to fruition. So, but I get that kind of feeling whenever I walk through a store and I see products like, oh, they're a customer and they're a customer and they're a customer.

Jacob (04:17.021)
you

Shawn (04:29.536)
Because we say that at least 30 times a day, you touch a product that was actually developed using our technology, using our compiler tools. So, you know, we've grown and we now have products that address embedded device security and making it very, very simple for customers to use code analysis products that help you to...

Make sure that you're writing high quality code and to help you find defects really quickly while you're still desk checking your code and a number of other things. But you know, it's been a really exciting career at IAR Systems and I absolutely love it. It's just, it really fits my personality well.

Jacob (05:15.837)
Excellent. Yeah, I really appreciate you giving us the background. I think it will help a lot of people and what understand what you do and what IR has been doing. And it's amazing to see as well the impact that they've had through the industry, as you mentioned, with the number of customers and products that use their technologies to help developers get things to market. So now, maybe an interesting place for us to start, mentioning how as an FAE, you get to see a lot of different things. Do you have any, obviously,

something that you can share, right? But I'm not asking for anything that would be obviously confidential or anything. But what kind of general trends do you currently see kind of out in the industry?

Shawn (05:56.11)
Well, that's actually a really good question. The two things that I really see people asking a lot of questions about and trying to decide what they're going to do are around artificial intelligence and around security. I guess we could probably start with artificial intelligence since that seems to be the really hot topic. Security is still hot, but it was hot several years ago, and it's just continued to kind of smolder.

Jacob (06:16.935)
It's.

Jacob (06:21.727)
Yeah.

Shawn (06:25.774)
as people try to figure out exactly what they're going to do in both those regards. And, you know, artificial intelligence just kind of reminds me of a quote I heard one time about time. You know, everybody knows what you mean when you say time until you ask them to define it. And then all of a sudden they realize, maybe I don't know what we're talking about. And artificial intelligence has kind of a similar bent.

But what I found is that most customers, when they're asking about AI, they have three different things that they could possibly mean. And so I try to quantify what they mean as soon as they use that terminology. The first one is the one that's in the news, and that's the generative artificial intelligence, the one that is creating things off the cuff and making things. So that could be whole.

books or giving you nice answers, which I have to say I've played with AI. And I kind of feel like it's a, I like to call it a dilettante, a technology dilettante, because you can ask it very pointed questions about things that you know. And it actually gives you a pretty good answer to give you information and terminology and things that you can use to go research.

So I don't know that I would necessarily trust what it says, whole cloth, but if you're new to a particular topic, you can try to learn a little bit. And it's like an expert friend, but not really an expert. It's really more of a dilettante. It knows enough to be dangerous and to kind of point you in the right direction, but then you need to go off and try to do things to educate yourself a little bit better on it. But it's an incredibly powerful tool.

The second thing that I see people using it for is typically AI at the edge, where they're trying to use machine learning neural network models to determine what is an anomalous condition. And perhaps one of the most cited examples is where you put it on an aircraft engine, where it has a number of sensors like vibration sensors, noise sensors, et cetera, et cetera. And it first learns what is normal for this particular engine.

Jacob (08:39.407)
you

Shawn (08:47.854)
And then once it knows what's normal, it's able to detect abnormal conditions. And based upon the training models that it has been exposed to, it can tell you, okay, I'm starting to hear this kind of noise, which means you probably have about 200 hours before this kind of failure is probably going to occur on this engine. So it basically tells the aircraft company.

you need to schedule this engine for maintenance and here's approximately how much time you have. So it's, uh, you know, that's a really interesting use that we see people using it in the embedded industry today. But then the third case is one that I'm actually seeing more and more of is people want to know, how can I get this stuff to write code for me? You know, I want to write the interesting bits of code, but you know, I don't want to go research how to, uh, use a howl to do.

Jacob (09:38.973)
you

Shawn (09:41.846)
XYZ or they need to do something that they feel is fairly simplistic. And so they use things like Microsoft Copilot or maybe even ChatGPT to actually write snippets of code for them. And in some cases, the code that they get is actually an example that comes off of a well -known source like Stack Overflow or something of that nature. And in other cases, it's pulling from all those things.

then it's just totally rolling its own code. And sometimes, you know, it comes up with some really good stuff and sometimes you're like, that's really suspect. I was playing with it the other day and it wrote some really good, at least at first blush, it looked like some good Matlab code and I was, uh, uh, noodling with it. But then when I actually executed the Matlab code, I'm like, this doesn't do anything. It doesn't do what it, it's supposed to do.

but at a cursory glance, it's like, oh, hey. So your mileage may vary. So those are the three things that I typically see with AI. But that actually goes back to what I tell people on the code quality and some of the tools that we're doing is that regardless of where you get code snippets from, because let's face it, we all go trolling on Stack Overflow or other places to look to see.

Jacob (11:05.509)
Yeah.

Shawn (11:09.422)
how have other people approached this problem? So I think it's kind of the dirty little secret that we don't really want to talk about in this industry, but people do it because it's a community. You don't always have time to very well vet and research the things you're doing. So you want to go find out what other people did. But I think code analysis tools are really great way to help vet some of these code samples that you get from other places to see, am I introducing a security hole here?

Jacob (11:32.005)
That one.

Mm -hmm.

Shawn (11:38.99)
You know, what's some potential places that this snippet of code can fail because I'm not the one who wrote this. So I don't really have it internalized like the person who was the original author. So, you know, that's a really good use case for wanting to do to statically analyze your code. And static analysis is fairly well understood in the industry, you know, looking at your source code. But then there's also the flip side to that code analysis, which is dynamic analysis.

Jacob (11:52.765)
you

Yeah.

Shawn (12:08.046)
where you're actually running the code on target, but then it also puts in little statements that are testing and measuring potential failure points in your code. And yes, obviously, since it's inserting code, it's going to affect the timing of your code. But for testing purposes to make sure that your code is solid, it's actually something that you really should go through the process of doing just to find out, are there some hidden little gotchas within this code that we have?

Jacob (12:15.613)
Hmm.

Shawn (12:37.518)
So, but yeah, that's AI in a nutshell and I see some really interesting development and stuff that's going on around it. As far as security goes, embedded device security is something that we still see a fair number of people that are what I call fence straddlers. They know that legislation's coming for them and they know they need to do something about it, but because nobody's telling them to do something about it, you know, they're like, eh, I'm just...

Jacob (12:59.453)
Okay.

Shawn (13:07.374)
kind of keeping aware of what's going on. And that's kind of where I like to show them, well, if I can demonstrate how you can do this really easily and check probably 80 % to 90 % of the security boxes that you're going to have, would you be interested in this? And of course, after you show them how easy it can actually be when you're using the appropriate tools,

you know, then they get really kind of excited about security. And in a lot of cases, they wind up wanting to be actually forward thinking. So even though the even though it's not being pushed down from any outside organization saying you have to do this, or from on high from the C suite saying we have to address these.

you know, it's they kind of do a grassroots movement where it gets into a little bit of trouble sometimes though is if the company has a cybersecurity department a lot of times the cybersecurity department is staffed by IT professionals and They don't always really understand the challenges that we face as embedded developers They kind of act like everybody's using a four gigahertz, you know

processor with 32 gigs of RAM and so you should be able to do all these things and they don't really seem to internalize the challenges you have when you're developing on resource constrained devices that typically either aren't connected all the time or they're only connected occasionally and they can't do all the things that...

a regular PC would do, but I guess the blessing in disguise there is that they also don't face the active threats that some of these other machines do. So, you know, it is a little bit challenging sometimes educating those people what is actually possible and what's considered best practices from an embedded device perspective, as opposed to the more IT infrastructure that they're used to dealing with.

Jacob (14:53.261)
Yeah. Yeah.

Shawn (15:16.398)
But, you know, it's still a really hot topic and I'm really glad that people are starting to take it more seriously. We're seeing less fence straddlers at these points, but, you know, we still have a fair number of people that it's kind of hard to convince them. And the ones that worry me the most are the medical device customers, which, as you said, are going to remain nameless to protect the guilty that say, well, we know these requirements are going to come down from the FDA, but nobody's telling us.

Jacob (15:20.125)
Yeah.

Shawn (15:45.806)
We have to do it now, so we're not going to do anything. We're just being aware of the situation and the battlefield so that when we decide we're going to jump in, we can figure out where we're going to parachute our people into the fray. So that's just not my philosophy. I would rather try to take care of the problem initially, because as the mantra of engineering is,

Jacob (15:57.073)
Yeah.

Shawn (16:10.19)
you plan for the worst and hope for the best. And sitting on the sideline and saying, well, nobody's telling me I got to enter the fray. That's not planning for the worst. That's just saying, I don't want to engage. So, but I'm sure you've, you've probably seen some people that are of that yourself.

Jacob (16:17.581)
Yeah.

Yep.

Jacob (16:26.653)
Absolutely. Yeah, I see a lot of opportunities where people are reactive engineering versus proactive engineering, especially when it comes to security, even sometimes as far as developing reusable, scalable software architectures. They'll look at it as, oh, well, you know.

Shawn (16:35.694)
Yes.

Shawn (16:48.2)
Thank you.

Jacob (16:49.377)
they won't look at look ahead to see whether they you know whether they need something to be reusable or not they'll kind of just allow the architecture to become emergent which generally ends up in a giant ball of mud right yes exactly

Shawn (17:01.102)
Yeah, you know, it's, hey, we prototype this. We never really intended this to be used, but now it's like, oh, well, let's slap some window dressing on the prototype and ship it. You know, it, excuse me. I think it was encapsulated in a saying that I saw one time that really resonated with me. Why is there never time to do it right? But there's always time to do it over. You know, it's one of the more interesting conundrums of our profession.

Jacob (17:21.393)
Right. Yep. Oh, it really is. It's it's so strange that we behave in that way. And we don't seem to learn our lessons either. We always think, oh, we'll go back and do it the right way later. And later never actually really happens. And you end up with a real scalability and a lot of technical debt and issues that just kind of, you know, prolong development and cost the company a lot of money. And.

Shawn (17:46.146)
Yes.

Jacob (17:48.701)
And security can be one of those things too, because you can't just bolt it on at the end, right? You have to start from the very beginning thinking about security, the requirements, performing a threat model security analysis, and kind of really define those requirements so that as you develop the software, you're really building security in from the start, just like quality, right? You can't add these things at the end once you have something that's working. But.

Shawn (18:10.094)
That's exactly right. And one of the things that I try to elucidate people why you don't want to treat security as a bolt on or some switch that you flip at the end and say, well, ha, we're secure, is that when you do that, you don't give your developers access to the security assets. And developers are actually incredibly inventive people. And when you add more tools to their toolbox, these security assets that they can use to do various things,

they will rummage around in that toolbox and go, hmm, I bet I could use this in this way. And they think of better ways to actually secure the code. You know, like, let's say, for example, you're about to go into a critical section of code. They see a secure API that says, hey, I can actually check the authenticity of this code before I go into this critical section, just to make sure I haven't been hacked or anything, rather than just.

Jacob (19:04.637)
Mm

Shawn (19:07.502)
a blithely continuing into this section of code. And they'll use that API to make sure that, yeah, the code's still legitimate. And that's an extra step and an extra layer of protection around the whole system that you don't get when you treat it as a bolt on at the end. But you're exactly right that you have to start thinking about threat modeling and whatnot. And that's kind of also been...

One of the reasons why people have been a little bit reticent to engage in the security topic is they let the perfect be the enemy of the good enough. And so I usually try to remind people security is not a destination. It's a journey. You don't arrive at, hey, we're secure and we never have to think about this ever again. What it is is that it's always a cat and mouse game. And what you do is you up your security game.

Jacob (19:38.405)
Yeah. Mm -hmm. Yeah.

Shawn (20:01.678)
and make it way harder for a threat actor to, uh, to compromise your product and then see what they do. Because in a lot of cases, they're going to wind up going and trying to hit an easier target. Um, you know, which is not always the best security, but if you start thinking about it, you know, we've got deadbolt locks on our doors and we have alarm systems, but everybody's got houses that are surrounded by glass windows. You know, it's.

Jacob (20:26.333)
Yeah.

Shawn (20:30.414)
pretty easy to break in. It's the same thing with car systems. We have theft deterrent systems, the low jack type systems where they can track the location of the car. We can also lock the car, but it's surrounded by glass and everything can be defeated to an extremely motivated attacker. But the goal is to, as we learned from certain car manufacturers who we won't talk about,

Jacob (20:55.997)
Yeah.

Shawn (20:58.574)
over the last couple of years, when you don't really think through and try to think of like a hacker and how they might potentially compromise the security, they basically attack the ones that they know how to attack and the ones that make it easy because they didn't imbue the devices with the high level of security.

And what they'll do is they'll wind up leaving the ones that they know have a high degree of security alone because it's the juice is not worth the squeeze. So, yeah, that's a very, a very good argument. But, you know, what we try to also tell people is in the threat modeling that you mentioned, which is a really good topic is you have to realize that there's a certain point where you're going to have to say, I can't do anything past this point.

And that's okay to recognize that. But what you really want to do is be able to show your board, especially if something bad happens, you know, when your system eventually does get compromised, you can at least show, hey, I thought this through. And these are all the threats that we considered. And we said up to this line right here, we can do something about it.

this line, we really can't do anything about it because of A, B, and C. And you elucidate all the reasons why it's just simply not practical for you to be able to do that. And people will tend to give you a pass in terms of the black eye that you take whenever a system's compromised. When they see that you've actually done some pretty sophisticated security analysis and engineering around the problem, they realize, oh,

I guess you just kind of got unlucky. You really did treat this seriously and it seemed like you were doing all the best practices. They tend to be a lot more forgiving. But the last thing you want to do is just be like, well, we didn't think anybody would care about it. Yeah, it's a $99 product and we didn't want to spend an extra five cents on the product, on the BML to treat security seriously because we figured nobody's going to pay.

Jacob (22:53.021)
Yeah. Mm

Shawn (23:13.27)
You know, that five cent BML typically translates into a 35 cent cost increase. So, you know, we just thought you wouldn't do that. But, you know, the really interesting thing is that when you look at, when you look at people who do focus groups and research on these types of topics with consumers, one of the biggest concerns to adopting IOT based technology.

is people's perception that security is treated with a certain degree of informality amongst embedded developers. And that's not, and that's a reputation that unfortunately we as embedded developers have actually earned. You know, we, we kind of deserve that reputation because we do have a tendency to say, and you know, that's not really what I'm interested in developing or, and that's a tough problem or.

Well, I can't solve this perfectly, so I'm just not even going to worry about that. That's just the wrong opinion. It's the wrong approach. You know, you have to do the best that you can and at least show that you've thought about it, enumerated what things can happen, say this is the boundary where we can do something about it. We feel we can reasonably do something about it. And you learn a lot actually by doing that, by doing that threat model.

And you discover things that you never thought, you know, ways that actors could try to maliciously attack your device that you had never considered before. But you also make your products so much better when you start to consider all these things. So, you know, it's an interesting time in embedded development, you know, with the security topics and the AI.

Jacob (24:56.967)
It is. I mean, you look back, you know, five, 10 years ago, maybe even 15, like, you know, 15 to 20 when I was entering the industry, I guess it's almost 20 now. You know, we didn't have to think about any of this stuff. I mean, it was all disconnected. And the biggest concern was, oh, I might have to write some assembly language code, right, to speed up some loop. And now it's suddenly where we've kind of integrated with the much larger software industry where we're worried about, you know, the languages we use, security, AI.

Shawn (25:14.422)
Yeah.

Shawn (25:20.928)
Yeah.

Jacob (25:24.765)
You know, DevOps, how do we connect the system? How do we scale that? You know, a lot, I see a lot of teams that, you know, they don't look at their individual product anymore as a one -off, right? Everything is platform based development, right? We're going to develop a system and the code that we build is going to be the framework on which we build, you know, maybe dozens of products over the next 10 to 15 years. Right. And so it's a far cry from the, I'm going to build this one little widget that's resource constrained and.

We'll maintain it for a few years and be done with it.

Shawn (25:54.638)
Yeah, there's actually two things I was going to say on that comment. You know, the whole thing with the disconnection, you know, we've heard a couple of customers say things of the ilk like, well, you know, our product's going to be on a Navy warship, you know, so it's going to be out in the middle of the ocean. So we don't really care about security because it's the Navy that provides security. I'm like, I wonder how that argument's going to age when somebody does find a way to...

get around the system that you have, you know, particularly if a weapon is launched, you know, I wonder how that argument's going to age because that is what we call a failure of imagination of how an enemy can attack that certain regard. And that's always concerning to me how people just, they kick the can where that's somebody else's problem. It's somebody else's problem. And what I try to educate customers is security is everybody's problem.

It's not the backhaul team's problem. It's their problem and your problem. And you both need to be working together to add extra layers of security. So, you know, let's say that your backhaul team's SSL connection gets compromised. Well, does that mean you throw up your hands and now you have no security and you know, that's it? Well, if you're encrypting data that's being sent back and forth, you have an extra layer of protection while you figure out how to address the problem with the SSL connection.

So when you wrap it in multiple layers of security, you're not over engineering the product. You are, as we said, with engineering, you're planning for the worst and hoping for the best. So that's definitely a way that you want to do that. And the second thing that you mentioned was on platforms. I remember when I was working at Texas Instruments, we would always try to design a platform for a calculator and say, okay,

There's going to be some jumpers on the board and depending upon which one, which jumpers are closed, it's going to be a this calculator or this calculator. And we were really trying to do that when we revamped the NGI line, the non -graphing instructionals like the 30 XA and whatnot. And, you know, we tried really, really hard to make that happen, but we realized, and this just isn't practical. And, uh, it, it made it very difficult.

Shawn (28:18.766)
Now, we did share some common code components across different calculators, obviously, in the math facts and whatnot. But we found that it was kind of an intractable problem. And what I realized is that we were actually facing this from the opposite end that we probably should have. And I'm thinking of a specific customer that I'm not authorized to disclose their name, but everybody would know exactly who I was talking about. They may...

Jacob (28:42.573)
Yeah.

Shawn (28:48.686)
billions of dollars a year making products that everybody knows about. But anyway, the way that they approached it is a completely opposite way of it. And so what they do is they have about seven or eight hardware platforms that you can choose from. So if you're going to design a new product, you have to choose from one of these seven or eight hardware platforms. And once you choose that platform, you can add whatever you want to.

onto that, but it has to be based on one of these seven or eight. So what this means is that there are some core components with the hardware abstraction layer that are standardized across the entire company that makes it much, much easier for people to develop and it accelerates the speed of performance. So they kind of approached it from a completely opposite perspective of, you we're not just designing one calculator and we're hoping that we're going to be able to use that.

They said, let's talk about what are the common core components across the entire product line and let's design, you know, one platform. And then one platform became two and three and four. And ultimately they decided that with about seven or eight core platforms, they could address the entire gamut of what they're doing. So they still, uh,

they still give their individual business units autonomy and say that, you know, if you don't want to use one of these six or seven or eight platforms, you can go design your own thing, but you have to write a study and an analysis why none of these seven or eight are actually appropriate for what you want to do. And so in the end analysis, what happens is, is that nobody goes.

Process they say all right How can we take one of these and and you know? Let's let's put some extra components and do the things that we need to do and it's actually served them incredibly well so You know I used to be a little bit skeptical of that approach But now that I've actually seen how somebody can make it work like oh, okay. This is where we went wrong and you know You can do things that people used to think were impossible, which is pretty cool, you know?

Jacob (30:52.657)
Yeah. Yeah.

Shawn (31:04.078)
Because as you alluded to, we've been in this industry long enough. We're always like, ah, I've seen it before, you know, nothing new here. But, you know, another thing in mentioning that we were just riffing before we started the podcast, we were talking about different languages and different language standards. And, you know, that's also a really interesting topic. You know, we were discussing Rust.

Jacob (31:06.749)
Yeah.

Jacob (31:29.871)
you

Shawn (31:31.886)
You know, and the White House recently said, you know, you should be using memory safe languages like Rust. And, you know, I kind of look at that and I go, you know, I'm not really sure how to feel about it. Um, it, from two standpoints, you know, one, the, the old school thing. And I, I'm sure you've seen this too, Jacob, that, uh, through the years, we've always heard, you know, Java is going to replace C plus plus everything's going to be Java. And, you know, there's.

Jacob (31:59.197)
Oh yeah.

Shawn (32:01.55)
It seems like every five to 10 years, there's this shiny new object that everybody's going to be developing in this. It's going to completely displace C and C++, and then it never really happens. It's the hype cycle, the Gartner hype cycle. And where is Rust on this hype cycle? Well, it's clearly trending upward, but is it really going to change things? I don't know. The...

Jacob (32:13.149)
It doesn't happen. Yep.

Jacob (32:21.437)
up.

Shawn (32:25.838)
It's a little early to tell simply because the language specification is changing so much. It's really hard to tell what kind of impact it's going to have in the embedded industry. I can see it having an impact certainly on typical IT infrastructure like we talked about in terms of cybersecurity. But as far as embedded devices, it's a little bit harder to say. But I always look back and say, okay,

Yeah, there are some memory type safe things that Rust does, which I think are really cool things to do. But if you're using C and C++ properly, along with static analysis, we know the holes in C and C++ and the things you shouldn't be doing. So if you're using good programming practices, and even if you're not using good programming practices,

Using static analysis tools will teach you those. Static analysis code tools to me, I heard a customer put it this way and I thought this so perfectly encapsulates it. What it really is, is it's a teacher to teach you how to write better code and that, you know, our CSTAT static analysis tool, as he said, over time, the number of messages that are elicited from CSTAT for your code that you're submitting,

or using C -Stat should trend towards zero, that it shows that you're learning to write really good code. You know, nobody's perfect. You're going to make mistakes, you know, like the spelling and grammar checkers in Microsoft Word. You're going to misspell a word every now and then. You're going to have a run -on sentence. And it's there to help, you know, oh, hey, you made a little mistake here. But when you're first starting out, it really teaches you to think through some of the code and the way that you design the code. So,

A lot of the things that Rust is intended to do is it just kind of seems to me it's, it's trying to idiot prove software development, which is not necessarily a bad goal, but I just look at it and go, you know, do we really, it's complicated. I see it from, from all sides. You know, you want to enable more people to develop better code. Totally understand that, but I just haven't seen a compelling argument that says why.

Jacob (34:38.429)
Yeah.

Shawn (34:49.71)
This is really going to display CNC plus plus as being the embedded device language of choice. You know, five years from now we'll see where it's going, but you know, we were having the same discussion around Java, you know, eight, nine years ago, maybe 10 years ago. And, uh, Java didn't really do too much for the embedded industry. It's still out there. You know, there, there's still a little bit of it in use, but you know,

I have the feeling that Rust for embedded systems is going to be a little bit more that way. And then when you start getting into different dialects of C and C++, you know, sometimes we'll have customers ask about, well, when are you going to support, you know, this latest language standard? And of course, my first question to them is, what is in this latest language standard that's not in the C or C++ standard that we currently support that you feel you really need?

that's actually appropriate to use in an embedded system. And usually that's where people kind of, you know, occasionally I'll get surprised and somebody will actually come up with a good cogent argument as to what they want to do. But nine times out of 10, maybe 99 times out of a hundred, it's, hey, this is the shiny new object. Why don't you support this? You know, like, well, it's not been completely ratified yet. That's one of the reasons why we don't go off and.

Jacob (35:50.397)
Yeah.

Jacob (36:02.353)
Mm -hmm. Yeah.

Shawn (36:15.412)
start coding to a moving target. You have to let the standard actually be ratified before you can start coding to it. And then you have to start asking yourself, is this stuff that we're putting in this language specification, is this really appropriate for an embedded system? Because that in and of itself can introduce security holes. So I mean, there's lots of interesting things going on in the embedded industry in that regard. But...

Jacob (36:33.085)
Yep.

Shawn (36:44.814)
bring up really good questions and topics. It's just a fascinating time to be an embedded developer.

Jacob (36:52.797)
It absolutely is. There's so much going on. And I'm kind of in the same boat. I've not also heard much that makes me convinced that we should run out and adopt a Rust in the embedded space. I've looked at the language, and there's certainly interesting things. But there is, like you said, there's stuff in there that I could see more people moving from C to C++ than going making a jump from C to Rust. And I've actually seen, with some of the customers I've been working with, I've seen more interest in folks.

saying, hey, we want to move from C to C++, and saying we want to adopt Rust. But you never know. It's always interesting to see as these things pop up and see what other people are seeing and hearing in the industry. And so it seems like you're seeing very similar types of things that I am as well.

Shawn (37:27.246)
Right.

Shawn (37:39.374)
And I, you at some point something will display C and C++ as being the de facto programming language, but I'm not sure it's this. You know, we'll see.

Jacob (37:49.309)
Yeah. It's going to be some AI generated language where we just tell it what we want and it generates the... Exactly.

Shawn (37:55.79)
And it starts dropping out machine language. Yeah. You know, not even assembler. I mean, it's just straight to binary. Like, ah, what does this mean? I don't know, but it seems to work.

Jacob (38:02.597)
Yep.

Jacob (38:06.405)
Yep. It passes the system tests and integration tests. It must be doing what we want, right?

Shawn (38:11.342)
Yeah, that's exactly right. You know, it just reminds me of how people will teach a game or, you know, tell it, hey, go learn how to play X, Y game. And then it comes up with these surprising strategies. Like, all you do is you just hit the pause button and then, you know, you do X, Y, Z. And it does something completely orthogonal to the goal. Well, it achieves the goal, but it does something completely orthogonal to.

Jacob (38:31.101)
Ha ha.

Shawn (38:39.278)
how we thought we had the parameters set for it to achieve that goal. And they're like, well, it feels like cheating, but it actually achieves the goal.

Jacob (38:50.211)
It's a goal. Yep, and if it gets you there within a reasonable time period and reasonable cost, then hey, maybe that's the right way to do it. But very cool. Well, hey, I really appreciate you taking the time to talk about all these different topics today. I really appreciate it. And yeah, hopefully we'll talk here again soon. And let us know if you hear of any other interesting things going on. And we'll be happy to chat some more. So.

Shawn (39:00.078)
Yeah, exactly.

Shawn (39:18.35)
Yeah, absolutely. Thank you for your time, Jacob.

Jacob (39:21.437)
Yeah, absolutely. Maybe before we leave, do you have any final closing thoughts you want to share with everybody?

Shawn (39:26.616)
Um, get out and ride your bike. You know, it's a, cause summer, uh, spring's coming. Uh, but yeah, you know, uh, love for people. If you're curious about IAR systems, you know, feel free to contact me personally. Uh, it's Sean at IAR .com. So S H A W N at IAR .com.

Jacob (39:29.917)
There you go.

Shawn (39:48.29)
You know, you can check out our website. You can also reach out to our more generic email address, which is fae .us at iar .com. And we'd be happy to, you know, talk about what your system's doing, you know, see if there's any synergies on how we can help you. You know, we don't necessarily have to talk about our products, but, you know, we're always interested in engaging with people, finding out what they're doing and, you know, what are you paying?

what kinds of problems are you trying to solve and maybe kick around some ideas. You know, it's always fun to talk with people. I've always got time to talk to people because as I said, it's one of my favorite things to do.

Jacob (40:32.303)
Excellent. Thank you very much. We really appreciate that. And I'm right there with you, which is why I kind of do this podcast and get the opportunity to kind of catch up with everybody and kind of see what's new and listen to hear what you guys are seeing. So all right. So with that, I want to thank everyone for their time and attention. And we look forward to talking with you again here soon.

Shawn (40:51.692)
All right, bye bye.