it works like this, see?
Chuck's Own Research Network
The 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 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 fro 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 communications 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 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 his SerialPower network. I’ve changed the emphasis from processes to messages, and have divided the network messages into command messages and information messages. For Jurjen’s theory, see his docs on his Web site. For a discussion of why I made this change, see here.
As discussed earlier, the network is an example of a multi-node, multi-processor network of communicating nodes. 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 identifies 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 communication cycles. The network is held in a high state at all times 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 ensure 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 slave nodes using a round-robin scheduler. The assigned node can use the communication slot to place data on the network; other nodes implement 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 CMDavailableTimeSlot, the ID of the node 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 to respond.
When an CMDavailableTimeSlot message is sent all nodes decode the called node ID to determine if that node is granted access to the network. If it is, control of the node is transferred to a routine that sends any waiting 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 and can read the message off the network. 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:
[message ID] [node 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. When a command message is sent the second byte is the identifier of the node that should handle the message.
An example of a command message is CMDflashLED. This command instructs the target node to flash its indicator LED for the period contained in the data bytes. The following command message instructs the master node to flash its indicator LED for 250 ms:
[CMDflashLED] [NODEmaster] [0] [250]
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. When an information message is sent the second byte is the node identifier of the node that sent the message.
An example of an information message is MSGtemperatureChanged. This message informs the network that a temperature change event occurred at the sending node. The following information message informs the network that the temperature in the den changed from 73 degrees to 72 degrees:
[MSGtemperatureChanged] [NODEden] [72] [73]