Speaker 1: Okay, so let's unpack this. It is Thursday, February twenty sixth,
Speaker 1: twenty twenty six, and today we are going to look
Speaker 1: at something that is literally all around.
Speaker 2: You right now, well absolutely everywhere.
Speaker 1: Yeah, Like it is probably on your mist it's definitely
Speaker 1: in your pocket, it's in your car, and it might
Speaker 1: even be in your toaster. But you never really.
Speaker 2: See it, right, which is I mean, that's the mark
Speaker 2: of a good design, right, If it's working perfectly, it's
Speaker 2: completely invisible. It's kind of the dark matter of the
Speaker 2: digital world.
Speaker 1: The dark matter. I love that exactly. So we are
Speaker 1: doing a deep dive today into the invisible digital infrastructure
Speaker 1: that basically runs the modern world. We are talking about
Speaker 1: embedded systems and to guide us through this absolute maze
Speaker 1: of you know, wires and logic gates, we're doing a
Speaker 1: deep dive into the source material here, which is the
Speaker 1: book Architecting High Performance Embedded Systems by Jim Leaden.
Speaker 2: It's a fantastic resource.
Speaker 1: It really is. Now. I have to admit, when I
Speaker 1: first saw the title, I thought, well, I thought, okay,
Speaker 1: this is going to be a super dry technical manual.
Speaker 2: Sure, yeah, it sounds like one.
Speaker 1: Right, but it's actually a beast of a book. I
Speaker 1: mean it covers everything from the literal physics of sensors
Speaker 1: all the way up to computer chips that can basically
Speaker 1: rewire themselves on the fly.
Speaker 2: It is a comprehensive guide for sure. And what I
Speaker 2: really appreciate about Lenins approaching this book is that he
Speaker 2: doesn't just treat these systems as well as like small computers.
Speaker 2: He really emphasizes the immense complexity and the precision that's
Speaker 2: required to actually make them work. Because you know, unlike
Speaker 2: your laptop, which just sits in a nice air conditioned
Speaker 2: room or on your desk hopefully right, hopefully, these embedded
Speaker 2: systems they live out in the real world there in
Speaker 2: the mud, the heat, the freezing rain, and you know,
Speaker 2: literally bolted inside exploding car engines.
Speaker 1: Yeah, the environment is brutal. So let's start with the
Speaker 1: basics for you listening, what actually counts as an embedded system?
Speaker 1: Because I feel like that term gets thrown around a lot,
Speaker 1: like I have a laptop, I have a smartphone, I
Speaker 1: have a car. Are they all embedded system?
Speaker 2: It's a really great question to start with. The core
Speaker 2: definition Leaden gives is pretty specific. An embedded system is
Speaker 2: digital processing that is integrated into a device that has
Speaker 2: a larger purpose beyond just computing.
Speaker 1: Well, okay, unpack that a bit, a larger purpose beyond computing.
Speaker 2: Yeah, so think about your laptop. Its entire purpose is
Speaker 2: to compute. It is a general purpose machine. Right. You
Speaker 2: can use it to write a novel, you can edit
Speaker 2: a video, you can calculate a giant spreadsheet. It's flexible.
Speaker 2: But a car, a car's purpose is to move people
Speaker 2: from point A to point B right to drive exactly.
Speaker 2: The computers inside the car are just there to facilitate
Speaker 2: that physical movement. They are specialists.
Speaker 1: Okay, So the laptop is the jack of all trades
Speaker 1: and the embedded system is the master of one.
Speaker 2: Precisely, And Lettin uses a really great simple example to
Speaker 2: draw the line here. He calls it the toothbrush test.
Speaker 1: The toothbrush test. Okay, I love this. Break it down.
Speaker 2: So take a standard electric toothbrush from say, maybe twenty
Speaker 2: years ago. Bat a motor and the little physical switch
Speaker 2: you turn it on, the circuit closes, the motor spins,
Speaker 2: and you brush your teeth. Is that an embedded system.
Speaker 1: I'm gonna guess. No, I mean it's just it's electric, right,
Speaker 1: It's just mechanics and a battery.
Speaker 2: Right. There is no digital processing happening. It's just dumb logic.
Speaker 1: Right.
Speaker 2: But take a modern smart toothbrush, the kind that lights
Speaker 2: up red if you press too hard against your gums.
Speaker 1: Oh yeah, I have one of those. It actively gets
Speaker 1: angry at.
Speaker 2: Me exactly, and that anger requires intelligence. It has a
Speaker 2: physical sensor to measure pressure. That sensor feeds analog data
Speaker 2: to a tiny micro controller okay, and then the micro
Speaker 2: controller processes that data and mathematically decides, hey, that is
Speaker 2: too much force. I need to turn on the red
Speaker 2: led and slow down the motor.
Speaker 1: That whole loop, that is an embedded system. It is
Speaker 1: a layer of digital thinking tucked inside an everyday object.
Speaker 2: Wow. And unlike my laptop, which, let's be honest, I
Speaker 2: have to reboot like once a week because it just
Speaker 2: gets confused. Yeah, things have to be incredibly robust.
Speaker 1: That is the other massive key distinction here. These systems
Speaker 1: don't usually have nice cooling fans. They have to survive
Speaker 1: intense vibration, dust, wild temperature swings.
Speaker 2: Because they're in the real world. Exactly. Think about it.
Speaker 2: If your laptop crashes, you lose an unsaved word document annoying,
Speaker 2: but fine. If the embedded system in your car is
Speaker 2: anti lock breaking, unit crashes, oh man. The consequences are
Speaker 2: physical and they are immediate.
Speaker 1: That makes total sense. And this naturally bleeds into I
Speaker 1: think the biggest buzzword of the last decade, which is
Speaker 1: the Internet of things or IoT because once you have
Speaker 1: that smart toothbrush, the next logical step for a company
Speaker 1: is to make it talk to your phone. Right.
Speaker 2: That is the natural evolution, and let draws a very
Speaker 2: clear line there in the source material. Embedded systems evolve
Speaker 2: into the Internet of things when they start communicating with
Speaker 2: central nodes. It's all about massive network communication.
Speaker 1: The book mentions some examples that really show the sheer
Speaker 1: scale of this. On one hand, you have everyday stuff
Speaker 1: like smart speakers, your Amazon Echo, Google Nest sitting in
Speaker 1: your living room just waiting for a wake word.
Speaker 2: Right, an admitted system that's listening, processing audio locally, and
Speaker 2: then communicating with the cloud.
Speaker 1: But then you connect that same concept to the industrial side.
Speaker 1: Think about an oil pipeline. You have embedded systems monitoring
Speaker 1: flow rates, pressure and temperature over thousands of miles of
Speaker 1: pipe exactly.
Speaker 2: So instead of a guy in a truck having to
Speaker 2: drive out into the middle of nowhere to check a
Speaker 2: physical gauge.
Speaker 1: The pope itself basically sends a text message saying, Hey,
Speaker 1: I'm leaking.
Speaker 2: Yes. Yeah, it's incredibly efficient, but this is a big butt.
Speaker 2: The book issues a pretty stark warning here regarding security.
Speaker 2: Oh absolutely, because when you take a device that was
Speaker 2: originally designed to be a simple, isolated specialist, like a
Speaker 2: home thermostat or a pipeline valve, and you suddenly give
Speaker 2: it a live Internet connection, you are opening a door.
Speaker 1: And historically these things aren't exactly built with Fort Knox
Speaker 1: level security, are they No.
Speaker 2: Historically they are not. And that's exactly the danger. If
Speaker 2: a malicious actor hacks your personal laptop, they might steal
Speaker 2: your credit card info. That is bad, obviously, but it's manageable.
Speaker 2: But if they hack an IoT system like a medical
Speaker 2: pacemaker or that oil pipeline we mentioned, or the steering
Speaker 2: control of a connected car, we aren't talking about data
Speaker 2: loss anymore. We are talking about severe risks to physical safety.
Speaker 1: It's the difference between a privacy nightmare and a literal
Speaker 1: safety crisis.
Speaker 2: Yeah, exactly. Leaden emphasizes that in this new IoT world.
Speaker 2: Security cannot just be a software pass you add on later.
Speaker 2: It has be baked into the very architecture of the
Speaker 2: hardware from day one.
Speaker 1: It's terrifying but also fascinating. Okay, let's step back a
Speaker 1: bit and look at how these systems actually interact with
Speaker 1: the physical world. Because a computer chip, at the end
Speaker 1: of the day only knows ones and zeros. It doesn't
Speaker 1: know what hot or fast or loud actually feels like.
Speaker 1: It lives in this dark digital bubble.
Speaker 2: And this is the realm of sensors. This is how
Speaker 2: the system literally senses the outside world. Letting categorizes them
Speaker 2: into two main buckets in the book that are super
Speaker 2: helpful to understand, passive and active sensors.
Speaker 1: Okay, passive sounds a bit safer. What is a passive sensor?
Speaker 2: A passive sensor just sits there and measures the environment
Speaker 2: exactly as it is. It's observant. A classic example he
Speaker 2: gives as a thermister. A thermister, Yeah, it's a special
Speaker 2: type of resistor that changes its electrical resistance based on
Speaker 2: the ambient temperature. It's not doing anything to the air
Speaker 2: around it. It's just reacting to the heat.
Speaker 1: Okay, so kind of like a sponge soaking up water.
Speaker 1: It changes its state based on the environment, but it
Speaker 1: doesn't spray water back out.
Speaker 2: That's a great analogy. Now contrast that with an active sensor.
Speaker 2: An active sensor actually goes out and pokes the world
Speaker 2: to see what happens.
Speaker 1: It pokes the world.
Speaker 2: Well in a way. Yes, think about an ultrasonic sensor.
Speaker 2: These are used a lot in robotics and in the
Speaker 2: parking sensors on your car bumber.
Speaker 1: Oh, the ones that beep when you get too close
Speaker 1: to a wall.
Speaker 2: Exactly, that sensor actively sends out a ping, a high
Speaker 2: frequency sound wave. Yeah, and then it immediately switches into
Speaker 2: listening mode and waits to hear the echo bouncing back like.
Speaker 1: A bat using echolocation or submarine.
Speaker 2: Exactly like that. It uses a concept called time of flight.
Speaker 2: The system knows the exact speed of sound, so it
Speaker 2: sends the ping out, starts a tiny internal stopwatch. Here's
Speaker 2: the echo return, and stops the watch.
Speaker 1: Oh, and then it just does the math.
Speaker 2: Right, the time it took tells you exactly how far
Speaker 2: away the physical wall is. That is active sensing. You
Speaker 2: generate a stimulus and you measure the real world response, and.
Speaker 1: The source material mentions lightar and radar working on similar principles.
Speaker 2: Right, Yes, lightar is completely fascinating. Instead of sound waves,
Speaker 2: it uses pulses of laser light. By spinning that laser
Speaker 2: around and measuring millions of those time of flight returns
Speaker 2: every single second, an autonomous vehicle can build what's called
Speaker 2: a point clide a point cloud. Yeah, it's basically a
Speaker 2: real time three D map of the entire world around
Speaker 2: the car. The computer knows that this specific cluster of
Speaker 2: data points is a pedestrian walking, that cluster over there
Speaker 2: is a stationary tree, and that fast moving cluster is
Speaker 2: another car. It's literally seeing the world in three D geometry.
Speaker 1: That is just incredible. But here is where it gets
Speaker 1: really technical and honestly, I think really interesting. The real
Speaker 1: world is analog like. Temperature doesn't just jump from seventy
Speaker 1: degrees to seventy one degrees in a single instant step.
Speaker 1: It flows smoothly, it's continuous, right, But computers are digital.
Speaker 1: They only understand distinct steps. They're choppy. So how do
Speaker 1: we bridge that gap between a smooth world and a
Speaker 1: choppy computer.
Speaker 2: That crucial job falls to the ADC. The analog to
Speaker 2: digital converter. It acts as the ultimate translator. Imagine you
Speaker 2: are drawing a smooth, sweeping curve on a piece of
Speaker 2: graph paper.
Speaker 1: Okay, I'm picturing it.
Speaker 2: The real physical world is that smooth curve. The ADC
Speaker 2: is looking at that curve at very specific tiny points
Speaker 2: in time. This is called sampling it, and it's turning
Speaker 2: each specific point into a precise digital number.
Speaker 1: So if you don't sample it fast enough, you miss
Speaker 1: all the details of the current exactly.
Speaker 2: That's a problem called aliasing. If you blink too slowly,
Speaker 2: you might miss the baseball flying right past your face.
Speaker 2: The source material talks about the XCDC hardware on the
Speaker 2: RDA seven board.
Speaker 1: Right, the RDA seven, which is a specific FPGA development
Speaker 1: board they use as an example.
Speaker 2: Yes, that specific hardware can sample the analog world up
Speaker 2: to one million times per second.
Speaker 1: One million times a second. That is, I mean, I
Speaker 1: can't even wrap my head around that.
Speaker 2: And honestly, that's just considered standard for high performance control.
Speaker 2: Some advanced radio frequency systems sampled into the billions of
Speaker 2: times per second. It creates this absolutely massive fire hose
Speaker 2: of numbers that the processor then has to crunch.
Speaker 1: Okay, so we have the data. Now, the sensor has
Speaker 1: picked up the physical world, the ADC has translated it
Speaker 1: into digital numbers. Now, how does that data actually get
Speaker 1: to the main brain of the system. We need a
Speaker 1: nervous system.
Speaker 2: We absolutely do. And these are called the communication protocols.
Speaker 2: Depending on exactly what you're trying to do, you pick
Speaker 2: a different digital language.
Speaker 1: Let's run through the big ones mentioned in Letin's book.
Speaker 1: Start with the absolute simplest one GPIO.
Speaker 2: Okay, GPIO General purpose input output. This is basically the
Speaker 2: brute force method. It's usually just a single wire that
Speaker 2: is either on or off high voltage or low voltage.
Speaker 1: One or zero, kind of like a physical light switch.
Speaker 2: Perfect analogy is the machine's safety cover open, yes or no?
Speaker 2: Is the emergency button currently pressed? Yes or no? It's
Speaker 2: incredibly fast, it's instant, but it obviously doesn't carry complex data.
Speaker 2: You can't send a JPEG image over a light switch.
Speaker 1: Right, Okay, So what if we do need to send
Speaker 1: actual complex data. The book talks about a protocol called
Speaker 1: I two C.
Speaker 2: I two C or inter integrated Circuit. I always like
Speaker 2: to call this one the polite conversation.
Speaker 1: Polite Why polite?
Speaker 2: Because it uses just two wires. One wire is a
Speaker 2: clock to keep the timing synchronized and the other is
Speaker 2: for the actual data. But it can connect multiple different
Speaker 2: devices using a clever address system. It uses a master
Speaker 2: servant architecture. Okay, so the master controller says, hey, Sensor A,
Speaker 2: it's your turn to speak, and Sensor A talks. Then
Speaker 2: the master says, okay, thank you, Sensor B, now it's
Speaker 2: your turn.
Speaker 1: Ah, So they actually take turns on the wire.
Speaker 2: Yes, it's what we call half duplex. You can only
Speaker 2: send data or receive data at one specific time, not both.
Speaker 2: It's great for simple things like reading a temperature sensor
Speaker 2: once a second, but it's a bit slow.
Speaker 1: So what if I have a real need for speed,
Speaker 1: like if I'm streaming that crazy one million sample per
Speaker 1: second data from the ADC, then you.
Speaker 2: Need to upgrade to SPI Serial Peripheral Interface. This is
Speaker 2: the speedy connection. It uses four wires instead of two,
Speaker 2: and because it has completely separate dedicated wires for sending
Speaker 2: and for receiving, it is full.
Speaker 1: Duplex, meaning it can talk and listen at the exact
Speaker 1: same time exactly. Sounds like a chaotic argument where everyone
Speaker 1: is just yelling over each other.
Speaker 2: Actually, it's more like a highly efficient high speed telephone
Speaker 2: call where both people are talking and perfectly understanding each
Speaker 2: other simultananeously. It can run much much faster than it
Speaker 2: two see easily up to fifty mega herds for more wow.
Speaker 1: Okay, but what about inside cars? Because I know modern
Speaker 1: cars are an absolute nightmare of electrical noise. You have
Speaker 1: spark plugs firing thousands of times a minute, giant alternator
Speaker 1: spinning that creates massive electromagnetic interference.
Speaker 2: Very hostile environment for electronics.
Speaker 1: So how do the tiny computer chips communicate without their
Speaker 1: data just getting completely scrambled by all that engine noise?
Speaker 2: That is exactly where the CANbus comes in the controller
Speaker 2: area network. It is the absolute gold standard for automotive systems,
Speaker 2: and the way it physically handles that noise is just
Speaker 2: brilliant physics.
Speaker 1: Okay, how does it work.
Speaker 2: It uses something called differential signaling. Imagine you have two
Speaker 2: separate wires running right next to each other through the car.
Speaker 2: When the system wants to send a signal, it sends
Speaker 2: a positive voltage down one wire and a negative voltage
Speaker 2: down the other wire.
Speaker 1: Okay, so like a plus one on the first wire
Speaker 1: and a minus one on the second wire.
Speaker 2: Right now, the receiving chip at the other end doesn't
Speaker 2: look at the absolute voltage on either wire. It strictly
Speaker 2: looks at the difference between the two wires. So positive
Speaker 2: one minus negative one equals two. The intended signal is two.
Speaker 1: Okay, I follow the math.
Speaker 2: Now, imagine a huge spike of electrical noise from the
Speaker 2: engine suddenly hits those wires. Because the wires are physically
Speaker 2: twisted together, the noise hits both wires equally. Right, Let's
Speaker 2: say it adds ten volts of pure noise, So the
Speaker 2: plus one wire becomes plus eleven and the minus one
Speaker 2: wire becomes plus nine.
Speaker 1: Ah, so both numbers instantly jump up.
Speaker 2: They do, but the receiver only cares about the mathematical
Speaker 2: difference between them, and eleven minus nine is still two.
Speaker 1: The signal is perfectly preserved exactly.
Speaker 2: The noise literally cancels itself out. It is an incredibly
Speaker 2: robust design. That is exactly why your anti lock breaks
Speaker 2: still work perfectly even when your engine is screaming at
Speaker 2: the red line.
Speaker 1: That is so smart. It's just elegant engineering.
Speaker 2: It really is. And there's one more very cool thing
Speaker 2: about cambus. Unlike it two C, there is no master controller.
Speaker 2: It's entirely peer to peer.
Speaker 1: Wait, so who decides who gets to talk? If there's
Speaker 1: no master it sounds like it would be chaos.
Speaker 2: The priority is actually built directly into the message ID
Speaker 2: number itself. If it deploy breaks message and the turn
Speaker 2: up radio volume message both try to talk on the
Speaker 2: network at the exact same millisecond. The system is physically
Speaker 2: designed so that the breaks have a lower ID number,
Speaker 2: and on a canvas, a lower number mathematically wins out
Speaker 2: and gets higher priority.
Speaker 1: That is amazing. The radio automatically just shuts up and
Speaker 1: waits yep.
Speaker 2: The physics of the wire forced the lower priority message
Speaker 2: to back off.
Speaker 1: I honestly wish human conversations worked like that, Like important
Speaker 1: safety info just mathematically overrides small talk.
Speaker 2: It would definitely make office meetings a lot more efficient.
Speaker 1: No kidding, Okay, So we had our sensors and we
Speaker 1: have the nervous system protocols. Now, let's talk about the brain.
Speaker 1: And this is where the book really focuses heavily. We
Speaker 1: aren't just talking about normal CPUs here, we are talking
Speaker 1: about FPG.
Speaker 2: Yes, this is where the engineering gets really interesting. FPGA
Speaker 2: stands for field programmable gate array.
Speaker 1: Field programmable makes it sound like I can literally fix
Speaker 1: it while I'm standing out in a cornfield.
Speaker 2: I mean, basically, yes, it means you can completely change
Speaker 2: how the physical chip works after it has already been
Speaker 2: manufactured and deployed in the field.
Speaker 1: How is that fundamentally different from a normal computer processor
Speaker 1: like the one in my laptop.
Speaker 2: Well, a normal CPU like an Intel or AMD chip
Speaker 2: has a totally fixed hardware structure. It is etched in silicon.
Speaker 2: It reads software instructions one by one from memory. Add
Speaker 2: this number, then move this data, then check this condition.
Speaker 2: It operates sequentially right, one step at a time, exactly.
Speaker 2: And FPGA, on the other hand, is basically a blank
Speaker 2: box of digital lego bricks. Raw logic gates, memory blocks
Speaker 2: flip flops. When you program it. You don't write software
Speaker 2: that runs on the chip. You write code that literally
Speaker 2: rewires the electrical connections between those internal lego bricks.
Speaker 1: Wait, I'm physically well electronically changing the actual circuit.
Speaker 2: Yes, you are literally creating custom hardware on the fly.
Speaker 1: Let's break down those lego bricks you mentioned. The book
Speaker 1: talks a lot about logic gates.
Speaker 2: Right, These are the fundamental decision makers of the digital world.
Speaker 2: You have eighty gates which say if input A andy
Speaker 2: input B are true, then do this. You haver gates,
Speaker 2: exoor gates, and then you have flip flops, which act
Speaker 2: as high speed memory units. They hold a single bit
Speaker 2: of data for a split second based on the ticking
Speaker 2: of the system clock.
Speaker 1: And a single FPGA is just made of millions of
Speaker 1: these little gates, millions.
Speaker 2: Of them, and because you are wiring them all up
Speaker 2: yourself in whatever pattern you need, you unlock the FPGA's
Speaker 2: true superpower parallelism. Parallelism that is definitely the key word here.
Speaker 2: Think of a standard CPU as a genius level math professor.
Speaker 2: He can solve absolutely any problem you give him, but
Speaker 2: he can only solve one problem at a time. He
Speaker 2: is very fast, but he's working entirely alone. Okay, And
Speaker 2: FPGA is more like a giant room flow of ten
Speaker 2: thousand middle school students. They might not be as smart
Speaker 2: individually as the professor, but they can all solve a specific,
Speaker 2: simple problem at the exact same time.
Speaker 1: So if I'm processing an image that has a million pixels,
Speaker 1: the normal CPU has to look at pixel one, then
Speaker 1: pixel two, then pixel three exactly.
Speaker 2: Even if it does it fast, it's still sequential. The FPGA, however,
Speaker 2: can be wired to look at all one million pixels,
Speaker 2: simultaneously process every single one of them, and be completely
Speaker 2: done in a single tick of the clock. That is
Speaker 2: true hardware acceleration. It's not just about running faster, it's
Speaker 2: about doing everything at once.
Speaker 1: That honestly blows my mind. But you don't use regular
Speaker 1: programming languages like Python or C plus plus to program
Speaker 1: these things, do you.
Speaker 2: Well? You can use C plus plus with some newer
Speaker 2: high level synthesis tools now, which definitely helps. But underneath
Speaker 2: it all the native tongue of the FPGA is VHDL
Speaker 2: or verolog. These are hardware description languages.
Speaker 1: Hardware description.
Speaker 2: Right when you type in violog, you aren't writing a
Speaker 2: sequential to do list for the computer. You are describing
Speaker 2: a physical structure. You are telling the software I need
Speaker 2: you to connect this wire to that specific gait.
Speaker 1: It's drawing architectural pootprints, not writing a recipe.
Speaker 2: Perfectly put, it is hardware design, just done at a keyboard.
Speaker 1: So we have this amazing custom hardware brain. But there
Speaker 1: is one more massive constraint that Leaden really hammers home
Speaker 1: in the book, and that is the concept of real time.
Speaker 2: Yes, and this is a concept that is so often misunderstood.
Speaker 2: Real time does not just mean really fast. A supercomputer
Speaker 2: taking three days to predict the global weather is incredibly fast,
Speaker 2: but it's not real time. Real time means computing with
Speaker 2: the strict deadline.
Speaker 1: A deadline like it has to be done by a
Speaker 1: certain millisecond.
Speaker 2: The mantra of embedded engineering is the system must be
Speaker 2: functionally correct, meaning it gets the right math answer, and
Speaker 2: it must be temporarily correct, meaning it gets that answer
Speaker 2: at the exact right time. If the right answer arrives late,
Speaker 2: it is a wrong answer.
Speaker 1: The book distinguishes between hard and soft real time systems.
Speaker 1: What are the stakes here?
Speaker 2: Soft real time is low stakes. The classic example used
Speaker 2: is a car keyfob. You walk up to your car,
Speaker 2: you press the unlocked button. If the system takes two
Speaker 2: seconds to unlock the door instead of point one seconds,
Speaker 2: you might be annoyed.
Speaker 1: Right, you might angrily press the button this second time.
Speaker 2: Exactly, but the system hasn't catastrophically failed. No one is hurt.
Speaker 2: It just lag right. But hard real time think about
Speaker 2: the airbag controller in that same car. If you can
Speaker 2: do a crash, the sensor detects the sudden impact, the
Speaker 2: processor has to calculate the force and physically fire the
Speaker 2: air bag. If that system deploys the air bag even
Speaker 2: one hundred milliseconds.
Speaker 1: Too late, it's entirely useless. Or even worse, it deploys
Speaker 1: right as your head is moving forward and actually hurts
Speaker 1: you exactly.
Speaker 2: That is a total system failure. In hard real time engineering,
Speaker 2: missing the deadline by a fraction of a second is
Speaker 2: literally the exact same thing as the computer completely crashing.
Speaker 1: This has to create a huge challenge for the programmer,
Speaker 1: doesn't it. Because the process is usually doing a dozen
Speaker 1: things at once. It has to check the sensors, It
Speaker 1: has to update the dashboard display, it has to talk
Speaker 1: to the CAN network. How do you guarantee that the
Speaker 1: life or death stuff happens first?
Speaker 2: That is known as the scheduling challenge, and the book
Speaker 2: discusses this in great detail. I imagine you have an
Speaker 2: electric motor that needs its voltage adjusted fifty times every
Speaker 2: single second, so fifty hertz, just to run smoothly without
Speaker 2: burning out. But the processor also has a display screen
Speaker 2: that it needs to update ten times a second.
Speaker 1: And if the display update takes just a little bit
Speaker 1: too long to draw the graphics.
Speaker 2: The motor doesn't get its critical voltage adjustment on time.
Speaker 2: The motor physically stutters. In the industry, that's called jitter. Yeah,
Speaker 2: and jitter is the absolute enemy of real time systems.
Speaker 1: Jitter just the word makes me anxious. So how do
Speaker 1: engineers fix it?
Speaker 2: The standard solution is using an RCOs, a real time
Speaker 2: operating system. It's a highly specialized operating system that acts
Speaker 2: like a completely ruthless traffic cop. Yeah. It manages all
Speaker 2: the system priorities using some they called preemptive multitasking.
Speaker 1: Preemptive meaning just violently interrupts whatever is happening ruthlessly.
Speaker 2: If the motor control task suddenly says, hey, it's my
Speaker 2: exact millisecond I need to run right now, the RTOS
Speaker 2: instantly pauses the display update task right in the middle
Speaker 2: of drawing a pixel. Let's the motor code run, and
Speaker 2: then it resumes the display. It doesn't ask permission. It
Speaker 2: absolutely ensures the heart deadlines are met, even if the
Speaker 2: soft deadlines have to wait a microsecond. M Wow.
Speaker 1: Okay, So bringing this all together, we have gone on
Speaker 1: quite a journey here. We start from a physical change
Speaker 1: out in the real world, a temperature rise or a
Speaker 1: brake pedal being pressed. Right, that physical change becomes an
Speaker 1: electrical signal through a sensor. The ADC translates that analog
Speaker 1: wave into digital numbers. Then those protocols, the ITCDESPI, the
Speaker 1: can bus zip that data safely through the nervous system.
Speaker 1: It finally lands in a processor, maybe an FPGA, which
Speaker 1: might literally be physically rewired just to handle that specific
Speaker 1: data perfectly. All all of this is happening under a microscopic,
Speaker 1: strict deadline managed by a ruthless RTOS.
Speaker 2: Honestly, when you summarize it all put together like that
Speaker 2: is kind of a miracle that anything in our modern
Speaker 2: world works at all.
Speaker 1: It really is. It completely changes how you look at
Speaker 1: everyday things. When I go out and unlock my car
Speaker 1: door today, I'm not just opening a door. I am
Speaker 1: triggering a massive, silent symphony of physics, electrical engineering, digital logic,
Speaker 1: and perfect timing.
Speaker 2: And that is the true AHA moment for me. When
Speaker 2: studying this stuff. We look at a car or a
Speaker 2: smartphone and we just see a single solid object. But
Speaker 2: underneath the metal and glass. It's actually a high speed
Speaker 2: conversation between hundreds of tiny specialized computer systems, all shouting
Speaker 2: at each other in perfect synchronization.
Speaker 1: Before we wrap up today, I really want to leave
Speaker 1: you the listener with a provocative thought that struck me
Speaker 1: while reading the source material about FPGAs. We are so
Speaker 1: used to the idea that hardware is hard it's the physical,
Speaker 1: unchangeable silicon chip, and that software is soft it's the
Speaker 1: code you can easily update.
Speaker 2: Right, That's the classic divide.
Speaker 1: But with FPGAs we are literally rewriting the physical circuit
Speaker 1: layout on the fly, we are downloading hardware.
Speaker 2: It raises a really fascinating question.
Speaker 1: About the future, right, like, where does the line between
Speaker 1: hardware and software actually exist anymore? If I can just
Speaker 1: download a file from the Internet that fundamentally changes the
Speaker 1: physical electrical pathways of my computer chip, essentially downloading an
Speaker 1: entirely new computer architecture over Wi Fi, are we entering
Speaker 1: an arrow where the hardware itself is just as fluid
Speaker 1: and temporary as the code running on top of it.
Speaker 2: That is the absolute frontier of embedded design, And as
Speaker 2: these systems get more connected and more complex, that dividing
Speaker 2: line is only going to get blurrier and blurrier. The
Speaker 2: rigid static hardware of the past is very quickly becoming
Speaker 2: a memory.
Speaker 1: Definitely something to mull over the next time you are
Speaker 1: standing in the bathroom waiting for your smart toothbrush to
Speaker 1: perform a firmware update exactly Well, that is it for
Speaker 1: this deep dive into the invisible infrastructure of our life vibes.
Speaker 1: Thanks so much for listening.