The Switchboard

The flow of data through a SNAP device is configured via the switchboard. This allows connections to be established between sources and sinks of data in the device.

Overview

The following data sources/sinks are defined in the file switchboard.py, which can be imported by other SNAPpy scripts. (You may also use the enumerations directly in your scripts, without importing the switchboard.py file.)

Value Enumeration
0 DS_NULL
1 DS_UART0
2 DS_UART1
3 DS_TRANSPARENT
4 DS_STDIO
5 DS_ERROR
6 DS_PACKET_SERIAL
7 DS_AUDIO (ZIC2410 only)

The SNAPpy API for creating switchboard connections is:

crossConnect(dataSrc1, dataSrc2) # Cross-connect SNAP data source (bidirectional)
uniConnect(dst, src)             # Data from src goes to dst (unidirectional)

Two uniConnect() calls can be equal to one crossConnect() call. For example:

uniConnect(DS_UART0, DS_UART1)
uniConnect(DS_UART1, DS_UART0)

Has the same effect as:

crossConnect(DS_UART0, DS_UART1)

To configure UART1 for Transparent (Wireless Serial) mode, put the following statement in your SNAPpy startup handler:

crossConnect(DS_UART1, DS_TRANSPARENT)

The following table is a matrix of possible switchboard connections. Each cell label describes the “mode” enabled by a row-column cross-connect.

  DS_UART0 DS_UART1 DS_TRANSPARENT
DS_UART0 Loopback Crossover Wireless Serial
DS_UART1 Crossover Loopback Wireless Serial
DS_TRANSPARENT Wireless Serial Wireless Serial Loopback
DS_STDIO Local Terminal Local Terminal Remote Terminal
DS_PACKET_SERIAL Packet Serial Packet Serial Remote SNAPconnect

Any given data sink can be the destination for multiple data sources, but a data source can only be connected to a single destination. Therefore, if you cross-connect two elements you cannot direct serial data from either of those elements to additionally go anywhere else, but you can still direct other elements to be routed to one of the elements specified in the cross-connect.

The DS_ERROR element is a data source, but it cannot be a data sink. Uniconnecting DS_ERROR to a destination causes any error messages generated by your program to be routed to that sink. In this way, you can (for example) route error messages to Portal while allowing other serial data to be directed to a UART.

You can configure Portal (using the preferences menu) to intercept just errors, non-error text, or both when you intercept STDIO to the application. Refer to the Portal Reference Manual.

Note

Most platforms have two UARTs available, so with most SNAP RF Modules, UART0 will connect to the USB port on an SN163 board and UART1 will connect to the RS-232 port on any appropriate Synapse demonstration board.

However, the RF300 SNAP RF Module has only one UART - UART0 - and it comes out where UART1 normally comes out (to the RS-232 port, via GPIO pins 7 through 10). If you are working with RF300 SNAP engines, be sure to adjust your code to reference UART0 rather than UART1 for your RS-232 serial connections.

Loopback

A command like crossConnect(DS_UART0, DS_UART0) will set up an automatic loopback. Incoming characters will automatically be sent back out the same interface.

Crossover

A command like crossConnect(DS_UART0, DS_UART1) will send characters received on UART0 out UART1 and characters received on UART1 out UART0.

Wireless Serial

SNAP supports efficient, reliable bridging of serial data across a wireless mesh. Data connections using the transparent mode can exist alongside RPC-based messaging.

A command like crossConnect(DS_UART0, DS_TRANSPARENT) will send characters received on UART0 over-the-air (OTA). Where the data will actually be sent is controlled by other SNAPpy built-ins.

Local Terminal

SNAPpy scripts can also interact directly with the serial ports, allowing custom serial protocols to be implemented. The SNAP device can be either the consumer or the creator of the serial data.

A command like crossConnect(DS_UART0, DS_STDIO) will send characters received on UART0 to your SNAPpy script for processing. The characters will be reported to your script via your specified HOOK_STDIN handler. Any text “printed” (using the print statement) will be sent out that same serial port.

This makes it possible to implement applications like a Command Line Interface.

Remote Terminal

SNAP’s transparent mode takes data from one interface and forwards it to another interface (possibly the radio), but the data is not altered (or even examined) in any way.

A command like crossConnect(DS_TRANSPARENT, DS_STDIO) will send characters received wirelessly to your SNAPpy script for processing. Characters “printed” by your SNAPpy script will be sent back out over-the-air.

This is often used in conjunction with a crossConnect(DS_UARTx, DS_TRANSPARENT) in some other SNAP device.

Packet Serial

A command like crossConnect(DS_UART0, DS_PACKET_SERIAL) will configure the unit to talk Synapse’s Packet Serial protocol over UART0. This enables RS-232 connection to a PC running Portal or SNAPconnect.

This also allows serial connection to another SNAP device (if the appropriate “cross-over” cable is used), which allows “bridging” of separate SNAP networks. Meaning networks that are on different channels and/or different Network IDs and/or different radio frequency ranges can communicate with each other.

A command like crossConnect(DS_UART1, DS_PACKET_SERIAL) will configure the unit to talk Synapse’s Packet Serial protocol over UART1. On some SNAP demonstration boards, one UART will be a true RS-232 serial connection, and the other will be a USB serial connection.