Serial communication is sending one bit at a time. That's essentially what it means. Now, in this context, and often you'll see the term serial communication used this way, serial means UART communication. UART is a specific serial protocol that we've talked about. We're going to talk about more too in the class, but it's a specific serial protocol. The term serial really is more broad than just UART, but it is often used interchangeably. Specifically, in the Arduino context, we're going to use this serial communication library. It's called serial, but it is a UART communication library. So, you should be aware of that. So, we're using UART protocol over a USB cable. UART protocol needs say three wires. One transmit, one receive, and then another one for the common ground. There are other wires you could use, but those are minimum. It sends one bit at a time in one direction or the other, or actually, it can send both directions at the same time. So, it's got two different wires. But you need those wires. So, you can connect to a microcontroller or an integrated circuit and communicate just via wires, but it is most common in bigger systems to use the USB cable itself. So, from the Arduino to the laptop when they want to communicate with each other, they communicate over the USB cable. When you're using the serial library, they are communicating using the UART protocol over the USB cable. But it wasn't originally that way. There was another cable, RS-232, that was originally made specifically for this protocol, but that's not installed in machines anymore. So, now people just do it commonly over the USB cable. So, the way you start serial communication in Arduino is you have to call this initialization function Serial.begin. Typically, you put that initialization function inside your setup because you only want it to be executed one time, you don't want it to be executed in a loop. Now, Serial.begin it can take one or two arguments. If it's one argument, that argument is the speed and if it's two arguments, then the first argument is the speed and the second is the configuration. Now, the speed is the baud rate. That means the bits per second that you're sending or the number of transitions per second on the line which is essentially the bits per second that you're sending. These are not all data bits node. So, even if you have a high baud rate, remember that the data rate is a little bit less than that because there's an overhead, there is the stop bit and a parody bit and other things that we'll talk about. But baud rate is the number of bits per second. There are certain baud rates that are common in serial. You can use anyone you want. There's certain common baud rates, like 9,600 baud is a common baud rate. Now, note that the faster the baud rate the faster the data transmission. So that sounds good. You want to transmit as fast as you can. Ninety-six hundred baud is pretty slow. Ninety-six hundred bits per second is pretty slow. But there's a limit to this because there's a synchronization that goes on between the two communicating parties. They have to be timed in sync and the synchronization fails once the baud rate gets too high. They don't synchronize well. Sometimes in practice when making an IoT device or analyzing a device, when communicating with the device at a particular baud rate, often just slowing down the baud rate will make it work. So, maybe at a high baud rate it doesn't work because they're not synchronizing well, but if I just slow it down, then they synchronize fine and everything's okay. The synchronization goes wrong because of noise errors in the wires and stuff like that, a long wire, stuff like this will cause problems. So, just slowing down the baud rate is often helpful. So, speed is first argument. You have to give that argument. The other argument is a configuration. So, this sets the properties of the communication, basically the bits that you're sending. How many data bits, how many parity bit, or are you sending a parity bit rather, how many stop bits and so on. So, there are a set of constants that are defined for that in the Arduino library. So, one thing you could call a Serial.begin 9,600 that's a common and that says okay centered at 9,600 baud rate. Now, you can also try this where you get the second argument. The second argument is a constant that is associated with some certain configuration. So, that Serial 8N1 that means, and you just have to look this up, but what that means is eight data bits, no parody, one-stop bit. Typically, we're not going to use a second argument. Not in this class because we're going to use the default. That's actually the default. We're going to use a default configuration and that's fine for us. But you can change that if you wanted to for any particular reason. Okay. So, again, with Arduino Serial communication with the library, there are several different functions that you can call. Now, the first function we already talked about is Serial.begin. You call that in the setup one time. But, there are other functions you can call to send data from the Arduino to the other device, in this case, to the laptop let's say over the USB cable. Serial.print is a very common function to call. Serial.print does basically what you would think. It sends a string and it sends it to the laptop. Let's say it's a laptop, it sends it to the laptop over the USB cable. Now, what happens when it arrives there is that the Arduino sending via serial there has to be a receiving program running on the laptop to receive the serial communication. Now, typically what we're going to do is if you look at the Arduino IDE, there's a button on there called, it's serial monitor. You click on that. It opens up a window. The window we see here. It opens up a window and it's blank. Then when the Arduino is running and when it calls Serial.print say hello, that hello is sent over the USB cable to the serial monitor running on the laptop and then that whatever text it was appears in the monitor. So, that's what we're seeing here. Now, notice that it's just saying hello, hello, hello, hello over and over. That's because, I'm not sure on the whole program, but that's because I put the Serial.print hello inside the loop function in the Arduino sketch and so it just loops and does it over and over and over. So, that's what we would expect to see. Then notice there's no carriage return after the hello. It's just hello, hello strung out after each other. If I did Serial.print line ln, it will put a carriage return after one and then each one would be on a different line, but this why I chose to do. So, this is the general idea. Now, something there about UART is that, basically UART is a protocol to send bytes, to send eight bits. These eight bits of data can be just raw data, can represent anything. Now, in this case though with Serial.print, we're generally representing strings, printable strings. Serial.print "hello" is a string, five characters. So, there are five characters that we need to send via UART over to the laptop. So, the thing is these, remember that we're sending bits, like sequences of bits, sending one bit at a time, zeros and ones. So each one of these five characters has to be represented as a sequence of zeros and ones in order to be sent via UART. The most common representation for small things like this is called ASCII code, A-S-C-I-I. So, if you google this, you'll find the ASCII code table. It's a big table and it's an eight-bit representation of most of the characters that there is an English that you want to represent on the screen. So, all the characters on your keyboard plus some more, each one of them is associated with a number, an ASCII code number. So, for instance, I happen to remember off the top my head a capital A is a 41 in ASCII. That's the only one I remember. But each one of this character is associated with a number in a big table. This number is an eight-bit number. So, what happens is when you'd call Serial.print, it says okay I've got five characters. It says H that is say it's 51. It picks a 51, represent it as an eight-bit number and sends that eight bits to the laptop, to the serial monitor. The serial monitor receives that eight bits and says, this eight bits must be ASCII code. It looks up that ASCII code number inside the table, says that's the letter H and it prints an H on the screen. That's how the data is sent and represented on the screen. So, an ASCII code is just an eight-bit code for every character that you want to display. Though that's what's actually being sent over the wires, this ASCII code representation. Now, I'm talking about ASCII. That's an eight-bit code and that's limited because if you only got eight-bit code, you can only represent 256 characters max. Now, in English that's fine. But especially when you get to like Chinese or something, you got a lot of characters and 256 will not cut it. So, you need more. Not just Chinese either, but there are other scripts, but Chinese particularly is all character-based. You got a lot of characters. Plus there are other characters besides letters, periods, and all kinds of weird characters that you might want to represent on the screen. So, 256 is not really enough. So, now people use Unicode, 16-bit character representation. But for now, we'll talk about ASCII. So, this is the idea. Each one of these characters is represented as an eight-bit number out of an ASCII table, you can google it and look at the table if you want to. Those eight bits are transmitted and then they're printed on the screen at the receiving end. They re-represented as the original character they represented and that's put on the screen. Now, that's what Serial.print does. Now, instead of using Serial.print, you might want to use Serial.write. Now, Serial.write it also sends bytes to the screen, but it sends one bite at a time. So, you remember what that Serial.print hello, you had in quotes as string H-E-L-L-O so it send five characters which means five bytes. In this case, Serial.write, you just give it one argument which is a number. That number it represents that as a byte. So, like in this case, Serial.write 42. It represents that as a number in binary, a sequence of bits and binary, eight bits. It sends those eight bits to the serial monitor. Now, the serial monitor, it receives all the bits and again it does what it did with serial print. It looks at those eight bits and says okay what ASCII character does this represent? And the ASCII character is what gets printed on the screen. So, notice even though you're doing Serial.write 42, 42 is not appearing on screen because what's happening is on the receiving end isn't taken that from 42 and interpreting that as an ASCII character and saying well, which character is represented by the number 42? It happens that it's an asterisk in this case. So, that's why we got asterisk appearing all down the screen. So, that's what Serial.write does. It sends a raw byte. You just give it the number, it interprets it as eight-bit number and it sends that and it gets represented in ASCII at the serial monitor because that's what serial monitor does.
