 |
NetBurner 3.5.8
PDF Version |
|
NetBurner 3.5.8
PDF Version |
Example Path: examples/SPI/Serial2SPI
This example demonstrates the basic configuration and use of the NetBurner DSPI driver. It tunnels data between a serial port and an SPI bus: bytes received on a secondary serial port are transmitted over SPI, the SPI response is read back, and that response is written back out the same serial port.
With a loopback jumper installed across the SPI MISO and MOSI pins (see below), the SPI bus echoes whatever is sent. The net effect is that characters typed into the secondary serial port are echoed back to the terminal – a simple, hardware-free way to exercise the SPI transmit and receive path with no external SPI device attached.
UserMain() brings up the system and network, then configures this platform's SPI pins from SpiPinConfig.h via the common SPI_CFG_*() macros.DSPIModule object is created (2 MHz, 8-bit transfers) and a semaphore is registered so the CPU can sleep while an interrupt-driven transfer runs.Start(), and the call blocks on the semaphore (Pend()) until the transfer completes. The received SPI bytes are then written back out the serial port.The example uses an interrupt-driven transfer signalled by a semaphore, which lets lower-priority tasks run during the transfer. A polled alternative (DSPIdone() in dspi.h) is described in the source comments.
This example uses the NetBurner DSPI API for SPI communication:
DSPIModule – SPI module instance (module number, baud rate, transfer size, chip select)RegisterSem() – register a semaphore signalled when a transfer completesStart() – begin an SPI transfer with TX/RX buffersOS_SEM::Pend() – block until the transfer completesStandard serial I/O (OpenSerial(), dataavail(), read(), writeall()) moves the data between the serial port and the SPI buffers.
To run the example with no external SPI device, place a jumper between the SPI MISO (data in) and MOSI (data out) pins so the bus loops transmitted data straight back. The per-platform SPI pin map lives in SpiPinConfig.h; the pins to jumper are:
| Platform | SPI peripheral | MISO (data in) | MOSI (data out) |
|---|---|---|---|
| MOD5441X | DSPI1 | J2[27] | J2[28] |
| NANO54415 | DSPI1 | Pins[33] | Pins[35] |
| MODM7AE70 | SPI0 | P2[27] | P2[28] |
| SBE70LC | SPI0 | J1[6] | J1[4] |
| SOMRT1061 | LPSPI1 | Pins[24] | Pins[25] |
| MODRT1171 | LPSPI5 | P1[45] | P1[44] |
The full SPI pin map (clock and chip select as well) is defined in SpiPinConfig.h, which also contains commented-out alternate pinouts for some boards (e.g. LPSPI1 on the MODRT1171, LPSPI2 on the SOMRT1061).
The data is tunneled on a secondary serial port, leaving the primary debug console (serial port 0) free for printf() status output. The port number and wiring vary by platform:
| Platform | Data serial port | UART | Pin configuration |
|---|---|---|---|
| MOD5441X | 1 | second UART | auto-configured by OpenSerial() (2nd DB9) |
| NANO54415 | 1 | second UART | auto-configured by OpenSerial() (2nd DB9) |
| MODM7AE70 | 1 | second UART | auto-configured by OpenSerial() (2nd DB9) |
| SBE70LC | 1 | second UART | auto-configured by OpenSerial() (2nd DB9) |
| SOMRT1061 | 2 | LPUART4 | Pin 87 = RX, Pin 88 = TX (set in UserMain()) |
| MODRT1171 | 1 | LPUART2 | P2[21] = RX, P2[22] = TX (set in UserMain()) |
On the i.MX RT parts (SOMRT1061, MODRT1171) a pin can serve many functions, so OpenSerial() does not mux the UART pins automatically. The example therefore assigns the secondary port's RX/TX pin functions explicitly before opening the port. On the ColdFire and SAME70 platforms the second UART's pins are configured automatically.
Startup status ("Serial2SPI application started") is printed on the primary debug console (serial port 0).
The Serial2SPI example can be expanded into an SPI-to-TCP bridge by creating a TCP socket file descriptor (similar to the TcpToSerial example) and using it in place of the serial file descriptor.