REFERENCE GUIDE SNAP Network Operating System ® Reference Manual for Version 2.4 © 2010-2011 Synapse, All Rights Reserved. All Synapse products are patent pending. Synapse, the Synapse logo, SNAP, and Portal are all registered trademarks of Synapse Wireless, Inc.
Table of Contents Table of Contents..................................................................................................................................... 3 1. Introduction........................................................................................................................................ 11 SNAP and SNAPpy ........................................................................................................................... 11 Portal and SNAPconnect.....................
You can use a special type of comment called a “docstring” ............................................................ 21 4. SNAPpy versus Python...................................................................................................................... 22 Modules.............................................................................................................................................. 22 Variables .................................................................................
getInfo(whichInfo) – Get specified system info........................................................................... 51 getLq() – Get the most recent Link Quality .................................................................................. 55 getMs() – Get system millisecond tick.......................................................................................... 55 getNetId() – Get the node’s Network ID ......................................................................................
sleep(mode, ticks) – Go to sleep (enter low-power mode)............................................................ 74 spiInit(cpol, cpha, isMsbFirst, isFourWire) – Setup SPI Bus..................................................... 75 spiRead(byteCount, bitsInLastByte=8) – SPI Bus Read.............................................................. 75 spiWrite(byteStr, bitsInLastByte=8) – SPI Bus Write .................................................................
ID 15 – Inter-character Timeout .................................................................................................... 97 ID 16 – Carrier Sense..................................................................................................................... 97 ID 17 – Collision Detect ................................................................................................................ 97 ID 18 – Collision Avoidance .................................................................
Scripts specific to the RF100 Platform ........................................................................................ 110 Scripts specific to the RF200 Platform ........................................................................................ 110 Scripts specific to the RF300/RF301 Platform ............................................................................ 110 Scripts specific to the Panasonic Platforms ..............................................................................
Performance Metrics.................................................................................................................... 143 California Eastern Labs ZIC2410 Chip and Module ....................................................................... 144 ZIC2410 IO Mapping .................................................................................................................. 144 Separate Analog Input Pins....................................................................................
SM700 Port Pin mappings ........................................................................................................... 185 STMicroelectronics STM32W108xB chip ...................................................................................... 186 Platform-Specific SNAPpy Functionality.................................................................................... 189 STM32W108CB Port Pin mappings............................................................................................
1. Introduction SNAP and SNAPpy The Synapse SNAP product line provides an extremely powerful and flexible platform for developing and deploying embedded wireless applications. The SNAP network operating system is the protocol spoken by all Synapse wireless nodes. The term SNAP has also evolved over time to refer generically to the entire product line. For example, we often speak of “SNAP Networks,” “SNAP Nodes,” and “SNAP Applications.” SNAP core software runs on each SNAP node.
Navigating the SNAP Documentation There are several main documents you need to be aware of: Start with an “Evaluation Kit Users Guide” Each evaluation kit comes with its own Users Guide. For example, the EK2500 kit comes with the EK2500 Evaluation Kit Users Guide (“EK2500 Guide”), and the EK2100 kit comes with the EK2100 Evaluation Kit Users Guide (“EK2100 Guide”).
• • The “End Device Quick Start Guide” The “SN171 Proto Board Quick Start Guide” (600-0001A) (600-0011C) These two documents are subsets of the “SNAP Hardware Technical Manual” and come in handy because they focus on a single board type. • The “SNAP Sniffer Users Guide” (600026-01A) Starting with Portal version 2.2.23, a “wireless sniffer” capability is included with Portal.
2. SNAP Overview SNAP is a family of software technologies that together form an integrated, end-to-end solution for wireless monitoring and control. The latest version is 2.4, which this document covers. Key features of SNAP • • • • • All devices are peers – any device can be a bridge for Portal, do mesh routing, sleep, etc. There are no “coordinators” in SNAP. SNAP implements a full mesh topology.
uploaded to SNAP devices. All SNAP devices are capable of running SNAPpy – it is the native language of RPC calls. SNAPpy Examples On installation, Portal creates a folder under “My Documents” called “Portal\snappyImages”. Several sample script files are installed here by default. These scripts are plain text files, which may be opened and edited with Portal’s built-in editor. External text editors or even full-fledged Python Integrated Development Environments (IDEs) may also be used.
Portal Script Examples On installation, Portal creates a folder under “My Documents” called “Portal”. Several sample script files are installed here by default. Feel free to copy and modify the sample scripts (the installed copies are read-only), and create your own as you build custom network applications. Be sure to make copies of the provided read-only examples. If you change the existing files to be writable, your changes to these examples will be overwritten when you install the next version of Portal.
3. SNAPpy – The Language SNAPpy is basically a subset of Python, with a few extensions to better support embedded real-time programming. Here is a quick overview of the SNAPpy language. Statements must end in a newline print "I am a statement" The # character marks the beginning of a comment print "I am a statement with a comment" # this is a comment Indentation is significant The amount of indentation is up to you (4 spaces is standard for Python) but be consistent.
Identifiers may only contain alphanumeric characters and underscores x123_percent = 99 # OK $%^ = 99 # not OK There are several types of variables a b c d e f g = = = = = = = True # Boolean False # Boolean 123 # Integer, range is -32768 to 32767 "hello" # String (1, 2, 3) # Tuple None # Python has a "None" data type startup # Function In the above example, invoking g() would be the same as directly calling startup().
then you are going to see no output at all in Portal. Because the “signatures” do not match, Portal does not invoke the displayStatus() function at all. You can change the calling SNAPpy script(s), or you can change the Portal script, but they must match.
Creating globals on the fly def newGlobal(): global x # this is a global variable, even without previous declaration x = x + 1 # ERROR! - variables must be initialized before use if x > 7: # ERROR! – variables must be initialized before use pass # Note that these two statements are NOT errors if some other function # has previously initialized a value for global variable x before this # function runs.
The usual Boolean functions are supported Symbol and or not Meaning Both must be True Either can be True Boolean inversion (not True == False) Result Result Result Result = = = = True and True # Result is True True and False # Result is False False and True # Result is False False and False # Result is False Result Result Result Result = = = = True or True # Result is True True or False # Result is True False or True # Result is True False or False # Result is False Variables do have types, but they
4. SNAPpy versus Python Here are more details about SNAPpy, with emphasis on the differences between SNAPpy and Python. Modules SNAPpy supports import of user-defined as well as standard predefined Python source library modules. from module import * import module # Supported # Not supported Variables Local and Global variables are supported. On RAM-constrained devices, SNAPpy images are typically limited to 64 system globals and 64 concurrent locals.
• • • • • • long – A long is an integer with arbitrary length (potentially exceeding the range of an int). complex – A complex is a number with an imaginary component. list – A list is an ordered collection of elements. dict – A dict is an unordered collection of pairs of keyed elements. set – A set is an unordered collection of unique elements.
Scripts that do string manipulations that were written to work within the 2.0/2.1 restrictions will still work as-is. They just may be performing extra steps that are no longer needed with version 2.2 and above. Expressions SNAPpy supports all Python boolean, binary bit-wise, shifting, arithmetic, and comparison expressions – including the ternary if form.
5. SNAPpy Application Development This section outlines some of the basic issues to be considered when developing SNAP based applications. Event-Driven Programming Applications in SNAPpy often have several activities going on concurrently. How is this possible, with only one CPU on the SNAP Engine? In SNAPpy, concurrency is achieved through event-driven programming. This means that most SNAPpy functions run quickly to completion, and never “block” or “loop” waiting for something.
Hook Name HOOK_100MS HOOK_1S HOOK_STDIN HOOK_STDOUT HOOK_RPC_SENT When Parameters Invoked Called every • tick – A rolling 16-bit integer 100 incremented every milliseconds millisecond indicating the current count on the internal clock. The same counter is used for all four timing hooks. Called every • tick – A rolling 16-bit integer second incremented every millisecond indicating the current count on the internal clock. The same counter is used for all four timing hooks.
The new way – @setHook() Immediately before the routine that you want to be invoked, put a @setHook(HOOK_xxx) where HOOK_xxx is one of the predefined HOOK codes given previously. This method is used in the samples provided above. The old way (before version 2.2) – snappyGen.setHook() This method still works in the current version, but most people find the new way much easier to remember and use.
0= 1= 2= 3= 4= 5= 6= DS_NULL DS_UART0 DS_UART1 DS_TRANSPARENT DS_STDIO DS_ERROR DS_PACKET_SERIAL The SNAPpy API for creating Switchboard connections is: crossConnect(dataSrc1, dataSrc2) # Cross-connect SNAP data sources (bidirectional) uniConnect(dst, src) # Connect src --> dst SNAP data sources (unidirectional) For example, to configure UART1 2 for Transparent (Wireless Serial) mode, put the following statement in your SNAPpy startup handler: crossConnect(DS_UART1, DS_TRANSPARENT) The following table i
Loopback A command like crossConnect(DS_UART0, DS_UART0) will setup 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 As mentioned previously, a command of: crossConnect(DS_UART0, DS_TRANSPARENT) will send characters received on UART0 Over The Air (OTA).
Refer to the API documentation on crossConnect() in section 7 for more details. Debugging Application development with SNAP offers an unprecedented level of interactivity in embedded programming. Using Portal you can quickly upload bits of code, test, adjust, and try again.
We want to implement a point-to-point bidirectional link We don’t want to make any changes to the original endpoints (other than cabling) This is clearly a good fit for the Transparent Mode feature of SNAPpy, but there are still choices to be made around “how will the nodes know who to talk to?” Option 1 – Two Scripts, Hardcoded Addressing A script named dataMode.py is included in the set of example scripts that ships with Portal. Because it is one of the demo scripts, it is write-protected.
With this script loaded into a node, the node’s Node Info pane should look like: Click on setOtherNode(address) in the Snappy Modules tree, and when prompted by Portal, enter the address of the other node as a quoted string (standard Python “binary hex” format). For example, if the other node is at address 12.34.56, you would enter "\x12\x34\x56" in the Portal dialog box. Do this for both nodes. On the following page is the source code to SNAPpy script dataModeNV.
def startupEvent(): """System startup code, invoked automatically (do not call this manually)""" global otherNodeAddr initUart(1, 9600) # <= put your desired baudrate here! flowControl(1, False) # <= set flow control to True or False as needed crossConnect(DS_UART1, DS_TRANSPARENT) otherNodeAddr = loadNvParam(OTHER_NODE_ADDR_ID) ucastSerial(otherNodeAddr) def setOtherNode(address): """Call this at least once, and specify the OTHER node's address""" global otherNodeAddr otherNodeAddr = address saveNvParam(OT
6. Advanced SNAPpy Topics This section describes how to use some of the more advanced features of SNAP.
For platforms other than the RF100, refer to the appropriate platform specific section in the back of this manual. Note! – These pins are only dedicated if you are actually using the CBUS functions. If not, they remain available for other functions. You will also need as many Chip Select pins as you have external CBUS devices. You can choose any available GPIO pin(s) to be your CBUS chip selects. The basic program flow becomes: 1. 2. 3. 4. 5. 6.
The SPI support routines in SNAPpy can deal with all these variations, but you will have to make sure the options you specify in your SNAPpy scripts match the settings required by your external devices. Like what was done for CBUS devices, dedicated SPI support (master emulation only) has been added to the set of SNAPpy built-in functions.
Note! – These pins are only dedicated if you are actually using the SPI functions. If not, they remain available for other functions. Also, if using three wire SPI, GPIO 14 remains available. For platforms other than the RF100, refer to the appropriate platform specific section in the back of this manual. You will also need as many Chip Select pins as you have external SPI devices. You can choose any available GPIO pin(s) to be your SPI chip selects. The basic program flow becomes: 1. 2. 3. 4. 5. 6.
Interfacing to external I2C slave devices Technically the correct name for this two-wire serial bus is Inter-IC bus or I2C, though it is sometimes written as I2C. Information on this popular two-wire hardware interface is readily available on the web; http://www.i2c-bus.org/ is one starting point you could use. In particular look for a document called “The I2C-bus and how to use it (including specifications).
For examples of using the new SNAPpy I2C functions to interface to external devices, look at the following scripts that are bundled with Portal: • • • i2cTests.py – This is the overall I2C 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 functions within them.
The functionality (meaning) of the CTS pin is controlled by the SNAPpy built-in function flowControl(). Refer to the description of that function in the “SNAPpy – The API” section of this document. Encryption between SNAP nodes Communications 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.
No encryption will be used if: • NV parameter #50 is set to a value other than 1 or 2. • NV parameter #50 is set to 1 in a node that does not have AES-128 encryption available in its firmware. • The encryption key in NV parameter #51 is invalid. When you are establishing encryption for a network of nodes, it is important that you work “from the outside in.” In other words, begin by setting up encryption in the nodes farthest from Portal and work your way in toward your nearer nodes.
to recover access to your node, the “big hammer” approach is to reload the node’s firmware, which you can also do from Portal’s Options menu. All three of these options require that you have a serial connection to the node.
7. SNAPpy – The API This section details the “built-in” functions available to all SNAPpy scripts, as well as through RPC messaging. As of version 2.2, there are over 70 of these functions implemented by the SNAP “core” firmware. These functions will first be presented in detail alphabetically. They will then be summarized, by category. Finally they will be categorized as immediate, blocking, or non-blocking.
For example, node A could invoke the following on node B: callback('showResult', 'readAdc', 0) Node “B” would invoke readAdc(0), and then remotely invoke showResult(the-actual-ADC-readinggoes-here) on node A. The callback() function is most commonly used with the rpc() function. For example: rpc(nodeB, 'callback', 'showResult', 'readAdc', 0) Basically callback() allows you to ask one node to do something, and then tell you how it turned out. This function normally returns True.
Node B would invoke readAdc(0), and then remotely invoke showResult(the-actual-ADC-readinggoes-here) on node C. The callout() function is most commonly used with the rpc() function. For example: rpc(nodeB, 'callout', nodeC, 'showResult', 'readAdc' ,0) Basically callout() allows you to have one node ask another node to do something, and then tell a third node how it turned out. This function normally returns True.
This function returns None. eraseImage() – Erase any SNAPpy image from the node This function is used by Portal and SNAPconnect as part of the script upload process, and would not normally be used by user scripts. Calling this function automatically invokes the resetVm() function first (otherwise the SNAPpy VM would still be running the script, as you erased it out from under it). This function takes no parameters, and returns None.
UNBOUND_LOCAL: Are you trying to use a variable before you put something in it? INVALID_FUNC_ARGS: Are you passing the wrong type of parameters to a function? Are you passing the wrong quantity of parameters? INVALID_SUBSCRIPT: Are you trying to access str[3] when str = 'ABC'? (When str = 'ABC', str[0] is 'A', str[1] is 'B', and str[2] is 'C') EXCEEDED_MAX_LOCAL_STACK: Do you have too many local variables? ALLOC_FAIL: Are you trying to keep too many string results? As of version 2.
characters. The CTS pin goes high (temporarily) if the RFE is “full” and cannot accept any more characters (you can keep sending characters, but they will likely be dropped). When flow control is ON (isEnabled = True) and isTxEnable is also True, the CTS pin functions as a TXENA signal. The CTS pin is normally high. It transitions low before any characters are transmitted, and remains low until they have been completely sent. Only then does the CTS pin transition back high.
SNAP Channel 0 1 2 900 MHz Chan. Range 1 – 25 5 – 29 9 – 33 Frequency Range (MHz) 902.4 – 912.0 904.0 – 913.6 905.6 – 915.2 SNAP Channel 8 9 10 3 13 – 37 907.2 – 917.0 11 4 17 – 41 908.8 – 918.4 12 5 21 – 45 910.4 – 920.0 13 6 25 – 49 912.0 – 921.6 14 7 29 – 53 913.6 – 923.2 15 900 MHz Chan. Range 33 – 57 37 – 61 41 – 64, 1 45 – 64, 1–5 49 – 64, 1–9 53 – 64, 1 – 13 57 – 64, 1 – 17 61 – 64, 1 – 21 Frequency Range (MHz) 915.2 – 924.8 916.8 – 926.4 918.4 – 927.6, 902.4 920.0 – 927.
If you need an energy reading for a SNAP channel on a platform with 900 MHz frequency-hopping firmware, you could use a function like this to retrieve an average value of the appropriate frequencies: def GetEnergy(): if getInfo(2) == 6 and getInfo(1) == 5: # RF300, or compatible hardware, running FHSS incomingChannel = getChannel() energyLevel = 0 channelLoop = 0 while channelLoop < 25: setChannel((incomingChannel * 4 + channelLoop) % 64 + 1) energyLevel += getEnergy() channelLoop += 1 setChannel(incomingCh
getInfo(whichInfo) – Get specified system info This function returns details about the platform and operating environment a script is running under.
getInfo(1) – Primary Communications Interface The Network Interface indicates the means the node uses to connect to the rest of the network. Possible Network Interface result codes for getInfo(1): 0 = 802.15.4 1 = None (Serial communications only) 2 = Reserved 3 = 868 MHz 4 = Powerline 5 = 900 MHz Frequency-Hopping (other interfaces may be supported in the future) getInfo(2) – CPU The CPU indicates the processor paired with the radio in the SNAP module.
getInfo(3) – Platform/Broad Firmware Category The Platform indicates the model of module and firmware on which SNAP is running.
getInfo(8) – Encryption The Encryption setting specifies what type of encryption is available in the module. It does not indicate what encryption (if any) is enabled for the module. Possible Encryption result codes for getInfo(8): 0 = None (no encryption support) This is deprecated. As of release 2.4, all nodes include support for the option of Basic encryption.
getInfo(14) – Route Table Size The Route Table Size value indicates how many other nodes your node can keep track of in its address book. When a node needs to talk to another node, it must ask where that node is. It will find that it can talk to the node directly, that it must communicate through another node, or that it cannot find the node at all.
getNetId() – Get the node’s Network ID The getNetId() function returns the 16-bit Network Identifier (ID) value the node is currently using. The node will only accept packets containing this ID, or a special “wildcard” value of 0xffff (the “wildcard” Network ID is used during the “find nodes” process). The Network ID and the channel are what determine which radios can communicate with each other in a wireless network.
getStat(10) – Radio Transmit Buffers This provides the number of transmit buffers processed through the radio. getStat(11) – Radio Forwarded Unicasts This provides the number of “unicast” (directly addressed RPC) packets forwarded for nodes over the radio. getStat(12) – Packet Serial Forwarded Unicasts This provides the number of “unicast” (directly addressed RPC) packets forwarded for nodes over packet serial.
i2cRead(byteStr, numToRead, retries, ignoreFirstAck) – I2C Read This function can only be used after function i2cInit() has been called. I2C devices must be addressed before data can be read out of them, so this function really does a write followed by a read. Parameter byteStr specifies whatever “addressing” bytes must be sent to the device to get it to respond. Parameter numToRead specifies how many bytes to read back from the external I2C device.
A bps value of 1 selects 115,200 bps (This large number would not fit into a SNAPpy integer, and so was treated as a special case). Usually you will set bps directly to the desired bits per second: 1200, 2400, 9600, etc. NOTE – you are not limited to “standard” baud rates. If you need 1234 bps, do it. Valid baud rates are platform-dependent. Refer to the back of this document. This is the short form of the initUart() function. Data Bits defaults to 8, Parity defaults to None, and Stop Bits defaults to 1.
lcdPlot() – LCD Support (Deprecated) Currently this function only works on the CEL ZIC2410 firmware, on evaluation boards equipped with an LCD display. As CEL is no longer manufacturing the hardware, the function is deprecated and may not be supported in future releases. The lcdPlot() function performs different tasks, depending on the parameters passed to it: Calling lcdPlot() with no parameters will trigger “LCD detection.” If an LCD is present, it will be cleared, and the function will return True.
loadNvParam(id) – Read a Configuration Parameter from NV This function reads a single parameter from the SNAP Node’s NV storage, and returns it to the caller. Parameter id specifies which parameter to read. For a full list of all the system (reserved) id values, refer to section 8. User parameters should have id values in the range 128-254. See also function saveNvParam().
mcastRpc(6, 2, 'reboot') will ask all nodes within 2 hops and belonging to group 2 (0x0002 or 0000000000000010b) or group 3 (0x0004 or 0000000000000100b) to do a reboot(). This function normally returns True. It returns False only if it was unable to attempt the Remote Procedure Call (for example, if the node is low on memory, or the RPC was too large to send). If this function returns True, it does not mean your RPC request was successfully received (SNAP multicast messages are unacknowledged).
then the previously specified handler function will be invoked with the number of the IO pin that changed state, and the pin’s new value. This function does not return a value. See also function setRate(), which controls the sampling rate of the background pin monitoring that is enabled/disabled by this function. ord(str) – Return the integer ASCII ordinal value of a character Parameter str specifies a single-character string to be converted. For example, ord('A') = 65 (0x41), and ord('2') = 50 (0x32).
peekRadio(address) – Read an internal register of the radio The peekRadio() function allows you to read any location within the radio’s memory space (which on many SNAP Engines is separate from the processor’s memory space). Parameter address specifies which memory location to read (0-65535). This function returns an integer in the range 0-255. This function is intended for advanced users only.
See for example sample SNAPpy script PWM.py. pokeRadio(address, value) – Write to an internal radio register The pokeRadio() function allows you to write to any location within the radio’s memory space. On some SNAP Engines (including the Synapse RF100 SNAP Engine), the memory space for the 802.15.4 radio is not included within the memory space for the processor. The pokeRadio() function allows you to access the internal registers of the radio hardware, regardless of how the radio is physically accessed.
Output from the print statement is enqueued to STDOUT, which can be connected to a serial port or transparent connection using the switchboard API (see the crossConnect() function). Since a limited number of output RAM buffers can be enqueued to STDOUT, a script doing lots of ‘print’ output will need to HOOK_STDOUT. This allows your script to ‘print’ more output as space becomes available.
random() – Generate a random number This function returns a random number between 0-4095. This function does not take any parameters. readAdc(channel) – Read an Analog Input pin (or reference) This function can be called to read one of the available analog input channels. Some channels correspond to external analog input pins, the internal low voltage reference, or the internal high voltage reference. Parameter channel specifies which analog input channel (platform dependent) to read.
rpc(address, function, args…) – Remote Procedure Call (RPC) Call a Remote Procedure (make a Remote Procedure Call, or RPC), using unicast messaging. A special packet will be sent to the node specified by parameter address, asking that remote node to execute the function specified by parameter function. The specified function will be invoked with the parameters specified by args, if any args are present. For example, rpc('\x12\x34\x56', 'writePin', 0, True) will ask the node at address 12.34.
def pong(): print 'got a response!' Now imagine node “B” is loaded with a script containing the following function: def ping(): rpc(rpcSourceAddr(),'pong') Node A can invoke function “ping” on node B, but it has to know node B’s address to do so: rpc(node_B_address_goes_here, 'ping') When node B receives the RPC request packet, it will invoke local function ‘ping’, which will generate the remote ‘pong’ request. Notice that node B can respond to a ‘ping’ request from any node.
See also function loadNvParam().
setChannel(channel) – Specify which channel the node is on For all SNAP devices, the setChannel() function takes a number in the 0-15 range to specify which frequency (or range of frequencies) the device should use for its communications. Refer to the description for function getChannel() for more on this topic. On 802.15.4/2.4 GHz devices, channels 0-15 correspond to 802.15.4 channel 11-26.
For a given IO pin, you should call this function once to initialize the pin before calling functions such as setPinPullup(), readPin() and monitorPin() (for input pins) or setPinSlew(), writePin() and pulsePin() (for output pins). This function does not return a value. setPinPullup(pin, isEnabled) – Control internal pull-up resistor This function should be called for each IO pin you are using as a digital input if you want the internal pull-up resistor for that pin to be enabled.
NOTE – The “encoding” for non-standard data rates may differ between radio manufacturers. This means that different radio hardware may not be able to interoperate, even if set to the same (nonstandard) rate. All radios on the same frequency range set to rate 0 will be able to interoperate. setRate(rate) – Set monitorPin() sample rate By default, the background pin sampling that is enabled/disabled by function monitorPin() takes place 10 times a second (every 100 milliseconds).
Bit (in hexadecimal) Bit Position Within Display Bit (in hexadecimal) 0x0100 0x0001 0x0200 0x0002 0x0400 0x0004 0x0800 0x0008 0x1000 0x0010 0x2000 0x0020 0x4000 0x0040 0x8000 (no effect) 0x0080 (no effect) Bit Position Within Display sleep(mode, ticks) – Go to sleep (enter low-power mode) This function puts the radio and CPU on the SNAP node into a low-power mode for a specified number of ticks. This is used to extend battery life. Parameter mode chooses from the available sleep modes.
spiInit(cpol, cpha, isMsbFirst, isFourWire) – Setup SPI Bus This function initializes the SNAP node to perform Serial Peripheral Interface (SPI) Bus interfacing. The SPI standard supports multiple options, hence the large number of parameters in spiInit(). Parameter cpol refers to Clock Polarity, and can be either True or False. Basically it specifies the level of the CLK pin between SPI exchanges. To put it another way, cpol specifies the idle clock level.
This function returns a string containing the actual bytes received. More background information on using SPI is in section 6. spiWrite(byteStr, bitsInLastByte=8) – SPI Bus Write This function can only be used after function spiInit() has been called. This function writes data to a three or four wire SPI device. If you want to write and read data simultaneously (four wire SPI only), then you should be using the bidirectional function spiXfer() instead of this one).
This function returns a byte string consisting of the bits that were shifted in (as the bits specified by parameter byteStr were shifted out). More background information on using SPI is in section 6. stdinMode(mode, echo) – Set console input options This function controls how serial data gets presented to your SNAPpy script (via the HOOK_STDIN), and how it appears to the user. Parameter mode chooses between line-at-a-time (mode = 0) or character based (mode = 1).
Parameter power specifies a transmit power level from 0-17, with 0 being the lowest power setting and 17 being the highest power setting. This function does not return a value. ucastSerial(destAddr) – Setup outbound TRANSPARENT MODE SNAP TRANSPARENT MODE is covered in section 5. When you want the outbound data to be sent to a specific node, use this function. Parameter destAddr specifies the Network Address of some other node to give the received serial characters to.
vmStat(statusCode, args…) – Invoke “status” callbacks This function is specialized for management applications (like Portal), and provides a range of control/callback functionality. Parameter statusCode controls what actions will be taken, and what data will be returned (via a tellVmStat() callback to the original node).
For VM_NET, the only parameter is the optional reply window. The reported values will be a “hiByte” containing the currently active channel (0-15), and a “data” value of the current Network ID For VM_SPACE, the only parameter is the optional reply window. The reported “data” value will be the Total Image (script) Space Available For VM_SCAN, the only parameter is the optional reply window. The reported “data” value will be a 16 character string containing the detected energy levels on all 16 channels.
writeChunk(offset, data) – Synapse Use Only This function is used by Portal and SNAPconnect as part of the script uploading process. There should be no reason for user scripts to call this function, and attempting to do so could erase or corrupt all of your SNAP firmware, requiring a firmware reload (Portal has the capability to do this). This function does not return a value.
Here are the functions again, but this time broken down by category. ADC readAdc(channel) Sample ADC on specified input channel, returns raw reading CBUS Master Emulation cbusRd(numToRead) Reads numToRead bytes from CBUS, returns string cbusWr(byteStr) Writes every byte in byteStr to the CBUS These functions are discussed in section 6 of this document.
writeChunk(ofs, str) chr(number) str(obj) int(obj) len(str) random() stdinMode(mode, echo) Write string to user-application FLASH memory Returns the character string representation of “number” Returns the string representation of obj Returns the integer representation of obj Notice that you cannot specify the base.
SPI Master Emulation spiInit(cpol, cpha, isMsbFirst, isFourWire) spiRead(byteCount, bitsInLastByte) spiWrite(byteStr, bitsInLastByte) spiXfer(byteStr, bitsInLastByte) setup for SPI, with specified Clock Polarity, Clock Phase, Bit Order, and Physical Interface receive data in from SPI – returns response string (three wire SPI only) send data out SPI – bitsInLastByte defaults to 8, can be less bidirectional SPI transfer – returns response string (four wire SPI only) These functions are discussed in section
UARTs Enable UART at specified rate (zero rate to disable) Enable UART at specified rate (zero rate to disable), data bits, parity, and stop bits Enable RTS/CTS flow control. If enabled, the CTS pin functions flowControl(uartNum, isEnabled) as a “Clear To Send” indicator flowControl(uartNum, isEnabled, isTxEnable) Enable RTS/CTS flow control. If enabled and parameter isTxEnable is True, then the CTS pin functions as a TXENA (transmit enable) signal.
Immediate Functions Most SNAPpy built-ins (when called) quickly do their job, then return. Script execution then continues with the next line of SNAPpy source code. Although technically they are blocking functions (they do not return until they have completed), because of their relatively short duration we classify them as immediate functions.
print – the textual output is generated in a blocking fashion, but the output is sent in the background. reboot() – this function schedules a reboot in approximately 200 milliseconds, then allows script execution to continue until the reboot occurs. setSegments() – the new pattern is defined immediately, but the actual periodic refresh occurs in the background.
Beware of Accidental Local Variables All SNAPpy functions can read global variables, but (as in Python) you need to use the “global” keyword in your functions if you want to write to them. count = 4 def bumpCount(): count = count + 1 …is not going to do what you want (count will still equal 4). Instead, write something like: count = 4 def bumpCount(): global count count = count + 1 Don’t Cut Yourself Off (Packet Serial) Portal talks to its “bridge” (directly connected) node using a packet serial protocol.
global sleepCountDown if sleepCountDown > 0: if sleepCountDown < 100: # timebase is 100 ms sleepCountDown = 0 sleep(mode, duration) else: sleepCountDown -= 100 Remember nodes do not have a lot of RAM SNAPpy scripts should avoid generating a flood of text output all at once (there will be no where to buffer the output). Instead, generate the composite output in small pieces (for example, one line at a time), triggering the process with the HOOK_STDOUT event.
Don’t Define Functions Twice In SNAPpy (as in Python), defining a function that already exists counts as a re-definition of that function. Other script code, that used to invoke the old function, will now be invoking the replacement function instead. Using meaningful function names will help alleviate this. There is limited dynamic memory in SNAPpy Functions that manipulate strings (concatenation, slicing, subscripting, chr()) all pull from a small pool of dynamic (reusable) string buffers.
Remember you can invoke functions remotely Writing modular code is always a good idea. As an added bonus, if you are able to break your overall script into multiple function definitions, you can remotely invoke the individual routines. This can help in determining where any problem lies. Be careful using multicast RPC invocation Realize that if you multicast an RPC call to function “foo”, all nodes in that multicast group that have a foo() function will execute theirs.
8. SNAP Node Configuration Parameters You make your SNAP nodes do completely new things by loading SNAPpy scripts into them. You can often adjust the way they do the things that are already built-in by adjusting one or more Configuration Parameters. These Configuration Parameters are stored in a section of Non-Volatile (NV) memory within the SNAP node. For this reason Configuration Parameters are also referred to as NV Parameters.
ID 3 – Network ID The 16-bit Network Identifier of the SNAP Node. The Network ID and the Channel are what determine which radios can communicate with each other in a wireless network. Radios must be set to the same channel and Network ID in order to communicate over the air. Nodes communicating over a serial link pay no attention to the channel and Network ID. Network IDs can be set to any value from 0x0000 through 0xFFFF.
ID 7 – Manufacturing Date Synapse use only. This parameter is not modified when you reset parameters to factory defaults. ID 8 – Device Name This NV Parameter lets you choose a name for the node, rather than letting it be determined by what script happened to be loaded in the node at the time Portal first detected it. If this parameter is set to None, then the first detected script name will determine the node name.
For RF100 SNAP Engines, the PA feature bit (0x10) should only be set on “RFET” units. Setting this bit on a “RFE” board will not harm the SNAP Engine, but will actually result in lower transmit power levels (a 20-40% reduction). The bit should be set for RF200 SNAP Engines, as well. The external power-down bit (0x20) should be set on units that need to power down external hardware before going to sleep, and power it back up after they awake.
Although you can request that one or both UARTs are disabled (via the Feature Bits), and you can request that there is no Packet Serial mode UART (by setting the Default UART parameter to 255), both of these user requests will be ignored unless there is also a valid SNAPpy script loaded into the unit. If the parameter is set to a value outside the range of UARTs on your module (other than 255), UART1 (UART0 on modules with only one UART) will be the default.
The maximum SNAP packet size is 123 bytes. If you set this parameter to a value greater than 123, the system will simply substitute a value of 123. If you set this parameter equal to or less than the packet header size, SNAP will construct packets with a complete header and one byte of data. Like parameters #13 and #15, larger values can result in larger (more efficient) packets, at the expense of greater latency.
was transmitting at the same time, then it will resend the multicast packet. This results in more multicast packets making it through, but again at a throughput penalty. The same criteria given for NV Parameter #16 apply to this one as well. You can try setting this parameter to True, and see if it helps your application. If not, set it back to False. ID 18 – Collision Avoidance This lets you control use of “random jitter” to try and reduce collisions. This setting defaults to True.
Discovered mesh routes timeout after a configurable period of inactivity (see #23), but this timeout sets an upper limit on how long a route will be used, even if it is being used heavily. By forcing routes to be rediscovered periodically, the nodes will use the shortest routes possible. Note that you can set this timeout to zero (which will disable it) if you know for certain that your nodes are stationary, or have some other reason for needing to avoid periodic route re-discovery.
If your nodes are geographically distributed such that they are always more than 1 hop away from their logical peers, then you can increase this parameter. Consequently, if most of your nodes are within direct radio range of each other, having this parameter at the default setting of 1 will use less radio bandwidth. If you set this parameter to zero, SNAP will make an initial attempt to talk directly to the destination node, on the assumption it is within direct radio range.
This feature was added to better supports nodes that spend most of their time “sleeping.” If a node is going to be asleep, there may be no point in it becoming part of routes for other nodes while it is (briefly) awake. This can also be useful if some nodes are externally powered, while others are battery-powered.
platform’s section at the end of this manual to determine whether this parameter applies to your platform. ID 34 through 38 – Reserved for Future Use Reserved for future Synapse use. ID 39 – Radio LQ Threshold This allows for ignoring packets with poor Link Quality. Link quality values range from a theoretical 0 (perfect signal, 0 attenuation) to a theoretical 127 (127 dBm “down”).
When a script is loaded into a node, the script is compiled for the node. At compile time the platform variable is loaded with the contents of NV parameter 41, which you can use to control which other SNAPpy modules get imported or what other code will be compiled.
encryption key. Your encryption key should be complex and difficult to guess, and it should avoid repeated characters when possible. An encryption key must be exactly 16 bytes (128 bits) long to be valid. This parameter has no effect unless NV parameter #50 is also set to enable encryption.
preamble, and all radios will scan all frequencies for transmissions rather than expecting a transmission on any particular channel. The default value is 185. ID 54 through 59 – Reserved for Future Use Reserved for future Synapse use. ID 60 – Last Version Booted (Deprecated) At one time the system tracked this to allow “test driving” a newer demo version of the firmware, even after using up the “reboots remaining” with a previous version.
ID 67 through 127 – Reserved for Future Use Reserved for future Synapse use. ID 70 – Transmit Power Limit The Transmit Power Limit is a string that specifies, channel by channel, the maximum power level that can be transmitted on each channel. The units for the setting match those for the txPwr() function, ranging from 0 through 17 (with 17 being the highest power).
9. Example SNAPpy Scripts The fastest way to get familiar with the SNAPpy scripting language is to see it in use. Portal comes with several example scripts pre-installed in the snappyImages directory. Here is a list of the scripts preinstalled with Portal 2.4, along with a short description of what each script does. Take a look at these to get ideas for your own custom scripts. You can also copy these scripts, and use them as starting points.
Script Name hardTime.py (synapse.hardTime.py) hexSupport.py (synapse.hexSupport.py) i2cTests.py ledCycling.py ledToggle.py LinkQualityRanger.py McastCounter.py NewPinWakeupTest.py nvparams.py (synapse.nvparams.py) pinWakeup.py (synapse.pinWakeup.py) platforms.py (synapse.platforms.py) protoFlasher.py protoSleepcaster.py PWM.py (synapse.PWM.py) servoControl.py sevenSegment.py snapsys.py (synapse.snapsys.py) spiTests.py switchboard.py (synapse.switchboard.
Script Name sysInfo.py Throughput.py What it does Defines some constants for the getInfo() function Can be used to benchmark packet transfer between two units Scripts Specific to I2C Script Name M41T81.py (synapse.M41T81.py) CAT24C128.py (synapse.CAT24C128.py) LIS302DL.py (synapse.LIS302DL.
Platform-Specific Scripts Scripts specific to the RF100 Platform These scripts are meant to be run on RF100 SNAP Engines (formerly known as RF Engines). Script Name What it does pinWakeupRF100.py Pin Wakeup functionality specifically for the RF100 (synapse.pinWakeupRF100.py) Engine. (Imported automatically by pinWakeup.py) RF100.py (synapse.RF100.py) Platform specific defines and enumerations for RF100 Engines. (Imported automatically by platforms.py) rf100HardTime.
Scripts specific to the Panasonic Platforms These scripts are meant to be run on the corresponding Panasonic hardware platforms. Script Name PAN4555.py What it does Defines initialization routine to drive unavailable IO pins as low outputs or pull them as high inputs. These IO pins on the chip are unavailable on the module, but must be configured for efficient sleep. PAN4555_ledCycling.py Demonstrates extra PWMs on PAN4555 PAN4555_PWM.py Controls the additional PWMs on a PAN4555 PAN4555_SE.
Scripts specific to the California Eastern Labs Platforms These scripts are meant to be run on the corresponding CEL hardware platform. Script Name pinWakeupZIC2410.py What it does Configures the “wakeup” pins on a ZIC2410. (Imported automatically by pinWakeup.py) ZIC2410_PWM.py Support routines for accessing the two pulse-width (synapse.ZIC2410_PWM.py) modulation pins on a ZIC2410. ZIC2410_SE.py Platform specific defines and enumerations for SNAP (synapse.ZIC2410_SE.
Scripts specific to the ATMEL ATmega128RFA1 Platforms These scripts are meant to be run on the corresponding ATMEL hardware platform. See also the scripts specific to the RF200, which is based on the ATmega128RFA1 chip. Demos written for the ATMEL STK600 board will also run on a Dresden “RCB” board, but then any references to “LED color” are wrong (All the LEDs are red on the “RCB” board, compared to the red/yellow/green set on the STK600). Script Name atFlasher.
Scripts specific to the SM700/MC13224 Platforms These scripts are meant to be run on the Synapse SM700 surface mount module, or the Freescale MC13224 chip on which it is based, or on a compatible board that uses one of the two. Script Name MC13224_PWM.py MC13224_ledCycling.py McastCounterSM700evb.py Page 114 of 202 What it does Demonstrates Pulse Width Modulation on the TMR0/TMR1/TMR2 pins (GPIO8-10). For an example of using this script, see MC13224_ledCycling.py.
Scripts specific to the STM32W108xB Platforms These scripts are meant to be run on the DiZiC MB851 evaluation board, or on a compatible hardware design based on the underlying STM32W108CB and STM32W108HB chips. Script Name STM32W108xB_Example1.py What it does Simple example of how to blink LEDs and read a push button input from SNAPpy. The LED and button definitions assume the script is running on a DiZiC MB851 evaluation board. STM32W108xB_GPIO.
Here is a second table listing some of the included scripts, this time organizing them by the techniques they demonstrate. This should make it easier to know which scripts to look at first. Technique Importing evalBase.
Technique Controlling a GPIO pin using writePin(), etc.
Technique The use of “device types” as generic addresses, or to make a single script behave differently on different nodes Sleeping and waking up on a button press, importing and using pinWakeup.py Knowing when a RPC call has been sent out, by using HOOK_RPC_SENT.
10. Supported Platform Details In the remainder of this document, we present some of the low-level details of each platform (physical environment) you might be writing SNAPpy scripts for. Some variations are due to differences in physical I/O (both quantity and capability). Each platform specific section starts with information about the physical pins. Other variations between platforms are due to the varying amounts of RAM available.
Each of these is detailed in the following pages.
Synapse RF100 The original SNAP platform, formerly referred to as the RF Engine®. Form factor Currently only available in the SNAP Engine form factor, the RF100 supports 19 GPIO pins (GPIO_0 to GPIO_18), each with different special abilities. GPIO pins Any of the 19 GPIO can be a digital input, or digital output. Wakeup pins Six of the 19 GPIO support a hardware “wakeup” capability; see GPIO 1, 2, 5, 6, 9 and 10.
• • 1= • • • • This mode uses less power than mode 1 You can sleep for up to 32767 ticks using this mode the radio stays awake just enough to “count down” the sleep interval Parameter ticks is in units of 1.0 seconds The timing in this mode is more accurate This mode uses more power than mode 0 You can sleep for up to 1073 ticks using this mode Timers Normally the RF100 uses timer 2 in the hardware for its system clock.
Synapse RF100 Pin Assignments Pin No. Name Description 1 GND Power Supply 2 GPIO0_TPM1CH2 GPI/O, or Timer1 Channel 2 (ex.
SNAPpy Virtual Machine Memory Usage Number of Tiny Strings: Tiny String Size: Number of Medium Strings: Medium String Size: Global Variables: Concurrent Local Variables: Maximum Call Stack Depth: 7 up to 8 characters 6 up to 62 characters 64 64 8 Platform-Specific SNAPpy Built-In Functionality Built-in function lcdPlot(): On Synapse RF100 Engines, function lcdPlot() has no effect. Built-in function pulsePin(): On Synapse RF100 Engines, negative durations are in units of approximately 1.1 microsecond.
Mode 0 uses the internal Real Time Interrupt (RTI) as a time base. It has the lowest current consumption, but the worst accuracy (+/- 30%). For sleep mode 0, each “tick” is normally 1.024 seconds. The exceptions are when you specify a negative number of ticks, as shown in the following table: “ticks” value -1 -2 -3 -4 -5 -6 -7 Actual sleep duration 8 ms 32 ms 64 ms 128 ms 256 ms 512 ms 1024 ms Specifying a negative value beyond -7 is treated as a -7. Mode 1 uses the radio as the sleep timer.
SNAP has to wait for the radio to power up. Maximum rate a SNAPpy script can toggle a GPIO pin: 1.9 kHz Keep in mind that as a general rule, SNAPpy scripts should not be looping, the 1.9 kHz rate is only attainable if the node is doing nothing else (for example, no radio or serial port communication). Maximum rate for readAdc() calls: maximum 5000 samples/second NOTE! – This measurement was taken using a script that did not actually do anything with the data.
Freescale MC1321x Chip This section applies to you if you are running SNAP on a “raw” MC1321x chip. If you are running SNAP on a Panasonic PAN4555 or PAN4561 module which is based on the MC1321x, please refer instead to one of the following sections. The MC1321x port of SNAP implements 33 “IO” pins. (Refer to the SNAP 2.2 Migration Guide if you do not understand the difference between an “IO” and a “GPIO.”) The mapping is as follows: PTA0-PTA7 are mapped to IO 0-7.
Timers Normally the MC1321x uses timer 2 in the hardware for its system clock. Feature bit 0x40 of NV Parameter 11 can be set to instruct SNAP to use timer 1 instead. This affects the availability of PWM on associated pins. Refer to the Freescale documentation for details on how to make use of this.
SNAP Protocol Memory Usage Global Buffer Pool: UART Budget: Mesh Routing Budget: RPC Budget: Radio Budget: STDOUT Budget: 12 4 4 4 4 2 SNAPpy Virtual Machine Memory Usage Number of Tiny Strings: Tiny String Size: Number of Medium Strings: Medium String Size: Global Variables: Concurrent Local Variables: Maximum Call Stack Depth: 7 up to 8 characters 6 up to 62 characters 64 64 8 Platform Specific SNAPpy Built-In Functionality and Performance Metrics Because the MC1321x chip contains essentially the same
Panasonic PAN4555 SNAP Module Because it is based on the Freescale MC1321x chip, the PAN4555 wireless module can also run SNAP. NOTE – If you are using a SNAP Engine based on the PAN4555 module, skip ahead to the next section. This section is for users putting the PAN4555 module directly down on their board. Because the hardware is not in the SNAP Engine form factor, there is no such concept as GPIO. You should write your script using plain “IO” numbering (Refer to the SNAP 2.
PAN4555 Module IO Mapping PAN4555 Module Pin Number PAN4555 Module Pin Name SNAPpy IO Number 1, 9, 17, 25, 31 GND N/A 2 PTB0 8 3 PTB1 9 4 PTB2 10 5 PTB7 15 6 VREF N/A 7 PTA7 7 8 PTA5 5 10 PTA6 6 11 PTG0/BKGD N/A 12 PTG1 31 13 PTG2 32 14 CLKO N/A 15 PTC0 16 16 PTC1 17 18 PTC5 21 19 PTC3 19 20 PTC2 18 21 PTE0 29 22 PTE1 30 23 VDDA N/A 24, 26 VCC N/A 27 RESET N/A 28 PTD6 27 29 PTD4 25 30 PTD2 24 32 EXTANT N/A SNAP Reference Man
Panasonic PAN4555 (SNAP Engine Form Factor) In addition to the existing line of Synapse RF Engines, SNAP 2.2 is also available as a SNAP Engine based on Panasonic’s PAN4555 module. Like the other SNAP Engines, this PAN4555 board has 24 pins, and supports 19 GPIO. These two types of modules are largely interchangeable.
getInfo() Differences On a getInfo(0) call, the parameter value of 0 requests a “vendor code.” On a Synapse RFE, getInfo(0) returns 0 (meaning “Synapse”). On a PAN4555, getInfo(0) returns 2 (meaning “Freescale”). On a getInfo(3) call, the parameter value of 3 requests a “platform code.” The PAN4555 returns a value of 5, indicating MC1321x (the chipset the PAN4555 is based on). SNAPpy scripts can use the getInfo() function to adapt themselves to the board they find themselves running on.
Pin Configuration of a PAN4555 in SNAP Engine Format Pins that differ from Synapse RF100 Engines are highlighted in bold. Pin No. Name Description 1 GND Power Supply 2 GPIO0_TPM1CH2 GPI/O or Timer1 Channel 2 (ex.
PAN4555 GPIO Assignments (GPIO assignments defined in PAN4555_SE.
Panasonic PAN4561 (SNAP Engine Form Factor) The PAN4561 utilizes the same core processor as the original RFE and PAN4555 (the Freescale HCS08). In fact, the PAN4561 utilizes the same MC13213 integrated IC (HCS08 plus radio front end) as the PAN4555. As such, the PAN4561 will use a firmware version designed for all modules based on the Freescale MC1321x series of chipsets. This same firmware will run on the PAN4555, PAN4561, etc.
Platform Specific Hardware Configuration Low-Noise Amplifier High-Gain Mode (HGM) => Radio Transceiver GPIO- 3: The LNA located on the PAN4561 module supports a high-gain mode. This can be enabled or disabled by using GPIO-3 of the MC1321x’s radio transceiver. HGM State GPIO‐3 Enabled High Disabled Low This GPIO pin can be read and/or controlled by using SNAP’s peekRadio() and pokeRadio() built-in functions. This pin is driven high during the startup process when SNAP Feature Bit 5 (0x20) is set.
The LNA is set to a high-gain mode and the PA is enabled by default during startup when feature bit 5 (0x20) is set and module pin 45 is tied to pin 52. Default UART remains UART1 The default UART is still designated as UART1. This is consistent with SNAP ports to other devices. I2C Emulation vs. Hardware pins The hardware I2C pins designated as SCL and SDA are assigned to GPIO pins 1 and 2 respectively. However, hardware I2C is not currently enabled within the SNAP core.
PAN4561 GPIO Assignments (GPIO assignments defined in PAN4561_SE.
Pin Functionality for the PAN4561 Module Page 140 of 202 Processor Port PAN4561 Pin SNAPpy IO Num SNAPpy GPIO PTA0/KBD0 41 0 GPIO_19 PTA1/KBD1 40 1 GPIO_20 PTA2/KBD2 39 2 GPIO_21 PTA3/KBD3 38 3 GPIO_22 PTA4/KBD4 37 4 GPIO_23 PTA5/KBD5 36 5 GPIO_6 PTA6/KBD6 35 6 GPIO_9 PTA7/KBD7 34 7 GPIO_10 PTB0/AD0 12 8 GPIO_18 PTB1/AD1 13 9 GPIO_17 PTB2/AD2 14 10 GPIO_16 PTB3/AD3 15 11 GPIO_24 PTB4/AD4 16 12 GPIO_25 PTB5/AD5 17 13 GPIO_26 PTB6/AD6 18 14 GPIO
Another view of the same data (PAN4561) PAN4561 Pin Processor Port SNAPpy IO Num SNAPpy GPIO 2 PTD4/TPM2CH1 25 GPIO_15 3 PTD5/TPM2CH2 26 GPIO_31 4 PTD6/TPM2CH3 27 GPIO_14 5 PTD7/TPM2CH4 28 GPIO_32 6 PTD2/TPM1CH2 24 GPIO_0 8 PTC0/TxD2 16 GPIO_8 9 PTC1/RxD2 17 GPIO_7 10 PTC2/SDA 18 GPIO_2 11 PTC3/SCL 19 GPIO_1 12 PTB0/AD0 8 GPIO_18 13 PTB1/AD1 9 GPIO_17 14 PTB2/AD2 10 GPIO_16 15 PTB3/AD3 11 GPIO_24 16 PTB4/AD4 12 GPIO_25 17 PTB5/AD5 13 GPIO_26 18
Pin Configuration of a PAN4561 in SNAP Engine Format Pins that differ from Synapse RF Engines are highlighted in bold. Pin No. Name Description 1 GND Power Supply 2 GPIO0_TPM1CH2 GPI/O or Timer1 Channel 2 (ex.
Vendor-specific settings: NV Parameter 64 is used on the PAN4561. Bit 0x0001 – Indicates PAN4561 module is older (Rev B) hardware, and requires special handling for I/O differences. Users should verify this bit is set to 1 for the older units, and set to 0 for the newer (Rev C) units.
California Eastern Labs ZIC2410 Chip and Module In addition to modules built on a SNAP Engine footprint, you will find SNAP running on CEL chips (ZIC2410) and modules (ZICM2410P0, without a power amplifier, and ZICM2410P2, with a power amplifier). Versions with the power amplifier require SNAP firmware version 2.2.16 or higher. See the following section for details unique to the SNAP Engine form factor. The default setting for NV parameters is to assume that the power amplifier is available.
I2C Emulation The ZIC2410 has no I2C hardware, but SNAP emulates I2C (I2C master only) in software, using the following two pins: I2C SDA is emulated using P1.3 / SNAPpy IO 11 I2C CLK is emulated using P1.4 / SNAPpy IO 12 Please refer to the CEL ZIC2410 and ZICM2410 data sheets for more information on the pinouts and capabilities of these parts. Memory Usage In the current version of ZIC2410 code, AES-128 encryption support has an impact on the amount of RAM available.
Memory Usage with AES-128 Support Here are the settings in ZIC2410 builds with AES-128 encryption support: SNAP Protocol Memory Usage: Global Buffer Pool: UART Budget: Mesh Routing Budget: RPC Budget: Radio Budget: STDOUT Budget: 16 6 6 6 6 4 SNAPpy Virtual Machine Memory Usage: Number of Tiny Strings: Tiny String Size: Number of Medium Strings: Medium String Size: Global Variables: Concurrent Local Variables: Maximum Call Stack Depth: 7 8 characters 6 62 characters 64 64 8 Platform Specific SNAPpy Func
Built-in functions peekRadio() and pokeRadio(): These functions are not necessary on the ZIC2410. The internal radio registers are in the main memory space of the ZIC2410, and can be read or written using the regular peek() and poke() functions. Built-in function pulsePin(): On the ZIC2410, negative durations are in units of approximately 1.63 microsecond. Built-in function random(): On the ZIC2410, the pseudo random number generation is done in hardware, not software.
A raw reading of 0x8000 will look like -32768 to SNAPpy. 0x8001 will be interpreted as -32767, 0xFFFE will be -2, and 0xFFFF will be -1. To compensate, you will likely need to adjust for this at the point you try to actually use the results of readAdc(10) – readAdc(19).
NOTE – The ZICM2410P2, which includes a power amplifier, requires that you have P3.2 (pin 18) and P3.3 (pin 19) pulled high (CEL recommends a 10 KΩ pull-up resistor between VCC and the pins) in order to prevent internal interrupts from waking the module prematurely when sleep modes 1 and 2 are used. For more information on the sleep modes of the ZIC2410, refer to the manufacturers data sheets. In each mode, one tick is one second. The maximum sleep duration for timed sleep on the ZIC2410 is 256 seconds.
SPI Byte Transfer Time The actual SPI transfers are done using “bit banging” in software. This was measured using a logic analyzer at 1600 µs (1.6 ms) per byte. Virtual Machine Speed SNAP 2.
California Eastern Labs ZIC2410 (SNAP Engine Form Factor) SNAP Engines based on the ZICM2410P2 are available. All the details appropriate for the chip- and module-based SNAP Modules apply to module-based SNAP Engines, with the following additions. SNAP Engines based on the ZIC2410 should not be used on the Synapse SN111 End Device board. The power-up state of the pins conflicts with the relay controls on that board.
Pin Configuration of a ZICM2410P2 in SNAP Engine Format Engine Pin No. SNAPpy IO No. 1 Name Description GND Power Supply 2 11 GPIO0_P1.3 GPIO_0 3 18 GPIO1_INT0_P3.2 GPIO_1 or interrupt 4 19 GPIO2_INT1_P3.3 GPIO_2 or interrupt 5 16 GPIO3_RXD0_UART0_P3.0 GPIO_3 or UART0 Data In 6 17 GPIO4_TXD0_UART0_P3.1 GPIO_4 or UART0 Data Out 7 21 GPIO5_CTS0_SPIDO_P3.5 GPIO_5 or UART0 CTS Output or SPI MOSI 8 20 GPIO6_RTS0_SPIDI_P3.
ATMEL ATmega128RFA1 In addition to modules built on the SNAP Engine footprint, you will find SNAP running on ATMEL chips. See the following section for details unique to the SNAP Engine form factor. IO pins The ATmega128RFA1 supports 38 IO pins. Any of the 38 IO can be a digital input, or digital output. Wakeup pins Seventeen of the 38 IO support a hardware “wakeup” capability. See IO 0-7, 8-11, 16, and 20-23.
ATmega128RFA1 Port mappings Processor Port Pin SNAPpy IO Processor Port Pin SNAPpy IO PB0 PCINT0 0 PE3 RTS0 OC3A AIN0 19 PB1 PCINT1 1 PE4 INT4 OC3B 20 PB2 PCINT2 2 PE5 INT5 OC3C 21 PB3 PCINT3 3 PE6 INT6 22 PB4 PCINT4 OC2 4 PE7 INT7 ICP3 23 2 PB5 PCINT5 OC1A 5 PF0 ADC0 I C_SCL 24 PB6 PCINT6 OC1B 6 PF1 ADC1 I2C_SDA 25 PB7 PCINT7 OC1C OC0A 7 PF2 ADC2 26 PD0 INT0 8 PF3 ADC3 27 PD1 INT1 9 PF4 ADC4 28 PD2 INT2 RXD1 10 PF5 ADC5 29 PD3 INT3 TXD1 11 PF6 ADC6 30 PD
Serial port 0 Four IO pins can optionally function as UART0. IO16 becomes RXD0 and IO17 becomes TXD0. If hardware flow control is required, IO20 becomes CTS0 and IO21 becomes RTS0. Serial port 1 Four IO pins can optionally function as UART1. IO10 becomes RXD1 and IO11 becomes TXD1. If hardware flow control is required, IO12 becomes CTS1 and IO23 becomes RTS1.
Memory Usage SNAP Protocol Memory Usage: Global Buffer Pool: UART Budget: Mesh Routing Budget: RPC Budget: Radio Budget: STDOUT Budget: 20 6 6 6 6 4 SNAPpy Virtual Machine Memory Usage: Number of Tiny Strings: Tiny String Size: Number of Medium Strings: Medium String Size: Global Variables: Concurrent Local Variables: Maximum Call Stack Depth: 14 up to 16 characters 8 up to 126 characters 64 64 8 Platform Specific SNAPpy Built-In Functionality Built-in function getInfo(): On a getInfo() call, a paramete
Built-in function pulsePin(): On the ATmega128RFA1, negative durations are in units of approximately 0.94 microsecond. Here are some requested versus measured pulse timings, taken with a logic analyzer. Requested duration -1 -2 -3 -10 -20 -30 Measured Pulse Width (µs) 0.94 1.37 1.82 4.88 9.25 13.63 Built-in function random(): On the ATmega128RFA1, the pseudo random number generation is done in hardware, not software.
23 24 25 26 27 28 29 ADC7 – ADC1 ADC0 – ADC2 ADC1 – ADC2 ADC2 – ADC2 ADC3 – ADC2 ADC4 – ADC2 ADC5 – ADC2 This function returns an integer value 0-1023 (these are 10-bit analog to digital converters). The reference voltage is 1.6 volts. Refer to the ATmega128RFA1 datasheets for more information. Built-in function setRadioRate(): On the ATmega128RFA1, setRadioRate() supports values of 0, 1, 2, and 3.
-3 -4 -5 -6 -7 66 ms 132 ms 263 ms 508 ms 1000ms 82 ms 111 ms 236 ms 486 ms 986 ms Maximum allowed sleep: 1023s Note – Do not configure the ATmega128RFA1 to wake up from an edge-triggered interrupt on INT4INT7. This will work, but the processor will not go into a very “deep” sleep, and it will continue to draw a substantial amount of current (~900µA). Built-in function getLq(): The ATmega128RFA1 supports two getLq() modes: Invoking getLq() or getLq(0) returns a signal strength in negative dBm.
Time to awaken from sleep (mode 0): < 850 microseconds Time to startup from power-on: < 250 milliseconds Maximum rate a SNAPpy script can toggle a GPIO pin: 9518 Hz In other words, each True/False cycle took 105.06 microseconds. (To change the state of a pin takes 52.56 microseconds, and each pulse requires two state changes).
Reserved Hardware On the ATmega128RFA1, SNAP uses Timer 4 and Timer 5 internally. Timer 4 provides the 1 millisecond “heartbeat” and Timer 5 is used in some sleep modes. Do not peek()/poke() these timers! The remaining timers are available for use by your scripts (for example, PWM).
Synapse RF200 SNAP Engines based on the ATmega128RFA1 are available. All the details appropriate for the chipbased SNAP Modules (see the previous section) apply to the SNAP Engine, with the following additions and exceptions. Pin numbers below refer to the pin on the SNAP Engine footprint. To reference the pins in your code, use the SNAPpy IO number from the table below. Note that the SPI and I2C locations are different on the RF200 than they are on the ATmega128RFA1.
PWM Six pins can optionally be used as Pulse Width Modulation (PWM) outputs: pins 2-4 (GPIO_0GPIO_2), pins 7 and 8 (GPIO_5 and GPIO_6), and pin 22 (GPIO_19).
Synapse SS200 Synapse also offers the SNAP Stick 200. This device, based on the ATMEL ATmega128RFA1 hardware, is a USB dongle - about the size of a thumb drive. It is designed to act as a bridge between Portal or SNAP Connect and your 802.15.4 2.4 GHz wireless network. Because it is based on the ATmega128RFA1, the SS200 has the same capabilities as the underlying hardware, relating to sleep options and radio rates. The USB dongle form factor means that only one UART is available on the SS200.
Silicon Labs Si100x In addition to RF300 and RF301 modules built on the SNAP Engine footprint, you will find SNAP running on Silicon Labs Si100x chips. (See the following section for details unique to the RF300/RF301 on the SNAP Engine form factor.) There are two versions of the Si100x firmware: One version provides frequency hopping in the 900 MHz range, and the other provides service in the 868 MHz range. Details below refer to both versions of the firmware except where explicitly specified as different.
Si100x Port mappings Processor Port Pin SNAPpy IO Processor Port Pin SNAPpy IO P0.0 ADC0 VREF 0 P2.1 ADC17 10 P0.2 ADC2 RTS0 1 P2.2 ADC18 11 P0.3 ADC3 CTS0 2 P2.3 ADC19 12 P0.4 ADC4 TXD0 3 P2.4 ADC20 13 P0.5 ADC5 RXD0 4 P2.5 ADC21 14 P0.6 ADC6 CNVSTR 5 P2.6 ADC22 15 P1.5 ADC13 SPI_SPLK 6 P2.7 C2D 16 P1.6 ADC14 SPI_MISO 7 GPIO_0 17 P1.7 ADC15 SPI_MOSI 8 ANT_A 18 11 P2.
I2 C Two IO pins can optionally function as an I2C bus. IO11 becomes SCL, and IO10 becomes SDA. Use external pull-up resistors to VCC. Resistors on the order of 10 KΩ work well.
868 MHz Channel usage: Si100x radios operating in the 868 MHz range share the same pool of three frequencies regardless of the radio channel specified. Controls within the SNAP firmware prevent communications from bleeding across channels. Carrier Sense (NV Parameter 16) and Collision Detect (NV Parameter 17): The default values for Carrier Sense (NV Parameter 16) and Collision Detect (NV Parameter 17) are disabled. (This is true for all SNAP platforms.
Built-in functions cbusRd() and cbusWr(): These functions have no effect on the Si100x. Built-in functions getEnergy() and scanEnergy(): For FHSS firmware, the getEnergy() and scanEnergy() built-in functions return the energy levels heard on the frequency you specify. (Each channel uses 25 frequencies in the 900 MHz band. In the 868 MHz band, all channels use the same three frequencies.
Built-in function readAdc() The reference voltage is 3.3 volts. In addition to the 10-bit ADC channels listed in the Port Mappings table, readAdc(27) can provide a reading of an internal temperature sensor in the module, and readAdc(28) can provide an indication of voltage supply. (readAdc(28) requires additional pokes to enable the reading. Refer to the Silicon Labs documentation for more details.) You can also choose to scale your ADC readings to 1.65 volts.
On the Si100x, zero indicates “untimed sleep.” Positive numbers indicate how long to sleep in 1.0s “ticks” (regardless of mode), and negative numbers indicate the following fractions of a second: Ticks -1 -2 -3 -4 -5 -6 -7 Sleep time 16ms 31ms 63ms 125ms 250ms 500ms 1000ms Maximum allowed sleep: 32767 seconds, or 9:06:07. Encryption The Si100x supports Basic encryption. AES-128 encryption is not available in the Si100x firmware. (It is available for RF300/RF301 firmware.
Performance Metrics Here are the results of some recent performance measurements, which may help you gauge if SNAPpy can address your application’s timing requirements. Time to awaken from sleep (mode 0): 340 ms Time to awaken from sleep (mode 1): 1.2 ms Time to startup from power-on: 677 ms Maximum rate a SNAPpy script can toggle a GPIO pin: 1149.6 Hz In other words, each True/False cycle took 869.9 µs. (To change the state of a pin takes 434.9 µs, and each pulse requires two state changes).
Reserved Hardware Timers On the Si100x, SNAP uses Timer 1 and Timer 2 internally. Timer 2 provides the 1 millisecond “heartbeat.” You should not do anything that makes explicit use of that timer. Timer 1 is used to set the UART baud rate. If you are not using a serial connection, you can use Timer 1 for your own purposes. (The real-time clock is also available to you. Initialization of the real-time clock is cumbersome, but can be automated by executing a brief timed sleep.
Synapse RF300/RF301 SNAP Engines based on the Si1000 are available. All the details appropriate for the chip-based SNAP Modules (see the previous section) apply to the SNAP Engine, with the following additions and exceptions. Pin numbers below refer to the pin on the SNAP Engine footprint. To reference the pins in your code, use the SNAPpy IO number from the table below, or import synapse.platforms into your script and refer to the pins by their GPIO number.
these pins are used for UART 1. However there is only one UART (UART 0) on any Si100x-based SNAP device. UART1 There is only one UART on the RF30x. It is UART 0, though it comes out on the pins normally used for UART 1. SPI SPI uses pins GPIO_4, GPIO_5 and GPIO_6 as MOSI, SCLK, and MISO, respectively. Additionally, you will need to define a chip select pin for each SPI device.
Pin Configuration of an Si1000 in SNAP Engine Format (RF300/RF301) Engine Pin SNAPpy IO 1 Name Description GND Power Supply 2 10 GPIO0 ADC17 P2.1 GPIO_0 or ADC17 or I2C SDA 3 11 GPIO1 ADC18 P2.2 GPIO_1 or ADC18 or I2C SCL 4 12 GPIO2 ADC19 P2.3 GPIO_2 or ADC19 5 13 GPIO3 ADC20 P2.4 GPIO_3 or ADC20 6 14 GPIO4 ADC21 P2.5 GPIO_4 or ADC21 or SPI MOSI 7 15 GPIO5 ADC22 P2.6 GPIO_5 or ADC22 or SPI SCLK 8 0 GPIO6 ADC0 P0.
Freescale MC13224 chip This section applies if you are running SNAP on a Freescale MC13224 chip in your own hardware. If you instead are running SNAP on a Synapse SM700 module, refer also to the section following this one. IO pins The MC13224 supports 64 GPIO input/output pins, referenced as GPIO_0 through CPIO_63. Wakeup pins Four pins, GPIO_26 through GPIO_29, can be configured to wake the module from sleep. Note that these pins automatically become inputs when entering sleep.
PWM Three pins support hardware PWM, refer to GPIO_8, GPIO_9, and GPIO_10 (These pins are also referred to as TMR0, TMR1, and TMR2 in the MC1322x data sheets). Serial rates 1200-65535 bps as well as 115.2Kbps (115.2Kbps is specified using a “baudrate” of 1). Network IDs The MC13224 hardware does not function properly with all network IDs. An MC13224 node set to a network ID that fits the pattern 0xn2nn or 0xnAnn will not be able to receive radio transmissions, though it can still send them.
Built-in function getInfo(): The values returned by the getInfo() function for the first four parameters vary by platform.
Built-in function poke(): The MC1233x modules use a 32-bit architecture, so the signature for the poke() function has changed to accommodate the larger address space and the potential for different value sizes being poked. The new function signature is: peek(addrHi, addrLow, word, data) with word = 0 or word = 1, or peek(addrHi, addrLow, word, dataHi, dataLow) with word = 2. The addrHi and addrLow parameters are 16-bit values.
Built-in functions readAdc(): The ADC on an MC13224 returns a 12-bit value (0x0000 to 0x0FFF, 0 to 4096), with 8 to 9 bits of precision. Most other SNAP platforms return 10-bit values from their ADCs. In order to scale these values to match, you can shift right two bits or divide by four, without any loss of precision. On an MC13224, a call to readAdc() clears any state set on a pin by the setPinDir() function to define the pin as either a digital input or output.
Built-in functions setPinPullup(): The setPinPullup() function does not apply a pull-up to GPIO_30 through GPIO_41. No internal pull-ups are available on these pins, and it is not recommended that external pull-ups be applied as they do not function well with the keepers that must be applied to those pins to allow them to function as digital inputs or outputs rather than ADCs or VREFs.
Memory Usage SNAP Protocol Memory Usage: Global Buffer Pool: 20 UART Budget: 6 Mesh Routing Budget: 6 RPC Budget: 6 Radio Budget: 6 STDOUT Budget: 4 SNAPpy Virtual Machine Memory Usage: Number of Tiny Strings: 32 Tiny String Size: up to 16 characters Number of Medium Strings: 16 Medium String Size: up to 255 characters Global Variables: 128 Concurrent Local Variables: 64 Maximum Call Stack Depth: 8 Virtual Machine Speed SNAP 2.
Synapse SM700 Surface-Mount Module The SM700 surface-mount module is based on the Freescale MC13224 chip. All the details described for the MC13224 in the previous section apply to the SM700 as well, with these exceptions and elaborations. getInfo() return values A call to built-in function getInfo(0) returns 0 (zero, meaning Synapse) on an SM700 module. Sleep The SM700 includes an external 32kHz crystal, so you should use odd-numbered sleep modes for the most accurate sleep timing.
SM700 Port Pin mappings Module Pin 1 Processor Port Pin SNAPpy IO Processor Port Pin Ground Module Pin 31 2 Ground 32 GPIO_10 17 10 3 Ground 33 GPIO_9 18 9 19 8 4 GPIO_39 ADC2_VREFL 39 34 5 GPIO_41 ADC1_VREFL 41 35 6 GPIO_40 ADC1_VREFH 40 7 GPIO_38 ADC2_VREFH 38 8 GPIO_30 ADC0 9 SNAPpy IO VCC GPIO_8 GPIO_7 SPI_SCK 7 36 GPIO_14 UART0_TX 14 37 GPIO_15 UART0_RX 15 30 38 Ground GPIO_31 ADC1 31 39 GPIO_6 SPI_MOSI 6 10 GPIO_32 ADC2 32 40 GPIO_5 SPI_MISO 5
STMicroelectronics STM32W108xB chip This section applies if you are running SNAP on a STMicroelectronics STM32W108CB or STM32W108HB chip. At the time of this writing there is no SNAP Engine or other Synapse module based on this chip. IO pins The STM32W108CB supports 24 input/output pins, referenced as IO 0 through IO 23.
Analog inputs Six pins support ADC usage. ADC 0 1 2 3 4 5 STM32W108 Signal Name PB5 PB6 PB7 PC1 PA4 PA5 SNAPpy IO 13 14 15 17 4 5 For more about using the ADC channels on this part, refer to the text on readAdc() later in this section of the document. UART Four pins support UART 0. IO 9 and IO 10 perform as TX and RX, respectively, and IO 12 and IO 21 perform as CTS and RTS, respectively. If you do not need RTS/CTS signals, then those two pins are available for other uses.
PWM Twelve pins support hardware PWM, refer to the following table. Note that there are really only 8 PWM generators on this chip, four of them have the ability to be routed to one of two different pins (only one of the two pins can be a PWM output at a time). So keep in mind there are 8 total PWM generators, not 12.
Platform-Specific SNAPpy Functionality Radio Calibration Info (NV Parameter 66): The system automatically maintains calibration data for 16 radio channels (4 bytes per channel). This calibration info is stored in NV Parameter 66. To see how to trigger radio calibration, refer to the descriptions of pokeRadio(5) and pokeRadio(6) later in this section. Built-in function getInfo(): The values returned by the getInfo() function for the first four parameters vary by platform.
Built-in function peek(): The STM32W108xB chips use a 32-bit architecture, so the signature for the peek() function has changed to accommodate the larger address space and the potential for return values of different sizes. The new function signature is: peek(addrHi, addrLow, word) The addrHi and addrLow parameters are 16-bit values.
Built-in function poke(): The STM32W108xB chips use a 32-bit architecture, so the signature for the poke() function has changed to accommodate the larger address space and the potential for different value sizes being poked. The new function signature is: peek(addrHi, addrLow, word, data) with word = 0 or word = 1, or peek(addrHi, addrLow, word, dataHi, dataLow) with word = 2. The addrHi and addrLow parameters are 16-bit values.
Built-in functions peekRadio() and pokeRadio(): The internal radio registers inside the STM32W108xB are not documented by ST. Instead, they supply a binary (no source code) library of routines with which to control the lowest level functionality of the internal radio. For this reason, the peekRadio() and pokeRadio() functions as implemented in this version of SNAP are somewhat non-standard: they do not provide access to low-level radio registers.
Built-in function pulsePin(): On the STM32W108xB, negative durations are in units of approximately 1.4 µs. Here are some requested versus measured pulse timings, taken with a logic analyzer. Requested Duration Measured Pulse Width -1 1.42 uS -2 2.34 uS -3 3.43 uS -4 4.42 uS -5 5.43 uS -10 10.34 uS -100 100.42 uS -10000 10,000.4 mS -20000 19,999.
Built-in function readAdc(): The ADCs on a STM32W108xB return signed 16-bit values, but the data sheets state that only 12 bits are significant. So, SNAPpy returns signed 12-bit values in the range -4096 to 4095. Note that this is different than many versions of SNAP to date – usually the values returned by the SNAPpy readAdc() built-in are unsigned numbers. There are also optional “divide by 4” (gain = 0.25) “buffers” that can be switched in.
For example, invoking readAdc(0x08) would give a comparision between ADC 0 (code 0x0) and GND (code 0x8). Invoking readAdc(0x80) would compare the same two voltages, but the sign of the result would be negated, since the voltage comparison itself would be reversed in polarity. To give another example, invoking readAdc(0x12) would return a reading of the differential voltage between the ADC1 and ADC2 pins. For a call to readAdc(0x23), the internal divide-by-4 “buffer” would not be switched inline.
Built-in function setRadioRate(): The setRadioRate() function does not do anything on the STM32W108xB. The only radio rate available is the default rate of 250 Kbps, compatible with other 2.4 GHz-based SNAP nodes. Built-in function setSegments(): On the STM32W108xB, setSegments() has no effect. Built-in function sleep(): There are three sleep() modes on the MC13224 module. Higher numbered sleep modes draw less current, but have increasing limitations.
Current savings in sleep The following measurements were taken with a DiZiC MB851 evaluation board, and so some of the current draw was from the board, not just the chip. However, the delta in current readings should be meaningful. Mode Awake with radio on (rx(True)) Awake with radio off (rx(False)) sleep(0, 0) sleep(1, 0) sleep(2, 0) Measured current draw 29.1 mA 10.3 mA 1.4 uA 0.6 uA 0.
STM32W108CB Port Pin mappings Chip Pin 1 Processor Port Pin SNAPpy IO VDD_24MHZ Chip Pin 25 Processor Port Pin SNAPpy IO PA3, SC2nSSEL, TRACECLK, TIM2_CH2 PA4, ADC4, PTI_EN, TRACEDATA2 PA5, ADC5, PTI_DATA, nBOOTMODE, TRACEDATA3 3 2 VDD_VCO 26 3 RF_P 27 4 RF_N 28 VDD_PADS 5 VDD_RF 29 PA6, TIM1_CH3 6 6 RF_TX_ALT_P 30 9 7 RF_TX_ALT_N 31 PB1, SC1MISO, SC1MOSI, SC1SDA, SC1TXD, TIM2_CH1 PB2, SC1MISO, SC1MOSI, SC1SCL, SC1RXD, TIM2_CH2 8 VDD_IF 32 SWCLK, JTCK 9 BIAS_R 33 PC2,
STM32W108HB Port Pin mappings Chip Pin 1 Processor Port Pin VDD_VCO Chip Pin 21 Processor Port Pin SNAPpy IO PA3, SC2nSSEL, TRACECLK, TIM2_CH2 3 2 RF_P 22 4 23 PA4, ADC4, PTI_EN, TRACEDATA2 PA5, ADC5, PTI_DATA, nBOOTMODE, TRACEDATA3 3 RF_N 4 VDD_RF 24 VDD_PADS 5 RF_TX_ALT_P 25 6 RF_TX_ALT_N 26 PB1, SC1MISO, SC1MOSI, SC1SDA, SC1TXD, TIM2_CH1 PB2, SC1MISO, SC1MOSI, SC1SCL, SC1RXD, TIM2_CH2 7 VDD_IF 27 SWCLK, JTCK 8 BIAS_R 28 PC2, JTDO, SWO 18 9 VDD_PADSA 29 PC3, JTDI 19
Memory Usage SNAP Protocol Memory Usage: Global Buffer Pool: 20 UART Budget: 6 Mesh Routing Budget: 6 RPC Budget: 6 Radio Budget: 6 STDOUT Budget: 4 SNAPpy Virtual Machine Memory Usage: Number of Tiny Strings: 14 Tiny String Size: up to 16 characters Number of Medium Strings: 10 Medium String Size: up to 128 characters Global Variables: 128 Concurrent Local Variables: 64 Maximum Call Stack Depth: 8 SNAPpy Script Space: 60K Performance Metrics Here are the results of some recent performance measurements,
Maximum rate a SNAPpy script can toggle a GPIO pin: 11583 Hz In other words, each True/False cycle took 86.33 µs. Keep in mind that as a general rule, SNAPpy scripts should not be looping, the above rate is only attainable if the node is doing nothing else (for example, no radio or serial port communication). Maximum rate for readAdc() calls: Maximum 120 samples/second. NOTE! – This measurement was taken using a script that did not actually do anything with the data.
License governing any code samples presented in this Manual Redistribution of code and use in source and binary forms, with or without modification, are permitted provided that it retains the copyright notice, operates only on SNAP® networks, and the paragraphs below in the documentation and/or other materials are provided with the distribution: Copyright 2008-2011, Synapse Wireless Inc., All rights Reserved.
