Up to now, we have dealt with digital and analog components. GPIO logic is much like ON/OFF switches. It is not good for exchanging complex information. Data exchange in between intelligent devices can not be done by GPIO logic. Then we dealt with sensors of analog type. Analog sensors generate voltage on output pin proportional to measured units. Reading information from them is straightforward. New generation digital sensors do a lot more than this. They accept and respond to supported commands. They can have the capability to do signal processing, data storage, analog-digital conversion, auto-calibration, and so on. They generate more information than digital HIGH/LOW or analog voltage equivalent to measured units. An example is GPS coordinates information by GPS sensor or current time information by the RTC clock. GPIO/analog logic is not enough to transfer this complex data. Besides these smart sensors, many output devices expect complex information for their work, for example, an LCD screen. So, there is a need for complex data transfer. The solution is to use the I/O bus.

In Wikipedia a bus is defined as a communication system that transfers data between components inside a computer, or between computers. A bus communication system involves physical interconnection lines between components/devices and software logic used for communication. One physical line is capable of transmitting signal representing one bit at a time. Physical interconnection in two components/devices can be done via multiple parallel data lines sending multiple bits at a time. It is called parallel bus, for example the old parallel port in a PC had eight parallel data lines. So it could transfer one byte at a time. Another physical interconnection way is to have a single physical line to transmit/receive data. It is called a serial bus. Here, one byte gets transferred when 8 bits are transmitted one after another on serial bus. This is time division multiplexing, actually. The advantage of a serial bus is that it minimizes the number of pins, lines and the size of the chip. Parallel buses lead to crosstalk and a time skewing problem when speed is increased. Therefore, many parallel standards have been dropped and serial standards have gradually been replacing them. Generic buses supported by BeagleBone are serial. So, this book only considers the serial bus. You need not to know detailed bus theory to do drive devices on these buses. You can skip theory section and jump to circuit diagrams and programs directly.

I/O devices differ among themselves widely. Some devices respond very fast. Some devices are slow in response. Some devices generate a small amount of information to be read like an accelerometer. Some devices like webcams generate a continuously big amount of information to be read. If the same software logic applied to slow and fast devices, it would hamper the speed of fast devices and would exhaust slow devices. Also, some devices expect to know the transmission speed in advance. Others transmit according to clock signals. Overall, communication with different types of devices needs different sets of rules to be followed. These sets of rules are called bus protocols. Two components/devices must follow the same protocol in order for successful communication between them, for example a USB keyboard follows USB protocol. It has an internal chip that has USB protocol software logic. When a USB keyboard is connected to a USB port, the CPU starts using the USB device driver software logic. They both follow USB protocol logic and communication happens smoothly. Bus protocols can be used to exchange information between two systems as well, for example BeagleBone and Arduino can exchange information via UART serial bus protocol when connected correctly.

For a serial bus, it is ideal to have a dedicated line to transmit and receive data between every two components/devices that are communicating with each other. In this case, data transmission can happen at any time without signal overlap. Adoption of a new device becomes difficult here. But it is not practical to have separate physical lines in between all devices. So, bus standards support sharing of physical lines between multiple devices. This new change makes a bus easily expandable to new devices. Now, there are many devices sharing the same data line, which can start transmitting data at any time. If two devices transmit data at the same time on a shared data line, then the signal gets overlapped and data is lost. So, only one device should transmit at a time. There is the need for some governing entity here to decide which device can communicate at a given time. This problem is solved by making a single hardware device the bus controller or master. Any device on the bus that starts/stops transmission according to an instruction given by the master is called a slave. The master is like traffic police. It coordinates to make sure only one device is talking at a time. A slave never initiates communication. It responds only when addressed.

For successful data transmission, there should be time coordination between the transmitter and receiver. The receiver can see only changes in signal over the time period. There should be some way for the receiver to detect individual bits from this, for example if the data line was kept HIGH for 10 milliseconds by transmitter, it is not clear if that means five bits 11111 or 10 bits 1111111111 data or it could be anything else. To solve this problem, an extra physical line for a clock signal is introduced to have all data transfer events synchronized. The clock line is shared among all devices on the bus. All the devices on the bus can read the clock line and all events start at the beginning of the clock cycle. The clock signal provides a reference signal for devices to use when exchanging data. Often, one bit of data is transferred with each clock cycle. Now, if the physical line is kept HIGH for 10 milliseconds and 5 clock cycles are completed in 10 milliseconds on the clock line, then the receiver will interpret data as five bits – 11111. The bus protocol using this solution is called synchronous bus. Another solution is to have special "start" and "stop" bits for synchronization along with each data byte. The "start" bit alerts the receiver that a new byte is coming. Internal timing units are adjusted accordingly after each byte transfer. So, even if the transmitter or receiver clock source crystal has a small time deviation, the receiver does not get out of alignment with the transmitter. The timing unit in communicating devices is still independent here. There is no common clock reference signal for synchronization. So, this type of bus solution is called an asynchronous bus. Asynchronous communication has an overhead of "start" and "stop" bits with each byte transfer. But it saves extra clock lines and pins.

There are many standard bus protocols. Most devices/sensors follow one of the standard bus protocols. The BeagleBone processor has some pins that support interfacing with popular bus devices, for example I2C, SPI, CAN and UART devices. We will cover UART, I2C and SPI in this chapter. We will need the above theory about bus to study the characteristics of these buses.