Are you wondering what the heck serial communication is? Maybe you've been using some functions from the Arduino serial library, like Serial.begin and Serial.print, and they kind of leave you wondering more about this serial communication thing. I mean, how does it actually work? In this lesson, you'll learn what is meant by serial communication. You'll also learn how a basic serial communication protocol actually works. Stay tuned. (gentle music) Subscribe to our YouTube channel to get more videos like this. Are you learning Arduino programming? Check out our membership program to learn the software and hardware skills, you'll need to build your own projects. You will get an all access pass to our high quality video training that covers everything from the basics of programming, like variables and control structures up to using interrupts, arrays and more. Follow the link in the description to sign up today. All right, before we start, I want to warn you that this lesson is going to be filled with tons of technical terms, probably like 572 of them or something. I know when you're new to electronics, all this crazy sounding jargon can be pretty confusing and you might think it's gonna be over your head. And it might be over your head for a while, I mean, it still might be over my head. But as you get more familiar with these terms and you see them used and explained in different ways. Over time, all this crazy sounding stuff kind of starts to sink in. I am going to do my best to explain the jargon along the way as best as I can. But just in case you miss something, you can go to the link below in the description and we'll have a chart listing all the terms that we used here and a written description about everything that you're about to learn. Okay. So what the heck is serial communication? In a nutshell, serial communication is a method of sending and receiving information, one bit at a time. Serial communication takes many different forms, just like there's many ways to communicate from one person to another. There's many ways to serially communicate from one device to another. Probably, the most familiar method of serial communication is over USB. And if you didn't know, USB stands for Universal Serial Bus. USB is a serial communication protocol and a protocol is just a way of doing something. USB is, but one of many serial communication protocols that your Arduino can use, it's also equipped to communicate using other protocols like Serial Peripheral Interface, SPI, Inter-Integrated Circuit, I2C, and TTL serial using a USART. This last method is by far the simplest method of serial communication and it's what we're gonna use as our starting point for a fundamental understanding of how serial communication works. Many microcontrollers come equipped with a simple way to communicate serially, using a USART. USART stands for Universal Synchronous/Asynchronous Receiver/Transmitter. Now, that is like one heck of a name, intimidates me a little bit, but it's actually a little more reasonable than you might think. A USART is a piece of hardware, it can be a standalone integrated circuit or built right into a microcontroller. An Arduino Uno for example, uses an ATmega328P microcontroller, which has a built-in USART. This built-in USART, which uses the receive and transmit pins on the Arduino can send bytes of data serially to a different microcontroller on the Arduino Uno board. The ATmega16U2, which is then used to handle serial communication over USB to your computer. USARTs allow us to take data in parallel from one device, convert it into a serial transmission, and then transform it back again into parallel data. Now, I wanna draw attention to the synchronous/asynchronous part of USART for a moment because for me, at least, that is like the most confusing sounding thing ever. When serial communication protocols are synchronous, for example, with I2C and SPI, they use a clock signal for synchronizing the transmission of data from the sender to the receiver. The clock signal is what actively keeps the two in unison. With an asynchronous protocol, there is no clock signal to synchronize the communication, which is why it requires a baud rate that the receiver and the transmitter agree upon beforehand. We're gonna be talking about asynchronous protocols here, and we'll also talk more about the baud rate in just a moment. The kind of serial communication that takes place between to USARTs is sometimes referred to as TTL serial. TTL stands for Transistor-Transistor-Logic, which we won't be diving into here. It's this TTL serial communication that we will use as a basis for our discussion of serial communication. So let's get into the nitty gritty of this TTL serial communication. How does it work? Well, it's pretty cool. Each USART has a transmit and receive pin. The transmit pin of the sending device is connected to the receive pin of the receiving device and vice versa. By modulating the transmit pin state, making it a high to send a one or a low to send a zero. The sender is able to transmit a message over a connecting wire. The receiver reads the pin state at its transmit pin to determine what was sent. Serial communication protocol goes something like this. First, you send a start bit, which is gonna be low and it's basically saying, "Hey, I'm getting ready to send a message." Then you send a set number of bits, which is often eight and this is your message, which is also known as the data frame. After the data frame, you can send an optional parity bit, which is used for error checking. Finally, you send a stop bit, which is always going to be high and that saying, "Hey, the message is now complete." This is the kind of serial communication that is taking place when using the Arduino serial library, for example, with functions like Serial.begin and Serial.print. If you're not familiar with Serial.begin or Serial.print, make sure to check out the description to links to other lessons that we have on both of those topics. Do you need a printed circuit board design software to move your prototype to the next level? Altium Designer is a great choice for designing PCBs, sharing your design with team members and even getting your design manufactured. What really kind of blows me away about this software is that even though it's a super powerful tool, at the same time, it's really intuitive to use. They've got helpful video tutorials, but right into the software so you can kickstart your learning process and actually get something made. Right now you can get a free trial to Altium Designer with our link in the description. That's right, you can test drive this super powerful software with the free trial. Just check out the link in the description. All right, so let's look at a concrete example. Let's say we wanted to send the capital letter G from our Arduino to our computer and see it on the serial monitor window in the Arduino IDE. So the ASCII character capital G is represented by the bits 0100 0111. If we were to monitor the logic levels of the transmit pin on the Arduino Uno while we are printing a capital G using Serial.begin and Serial.print, it would look something like this. All right, so what is going on here? Well, the solid line represents the logic levels, you know, the high and the low, and the black dots represent the sampling times, which is set by the baud rate. The time between the two consecutive dots is the period, which is actually the inverse of the baud rate. You'll notice that at the start of the transmission, the logic level is high. This is the default logic level of the transmit pin when not sending a message. When the sender is ready to send information, it starts by bringing it's transmit pin low. This is the start bit, the receivers on the lookout for this. And when it sees the logic level go from high to low on it's receive pin, this state change tells the receiver, "Hey, a message is about to come in." The receiver based on the baud rate, then begins to read-in the message one bit at a time that is coming in at its receive pin. The receiver waits 1 1/2 cycles to start sampling after it sees the initial state change. Now, why does it wait 1 1/2 cycles? Why not just one cycle? Well, by waiting 1 1/2 cycles, it's able to sample right in the middle of the incoming signal so it can be sure what it reads is the correct signal. Say for example, that you're pounding nails into studs to hang dry wall. You wanna get your nail right in the center of the stud to get the best quality connection. The receiver wants to be right in the middle of the transmission to get the best guarantee that what it measured was the true signal. After the start bit, the receivers actually reading in the message, the message portion of the transmission is called the data frame. In this example, while we're sending the capital G, the first time it samples, the logic level is high. So if you can imagine the receiver is some guy with a clipboard, he'd be like, "Hey, okay, let me mark down a one." The next time the receiver samples, the receive pin is still high, so that's another one, another check mark. After that, it's still high, that's another one. Then it goes low, so now the receivers like, "Oh, Hey, there's a zero." Marks it down on its clipboard. And this keeps up for eight bits. You'll notice that the order of the bits in the capital G is reversed. This is because the serial protocol sends the least significant bit first. Why? Well, this is how it was done long ago, just to confuse people like me. I mean, okay, there's probably a valid reason for sending the least significant bit first, but still confusing even when you know it. After the data frame comes an optional parity bit, the default serial communication protocol for Arduino using Serial.begin does not send a parity bit, but we'll talk about it here shortly, because I think it is pretty neat. The term parity refers to whether a number is even or odd. If you asked me the parity of the number 12, the answer would be even. Having a parity bit is a way for the receiver to check if the bits it received in the data frame have been corrupted in any way, that is parity bits are for error checking. When a parity bit is used, both the sender and the receiver agree ahead of time to have either an even or an odd parity to the total number of bits with the value one in the data frame, including the parity bit. Now I know that sounds super confusing, but it is deceptively simple. All right, say for example, the sender and the receiver agreed to have an even parity, this means that all the ones in the data frame plus the parity bit need to equal an even number. So if the data frame has three ones, then the sender will set the parity bit to one as well. This way, the total number of ones is four, which has an even parity. If the receiver counts up all the ones in the transmission and finds that it doesn't match the agreed upon even parity, then it knows something has corrupted the data frame. And perhaps it can ask for that data frame again. Once the last bit is sent either the end of the data frame or the parity bit, then the sender sets its transmit pin high. This is the stop bit, the stop bit is always high and the transmit pin is going to stay high until the start of the next transmission brings it low, like we did at the beginning with the start bit. And then the communication process starts all over again. I want you to notice that the baud rate is super important here. If the sender is sending at a slow baud rate and the receiver is reading at a fast baud rate, it'd be total mayhem. The message the sender would read-in would be completely messed up. The baud rate is how many times per second the signal can change. If you set a baud rate of 9,600, that means the signal could change once every .000104166 seconds. As a quick rule of thumb to calculate how many bytes you can send per second is to divide the baud rate by the total number of bits sent in one packet, the default configuration of Serial.begin sends one start bit, eight data bits, and one stop bit, so that's a total of 10 bits. So with a baud rate of 9,600, you can expect to send 960 bytes per second. It's the baud rate that is going to tell the sender when to receive and the receiver when to sample. When using the Arduino serial library, you set the baud rate with the Serial.begin function. The baud rate is the value that goes inside the parentheses. You might be wondering what's the significance of 9,600. As you see that used as the baud rate in lots of Arduino programs. Can you change that number? Is your Arduino gonna blow up if you do? Well, the answer is yes, you can change the baud rate and your Arduino will not blow up. You just need to make sure that the baud rate on both devices are the same. So the baud rate and Serial.begin needs to be the same as the baud rate's selected on your computer. Usually, you're gonna be using the Arduino IDE and in the serial monitor window, you can select the baud rate there, they need to match. But, why 9,600? Well, there are simply conventional baud rates out there. There is no good reason not to use a faster baud rate, like say 115,200. It's just that 9,600 is pretty adequate for most serial communication done with an Arduino. Again, it's just a convention. If something is a convention, it means what everybody kind of does and expects others to do. Like, say, you're driving on a highway in the USA, you'll often see a speed limit sign of 65 miles per hour. If you're in Canada, it might be something like a 100 kilometers per hour. I mean, they could make it 63 miles per hour or 97.2 kilometers per hour. But, I mean, that just be a little weird because it doesn't follow convention. Okay, I feel like weird is a good stopping point. We've covered a lot here, so let's do a review. Serial communication works by sending one bit at a time. There are many forms of serial communication in most Arduinos come equipped to do several different kinds. One of the simplest forms of serial communication is between two USARTs and it's often referred to as TTL serial. Both the sender and the receiver need to agree on the timing of the signal, this is called the baud rate. The commonly seen baud rate of 9,600 is a convention, which means that something that people are just used to seeing. Well, hey, I hope you found this helpful. I know this was a ton of information. And if you're curious about other features of serial communication, make sure to check out our other lessons, which we have tons of. This is just the tip of the iceberg. As always have a great one and I can't wait to see you next time, bye. (gentle music)
