YT YouTube2Text

YouTube2Text → Transcripts → EECS 373 - Fall 2026 - Lecture 11: "Serial Bus Over & UART"

EECS 373 - Fall 2026 - Lecture 11: "Serial Bus Over & UART" — Transcript

by Interactive Sensing and Computing Lab · 10,451 words · 1,538 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00from last time we talked about serial in
0:02general
0:03few extra slides and then we'll talk
0:05about different serial protocols we'll
0:07probably get through UR today and maybe
0:08start a little bit of SPI so for
0:11announcements uh slide ideation slides
0:14are due Thursday right in the day then
0:16we'll have your mic on
0:19>> I don't have my mic on I do have my mic
0:22on
0:27>> is this better
0:29Quiet.
0:32>> How about now?
0:35>> No. Better. [snorts] I can try a
0:36different mic.
0:46That's loud.
0:50How's that? Great. Thanks for letting me
0:53know. Uh, so team formation is on
0:56Friday. Uh James has already ordered the
0:58pizza. Um just come and find find
1:03partners, find teammates, and if you can
1:05look through the slides beforehand,
1:07they're going to be in that folder. And
1:09then homework is due uh on Monday. Any
1:13logistics questions?
1:18>> Yeah.
1:23>> Uh so technically I'm not going to watch
1:25you. You do have to sign a piece of
1:27paper to basically sign in and get free
1:30pizza so you can you can get out of
1:32there if you had to. But I really don't
1:35leave until you have a team because it's
1:37much harder to find a team when the
1:39people aren't in the room. And here's
1:41what happens. There's always a bunch of
1:43stragglers and they're screwing around
1:45and that's fine. I get life. And then
1:47they come to me and say they don't have
1:48a partner and then I just put them in
1:49the team and they don't know each other.
1:51They don't have anything any project
1:52ideas in common and it's painful, right?
1:55because then they nobody wants to work
1:56on the same thing. So don't don't get l
1:58get in that last group if you can avoid
2:01it.
2:04All right. All right. So we're talking
2:06generally about design considerations
2:08for USB or sorry for communication
2:10protocols in general. I'll just review
2:12them quickly and then we'll go forward.
2:14So, uh, we talked about wiring, whether
2:17it's serial or parallel. And then
2:20there's a bunch of trade-offs that you
2:21got. And essentially the big trade-off
2:23with parallel is that you get lots of
2:25speed. You got parallel wires. Multiple
2:27bits can go out per clock cycle, but for
2:31reasons that are a little bit beyond
2:32this course, they don't really go far.
2:34It's not it's not in physically long
2:36distances. That's good for like one chip
2:38to another chip on device,
2:40but trying to do a parallel bus over
2:43like a USB cable length or Ethernet
2:45cable length is pretty impractical,
2:47especially if you're trying to get up to
2:49really high speeds. And so, uh there's a
2:52trade-off there about distance. And then
2:54there's also the hidden cost of uh GPAO
2:58pins or just pins on a piece of silicon.
3:00how you're just not going to get 32 pins
3:03out of a really small piece of silicon
3:05or or lots of uh pins out. So then the
3:08default is that they're going to go to
3:10serial communication for usually for
3:12offdevice chip to chip communic or
3:14package to package uh communication
3:18unless they really need the bandwidth.
3:20Uh and then the bandwidth is usually
3:21like talking to a video card or talking
3:23to memory.
3:25Uh, and then so wiring and parallel
3:27versus serial is closely related to
3:30speed. Um, you can see that there's a
3:32there's an inherent trade-off, but
3:34that's the other thing when you're
3:35thinking about a protocol, the higher
3:36the speed is that there's a set of
3:38constraints that come into that. So, a
3:40lot of what your job is going to be in
3:42the industry is like which is the
3:44correct protocol for this job. Like I
3:46have to do a task of getting these
3:48things to talk to each other. Which one
3:49should I choose? And these are the
3:51constraints you have to figure out.
3:53Another
3:55set of constraints for these
3:57communication protocols we'll look at is
3:59that whether they're synchronous or
4:00asynchronous. And so synchronous means
4:03that there's a clock. And so there's a
4:04method for synchronizing the receiver to
4:07the transmitter so that the receiver
4:09knows when the clock cycle when to clock
4:11in the data. But that's not a
4:13requirement. You can certainly make a
4:15protocol and we'll look at one today
4:16that does not need a clock which is
4:19nice. You don't have to have an extra
4:20wire.
4:21So you reduce those pins that are hard
4:24to get. And if we also think about like
4:25wireless communication doesn't have
4:27inherently have a clock with it. So
4:29there must be a method here for
4:31recovering that clock. And we'll talk
4:32about that with the asynchronous
4:34versions. But it also makes things
4:36harder in the sense you have to actually
4:38recover that clock or figure out when
4:40you're supposed to be sampling those bit
4:41transitions.
4:43Um we talked a bit about the number of
4:46destination and sources. So a trivial
4:49case is just one to one. you have a your
4:51microcontroller is going to talk to say
4:52a wireless module. There's only one
4:54wireless module on your device. You're
4:55talking back and forth. That's pretty
4:57easy. But when you start getting to I
4:59have an array of sensors or I have 10
5:01different sensors of different types or
5:03maybe I have other IO devices, then
5:07choosing a protocol that's the right one
5:09that supports multiple sources or
5:11multiple uh destinations is important.
5:16uh the arbitration scheme which is the
5:18idea of how do you determine
5:20which device you should talk to. Um
5:24there are a bunch of different methods
5:26uh we'll review some uh which are
5:28related to uh select lines or addresses
5:31or it's just inherent because it's just
5:33one source to another source or one
5:34destination and one source. Uh protocols
5:37there's different data formats and this
5:39kind of lives typically above the
5:41signaling layer. So a lot of lecture is
5:43going to worry about the signaling layer
5:44like which lines go high but on top of
5:47that is the protocol layer and that's
5:48what is the format of the data and is
5:51there redundancy.
5:53All right so any
5:55questions about these sort of
5:57constraints or factors when thinking
5:59about uh communication protocols.
6:07Okay. So as you look through today and
6:10next week as we talk about more
6:12protocols, you should think about uh or
6:15more yeah communication protocols, you
6:17should think about which of these
6:19things, you know, which camp do they fit
6:21into and which one is allowing which one
6:23of these factors is allowing them to be
6:24faster, quicker or more um usable in a
6:28particular uh scenario.
6:31Uh I forgot if we asked this question
6:33yesterday or Monday, but why does ARM
6:36use parallel buses on the APB and we use
6:39chip to chips communication? Did we ask
6:41this question?
6:44All right, go talk amongst yourselves.
6:46Figure out a reason why ARM would choose
6:48to do this uh use parallel internal but
6:51serial out from device to device.
7:18My name is Jesus.
7:48All right. Why do we think why would why
7:50do we make this choice?
7:56outside.
8:04>> It's true.
8:06>> That's true. Why not use serial
8:07internally? It's less wiring. Seems
8:09easy.
8:11>> Yeah,
8:22>> Blate. Uh, you can do Yeah, that's true.
8:24And why wouldn't you want to do it
8:26internally on a chip? Why wouldn't you
8:27want to do take the time penalty for
8:29serial internally?
8:38Why isn't the APB serial instead of
8:40parallel?
8:49You guys have all good ideas. Yeah.
8:58Yeah.
9:01>> Right. So like that doing imagine you
9:02have to wait eight clock cycles just to
9:04send eight bits somewhere. That would
9:06just be inefficient. Right. So now
9:08they're trying to go as fast as
9:09possible. And the trick is just to think
9:12about the architectural constraints of
9:13silicon design. So here this is an old
9:15picture. This is only 8bit bus. Um I
9:18don't have I don't know where the buses
9:19are in the new chips, but um the idea
9:23here is uh doing eight bits or 32 bits,
9:26uh you really want that high speed, but
9:28there's lots of effectively space on a
9:30chip. You're not bound by these wires.
9:32So remember these S1, S0, all those
9:35bumps around, all those squares around
9:37that's the amount of space that's needed
9:39for uh IO. So this is these are pads
9:42that go out and there's just so many a
9:44limited number of pads you could
9:46possibly put around the edge. Um but you
9:49can have because it's the world of the
9:52small very small things you can have
9:53massively parallel buses internally and
9:55you really want the speed. Um but you
9:58have to pay the penalty to go uh when
10:00you're going off the device just because
10:01there's not enough pins.
10:04Uh, I can't think of any any time I've
10:06ever seen a serial bus on a piece of
10:09silicon.
10:12I've seen it from die to die, but not
10:14for a piece of silicon. Okay.
10:17Uh, yeah. And then this is just the
10:19counter example. This is just reminding
10:21you that these these bumps are like
10:23literally this like trying to get more
10:25in here. I can't get in this little die.
10:27I can't get like thousands of these. I
10:29can't get hundreds of these. I I'm
10:30really limited in the number of bumps.
10:32little they call these bumps. These are
10:34uh these little pads here. They're
10:35called bumps. Uh there's a number of
10:37them that you can get off and they do
10:39have chips where you they basically
10:40cover as much of the surface area as you
10:42can with um pads or bumps, but uh
10:46there's still limitations and it's costs
10:48a lot. Okay.
10:52All right. Well, we're going to move on
10:53to um UART somewhere in here. There we
10:58go.
11:02Okay. So, we're going to talk about uh
11:05three communication buses in general.
11:08All these lectures go together that it's
11:09broken up over multiple slide decks. Um
11:13if you want, so today we're going to
11:15talk about UR if you want to learn more
11:16like really the data sheet at this point
11:19uh is a great source to learn about it.
11:22You should be more or less at the point
11:24where you can figure out how the
11:25peripheral works by reading the data
11:26sheet. It doesn't give you lots of
11:27background. It kind of assumes you've
11:29taken the course but you could probably
11:31figure out how it works. Um there is
11:33this textbook uh again is for a
11:35different microcontroller but the
11:37exposition the discussion of how serial
11:39ports works is uh still relevant and so
11:42you can get more information there but
11:44the web also has lots and UART in
11:46particular is an old protocol. Um all
11:48the ones we talk about are well
11:50documented on the web.
11:52Okay so universal asynchronous receiver
11:56transmitter. Um so this is a as it
11:58suggests a type of trans uh protocol
12:02that is asynchronous meaning there's no
12:03clock. Um it's a particularly old
12:06standard. It used to be that computers
12:09before there was Ethernet would talk to
12:11each other over a version of this
12:13protocol. And you may find uh in a
12:16research lab or something some devices
12:18with protocols like RS232 and RS2 or 422
12:23um those still uh are underneath are
12:26just UART protocols. So it is a
12:30wellestablished
12:31uh signaling method. Um,
12:37it's relatively configurable in a sense
12:39that the protocol really just defines
12:42what the signaling is and like what the
12:44waveform looks like, but it leaves lots
12:46of flexibility for how big packets
12:48should be, what how they're encoded,
12:50what speeds are there, so it's not
12:52overly constrained. And so, you know, a
12:55little history lesson I was saying like
12:57this is the back of your maybe your
12:59grandparents first computer looked like
13:01this. I don't know. Um but they used to
13:03have all these connectors here. DB uh 9
13:06was the standard for just normal serial
13:08ports and RS232
13:10uh was there. So my question to you uh
13:13is why are we still using UART today?
13:15Like this came out in 1971 I think UART
13:19was a pro established as a protocol. Why
13:21are we still teaching it now? What could
13:24be the market forces or the reasons why
13:28it was in computers and now we're
13:29talking about a microcontroller? Take
13:31take 60 seconds. Think about it.
13:47[snorts]
14:22All right. Why do you think not even I
14:25am this old? So why are we still
14:27teaching this in 2026?
14:35>> Yeah.
14:38>> I'm sorry.
14:40>> Yeah, maybe. But none of these computers
14:44probably run anymore. So it's not like
14:45I'm trying to talk to them. Although
14:47that's not a bad reason. I bet that's a
14:48good reason why it existed. So in 2000
14:52or so, PCs started going switching to
14:54USB, but that we still had uh UART type
14:57ports then. So, but now we're 26 years
15:01later. What are some other reasons?
15:03Yeah,
15:05I'm sorry. It's simple. Oo, I like that
15:08one. It's simple. Right. So this was
15:10state-of-the-art for 1971 when you had
15:13the and even these computers are like
15:15that's 80s and that's 2000s I think. But
15:18so UART was a way for computers to talk
15:20to each other and then they had
15:21complicated switching protocols so you
15:23could have multiple computers talk to
15:24each other but it was still basically
15:26like take one wire to another your
15:29buddy's computer and hook them up.
15:30That's the kind of modality. Uh and then
15:33computers got much much faster but
15:34microcontrollers haven't done the same
15:36thing. Microcontrollers more or less
15:37stayed at the same performance level.
15:39they just got cheaper and cheaper and
15:41smaller and smaller. And so now the
15:44legacy part comes through because we
15:45have this existing protocol. It's not
15:48really good for
15:50modern say year 2000 computers to talk
15:52to each other, but it's still relevant
15:55and there's lots of hardware that
15:56supports it in terms of chipsets and
15:58other things for microcontrollers talk
15:59to each other. So that's kind of like
16:01how the embedded system industry
16:03inherited UART uh just because it was
16:05well known engineers understood it and
16:08it's dead simple
16:11uh at least in the in the realm of what
16:13a embedded system could be. Um so you
16:16might find even in the lab if you're
16:17trying to build uh your projects you
16:19might find these things they're just
16:20called DB9 connectors. You don't have to
16:21remember what they are but the the big
16:24takeaway here is that there's these two
16:25lines here. Receive data, transmit data.
16:28the extra data lines aren't really
16:30necessary, aren't used anymore, but they
16:32were the handshaking protocols, uh the
16:35the acknowledge bits, you see clear
16:37send, ready send, all those extra
16:39handshaking methods used to be required,
16:42but now we have relatively fast
16:43electronics. We don't really need them
16:45anymore, especially for how embedded
16:46systems uses them.
16:49Um, also, uh, we'll see in a minute that
16:53RS232, R, RS422, and 485, those were
16:58almost exactly the same protocols in a
17:00sense of
17:02uh, the signals that were sent out. It's
17:04just that they had different power,
17:07voltage levels, right? They were trying
17:08to accomplish different tasks. So if
17:11you're only going to go from 0 to 5
17:12volts, you can't really go that far
17:14until noise or degradation or just the
17:17inductance and capacitance starts
17:18messing up your bits. And so they
17:21started increasing the voltage and
17:22differential means that there's one line
17:24that goes positive, one line that goes
17:25negative. Uh RS232 is and you are
17:28generally single-ended. But now they're
17:30just these are different different
17:31versions and all they really indicate is
17:33that the signaling is different but the
17:35underlying mechanism is the same.
17:38And so here's an example of what a UART
17:40packet would look like. We'll go through
17:41it in a little bit more detail later,
17:43but here's 5 volts, 0 to 5 volts. The
17:46voltage doesn't actually matter, but
17:47this is what standard UART was. And then
17:50RS232 would kick it up to plus or minus
17:5312 volts. And so, uh, you might notice
17:55that one is in inverted of the other
17:57one. And so, when I was undergrad, I was
17:59asked to hook up to some ancient
18:01machine. I had my little USB
18:03microcontroller, uh, and had a little
18:05USB converter. And then I would go and
18:07talk to um uh this old RS232 device and
18:12I couldn't figure out why it couldn't
18:14understand me at all. And what I didn't
18:16realize is that the part of protocol
18:18just inverts the signal and all they do
18:20is they have this big in buffer this big
18:22inverter and it just sends it through.
18:23The inverter goes from -12 to positive
18:2512 and just inverts the signal. So
18:28that's the that's the history lesson of
18:29where this protocol came from. So today
18:32we primarily use it just for two devices
18:35talking to each other. Uh you have a
18:38transmit. So this is when one device is
18:40sending data to the other one and then
18:42you have a receive. Now the problem is
18:44there's no idea of a master. There's no
18:46one individual in charge. And so it's
18:49the TX goes to the RX of the other
18:52device and the RX listens to the TX of
18:55the other device. It's not that the TX
18:57of device one goes to TX of device two.
19:00Right? that would only make sense if it
19:02was um there was a master and there was
19:04a peripheral. So I made this mistake
19:07when I made one of my first boards. I
19:09didn't really understand the protocol
19:10and I just said, "Oh well, this is my
19:12microcontroller and that's the
19:13peripheral device and so TX here goes to
19:16TX there, right? That's what the
19:17signal's name is." And uh well, what I
19:20learned after that is that I would
19:22always put extra zero ohm resistors and
19:25a configuration there that if I ever
19:26need to, I could solder them and switch
19:28those signals around. just something
19:30that you will uh maybe painfully learn
19:32one day. Um the other trick here is with
19:36all the protocols we talk about the
19:37number of signals that they have. Uh
19:39typically we say this one has two but
19:41there's always implicitly ground. And
19:44why does anybody know why you would have
19:46to have a ground?
19:49Yeah.
19:52>> Nope. Uh ground plane maybe. But yeah.
19:59Yes, they have to have we have to have
20:00the same sense of uh voltage, right? So,
20:03if this one is like a 100 volts higher
20:05than this one, uh bad things can happen.
20:07One other kind of reason
20:11the inverse of voltages
20:16guys took 215
20:19current, right? Current has to go in a
20:21loop. So if I just if I have no return
20:25loop here and I just raise the voltage
20:27over here, no no current's going to fly
20:29over to the other thing, right? And so
20:31if there's uh you have to have some
20:33return path here uh for your signal. So
20:37um just whenever we're looking at
20:39communication protocols uh you always
20:42have to remember that include ground and
20:44every year we see it not your fault.
20:45You're learning about embedded systems.
20:48person says, "I can't get this serial
20:49bus to work." And we look at their
20:51hardware and there's no ground. And you
20:53know, maybe it'll work intermittently at
20:55certain points, but there's no guarantee
20:56it's going to work. You actually have to
20:58have that ground pin,
21:01but there's no clock, right? So, um,
21:04this thing is just going to send out
21:06signals. They're going to look like
21:09like literally it's going to look like
21:11this top thing as a function of time.
21:13You're going to get highs and lows.
21:15So, how is it possible that this device
21:19is going to be able to figure out when
21:21to sample the data? So, I take 60
21:24seconds, brainstorm, figure out some
21:26ways in which if you're the device 2 and
21:28you're receiving data, how do you know
21:30when to clock?
21:44>> [snorts]
21:51>> Happy birthday.
22:24What do you think? How do how can we
22:26figure out how to clock the signal in?
22:31Maybe somebody over here. I missed this
22:33side of the room. Need brave people.
22:38>> Yes, he's bravest person.
22:43>> They do. Absolutely. Uh but how do you
22:46know when? Just knowing that the data is
22:48coming in at a certain time, a certain
22:50rate doesn't tell me when I'm supposed
22:52to like clock it in.
22:55>> Yeah.
23:07Okay. Yeah. But but okay. Yeah.
23:16>> What's that?
23:18>> Sure. Okay. Let's let me I'm gonna jump
23:20a little bit ahead in slides. So I kind
23:22of look at like this. Like I'm here
23:27and I gotta figure out I can use there
23:30could be a start and stop bit something
23:31that says this is the start of the frame
23:33and this is the the stop of the frame.
23:34But how do I know where to put those
23:37clock edges on there, right? So if I
23:39kind of go ahead Oh, did that work? No,
23:41they didn't work. At one point I had
23:42this thing would slide back and forth.
23:44But like imagine those little clock
23:45edges are sliding back and forth. Like
23:47how do I know when the middle of D3 is?
23:54If you had to create a circuit to do it,
23:56what would you think? Or a method
24:01and assume that you can know the clock
24:02rate.
24:06No idea. So I look at this uh kind of
24:10like analogy is like you're pushing a
24:11kid. I don't know why you would do this.
24:14When I I had I had my daughter when I
24:16made this slide, I never pushed her with
24:17a blindfold on. But if you did, you
24:19imagine that you have to know when the
24:21child is there. so that you push them at
24:22the right cadence. Otherwise, you're
24:24just going to push your hand forward.
24:25You're going to miss the child, maybe
24:26get hit in the face. I don't know. Okay.
24:29So, how so how do you know when? Well,
24:31the trick is you have to effectively
24:33measure the start bit and you know how
24:37long it's supposed to be and then you
24:38have to have some hardware inside that's
24:40going to over sample the clocks
24:44here. So, you have a clock that's going
24:46faster. You see a clock edge coming down
24:48and then you count. You say this should
24:51be the middle of my start bit. And then
24:53you say, "Aha, that was eight clock
24:55cycles. I know the baud rate. I'm eight
24:57times over sampling. I'm going to go
24:58eight clocks forward. And then I know 16
25:00clocks from now will be the midpoint."
25:03Right? So you have to over sample this.
25:04You have to a know the baud rate. And
25:06then you have to guess essentially, but
25:08you have to count off some. You have to
25:10be have a clock that's faster than your
25:12data rate coming in to figure that out.
25:16>> Yeah.
25:19Nope. It's an asynchronous protocol.
25:24>> This is uh this is internal to your
25:26device. So I am a receiver and I have a
25:30clock that's running 16 times faster
25:32than you are.
25:34And so I am trying to figure out okay I
25:36saw a falling edge after a long period
25:38of time. So say that start bit was high
25:41for a long period of time and then the
25:42transition comes down and I say okay
25:45that's the signal that we're going to
25:46start a packet and now I'm going to
25:48count forward
25:50basically uh eight and then 16 and say
25:52that's when I'm supposed to sample.
25:56>> Yeah.
26:01So how do you know that the speed is 16?
26:04>> Ah so um the guy up there said you know
26:07the clock speed you know the data speed.
26:10So APR you have to agree that data is
26:12going to come in at a certain rate but
26:15you don't but that just because you know
26:16the rate doesn't know you doesn't mean
26:18you know when. So this is all about
26:20trying to figure out the when when do I
26:23clock in data at D0
26:26right? Because if I'm doing the counter
26:28example is here when I'm pushing the kid
26:31on the swing, when do I push? If I have
26:34my eyes closed, I don't know when. I can
26:36hear the swinging go back and forth. So
26:37maybe I know the rate, but I don't know
26:39when.
26:42And so the way to do that is on device
26:44you over sample. you sample essentially
26:46faster or you have a clock here that is
26:50sampling is not the right term but you
26:51have a clock that's running uh in this
26:53case uh 16 times faster so that you can
26:57uh count and guess where that edge is
26:59going to be. What do you think the
27:00downside of this is? What's going to
27:02happen after a long period of time?
27:08>> Yeah.
27:11>> Yeah. because there's no guarantee,
27:14remember? Um, so you have an internal
27:16clock. It's pretty good. It's not
27:17perfect. It's pretty good. And they have
27:18an internal clock. It's pretty good.
27:20It's not perfect. And you've both agreed
27:21on a rate. But over time, there's going
27:24to be some drift between those clocks.
27:25They're not perfectly synchronized. So
27:28you're only saying here every 16 times
27:30I'm going to go and clock in the data
27:32whatever it is. But over eventually
27:34they're going to become out of sync. And
27:35this is a question of how long, right?
27:37Is it, you know, a few bits? Is it a
27:40week? Right? And typically this protocol
27:43is more in the let's be conservative.
27:44Let's assume it's like 10 bits before we
27:48have to send a new start bit to
27:50synchronize
27:55questions.
27:58Okay. All right. So I got a little out
28:01of order.
28:03Um so where that is done on device is so
28:07this is an example of the uh UART
28:10module. So they have I forgot what it's
28:11called universal serial interface
28:15channel. I think that's what it stands
28:17for. Um as we'll see later that this
28:20thing can be reconfigured for multiple
28:22different tasks. Uh so it can be UART or
28:26I squared C or SPI. These are other
28:27protocols you'll learn about. But inside
28:30here they have uh the baud rate
28:31generator and I for what the PPC stands
28:34for something in particular. I don't
28:35know my notes aren't here. It's the
28:37programmable
28:39I don't know the programmable
28:42pre-processor. So basically what it does
28:45is it it's the thing that is counting
28:49beforehand. And so the baud generator
28:50says I got my basically a register that
28:52tells me what the baud rate is and then
28:54it says okay this is the rate at which
28:56data should be coming in and the um
28:59programmable prep-processor is doing the
29:0116 times or n times over sampling. I
29:04don't know on this particular processor
29:06many of them you can say it's eight or
29:0716 or even 32 depending on you know how
29:10you want to configure it but it does
29:12require a trade-off right now your
29:13internal clock as you're receiving this
29:15thing has to be faster than the baud
29:17rate back in the day when they're back
29:19in 1971 when they were building this
29:21that was probably much more higher
29:22burden here we're at you know 100 mega s
29:25or megga hertz on uh for your chip
29:28clocks and you're probably only at best
29:30megahertz uh even hundreds a kilohertz
29:34uh for a symbol rate on UR. So the
29:37oversampling is not that big a deal
29:38anymore.
29:41What questions you have?
29:45I see questions. I see your faces.
29:47You're like, I don't understand anything
29:48this guy's saying.
29:54Why don't you talk to each other and
29:56explain to each other how this
29:57oversampling thing works?
30:18The clock's internal. That clock is
30:20internal to the device. It's not shared
30:21between devices.
30:28All
30:52right. So, just just for clarity,
30:55there's no shared clock between these
30:56devices.
30:58So if device one is sending packets over
31:00here, device two is waiting for that
31:02edge to come down and then it has an
31:04internal clock that is n times faster,
31:0716, 32 or 8 times faster and then it's
31:09figuring out where it should be
31:12sampling. Yeah.
31:18>> Correct.
31:20>> Unit of time. We'll call it baud. This
31:22is called a baud rate.
31:24>> Okay.
31:28that
31:29>> uh
31:32it could be uh the the architects of
31:35these protocols said like let's talk
31:37about not internal clock rates because
31:39those clock rates could be different
31:41right this system could be running at
31:43meghahz the other one could be kilohz
31:45you could have different oversampling or
31:48faster sampling clocks and so they just
31:50talked about the signal itself has a
31:52certain rate to it baud rate
31:54>> so the hardware do
31:59Yeah.
32:02>> Yeah. Yeah. Yeah.
32:09[snorts]
32:16>> Uh yeah, I did jump around a little bit.
32:18So baud rate is established a priority.
32:21Two programmers agree beforehand that
32:23this is the baud rate. And how you would
32:25normally do it is you will look at the
32:27data sheet and the data sheet will tell
32:28you what the baud rate of this device is
32:30or it'll tell you it supports these uh
32:33baud rates. You might work in a serial
32:36terminal program on your computer. And
32:38you'll see that there's lots of
32:39different baud rates to choose from. And
32:42so then you would have to choose the one
32:43that you've programmed into your
32:44microcontroller. And sometimes the
32:46computers are fancy now and it will just
32:48detect it'll automatically detect the
32:50baud rate coming off your
32:51microcontroller.
32:56Yeah.
32:57>> So to that point like if you wanted to
32:59establish a log across machines like
33:02default log and then you pack it over
33:05with a new rate is upgrade that rate.
33:07>> Uh don't do that.
33:09>> You could I mean I don't know why you
33:11want to. Um typically like the default
33:14baud rate is like 960 0 for whatever
33:17reason. I know it's like really slow and
33:18everybody agrees on it. Uh we'll get to
33:20the start bit in just a second. Um I
33:21forgot. I know. I forgot. Um,
33:24but uh I don't think there's any reason
33:27why you're dynamically changing the baud
33:29rate because typically the hardware the
33:32physical layer is not changing and
33:34that's one thing that would change it,
33:36right? You make your wires really long
33:39and now they can't support the higher
33:41frequencies. Okay. Well, now you'd have
33:43to shorten it. But that's usually not
33:44happening. These are not hot swap
33:46plug-and-play USB style protocols.
33:49Uh, yeah. All right. Any other questions
33:52before I get to start bit?
33:54These are good questions. Okay, start
33:57bit. Uh, so here is the general
34:00protocol. There are variations to it. So
34:04in almost all cases, unless otherwise
34:06specified, the bus is typically held
34:09high. Okay, so here we're you see that
34:12the line comes in from the sender is
34:14high. uh just assume it's been high for
34:17quite a long time, much longer than a uh
34:20bit width. And now the device is looking
34:23for the start and the start is I was in
34:26a a state where the bus was idle. So
34:28you're you're but in bus idle state. It
34:30transitions down and that's the
34:32indication of a start bit that falling
34:34edge. Then it does its uh calculation to
34:38figure out well based on the baud rate,
34:40how fast my clock is going, then I can
34:42go and figure out where to sample. at B
34:450, at B1, at B2.
34:56>> I think the I think the protocol says
34:57it's like two and a half symbol widths
35:01and a symbol is this distance here,
35:05right? So you there is a you cannot jam
35:08these things too close to each other or
35:10else you're not you don't ever get into
35:12the idle state of the state diagram.
35:19B34
35:21and B5 are all
35:23>> Oh, yeah. Uh oh. Ah. Okay. So, now he's
35:27getting he's getting good here. So, we
35:30have to have a start bit and you also
35:32have to agree on how many bits are in
35:34the in the packet beforehand.
35:36So, typically it's going to be eight
35:38bits, but there's no reason why it can't
35:39be five, six, seven. I've seen nine bits
35:42as well. eight bits just happens to be a
35:44happy number. All the engineers choose
35:46it. Um there's also an optional par bit
35:49uh is doesn't have to be there. So the
35:51par bit is there and that's just telling
35:53you uh it's a summation of the uh the
35:57ones I believe was if that's right. Um
36:00and it says if this bit is high that you
36:02can check then you can count up all the
36:04ones and if the bit is high and that and
36:06it's an odd number then it matches. If
36:07it's a odd number then it's um uh zero.
36:10So now you have a way a data redundancy
36:13way to figure out what was uh if that
36:16packet is valid. Uh and then there's a
36:19stop bit and sometimes they enforce two
36:21spot stop bits because they want to make
36:22sure there's more timeout time for the
36:24hardware to recover. Usually it's
36:26because the hardware has to do tasks
36:28like take that eight bits that's now in
36:31uh your silicon and then like shift it
36:32out to somewhere else. So if they did it
36:34too fast so the extra stop bit helps
36:37with that. Uh yeah questions.
36:52Uh, so you said why is it always
36:54essentially what I've got is why is it
36:55always hacked active high? Why not
36:56something else?
36:58No, no, that's what they did. That's
37:00what they did. So I could imagine a
37:02reason. The reason is I have my uh
37:05device plugged in and I want to know am
37:07I connected to anything?
37:09And if it's active low, you assume
37:11you're connected. You don't know. But if
37:12it's active high, at least you know that
37:14you're connected.
37:15>> Does that answer your question?
37:16>> Yeah.
37:17>> Okay. Yeah.
37:22Y
37:27>> you could be insane and you could do it
37:29for communication. That's fine. Um but
37:31it's going to be too hard. So you would
37:33just do it because we're going to assume
37:36that the hardware doesn't change during
37:38this transaction. Uh you plugged it in
37:40and now you've user said go or start or
37:42something. Um that the uh number of
37:45symbols and the rate doesn't change and
37:47you know you you're not adding a parody
37:49bit. You're not adding an extra stop
37:51bit.
37:54>> Yeah, you have to configure it. Yep.
37:59Other questions?
38:05Um,
38:06yeah. And this just showing off that
38:08there's certainly are other types of
38:10data frames. And typically you see this
38:12nomenclature here. It's like, do I have
38:14it here? I'm sure it's somewhere. Um
38:19that's it's like it'll be like uh 9
38:23um n or 8 n1 and the 8 n1 this is uh
38:28eight is a number of bits n would be no
38:31uh par bit and then one is the number of
38:33stop bits. So you'll see these kind of
38:34like these three symbols that indicate
38:37uh what frame it's at or like what's
38:39what's the frame type what how how is
38:42data encoded. The other thing that's not
38:44known is whether it's LSB or MSB. You
38:47have to kind of you have to agree abi
38:50what it is. And so you might think like
38:52that's a lot of stuff to configure, but
38:54it also gives you lots of flexibility.
38:56You can change the speed. You can change
38:57the number of bits. You can change all
38:59those things. Yeah.
39:02>> What do they look like?
39:05>> They're just extra time that stopped.
39:12Yeah, it's just telling you there's a
39:14timeout between
39:16uh signals. So, let's see. Is there
39:19here's an example of like what two spot
39:22I think what they're trying to say here
39:23is here's what two stop bits would look
39:24like before the next stop stop bit. So,
39:26I was wrong. It's not two and a half.
39:27It's up to two. It's not two and a half.
39:32I thought that there was a more of a a
39:33mandatory timeout in this protocol. Does
39:36that answer your question?
39:38Yeah. Okay.
39:41And then let's see maybe did I I may
39:44have said the polarity wrong or the par
39:46bit wrong. So if the total is even then
39:49the parity bit is one. Oh I think I did
39:51say it wrong. And then the if the total
39:53number of bit you take the bits you
39:54figure out if it's odd. You sum them. If
39:56it's odd or even then um if it's odd par
39:59then you get a one. And so now you can
40:00imagine if you get one bit flip. If one
40:02bit flips then your par is changed. your
40:04summation of all the ones changes and
40:07now you can check to see if that packet
40:09is valid or not. And that's just a nice
40:12way you could you get an invalid packet
40:13you can ask the transmitter for another
40:16version of that packet. So a little bit
40:18of uh redundancy built in there.
40:20Oftentimes I think you asked what
40:22happens with the you get bad data
40:24happens all the time. It's going to
40:25happen in Tun Lab. It's going to be
40:26great. You just get garbage, right? uh
40:29oftentimes uh you I don't know if you
40:32ever looked at an ASKY character table
40:34there are so many ASKI characters that
40:36if you misinterpret a a packet it kind
40:39of lands to some asy character and so
40:42now you get gibberish out and so that is
40:45a common error or there's just no uh you
40:48just get an error there's no actual data
40:49in there so that is just a known failure
40:53case of this parody bit comes in there
40:55to help with that to see if it's
40:57unlikely that you got gibberish in and
40:59the parody was right. Um, yeah.
41:05Yeah.
41:08>> Yep. You have to a par decide if there's
41:09a parody bit.
41:20>> No, it's dependent on the data. So if
41:22the data is uh if if you sum them all up
41:25and it's uh even then the parity is one.
41:28Oh the par even sorry.
41:33Okay. Is there an example? No.
41:37Okay. Uh so then we had this idea of
41:41baud rate.
41:42So uh sorry the data rate and baud rate
41:45are two different things. And why they
41:47chose this is a little unclear. So here
41:50we have uh this is the rate at which uh
41:53packet or symbols come through not the
41:56rate at which data comes through. And so
41:58you're saying well isn't that the same
41:59thing? Why is a symbol and a symbol here
42:01means like just this this is just a
42:04trans like this indicates one bit right
42:07this is also a symbol these are all
42:09symbols and certainly in wireless
42:10communication you often times many
42:12transitions could equal a symbol. Um but
42:15here we're just saying that okay uh uh
42:18you have a certain number of symbols go
42:20through but how is that different than
42:21data rate? Well remember by the
42:23definition here
42:25not all of these bits are data bits
42:28right so here we have a start bit a par
42:31bit and a stop bit. Well those three
42:32bits aren't data even though the par you
42:35know technically has some idea about
42:37data it's not those are overhead to your
42:39protocol. So here your baud rate is just
42:43about your data rate how many how much
42:45data gets through per second not your uh
42:47or your symbol rate which is uh just
42:50sorry baud rate is about symbol rate not
42:53about your data rate
42:57what's going on
43:00and so here's just an example of an a
43:02fictitious uh thing that could increase
43:05your baud rate here right because here
43:08uh each symbol has more encodes more
43:11data than just the single symbol. So
43:13here you can encode two bits with this
43:15particular encoding scheme. Now this is
43:16fictitious. This is not how um UART
43:19works, but it's just showing that like
43:21the number of bits per symbol does not
43:25uh the same as the symbol itself. There
43:27are ways to trick the system and get
43:29more information through per symbol.
43:36No questions. Okay. Um
43:41yeah, I think I just said this, but here
43:43this is the most common um baud rate. So
43:46each frame has in this particular case
43:48say like one start bit, eight uh data
43:51bits, one stop bit, no parody bits. And
43:53so you might say, okay, well u I'm going
43:56to go through and um
43:59uh calculate what the baud rate is.
44:01That's not actually it. Instead, you
44:02have to consider about the overhead of
44:04the protocol.
44:06Okay, now we had jumped ahead because I
44:08put these out of order. The asynchronous
44:10versus the synchronous.
44:12All right, let's go through a particular
44:14this is like a standard oscilloscope
44:16transaction. Here you're seeing is
44:17between 0 to three to three volts
44:19because that's typically how you're
44:20going to see for most microcontrollers.
44:23Um here we have a start bit, stop bit uh
44:26start bit and then we have data bits. In
44:28this particular case, you have to know
44:30beforehand that it's LSB first. Uh, and
44:33then you have um a stop uh one start
44:36bit, one stop bit. This is what it's
44:38telling you. Eight data bits, no par,
44:40and that's the baud rate. And then you
44:41can go through and you're just going,
44:43you have to figure out where to clock in
44:45your data. So it could be all zeros uh
44:48and then you just have to really trust
44:50that like you, you know, did the math
44:52correctly or it could just be one high
44:53thing and you got to make sure that you
44:54figured out where it is. Uh and then of
44:57course you can send one packet after
44:58each other. I think that this is very a
45:00very optimistic uh data transfer cycle
45:03in the sense that your hardware had to
45:05be ready to send both of that those
45:07packets which means typically you have a
45:10buffer full of data and then you're
45:12asking your peripheral to clock out that
45:14data. Um but if you're say you're taking
45:17data all the way from the core and say
45:18now send this over UART then you go
45:20another thing all the way from the core
45:21you have to pay the penalty to go
45:23through the advanced peripheral bus and
45:24send it all out which has a latency
45:26associated with it. So this would be a
45:28scenario where you have a buffer in your
45:30peripheral and you're telling it to
45:31clock out this data.
45:38What questions do you have?
45:46>> Yeah. So I didn't I should just show you
45:49the nomenclature, but it's essenti like
45:50here I'm telling you what how many bits
45:52it is, but typically it's something like
45:53this. Um
45:57like for this it would be like
46:01one eight.
46:04Oh no, you don't usually don't do the
46:05one because it's always one start bit.
46:07It would be like eight
46:09uh n for no par and then one. So that's
46:13like the nomenclature for this
46:14particular thing. So there's always one
46:16start bit is optional one or two stop
46:19bits and it's telling you the number of
46:21data bits and the number of par bits. So
46:23it would be eight for uh data bits, n
46:27for no par or a p and then you would
46:30have a one or two for stop bits. So you
46:32have to know that information beforehand
46:34has to be given to you. That's the
46:36information. And then you also have to
46:37know the bud rate.
46:44You want to decode one of these things
46:46for yourself. Super exciting.
46:51And can you pass them like that way
46:53behind you too?
46:59You can pass them up that way.
47:04There you go. Thank you.
47:11You're going to fasten this way and that
47:13way.
47:16Go.
47:22My bad.
47:34>> Did I tell you if it's most significant
47:36bit? I don't think I did. Yeah.
48:27>> [clears throat]
48:30>> That's
48:40Amen.
48:52This is
49:08crazy.
49:22I think I forgot to say there was lsb.
49:24It doesn't really matter but and you
49:27would have to use an asky table to
49:29figure out what uh asky character it is.
49:31We would provide that to you if we
49:32carried on the exam. But here you can
49:34assume it's LSB.
49:54start.
50:22Okay.
50:51You got a Let's go.
51:18Hey,
51:37I know.
51:54Yeah. Yeah. Yeah.
52:30I'm sure
52:37Number
53:02[clears throat]
53:33Smells like water.
53:35>> Wow.
53:42>> [clears throat]
54:04>> My god. Thank you.
54:27>> No, we will not.
54:35section.
54:58[groaning]
55:01We had more
55:04Yeah.
55:22[cough]
55:31Right.
55:34kind of warm up. Yeah.
55:41[clears throat]
55:53I love you.
56:05[clears throat]
56:26Yummy.
56:38Let's
57:26Yeah, I think so.
57:37What you get for your
57:56All
58:04right. What do we get for
58:06>> uh uh your what what asking character is
58:10this?
58:13>> Does anybody get anything other than G?
58:17>> Good. I'm glad to see I always check my
58:18work by asking me first. If I get enough
58:20people that agree with my answers, then
58:22I'm like, "Okay, go forward." But how do
58:24we figure that out? So here the trick is
58:27uh try and do this. So here the uh this
58:30is giving you all the information and
58:31then we just wrote it out for you just
58:33to to help uh figure it out. So we're
58:37always going to assume that we're in the
58:39uh idle state high. So we've been high
58:42for a while
58:44and then the transition from high to low
58:47indicates the beginning of a start bit.
58:49So like right here would be that start
58:50bit. And so we're going to call this
58:52test. Okay. [sighs]
58:54Now, it is technically a zero, but it's
58:56better to call it x. It's not actually
58:57data. And now, the trick would be, well,
59:00what happens if it was actually like
59:02this, right? The first bit, we made it
59:04easy for you because the first bit is a
59:06one, but the first bit is zero. Well,
59:08then you better be pretty confident that
59:09you know what the bar rate is. Then
59:11you'd have to go through and do the math
59:13to figure out, wait, is this really a
59:16one or a zero? Or is this a long zero or
59:19is this a one? Right? Kind of you'd have
59:22to know. The only thing that tells you
59:23that is the B rate. [snorts] That make
59:25sense?
59:29No. Yes. Okay.
59:33And so then we're going to get one one
59:37zero
59:41one
59:43and then zero. And then we're back here
59:45to uh stop bit
59:49I guess. Uh put this T here for now. So
59:52here we have start bit, stop bit. It's
59:53good to label them as those things and
59:56then you can go put this in an ASP
59:58table. Uh we said it was the lowest uh
1:00:01significant bit first which is I don't
1:00:03know if that's the default. That's just
1:00:05a common state for u uh that it's LS.
1:00:10So if you're going to label this on an
1:00:12exam or homework like label out that
1:00:14they start and stop. It's it's better
1:00:16not or parody bits if they're there.
1:00:17It's better not to label them as ones
1:00:19and zeros. Does anybody have a question
1:00:21about how we got here?
1:00:29All right. So then we got G. And how do
1:00:31you get you? Well, you go look up on an
1:00:32ASI table. Did I give you ask table? No.
1:00:35In exam, we would give you an ASI table.
1:00:37Uh but you can look online or not. But
1:00:39it's really the ones and zeros. And asie
1:00:41is used so often you might as well as
1:00:44system engineers be aware of it. All
1:00:46right. So how do you go about figuring
1:00:48out the bud rate?
1:00:59It's like this period.
1:01:02>> Yeah.
1:01:06>> Just like the the duration basically.
1:01:09>> So you could just go take that number
1:01:11and divide by one.
1:01:14>> But and so the one problem is your your
1:01:16graph might not be perfect, right? There
1:01:18might be some errors. So it's just the
1:01:21number of bits is by the number of
1:01:23period of time. So you can go all the
1:01:24way [clears throat] up to 9 uh 37.5.
1:01:28But then you have to count all those
1:01:29bits, right? So the bottom rate number
1:01:31changes. It's just the time interval
1:01:33divided by the number of bits. And so
1:01:35what is that people get?
1:01:41>> 9600.
1:01:42>> 9600. That's what I got. I saw at least
1:01:45three people got 9600. So, I'm locking
1:01:47that answer in. Any questions on how to
1:01:50decode this.
1:01:56Now, one thing to to think about is that
1:01:59um this we kind of show this as one
1:02:02single transaction on one line, but
1:02:04there could be two different there are
1:02:06two lines, a transmit and receive line,
1:02:08and they're separate lines so that each
1:02:10device doesn't they don't collide. And
1:02:12they don't have to be synchronized at
1:02:14all to send data. Like it's not that one
1:02:16sends data and then they wait and the
1:02:18other one does. Happens to be that's
1:02:20often the case where they could just be
1:02:21sending data at the same time. You could
1:02:23have half the packet like coming in from
1:02:25the other transmission other line under
1:02:28here. There's no guarantee that one is
1:02:30talking while the other one's not
1:02:31talking. Um they don't have to because
1:02:34they have two separate physical lines.
1:02:37Okay,
1:02:39let's see. And uh I put those answers to
1:02:42be online. You can do those. Okay. uh
1:02:44what they are. It's not exactly 96 bits.
1:02:46It's approximately and that's because
1:02:48there is error in these. It just it's
1:02:51allowing there to be error in the
1:02:53protocol. Uh because the crystals aren't
1:02:56always the same. The clock division, the
1:02:58biggest source of error is that you have
1:02:59a really fast crystal, really precise,
1:03:01[clears throat] beautiful crystal, but
1:03:02then the baud rate is not an even number
1:03:05of that crystal. So then you you have an
1:03:07approximation and that's why protocol
1:03:10allows approximately 10% error
1:03:13accumulation because they know over 9 10
1:03:16uh symbols that you're not going to lose
1:03:18phase lock. You're not going to start um
1:03:22[snorts]
1:03:23counting a different bit than you should
1:03:24have.
1:03:27Uh oh, there's a missing slide here. But
1:03:30essentially inside here
1:03:37So this is an example of uh your um
1:03:43uh your uh microcontroller. Uh this is
1:03:46uh inside the the biggest trick of
1:03:48almost all the serial protocols is that
1:03:50it is a way to go from the world of
1:03:53serial to the world of parallel. Like
1:03:55that's what almost all these things are
1:03:57trying to accomplish internally. And
1:03:59it's just a chip register, right? So
1:04:01serial data comes in and you don't want
1:04:04your core going out here and sampling
1:04:06one bit at a time, right? That would
1:04:08just be inefficient. So the this device
1:04:11here is perfect shift shifting in pull
1:04:15it out as paradol data. And so this is
1:04:18the this is why we still use UR today.
1:04:21So the simplicity of this structure and
1:04:23its flexibility, the you know people
1:04:26developing microcontrollers said, "Oh,
1:04:28we're just going to borrow that because
1:04:29it's such a well utilized and useful
1:04:32structure from the uh ancient PC world."
1:04:35They reuse this uh to figure that out.
1:04:37And then you see the same thing here.
1:04:39The difference now is that um modern
1:04:41microcontrollers, they give you a FIFO
1:04:43buffer and you have interrupts and all
1:04:45these other signals. And the goal here
1:04:47really is that you will set your thing
1:04:49up and uh data will come in and it'll
1:04:51fill up the the 54 buffer and I forgot
1:04:53exactly what the size is for your
1:04:55particular device. But you can imagine
1:04:57data comes in you get an interrupt or
1:05:00something. You have to pull the data out
1:05:01fast enough so that the next data piece
1:05:03of data that you push in doesn't get
1:05:05overwritten. So you'll find when you do
1:05:07your labs uh that there's these
1:05:09concurrency problems where if you're not
1:05:10servicing interrupts fast enough or
1:05:12you're not uh setting up your buffers
1:05:15properly and your buffer size that your
1:05:17data can get overwritten and now you're
1:05:19saying well wait a second something's
1:05:20wrong right I'm sending packets but I
1:05:23sent five packets I only received four
1:05:25or even one that's really not the
1:05:28transmitter side it may be your side but
1:05:29you're not pulling the data out fast
1:05:31enough. So that's a common set of
1:05:33problems
1:05:36and that leads to this idea that often
1:05:39times you're you're going to set up an
1:05:41IRQ handler or interrupt that says you
1:05:43get a bite in or your buffer is full and
1:05:46then you send uh a signal to your core
1:05:50which [snorts] pulls the data out to
1:05:51make sure that it's not going to get
1:05:52bothered. Same thing for writing. You
1:05:54might have a large um multicar string
1:05:58that you have to send out. Um you could
1:06:00if there is a buffer you can fill with
1:06:02the buffer and say you know flush that
1:06:04buffer or you said when you have the
1:06:07buffer has been emptied you send up the
1:06:09IRQ that interrupts the core and then
1:06:11you just send out the next flight. So
1:06:13that's just a way to make maximum use
1:06:16utility out of your device to get
1:06:18maximum transfer without having to be
1:06:20pulling for any of those other things.
1:06:23Any questions?
1:06:29Okay. Um the modern instantiation of uh
1:06:33UART is there's a couple different
1:06:35places where you're going to see it all
1:06:36the time. Um and that is usually you're
1:06:39trying to get off of device. And so here
1:06:42you have my little microcontroller with
1:06:44a RX and TX and then a common chip that
1:06:47you find there. There are other brands.
1:06:48Uh but it's FTPDR chip. Uh I don't
1:06:51decide right in there. I just know it's
1:06:53called FPDR. I think that's the acronym
1:06:55for the company and they have a FTE 232
1:06:58whatever are and basically this chip
1:07:00holds the USB interface. It does the
1:07:02entire USB protocol which is painful and
1:07:06the amount of signaling and overhead and
1:07:08confirmation packets and you this in 373
1:07:11you don't want to deal with that
1:07:12overhead uh because it's unless there's
1:07:15a nice library or something you can
1:07:16instantiate but you certainly wouldn't
1:07:17want to do it yourself. You don't want
1:07:18to busy the floor with it. So here you
1:07:21would have your microcontroller and you
1:07:22already know this chip and then there's
1:07:24a USB cable that comes through to your
1:07:25computer and you would look at the data
1:07:27sheet of this chip and maybe there's
1:07:29some configuration packets. You say okay
1:07:31I want you to be USB 2. I want you to do
1:07:33XYZ and you have to know what the B rate
1:07:36is and the symbol rate and then this
1:07:37thing is just going to send over
1:07:40uh the you know the asky characters or
1:07:43whatever the message is to the computer
1:07:45and then this chip is going to handle
1:07:47the entire protocol for you. So that is
1:07:50essentially on your dev kits already.
1:07:52There is a chip that's effectively
1:07:54equivalent to the FDI chip that is doing
1:07:56this task. It's a bridge between UR uh
1:07:58and USB. Now your particular device does
1:08:01have an internal USB peripheral. You can
1:08:04use that if you want. Um there's just
1:08:06different trade-offs can be made.
1:08:10Uh yeah, it's just the same. This is
1:08:12just a standard schematic showing
1:08:14[clears throat]
1:08:15the actual USB connector. And you have
1:08:17to have a bunch of extra little
1:08:18circuitry around there to handle. USB is
1:08:21really noisy actually because it's like
1:08:23consumer grade and all horrible things.
1:08:25But aside from that, it this works out
1:08:27really well. And then the other way that
1:08:30almost every one of you will use this
1:08:32probably on your project is this a way
1:08:35to make a radio uh communication. So you
1:08:38do Bluetooth or maybe XP or Ziggp. These
1:08:41are different protocols. And instead of
1:08:43worrying about how does wireless work
1:08:45and how do I get wireless signals to go,
1:08:47you're just going to make this uh bridge
1:08:50in which you will send over uh some
1:08:53configuration data to the um the the
1:08:57bridge module, the XP module. It will
1:08:58basically say this is your channel, this
1:09:00is your ID and then you will it will do
1:09:03all the radio communication
1:09:04synchronization all those other things
1:09:06and then your computer or your other
1:09:08device will just pick up.
1:09:09[clears throat]
1:09:10Just think of how we use UR is really as
1:09:13a bridge to the external world through
1:09:15these other chips. That's the modern way
1:09:17that we're using now.
1:09:21Questions? Yeah.
1:09:22>> If you go back a couple slides to
1:09:25device, does that
1:09:28request data
1:09:30mismatch?
1:09:31>> I'm sorry. Is it do what? Does that chip
1:09:34angle like oh the period is wrong when
1:09:38you requesting the money that's a good
1:09:40question probably
1:09:43like so that would all be coming from
1:09:45here so your microcontroller hit the
1:09:47wrong thing right now this um I don't
1:09:50know how it's set up a data sheet
1:09:52typically
1:09:54you have to see I don't know uh let's
1:09:57see can we look there's some of them
1:09:58that have an error a bus error signal
1:10:01that you can choose [clears throat]
1:10:02I'd have to look through all the
1:10:03schematics but they actually provide
1:10:05like all these extra pins and some of
1:10:08those you can actually see are leftovers
1:10:10from the old protocol. So like this is
1:10:12clear channel this is like I forgot what
1:10:15these bits are but they implement these
1:10:17extra functionalities so that you can
1:10:18get that feedback
1:10:21um
1:10:23and then it it's doing all the error
1:10:24handling uh between you and USB. So if
1:10:27that has an error uh it will talk to the
1:10:30computer and figure that out.
1:10:35Okay.
1:10:37Uh and then uh just to kind of wrap up,
1:10:41this is a weirdly formatted slide, but
1:10:43uh on your particular device, you have a
1:10:45US uh serial interface channel. So
1:10:48there's a module called FA and it has um
1:10:51up to six uh channels. Now a channel is
1:10:54not a single wire. A channel just means
1:10:57essentially a protocol. though you have
1:10:59these configurable modules that can be
1:11:02UART or SPI or I squared C. Those are
1:11:06other protocols you'll learn about
1:11:07later. I2S is an audio protocol. Um I
1:11:10actually don't know what LIN is. Um but
1:11:13there are different types of protocols
1:11:15and because they're relatively simple
1:11:17now like 15 20 years ago you might get a
1:11:21device that can only do SDI or only do I
1:11:24or they might need different modules to
1:11:26dedicated different antennas. Now uh
1:11:29digital logic is relatively cheap. The
1:11:32IP to put that on a chip is readily
1:11:34available and now you have these six
1:11:36different modules essentially three
1:11:39modules each with two channels. But
1:11:40regardless that can do lots of different
1:11:43protocols. So now it's just a task for
1:11:45you to figure out okay I which protocols
1:11:48do I want to have on my embedded system?
1:11:51Which pins are available? And then you
1:11:52can reallocate uh these modules to do
1:11:55those different tasks. Um, so they're
1:11:58reconfigurable. They have uh, you know,
1:12:01uh, word buffers, so they do have hypos
1:12:03in them so that you don't have to
1:12:05constantly pull data out and it helps
1:12:08you miss less packets. It makes the
1:12:09assumption across 16 bits. And then each
1:12:11of the modules has IRQS. And so those
1:12:15IRQs can be data is available, data got
1:12:17sent, error, all those other uh, other
1:12:19things. And those are configurable as
1:12:21well.
1:12:23All right. Uh, pros and cons. So only
1:12:26two wires, no clock signal, so that's
1:12:28nice. And it has error correcting in it.
1:12:31Um, so those are all like pretty good
1:12:34features. Uh, the the challenge here is
1:12:36that the the data frame is going to be
1:12:37limited to like 9 uh bits at max unless
1:12:41you try and like really make some sort
1:12:42of custom thing, but typically your
1:12:45hardware is going to be at that level.
1:12:47And it doesn't really support multiple
1:12:50uh peripherals or multiple uh
1:12:52controllers at once, even though it once
1:12:53did. uh that's just not the
1:12:55functionality that we have now. So, it's
1:12:57usually one device to another device. Um
1:13:00[snorts] oops. It's not really a con
1:13:02anymore, but the hardware has to do the
1:13:05oversampling or the hardware has a clock
1:13:07that's 1632 or eight times faster. Back
1:13:11in the day, that was a problem. I
1:13:12suppose now it's not really a con. It's
1:13:14just something to think about. Uh and
1:13:16then last one, last two is that uh you
1:13:20have to agree on everything a priority.
1:13:22USB is nice. You don't have to agree on
1:13:23anything. The protocol itself negotiates
1:13:26speeds uh and that sort of stuff. But
1:13:28here you have to actually have read the
1:13:30data sheet or the device you're plugging
1:13:33in. You as programmers have to agree on
1:13:35the spec of how you're going to encode
1:13:38data least significant most significant
1:13:41bit fog rate all those sort of things.
1:13:43And then inherently you're going to be
1:13:45limited in how good that packet can be
1:13:48because you're dealing with the
1:13:49stability of the clock and more
1:13:51accurately the inaccuracies of your
1:13:53clock dividers to hit basically their
1:13:55body.
1:13:56Okay,
1:13:58any last questions? [clears throat]
1:14:08>> Nope, that [clears throat] is data bits.
1:14:10So there
1:14:13>> uh there you can go up to 9 bits. Almost
1:14:15everything is 8 bits. Everything you're
1:14:16going to see in the world is 8 bits. You
1:14:18could it's very uh your hardware is
1:14:20going to support up to 9.
1:14:25[clears throat]
1:14:38Yeah. What is it?
1:14:44You so why do you have parity bit? What
1:14:47would you do with it? So you're a
1:14:49receiver, you know, do not trust that.
1:14:52That's all you can do with that. Say
1:14:53this pack is then you can choose to get
1:14:56more data. Ask for it if that's
1:14:58available or you just throw away.
1:15:01>> All right. Thank you. See you on Friday.

About this transcript

This page contains the full transcript of EECS 373 - Fall 2026 - Lecture 11: "Serial Bus Over & UART" by Interactive Sensing and Computing Lab , generated from the public captions YouTube serves with the video. The transcript has 10,451 words across 1,538 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.