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
No comments:
Post a Comment