IS MSB SENT FIRST FOR SERIAL COMMUNICATION PROTOCOL FULL
(In cases where you might want to return a variable amount of data, you could always return one or two bytes specifying the length of the data and then have the controller retrieve the full amount.)
For example, if you send the command for "read data" to a device, you know that the device will always send you, for example, two bytes in return. In practice this isn't a problem, as SPI is generally used to talk to sensors that have a very specific command structure. This is very different than asynchronous serial, where random amounts of data can be sent in either direction at any time. Because the controller always generates the clock signal, it must know in advance when a peripheral needs to return data and how much data will be returned. Notice we said "prearranged" in the above description.
If the peripheral needs to send a response back to the controller, the controller will continue to generate a prearranged number of clock cycles, and the peripheral will put the data onto a third data line called CIPO, for "Controller In / Peripheral Out". When data is sent from the controller to a peripheral, it's sent on a data line called COPI, for "Controller Out / Peripheral In". There is always only one controller (which is almost always your microcontroller), but there can be multiple peripherals (more on this in a bit). The side that generates the clock is called the "controller", and the other side is called the "peripheral". In SPI, only one side generates the clock signal (usually called CLK or SCK for Serial ClocK). You might be thinking to yourself, self, that sounds great for one-way communications, but how do you send data back in the opposite direction? Here's where things get slightly more complicated. You can also see OSHWA's resolution here. Check out this page for more on our reasoning behind this change. SparkFun has joined with other members of OSHWA in a resolution to move away from using "Master" and "Slave" to describe signals between the controller and the peripheral. Note: You may not recognize the COPI/CIPO labels for SPI pins.
Because the clock is sent along with the data, specifying the speed isn't important, although devices will have a top speed at which they can operate (We'll discuss choosing the proper clock edge and speed in a bit). When the receiver detects that edge, it will immediately look at the data line to read the next bit (see the arrows in the below diagram). This could be the rising (low to high) or falling (high to low) edge of the clock signal the datasheet will specify which one to use. The clock is an oscillating signal that tells the receiver exactly when to sample the bits on the data line. It's a "synchronous" data bus, which means that it uses separate lines for data and a "clock" that keeps both sides in perfect sync. SPI works in a slightly different manner. If the receiver is looking at the wrong times, it will see the wrong bits. This is because the receiver is sampling the bits at very specific times (the arrows in the above diagram). And as you've probably noticed in your own projects, if both sides aren't set to the same speed, the received data will be garbage.
The lower nybble is actually 0011 = 0x3, and the upper nybble is 0101 = 0x5.)Īsynchronous serial works just fine, but has a lot of overhead in both the extra start and stop bits sent with every byte, and the complex hardware required to send and receive data. Serial protocols will often send the least significant bits first, so the smallest bit is on the far left. (By the way, if you noticed that "11001010" does not equal 0x53 in the above diagram, kudos to your attention to detail.