Embedded Systems Explain. i'll be explaining the fundamentals of the CAN Bus after watching this video you'll know how the CAN Bus works and you'll also be able to experiment with it this video is part of an educational series i'm doing on my channel named Embedded Systems Explained so feel videos that i have posted already or make sure to stay tuned because i'm going to post each and every weekend from now on without further due let's go over to our topic for today which is the CAN Bus so CAN or Controller Area Network is a serial communication bus which was designed to be extremely reliable and flexible because it's meant to work in environments which are really harsh such as in cars or in other industrial fields if you've heard about the OSI model which basically divides computer networks into seven layers the CAN Bus only defines two of these layers and these are going to be the physical layer and the data link layer and this allows the can bus to be optimized as a low-level high-speed network solution on the physical layer the can bus only uses one pair so two wires and these are called CAN high and CAN low and the reason they are actually twisted is because this allows for electromagnetic interference to cancel itself out because this would basically appear as noise over the signal that we are trying to transmit the way data is sent on the CAN Bus is through differential signaling and what this means is that we use both the lines both CAN high and CAN low to transmit data at the same time because what matters to us is the difference in voltage between these two lines as you can see from the graph the recessive level means that both of the lines are going to stay at around 2.5 volts so the differential voltage or the voltage difference between the two lines is going to be close to zero volts the dominant level means that the can high line goes to a higher voltage whereas the can low line goes to a lower voltage therefore creating about a 2.5 volt difference between the two lines something else that you need to keep in mind is the fact that the recessive level means a logical one and the dominant level means a logical zero the robustness of the can bus actually comes from the fact that it works as a differential pair because this means that it can also work if one of the wires is shorted to ground or is not connected it can basically work with one line only but of course it's going to take a performance hit another important aspect of the physical layer of the can bus is the need for termination resistors the reason for this is that at high speeds we absolutely want to avoid reflections so at high speeds you can think of the data that is transmitted as a sort of wave that is flowing through the wire and we need to make sure that when it reaches the end it doesn't come back as a reflection these reflections happen whenever there is an impedance mismatch on the bus and because a twisted pair cable has an impedance of about 100 to 150 ohms if we don't use termination resistors we're going to end up with these reflections which of course overlap with the useful signal and are noise it's okay if you don't understand these phenomenons right now they do require you to understand a little bit of high frequency techniques all you really need to know is the fact that you need to use 120 ohm resistors as terminators because this is what the standard requires just a quick fun fact every car made since around the beginning of the century has something called an obd2 port or an onboard diagnostics port which basically works through the can bus and allows you or your mechanic to read every parameter of your engine or other useful information about your car moving on to the data link here we have the structure for a CAN message which is made out of the following parts start of frame arbitration field control field data field crc or cyclic redundancy check acknowledge field enf of frame and then also an intermission field now let's talk about each of these and start with the starter frame which marks the beginning of a new message and allows all of the nodes on the bus to synchronize the arbitration field contains an 11 bit identifier for the message and also an rtr or remote transmission request bit which is dominant when we are requesting information from another node unlike SPI or I2C where we would have a different line or an address to actually signal which device we are talking to this sort of concept doesn't exist with the can bus because each and every message is being broadcast on the entire network what we do have though is the 11 bit message identifier which although is not meant for this purpose is actually used as a sort of topic which allows nodes to ignore messages if they're not interested in that particular topic the real reason for this 11-bit id is to actually allow for collision avoidance so in a system like the CAN Bus this is used to control which device gets to send their message when multiple nodes decide to initiate a communication at the same time the way this mechanism works is that each node is allowed to start a communication only when they sense that the line is idle but what happens when two nodes see that the line is idle and they both decide to start communicating at the same time this is actually where the arbitration field comes in because whenever a node transmits something they are also monitoring the line and this is because if they are pushing out a recessive level and they sense a dominant level present they are going to give up transmitting this is because messages which have a dominant level earlier in the arbitration field have priority over the others this also means that no time is wasted with the arbitration because if a node senses that they have to give up transmitting the message now they're going to try transmitting it as soon as the line becomes idle again which means a recessive level on the line let's try and visualize this by taking a look at the arbitration field of two different messages sent by two different nodes and this is basically going to be in binary so the first bit of both node one and node two is going to be one which is a recessive level and the second bit is going to be one for the first note and zero or the dominant level for the second note and at this point when the first note scans the line they're going to see a dominant level and they are going to give up transmission basically becoming a receiver at this point and this is actually why you see all of those dashes it means that the first note just gave up they're not going to transmit anything anymore until the second node finishes their transmission the conclusion we can draw from this is that messages with an arbitration field which has a lower value are going to be of higher priority moving on to the control field this contains an IDE or identifier extension which basically tells us if this message is a standard can bus message or an extended one then we have r0 which is reserved for future development and then we have DLC or data length code which is half of a byte and it signals how many data bytes are going to follow the data frame is pretty straightforward this only has 0 to 8 bytes of data depending on how many were actually specified in the data length code the CRC or cyclic redundancy check is a very reliable way to detect errors and is much more fail proof than something as basic as a simple checksum the acknowledge bit is a recessive bit which is part of the structure of the message because it allows for receiving notes to actually confirm that they received an error free message the way this works is that the receiving nodes would actually verify the cyclic redundancy check and check for any other errors and if there are no errors they would overwrite this recessive level bit with a dominant bit if an error has been detected this recessive level bit will not be overwritten and the transmitter will know that they have to send the message again the end of frame part is a 7 bit field which signals the end of the can frame and it also disables bit stuffing which i will explain in just a moment the inter frame space is just a 7 bit field which is used as a delay so that receiving nodes can move the information they just received to a separate buffer for further processing so the can bus does a bunch of things under the hood to ensure an error-free transmission of the messages and there are actually five mechanisms at work to accomplish this two at the bit level and three at the message level at the bit level we have bit monitoring and bit stuffing and what bit monitoring is is that each transmitter monitors the line while they're transmitting to see if there's no error and if there's an error they're going to signal it this same mechanism is also used during the arbitration phase and when a CAN node is looking to see if the line is idle so that they know if they have the possibility to start a transmission right now bit stuffing involves adding a six bit of the opposite level if five bits of the same level are sent during the message this gives the receiving nodes a chance to synchronize with the transmitter and this also means that this bit is going to be easily extracted when a receiver processes this message because it's part of the standard and each node expects this on the message level we have frame checking which means verifying if all of the parts of a can message are present and if things such as a recessive the limiter bit is present after the CRC and acknowledge field the last two mechanisms are the acknowledgement check and the CRC which we already talked about another feature of the can bus is its error confinement mechanism each node has an error receive and transmit counter and two separate thresholds before reaching these thresholds if an error occurs a node will transmit a dominant error flag after either counter reaches the first threshold only recessive error flags are going to be sent which means that they're not going to interfere with the traffic on the bus anymore after the second threshold has been reached the node is basically being shut off because it means that there's a serious error there there's also a mechanism for these counters to go down in value and this happens when a message is received or sent successfully with the counters being decremented by one on each occasion now of course the CAN Bus evolved over time so we have extended CAN but as the name implies this is just an extension so we have a 29 bit identifier and a few new fields but this is backwards compatible and of course the basics stay the same so how do you use the CAN Bus to experiment at home well there's a lot of ways but i'm going to tell you about two of them and the first one is going to involve the development board i've been recommending over the past few videos which is the msp430 G2 Launchpad and CAN transceiver boards from microchip and i've actually linked both of these in the description down below if you ordered these can transceiver boards you're actually going to get three of them so you can set up your own network at home these boards can be connected through SPI to the msp430 and i'm actually going to link a project in the description down below which actually shows you code examples of how you can get this to work of course this also works with other microcontrollers which have spi so feel free to choose whatever you wish another route you can take is to actually purchase a development board from texas instruments or from someone else which already has a can transceiver a good example for this would be the texas instruments TIVA development board the TM4C123G because these have a CAN transceiver and i've actually heard from a lot of you guys in the comment section down below that you like working with these boards of course you'll also be able to find this board linked in the description down below i hope you guys found this video useful today we talked about the physical and the data link layer of the CAN Bus we also looked at the mechanisms the CAN Bus uses to detect errors and i also explained to you how you can actually use the CANBus at home make sure to like this video and subscribe for next week's video in which i'm going to talk about registers and memory addressing again this video is part of my embedded systems explained series and if you want to check out the other videos there's going to be a link in the pinned comment in the comment section down below anyways thank you guys for watching i'll catch up with you in next week's
Tuesday 25 August 2020
5 Concepts Explained ,How To Learn Embedded Systems At Home
today's i'm going to show you just how easy and how cheap it can be to start learning embedded systems i'm going to do this by first of all talking about what an embedded system is and then actually explaining five important concepts that you need to know if you want to learn embedded development the first concept i'm going to explain is going to be gpio or general purpose input output the second one is going to be interrupts the third one is going to be timers the fourth one is going to be ADCs or analog to digital converters and the fifth one is going to be serial interfaces but first of all what is an embedded system it's basically everything you would expect a computer to have such as a processing unit memory input and output ports but it's integrated in a mechanical or an electrical system also because it usually isn't intended to run tasks that are as complex as a pc would run it mostly has limited resources and this is fairly good because it encourages the developer to use those resources wisely now before actually starting to learn embedded systems it's important to choose a platform as your starting platform so this would be a family of microcontrollers which has development boards available so you can get going really easily now there's a lot of options out there and if i were to start right now i would Probably be confused as to which one to choose you can for example go for the texas instruments msp430 microchip PIC the Atmel ATmega family or many others but personally i'm going to recommend you the texas instruments msp 430 family because it has a great selection of microcontrollers it has a great community online and also texas instruments offers a lot of Documentation and great examples for each and every microcontroller and each and every peripheral that that microcontroller has and this includes code examples and also documentation now we're going to talk about the five peripherals you need to Understand if you want to start learning embedded systems i'm not going to go into formulas or implementations i'm just going to explain to you what each and every one of these peripherals does and how they can be useful if you want to build an application the first peripheral we are going to talk about is gpio or general purpose input output and these are basically ways for your microcontroller to connect to the outer world basically just like ports on your computer but they're much simpler they can either output one of two values or read one of two of the same values and these values are logical zero which corresponds to zero volts and logical one which corresponds to usually about three to five volts which is basically the supply voltage of the microcontroller the way you would read or output the Value to and from a port which is basically just a physical pin is through registers And registers are really important if you want to understand peripherals because every time you're going to work with peripherals you're basically going to work with their registers all that registers are is location memories which are allocated to a specific peripheral so that you can actually interact with it set it up and take values from it so how would gpio be useful in a real life application well there's a lot of things that you can use these for but some simple examples could be to turn on or off an led or to signal to another system the fact that a process went through without an issue or that you have errors so you would basically output logical one if that process didn't have an ever or logical zero if there were errors within the process the second concept we are going to talk about is going to be interrupts and these come in handy when you're trying to run a block of code right after an event happens unlike polling which means you have to wait inside the loop for a condition to be met or for a flag to be set with interrupts all you have to do is write an interrupt handler which you can think of as a function that gets called right after an event happens so you're not wasting cpu cycles just waiting for an event to happen all you have to do is set the event which will trigger the interrupt and then you can go on and execute other code until the event happens as you can see in the figure that i've drawn i've set the following edge of that signal to be the source for the interrupt so whenever there's going to be a falling edge on that signal on that physical pin basically the interrupt is going to get triggered again in this example it implies that you're going to supply a signal to a physical pin to the microcontroller but this doesn't necessarily have to be a signal it can be something internal such as from another peripheral maybe it finished a process or maybe it's thrown an error or something like that it can really be a lot of things the third peripheral we are going to talk about is going to be the timer and so with the timer you can create timeouts you can count how long a process takes or you can even create a real-time clock so a timer usually counts up up and down or continuously and what counting up means is that you actually set a value in a register and the timer counts up to that value and when it reaches that value it starts over from zero count up and down on the other hand means that your timer is going to count up to that value that you just set and then it's going to start counting back down to zero and then it's going to start all over again and with count continuously it doesn't matter which value you set the timer is going to count until it Overflows so it reaches its maximum value and then it starts again from zero the maximum value a timer can count up to is going to be dependent on how many bits the timer is actually running on just for example if we have a three bit timer the maximum value it can count up to is going to be seven so this means two to the power of three minus one usually timers nowaday also includes modules named ccp or capture compare and pulse with modulation modules the capture mode allows us to time different processes and the way we do this is by supplying a signal to the module and then we can actually find the time difference between two edges of that signal this happens by saving a snapshot of the value that the timer has counted up to when the edge happened and then when the other edge happened and then it's just a matter of subtracting these two values and just converting it into time because we know the frequency with which the timer counts up the compare mode is kind of the opposite because it allows us to output pulse width modulated signals or signals where we modify the duty factor so we have a fixed frequency and then we can choose how long the logical one or logical zero lasts within one period this would for example be useful if we want to control how fast a fan spins which is basically a dc motor or if you want to control how much light and led outputs the way the compare mode works is by setting a value in a register and then the timer is going to create an edge on the output signal when the timer counts up to that value and then the other edge happens when the timer overflows the fourth peripheral is going to be the adc or the analog to digital converter and what this allows us to do is to actually work with analog inputs so if you have a voltage that you want to measure you can use this to actually get a number you can work with in software as you can see in the figure though this only works between two boundaries and so you would have a minimum and a maximum voltage and this is because you actually need to have these voltages as references and you can't surpass them you can also probably notice that this peripheral only outputs integer numbers this means that there's going to be an error between the value that you're going to input to the peripheral and the value that you get as an output this is referred to as the quantization error and it's always going to be smaller than half of the quantization step again with a three bit adc as you can see in the figure we have eight steps from zero to seven and these are going to be your outputs there's also the opposite of the adc which is a DAC or digital to analog converter and not as many microcontrollers have this peripheral but it's useful if you want to output a signal from values that you have stored in your memory the fifth and final peripheral we are going to talk about is going to be serial interfaces and these basically allow us to transmit data to other parts of our system or even to other systems today i'm going to talk about the three most basic ones but there's actually quite a lot of them out there the most basic one is going to be wart which stands for universal asynchronous receiver transmitter and it only requires two data lines though simple requires setting up the baud rate of the rate at which you're transmitting data on both systems which are going to communicate before actually initiating the communication and it also doesn't allow more than two devices to communicate at once as you can see in the explanation figure to my right you basically have a start bit followed by seven to eight data bits one parity bit if this is enabled and then a stop bit in contrast to UART SPI and I2C both allow for multiple devices to be connected to the bus and for faster speeds so SPI is the fastest out of the bunch it has two data lines and one clock line which you can think of as a synchronization line and the way you talk to multiple devices is by having one physical pin connected to each and every one of them so another line which just selects which device you're talking to the way you select the device is usually by outputting a low voltage to that pin so logical zero I2C on the other hand is slower than spi but only has two lines in total so one is for data and the other one is for clock and the way you actually select which device you're talking to is through an address so before actually sending data you're going to send the address of the device you want to talk to this of course implies that each and every device is going to have a unique address on this bus wow this turned out to be longer than I thought but i hope it was helpful for you and just so you know there's a lot of things under the hood that are going on that you're going to learn eventually but at first if you understood or are going to understand these concepts it's going to be enough to start programming easy applications the reason why i don't actually recommend arduino for beginners is because it has so many layers of software on top of the hardware that you're not really actually interacting with the hardware and that's what's most exciting when you're going to work with embedded systems later on when you understand all of these concepts and you just want to code a quick and dirty prototype you're going to be able to use arduino but in the beginning it's just really not worth it if you want to see more videos on topics like this one make sure to like this video and tell me in the comment section down below what actual topic you want to see me make a video on again in the description down below there's going to be links so that you can buy the development boards i talked about and also some documentation to get you started anyways make sure to subscribe for future content i'm going to catch up with you in the next video peace out guys peace
How SPI & I2C Work Communication Protocols
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