Tuesday 25 August 2020

Learn How The CAN Bus Works (Controller Area Network)

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

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