User manual

Code Density
When you upload a SNAPpy script to a node, you are not sending the raw text of the SNAPpy script to the node.
Instead the SNAPpy source code is compiled into byte-code for a custom Virtual Machine (the SNAPpy VM), and
this byte-code and data (SNAPpy “Image”) are sent instead.
We have not performed an exhausve analysis, but a quick check of two typical example scripts (ZicCycle.py and
Zic2410i2cTests.py) showed code densies of 11.625 and 13.138 bytes/line of code.
So, a conservave esmate of SNAPpy code density is 10-15 bytes per line of SNAPpy code.
Simple code will have a higher density; scripts that include a lot of data (for example, text) will be lower.
For example:
def hi():
print "Hi”
takes 35 bytes, but
def hi():
print "Hello everyone, I know my ABCs! - ABCDEFGHIJKLMNOPQRSTUVWXYZ"
takes 91 bytes.
Keeping text messages and funcon names short will help conserve
SNAPpy script space.
Cross-Platform Coding and Easy Pin Numbering
The first hardware plaorm to support SNAP was the RF100, based on
Freescale’s MC9S08 processor family. For the sake of simplicity, SNAP
pin numbers were assigned sequenally to the pins available from the
various ports on the microprocessor, and brought out to the SNAP
Engine footprint sequenally, as shown in the image to the right.
If you have an LED connected to the third pin on the SNAP Engine
(counng from the upper le) and you wish to blink it, your SNAPpy
code could simply use code like this:
pinNum = 1
duration = 500 # Milliseconds
flashOn = True
pulsePin(pinNum, duration, flashOn)
As long as the code you write will always run on RF100 SNAP Engines, and your hardware always has its LED
connected to that third pin, you could always pulse pin 1 and the LED would respond appropriately.
However, you might have a network that includes more than one hardware plaorm, and pulsing pin 1 on an
RF200 would not give you the same results. As new types of SNAP Engines were based on different underlying
hardware plaorms, it was more important that pin funconality be preserved than that pin numbering
compability be maintained. For example, the RF200 has two UARTs, just as the RF100 does, and those UARTs
are available on the same pins on the SNAP Engine footprint. On both an RF100 and an RF200, UART1 (the
default UART) comes out on pins 9 and 10 on the SNAP Engine footprint. On an RF100, those pins are referenced
in SNAPpy code as pins 7 and 8. On an RF200, those pins are referenced in SNAPpy code as pins 10 and 11.
SNAP® Network Operang System 27