Difference between revisions of "General SPI protocol"

From BitWizard Wiki
Jump to navigation Jump to search
(Created page with " BitWizard expansion boards communicate with SPI. SPI is a well-known synchronous protocol, but not very well standardized. Many implementations require a separate "CS" line...")
 
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:


BitWizard expansion boards communicate with SPI.
BitWizard expansion boards communicate using an SPI protocol.


SPI is a well-known synchronous protocol, but not very well standardized. Many implementations require a separate "CS" line to each chip connected to the SPI bus. The BitWizard implementation does not have this requirement. This allows us to daisy chain a large number of boards without requiring an extra pin for every board.
SPI is a well-known synchronous protocol, but not very well standardized. Many implementations require a separate "CS" line to each chip connected to the SPI bus. The BitWizard implementation does not have this requirement. This allows us to daisy chain a large number of boards without requiring an extra pin for every board.


= Timing =


The slaves use an ATTINY44 processor. These have a hardware universal serial interface (USI) module that can be configured as "SPI slave". Many things however have to be processed in software. This means that some time is required between each byte. This time is 20 microseconds. This is the time between sucessive bytes, not the dead time between bytes.
The slaves use an ATTINY44 processor. These have a hardware universal serial interface (USI) module that can be configured as "SPI slave". Many things however have to be processed in software. This means that some time is required between each byte. This time is 20 microseconds. This is the time between sucessive bytes, not the dead time between bytes.
Line 12: Line 13:


With new firmware written in assembly (or at least the interrupt handler routine) this might be improved.
With new firmware written in assembly (or at least the interrupt handler routine) this might be improved.

= Protocol =

To send a sequence of bytes to the slave SPI device, the master starts by pulling the SS line low. All slaves are now primed to receive an "address" byte. Next the master sends the address byte.

After this the protocol in theory depends on which slave you are talking to. In practice so far it is convenient to make the slaves talk a similar protocol: the next byte specifies a "register" or "port" address. After this you can send data to that port or register.

If the data can be considered a "data stream" like with the SPI_LCD board, you can call it a "port". If there is just a single value, it is more common to call it a register.

Latest revision as of 11:28, 6 November 2015

BitWizard expansion boards communicate using an SPI protocol.

SPI is a well-known synchronous protocol, but not very well standardized. Many implementations require a separate "CS" line to each chip connected to the SPI bus. The BitWizard implementation does not have this requirement. This allows us to daisy chain a large number of boards without requiring an extra pin for every board.

Timing

The slaves use an ATTINY44 processor. These have a hardware universal serial interface (USI) module that can be configured as "SPI slave". Many things however have to be processed in software. This means that some time is required between each byte. This time is 20 microseconds. This is the time between sucessive bytes, not the dead time between bytes.

You can choose a clock frequency that suits you. The maximum is 2MHz. At 2MHz, transmitting one byte takes 4 mircoseconds, so a delay of 16 microseconds between bytes is required.

At 0.625MHz, transmission of a byte takes 12.8 microseconds, so a delay between bytes of only 7.2 microseconds is required.

With new firmware written in assembly (or at least the interrupt handler routine) this might be improved.

Protocol

To send a sequence of bytes to the slave SPI device, the master starts by pulling the SS line low. All slaves are now primed to receive an "address" byte. Next the master sends the address byte.

After this the protocol in theory depends on which slave you are talking to. In practice so far it is convenient to make the slaves talk a similar protocol: the next byte specifies a "register" or "port" address. After this you can send data to that port or register.

If the data can be considered a "data stream" like with the SPI_LCD board, you can call it a "port". If there is just a single value, it is more common to call it a register.