Menu
▾
▴
[Can-svn] SF.net SVN: can: [802] trunk
|
From: <ak...@us...> - 2008-01-29 17:49:26
|
Revision: 802
http://can.svn.sourceforge.net/can/?rev=802&view=rev
Author: akhe
Date: 2008-01-29 09:49:18 -0800 (Tue, 29 Jan 2008)
Log Message:
-----------
Minor Cleanup
Removed Paths:
-------------
trunk/ODIN/isdn/img/
trunk/ODIN/webif/dtgraph/
trunk/ODIN/webif/netjukebox/
trunk/ODIN/webif/prototype/
trunk/OMobile/
trunk/docs/canal/images/canallogger_format.bmp
trunk/docs/vscp/eda.pdf
trunk/docs/vscp/eda_abstract.doc
trunk/docs/vscp/vscp_spec.docbook
trunk/docs/vscp/vscp_spec.pdf
trunk/docs/vscp/vscp_spec.ps
trunk/docs/vscp/vscp_spec.sxw
trunk/docs/vscp/vscp_spec.tex
trunk/docs/vscp/vscp_spec142.pdf
Deleted: trunk/docs/canal/images/canallogger_format.bmp
===================================================================
(Binary files differ)
Deleted: trunk/docs/vscp/eda.pdf
===================================================================
(Binary files differ)
Deleted: trunk/docs/vscp/eda_abstract.doc
===================================================================
(Binary files differ)
Deleted: trunk/docs/vscp/vscp_spec.docbook
===================================================================
--- trunk/docs/vscp/vscp_spec.docbook 2008-01-29 11:07:57 UTC (rev 801)
+++ trunk/docs/vscp/vscp_spec.docbook 2008-01-29 17:49:18 UTC (rev 802)
@@ -1,4176 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" ?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN">
-
-<book id="vscp-spec" lang="en">
-
-<bookinfo>
-<title>VSCP - Very Simple Control Protocol - Specification</title>
-<authorgroup>
-<author>
-<firstname>Ake</firstname>
-<othername></othername>
-<surname>Hedman</surname>
-</author>
-<author>
-<firstname>Mark</firstname>
-<othername></othername>
-<surname>Marooth</surname>
-</author>
-<author>
-<firstname>Charles</firstname>
-<othername></othername>
-<surname>Tewiah</surname>
-</author>
-<author>
-<firstname>Andreas</firstname>
-<othername></othername>
-<surname>Nyholm</surname>
-</author>
-</authorgroup>
-
-
-<date>2005-06-02</date>
-<releaseinfo>1.31</releaseinfo>
-
-<abstract>
-
-<para>
-Reversion: 1.31 2005-05-23
-</para>
-
-<para>
-the VSCP Team, http://www.vscp.org
-</para>
-
-<para>
-Copyright © 2000-2005 Ake Hedman, eurosource
-</para>
-
-<para>
-<application>VSCP - Very Simple Control Protocol Specification</application> decribes a simple protocol for control tasks over different network media.
-</para>
-</abstract>
-
-<keywordset>
-<keyword>VSCP</keyword>
-<keyword>sample application</keyword>
-</keywordset>
-</bookinfo>
-
-<chapter id="introduction">
-<title>Introduction</title>
-
-<para>
-There are a lot of protocols and technologies that claims to be the perfect protocol
-for use in SOHO (Small Office/HOme) control situations. TCP/IP, Bluetooth, different
-ways of power line communication, to name a few. VSCP is no such thing, period! It is
-just another solution to a common problem. In this case the need to manufacture low
-cost nodes that can work reliably and efficiently and be trusted in their day-to-day
-use.
-</para>
-
-<para>
-The VSCP Protocol has been designed to be used in CAN networks. There is one reason
-for this, CAN is very reliable and today it is also low cost. Two good things. It is
-also possible to understand the inner workings of the protocol with just minimal
-effort and it is supported throughout the industry.
-Even though the protocol is designed for CAN there is no need for CAN. It can be used
-equally well in other environments.
-</para>
-
-<para>
-VSCP has been designed in two levels. Level 1 is intended for low-end machines while
-Level 2 is intended for higher level and speedier transport mechanisms such as TCP/IP.
-The initial design goals in designing VSCP have been:
-</para>
-
-<para>
-It should be free and open. No usage, patent or other costs for its implementation/
-usage.
-</para>
-
-<para>
-
-Keep it simple stupid (K.I.S.S.) is the ruling design model.
-</para>
-
-<para>
-Flexible.
-</para>
-
-<para>
-A node should be constructed for the lowest possible cost.
-</para>
-
-<para>
-Uses standard components and cables.
-</para>
-
-<para>
-All nodes should be identifiable by a globally unique ID. This can also be used as a
-globally unique serial number for the device.
-</para>
-
-<para>
-No need to configure nodes with addresses. This is totally handled internally by the
-protocol.
-</para>
-
-<sect1 id="open">
-<title>Open?</title>
-<para>
-This protocol is open and free in all aspects that are possible. We want you to
-contribute work back to the project if you do your own work based on our code but we
-also like to make as much of this work useful also in commercial projects. The tool we
-have chosen to do this is the GNU public license and the lesser GPL. For firmware code
-we use an even more open model so that there is no question that you are allowed to
-put the code in your own commercial projects if you feel to do that.
-The GPL license and the LGPL license is included in the distribution of code in the
-file COPYING but can also be ordered from by writing to the Free Software Foundation,
-59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-</para>
-
-<para>
-Copyright © 200-2005 Ake Hedman, eurosource
-</para>
-
-<para>
-Current information about canal, canald and VSCP (Very Simple Control Protocol) can be
-found at:
-</para>
-
-<simplelist>
-<member>http://www.vscp.org</member>
-<member>http://can.sourceforge.net</member>
-</simplelist>
-
-<para>
-There are two mailing lists available on Sourceforge https://sourceforge.net/mail/?
-group_id=53560 that is about canal (can_canal) and VSCP (can_vscp) topics.
-</para>
-
-<para>
-To subscribe to the canal list go to http://lists.sourceforge.net/lists/listinfo/can-
-canal
-</para>
-
-<para>
-To subscribe to the VSCP list go to http://lists.sourceforge.net/lists/listinfo/can-
-vscp
-</para>
-
-</sect1>
-
-
-<sect1>
-<title>VSCP level I</title>
-<para>
-When the protocol was designed it's usefulness on the CAN bus was the main objective.
-The identifier length and many other things are therefore very 'CAN-ish' in its design
-and behavior. CAN is however no prerequisite.
-</para>
-
-<sect2>
-<title>VSCP over CAN</title>
-
-<para>
-The maximum number of nodes is 254. In practice this is probably around 127 depending
-on drivers and media used.
-</para>
-
-<para>
-The transmission speed is 500 kilobits per second. Other speeds can be used but all
-nodes should support 500 kbps,
-</para>
-
-<para>
-The maximum length of the cabling in a segment is 100 meters using AWG24 or similar
-(CAT5).
-</para>
-
-<para>
-The cable should be terminated at both ends with 120 ohms.
-</para>
-
-<para>
-VSCP requires a 29-bit identifier with a meaning defined below.
-</para>
-
-<para>
-The protocol is compatible with dumb CAN nodes such as the Microchip MCP2502x/5x.
-</para>
-
-<para>
-Appendix C shows how the VSCP Level I frame looks like for CAN.
-</para>
-</sect2>
-
-</sect1>
-
-<sect1>
-<title>VSCP level II</title>
-<para>
-VSCP level two is designed for TCP/IP and other high-end network transport mechanisms
-that are able to handle a lot of data. With all the additional bandwidth available it
-would be ideal to always have a full addresses in packets for this type of media. That
-means that the address part in the header that is now 8-bits should be 129 bits
-instead. Information would be packed in the following way
-</para>
-
-<simplelist>
-<member>3-bits Priority</member>
-<member>16-bits Class</member>
-<member>1-bit Hardcoded </member>
-<member>16-bits Type </member>
-<member>128-bits Originating Address</member>
-</simplelist>
-
-<para>
-The HEAD is defined as
-</para>
-
-<simplelist>
-<member>bit 7,6,5 - Priority</member>
-<member>bit 4 - Hardcoded</member>
-<member>bit 3,2,1,0 reserved</member>
-</simplelist>
-
-<para>
-And the packet format is
-</para>
-
-<simplelist>
-<member>0 - HEAD</member>
-<member>1 - CLASS MSB</member>
-<member>2 - CLASS LSB</member>
-<member>3 - TYPE MSB</member>
-<member>4 - TYPE LSB</member>
-<member>5 - ORIGINATING ADDRESS MSB</member>
-<member>...</member>
-<member>20 - ORIGINATING ADDRESS LSB</member>
-<member>21 - DATA SIZE MSB</member>
-<member>22 - DATA SIZE LSB</member>
-<member>..... data ... limited to max 512-25 = 487 bytes</member>
-<member>len -2 - CRC MSB (Calculated on HEAD + CLASS + TYPE + ADDRESS + SIZE + DATA)</member>
-<member>len -1 - CRC LSB</member>
-</simplelist>
-
-<para>
-The number above is the offset in the package. Len is the total datagram size.
-</para>
-
-<para>
-Note also that the MSB is sent before the LSB (network byte order). So, for little
-endian machines such as a typical PC the byte order needs to be reversed for multi
-byte types.
-</para>
-
-<para>
-There is a 24-byte overhead to send one byte of data so this is not a protocol which
-should be used where an efficient protocol for data intensive applications is required
-and where data is sent in small packets.
-</para>
-
-<para>
-The CRC used is the 16-bit CCITT type and it should be calculated across all bytes
-except for the CRC itself.
-</para>
-
-<para>
-The original message format is called Level 1 VSCP and this new format is Level 2
-VSCP. The two formats can work side-by-side and all classes and types for Level 1 are
-also available in Level 2.
-</para>
-
-<para>
-As indicated, the Class has resized from 9-bits to 16-bits allowing for 65535 classes.
-Class 0000000x xxxxxxxx is reserved for the original classes. A low-end device should
-ignore all packages with a class > 511.
-</para>
-
-<para>
-A packet traveling from a Level 1 device out to the Level 2 world should have an
-address translation done by the master so that a full address will be visible on the
-level 2 net.
-</para>
-
-<para>
-A packet traveling from a Level 2 net to a Level 1 net must have a class with a value
-that is less then 512 in order for it to be recognised. If it has it is aimed for the
-Level 1 network. Classes 512-1023 are reserved for packets that should stay in the
-Level 2 network but in all other aspects (the lower nine bits + type) are defined in
-the same manner as for the low-end net.
-</para>
-
-<para>
-The Level 2 register abstraction level also has more registers (32-bit address is
-used) and all registers are 32-bits wide. Registers 0-255 are byte wide and are the
-same as for level 1. If these registers are read at level 2 they still is read as 32
-bit but have the unused bits set to zero.
-</para>
-</sect1>
-
-<sect1>
-<title>GUID's, Globally Unique Identifiers</title>
-<para>
-To classify as a node in a VSCP net all nodes must be uniquely identified by a
-globally unique 16-byte (yes that is 16-byte (128 bits) not 16-bit) identifier. This
-number uniquely identifies all devices around the world and can be used as a means to
-obtain device descriptions as well as drivers for a specific platform and for a
-specific device.
-</para>
-
-<para>
-The manufacturer of the device can also use the number as a serial number to track
-manufactured devices.
-</para>
-
-<para>
-In many other environments and protocols there is a high cost in getting a globally
-unique number for your equipment. This is not the case with VSCP. If you own an
-Ethernet card you also have what is needed to create your own GUID's.
-</para>
-
-<para>
-The GUID address is not normally used during communication with a node. Instead an 8
-bit address is used. This gives a low protocol overhead. A segment can have a maximum
-of 127 nodes even if the address gives the possibility for 256 nodes. The 8-bit
-address is received from a master node called the segment controller. The short
-address is also called the nodes nickname id or nickname address.
-</para>
-
-<para>
-Besides the GUID it is recommended that all nodes should have a node description
-string in the firmware that points to a URL that can give full information about the
-node and its family of devices. As well as providing information about the node, this
-address can point at drivers for various operating systems or segment controller
-environments.
-</para>
-</sect1>
-
-<sect1>
-<title>Reserved GUID's</title>
-
-<para>
-Some GUID's are reserved and unavailable for assignment. Appendix A list these and
-also assigned id's.
-</para>
-
-<para>
-The VSCP team controls the rest of the addresses and will allocate addresses to
-individuals or companies by them sending a request to gui...@vs.... You can
-request a series of 32-bits making it possible for you to manufacture 4294967295
-nodes. If you need more (!!!) you can ask for another series. There is no cost for
-reserving a series. Appendix A in this document contains a list of assigned addresses
-which will also be available at http://www.vscp.org
-</para>
-</sect1>
-
-<sect1>
-<title>Level I Node types</title>
-<para>
-On each segment there can be two kind of nodes. Dynamic and hardcoded.
-</para>
-
-</sect1>
-
-<sect1>
-<title>Dynamic nodes</title>
-<para>
-Are VSCP nodes that confirm fully to the Level I part of this document. This means
-they have
-</para>
-
-<itemizedlist>
-<listitem><para>a GUID.</para></listitem>
-<listitem><para>the register model implemented.</para></listitem>
-<listitem><para>all or most control messages of class zero implemented. As a minimum
-register read write should be implemented id addition to the events related to the
-nickname discovery.</para></listitem>
-<listitem><para>Have the hard coded bit in the id is set to zero.</para></listitem>
-<listitem><para>Must react on PROBE message on its assigned address with a probe ACK
-and should send out the ACK with the hard coded bit set.</para></listitem>
-</itemizedlist>
-
-<para>
-Sample implementations are available at http://www.vscp.org
-</para>
-</sect1>
-
-<sect1>
-<title>Hard coded nodes</title>
-<para>
-Are VSCP nodes which have a loose conformity to the Level 1 part of this document.
-They can have a nickname address set in hardware or it can have the nickname discovery
-process implemented. In the former case it is up to the installer to assign a unique
-address to the node in the segment and remember to have the hard coded bit set to one.
-There can not be any hard coded nodes with the hard coded bit set to zero.
-Very simple hard coded nodes can therefore be implemented. A node that send out an
-event at certain times is typical and a button node that send out an on-event when the
-button is pressed is another example.
-</para>
-</sect1>
-
-<sect1>
-<title>Level II Node types</title>
-<para>
-Level II nodes are intended for media with higher bandwidth then Level I nodes and no
-nickname procedure is therefore implemented on Level II. As result of this the full
-GUID is sent in each packet.
-</para>
-
-<para>
-The header for a level II event is defined as
-// This structure is for VSCP Level II
-typedef struct _vscpMsg {
-
- _u16 crc; // CRC checksum
- _u8 *pdata; // Ponter to data. Max 487 (512- 25) bytes
- // Following two are for daemon internal use
- _u32 obid; // Used by driver for channel info etc.
- _u32 timestamp; // Relative time stamp for package in microseconds
-// CRC should be calculated from
-// here to end + datablock
-
- _u8 head; // bit 765 prioriy,
- // Priority 0-7 where 0 is highest.
- // bit 4 = hardcoded, true for a
- // hardcoded device.
- // bit 3 = Dont calculate CRC,
- // false for CRC usage.
- _u16 vscp_class; // VSCP class
- _u16 vscp_type; // VSCP type
- _u8 GUID[ 16 ]; // Node address MSB -> LSB
- _u16 sizeData; // Number of valid data bytes
-} vscpMsg;
-</para>
-
-<para>
-The biggest differences is that the GUID is sent in each event and that both class and
-type has a 16-bit length.
-</para>
-
-<para>
-The CRC is calculated using the CCITT polynomial see appendix E.
-The max size for a Level II event is 512 bytes and as the header takes up 25 bytes the
-payload or datapart can take up max 487 bytes. This can seem a bit strange looking at
-the above structure but in a datagram or aother package not all of the above members
-are present. The format in a stream is
-</para>
-
-<para>
-// VSCP LEVEL II UDP datagram offsets
-#define VSCP_UDP_POS_HEAD 0
-#define VSCP_UDP_POS_CLASS 1
-#define VSCP_UDP_POS_TYPE 3
-#define VSCP_UDP_POS_GUID 5
-#define VSCP_UDP_POS_SIZE 21
-#define VSCP_UDP_POS_DATA 23
-#define VSCP_UDP_POS_CRC len - 2
-</para>
-
-<para>
-As is noted the obid and timestamp is not present in the actual stream and is only
-inserted by the driver interface software.
-</para>
-
-<para>
-Level I events can travel in the Level II world. This is because all Level I events
-are repleted in Class=1024. As nicknames are not available on Level II they are
-replaced in the events by the full GUID. This is an important possibility in larger
-installations.
-</para>
-
-<para>
-A message from a node on a Level I that is transfered out on a Level II can have the
-nodes own GUID set or the GUID of the interface between the Level I and the Level II
-segment. Which method to choose is up to the implementor as long as the GUID's are
-unique.
-</para>
-
-<para>
-For interfaces the machine MAC address, if available, is a good base for a GUID which
-easily can map to real physical nodes that are handled by the interface. By using this
-method each MAC address gives 65536 unique GUID's.
-Other methods to generate GUID's s also available form more information see Appendix
-A.
-</para>
-
- <para>
-Address or "nickname" assignment for Level I nodes
-All nodes in a VSCP network segment need a way to get their nicknames ID's, this is
-called the nickname discovery process.
-A VSCP Level 1 segment can have a maximum of 254 nodes + 254 possible hard coded
-nodes. A segment can have a master that handles address or nickname assignment but
-this is not a requirement.
-After a node has got its nickname id it should save this id in permanent non-volatile
-storage and use it until it is told to stop using it. Even if a node forgets its
-nickname a segment controller must have a method to reassign the id to the node. The
-master needs to store the nodes full address to accomplishe this.
-</para>
-</sect1>
-
-<sect1>
-<title>Node segment initialization</title>
-<sect2>
-<title>Dynamic nodes</title>
-<para>
-In a segment where a new node is added the following scenario is used.
-</para>
-
-<para>
-1.The process starts by pressing a button or similar on the node. If the node has a
-nickname assigned to it, it forgets this nickname and enters the initialization state.
-Uninitiated nodes use the reserved node id 0xff.
-</para>
-
-<para>
-2.The node sends a PROBE message to address 0 (the address reserved for the master of
-a segment) using 0xff as its own address. The priority of this event is set to 0x07.
-The master (if available) now has a chance to assign a nickname to the node.
-If no nickname assignment occurs the node checks the other possible nicknames (1-254
-in turn. The node listens for a response event, probe ACK, from a node (which may
-already have the nickname assigned) for five seconds before concluding that the id is
-free and then uses the id as its own nickname id. On slower medium increase this
-timeout at will.
-</para>
-
-<para>
-It is recommended that some visual indication is shown to indicate success. A blinking
-green led that turns steady green after a node has got its nickname is the recommended
-indication. If there is a response for all addresses a failure condition is set
-(segment full) and the node goes to sleep.
-</para>
-
-<para>
-On an insecure medium such as RF it is recommended that the Probe is sent several time
-in a row to make sure that the nickname actually is free.
-</para>
-
-<para>
-3.After it assigns a nickname to itself the node sends Nickname id accepted using its
-new nickname id to inform the segment of its identity.
-</para>
-
-<para>
-4.It's now possible for other nodes to check the capabilities of this new node using
-read commands.
-</para>
-
-<para>
-Only one node at time can go through the initialization process.
-</para>
-
-<para>
-The following picture show the nickname discovery process for a newly added node on a
-segment
-</para>
-
-<para>
-1.The node which initially have its nickname set to 0xff probe for a segment
-controller. Class = 0, Type = 2
-2.No segment controller answerers the probe and a new probe is therefore sent to a
-node with nickname=1. Again Class=0, Type=2.
-3.There is anode with nickname= 1 already on the segment and it answerers the probe
-with "probe ACK" Class=0, Type=3. The initiating node now knows this nickname is
-already in use.
-4.A new probe is sent to a node with nickname=2. Again Class=0, Type=2.
-5. No ACK is received and the node conclude that the nickname=2 is free and assign it
-to itself. It then send a probe again with the new nickname assigned reporting a "new
-node on line".
-</para>
-</sect2>
-
-<sect2>
-<title>Hard coded nodes</title>
-<para>
-Things are a little different for hard coded nodes
-If a hard coded node has its address set in hardware it starts working on the segment
-immediately.
-</para>
-
-<para>
-If the nickname discovery method is implemented it goes through the same steps (1-3)
-as the dynamic node. In this case all hard coded nodes on the segment must recognize
-and react on the probe-event.
-The hard coded bit should always be set for a hard coded node regardless if the
-nickname discovery method is implemented or not.
-</para>
-</sect2>
-
-<sect2>
-<title>Example</title>
-<para>
-A typical scenario for a master less segment can be a big room where there are several
-switches to turn a light on or off. During the installation the switches are installed
-and initialized.
-When each switch is initialized it check the segment for a free nickname and grabs it
-and stores it in local nonvolatile memory. By being conected to the segment the
-installer makes not of the ids. It is of course also possible to set the nicknames to
-some desired value instead.
-Additionally, VSCP aware relays are installed and also initialized to handle the
-actual switching of lighting. Again each in tern are initialized and the segment
-unique nickname noted.
-At this stage the switches and the releay nodes have no connection with each other.
-One can press any switch and an on-event is sent on the segment but the relays don't
-know how to react on it.
-We do this by entering some elements in the decision matrix of the relay nodes.
-</para>
-
-<para>
-If on-event is received from node with nickname n1 set relay on.
-If on-event is received from node with nickname n2 set relay on.
-If on-event s received from node with nickname n2 set relay on.
-
-etc and the same for off-event
-
-If off-event is received from node with nickname n1 set relay off.
-If off-event is received from node with nickname n2 set relay off.
-If off-event s received from node with nickname n2 set relay off.
-</para>
-
-<para>
-As the decsion matrix also is stored in the nodes non volatile storage the system is
-now coupled together in this way until changed sometime in the future.
-To have switches in this way that send on and off events is not so smart when you have
-a visible indication (lights go on or off) and it would have been much better to let
-the switches send only an on-event and let the relay-node decide what to do. In this
-case the decion matrix would loook
-</para>
-
-<para>
-If on-event is received from node with nickname n1 toggle relay state.
-If on-event is received from node with nickname n2 toggle relay state.
-If on-event s received from node with nickname n2 toggle relay state.
-But how about a situation when we need a visual indication on the switch for instance?
-This can be typical when we turn a boiler or something off.
-The answer is simple. We just look for a message from the device we control. In the
-decision matrix of the switches we just enter
-If on-event is received from node with nickname s1 - status light on.
-If off-event is received from node with nickname s1 - status light off.
-</para>
-
-<para>
-It s very easy to add aswitch to the scenario above and it can be even easier if the
-zone concept s used. In this concept each switch on/off message add information on
-which zone it controls and the same change is done in the decision matrix We get
-someting like
-</para>
-
-<para>
-If an on-event is received for zone x1 turn on relay
-We now get even more flexible when we need to add/change the setup.
-What if I want to control the lights from my PC?
-No problem just send the same on-event to the zone from the PC. The relay and the
-switches will behave just as a new switch has been added.
-What if whant a repote control that controls the lightning?
-Just let the remote control interface have a decisn matrix element that sens out the
-on-event to the zone when the selected key s pressed.
-What if I want the lights to be turned on when the alarm goes off?
-Same solution here. Program the alarm control to send the on.event to the zone on
-alarm.
-</para>
-
-<para>
-You imagination is the only limitation....
-</para>
-</sect2>
-</sect1>
-
-<sect1>
-<title>TODO</title>
-<para>
-Level I - Register Abstraction Model
-The model used for reads and writes is defined in this section. Register 0x00 - 0x7f
-are application specific.
-Registers between 0x80-0xff are reserved for VSCP usage.
-If the node has implemented EDA the decision matrix is stored in application register
-space.
-With Node control flags (0x83) the node behavior can be controlled. The startup
-control is two bits that can have two values, binary 10 and binary 01. All other
-values are invalid and are translated to binary 10. If set to binary 10 it will
-prevent the initialization routine of the node to start before the initialization
-button on the node has been pressed.
-Bit 5 of the node control flags write protects all user registers if cleared ( == 1 is
-write enabled).
-The page select registers (0x92/0x93) can be used if more application specific
-registers are needed. The page is selected by writing a 16-bit page in these
-positions. This gives a theoretical user registry space of 256 * 65535 bytes (65535
-pages of 256 bytes each). Note that the normal register read/write method can not be
-used to access this space. The page read/write methods are used instead.
-0x98 Buffer size for device is information for control nodes of limitations of the
-buffer space for a Level II node. Level I nodes have eight in this position. Level II
-nodes that can accept the normal Level II packet have 0 which indicates 512-25 bytes
-or can have some number that represent the actual buffer. The Page read/write, boot
-events etc can handle more then eight data bytes if the buffer is larger then eight
-even if the event is a Level I event.
-The VSCP registers are defined as follows:
-Address
-Access Mode
-Description
-0x00 - 0x7f
----
-Device specific
-0x80
-Read Only
-Alarm status register content (!= 0 indicates alarm). Condition is reset by a read
-operation. The bits represent different alarm conditions.
-0x81
-Read Only
-VSCP Major version number this device is constructed for.
-0x82
-Read Only
-VSCP Minor version number this device is constructed for.
-0x83
-Read/Write
-Node control flags
-bit 7 Startup control
-bit 6 Startup control
-bit 5 r/w control of registry below 0x80. (1 means write enabled)
-bit 4 Reserved
-bit 3 Reserved
-bit 2 Reserved
-bit 1 Reserved
-bit 0 Reserved
-
-0x84
-Read/Write
-User ID 0 - Client settable node id byte 0.
-0x85
-Read/Write
-User ID 1 - Client settable node id byte 1.
-0x86
-Read/Write
-User ID 2 - Client settable node id byte 2.
-0x87
-Read/Write
-User ID 3 - Client settable node id byte 3.
-0x88
-Read/Write
-User ID 4 - Client settable node id byte 4.
-0x89
-Read only
-Manufacturer device ID byte 0.
-0x8a
-Read only
-Manufacturer device ID byte 1.
-0x8b
-Read only
-Manufacturer device ID byte 2.
-0x8c
-Read only
-Manufacturer device ID byte 3.
-0x8d
-Read only
-Manufacturer sub device ID byte 0.
-0x8e
-Read only
-Manufacturer sub device ID byte 1.
-0x8f
-Read only
-Manufacturer sub device ID byte 2.
-0x90
-Read only
-Manufacturer sub device ID byte 3.
-0x91
-Read only
-Nickname id for node if assigned or 0xff if no nickname id assigned.
-0x92
-Read/Write
-Page select register MSB
-0x93
-Read/Write
-Page Select register LSB
-0x94
-Read Only
-Firmware major version number.
-0x95
-Read Only
-Firmware minor version number.
-0x96
-Read Only
-Firmware sub minor version number.
-0x97
-Read Only
-Boot loader algorithm used. 0Xff for no bootloader support.
-0x98
-Read Only
-Buffer size.
-0x99-0xcf
----
-Reserved for future use.
-0xd0-0xdf
-Read Only
-128-bit (16-byte) globally unique ID (GUID) identifier for the device. This identifier
-uniquely identifies the device throughout the world and can give additional
-information on where driver and driver information can be found for the device. MSB
-for the identifier is stored first (in 0xd0).
-0xe0-0xff
-Read Only
-Module Description File URL. A zero terminates the ASCII string if not exactly 32
-bytes long. The URL points to a file that gives further information about where
-drivers for different environments are located. Can be returned as a zero string for
-devices with low memory.
-
-It is recommended that unimplemented registers read as oxff
-Level II - Register Abstraction Model
-The level II abstraction model is the same as Level I but covers a much wider address
-space. The registers are layed out in an 32-bit address space with the standard Level
-I register map on the top (0xffffff80 - 0xffffffff).
-Level II also have a configuration model where data for a node can be read and written
-in XML format. Its up to the designed of the node which method to use as long as the
-required registers are implemented.
-
-Level II - Configuration Model
-Preliminary
-For the level II part of the protocol a configuration model for nodes has been added.
-This is a complimentary way to configure a device besides the register model. The
-manufacturer define what the dataformat for a specifc node looks like.
-XML format for configuration messages
-
-
-< config xmlns:xs=http://www.w3.org/2001/XMLSchema >
-< name type="xsd:string" > Kitchen Light Switch</name >
-< idleSeconds type="xsd:integer" > 10 < /idleSeconds >
-< enabled type="xsd:bool > true < /enabled >
-</config >
-
-
-No reliance should be placed on the name of the root level element as it's simply used
-to create a well formed XML message.
-
-The "xmlns:xs" specifies the name space being used and can always be as specified
-above.
-
-Each parameter for the node is then specified as an element with the "type" attribute
-specifying the type of value supported for this attribute.
-
-Support will be included for extended type, however, for the moment only simple "xsd"
-types are supported.
-
-A number of the methods below requires that the GUID of the target node is known
-beforehand. This can be achieved by sending a "Segment Status
-Heartbeat" (CLASS.PROTOCOL1, TYPE= 1). Nodes respond to this message by sending a
-NodeHeartbeat (CLASS.INFORMATION, TYPE=9).
-
-
-The following is an example of how these messages can be used.
-
-1.ConfigReadRequest event is broadcast with the GUID of the target node in the "Data"
-portion of the message and 0 in the code portion.
-
-2. Node responds with a ConfigReadResponse with the code portion indicating the
-current page / total pages.
-
-3. Requesting node receives all the ConfigReadResponse messages and pieces together
-the message. Note that if a ConfigReadRequest is detected whilst compiling the
-ConfigReadResponse message then the process is abandoned.
-
-4. The requesting node can then edit the configuration and then send out a
-ConfigChanged message with the GUID of the target in the data portion. This indicates
-that the data for another node has been modified and can be sent on request.
-
-5. The target node can now request the new configuration by issuing a
-ConfigUpdateRequest
-
-6.The node that changed the configuration will now notice this message and from the
-GUID of the sender can determine that it has a new configuration for the node and thus
-sends out a series of ConfigUpdateResponse messages.
-
-7. The target node now waits for a series of ConfigUpdateResponse messages with a
-segment / total segment parameter.
-
-
-8. The process is ended with a ConfigChanged with no GUID in the data portion.
-
-
-Module Description File (mdf)
-Preliminary
-The VSCP registers 0xe0-0xff specifies the Module Description File URL (without
-"http://" which is implied if not specified).
-The file is in XML format and defines a modules functionality, registers and events.
-The intended use is for application software to be able to get information about a
-node and its functionality in an automated way.
-On Level II devices this information can be available in the configuration data and be
-locally stored on the node.
-If <language> tags are missing for a name or a description or in an other place
-where
-they are valid English should be assumed.
-
-<vscp> ... </vscp>
- This is the top level tag. Data within thees tags are valid. Data outside should be
- disregarded.
-<name>...</name>
-Manufacturer Name of devices.
-<model>...</model>
-Manufacturer model of devices.
-<description>...</description>
-These tags can be present in several places. At the top level they give a general
-description of the module and its functionality.
-<language>...</language>
-Language as an ISO code (same as domain extensions).
-<infourl>...</infourl>
-Specifies an URL to human readable information pages about the module.
-<manufacturer> ... </manufacturer>
-This is a tag for a manufacturer information block for the module. One for each
-region the company may be present in or a single entry (Head Office).
-<name> ... </name>
-In a manufacturer block this is the name of the manufacturer.
-<address> ... </address>
-In a manufacturer block this is the postal address of the manufacturer. Several are
-allowed.
-<zipcode> ... </zipcode>
-<postalcode> ... </postalcode>
-In a manufacturer block this is the zip-code of the manufacturer. Both are valid but
-only ever one at the time.
-<state> ... </state>
-In a manufacturer block this is the state of the manufacturer.
-<region> ... </region>
-In a manufacturer block this is the region of the manufacturer.
-<city> ... </city>
-In a manufacturer block this is the city of the manufacturer.
-<country> ... </country>
-In a manufacturer block this is the country of the manufacturer.
-<telephone> ... </telephone>
-In a manufacturer block this is the telephone number of the manufacturer. Several are
-allowed.
-<description> ... </description>
-Description of phone number. "sales", "info", "exchange".
-<telefax> ... </telefax>
-In a manufacturer block this is the fax number of the manufacturer. Several are
-allowed.
-<email> ... </email>
-In a manufacturer block this is the email address of the manufacturer. Several are
-allowed.
-<web> ... </web>
-In a manufacturer block this is the web URL of the manufacturer. Several are allowed.
-
-<register> ... </register>
-Module register definition.
-<pos> ... </pos>
-Register position as a decimal or a hexadecimal number. If in hex the number should be
-preceded with "0x0". A page can also be defined. In this case the form reg:page is
-used. So 0x10:0x0001 means register 0x10 in page 1.
-<name> ... </name>
-Register name.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Name in optional other language
-<description> ... </description>
-Register description.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Description for optional other
-language.
-<access> ... </access>
-"r" or "w" is valid values. "r" stands for read. "w" stands for write. "rw" is read
-write.
-<default> ... </default>
-Default value for the register as a decimal or a hexadecimal number. If in hex the
-number should be preceded with "0x0".
-<bit> ... </bit>
-Register bit definition.
-<pos> ... </pos>
-Bit position as a decimal between 0 - 7 .
-<name> ... </name>
-English bit name.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Name in optional other language
-<description> ... </description>
-Bit description
-<language>...</language>
-Language as an ISO code (same as domain extensions). Description for optional other
-language
-<default> ... </default>
-Default value for the bit. 0 or 1.
-<access> ... </access>
-"r" or "w" is valid values. "r" stands for read. "w" stands for write. "rw" and "w" is
-read/write.
-
-
-<event> ... </event>
-Specifies an event this device is capable of generating.
-<class> ... </class>
-VSCP class for event as a decimal or a hexadecimal number. If in hex the number should
-be preceded with "0x0".
-<type> ... </type>
-VSCP type for event as a decimal or a hexadecimal number. If in hex the number should
-be preceded with "0x0".
-<priority> ... </priority>
-VSCP priority for event as a decimal or a hexadecimal number between 0 - 7. If in hex
-the number should be preceded with "0x0".
-<hardcoded> ... </hardcoded>
-VSCP hard coded flag as 0 or 1.
-<name> ... </name>
-Event name.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Name in optional other language
-<description> ... </description>
-Event description.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Description for optional other
-language.
-<data> .. </data>
-Describes one data byte of the event.
-<pos> ... </pos>
-Data position as a decimal between 0 - 7 .
-<name> ... </name>
-Name for data byte.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Name in optional other language
-<description> ... </description>
-Data byte description.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Description for optional other
-language
-<bit> ... </bit>
-Data bit definition.
-<pos> ... </pos>
-Bit position as a decimal between 0 - 7 .
-<name> ... </name>
-Bit name.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Name in optional other language
-<description> ... </description>
-Bit description.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Description for optional other
-language
-
-
-<alarm> ... </alarm>
-Specifies alarmbits in the alarmstatus register..
-<bit> ... </bit>
-Status bit definition.
-<pos> ... </pos>
-Bit position as a decimal between 0 - 7 .
-<name> ... </name>
-Bit name.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Name in optional other language
-<description> ... </description>
-Bit description.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Description for optional other
-language
-
-<eda> ... </eda>
-Specifies eda capabilities for the node.
-<dmrows> ... </dmrows>
-The number of rows in the decision matrix as a decimal or a hexadecimal number. If in
-hex the number should be preceded with "0x0".
-<action> ... </action>
-Defines an available module specific action.
-<code> ... </code>
-The code for the action as a decimal or a hexadecimal number between 2 - 63. If in hex
-the number should be preceded with "0x0".
-<name> ... </name>
-Action name.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Name in optional other language
-<description> ... </description>
-Action description.
-<language>...</language>
-Language as an ISO code (same as domain extensions). Description for optional other
-language
-
-If the action can send an event, the event tag can also be defined here.
-
-
-<bootload> ... </bootload>
-Bootloader information
-<algorithm> ... </algorithm>
-Boot loader algorithm supported. For coding see Class=0, Type=12
-<blocksize> ... </blocksize>
-Block size for updateable area.
-<blockcount> ... </blockcount<
-Number of blocks available.
-
-
-EDA - Message handling and Rules
-Every message on a VSCP segment can be seen as an event. To be of any use to anyone a
-decision has to be taken on what to do as a result of the event. This is done in a
-decision-matrix, which is a standardized way to write the rules that take care of
-events. To get something done when a specific event is detected some sort of action
-mechanism is needed.
-The event-decision-action model or eda-model is the way we look at the functionality
-of a VSCP-node. First of all a node can be a level I or level II node. A level I node
-can perform actions from all level I messages. A level II node can handle both level I
-and level II messages. In fact when we define rules we define them at the highest
-level.
-
-The eda model
-To be able to build a software model that is common for several device/machine
-situation types and environments we have make a model to suit the typical control
-situation. The model is very simple and is also very easy to implement on different
-target environments.
-EVENT: Something happens that triggers some kind of input. This could be the elapse of
-a timer, a delivered temperature reading, a triggered fire alarm etc. Without this
-state there is nothing to do. We call this state the EVENT - state.
-DECISION: If an event occurs we may react in some way to this happening. This reaction
-comes after a decision about if and how the event should be handled. We use a decision
-matrix to control the logic of our decisions. Every element in the decision matrix
-handles one event and performs one action. A decision matrix element is also capable
-of generating events and can in this way perform several actions on the behalf of one
-event.
-ACTION: The action is the function, thread, procedure, method or other functionality
-that should be carried out as a result of an event.
-The states represented by EVENT + DECISION + ACTION are treated as one transaction.
-All steps must be handled for the transaction to be marked as completed.
-So when you describe the functionality of a VSCP-node you say
-This node reacts on the following events
-This node can perform the following actions.
-To make the node a useful piece of equipment it needs a decision matrix. This matrix
-can be implemented with no possibility for a user to change it or it can be undefined
-and left for the user to specify.
-
-
-Decision matrix for Level I nodes.
-In resource-limited environments, such as a microprocessor, the previously discussed
-matrix format takes up to much space and a more resource friendly format is therefore
-defined. Here the class + type bytes formats the event.
-This matrix has no trigger for data values. This has to be done internally by the
-application using user defined codes.
-A matrix row consists of 8 bytes and has the following format
-
-byte 0 - byte 7
- | oaddr | flags | class-mask | class-filter | type-mask | type-filter | action |
- action-param |
-
-oaddr
-oaddr is the originating address. We are only interested in messages from the node
-given here. 0x00 is segment controller and 0xff is a node without a nickname. If bit
-of flags are set oaddr will not be checked and events from all nodes will be accepted.
-
-flag
-bit 7 Enabled if set to 1.
-bit 6 oaddr should be checked (=1) or not checked (=0)
-bit 5 Indicates hardcoded originating address
-bit 4 Reserved
-bit 3 Reserved
-bit 2 Reserved
-bit 1 Class-mask bit 8.
-bit 0 Class-filter bit 8.
-The enable bit can be used to disable a decion matrix row while it is edited.
-
-class-mask / class-filter
-A class that should trigger this decision matrix row is defined in class-mask and
-class-filter with bit eight for both taken from the flags byte.
-
-The following table illustrates how this works
-
-Mask bit n
-Filter bit n
-Incoming event class bit n
-Accept or reject bit n
-0
-x
-x
-Accept
-1
-0
-0
-Accept
-1
-0
-1
-Reject
-1
-1
-0
-Reject
-1
-1
-1
-Accept
-
-So to only accept one class zset all mask bits to one and enter the class in filter.
-
-
-type-mask / type-filter
-A type that should trigger this decision matrix row is defined in type-mask and type
-filter with bit eight for both taken from the flags byte.
-A similar truth table as for the class-mask/filter is used.
-
-
-action
-
-This is the action or operation that should be performed if the filtering is
-satisfied. Only action code 0x00 is predefined and means No-Operation. All other
-codes are application specific and typical application defined codes could be do
-measurement, send predefined event etc
-action-parameter
-A numeric action can be set and its meaning is application specific.
-
-The number of matrix rows are limited in a micro controller. The control class has an
-event defined that gets the number of elements in the matrix and the location of the
-matrix in the register model of the node (Get EDA matrix info, CLASS1.PROTOCOL,
-Type=33).
-The matrix information is read and written with the standard read/write control
-functions. And is placed in the standard low register range (< 0x80) or in an optional
-page in this are.
-Note that there is no demand that a node implements a decision matrix. If not
-implemented the Get EDA matrix info just returns a zero size.
-A special paged feature is available for the decision matrix to save register space.
-If the offset for the decision matrix is 0x80 -8 i.e. Starts at 0X78 (120) it is
-implied that the register position just below 0x77(119) contains a register that is an
-index to the row that is available in the decision matrix space.
-Method CLASS1.PROTOCOL TYPE=32 is used to fetch decision matrix information for a
-specific node.
-
-General
-It is important to note that the decision matrix can contain any number of lines for a
-specific event element. So one incoming event can trigger many actions.
-Events are marked as handled when the action thread is started. This can be bad in
-some situations where the event chain is dependent on the action to complete its task
-before any new work is done. In this case it is better to continue the event chain by
-posting an event from the action thread instead of setting the following event as a
-next event in the decision matrix.
-The decision matrix structure gives us the freedom to implement events that perform
-
-Exactly one action.
-Several actions.
-Several actions in a sequence.
-Decision matrix for Level II nodes.
-To understand how the decision matrix is updated one needs to understand how it is set
-up. Each line of the matrix is built from a table of entries of the following form:
-Mask (32-bit)
-This is a bit mask, which has ones at the bit positions of the event that is
-interesting. So 0xffffffff makes all messages interesting. Class is in the high word.
-Type is in the low word. For a truth table see the class-mask for Level I decision
-matrices.
-Filter (32-bit)
-This is a bit mask, which tells the vaule for bits that is of iinterest. Class is in
-the high word. Type is in the low word. For a truth table see the class-mask for Level
-I decision matrices.
-Control(32-bit)
-Bit 31 - Enabled (if == 1). Indicates if this element in the decision matrix is
-enabled or disabled. If disabled the decision matrix element is ignored.
-Bit 30 -- Bit 0 Reserved
-
-Action (16-bit)
-This is the what should be carried out to make this action happen. This is a 16-bit
-cod that is application specific. 0X0000 is the only code that is predefined as no
-operation.
-Action Parameters
-This is a variable length text-string/binary array that can contain parameters for the
-action. Format is application dependent. Can be set omitted if no parameters are
-used.
-
-A decision matrix row is 14 bytes plus the size of the action parameters.
-A special paged feature is available for the decision matrix to save register space.
-If the offset for the decision matrix is 0x80 -dm-row-size it is implied that the
-register position just below 0x80 -dm-row-size - 1 contains a register that is an
-index to the row that is available in the decision matrix space.
-Method CLASS1.PROTOCOL TYPE=32 is used to fetch decision matrix information for a
-specific node. Byte six of the response tells the actual size for a decision matrix
-row.
-
-
-VSCP boot loader algorithm
-This is the VSCP boot loader. Note that several other low level boot loader mechanisms
-that are more suited for low memory footprint devices are available.
-Many devices of today have the capability for in circuit programming and can have
-their firmware changed whilst still in the system. This is supported by VSCP with boot
-loader events.
-
-Most flash devices are programmed block by block. The boot loader algorithm must
-support this. Blocks are usually quite small but to be compatible with future devices
-16-bit words are used to describe a block size. 16-bit words are also used to describe
-the number of available blocks. This means that the total Flash size is described by a
-32-bit word and the maximum flash size supported is thus four gigabytes.
-
-The boot loader sequence is as follows:
-
-1.)The master instructs the node to enter boot loader mode by sending an enter boot
-loader mode message to the node. A unit now can use the VSCP boot loader which is
-described here or another boot loader.
-2.)The node confirms that it is ready for code loading by sending the ACK boot loader
-mode message (a NACK boot loader mode message is also possible). Block size and
-number of blocks are sent as arguments in the acknowledge message.
-3.)The master sends a start block data transfer message to specify which block should
-be programmed and to initiate the transfer of data for the block.
-4.)The master sends one or several block data messages until the complete block is
-transferred.
-5.)When all data for a block is received by a node it sends a confirm block message to
-acknowledge the reception of a complete block.
-6.)The master now sends a program block message to the node to make it write the block
-buffer into flash memory.
-7.)The node confirms the block programming by responding with an ACK program block
-message.
-8.)The next block is handled or the node is taken out of the boot loader mode by
-sending a drop nickname/reset device message.
-9.)To activate the new program code the boot loader sends an activate new image event
-with the 16 bit CRC for the new block as an argument. The new node should come up
-after reboot.
-
-The 16-bit CCITT CRC is used.
-
-The bootloader is built to direct control flash if other methods such as intermediate
-storage is used. Data can be loaded direct and program block can just get a dummy ACK.
-Data coding
-All data is sent in a form that is related to the default format of the data. The
-number of data bytes in the frame also reflects the size of the variable.
-In this definition there is a very important assumption. If two nodes should be able
-to talk to each other they have to know each others data formats. So our assumption is
-that if a node is interested in what another node has to say it must learn its data
-format. Also if a node needs to control another node it has to learn its data format
-to do so.
-As a guideline the format defined bellow for the first data byte of a data frame can
-be used but if a user likes to use another format it is perfectly fine to do so.
-Byte 0 - Tells how data that follows should be interpreted. This is used for
-CLASS1.MEASUREMENT
-
-
-Bits
-Description
-5,6,7
-Represent one of several numerical representations in which the data that follows is
-represented in:
-000b Bit Format
-The data should be represented as a set of bits. This can be used for picture coding
-etc.
-
-001b Byte Format( 0x20 )
-The data should be represented as a set of bytes.
-
-010b String Format( 0x40 )
-The data should be represented as an ASCII string (possibly with language extensions
-(8-bit)).
-
-011b Integer Format( 0x60 )
-Data is coded as an integer. The integer is coded in the bytes that follows and can be
-1-7 bytes where the most significant byte always is in byte 1 (big endian).
-
-If DLC=2 the data is a 1 byte integer or 1 byte.
-If DLC=3 the data is a 16-bit integer or 2 bytes.
-If DLC=4 the data is a 24-bit integer or 3 bytes.
-If DLC=5 the data is a 32-bit integer or 4 bytes.
-If DLC=6 the data is a 40-bit integer or 5 bytes.
-If DLC=7 the data is a 48-bit integer or 6 bytes.
-If DLC=8 the data is a 56-bit integer or 7 bytes.
-
-100b Normalized Integer Format( 0x80 )
-Data is coded as a normalized integer. Byte 1 is the normalizer byte which have bit
-7 set for a negative value.. The test of the value is coded in the bytes that follows
-and can be 1-6 bytes where the most significant byte always is in byte 1 (big endian).
-The normalizer bytes lower six bits tells how many position the decimal point should
-be shifted left or right. If it has a negative value the decimal point should be
-shifted in the left direction and if it has a positive value in the right direction.
-
-101b Floating point value( 0xA0 )
-Data is coded as a IEEE-754 1985 floating point value
-s eeeeeeee mmmmmmmmmmmmmmmmmmmmmmm
-s = sign bit( 1-bit)
-e = exponent ( 8-bit)
-m = mantissa (23-bit)
-That is a total of 32-bits. The most significant byte is stored first. The frame holds
-a total of five bytes.
-
-The full definition is at http://www.psc.edu/general/software/packages/ieee/ieee.html
-
-110b Reserved.( 0xC0 )
-The format is yet to be defined.
-
-111b Reserved( 0xE0 ).
-The format is yet to be defined.
-3.4
-Indicates how the data should be interpreted:
-000b
-Standard format. All other codes in this field are message class/type specific.
-
-0,1,2
-This is the sensor index if there are more then one sensor handled by the node.
-
-Class Definitions Level I
-
-Class = 0 (0x00) VSCP Protocol functionality
-CLASS1.PROTOCOL
-Description
-This class defines some types that must be implemented by every node that implements
-the VSCP protocol. The types in this class must be handled by all level I and Level II
-nodes.
-Note also that this class is repeated as Level II class=512 whot the only dfifference
-that GUID's are used instead of nicknames.
-
-Type = 0 (0x00) Undefined.
-Undefined protocol function.
-
-Type = 1 (0x01) Segment Status Heartbeat.
-A segment controller sends this message once a second on the segment that it controls.
-The data field contains the 8-bit CRC of the segment controller GUID and the time
-since the Epoch (00:00:00 UTC, January 1, 1970) as a 32-bit value.
-Also other nodes can originate this event on the network. For these nodes the data
-part should be omitted.
-All nodes should save the 8-bit CRC in non-volatile storage and use it on power up.
-When a node starts up on a segment it should begin to listen for the Segment
-controller heartbeat. When/if it is received the node compares it with the stored
-value and if equal and the node is assigned a nickname id it continues to its working
-mode. If different, the node has detected that it has been moved to a new segment and
-therefore must drop its nickname id and enters the configuration mode to obtain a new
-nickname id from the segment controller.
-If the node is in working mode and it's nickname id changes, the node should do a
-complete restart after first setting all controls to their default state.
-As a segment can be without a segment controller this message is not available on all
-segments.
-Byte 0 8-bit CRC.
-Byte 1 MSB of time since Epoch (optional).
-Byte 2 Time since Epoch (optional).
-Byte 3 Time since Epoch (optional).
-Byte 4 LSB of time since Epoch (optional).
-Uninitiated nodes have the CRC of the segment controller set to 0xff.
-A node that is initialized on a segment and does not receive a Heartbeat can take the
-role of segment controller if it wishes to do so. Only one node one a segment are
-allowed to do this fully by setting its nickname=0 and therefore a standard node
-should not have this feature built in. Any node can however behave like a segment
-controler but use a nickname other then zero.
-Type = 2 (0x02) New node on line / Probe.
-This is intended for nodes that have been initiated, is part of the segment and is
-powered up. All nodes that have a nickname id that is not set to 0xff should send this
-message before they go on line to do their "day to day" work.
-Normally all nodes should save their assigned nickname id in nonvolatile memory and
-use this assigned id when powered up. A segment controller can however keep track of
-nodes that it controls and reassign the id to a node that it did not get a new node
-online message from. This is the method a segment controller uses to detect nodes that
-have been removed from the segment.
-For the nickname discovery procedure this event is used as the probe. The difference
-between a probe and a new node on line is that the later has the same originating
-nickname as value in byte 0.
-It is recommended that also level II nodes send this message when they come alive.
-Byte 0 - Target address - If specified this is a probe message that the new node is
-using to test if this is a valid target node. If there is a node with this nickname
-address it should answer with probe ack
-
-Type = 3 (0x03) Probe ACK.
-This message is sent from a node as a response to a probe. There are no arguments.
-
-Type = 4 (0x04) Nickname Failure.
- Sent to inform other nodes that a node failed to find a free nickname and will go off
- line.
-
-Type = 5 (0x05) Reserved for future use.
-
-Type = 6 (0x06) Set Nickname id for node.
-The message contains the new nickname id for a node that is in the initializing state.
-Byte 0 Old nickname for node. This is normally 0xff.
-Byte 1 The nickname for the node.
-
-Type = 7 (0x07) Nickname id accepted.
-A node sends this message to confirm that it accepts its assigned nickname id. When
-sending this message the node uses its newly assigned nickname address.
-
-
-Type = 8 (0x08) Drop nickname id / Reset Device.
-Request a node to drop its nickname. The node should drop its nickname and then behave
-in the same manner as when it was first powered up on the segment.
-Byte 0 The current nickname for the node.
-
-Type = 9 (0x09) Read register.
-Read a register from a node.
-Byte 0 Node address.
-Byte 1 Register to read.
-A read/write response message is returned on success.
-Note for event on a Level II network
-Byte 0 - byte 15 GUID
-Byte 16 Register to read
-
-Type=10 (0x0A) Read/Write response.
-Response for a read/write message. Note that the origin is given from the CAN header
-information. Note that the data is returned for both a read and a write and can be
-checked for validity.
-Byte 0 Register read/written.
-Byte 1 Content of register.
-
-Type = 11 (0x0B) Write Register.
-Write register content to a node.
-Byte 0 ...
[truncated message content] |
