Thread: [Can-svn] SF.net SVN: can: [802] trunk

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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 &copy; 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 &copy; 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 th...
 
[truncated message content]

Thread: [Can-svn] SF.net SVN: can: [802] trunk

can-svn