Nowadays, at the low end of the transmission protocols, I²C (for ‘Inter-Integrated Circuit’, protocol) and SPI (for ‘Serial Peripheral Interface’) are to be found. Both protocols are well-suited for transmissions betwixt unified circuits, for slow transmission with onboard components. At the essence of these two popular protocols two major companies are found – Philips for I²C and Motorola for SPI – and two diverse histories about why, when and how the protocols were generated.
The I²C bus was developed in 1982; its authentic purpose was to supply an effortless way to link a CPU to peripherals chips in a TV set. Peripheral instruments in embedded systems are frequently connected to the microcontroller as memory-mapped I/O mechanisms. One straightforward way to do this is connecting the components to the microcontroller parallel address and data busses. This results in countless wiring on the PCB (printed circuit board) and supplementary ‘glue logic’ to decode the address bus on which all the peripherals are connected. To reserve microcontroller pins, further logic and make the PCBs simpler, in order words, to lower the expenditure.
SPI is a single-master communication protocol. This means that one fundamental device initiates all the communications with the servants.
When the SPI master requests to send data to a servant and/or request information from it, it decides servant by pulling the corresponding SS line low and it triggers the clock signal at a clock frequency usable by the master and the servant. The master achieves information onto MOSI line while it fragments the MISO line.
SPI does not determine any maximum data rate, not any precise addressing pattern. It does not have an assertion mechanism to affirm receipt of data and does not offer any flow control. The SPI master has no knowledge if a servant exists unless ‘something’ supplementary is accomplished outside the SPI protocol.
For example, an easy codec will not require more than SPI, while a command-response type of control would need a higher-level protocol built on top of the SPI interface. SPI is not concerned about the physical interface traits like the I/O voltages and standard used between the machines. Initially, most SPI exercises are using a non-continuous clock and byte-by-byte scheme. But many variations of the protocol now endure, that use a continuous clock signal and an arbitrary transfer limit.
