User manual

• i2cTests.py – This is the overall I
2
C demo script
• synapse.M41T81.py – Example of interfacing to a clock/calendar chip
• synapse.CAT24C128.py – Example of interfacing to an external EEPROM
Script i2cTests.py imports the other two scripts, and exercises some of the funcons within them.
Interfacing to multi-drop RS-485 devices
Several of the SNAP Demonstraon Boards include an RS-232 serial port. The board provides the actual
connector (a DE-9, somemes referred to as a DB-9), and the actual RS-232 line driver. SNAP Engine UARTS only
provide a logic level serial interface (3 volt logic).
RS-422 and RS-485 are alternate hardware standards that can be interfaced to by using the appropriate line
driver chips. In general, the SNAP Engine does not care what kind of serial hardware it is communicang over.
Some types of mul-drop serial hardware are an excepon. For these, mulple devices are able to share a single
serial connecon by providing a special hardware signal called TXENA (transmit enable). Normally none of the
connected devices are asserng their TXENA signals. When a device wants to transmit, it first asserts TXENA.
Aer all of the characters have been shied out the serial port, the transming device deasserts TXENA so that
another device can use the connecon.
The following example of three nodes sharing a mul-drop RS-485 bus may make this clearer. You will also
noce that the TXENA signal is acve low.
Device #1 TXENA --_____----------_____------------------------------------
Device #1 TX ---CMD------------CMD-------------------------------------
Device #2 TXENA ----------_____-------------------------------------------
Device #2 TX -----------RSP--------------------------------------------
Device #3 TXENA ------------------------_____-----------------------------
Device #3 TX -------------------------RSP------------------------------
As of version 2.2, SNAP can interface to this type of hardware (SNAP can provide the needed TXENA signal). The
TXENA signal is output on the pin normally used for Clear To Send (CTS).
The funconality (meaning) of the CTS pin is controlled by the SNAPpy built-in funcon flowControl(). Refer to
the descripon of that funcon in the “SNAPpy – The API” secon of the SNAP Reference Manual.
Encryption between SNAP nodes
Communicaons between SNAP nodes are normally unencrypted. Using the SNAP Sniffer (or some other means
of monitoring radio traffic) you can clearly see the traffic passed between nodes. This can be very useful when
establishing or troubleshoong a network, but provides no protecon for your data from prying eyes. Encrypng
your network traffic provides a soluon for this. By encrypng all your communicaons, you reduce the chances
that someone can intercept your data.
SNAP nodes offer two forms of encrypon. If you have a compable firmware version loaded into your nodes,
you can configure them to use AES-128 encrypon for all their communicaons. You must have a firmware
version that enables AES-128 to be able to do this. You can determine which firmware is loaded into a node by
checking the Node Info pane for the node in Portal. Firmware that supports AES-128 encrypon will include
“AES-128” in the firmware name.
42 SNAP® Network Operang System