Chuck's own research network
This Puddlehaven office network example is a research network using Revolution Education
Picaxe chips networked together using the SerialPower network hardware and software
created by Jurjen Kranenborg and posted to his Web site,
kranenborg.org.
The primary design consideration of the network is for testing and experimenting
using the Picaxe chips and a network. None of the nodes on the network do any "real"
work; they mostly simulate real work with various arm-wavers and blinkin' lights.
The principles that they use could, however, be applied to real-world problems by
interested people.
Background
The network is designed for hobbyist research into a multi-processor, multi-node
network of cooperating processes. Each node on the network is designed to handle
one task, and usually relies on other network nodes for data or to perform actions
on behalf of the node.
For example, an environmental sensor node continuously monitors its sensors to detect
changes in the environment. When a change is detected it records the change, and
then, during the next communication time slot available to the sensor node it sends
a message containing the detected change. The sensor node does not have any provisions
for displaying these readings; it simply sends them to the network -- other nodes
use these readings to perform their own tasks.
The display and control node reads the current temperature from the sensor node
message and displays it on the control panel LCD. The PC interface node sends the
current temperature and humidity data to the attached PC; the PC calculates the
dew point and returns it via the PC interface node where it can be picked up by
the display and control node for display. The thermostat node reads the current
temperature from the network and uses that value to determine if the heater should
be turned on or off.
As with most other research projects I've been involved with, my network is heavy
on network service nodes and light on nodes that even pretend to do things -- as
designed it the ratio of network service nodes to "do something" nodes is 1:1, one
service node for each active node. Of course at least two of the active nodes are
mostly theoretical at this point, so that means that the actual ratio is closer
to 3:1 network service nodes to active nodes.
Theory of operation
Note: This is my interpretation of the description that Jurjen wrote in his documentation
of the SerialPower network. For the real theory, see his docs on his Web site.
As discussed earlier, the network is an example of a multi-node, multi-processor
network of communicating processes. Each node is responsible for managing the interfaces
and data that it needs to accomplish its primary goal while reading any necessary
information from other nodes on the network. Nodes on the network typically take
on one of two roles, either as a sending node that places messages on the network
or as a receiving node that reads information from the network.
Nodes cooperate by sending messages on the network that are read and acted upon
by other nodes on the network. Each message contains four data bytes, a message
ID that identifies the type of message, a source ID that identfies the process or
node that originated the message, and two bytes of data that make up the body of
the message. The fixed size of the network packet simplifies reading the packet
off the network -- the Picaxe will block on a serial input command until the specified
number of bytes are read from the network. The fixed data size makes it easy to
set up an input command for the data coming in from the network.
The physical layer of the network consists of two wires, a power/data connection
and a ground wire. Nodes can either be self powered, providing their own electricity
from an external source, or they can be network powered, getting the electricity
required to run from the network during power-up cycles and storing it in a local
capacitor for use during communications cycles. Self-powered nodes use the power/data
connection as a communications channel only.
The master node creates the cycles on the network, connecting the network to the
power supply to charge up the network-powered nodes and then switching to a pull-up
resister to hold the network high during the communications cycle. The network is
held in a high state at all tiems when data is not being sent -- this keeps network-powered
nodes powered and running. This also means that all data bytes that are ignored
by receivers should be set to all ones to enusre that the network is powered as
often as possible.
Access to the network during the communications cycle is controlled by the master
node. The master assigns communication time slots to processes running on slave
nodes using a round-robin scheduler. The assigned process can use the comminication
slot to place data on the network; other nodes implemnet handlers for the message
to use the information from the network.
The master node signals the start of a network transmission by setting the power/data
connection low. This causes an interrupt on the other network nodes, they respond
by preparing to receive the four bytes of data that will follow
After a short delay for the slave nodes to respond to the interrupt and prepare
to receive data, the master node sends four bytes of data to the network. The packet
is sent with the special message ID IDavailableTimeSlot, the ID of
the message being granted access to the network is contained in the second byte.
After sending the message the master switches the power/communications connection
to communications mode and enters a state waiting for the node sending the specified
message to respond.
When an IDavailableTimeSlot message is sent all nodes decode the called
message ID to determine if the message is sent by that node. If it is, control of
the node is transferred to a routing that sends the requested message, otherwise
the node goes back into its default running mode.
Note that when the master node is in this state it is also waiting for an interrupt
signal. The master node can also be assigned duties unrelated to its tasks as the
master node if necessary for your application.
Because the network stack is implemented as an interrupt service routine, the node
can spend most of its time in its main processing loop, only breaking out of the
loop to determine if it is being granted a network time slot to send a message or
if it is receiving messages from another node. If the node does not have any data
to send the master will eventually time out, move to the next entry in the process
table, and start the cycle again.
Network messages
The nodes running on the network exchange messages by placing message frames on
the network when granted an available time slot for sending. Each message on the
network is in the following format:
[messaage ID] [sender ID] [data byte] [data byte]
When the start of a transmission occurs all nodes on the network interrupt their
main program loop and listen for the message frame. Each node examines the message
and determines if it is interested in the message. If not, the node immediately
returns to its normal processing loop. If the node is interested in the message
it jumps to a handling routine for the message. The slave node can either process
the message immediately in the message handler, or it can set flags or data registers
that indicate to the main processing loop that a change in state has occurred.
There are two types of messages that can appear on the network: command messages
and information messages.
Command messages are instructions from one node to another, the first node determining
that a specific action is required and instructing another node to perform that
action. The prevalent form of command message on the network is the available time
slot messages sent by the master node, each a command to the specified node or process
to place a message on the network.
Information messages are messages that nodes place on the network to provide information
to other nodes on the network. The node that places the message on the network does
not know which other node, or even if another node will use the information
in the message.