YT YouTube2Text

YouTube2Text → Transcripts → EECS 373 - Fall 2026 - Lecture 12: "Serial Buses: I2C and SPI"

EECS 373 - Fall 2026 - Lecture 12: "Serial Buses: I2C and SPI" — Transcript

by Interactive Sensing and Computing Lab · 12,546 words · 1,819 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:21All right.
0:24You guys hear me? Okay.
0:26>> Yeah. Good. Good. All right. Cool.
0:31All right. So, Professor Sample is out
0:33this week. So, I'm your substitute
0:35teacher. I was thinking maybe we just
0:37watch a movie if that's okay.
0:40All right. Uh, so we're going to be
0:42learning about spy today. Um,
0:45couple announcements. So, homework 5 is
0:48due tonight. Um, team registration, if
0:52you haven't done that already, I think a
0:54lot of you haven't done it. Um, just
0:56fill out that Google form with your
0:57teammates. uh do that by Wednesday. If
1:01you don't have a team already, please
1:03reach out to me or Professor Sample and
1:05we'll help you get on a team. Uh we
1:08don't want any stragglers. So maybe you
1:10can also come to me after the lecture
1:12and we can try and find everyone a team.
1:14Okay.
1:15Um after tonight, you have homework six
1:18and homework 7. Um and then after that,
1:21you're all done with homework and we'll
1:22go into the project phase and all your
1:24focus will be on that.
1:28So uh last week you talked about uh UART
1:32that was a serial interface. We are
1:35going to be talking about SPI. Today
1:37stands for serial peripheral interface.
1:40Um it's kind of the same idea where
1:43we're we're having some chips on a board
1:45talking to each other. Uh but they've
1:47implemented it slightly differently.
1:50So if you want to do some reading on how
1:52Spy works, you can go to the reference
1:55manual. For whatever reason, Infinine
1:57has decided to change the name of it.
2:00So, they call it synchronous serial
2:02channel in the manual. Um, they kind of
2:04do that with all of them. For some
2:05reason, they changed the name. Um, you
2:08can also go to that that ARM book that
2:10we always reference and you can look at
2:12chapter 22 to read up on this a little
2:14bit more.
2:17Okay, so here's kind of the overview of
2:19what SPY is. Um, it's a very common
2:23communication protocol. Um, a lot of you
2:26will probably interface with it during
2:28the project. Um, if you have a device
2:31that needs a lot of data, this is
2:34typically what you would see on that
2:35device. So, for instance, if I have an
2:38LCD and I have a lot of pixels on the
2:41LCD that are different colors, well, in
2:43order for me to refresh that display, I
2:46need to send it a lot of data. And spy
2:48happens to be a common protocol that
2:50those type of displays use. Um, it uses
2:54four wires. Um, it's used for chip to
2:57chip communication. So, with like USB,
3:00that's more like device to device. Uh,
3:03spy is more like all on the same board.
3:06Um, and it has a single controller with
3:08multiple peripherals. So, if we think
3:11back to UART, that was just one to one,
3:14right? Only one device could talk to
3:15another device. We couldn't add more of
3:17those or more devices onto that bus.
3:20With Spy, we can actually add more and
3:22more devices and we can share the same
3:24wires between all those devices. And so
3:27it can kind of help out with if we're
3:29limited on how many pins are on our
3:32microcontroller. Um, that can help out
3:34uh cuz we're reusing those pins for
3:37multiple devices.
3:39Um, and it's synchronized. So what that
3:42means is it uses a clock. So, if you
3:44think back to UART, that had no clock
3:47wire on it. Um, you had to have the two
3:50devices basically speak at the same
3:53speed, right? We had a preconfigured
3:55baud rate for UART and you had to make
3:57sure that both devices were at that baud
3:59rate for them to talk to each other.
4:01With Spy, that's not how it works. With
4:03Spy, we have a separate clock uh wire
4:06which is driven by the controller. And
4:09so it can basically decide what the
4:11speed is going to be with that
4:12additional wire. Um it's full duplex
4:16with that which that means is we can
4:18both send and receive data at the same
4:20time very similar to UART. Um and it can
4:23go quite fast. So multiple megabits per
4:26second and it's a de facto standard. So
4:29I think Philips back in the 80s came up
4:31with this but there's no like standard
4:34document um that explains how this all
4:36works. the industry has just kind of uh
4:39figured out or all agreed on how this
4:42should work and a lot of devices out
4:44there all kind of speak this. Uh there
4:46are some differences between
4:48manufacturer to manufacture and we'll
4:49talk about what those potential
4:51differences are but most of the stuff
4:53that we're going to be talking about
4:54everyone has already kind of agreed on
4:55and this is how we implement spy. Okay,
4:59any questions so far?
5:02Okay,
5:06so here's an example where we have uh a
5:09controller. So this would most likely be
5:11our microcontroller. And then we have
5:13three peripherals. And you can see that
5:15they're all sharing those wires, right?
5:17Like I was talking about.
5:20And so those wires are SDO, that's
5:22serial data out, SDI, serial data in.
5:25And so the serial data data out of the
5:28controller will connect to the serial
5:30data in of the peripheral. and vice
5:32versa for the other way around. And then
5:34we have a clock like I was talking about
5:37and that's driven by the controller. So
5:40the controller is the one that actually
5:42flips the clock high and low, the
5:44peripheral does not touch that wire. It
5:46just listens to it. Um, and what that
5:50basically means is if we want to clock
5:52in data from the peripheral uh to the
5:55controller, well, the peripheral can't
5:57just start sending data. it needs to
5:59wait for the controller to actually
6:01start cycling the clock before it can
6:03send data.
6:08Okay, you'll notice that we have a
6:10couple more pins in here and they're
6:12called chip selects or CX. And so this
6:15is how we can uh do arbitration where
6:19the controller can choose who it wants
6:20to talk to. So because we're sharing all
6:23those data lines, we need some way to
6:25choose which device that we want to talk
6:28to. So how we do that is basically the
6:31controller would set the CS pin low. So
6:34if we were trying to talk to peripheral
6:362, it would set CS2 to low. It would
6:39keep CS1 and CS uh 3 high. And then it
6:43would talk to peripheral 2. Okay? And
6:46the other peripherals, they would see
6:48all that all that stuff happening on the
6:50bus. they would see the clock going and
6:51all that. They just won't listen to it
6:53because their chip select is high at
6:55that point. Does that make sense? Any
6:59questions so far?
7:02All right. And a good way to think about
7:05um spy is basically we have a shift
7:08register on the controller and a shift
7:09register on the peripheral and we're
7:11shifting data uh from the controller
7:14onto the peripheral and shifting data
7:16back from the peripheral to the
7:18controller. And to demonstrate that a
7:20little bit more, here's kind of an
7:22example.
7:24So here, as the clock goes up and down,
7:27we're going to take bit by bit, you
7:29know, on those STO and SPI lines, and
7:32we're going to take the data that was in
7:33the spy controller shift register and
7:36shift it over to the spy peripheral
7:39uh shift uh register. And then at the
7:42same time, we're also taking from the
7:43peripheral to the controller. Okay. And
7:46so you can implement this protocol with
7:48just two shift registers and a clock and
7:51you got spy. So this is kind of a good
7:54way to think about this how it actually
7:56gets implemented on your
7:58microcontroller. Um we don't know uh we
8:01think we have some ideas but this is
8:04just kind of just to demonstrate um how
8:06this could work.
8:08Okay. The packet sizes they're typically
8:108 bits but this isn't standardized. you
8:13know, it's one of those things that's
8:14not standardized. So, the device and the
8:18controller would have to agree on how
8:19big the packet sizes are going to be.
8:22Um, so typically those are between 4 and
8:2416 16 bits, but mostly 8 bits is the
8:27go-to. And there's no flow control. So,
8:29UART has some flow control. And then
8:32we're going to be talking about I
8:33squared C next. It has something called
8:35an acknowledgement bit. There's no
8:37acknowledgement for spy. Um, if you
8:40wanted to implement something like that,
8:42you could probably do it in software.
8:44Uh, but there's no like mechanism built
8:46into the spy protocol to do that type of
8:48stuff.
8:50Okay. Any any questions on this part?
8:54Still all making sense?
8:57This is my first time lecturing, so Oh,
8:59you got a question. So does
9:08>> um it depends on how the peripheral is
9:10designed. But yes, that's that's uh how
9:13you should think about this part. Yeah.
9:18>> If you want to receive data, you have to
9:19send data basically. So most of the time
9:22we'll see in an example where you don't
9:24necessarily need to send data, but the
9:27the line has to be high or low. So
9:29technically you are either sending all
9:31ones or sending all zeros. So yes, you
9:33would be sending data even though it
9:35doesn't really look like you are.
9:37>> Uh you first. Yeah.
9:38>> Yeah. Um also you're saying that there
9:42is a [clears throat] single register
9:44where
9:48[snorts]
9:498 bit.
9:54>> So we we're going to we have a
9:55falsestead simulation that I'm going to
9:57show right after this. Maybe hopefully
9:59that'll answer your question. If it
10:00doesn't let me know and we'll we'll
10:01we'll circle back. You had a question?
10:03Um let's say like like you said if I
10:07want to read something from I need to
10:10write something as well.
10:12>> Does that mean my has to have like know
10:14like this means nothing?
10:17>> So yes the you would beforehand kind of
10:20figure out how the controller and the
10:23peripheral would talk to each other. Um
10:25I'm just going to skip ahead a little
10:26bit to kind of explain what the typical
10:29transaction would look like.
10:32Okay, here we go. This is what you're
10:34typically going to see. So, you don't
10:37necessarily see both data being
10:39transmitted and received at the same
10:41time. So, we got the SDO, that's what's
10:44being sent from the controller to the
10:45peripheral and the SDI, that's what the
10:48peripheral is sending to the controller.
10:50You can see in this example, it's it's
10:53one after another, right? We're first
10:55sending data from the from the
10:57controller and then we're sending data
10:59from the peripheral. Okay? Okay. And the
11:01reason you would probably do this is
11:03because the controller probably needs to
11:05request from the peripheral which what
11:07data do I actually want? Okay. So this
11:11transaction might be like the controller
11:13might want to read register S on the
11:17peripheral. Okay. So usually other
11:19devices other peripherals will have like
11:21internal registers. Uh so maybe it wants
11:24to read uh uh register S and then F
11:28would be the data that the peripheral
11:30sent back uh that was in its register.
11:34Okay,
11:36any other questions?
11:39All right, so let's kind of look at that
11:41false said.
11:44Um
11:45I think I have it here.
11:48Okay, so in this example, we don't have
11:51the the return path. So the peripheral
11:54going back to the controller. We're just
11:55kind of showing how if the controller
11:57wanted to send data through the
11:59peripheral, this is what it's going to
12:00look like. You can see we have two shift
12:03registers. We got uh the shift register
12:06for the controller right here, and we
12:08got the shift register for the
12:10peripheral here. You can see this is the
12:12data that we currently have in the
12:14controller's shift register. We got a
12:17clock in here. This clock will go to
12:20both peripherals. And then we have these
12:23lines here. These are our chip selects.
12:25So right now I have chip select one low.
12:29And low means I want to select you. So
12:32if we if we run this simulation, what we
12:34should see happen is the data in this
12:36shift register should get shifted over
12:39on this wire to this peripheral for each
12:42clock edge. Okay. So, let's just kind of
12:44run that and hopefully that will make
12:46sense to you guys.
12:49So, there's the clock going. You can see
12:51the clock down here is clocking
12:54and it's not shifting.
12:57So, I have to actually tell it to shift.
12:59So, let's try that one more time.
13:05Okay, now it's shifting the data. You
13:07can see here's the data that's being
13:09sent [clears throat] on the SDO line
13:11through the peripheral.
13:13And when we're done with those eight
13:14bits, we should see the same data that
13:18was in this shift register now got
13:20shifted over into this shift register.
13:24Does that make sense?
13:27Does that answer your question earlier,
13:28do you think?
13:30>> Uh, yeah. So, it's just one pack at a
13:32time.
13:33>> Yeah, one packet at a time. Okay. If we
13:36wanted to have some data on the
13:40peripheral that gets shifted back to the
13:42controller, we could have done that. We
13:43could have had data there and had a wire
13:45coming back the other way and it would
13:47have filled in the side controller shift
13:49register with whatever data was in that
13:50other one.
13:52Okay.
13:55All right.
13:57So, why don't we go back to this?
14:05Okay, so here's a typical timing
14:06diagram. This will be like eight bits.
14:09You can see our clock. You can see our
14:11chip select that's going low during the
14:14transaction.
14:17Uh here's our serial data out. This is
14:19the data being sent by the controller. A
14:21serial data out could also come from the
14:23peripheral. That's what the pin is
14:25labeled for the out pin on both devices.
14:27So you just have to think about that.
14:28Similar to UR, right? You had a TX go to
14:31RX, TX go to RX. Same thing here. But
14:34here we'll assume this is coming from
14:36the controller. This is coming from the
14:39peripheral.
14:40And then there's our clock edges that
14:42we're using to shift in the data. And so
14:45we'll find on the next slide that we can
14:47actually choose which edge we want to
14:49use. But in this example, for each
14:51rising edge, the data that is in uh or
14:55is on those wires, that's the data
14:57that's being sent.
15:00This part make sense?
15:03All right.
15:05Okay. So, this is what I was talking
15:07about where we can choose actually what
15:09edge we want the data to actually get
15:12clocked in at. Um, so kind of confusing,
15:16but they split it into two things. They
15:18split it into a polarity thing and they
15:21split it into a phase. So, the clock
15:23polarity is basically what does the
15:26clock default as? Does it default at
15:29high or low? And so when there's no
15:31transaction going on, if I set the clock
15:34polarity to one, then this would be
15:36high. If the clock polarity is zero, it
15:39would be low. And then the phase, that's
15:41to choose whether or not we're clocking
15:43on the first clock edge or the second
15:46clock edge. Okay? So the phase of zero,
15:49that's going to be the first edge. Phase
15:51of one is going to be on the second
15:52edge. It doesn't necessarily mean
15:54whether it's going to be a rising edge
15:55or a falling edge. It's just whether
15:57it's the first or the second. Okay, does
16:00that kind of make sense?
16:04This this right here shows us all those
16:07different all the different combination
16:08of those four different modes. So we
16:11have modes 1 2 3 uh 0 1 2 3 and you can
16:16just kind of see how I can kind of show
16:18it with my cursor.
16:21So if the polarity is low, you can see
16:23it starts low and if the phase is zero,
16:26then we're clocking on the first edge
16:28here.
16:29If the phase is one, that means we're
16:31clocking on the second edge. And then
16:33here are the other combinations of that.
16:36Okay? And this is something that um
16:40wasn't standardized, right? So people
16:44started making spy devices and some of
16:46them decided, okay, well, I'm going to
16:48implement it like this or I'm going to
16:50implement it like this. And so what has
16:52happened is microcontrollers have now
16:54needed to support all of these different
16:56modes. And it's just because there's no
16:58standard. I mean, one of these would
17:00have worked for everyone, but no one
17:01could really agree on how to do it. Um,
17:04so now this is some setting that you're
17:06going to have to set up in your
17:07microcontroller in order to make sure
17:09that these devices can talk to each
17:10other. Anyone have a Yeah, question.
17:14>> What's the difference between sampling
17:15and talking?
17:18>> Okay, toggling. Yeah, good question. So,
17:20sampling is when the data is valid.
17:22Okay, so you can see this is called an
17:24an eye diagram.
17:26um it looks like an eye like your eye
17:28here. Um so the edge of the eye that is
17:33when the data is uh transitioning. So
17:35that's your toggling edge. Okay? So this
17:38would be your toggling edge right here.
17:40And then when the data is valid this
17:43would be your sampling edge.
17:45That make sense? Okay. Any other any
17:49other questions?
17:54Okay. So, we kind of already went over
17:56this slide, but this is what a typical
17:59transaction would look like. You're
18:01probably going to send data and then
18:03receive data. It's uh uncommon for you
18:06to be sending and receiving at the same
18:08time, but the protocol totally supports
18:10it and you can do that. Um, if for
18:13instance, let's say we had a lot of data
18:15to send or receive, well, you could
18:17basically say this transaction could be
18:19asking for data and then this
18:21transaction could be the receiving data
18:23of this transaction. But at the same
18:25time, we could be queuing up maybe the
18:27next read we're going to do. So you
18:28could do a bunch of sequential reads
18:30where we ceue them all up. That is
18:32potentially something that you could do
18:33with this. Okay, we can kind of figure
18:37out looking at this. Um, all right, we
18:40look at the clock. So the clock um by
18:43default is high. So that means that the
18:46polarity is one. And we we can see that
18:49we're sampling the [clears throat] data
18:51on the second clock edge. So that means
18:53that our phase is uh one as well. So
18:56this would be mode three.
19:01All right. So there are there's no
19:03maximum speed that spy can go. It's
19:06really dependent on your hardware. Um if
19:08your wires can handle the speed and your
19:10peripheral can handle the speed, then
19:13the microcontroller can go as fast as it
19:16can.
19:17um [cough]
19:18[clears throat]
19:19the limits are so so the microcontroller
19:23it will be driving for instance the
19:24clock high and low okay we'll learn
19:27about for I squared C that that's not
19:30always the the case we have something
19:32called open drain uh we'll explain that
19:34later but that might be a little bit
19:36slower but in this scenario just like
19:38when you set up in lab one where you had
19:40the GPIO pin uh push pull that's what
19:43that means right I can drive the pin
19:45high or I can drive the pin
19:47And so however strong that drive circuit
19:49is and however uh much capacitance is on
19:53the bud on the bus that determines how
19:56fast we can go. Okay? You're going to
19:58have some parasitic capacitance on the
20:01bus. Wires have capacitance. Pins have
20:04capacitance. That's going to slow us
20:06down a little bit, but it's not that
20:07much. So that's kind of what determines
20:10our speed. you get really fast and then
20:13you start having reflections of the
20:15signals and things like that. Um, we
20:18probably won't go that fast in this
20:19class. Uh, but that is something you
20:21might have to worry about if you're
20:22getting into like some really high speed
20:24stuff.
20:26Um, as far as knowing how fast the
20:29peripheral can go, just read the data
20:31sheet and it'll hopefully tell you like,
20:33hey, this is how fast this device can
20:35actually consume data. And so if we read
20:39that data sheet, we'll see, okay, well,
20:41I'm going to set my spy clock to 1
20:43megabit because that's what my
20:46peripheral can handle. Sometimes you can
20:48actually overclock. Um, a lot of the
20:50times, like going back to the example of
20:52using a um LCD display for the projects,
20:56I think the specs say it can go up to
20:58like 10 megabits per second, but often
21:01we'll have groups overclocking to like
21:0430 40 and it still works fine.
21:07Okay,
21:10here are some standard speeds that you
21:12might see around, but like I said, you
21:15can really pick whatever clock frequency
21:17you want. There's no This is standard
21:20um which means sometimes you'll see them
21:23use these. Sometimes you'll even see up
21:25to 100 megabits per second. So you there
21:28are some high-speed spy u buses out
21:30there.
21:33Okay. So, one downside with having the
21:37controller always have to request data
21:41is that if the peripheral has some
21:43information or it has something
21:45important it needs to uh tell it to the
21:47controller, there's really no way for
21:49the peripheral to get the controller's
21:51attention. Like um something happens,
21:54hey controller, I have data center.
21:55There's really no way to do that. So, we
21:57have to go outside of the spec. we have
21:59to go outside of spy and we have to
22:01implement that in some other way. And so
22:03in this example, what we're doing is
22:05we're adding some more wires. So if we
22:07can afford it, we'll add a couple more
22:09wires and we can use those wires as
22:11signals to our controller like, hey, I
22:13have something important to tell you,
22:15can you please wake up and let me clock
22:17in data to you? Okay. So, an example for
22:20this would be let's say I have a
22:23smartwatch and I most of the time want
22:26the screen to be off to not waste
22:28battery, but when I lift up that
22:30smartwatch to my face, I want the screen
22:32to turn on. Okay? And the way that we
22:35detect that is we have some gyro that's
22:37kind of measuring that movement and
22:39figuring out when the watch has been
22:42risen up. And if we were to just have
22:45the microcontroller uh just use regular
22:48spy to talk to the gyro, the potential
22:50issue is that um basically we have to
22:53constantly pull that gyro and we might
22:56want the microcontroller to go to sleep,
22:58right? If we want the screen off, we
23:00want it we want the watch to have a long
23:02battery life. Kind of want everything to
23:03be like in a low power mode. So what we
23:06could do and this is very common on
23:08gyros is we can use one of the interrupt
23:10pins that they usually have built into
23:12them. And so there will be some logic
23:14running on the gyro. It will detect this
23:16motion. It will flip one of those
23:19interrupt pins, maybe send a pulse or go
23:22high and that will tell our
23:23microcontroller like, "Hey, it's time to
23:25wake up. I got some important
23:27information to tell you." The
23:29microcontroller will read that data off
23:31the gyro. And then that is a way that we
23:34could save power in this type of um
23:36application. Okay. So there are ways to
23:40get around the issue of the controller
23:43um having to initiate every single
23:45transaction.
23:47How are we doing so far?
23:50Any questions?
23:54All right.
23:57I was going to say earlier I've never
23:58lectured before. So the fact that you
24:00have questions is scary
24:03because I have a feeling I'm not doing
24:04that well. But anyways, let's keep
24:05going.
24:08All [snorts] right. So, what are we
24:10talking about here? Oh, okay. So, we
24:12talked about how these are shift
24:13registers. Well, that means that we
24:15could do something kind of clever. Um,
24:17and I'll kind of explain that. So, we
24:20could actually daisy chain uh
24:23peripherals. And basically what we could
24:25do is we could put the STO to the one
24:29peripheral and then daisy chain. So,
24:30have the out of the other peripheral go
24:32to the next one to the next one. And so
24:34what could happen as we're cycling that
24:36clock, all that data is just we
24:39basically made a ginormous uh chip
24:41register and we're just shifting that
24:43data all the way down through all the
24:44peripherals. And the advantage of this
24:47is I don't need a chip select for all
24:49those peripherals. So let's say I had an
24:53LED strip. Okay? And this is something
24:55you probably will interface with uh
24:57during the project. This thing has
24:59hundreds of LEDs on it, right? If I were
25:01to use Spy House design with the chip
25:05selects, that would mean I would need
25:06like a 100 wires going down that strip
25:09in order to select which LED I want to
25:12talk to. Um, and as far as talking to an
25:15LED, why would I want to talk to an LED?
25:17Well, if I want them all to be a
25:19different color, I basically need to
25:20program them. So, that would mean I
25:22would need to talk to each of them
25:23individually so they could they could
25:25all be different colors. And so, the
25:27data that I'm sending to them is
25:28basically my color data. This is a very
25:31common thing that you'd see. I'm sure
25:32you've seen the LED strips but maybe not
25:34understood how they work. So anyways,
25:37going back to that with the shift
25:38registers, I don't need a chip select
25:41for all those LEDs. Instead, what I can
25:43do is I can just shift out all of the
25:45data. So there's, let's say there's 100
25:46LEDs. I would do a 100 transactions. All
25:49that data would get shifted to all those
25:51different LEDs and then I would have
25:53some kind of trigger, maybe like a
25:55pause. Maybe I pause for a couple
25:57milliseconds and that would tell the
25:58LEDs, okay, whatever values currently in
26:01your shift register, this is the color
26:03that you should display. Okay, that's
26:06how something like this would work. Um,
26:08if we look at this timing diagram here,
26:11in this example, we have a U, U1, and
26:14U2. So uh the first transaction would be
26:17the data going to U2 and then for the
26:21next transaction the data uh between
26:26these two
26:28that's what we're seeing on the top
26:29line. The data between these two is what
26:32we're seeing on the bottom line. So the
26:34data that was here then gets shifted to
26:36this device. And then after those two
26:39transactions, the data that we needed
26:41for U1 is there and the data that we
26:43needed for U2 is there.
26:46Does that kind of make sense how this
26:47would be possible?
26:50How we could daisy chain those all
26:51together?
26:55Okay, [snorts]
26:57any questions?
27:00All right.
27:04Okay, we're going pretty quickly.
27:07Um, okay. Spy on the XMC 4700. So, I
27:13think we learned about in UART that
27:16there's these things that are uh these
27:18channels that are configurable on our
27:20device. So, the device we use in lab and
27:23there's six of them. They call them
27:24USIC. I forget what universal serial
27:27something. Forget what it stands for.
27:30Um, anyways, there's six of them. We can
27:32configure them to be whatever we want.
27:33you want if they want you want them to
27:35be UART we can configure them to be UART
27:37if we want them to be spy we can do that
27:39we're going to learn about I squared C
27:40you could use them for that and the
27:42reason they did that is all of these
27:44protocols have similar things that can
27:46get reused they're all going to have
27:48like a clock they're all going to have
27:50buffers where data gets received and
27:53transmitted um so they decided to just
27:56reuse a lot of that hardware and just
27:58make these generic boxes that can talk
28:00all kinds of different protocols Okay.
28:04Um,
28:06again they call this synchronous serial
28:08channel on the XMC. And then this thing
28:11has uh these just for UART as well. They
28:14have uh FIFO buffers. So if you want to
28:17receive a lot of data pretty quickly,
28:19they have 64 of that or send a lot of
28:21data quickly. And then there's also some
28:23interrupts that these things can
28:24generate. Um, it also supports something
28:27called dual spy and quad spy. Um, so
28:32these are really common with flash chips
28:34that might be on your PCB. So let's say
28:37my microcontroller uh needs more flash
28:40and I decide to put a flash chip next to
28:42it. Uh, the way that I would interface
28:44with that is potentially these these
28:46things called dual spy or quad spy. And
28:49instead of having one wire that's
28:51transmitting data, how these things work
28:52is dual spy will have two wires. So,
28:55what that means is I can go twice as
28:57fast. Or if it's quad spy, that means I
28:59can go four times as fast. And that
29:01might be something I might want for
29:03flash because usually, you know, I want
29:06to get data on and off that flash as
29:07fast as possible. And so that's why a
29:10lot of the times they have this uh kind
29:12of it's a hybrid between a parallel
29:14interface and a serial interface because
29:17we're adding those additional channels
29:19uh that the data can be sent on. Okay.
29:24All right, so let's kind of go over what
29:26the pros and cons are of uh Spy. So the
29:31wiring is pretty straightforward. We
29:32have four wires. If we want to add more
29:35and more devices, that's going to cost
29:36us an additional wire. Okay, if we think
29:39back to UART, every time we added a new
29:42device, we had to add two more wires,
29:44right? And the other potential issue
29:47with UART is every time I add a device,
29:49I have to use another USIC channel.
29:52Okay. So, basically on my mic on the
29:54microcontroller we use, we're maxed out
29:56at six UART devices. With SPY, I can use
30:01I can use basically any GPIO pin for
30:03that chip select uh wire. And so, what
30:06that means is we're really limited by
30:08the number of pins on our device. So,
30:10for like the XMC 4700, it has 100
30:13something GPIOs. That means I could
30:16potentially have the spy set up where I
30:18have a 100 devices [clears throat] on
30:20that bus and they would all share the
30:22same clock and data lines.
30:24It is faster than asynchronous serial.
30:27So that clock is going to help us go a
30:29little bit faster. And there's no
30:31addressing. We'll talk about that in I
30:33squared C, but there's uh the only
30:36addressing that we really have are those
30:37chip select lines to let uh the
30:40peripherals know that they're being
30:41talked to. Um,
30:44chip select doesn't really scale that
30:46well. Let's say I have an Arduino like
30:48microcontroller. It only has like 15 IO
30:52pins. Well, that means that I can only
30:54have around 15 uh spy devices before I
30:58run out of pins.
31:00Um, there's no acknowledgement. We'll
31:02talk about with I squed C why an
31:03acknowledgement might be helpful. And
31:05there's no flow control like UART. And
31:08the controller must initiate all those
31:10communications. So with UR the whatever
31:13was on the um one end could always send
31:15data to the other one and vice versa.
31:18With spy the controller is the one that
31:20has to initiate all of those uh
31:23transactions.
31:26All right. So that is spy. Any last
31:29questions before I move on to I squ C?
31:34It all kind of makes sense.
31:38Okay.
31:46So, I squared C.
31:52So, it stands for interintegrated
31:55circuit. Um, everyone calls it I squ C
31:58though or I2C.
32:00Um, I I always forget what this actually
32:04called, but it's this is what's called
32:05inner integrated circuit. Um, you can
32:08read about it in the reference manual.
32:10Again, they kind of swat switched up
32:12what this thing is. It's called they
32:13call it interic bus protocol or IIC.
32:18Um, you can read about it here. This
32:20protocol was actually standardized at
32:22one point and um, NXP is the current uh,
32:26company that owns it. So, you can
32:28actually look up the spec for this
32:30protocol.
32:32All right. So, what is I squared C?
32:34Talked about how it's pronounced. It was
32:37developed also by Philips back in the
32:3980s for television sets. So they're
32:41they're uh designing TVs that had a
32:44bunch of IC's on them and they were
32:46trying to figure out ways to kind of
32:48reduce the number of pins that they
32:49needed and a way to communicate between
32:52all the different IC's on a TV.
32:55Um they had uh patents back when they
32:59invented this, but those patents have
33:01since expired. So now it's the de facto
33:04standard uh for two-wire communication.
33:07Um what that means is everyone well the
33:11the standards exist but now there's no
33:13license to use to use it. Um a lot of uh
33:17different companies have implemented it.
33:19Anytime you're going to have a simple
33:21sensor that doesn't have to send that
33:23much data like a temperature sensor or
33:25something like that um you're going to
33:27use I squared C. I suspect most of you
33:30for your project you're going to be
33:31using I squared C in lab this week we're
33:34going to be talking to an accelerometer
33:36via I squared C. So it's very common.
33:41Uh so 2 years ago and 2 days uh the
33:45patents expired. So that means you no
33:47longer have to pay NXP. So Phillips got
33:50spun into NXP. You no longer have to pay
33:54them in order to implement this
33:55protocol. But what they do still do is
33:58they keep a list of all the addresses
34:01that have been assigned to devices or
34:03sensors. Okay, we're going to learn
34:05about why this protocol needs addresses
34:08and why each uh peripheral needs its own
34:12uh unique address in order to make sure
34:14there's no conflicts. So devices have
34:17two devices having the same address.
34:19What NXP offers is basically getting
34:22officially assigned an address. So you
34:26would pay some money to NXP. They would
34:28give you an address and they would
34:30guarantee you that that address is not
34:33used by any other official I squared C
34:37um device. Okay? And they don't publish
34:39that list. If they did, it would be
34:41pretty easy to just pick an address uh
34:44that's not used. I'm sure someone can
34:46figure out all the addresses they've
34:48already kind of sent out. Uh but that's
34:50technically how it works. And I'm sure
34:51there's a lot of companies out there
34:53that are just making sensors and not
34:55actually going through that process to
34:56get the address.
35:00Okay, so this is what it looks like.
35:02This is what the bus looks like. And it
35:05only has two wires. And we can add as
35:08many devices as we want. And we still
35:10only have those two wires. There's no
35:12additional wires needed for more
35:13devices. And it has some weird stuff
35:16going on here. We got some external
35:18resistors. These are pull-up resistors
35:21and we need these in order for this bus
35:23to work. So, we'll kind of explain that
35:26in the next couple slides, but that is a
35:29a thing about this bus. And the two
35:31wires that we have, we have serial data
35:33line, SDA, is what you'll commonly see
35:36it uh listed as, and serial clock line,
35:39SDL. Okay, so we have a clock and a
35:41data. And you might wonder, well, how do
35:44I send data and receive data? Well, both
35:47of these lines can be controlled by both
35:49the controller and the peripheral. So,
35:51if the peripheral wants to send data to
35:53the controller, it can do it using this
35:55wire and the same going the other way
35:57around. Okay? And we'll we'll go in the
36:00next couple slides and explain how that
36:02actually works. Um, so how do we
36:05actually make sure that we're talking to
36:07the correct address or correct device?
36:09We have an address. So, we have a bunch
36:11of devices or peripherals on the bus.
36:14They need to have addresses so that we
36:16can tell all the devices on the bus who
36:18we're actually talking to. And those are
36:20typically seven bits, but you can also
36:22configure it so that they're 10 bits or
36:2416 bits, but seven is very common. Um,
36:29address zero, that's if I
36:30[clears throat] wanted to broadcast
36:31something to all the devices, I could
36:33just use the address zero for that.
36:37And then the speed is actually
36:40determined by these pull-up resistors
36:42that we have. Can anyone guess why the
36:46speed would be controlled by the it
36:49would be dependent on whatever the
36:51resistor value is? Any ideas? [snorts]
36:54To give you a little hint. So if these
36:57are pull-ups, then what are these
36:59devices doing? Well, they're just
37:02pulling the lines low. They're not
37:04actually setting a high value. That's
37:06the job of the resistor. So the resistor
37:09will transmit a one. And if we wanted to
37:11transmit a zero, then we would have the
37:14device pull that down. So with that
37:17information, any ideas why the resistor
37:20value
37:22would impact the speed of how this
37:24works?
37:26No one.
37:28It gets at that that parasitic
37:30capacitance that we were talking about
37:31with spy. So all wires and like the pins
37:36on our microcontroller, they have a
37:38small amount of capacitance. We call
37:40that parasitic capacitance. And that
37:43wasn't designed into the system. It's
37:45just inherently there. And so we have to
37:48deal with it. And the problem is is
37:50these pull-up resistors can't charge up
37:53all those parasitic capacitors fast
37:55enough. Okay? So if we have a a big
37:58resistor value, you know, we're going to
38:01create basically an RC circuit and it's
38:03going to take a long time to uh
38:06basically pull that line high by the the
38:09resistor is doing that. And so what we
38:12could do is we could have smaller values
38:14and that would cause the line to go high
38:16faster. Otherwise, we're waiting for
38:18that edge transition. the longer that
38:20edge transition is, the the shorter
38:23basically the uh the longer the clock
38:25period has to be in order for that to uh
38:28go high and low. Does that kind of make
38:30sense? We're going to do a false bed
38:33that kind of shows that a little bit
38:35more uh detail. Um so we'll we'll get
38:38there if it doesn't make sense right
38:40now. What does that kind of look like
38:43inside the devices? So we have these N
38:47losses and again if we think back to
38:51when we were configuring GPIO in lab one
38:54we could either configure it as in a
38:56pushpull mode or we could configure it
38:58in an open drain mode. And that's what
39:01this this mode is. Basically these N
39:03mosses are pulling the line low but we
39:06don't have a poss.
39:10The thing that's actually driving the
39:12pin high is this external resistor which
39:15is outside of the chip. [clears throat]
39:19Does that make sense?
39:22Because of that we actually need to uh
39:25also read what's going on uh from the
39:29same pin. So uh the controller for
39:32instance will be driving the pin low
39:35[snorts] but in order to see the data
39:36that the peripheral is sending it also
39:39needs to basically read from that pin so
39:41that that pin can go in both directions.
39:43So we can both write and read from that
39:47pin. Okay. The reason why we're doing
39:50this is if we were to have both of these
39:53devices push and pull. So if if the
39:56peripheral was pushing the the line
39:58high, like it was driving the line high,
40:00and the controller was driving the line
40:02low, well, you have a conflict there.
40:04One's trying to drive it high, one's
40:06trying to drive it low. You're going to
40:07have a lot of current going between
40:09those. You might break something. So
40:12this uh this architecture here allows us
40:14to basically put any value we want on
40:17the on the line and it won't break
40:19anything. So for instance if uh the
40:22peripheral wants to send a one and the
40:25controller wants to send a zero well the
40:27controller will be driving it to zero
40:29and that's will be the actual value on
40:32here but nothing will break right even
40:34though the peripheral is trying to send
40:35a one it doesn't really matter uh
40:38because nothing will break and the
40:40peripheral will actually see that like I
40:42was trying to send a one but I'm seeing
40:45a zero on the bus. We'll see how that
40:47that tool could actually be useful later
40:49on.
40:51Does that the physics of this kind of
40:52make sense?
40:54All right, let's dig into it a little
40:56bit more. First, I kind of want to show
40:58the advantage of this bus, what it looks
41:00like. Um,
41:02so this is typically what you're going
41:04to see. You're going to see a bunch of
41:05devices on the bus. You only need four
41:07wires, really two. You need your clock
41:10and your data, and we need power and
41:12ground. you have those four wires to all
41:14the devices and they can all talk to
41:16each other. So all five of those devices
41:18hopefully they all have a different
41:20address. Okay, if they had the same
41:22address then if I tried to talk to this
41:24one and this one had the same address uh
41:27these devices wouldn't they would both
41:28think they're being talked to. In
41:30reality we only talk to one. So ideally
41:32you would configure or make sure that
41:34all of these devices have different
41:36addresses. Um, sometimes you'll have
41:39that issue where you want to use, well,
41:42let's say you want to use a sensor,
41:44multiple sensors that are all the same.
41:46Well, they're all going to have the same
41:47address, right? Cuz the manufacturer is
41:49going to basically say, "Okay, this
41:51device has this address." So, if I want
41:53to talk to multiples of that, then I'm
41:56going to have an issue. Um, I could use
41:58external expander chips that can help us
42:01in this situation. So they have some
42:03chips that basically break out one I
42:05squared C bus and and make it into a
42:07bunch. So I can talk to a bunch of
42:09devices that have the same address. And
42:11sometimes these devices will have a wire
42:14on them or a pin rather that I can set
42:17high or low and that will actually
42:19change the the address of my device.
42:22Okay. So and we're actually going to do
42:24that in lab 6. So, we're going to have
42:27you play around with an accelerometer,
42:29and there is a pin that I can set either
42:31high or low, and that will determine
42:33what the address of the device is going
42:35[cough] to be. [clears throat] So, I can
42:36talk to two of those devices. I can set
42:38the pin high on one of them, the pin low
42:40on the other one. We'll have two
42:42different addresses. I can talk to those
42:44two devices separately.
42:47Does that make sense?
42:50Okay.
42:53Um, as far as pull-ups, uh, a lot of the
42:56times you're going to get these boards
42:58that they're going to just automatically
43:00put the pull-ups on there for you. So
43:02that, for instance, in lab, we're going
43:04to be working with an accelerometer that
43:06already has the pull-ups built into it.
43:08But if you were designing the PCB, you
43:10would have to think about putting those
43:11pull-ups on there in order for this bus
43:14to work.
43:17Okay, so let's look at falsestead.
43:20Um,
43:26so for this example, um, the clock is
43:29just going to be going all the time.
43:31That's not what would actually be
43:33happening. Uh, the clock only goes per
43:36transaction. In the next couple slides,
43:38we'll kind of show you what a
43:39transaction looks like, but this is
43:41really just to demonstrate
43:43um what's going on with that parasitic
43:45capacitance and how those uh those end
43:49mosses are pulling the lines low.
43:53Okay, so
43:55here I have my clock and this is just
43:58going high and low. You can see while
44:00we're also driving the clock, we're also
44:02reading it. Okay. So, both devices are
44:05reading that uh the the target or the
44:09peripheral it can do something called
44:11clock stretching. So, if it if for
44:13instance it wanted to slow down uh a
44:17transaction, it could actually keep the
44:18clock low to let the controller know
44:21like, hey, I need more time.
44:23Um that's kind of a thing. Um but okay,
44:27so if we wanted to send data, so here's
44:29our data line. You can see here's our
44:31our pull-up resistor.
44:34And I'm going to just turn off this
44:36parasitic capacitance for for right now.
44:38So if I wanted to send data, our clock
44:40is just going. What I can do is I can
44:44turn on this end loss right here and I
44:46can pull the line low. Okay? And so now
44:48my controller is talking on that data
44:51line. If the target wants to respond and
44:54send some data back, it uses the same
44:56wire and it pulls it down. Okay, so
44:59here's the target sending data. So
45:01here's the data that was sent by the
45:03controller. Here's the data being sent
45:06by uh the target. Okay, does that part
45:10make sense?
45:12So it's kind of a clever way to use one
45:14wire to talk in two directions.
45:17So if we turn on that parasitic
45:18capacitance,
45:21you can see that our clock is now not
45:25shaped norm. It's not a square wave
45:27anymore. It's got that that curved
45:29rising edge. And if you were to hook up
45:32this bus to an oscilloscope, you would
45:34actually see that like this is what what
45:36the I square C transactions actually
45:38look like. You have that that rising
45:40edge that's kind of curved off at the
45:42end. Okay. If that capacitance
45:47um where we're already maxed out on
45:50that, so let me just show an example
45:51where
45:53let's say we have a different resistor
45:55here. So, so we have a higher resistor.
45:57So, a higher resistor means that we have
45:59to go slower, right? So, it looks fine
46:03now, but that's because our capacitance
46:06is quite low. Let's say we have a lot of
46:08devices. As we add more and more
46:10devices, our capacitance is going to get
46:13bigger and bigger. There's going to be
46:14more parasitic capacitance because we're
46:16going to have more wires. We're going to
46:17have more pins. Okay? So if that
46:21happens,
46:23we we crank up that capacitance. You can
46:25see this is what happens to our clock
46:27signal. It doesn't actually have enough
46:29time to get up to the high value.
46:33Okay? And if it if if it doesn't get
46:35high enough, that could be an issue,
46:37right? Our our target won't even see the
46:39clock cuz the target is just seeing
46:41whether it's high or low. You can see uh
46:45well, it's still working here. we must
46:47be still at the threshold for this
46:50inverter. Um, but potentially the
46:53capacitance could be so high that this
46:54won't get high enough. And so what we
46:56can do is we can make that resistor
47:00smaller.
47:01We want to go faster or we have more
47:04devices.
47:06Okay. And that fixed that. Let's go
47:08faster and see what happens there.
47:12So I'm going to make my clock go a
47:13little bit faster. Maybe like 300 hertz.
47:18Okay, now we're going really fast.
47:19Again, we have that same issue where the
47:21clock is not getting up to the the high
47:24value uh fast enough. And we'll go even
47:28lower. We'll go even lower on this. So
47:30maybe we'll do 200 ohms. And now look,
47:35we we fix the clock.
47:39Okay, does that kind of make sense? What
47:41we're trying to show in this slide is
47:44that um basically how those end Mosses
47:47work and kind of the realities of
47:51building this with the parasitic
47:53capacitance and the pullup resistors
47:55kind of the things we have to design
47:57around in order to get this thing to
47:58work.
48:01Any questions?
48:03Any other values you want me to plug in
48:05there?
48:08Okay.
48:12So let's go back to the slides.
48:20Okay,
48:22so we were just kind of talking about
48:23the the physical aspects of I squared C,
48:27but this is what the actual timing
48:28diagram looks like. And it's kind of
48:31unique in that we're not using edges to
48:33clock in data. The data is actually it's
48:36in those those those uh rectangles. So
48:39the data is valid when the S the clock
48:43line is high. Okay. So this is the point
48:46where that data is valid. Why do they
48:48kind of do that? So you know we have
48:51that long rising edge in order to uh
48:54deal with that. Basically how this works
48:57is
48:58uh the clock is going to go low. That's
49:01going to happen quite quickly. We can
49:02pull the line the clock line low fast
49:04because there's no resistance there. And
49:07that's basically signaling to let's say
49:10we have the target sending data.
49:13So in that example, if the target is
49:14sending data, it would see that clock
49:16line go low. And that would basically
49:19tell it, okay, now it's time for you to
49:21transition the data line to whatever
49:24value you want to put there. So that is
49:26that transition there. And hopefully
49:29that takes a short amount of time or uh
49:33that happens before we get to this this
49:35point right here. Okay. So that's giving
49:37some time for that to happen. Then by
49:40the time that this clock signal is high
49:43right here, whatever data that's on the
49:45data line, it should be valid. Okay. Um
49:50so that that's how data is clocked in
49:52and out. Uh the other thing to look at
49:55are these start and stop conditions.
49:58So to start off a transaction, what the
50:01controller is going to do, and maybe I
50:03didn't mention it by the way. Well, here
50:04it is right now. uh the controller is
50:07the one generating the clock. So similar
50:09to spy, the clock is is always driven by
50:12the controller.
50:14Um so the controller is going to be the
50:16one that's going to kick off this
50:18transaction. What it's going to do is
50:20it's going to pull the data line low and
50:22then that's kind of a warning to the
50:25peripheral like, hey, we're about to
50:27start a transaction. It's going to wait
50:30a little bit of time and then it's going
50:32to start cycling the clock. Okay. Then
50:35once we've sent all of our data, we are
50:38going to uh do this stop sequence here
50:41where it's the data is going to finish
50:43uh low and then uh the clock is going to
50:46stop and then this is going to go high
50:48and then the bus by default just rests
50:50at high for both wires.
50:54Does that part make sense?
50:55>> Yeah.
50:56>> If the controller like how does the
50:59control
51:01center?
51:01>> It's the same issue we have with spy.
51:04you would need to pull it or use an
51:06internet or uh internet interrupt pin to
51:10basically communicate that to the
51:12controller.
51:14Okay.
51:16Any other questions?
51:20Okay.
51:23Okay. So, uh this is what a full frame
51:27looks like. So, this is a a complete
51:29transaction. We hadn't really touched on
51:31the addressing part. So this is showing
51:33the addressing phase and then the data
51:36phase.
51:38So because [clears throat]
51:40uh we need to because each device um
51:44doesn't have like a chip select line,
51:46right? We need to first tell the bus who
51:48we're talking to. And that's what this
51:50address stage is. This is where we're
51:52going to communicate to the bus which
51:55device do we want want to actually talk
51:56to. In this example, we have seven u
52:00seven bits. Okay, this is how we do
52:03arbitration. So we have seven bits and
52:05that's going to be our our address.
52:09Um, so that gets sent first and you can
52:12see that start condition that we were
52:14talking about right there. And then we
52:17have a read write bit. Okay. And this
52:20tells the target whether or not we're
52:22about to do a write transaction or a
52:24read transaction.
52:26Okay. So whatever follows this address
52:29part is then either a write or a read
52:32and that's determined by what this bit
52:34is set to. And then we have this thing.
52:38This is an acknowledgement.
52:40Um
52:42it's for short we call it an act. And if
52:45it's a not acknowledged we call that a
52:47knack. Okay. And an an act is
52:51represented if the uh the line goes low.
52:54And what's unique about this is these
52:57first eight bits, these are going to be
52:59sent by the controller. The act is sent
53:03by the target. Okay? So inside this
53:06transaction using the same wire, both
53:09the controller and the target are
53:12talking inside of here. Okay.
53:16Why might we want to use or why might we
53:19want to assign zero to app? Why do we
53:22use zero instead of one?
53:26Can anyone guess?
53:28>> Yeah.
53:32>> Always. So acknowledge it by just not
53:36doing anything.
53:36>> Exactly. Yeah. So the only way that we
53:39can acknowledge the only thing that we
53:40can actually do as a target or
53:42controller is pull the line low. The
53:45resistor is always pulling it high. So
53:47if the target's not even there and uh if
53:51it's not even there this line would stay
53:53high. Okay. So we what we need to do is
53:56we need to assign an acknowledgement to
53:58zero and so that uh that target would
54:01pull this low and that would tell the
54:04controller like hey I've acknowledged
54:06that you have sent me an address. And
54:09what does that kind of acknowledgement
54:11mean? It I mean that's basically what it
54:13means. and says hey I have successfully
54:16I am ready to either uh read or write
54:19data okay that's what the target is
54:21saying to the controller
54:24um what else about this
54:29yeah okay one like okay so when we're in
54:33lab and we're trying to figure out
54:35what's wrong with this you're going to
54:36hook up I squ C to a logic analyzer to
54:40kind of figure out what's going on with
54:41the bus when it's not working Okay,
54:43that's the first thing I'm I'm always
54:44going to ask you to do if your I squed C
54:47is not working. Well, we got to hook up
54:49a logic analyzer and see what's actually
54:50going on. So, you're going to see
54:52something like this on the logic
54:53analyzer and you're going to see that
54:55act that active and if that act is
54:58staying high, which means not
55:00acknowledged, it could mean a couple
55:01things. It could mean that our target is
55:03not wired properly. So, it's not even
55:06there. So, it can't acknowledge anything
55:07and it's not wired correctly. Or it
55:10could mean that your address is wrong.
55:12If you put the wrong address in there,
55:14well then of course the device is not
55:16going to acknowledge that because you're
55:17talking to someone else. Okay, so that
55:20could be some scenarios where um like
55:23when when you're actually working on
55:24this in lab where you would see a knack
55:26there. Okay, so after we've done this
55:30whole address phase, that's when we
55:32start moving on to the data. And this
55:33would be either a read or a write
55:35depending on this bit here. And then we
55:37send the data. Um and we can actually
55:40have this continue on. So if I wanted to
55:42send a lot of data, I could have a bunch
55:44of data after this. So a bunch of 8bit
55:46transactions or I could read a bunch of
55:49data. Okay. And here's [clears throat]
55:52another acknowledgement I think. Do we
55:54talk? We'll talk about Yeah, we'll talk
55:56about it on the next slide, I think.
56:00Maybe.
56:03Yeah, we'll talk about in a little bit.
56:04We'll talk about what that other act
56:06does uh for the data phase.
56:11Okay, this protocol allows us to have
56:14multiple controllers. This isn't
56:16something you do commonly, but it is
56:19capable of doing it. And it and
56:21accomplish this is that using what we
56:23call a wired and so we've essentially
56:26made an ANDgate with a wire. Uh what
56:31that means is if both device we have two
56:33devices sharing the same wire. If both
56:36devices are sending a one then we would
56:39see a one on the b on the bus. If one of
56:41the devices is sending a zero it would
56:43be zero. If the other device is sending
56:45a zero it be zero. If they're both
56:46sending zero it would be zero. So that's
56:48an and um and so what that allows us to
56:53do with multiple controllers. Uh if we
56:55have a single controller, we don't
56:57really have to worry about arbitration,
56:58but we do have to worry about that with
57:00multiple controllers because if they
57:02both want to talk at the same time, we
57:04need to decide who actually gets to
57:07talk. Okay? And so they're both going to
57:10start sending the data at the same time.
57:14Uh but then we're going to have this
57:16arbitration thing where whoever sends
57:18the first zero is going to win. Okay?
57:21Because it's a wired hand. Whoever sends
57:23the first zero, it's going to be zero.
57:26And the other device can see that. So if
57:28one device is sending a zero and the
57:30other one's sending a one, well, they're
57:32also both reading the line at the same
57:34time, that other device will see the the
57:37zero and be like, "Okay, I lost. Someone
57:40has a higher priority message." So what
57:42that basically means is if I have a
57:43lower address, uh, I have a higher
57:46priority. And and if I have the same
57:48address, let's say these both
57:50controllers are talking to the same
57:52target, they have the same address.
57:54Well, then it would go to the read write
57:55bit. So whoever is writing, I think
57:58writing is zero, that one would win. And
58:00if they're both trying to write, then it
58:02would go to whoever whoever sends the
58:03lowest data value. Okay, that's kind of
58:06how this arbitration scheme would work.
58:08Does that make sense how that would all
58:10work?
58:12It's not that common. I can't imagine
58:15why anyone would want to do this for the
58:17project, [clears throat] for instance.
58:19Uh, but it does exist. [snorts] You can
58:22do it.
58:24All right. So, we kind of we were kind
58:25of talking about what this stuff would
58:27look like on an oscilloscope.
58:28[clears throat]
58:28This is a screenshot from an
58:30oscilloscope. You can see that curved
58:33edge on the rising edge. Okay. And here,
58:36um, it's kind of surprising that it
58:38works, but it does. It's not quite
58:40getting to high, but we can see we're
58:43getting acknowledgements. Um, so this
58:45this is what a natural transaction would
58:47look like um on an oscilloscope. And if
58:51if it's if you're looking at the logic
58:53analyzer and everything looks right, but
58:56the but things are still not working,
58:58then that's where you got to pull out
59:00the oscilloscope and that will give you
59:02more information. Right? This is kind of
59:03like an analog issue, right? That that
59:05that curved edge. We need to see that on
59:09an oscilloscope to kind of debug this
59:11bus even further. Okay. During like the
59:14exam, we might give you one of these di
59:17diagrams and you should be able to look
59:19at these [clears throat] signals and be
59:21able to basically all the all the
59:22writing up top. You should be able to
59:24fill that all in. You should be able to
59:25see what we're doing here. Like we're
59:27doing a right and then doing a read.
59:30Okay.
59:33Any questions on that? [snorts]
59:39Okay, so we talked about that
59:41acknowledgement at the end of the data.
59:45Okay, and it can mean two different
59:47things depending on whether we're
59:48writing data or reading data. If we are
59:51reading data, then the acknowledgement
59:53is going to be sent uh by the
59:55controller. That kind of makes sense.
59:57Okay, so the target is going to be the
59:59one that's sending the data and the
1:00:01controller is going to be the one that's
1:00:02acknowledging that. What an
1:00:04acknowledgement means if I acknowledge
1:00:07it means I would like to receive more
1:00:09data after this. That's what an it
1:00:11acknowledge means in this scenario. If
1:00:13it's if you send a nap and not
1:00:16acknowledge that means okay you sent me
1:00:18enough data we're done with this
1:00:19transaction. Uh that's it. If we are
1:00:22doing a write
1:00:25uh that's where the the target is the
1:00:27one doing the acknowledgement. So the
1:00:29controller is sending data. The target
1:00:32is acknowledging that data. And what
1:00:34that acknowledgement means is like, yes,
1:00:37I see that you're sending data. I
1:00:38understand this data. It makes sense to
1:00:41me. It's acknowledged. And not
1:00:42acknowledge is something's going wrong.
1:00:44Uh I don't understand the data. Um it
1:00:47didn't come through. We, you know, it
1:00:49can mean all all kinds of different
1:00:51things. But that's kind of what the the
1:00:53knack and the act means depending on
1:00:56whether it's a write or a read.
1:00:59Make sense?
1:01:05All right. What are we trying to convey
1:01:07here?
1:01:09Okay. So, yeah, we were doing a read and
1:01:12then you can see that the controller, it
1:01:15only wanted to read one bite. So, it
1:01:17sent a knack at the end of that telling
1:01:19the control or uh telling the [snorts]
1:01:22uh peripheral or the target, hey, we're
1:01:25done uh with this transaction.
1:01:31Okay. So, just like uh spy,
1:01:37we're going to be using and you are
1:01:38we're going to be using those USIC
1:01:40channels again.
1:01:42Um, and this is what it kind of looks
1:01:45like in the reference manual if you want
1:01:47to see how this is set up. Um, our chip
1:01:50does support multicontroller. So that
1:01:52thing we talked about with the
1:01:53arbitration scheme, our chip can
1:01:56actually do that. Again, I don't know
1:01:57why you would want to do that, but you
1:01:58could if you wanted. And then target
1:02:00mode. This is if you want the XMC to act
1:02:05as a target, right? Um, so let's say I
1:02:08have two uh microcontrollers and I want
1:02:11one to be the controller, one to be the
1:02:13target. I could set it up that way and
1:02:15they could communicate to each other uh
1:02:17via I squared C. So that is a a thing
1:02:20that we can do. One weird thing about
1:02:23the XMC 4700 is we can actually
1:02:28uh choose a pin. So these are these
1:02:31squares right here are pins. We could
1:02:34actually use four pins instead of two
1:02:36pins to talk I squed C. So we could have
1:02:39one P pin be the the clock output and
1:02:42one pin be the clock input. Usually you
1:02:45want it set up like this where you're
1:02:47using the same pin for both of those. If
1:02:50you did this, you'd have to connect them
1:02:51together outside of the chip. Um the
1:02:55only reason I can really think of them
1:02:56doing this is because this USIC is
1:02:59designed to work for all kinds of
1:03:00different protocols.
1:03:03Sometimes like this clock could be used
1:03:06for a spy clock and that only needs to
1:03:08be an output, right? So they might have
1:03:11some pins that are only designed to be
1:03:13clock outputs. So that's why you can set
1:03:15it up like this.
1:03:19Make sense so far?
1:03:23All right. To summarize,
1:03:26pros and cons. I squared C. It's really
1:03:29easy to wire up. Just two wires plus
1:03:31ground. Uh it's widely supported in
1:03:34industry. Um the cons the open
1:03:38collector. So that that end MOSS it
1:03:41could make debugging a little bit
1:03:43harder. We don't know which device is
1:03:44pulling the line low. It could be either
1:03:46of them. So it might be a little bit
1:03:47harder to debug what's going on there.
1:03:50We have that speed power tradeoff. So
1:03:53when we decrease those resistor values,
1:03:56that means there's going to be more
1:03:57current going through those resistors
1:03:59and therefore they're going to be
1:04:00dissipating more heat, more power. So
1:04:03the faster we go, the more power we use.
1:04:07Um, and that that max speed is
1:04:09determined by kind of the hardware, the
1:04:11resistors, the parasitic capacitance.
1:04:14That's going to define how fast we can
1:04:15actually go. And there's no hardware
1:04:18arbitration. It's kind of a pro and a
1:04:20con. We don't need more wires.
1:04:22Um but what we have to do is for every
1:04:26transaction we have to send an address
1:04:29before we send data. Okay. And that adds
1:04:31some overhead to each transaction. So I
1:04:33really need to send two bytes every time
1:04:36I want to send one. Okay. So that could
1:04:38be a potential downside where with UART
1:04:41and spy I can just send the data
1:04:43whenever I want. I don't have to have
1:04:45that address phase as part of the
1:04:47transaction.
1:04:51All right, that's I squared C. Yeah.
1:04:55>> In practice, how many devices do you
1:04:56have connected to an I2C bus? Like I
1:04:59know there's seven bits for addressing,
1:05:01so there could be a max of three to
1:05:03seven different devices, but in
1:05:04practice, like what do you see?
1:05:06>> Uh well, the cool thing is is we can
1:05:09just go slower and slower as we add more
1:05:11and more devices. Uh, so that
1:05:15capacitance like if I have 100 devices
1:05:17that means I got a lot of wire going on,
1:05:19right? I got a lot of space. Maybe this
1:05:21thing is spread out in a house or
1:05:24something like that. I wouldn't use I
1:05:25squared C for a house, but I suppose you
1:05:28could do it. Uh, but you're going to
1:05:30have a lot of capacitance. And so what
1:05:32that means is you have to go really
1:05:34slow. Like maybe you go one kilobit per
1:05:37second. Okay, so that's kind of you have
1:05:39to play around with it. I can't give you
1:05:41a definitive answer because it really
1:05:42depends on all all kinds of different
1:05:44variables.
1:05:46Okay. But yeah, the the limit is the
1:05:48address 128 for seven uh seven bits, but
1:05:53I can increase that to 10 bits if I want
1:05:56to add even more devices or whatever. I
1:05:59forget what the the max value is for
1:06:00address. You could increase that as
1:06:02well.
1:06:04Any other questions?
1:06:09Okay.
1:06:10So, we're going to do a quick review and
1:06:12then we're going to do a worksheet.
1:06:16All right. So, UART, we got the TX and
1:06:20the RX pin. We connect the TX to the RX
1:06:24and same going the other way around. Um,
1:06:27this is commonly used for devices that
1:06:29just need to like continuously stream
1:06:31data. Okay, we've already kind of used
1:06:33UART in lab, right? We use UART to
1:06:36transmit data from the XMC to the
1:06:38computer on the terminal.
1:06:42Often when you're playing around with
1:06:44GPS receivers, they're almost always
1:06:47going to use UART. That's kind of a
1:06:49common use case where uh GPS is used and
1:06:52that's just because the GPS is just
1:06:54continuously sending information about
1:06:56where it is. Okay, so that might be a
1:06:58good use case for UR.
1:07:01The the the thing about yard is we don't
1:07:04have a clock pin. So the two devices
1:07:06have to pre-negotiate
1:07:09what uh baud rate they're going to run
1:07:11at. So you have to kind of hardcode that
1:07:13beforehand. And that's the only way that
1:07:16they can talk to each other is if they
1:07:17know at what speed uh the data is being
1:07:20sent because there's no clock wire.
1:07:22Okay. Any questions on UR
1:07:30asynchronous clock? We need to do that
1:07:32that clock recovery where we're over
1:07:34sampling the data so that we can see
1:07:37where those edges are and can figure out
1:07:39what the clock actually is.
1:07:44Okay, spy. We got those four wires. The
1:07:48two data wires allows us to do full
1:07:50duplex. We got the clock that's sent by
1:07:53the controller. Um, anytime there's a
1:07:56transaction, the controller
1:07:57[clears throat] has to initiate that. As
1:08:00we add more and more devices, we have to
1:08:01add more and more chip selects. It's
1:08:03very similar to uh APB. If you remember
1:08:07APB, we had something called P select.
1:08:10Same idea here, right? You need an
1:08:12additional wire in order to add more
1:08:14peripherals.
1:08:16Um,
1:08:18a good way to think about them is is
1:08:19shift registers sha uh shifting data in
1:08:22and out.
1:08:24And some of the stuff is not
1:08:26standardized. So like that clocking
1:08:28stuff where we're actually clocking the
1:08:29data on the rising edge, falling edge,
1:08:31the polarity and the the phase that's
1:08:35things that our microcontroller has to
1:08:37support all of those in order to talk to
1:08:38all the different devices out there.
1:08:42And the packet size is t all of these,
1:08:44you know, packet size is typically 8
1:08:46bits, but you can play around with that
1:08:48with spy.
1:08:51Then I squared C. We got those two
1:08:53wires. We're doing open collector.
1:08:55That's where these devices are pulling
1:08:57the lines low. We need those external
1:08:59resistors which are basically doing the
1:09:02one part of this.
1:09:04Uh we have these possible addresses. So
1:09:07each peripheral is going to have its uh
1:09:09own address.
1:09:10Hopefully they're not the same,
1:09:12otherwise it'll be an issue. If you want
1:09:14to broadcast, use address zero. And
1:09:17those are the speeds for different
1:09:19resistor values.
1:09:21Okay, so here's kind of a summary
1:09:24of all of those together. And what I'm
1:09:27going to challenge you to do is make an
1:09:30even better protocol. I want a protocol
1:09:32that only uses one wire. Right? We had
1:09:35we had I squared C. It used two. That's
1:09:38too much. I only want one. Okay. So, I
1:09:41want you guys to think about with your
1:09:42your neighbor. I have a sheet here. I
1:09:45want you to think about Do we have time?
1:09:47We got 20 minutes. Um, we have 10
1:09:50minutes. Okay. So, we kind of have to
1:09:52hurry up. I'm going to [snorts] give you
1:09:545 minutes to think about
1:10:25Hello.
1:11:04I feel
1:11:26I think
1:11:45I don't
1:11:51Hallelujah.
1:12:24transmit.
1:12:55out.
1:13:12Sorry.
1:13:15[sighs]
1:13:29Sorry.
1:13:56You
1:14:07wonderful.
1:14:24Amen.
1:14:43We might
1:14:46Yeah.
1:14:56I need something.
1:15:33Oh yeah.
1:16:02All right, we got a couple more minutes.
1:16:04So, let's let's talk about how this
1:16:05might be possible. Who thinks they know
1:16:08how this can be done?
1:16:10>> Yeah. Um I know like [snorts]
1:16:15basically
1:16:18only one line
1:16:20talk at a time.
1:16:21>> Yeah. Okay. And how would the So is that
1:16:26just one device talking to one device?
1:16:28>> Yeah.
1:16:29>> Okay. [snorts] What if I wanted to talk
1:16:30to multiple devices?
1:16:34>> How would I do that?
1:16:36>> Any ideas? [clears throat]
1:16:41one way. [clears throat]
1:16:44>> What do you think?
1:16:45>> Um, you can make it like a walkie-talkie
1:16:48where you have some that that indicates
1:16:50which device should be talking and all
1:16:51the other ones can like only one device
1:16:54can communicate at one time.
1:16:56>> Okay. So, it just whenever one device
1:16:58wants to talk, it's just like, hey, I
1:17:00want to talk.
1:17:00>> Yeah.
1:17:01>> But what about I square C? How does it
1:17:03do it? Yeah.
1:17:04>> Like you can use addresses.
1:17:06>> You can use addresses. Yeah. controller.
1:17:10>> Yeah. Well, maybe maybe we could do it
1:17:12that way. Remember how we did
1:17:13arbitration of vice vers with multiple
1:17:15controllers? Maybe we can do the same
1:17:16thing.
1:17:17>> Okay. So, what can we actually do? We
1:17:20can do we can do it all with one wire.
1:17:23Um we basically are taking a hybrid
1:17:25between uh UART where we predefined the
1:17:29clock. Okay. So all the devices are
1:17:32talking at the same speed, but then
1:17:34we're also kind of using I squ C where
1:17:36we're using a single wire to talk back
1:17:38and forth. We're also using the
1:17:40functionality of I squared C where we
1:17:43have addresses and we're using addresses
1:17:45to let uh which device we're talking to
1:17:49know that we're talking to it. And we're
1:17:51going to take it one step further and
1:17:53what if I said, okay, we can do data,
1:17:55all the data we want on one line. We're
1:17:58also going to power this device with
1:18:00that one wire. So, we're going to power
1:18:02this device and send all of our data. We
1:18:05can actually do that. And so, let me
1:18:08just pull up false real quick. I know we
1:18:10just got 2 minutes.
1:18:14Um, so how would we actually do that?
1:18:18So, here is I squared Z. Here is that
1:18:22one wire interface that we made. So, we
1:18:24have that pull-up resistor. Okay, that
1:18:27is uh making sure that we can talk on
1:18:30the same wire. Okay, that's what that's
1:18:32doing there. And we can have both
1:18:35devices
1:18:37talk
1:18:38back and forth. We could do some
1:18:41addressing if we wanted. Okay, then what
1:18:45about actually powering the device? So,
1:18:47let's say I had uh for some reason I had
1:18:50like a remote sensor that was not
1:18:52connected to my PCB and I didn't want to
1:18:54run three wires to it. I just wanted to
1:18:56run two wires. So, I wanted to provide
1:18:58power, data, and ground with just two
1:19:01wires. I can do that. Since I got this
1:19:04pull-up resistor here, we got 5 volts on
1:19:08this data line. Well, we could harvest
1:19:10that that voltage and we could store the
1:19:13little capacitor here, big capacitor.
1:19:16And so while this is harvesting data,
1:19:19even though the line is going low, it's
1:19:21going low for a short amount of time,
1:19:24that capacitor still has that voltage
1:19:27there. Um, and it keeps the device on.
1:19:30Okay, so kind of a clever way to do data
1:19:33power all just one wire. It's possible.
1:19:36It's going to be kind of slow, but we
1:19:39can do it. Okay. And we took all the
1:19:40techniques that we learned from all
1:19:42those different serial uh peripherals or
1:19:44serial uh communication protocols and
1:19:48combine them all into one.
1:19:50All right, one minute. Any last
1:19:52questions?
1:19:56All right, see you on Wednesday. Thanks.

About this transcript

This page contains the full transcript of EECS 373 - Fall 2026 - Lecture 12: "Serial Buses: I2C and SPI" by Interactive Sensing and Computing Lab , generated from the public captions YouTube serves with the video. The transcript has 12,546 words across 1,819 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.