Embedded Systems Explained
hi everyone
this is Budi here and in today's
video i'm going to be explaining two
of the most used communication protocols out there these are going to be SPI and I2C and these are basically going to be extremely useful when trying to learn embedded systems.
why do we need
SPI and I2C though when we have UART and there's basically two drawbacks to UART which keep us from using it all the time and those are going to be the fact that it's asynchronous and then the fact that it only allows for two devices to communicate to each other so the fact that it's asynchronous means that we have to always make sure that the baud rate settings are going to be the same on both devices before
actually using them to communicate
to each other now this has sort of
been mitigated over the years because
there's automatic baud rate
detection now but not every
circuit has this feature so it's
still an issue a lot of the times
the fact that it's asynchronous
also means that we have to assure
a very high clock accuracy for both
devices communicating or otherwise
we'll end up with garbled data
simply because there's no synchronization
between the devices also this
doesn't allow us to push for very
high speeds because the clock
accuracy would be even higher so we're basically limited to about 115 kilo baudrate secondly UART is only meant for two devices and nowadays you
would like to connect multiple devices
to the same bus so only using one
peripheral on the microcontroller
and this is just something that
UART doesn't allow us to do if you're interested in learning more about UART the most basic way to communicate serially i'm going to let you know that this video is part of a series i'm doing on embedded systems and the first video i did in this series actually covers UART and
many other topics so feel free to check
out that video before watching the rest
of this one now on to the first
communication protocol we are
going to talk about today spi or serial peripheral interface is a communication protocol which allows multiple devices to talk on the same
bus thankfully both SPI and I2C went through a much needed nomenclature change as part of the black lives
matter initiative so as part of
this video i'm going to use both
the updated and the old names but
you need to know that in most
literature you're going to find the old
names so on an SPI bus there's
always going to be only one
controller who decides when a
communication happens and it also
decides which device it will communicate
to and then one or more
peripherals so the way you can
think of this is the controller
has total control over the bus and
then the peripherals need to comply
to what the controller says as far
as data lines go we have two of them and those are going to be MOSI or COPI which stands for controller out peripheral in and then we also have MISO or CIPO which stands for controller in peripheral out unlike
UART SPI is synchronous which means
we have to have a clock line between the controller and the peripherals and
this line is
called SCK again only the controller
can output a clock signal to this
line and communication only
happens when there is a clock
signal on this line what this
means is that a peripheral cannot
actually start a data transfer it
has to wait for the controller to do so
SPI is also always full duplex meaning
that when a controller sends data
to a peripheral the peripheral
needs to send data back at the
same time so this kind of works
like a shift register data comes
through one end and data is being
pushed out through the other end
when a controller asks a
peripheral to do something and then
it also expects data to be sent back what it can do is it can actually wait
a
little bit
after the first data transfer for
the peripheral to actually gather
the results and then it can
generate a few clock signals so
that the peripheral has the chance
to send that data back again the
clock signal is being generated by
the controller so the controller
needs to know how long it would
take the peripheral to actually
gather the data the way a
controller signals to which device
is talking to is through a signal
which is dedicated to each and
every peripheral and this is
called SS or CS which stands for
chip select before actually
outputting a clock signal to the
clock line so that it starts a
data transfer a controller has to actually
select which peripheral is going
to talk to usually this happens by
outputting a logical zero to the
CS line connected to the
peripheral in the schematic that
i've drawn to my right you can see
that we can share the two data lines
between all of the peripherals and
this is basically because we have
those peripheral chip selection
lines apart from this approach
which is known as the independent
peripheral approach we also have
daisy chaining in which the data
lines are connected from one peripheral
to the other so in order for a
data packet to actually get to the
last device in the daisy chain it needs to be transferred through each and every device in that chain again though the way you see things in this schematic over here is the way things happen most of the time in the real world the daisy chain approach is really not that used as far as speeds go the SPI protocol doesn't define any fixed data rates but out of the two protocols we are talking about today this one is the fastest with speeds higher than one megabit per second most of the time now to give you an idea you would mostly use SPI in scenarios where you absolutely care
about the speed but you don't have
a lot of devices to connect to the
bus such as a ram memory or any
other device that really expects a high data rate if you don't need this data rate though you have an
alternative and that alternative
is I2C or inter-integrated circuit
just like SPI I2C is a
multi-device communication
protocol with the difference being
that with I2C you can actually
have multiple controllers on one
bus there is only one data line
referred to as SDA and only one
clock line SCL both of which are
going to be high when idle this
actually represents a huge advantage
over SPI because it allows us to
have multiple devices connected to the
bus while still only having two
lines if you can remember with SPI
with each and every peripheral we would have added we would have
needed a separate chip selection
line the way a controller signals
which peripheral it intends to
communicate to is through a 7 to
10 bit address which is going to
be sent out as the first frame of
the data transfer this frame is named
address frame part of this address frame
is also a read/write bit which
tells the peripheral if we want to send
data to it or we expect data from it
the following frames are called data frames
and they each contain eight bits of
data something that is shared
between the address frame and the
data frame is the acknowledge
(ACK) or not acknowledge (NACK) bit
this bit is the last bit in the frame
and is actually the responsibility of
the receiving device so the device that
actually receives this frame has to pull
the data line low if it managed to
receive the data frame successfully
otherwise the data line would just
default to the idle state which is
logical one now in order to start
a data transfer the controller has to
generate a start condition what
this means is the fact that it has
to pull the data line low while
the clock line is still high on the opposite side if it wants to generate a stop condition it has to stop pulling the dayline low which means the data line is going to
go to the logical one level when the clock line is already high these two conditions are actually illegal during a data transfer so they can only be generated at the beginning or at the end of one during a normal data transfer the sda line is only allowed to have transitions when the clock line is low unlike UART or SPI I2C
is actually open drain which means
that devices connected to the bus can
only pull the line low the logical one idle states of both the data and the clock lines is being assured through two resistors connected between these two lines and the supply voltage these resistors connected between the I2C lines and the supply voltage are
called pull up resistors and what they
do is they allow us to pull either
line low and not cause a short
circuit between ground and the supply voltage because there is a resistor between the two one useful feature of I2C is the fact that allows slower peripherals to actually hold the clock line low while
they process the information or they
finish some other process before
actually acknowledging the frame that
they just received so they still
have to acknowledge the frame by
pulling the sda line low but that can be
delayed a little bit another
feature of I2C is the fact that it
allows for repeated start conditions
so before generating a stop condition
for a previous data transfer the
controller can actually choose to
start a new data transfer and it
could be useful in case the
controller wants to talk to a different
device all in the same go or
actually switch up between reading or writing from the same device data speeds are slower than SPI with two typical speeds being 100 kilohertz or 400 kilohertz which is still faster
than UART I2C can come in handy in a lot of scenarios where speed is not
of utmost importance such as with sensors which have some integrated logic
with slower memories or with a lot of other devices now
in the end the approach i'd suggest for
experimenting with both of these protocols
is the same as in my last video
and that is to actually pick up a development
board select a few devices you
want to talk to like sensors or
stuff like that and actually build
a project something that you're
passionate about now i can't
suggest you guys a project idea
because that's going to depend on what
you want to do but i can't
recommend you a development board
and that is going to be the MSP430 from
texas instruments and i recommended this
in the previous video as well but
i think that they provide great code examples
and they have great documentation and it allows you to code really close to the hardware which i think is really important if you want to learn embedded systems there's going to be links in the description down below to both the MSP430 development board and
a book on the MSP430 allowing you to learn
a lot more if you want to get into it
now i actually got the topic for this video
as a recommendation from the comment
section of the previous video so
if you want to recommend a topic for
the next video make sure to leave
a comment in the comment section down
below anyways i hope you learned
something new from this video make
sure to click the like button
subscribe to my channel and hit the
bell icon so you don't miss any
future videos just like i said in
the beginning this is a series so
there's going to be more videos
coming in the future regarding
embedded systems thanks again for
watching make sure to stay tuned
peace out guys peace
No comments:
Post a Comment