User manual

Simplifying the mapping of GPIO pins is only part of the power of the plaorms.py file. By having the plaorm
variable defined, you can take advantage of other special features of the various nodes:
from synapse.platforms import *
if platform == 'RF100':
sleepMode = 0
elif platform == 'RF200':
sleepMode = 1
sleep(sleepMode, 20)
On an RF200, sleep mode 0 results in a significantly higher sleep current than sleep mode 1 does. Mode 0 exists
for AT128RFA1 hardware configuraons that do not include an external ming crystal. But the RF200 does
include that crystal, so sleep mode 1 is preferred. Using a script like the one above, sleeping on either plaorm
will give the best efficiency.
The real “magic” part of this plaorm variable process is a lile more subtle than has been made evident so far.
The plaorm variable is available to Portal at compile me, rather than just being a run-me variable. So if your
SNAPpy script includes code secons condionally based on the plaorm variable, any parts that don’t apply for
the selected plaorm won’t even be included in the script loaded onto your node. This prevents incorrect code
from being run if the plaorm parameter is accidentally changed aer the code is loaded, and more importantly,
can significantly reduce the size of the image loaded into your node.
So far, the assumpon has been that the plaorm would be used only to disnguish between nodes based on
different underlying hardware. But you can set NV Parameter 41 to any value that suits your needs, and thus
have the plaorm variable be anything you like. (If you were to do so, you could sll explicitly include the GPIO
mappings by imporng synapse.RF200 or synapse.SM220 or the other appropriate mapping file to gain access to
GPIO constants for easy pin referencing.)
Defining your own plaorms could be useful in a situaon where you wanted to maintain a complete
applicaon’s code base in one source file, even though different devices used in your installaon required
different funconality.
For example, you may have different revisions of hardware connecng to your SNAP Engines, with discrepancies
in how things are connected, but wish to have only a single SNAPpy script code base to maintain. The difference
could be a simple as connecng an LED to a different pin, or making a serial connecon at a different baud rate.
Or, it could be much more complicated, where a “collectData()” funcon for one board revision makes a simple
serial connecon, while on a later board revision it makes an I
2
C connecon to harvest the appropriate
informaon.
Again, much of this could be accomplished with a user-defined NV Parameter as well. What NV Parameter 41
and the plaorm variable provide is access to this level of control at the point where your SNAPpy script is being
compiled before loading it into your node, which allows selecve control of which other SNAPpy modules are
imported into your script, and which helps reduce the code size of your script, leaving more script space for
more elaborate SNAPpy scripts.
30 SNAP® Network Operang System