The SPI master protocol

The most data transactions are done transparently by Netzer.

But a few protocol specifiers are implemented for handling.

The protocol is slightly different for the base and the pro version.

The protocol in base version.

In this version only one SPI slave is supported which is selected with the SPI_CS pin. On startup the SPI_CS pin is automatically configured as output and is driven high (slave is deselected).

If a TCP client is connected to the serial server, any sent character starts the SPI communication. The SPI_CS pin is automatically forced low.

All characters are sent transparently to the SPI slave. Due the three wire characteristic of SPI a written value also leads to a read one which is directly sent back to the connected TCP client.

To stop a pending SPI communication the client has to sent a backslash as escaping symbol and a null character right after. This is different from the protocol until Netzer firmware version 1.3! The SPI_CS pin is driven high when the serial server receives this characters. For sending a backslash to the SPI slave the serial TCP client has to sent two backslashes. Other escaped commands are ignored by the serial server.

The protocol in pro version.

There is no dedicated CS pin in this version. All pins (except the SPI pins MOSI, MISO and CLK) can be set or reset with protocol commands. The TCP client has to ensure that the appropriate CS pin is driven low before sending data to a SPI slave. Also he must manually stop the SPI communication with setting the CS pin at the end. Configure all used CS pins as set on startup via the io websites.

For accessing the pins the GPIO IDs are used. The IDs are escaped with the backslash character. For sending a backslash to the SPI slave the serial TCP client has to sent two backslashes. Small letters clear the appropriate pin, capitals set it.

For example sets \A the IO0 pin, \a resets it. Another example is IO5 where \F sets it, and \f resets it. Ensure that the pins are configured as digital outputs.