Menu
▾
▴
openlcb-svn-commits
|
From: <jac...@us...> - 2010-09-21 23:16:49
|
Revision: 937
http://openlcb.svn.sourceforge.net/openlcb/?rev=937&view=rev
Author: jacobsen
Date: 2010-09-21 23:16:43 +0000 (Tue, 21 Sep 2010)
Log Message:
-----------
and update links (last part)
Modified Paths:
--------------
trunk/specs/drafts/CanFrameTransferExpl.html
trunk/specs/drafts/CanFrameTransferSpec.html
trunk/specs/drafts/CanMessageNetworkExpl.html
trunk/specs/drafts/CanMessageNetworkSpec.html
Modified: trunk/specs/drafts/CanFrameTransferExpl.html
===================================================================
--- trunk/specs/drafts/CanFrameTransferExpl.html 2010-09-21 23:10:37 UTC (rev 936)
+++ trunk/specs/drafts/CanFrameTransferExpl.html 2010-09-21 23:16:43 UTC (rev 937)
@@ -22,7 +22,7 @@
</STYLE>
</HEAD>
<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
+<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
CAN Frame Transfer Explanation</H1>
<P>Much of this is just a collection of pieces from other docs right
now.</P>
Modified: trunk/specs/drafts/CanFrameTransferSpec.html
===================================================================
--- trunk/specs/drafts/CanFrameTransferSpec.html 2010-09-21 23:10:37 UTC (rev 936)
+++ trunk/specs/drafts/CanFrameTransferSpec.html 2010-09-21 23:16:43 UTC (rev 937)
@@ -6,13 +6,14 @@
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100919;20240300">
+ <META NAME="CHANGED" CONTENT="20100921;16153000">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<STYLE TYPE="text/css">
<!--
H2.ctl { font-family: "Lucida Sans" }
@@ -20,7 +21,7 @@
</STYLE>
</HEAD>
<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
+<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
CAN Frame Transfer Specification</H1>
<P><BR><BR>
</P>
@@ -29,6 +30,9 @@
<P>Some go as one frame, some as more. This specification describes
frame format and transfer.</P>
<H2 CLASS="western">Frame Format</H2>
+<P>29 bit extended only. Silent on standard-frames, though it's a
+good idea for nodes to tolerate them in case they're needed for e.g.
+bootloaders.</P>
<H2 CLASS="western">Node ID Alias Generation</H2>
<P><BR><BR>
</P>
Modified: trunk/specs/drafts/CanMessageNetworkExpl.html
===================================================================
--- trunk/specs/drafts/CanMessageNetworkExpl.html 2010-09-21 23:10:37 UTC (rev 936)
+++ trunk/specs/drafts/CanMessageNetworkExpl.html 2010-09-21 23:16:43 UTC (rev 937)
@@ -20,7 +20,7 @@
</STYLE>
</HEAD>
<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
+<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
CAN Message Network Explanation</H1>
<P>So far, mostly parts from other documents....</P>
<H1><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="David Harris"><!-- $Id$ -->OpenLCB
Modified: trunk/specs/drafts/CanMessageNetworkSpec.html
===================================================================
--- trunk/specs/drafts/CanMessageNetworkSpec.html 2010-09-21 23:10:37 UTC (rev 936)
+++ trunk/specs/drafts/CanMessageNetworkSpec.html 2010-09-21 23:16:43 UTC (rev 937)
@@ -19,7 +19,7 @@
</STYLE>
</HEAD>
<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
+<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
CAN Message Network Specification</H1>
<P>Body text starts here with a few words on page contents...</P>
<H2 CLASS="western">Common Parts</H2>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-09-22 05:47:02
|
Revision: 939
http://openlcb.svn.sourceforge.net/openlcb/?rev=939&view=rev
Author: jacobsen
Date: 2010-09-22 05:46:56 +0000 (Wed, 22 Sep 2010)
Log Message:
-----------
placeholder
Added Paths:
-----------
trunk/specs/drafts/CanEventTransportExpl.html
trunk/specs/drafts/CanEventTransportSpec.html
Added: trunk/specs/drafts/CanEventTransportExpl.html
===================================================================
--- trunk/specs/drafts/CanEventTransportExpl.html (rev 0)
+++ trunk/specs/drafts/CanEventTransportExpl.html 2010-09-22 05:46:56 UTC (rev 939)
@@ -0,0 +1,24 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>OpenLCB CAN Event Transport Explanation</TITLE>
+ <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
+ <META NAME="CREATED" CONTENT="0;0">
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+<H1><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2>
+OpenLCB CAN Event Transport Explanation
+</H1>
+<P>Body text starts here with a few words on page contents...</P>
+<h2>H2 is biggest standard body heading</h2>
+<P>OpenLCB is ...
+
+<HR>
+<P>Site hosted by <FONT COLOR="#000080">
+<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
+</P>
+<P>This is SVN $Revision$
+</P>
+</BODY>
+</HTML>
\ No newline at end of file
Property changes on: trunk/specs/drafts/CanEventTransportExpl.html
___________________________________________________________________
Added: svn:mime-type
+ text/html
Added: svn:keywords
+ Id Revision
Added: svn:eol-style
+ native
Added: trunk/specs/drafts/CanEventTransportSpec.html
===================================================================
--- trunk/specs/drafts/CanEventTransportSpec.html (rev 0)
+++ trunk/specs/drafts/CanEventTransportSpec.html 2010-09-22 05:46:56 UTC (rev 939)
@@ -0,0 +1,24 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>OpenLCB CAN Event Transport Specification</TITLE>
+ <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
+ <META NAME="CREATED" CONTENT="0;0">
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+<H1><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2>
+OpenLCB CAN Event Transport Specification
+</H1>
+<P>Body text starts here with a few words on page contents...</P>
+<h2>H2 is biggest standard body heading</h2>
+<P>OpenLCB is ...
+
+<HR>
+<P>Site hosted by <FONT COLOR="#000080">
+<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
+</P>
+<P>This is SVN $Revision$
+</P>
+</BODY>
+</HTML>
\ No newline at end of file
Property changes on: trunk/specs/drafts/CanEventTransportSpec.html
___________________________________________________________________
Added: svn:mime-type
+ text/html
Added: svn:keywords
+ Id Revision
Added: svn:eol-style
+ native
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-09-22 17:27:33
|
Revision: 946
http://openlcb.svn.sourceforge.net/openlcb/?rev=946&view=rev
Author: jacobsen
Date: 2010-09-22 17:27:27 +0000 (Wed, 22 Sep 2010)
Log Message:
-----------
placeholder
Added Paths:
-----------
trunk/specs/drafts/GenNodeIdAllocationExpl.html
trunk/specs/drafts/GenNodeIdAllocationSpec.html
Added: trunk/specs/drafts/GenNodeIdAllocationExpl.html
===================================================================
--- trunk/specs/drafts/GenNodeIdAllocationExpl.html (rev 0)
+++ trunk/specs/drafts/GenNodeIdAllocationExpl.html 2010-09-22 17:27:27 UTC (rev 946)
@@ -0,0 +1,33 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>OpenLCB Node ID Explanation</TITLE>
+ <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
+ <META NAME="CREATED" CONTENT="0;0">
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+<H1><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2>
+OpenLCB Node ID Explanation
+</H1>
+
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<HR>
+<P>Below this is just a collection of pieces from other docs right
+now.</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+
+<HR>
+<P>Site hosted by <FONT COLOR="#000080">
+<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
+</P>
+<P>This is SVN $Revision$
+</P>
+</BODY>
+</HTML>
\ No newline at end of file
Property changes on: trunk/specs/drafts/GenNodeIdAllocationExpl.html
___________________________________________________________________
Added: svn:mime-type
+ text/html
Added: svn:keywords
+ Id Revision
Added: svn:eol-style
+ native
Added: trunk/specs/drafts/GenNodeIdAllocationSpec.html
===================================================================
--- trunk/specs/drafts/GenNodeIdAllocationSpec.html (rev 0)
+++ trunk/specs/drafts/GenNodeIdAllocationSpec.html 2010-09-22 17:27:27 UTC (rev 946)
@@ -0,0 +1,33 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>OpenLCB Node ID Specification</TITLE>
+ <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
+ <META NAME="CREATED" CONTENT="0;0">
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+<H1><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2>
+OpenLCB Node ID Specification
+</H1>
+
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<HR>
+<P>Below this is just a collection of pieces from other docs right
+now.</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+
+<HR>
+<P>Site hosted by <FONT COLOR="#000080">
+<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
+</P>
+<P>This is SVN $Revision$
+</P>
+</BODY>
+</HTML>
\ No newline at end of file
Property changes on: trunk/specs/drafts/GenNodeIdAllocationSpec.html
___________________________________________________________________
Added: svn:mime-type
+ text/html
Added: svn:keywords
+ Id Revision
Added: svn:eol-style
+ native
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-09-22 17:28:13
|
Revision: 947
http://openlcb.svn.sourceforge.net/openlcb/?rev=947&view=rev
Author: jacobsen
Date: 2010-09-22 17:28:07 +0000 (Wed, 22 Sep 2010)
Log Message:
-----------
placeholder
Added Paths:
-----------
trunk/specs/drafts/GenNodeIdExpl.html
trunk/specs/drafts/GenNodeIdSpec.html
Copied: trunk/specs/drafts/GenNodeIdExpl.html (from rev 946, trunk/specs/drafts/GenNodeIdAllocationExpl.html)
===================================================================
--- trunk/specs/drafts/GenNodeIdExpl.html (rev 0)
+++ trunk/specs/drafts/GenNodeIdExpl.html 2010-09-22 17:28:07 UTC (rev 947)
@@ -0,0 +1,33 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>OpenLCB Node ID Explanation</TITLE>
+ <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
+ <META NAME="CREATED" CONTENT="0;0">
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+<H1><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2>
+OpenLCB Node ID Explanation
+</H1>
+
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<HR>
+<P>Below this is just a collection of pieces from other docs right
+now.</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+
+<HR>
+<P>Site hosted by <FONT COLOR="#000080">
+<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
+</P>
+<P>This is SVN $Revision$
+</P>
+</BODY>
+</HTML>
\ No newline at end of file
Copied: trunk/specs/drafts/GenNodeIdSpec.html (from rev 946, trunk/specs/drafts/GenNodeIdAllocationSpec.html)
===================================================================
--- trunk/specs/drafts/GenNodeIdSpec.html (rev 0)
+++ trunk/specs/drafts/GenNodeIdSpec.html 2010-09-22 17:28:07 UTC (rev 947)
@@ -0,0 +1,33 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>OpenLCB Node ID Specification</TITLE>
+ <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
+ <META NAME="CREATED" CONTENT="0;0">
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+<H1><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2>
+OpenLCB Node ID Specification
+</H1>
+
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<HR>
+<P>Below this is just a collection of pieces from other docs right
+now.</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+
+<HR>
+<P>Site hosted by <FONT COLOR="#000080">
+<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
+</P>
+<P>This is SVN $Revision$
+</P>
+</BODY>
+</HTML>
\ No newline at end of file
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-09-22 17:44:53
|
Revision: 948
http://openlcb.svn.sourceforge.net/openlcb/?rev=948&view=rev
Author: jacobsen
Date: 2010-09-22 17:44:44 +0000 (Wed, 22 Sep 2010)
Log Message:
-----------
renamed to GenNodeIdEplt/Spec
Removed Paths:
-------------
trunk/specs/drafts/GenNodeIdAllocationExpl.html
trunk/specs/drafts/GenNodeIdAllocationSpec.html
Deleted: trunk/specs/drafts/GenNodeIdAllocationExpl.html
===================================================================
--- trunk/specs/drafts/GenNodeIdAllocationExpl.html 2010-09-22 17:28:07 UTC (rev 947)
+++ trunk/specs/drafts/GenNodeIdAllocationExpl.html 2010-09-22 17:44:44 UTC (rev 948)
@@ -1,33 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB Node ID Explanation</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2>
-OpenLCB Node ID Explanation
-</H1>
-
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Deleted: trunk/specs/drafts/GenNodeIdAllocationSpec.html
===================================================================
--- trunk/specs/drafts/GenNodeIdAllocationSpec.html 2010-09-22 17:28:07 UTC (rev 947)
+++ trunk/specs/drafts/GenNodeIdAllocationSpec.html 2010-09-22 17:44:44 UTC (rev 948)
@@ -1,33 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB Node ID Specification</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2>
-OpenLCB Node ID Specification
-</H1>
-
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-09-22 19:17:09
|
Revision: 949
http://openlcb.svn.sourceforge.net/openlcb/?rev=949&view=rev
Author: jacobsen
Date: 2010-09-22 19:17:02 +0000 (Wed, 22 Sep 2010)
Log Message:
-----------
more detail, separate Exp and Spec
Added Paths:
-----------
trunk/specs/drafts/TemplateExpl.html
trunk/specs/drafts/TemplateSpec.html
Added: trunk/specs/drafts/TemplateExpl.html
===================================================================
--- trunk/specs/drafts/TemplateExpl.html (rev 0)
+++ trunk/specs/drafts/TemplateExpl.html 2010-09-22 19:17:02 UTC (rev 949)
@@ -0,0 +1,47 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>OpenLCB S&E Template</TITLE>
+ <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
+ <META NAME="CREATED" CONTENT="0;0">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGED" CONTENT="20100922;11035500">
+ <STYLE TYPE="text/css">
+ <!--
+ H3.ctl { font-family: "Lucida Sans" }
+ H2.ctl { font-family: "Lucida Sans" }
+ -->
+ </STYLE>
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
+Explanation Template
+</H1>
+<H2 CLASS="western">Introduction</H2>
+<P>This explanatory note contains informative discussion and
+background for the corresponding “OpenLCB ... Specification”.
+This explanation is not normative in any way.</P>
+<H2 CLASS="western">Annotations to the Specification</H2>
+<P>This section provides background information on corresponding
+sections of the Specification document. It's expected that two
+documents will be read together.</P>
+<H3 CLASS="western">Introduction</H3>
+<H3 CLASS="western">References and Context</H3>
+<P><BR><BR>
+</P>
+<HR>
+<P>Below this is just a collection of pieces from other docs right
+now.</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<HR>
+<P>Site hosted by <FONT COLOR="#000080">
+<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
+</P>
+<P>This is SVN $Revision$
+</P>
+</BODY>
+</HTML>
\ No newline at end of file
Property changes on: trunk/specs/drafts/TemplateExpl.html
___________________________________________________________________
Added: svn:mime-type
+ text/html
Added: svn:keywords
+ Id Revision
Added: svn:eol-style
+ native
Copied: trunk/specs/drafts/TemplateSpec.html (from rev 938, trunk/specs/drafts/Template.html)
===================================================================
--- trunk/specs/drafts/TemplateSpec.html (rev 0)
+++ trunk/specs/drafts/TemplateSpec.html 2010-09-22 19:17:02 UTC (rev 949)
@@ -0,0 +1,43 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
+ <TITLE>OpenLCB S&E Template</TITLE>
+ <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
+ <META NAME="CREATED" CONTENT="0;0">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGED" CONTENT="20100922;11062900">
+ <STYLE TYPE="text/css">
+ <!--
+ H2.ctl { font-family: "Lucida Sans" }
+ -->
+ </STYLE>
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
+S&E Template
+</H1>
+<H2 CLASS="western">Introduction (Informative)</H2>
+<P>This specification describes ...</P>
+<H2 CLASS="western">References and Context (Normative)</H2>
+<P>This specification is in the context of the OpenLCB-CAN …
+Specification, which specifies …</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<HR>
+<P>Below this is just a collection of pieces from other docs right
+now.</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<HR>
+<P>Site hosted by <FONT COLOR="#000080">
+<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
+</P>
+<P>This is SVN $Revision$
+</P>
+</BODY>
+</HTML>
\ No newline at end of file
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-09-23 08:48:36
|
Revision: 955
http://openlcb.svn.sourceforge.net/openlcb/?rev=955&view=rev
Author: jacobsen
Date: 2010-09-23 08:48:29 +0000 (Thu, 23 Sep 2010)
Log Message:
-----------
still working on 0.0 draft
Modified Paths:
--------------
trunk/specs/drafts/CanFrameTransferExpl.html
trunk/specs/drafts/CanFrameTransferSpec.html
trunk/specs/drafts/CanMessageNetworkExpl.html
trunk/specs/drafts/CanMessageNetworkSpec.html
Modified: trunk/specs/drafts/CanFrameTransferExpl.html
===================================================================
--- trunk/specs/drafts/CanFrameTransferExpl.html 2010-09-23 08:47:54 UTC (rev 954)
+++ trunk/specs/drafts/CanFrameTransferExpl.html 2010-09-23 08:48:29 UTC (rev 955)
@@ -6,10 +6,16 @@
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100921;20544000">
+ <META NAME="CHANGED" CONTENT="20100922;23132300">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<STYLE TYPE="text/css">
<!--
H2.ctl { font-family: "Lucida Sans" }
@@ -26,62 +32,12 @@
background for the corresponding “OpenLCB CAN Frame Transfer
Specification”. This explanation is not normative in any way.</P>
<P>Have to avoid collisions by design, not by luck.</P>
+<P>OpenLCB assumes(?) a global communications fabric: any node can
+send a message to any node, and any node can send a message to all
+nodes. This document describes how CAN is used to do that.</P>
<P>Cannot (do not assume) one of anything, including node managers,
etc. If you allow for more than zero, it has to be any number.</P>
<P>Fully traceability also assures no collisions.</P>
-<H2 CLASS="western">Annotations to the Specification</H2>
-<P>This section provides background information on corresponding
-sections of the Specification document. It's expected that two
-documents will be read together.</P>
-<H3 CLASS="western">Introduction</H3>
-<H3 CLASS="western">References and Context</H3>
-<H3 CLASS="western">Frame Format</H3>
-<P>The specification is silent on the uses for standard (11-bit
-header) frames. The proper-operation require is so nodes tolerate
-them in case they're needed for e.g. bootloaders. This could also
-have been phrased as “shall ignore ...”, but the current phrasing
-is thought to be more exact.</P>
-<P>We don't use RTR because CAN semantics require a specific use for
-it, which has been built into some silicon implementations. There are
-also some arbitration issues, see: CiA Application Note 802 (2005)
-and <A HREF="http://www.thecanmancan.com/?tag=rtr">http://www.thecanmancan.com/?tag=rtr</A>
-for more information.</P>
-<P>The MSB is likely to be used as a priority-boost bit in the
-future, e.g. so that a gateway can gain priority access to the CAN
-segment for various operations that require synchronization or
-atomicity. CAN encodes “do first” priority as 0 and “do later”
-as 1, so the specification requires that a 1 bit be sent. To preserve
-the utility of this, nodes must not require either a 1 nor 0 on
-receipt.</P>
-<P><BR><BR>
-</P>
-<H3 CLASS="western">Link State</H3>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<P>Discuss the use of repeaters, bridges and gateways w.r.t. Timing;
-ref physical layer. Possibility of reordering.</P>
-<P><BR><BR>
-</P>
-<H1 STYLE="page-break-before: always">From<!-- $Id$ --><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
-CAN Wire Protocol document</H1>
-<P>CAN bus (ISO 11898-*) provides a very convenient transport medium
-for OpenLCB on a specific module or layout. This section defines a
-specific wire protocol for transporting OpenLCB over CAN bus.
-</P>
-<P>Common OpenLCB messages need to be translated for transport via
-CAN 2.0B frames because of the limited CAN frame sizes and to take
-advantage of CAN interface features such as filtering on the header
-bits.
-</P>
<P>The adaptations include
</P>
<UL>
@@ -102,17 +58,6 @@
specific timing, deliberate creation of error cases or specific error
handling.
</P>
-<H2 CLASS="western">Physical Layer</H2>
-<P>The physical layer of OpenLCB-CAN is 125kbps CAN over twisted pair
-wiring. The NMRA is attempting to define a common physical layer for
-use across multiple implementations, and that may in turn define the
-physical layer of OpenLCB-CAN.</P>
-<P>For more information, see the separate <A HREF="../documents/can/CommonPlatform.html">Common
-CAN Platform</A> document.</P>
-<H2 CLASS="western">Link Layer</H2>
-<P>OpenLCB common messages are converted, to the extent possible, to
-single CAN frames via a one-to-one mapping.
-</P>
<P>The translations include:
</P>
<UL>
@@ -126,36 +71,52 @@
the specific CAN segment, it is used in the CAN header for
arbitration.
</P>
- <LI><P STYLE="margin-bottom: 0cm">MTIs may have to be shortened,
- depending on bit allocations.
- </P>
<LI><P>When possible, Destination NIDs are also mapped to the
shorter form. In some OpenLCB messages, this is not possible, in
which case the full NID form is sent; a bit is provided to indicate
which format is carried.
</P>
</UL>
-<P>Design decisions:</P>
+<P STYLE="margin-bottom: 0cm">The CAN format has been allocated on
+nibble boundaries to make it easier to e.g. read dumps of packets.
+The header is considered to be right (LSB) aligned.</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
<UL>
- <LI><P STYLE="margin-bottom: 0cm">The CAN format has been allocated
- on nibble boundaries to make it easier to e.g. read dumps of
- packets. The header is considered to be right (LSB) aligned.</P>
- <LI><P STYLE="margin-bottom: 0cm">A specific mapping from the common
- 16-bit MTI format to a shorter CAN format is documented in a
- <A HREF="../documents/MtiAllocations.ods">separate worksheet</A>
- (<A HREF="../documents/MtiAllocations.pdf">PDF version</A>). The
- common form is 16 bits to have lots of space to grow at the high
- end, but it can be mapped into a 8 bit field for efficient CAN
- transfer.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Nodes must handle full rate
- messages, specifically including messages not addressed to them.
- (The datagram and stream protocols provide ways for nodes to
- indicate whether or not they have sufficient buffering for the next
- transmission, triggering retries as needed) For long term
- reliability, a node <U>must</U> be able to completely process an
- entire CAN frame in the time it takes to receive the next one, which
- may be as little as 64 bit times, or about 500 microseconds.</P>
+ <LI><P STYLE="margin-bottom: 0cm">Designers may wish to use CAN
+ hardware filtering, but it can't be assumed to be present. We assign
+ a single bit to indicate “simple node protocol” messages to make
+ simple filtering possible.</P>
+</UL>
+<H2 CLASS="western">Annotations to the Specification</H2>
+<P>This section provides background information on corresponding
+sections of the Specification document. It's expected that two
+documents will be read together.</P>
+<H3 CLASS="western">Introduction</H3>
+<H3 CLASS="western">References and Context</H3>
+<H3 CLASS="western">Frame Format</H3>
+<P>OpenLCB uses a very vanilla transfer of frames, no special
+features, to reduce complexity and increase robustness.</P>
+<P>Standard header frames are also known as CAN 2.0A frames. Extended
+header frames are also known as CAN 2.0B frames.</P>
+<P>The specification is silent on the uses for standard (11-bit
+header) frames. The proper-operation require is so nodes tolerate
+them in case they're needed for e.g. bootloaders. This could also
+have been phrased as “shall ignore ...”, but the current phrasing
+is thought to be more exact.</P>
+<P>We don't use RTR because CAN semantics require a specific use for
+it, which has been built into some silicon implementations. There are
+also some arbitration issues, see: CiA Application Note 802 (2005)
+and <A HREF="http://www.thecanmancan.com/?tag=rtr">http://www.thecanmancan.com/?tag=rtr</A>
+for more information.</P>
+<P>The MSB is likely to be used as a priority-boost bit in the
+future, e.g. so that a gateway can gain priority access to the CAN
+segment for various operations that require synchronization or
+atomicity. CAN encodes “do first” priority as 0 and “do later”
+as 1, so the specification requires that a 1 bit be sent. To preserve
+the utility of this, nodes must not require either a 1 nor 0 on
+receipt.</P>
+<UL>
<LI><P>A 1-bit field priority field coarsely specifies the priority
of the message in terms of CAN arbitration to be high (pri=0) or low
(pri=1). By default, all messages are to be emitted with low
@@ -167,99 +128,14 @@
preempt the sending of responses to nodes over receiving new
requests to prevent message buffer overflow. This field is separate
from the static priority field in the MTI format specification.</P>
- <LI><P>Designers may wish to use CAN hardware filtering, but it
- can't be assumed to be present. We assign a single bit to indicate
- “simple node protocol” messages to make simple filtering
- possible.</P>
+ <LI><P></P>
</UL>
-<P>Header content and sizes (Nominal decisions shown, 29 bit header):
-</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Priority bit (Always sent as 1
- now; at front to ensure it acts like a true priority; 0 for high
- priority, 1 for low; not checked by receivers)
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Frame Type (1 bit) OpenLCB message
- or CAN control message
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Variable Field (15 bits)
- </P>
- <LI><P>Source NID alias (12 bits)
- </P>
-</UL>
-<P>The order of these fields is chosen to get proper priority and
-access disambiguation via CAN's standard mechanisms.</P>
-<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
- <COL WIDTH=64*>
- <COL WIDTH=64*>
- <COL WIDTH=64*>
- <COL WIDTH=64*>
- <TR VALIGN=TOP>
- <TH WIDTH=25%>
- <P>Bit 0</P>
- </TH>
- <TH WIDTH=25%>
- <P>Bits 1</P>
- </TH>
- <TH WIDTH=25%>
- <P>Bits 2-16</P>
- </TH>
- <TH WIDTH=25%>
- <P>Bits 17-28</P>
- </TH>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Priority: 0 high, 1 low</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Frame Type</P>
- <P ALIGN=CENTER>1: OpenLCB Message</P>
- <P ALIGN=CENTER>0: CAN Control Message</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Variable Field</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Source NID Alias</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x1000,0000</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x0800,0000</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x07FF,F000</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x0000,0FFF</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Solo top bit</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Top bit of 6<SUP>th</SUP> nibble from right</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>3 bits lower bits, then three nibbles</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Right-most three nibbles</P>
- </TD>
- </TR>
-</TABLE>
-<P STYLE="margin-bottom: 0cm">The "Variable field" has
-different meanings depending on the "Frame Type" field. CAN
-control messages are identified with a Frame Type bit of 0, to ensure
-high priority.</P>
<P STYLE="margin-bottom: 0cm"><I>Document no-seven-1-bits-in-top-11
limitation to ensure future selections don't violate it.</I></P>
-<H3 CLASS="western">Throughput and Temporarily Deaf Nodes</H3>
+<H3 CLASS="western">Link State</H3>
+<P><BR><BR>
+</P>
+<H4 CLASS="western">Throughput and Temporarily Deaf Nodes</H4>
<P>OpenLCB requires that CAN-attached nodes be able to handle the
full frame rate on the CAN bus. There is no guarantee that frames for
a given node will arrive with non-zero time between then.
@@ -279,290 +155,82 @@
modified the OpenLCB node state, which are now lost (e.g. drop alias,
CIM/RIM in absence, or even higher level events)
</P>
-<H2 CLASS="western">CAN-specific Control Messages and Interactions</H2>
-<P>These are identified by the Frame Type bit being 0. They are
-formatted as shown in the following table:</P>
-<P STYLE="margin-bottom: 0cm"><BR>
+<P><BR><BR>
</P>
-<TABLE WIDTH=762 BORDER=1 CELLPADDING=2 CELLSPACING=4>
- <COL WIDTH=317>
- <COL WIDTH=423>
- <TR>
- <TH WIDTH=317>
- <P>Name</P>
- </TH>
- <TH WIDTH=423>
- <P>Variable Field</P>
- </TH>
- </TR>
- <TR>
- <TD WIDTH=317>
- <P>Check ID (CIM) message</P>
- </TD>
- <TD WIDTH=423>
- <P>MMM,NNNN,NNNN,NNNN
- </P>
- <P>where MMM is the message sequence number, 0x7 to 0x4 (to give
- priority to messages later in the process)</P>
- <P>and NNNN,NNNN,NNNN is the 12-bit Node ID section being checked</P>
- </TD>
- </TR>
- <TR>
- <TD WIDTH=317>
- <P>Reserved ID (RIM) Message</P>
- </TD>
- <TD WIDTH=423>
- <P>0x0700</P>
- </TD>
- </TR>
- <TR>
- <TD WIDTH=317>
- <P>Mapping Reset (MR) Message</P>
- </TD>
- <TD WIDTH=423>
- <P>0x0701</P>
- </TD>
- </TR>
- <TR>
- <TD WIDTH=317>
- <P>Reserved</P>
- </TD>
- <TD WIDTH=423>
- <P>All others</P>
- </TD>
- </TR>
-</TABLE>
-<H3 CLASS="western">CANid assignment</H3>
-<P>The common message format uses full 48-bit node ID numbers to
-identify originating nodes and in some case destination nodes. CAN
-frames use 12-bit local "NID alias" for these to save space
-in the limited-size CAN payload.
+<P>Eventually may have to allow use of Overload Frames to throttle
+for e.g. NVRAM writing.</P>
+<P><BR><BR>
</P>
-<P>The standard Verify Node ID Number interaction can be used to get
-the full 48-bit NID from a node for translation. At power up each
-node must obtain a alias that is locally unique. Gateways will also
-have to obtain unique aliases for remote nodes they are proxying on
-to the segment.
-</P>
-<P>Proposed algorithm, in rough form:
-</P>
+<H3 CLASS="western">State machine</H3>
+<P>E.g. Higher level starts link control by providing a valid NID and
+telling to to start off.</P>
+<H2 CLASS="western">On the choice of a 12-bit alias length</H2>
+<P>How big should the NodeID alias field be on CAN links?</P>
<UL>
- <LI><P STYLE="margin-bottom: 0cm">Compute a CANid from the NID using
- a standard algorithm.
+ <LI><P>Smaller (fewer bits) allows more payload and/or simpler
+ coding of other parts of messages.
</P>
- <LI><P STYLE="margin-bottom: 0cm">Send CAN frames claiming that
- CANid and carrying sequential parts of NID in the Variable Field
- section of the header.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">If error, step the algorithm in a
- standard way and repeat until success.
- </P>
- <LI><P>Send a CAN frame announcing that the node has claimed an ID
- value.
- </P>
+ <LI><P>Larger allows more unique nodes to be accessed.</P>
</UL>
-<P>Note that there is no requirement that this alias be consistent
-from one run to the next. More detail is on a <A HREF="../documents/can/CanIDAllocation.html">separate
-page</A>.
+<H3 CLASS="western">Issues</H3>
+<H4 CLASS="western">Addressing</H4>
+<P>The Node ID size limits the number of unique nodes that can take
+part in communications on the CAN segment. Because Node ID aliases
+are assigned independently on each CAN segment, the only issue is how
+many different nodes are involved, not which ones they are or what
+pattern(s) are available in their address numbers.</P>
+<P>For electrical/timing reasons, a segment itself can only support a
+maximum of about 50 nodes, but communication also involves nodes off
+the segment. For example, chaining N CAN segments via bridges will
+generally make up to 50*N nodes available. We have a use case of
+chaining small numbers of CAN segments together, implying the need to
+address 500 or 1000 nodes.
</P>
-<H3 CLASS="western">CAN-specific messages</H3>
-<P>Most CAN frames are one-to-one or many-to-one equivalents of
-common OpenLCB messages.
+<P>As another example, a very large network might connect many CAN
+segments via TCP/IP or other networked connections. Each CAN-attached
+node might need to communicate with a larger number of others spread
+across that network.</P>
+<P>(CAN backbone case)</P>
+<P>In some cases, want 2 aliases (source and destination), plus a few
+more bits, in 29 bits total. 29-(2*12) = 5 is a pretty compelling
+choice.</P>
+<H4 CLASS="western">Collisions during Allocation</H4>
+<P>(not talking CAN arbitration here, but two nodes trying to use
+same alias) The allocation process resolves collisions (attempt to
+use an already allocated Node ID alias), but that takes time.
+Minimizing the number of collisions is good. If the address space is
+just the size of the number of things you want to address, the
+collisions get hard /slow to resolve across multiple nodes. This
+points to having a factor of 2, at least, between the number of nodes
+to be addressed and the size of the address space.</P>
+<P>(Mostly talking about separate nodes here, not just one big
+interface node: Points to CAN backbone case)</P>
+<H4 CLASS="western">Size</H4>
+<P>Reducing size most important (so far) in the stream protocol.</P>
+<P>Events and Datagrams can be transmitted with a 16-bit alias size.</P>
+<P>To get the full payload (8 bytes) for streaming requires getting
+the rest of the protocol control, including two aliases for source
+and destination, in the 29 bit header. Allowing 1 bit for
+priority/extension, 1 for protocol control, 3 for MTI and stream
+control (all very bare minima) leads to a 12-bit node ID alias
+length.
</P>
-<P>A few additional messages are used for CAN-specific purposes.
+<H4 CLASS="western">Simplicity</H4>
+<P>Byte vs nibble vs bit boundaries in code, when debugging the
+protocol, etc.</P>
+<P>Having extra bits available in the header allows much simpler MTI
+coding, reserving specific bits for expansion instead of codes, etc.</P>
+<H4 CLASS="western">Filtering</H4>
+<P>Having the destination short enough to be in the header allows
+automated filtering of traffic. Nodes must still deal with the full
+rate, because messages can always be adjacent in time.</P>
+<P><BR><BR>
</P>
-<DL>
- <DT>CIM</DT><DD>
- Check ID Message - used as part of the <A HREF="../documents/can/CanIDAllocation.html">ID
- allocation</A>.
- </DD><DT>
- RIM</DT><DD>
- Reserved ID Message - used as part of the <A HREF="../documents/can/CanIDAllocation.html">ID
- allocation</A>.
- </DD><DT>
- MR</DT><DD STYLE="margin-bottom: 0.5cm">
- Mapping Reset - indicates that the local alias in the source address
- field may no longer be associated with the same NID, and mapping
- tables should be reset.
- </DD></DL>
-<H2 CLASS="western">
-Translation</H2>
-<P>A node must be able to convert traffic on the local CAN segment
-into the common message format using only locally available
-information. This may be needed e.g. by a gateway or monitoring
-program attached to the CAN segment.
+<P>(Need to discuss the case of two segments being joined, to
+discover they've both arbitrated the same aliases, including with
+gateways on one or both)</P>
+<P><BR><BR>
</P>
-<P>All traffic on a CAN segment uses aliases for both Source ID
-(always) and Destination ID (when the full NID isn't known).
-</P>
-<P>If/when a full NID is needed, it can be obtained by sending a
-"Verify Node ID Number (Addressed)" message with an
-appropriate Destination Node ID in local alias form. The reply will
-eventually come back with the Source ID in local alias form and
-carrying the full NID in the message content.
-</P>
-<P>Aliases for nodes on the local segment are only valid until an
-"Initialization Complete" is seen from that alias.
-Initialization Complete indicates that a node has restarted, and may
-have another local alias.
-</P>
-<P>Gateways maintain the mapping between remote node's NID and local
-alias. If they need to break that mapping, e.g. because they need to
-reuse the local alias due to resource limitations in the mapping
-tables, they must send a "Mapping Reset" message to force
-nodes to drop their alias information. <I>"Mapping Reset"
-is a CAN-specific message limited to the segment, but all gateways on
-the segment must act on it.</I>
-</P>
-<P>Gateways may not be able ensure permanent validity for alias to
-remote NIDs. For example, if they have a limited routing table, they
-may need to reuse local alias. Before reusing them, they have to send
-a "Mapping Reset" frame to drop references to the old NID,
-followed by a "Initialization Complete" when the alias is
-allocated to a new NID.
-</P>
-<H3 CLASS="western">Map Acquisition</H3>
-<P><A NAME="todo"></A>In order to acquire the map between CANids and
-NIDs, a gateway needs to be able to send a CAN frame requiring
-"everybody reply with your NID". Much like Ethernet gateway
-mapping, this needs to return the NID of just the specific
-CAN-attached hardware, not all the NIDs that can be e.g. reached
-through a gateway, so it needs to be a segment-specific message
-defined only at the CAN level. It must not be a OpenLCB common
-message.
-</P>
-<H2 CLASS="western">OpenLCB message format</H2>
-<P>OpenLCB common messages are carried in frames with a 1 in the
-Frame Type field. They contain message type information and/or
-address information in the 15-bit variable field, and zero to eight
-CAN data bytes.</P>
-<P STYLE="font-style: normal">For OpenLCB messages, the variable
-field is used in three forms:</P>
-<UL>
- <LI><P STYLE="font-style: normal">Unaddressed messages – messages
- that don't have a destination address put the low 12 bits of the MTI
- in the variable field</P>
- <LI><P STYLE="font-style: normal">Addressed messages – messages
- that have a specific destination address put it in the variable
- field, and carry the MTI in the payload. This allows filtering.</P>
- <LI><P STYLE="font-style: normal">Stream addressed messages – as a
- special case to improve efficiency of transfer, the streaming
- protocol uses 12 bits of the variable field to identify a particular
- stream transfer. This is not the same as a destination NodeID alias,
- but performs a similar function to allow filtering while also
- allowing multiple streams from a source.</P>
-</UL>
-<P STYLE="margin-bottom: 0cm">The variable field is allocated:</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
- <COL WIDTH=96*>
- <COL WIDTH=160*>
- <TR VALIGN=TOP>
- <TH WIDTH=37%>
- <P>Variable Field Bits 0-2</P>
- <P>Header Bits 2-4</P>
- <P>OpenLCB Format</P>
- <P>0x0700,0000</P>
- </TH>
- <TH WIDTH=63%>
- <P>Variable Field Bits 3-14</P>
- <P>Header Bits 5-16</P>
- <P>OpenLCB Variable Header Content</P>
- <P>0x00FF,F000</P>
- </TH>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 0 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>MTI & additional information for “simple
- node” unaddressed messages</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 0 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>MTI & additional information for unaddressed
- messages other than “simple node” forms</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 0 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>(Reserved, must not be sent or accepted)</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 1 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>(Reserved for long-form MTIs in data area, <BR>must
- not be sent or accepted)</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 0 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for datagram message non-last
- fragment</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 0 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for datagram message last
- fragment</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 1 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for non-datagram addressed
- messages</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 1 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for Stream Data Send messages</P>
- </TD>
- </TR>
-</TABLE>
-<P>Putting the destination alias in the header allows filtering on it
-with common CAN hardware. Putting the Stream ID in the header also
-allows filtering, and preserves the full 8-byte CAN payload for
-stream data.</P>
-<P><SPAN STYLE="font-style: normal">The specific MTI values are being
-allocated in a <A HREF="../documents/MtiAllocations.ods">separate
-worksheet</A> (<A HREF="../documents/MtiAllocations.pdf">PDF
-version</A>). In general, the MTI selection is done on the top 8 bits
-of the variable field. This is mapped to the low MTI byte in a
-standard format message.</SPAN></P>
-<P STYLE="font-style: normal">Some MTIs have additional status bits
-defined as part of the 2<SUP>nd</SUP> field. For example, there are
-two status bits associated with “Consumer Identified” which must
-be kept in the header since there is no room in the CAN data field.
-To simplify translation between formats, these are the low bits of
-the first byte after the MTI in a standard-form message.</P>
-<P STYLE="margin-bottom: 0cm; font-style: normal">Note that messages
-with Destinations IDs may occur in two forms: with an alias in the
-header and the MTI in the message; and with a full address in the
-data field and the MTI in the header.</P>
<H2 CLASS="western">CAN Controller Filters</H2>
<P STYLE="margin-bottom: 0cm">This coding has been generated such
that simple nodes can use three hardware filters to select only
@@ -620,69 +288,9 @@
used, nodes must be able to handle all combinations of sucessive
frames that the full CAN rate. There is no guarantee that a node will
have time for processing between frames that it must handle.</P>
-<H2 CLASS="western"><BR><BR>
-</H2>
-<H2 CLASS="western"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">From
-Discussion of NodeID Alias Size on CAN Links</H2>
-<P>How big should the NodeID alias field be on CAN links?</P>
-<UL>
- <LI><P>Smaller (fewer bits) allows more payload and/or simpler
- coding of other parts of messages.
- </P>
- <LI><P>Larger allows more unique nodes to be accessed.</P>
-</UL>
-<P>This note describes the issues in more detail, followed by a
-recommendation.</P>
-<H3 CLASS="western">Issues</H3>
-<H4 CLASS="western">Addressing</H4>
-<P>The Node ID size limits the number of unique nodes that can take
-part in communications on the CAN segment. Because Node ID aliases
-are assigned independently on each CAN segment, the only issue is how
-many different nodes are involved, not which ones they are or what
-pattern(s) are available in their address numbers.</P>
-<P>For electrical/timing reasons, a segment itself can only support a
-maximum of about 100 nodes, but communication also involves nodes off
-the segment. For example, chaining N CAN segments via bridges will
-generally make up to 100*N nodes available. We have a use case of
-chaining small numbers of CAN segments together, implying the need to
-address 500 or 1000 nodes.
+<P><I>(but the simple-MTI stuff is at Message level)</I></P>
+<P><BR><BR>
</P>
-<P>As another example, a very large network might connect many CAN
-segments via TCP/IP or other networked connections. Each CAN-attached
-node might need to communicate with a larger number of others spread
-across that network.</P>
-<P>(CAN backbone case)</P>
-<H4 CLASS="western">Collisions during Allocation</H4>
-<P>The allocation process resolves collisions (attempt to use an
-already allocated Node ID alias), but that takes time. Minimizing the
-number of collisions is good. If the address space is just the size
-of the number of things you want to address, the collisions get hard
-/slow to resolve across multiple nodes. This points to having a
-factor of 2, at least, between the number of nodes to be addressed
-and the size of the address space.</P>
-<P>(Mostly talking about separate nodes here, not just one big
-interface node: Points to CAN backbone case)</P>
-<H4 CLASS="western">Size</H4>
-<P>Reducing size most important (so far) in the stream protocol.</P>
-<P>Events and Datagrams can be transmitted with a 16-bit alias size.</P>
-<P>To get the full payload (8 bytes) for streaming requires getting
-the rest of the protocol control, including two aliases for source
-and destination, in the 29 bit header. Allowing 2 bits for
-priority/extension, 2 for protocol control, 2 for MTI and 3 for
-stream ID (all very bare minima) leads to a 10-bit node ID alias
-length.
-</P>
-<P>Using 1 of 8 payload bytes allows up to 14 bit node ID alias
-lengths, or 12 bit node ID alias lengths with some room for expansion
-and simpler MTI coding.</P>
-<H4 CLASS="western">Simplicity</H4>
-<P>Byte vs nibble vs bit boundaries in code, when debugging the
-protocol, etc.</P>
-<P>Having extra bits available in the header allows much simpler MTI
-coding, reserving specific bits for expansion instead of codes, etc.</P>
-<H4 CLASS="western">Filtering</H4>
-<P>Having the destination short enough to be in the header allows
-automated filtering of traffic.</P>
<H2 CLASS="western" STYLE="page-break-before: always">From <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">Node
ID Alias Allocation Algorithm doc</H2>
<P>OpenLCB nodes on CAN segments do CAN arbitration by using their
@@ -700,13 +308,16 @@
</P>
<P>If a node sends out an check message containing just the alias,
then it could expect that another node to complain if it has the same
-alias. This would work, except in the (very unlikely) case where both
-nodes send out the identical check message simultaneously. Neither
-would recognize a conflict and both would consider that they own the
-same alias. Therefore, a method needs to be found that guarantees
-that the check message(s) are unique, even if they are send
-simultaneously.
+alias. This would work, except in the (admittedly unlikely) case
+where both nodes send out the identical check message simultaneously.
+Neither would recognize a conflict and both would consider that they
+own the same alias. Therefore, a method needs to be found that
+guarantees that the check message(s) are unique, even if they are
+sent simultaneously.
</P>
+<P><I>(timing of serialization of low-priority CAN nodes at network
+startup)</I></P>
+<P><I>(can store starting point, not just alias, for later use)</I></P>
<P>Unfortunately, limitations of CAN will not allow the full 48-bit
NodeID to be included in the check message. Doing so would violate
CAN rules as it could not be wholly contained in the header, and
@@ -812,7 +423,9 @@
<P>x<SUB>i+1</SUB> = (2<SUP>9</SUP>+1) x<SUB>i</SUB> + c</P>
<P>where c = 29,741,096,258,473 or 0x1B0CA37A4BA9.The paper actually
describes a PRNG that uses signed arithmetic, but for our purposes
-the 48<SUP>th</SUP> “sign” bit isn't important.</P>
+the 48<SUP>th</SUP> “sign” bit isn't important. <I>(verify that
+about sign) (This is a byte+bit shift and add, so it's quick to
+calculate)</I></P>
<P>Note that, unlike some other PNRGs, this one can generate a zero
result, and can accept a zero seed.</P>
<H3 CLASS="western">Discussion</H3>
@@ -824,7 +437,8 @@
initialization packets only at different times. In addition, CAN will
eventually signal an error if two packets with the same header and
different data payloads collide, but not all CAN interface hardware
-provides reliable indications about why that error occurred.</P>
+provides reliable indications about why that error occurred. <I>(lock
+step issue at startup)</I></P>
<P>At the highest level, this algorithm is broadcasting the complete
Node ID and tentative alias to see if any other node is checking the
same tentative alias. If two nodes have taken the same tentative
@@ -853,15 +467,16 @@
with it needs to have response times of a couple hundred milliseconds
or better to be reliable. The algorithm provides a wait of a few
times that to enable those programs to take part.</P>
-<H2 CLASS="western">From Background doc</H2>
<P><BR><BR>
</P>
+<P><BR><BR>
+</P>
+<H3 CLASS="western">Rate, bandwidth and throttling</H3>
<P>29-bit extended header and 8-byte payload results in a total
transmission taking about 135 bit times.</P>
<P>125Kbps with max-length extended header frames is about 900
frames/second. CAN is very good at running at 100% utilization, so
long as nodes can keep up and a proper set of priorities is in place.</P>
-<H3 CLASS="western">Rate, bandwidth and throttling</H3>
<P>CAN is designed to run at 100% usage without problem, and it's
routine for CAN segments in other contexts to run at 100% for
extended times. Therefore, the CAN network does not require any
@@ -887,14 +502,13 @@
<P>Although it might be a useful debugging tool, putting the full NID
in the data portion of the frames can cause errors. Therefore, we
decided not to do that.</P>
-<H3 CLASS="western">CAN Bibliography</H3>
+<H3 CLASS="western">Additional References</H3>
<P>B. Gaujal and N. Navet, “Fault confinement mechanisms on CAN:
analysis and improvements”, IEEE Transactions on Vehicular
Technology, pp.1103-1113, 54(3), May 2005 (An interesting analysis of
how CAN nodes react to error rates on the CAN bus by e.g. taking
themselves offline, etc)</P>
-<P><BR><BR>
-</P>
+<P><I>(Take some from physical layer doc)</I></P>
<HR>
<P>Site hosted by <FONT COLOR="#000080">
<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
Modified: trunk/specs/drafts/CanFrameTransferSpec.html
===================================================================
--- trunk/specs/drafts/CanFrameTransferSpec.html 2010-09-23 08:47:54 UTC (rev 954)
+++ trunk/specs/drafts/CanFrameTransferSpec.html 2010-09-23 08:48:29 UTC (rev 955)
@@ -6,14 +6,18 @@
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;13111500">
+ <META NAME="CHANGED" CONTENT="20100922;22344200">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<STYLE TYPE="text/css">
<!--
H2.ctl { font-family: "Lucida Sans" }
+ H3.ctl { font-family: "Lucida Sans" }
-->
</STYLE>
</HEAD>
@@ -44,29 +48,429 @@
</P>
<P>OpenLCB-CAN nodes shall operate properly when the CAN segment
carries proper standard-format (11-bit header) frames.</P>
-<P>OpenLCB-CAN nodes shall not transmit extended-format RTR frames.
-Nodes shall operate properly when the CAN segment carries proper
-extended-format RTR frames.</P>
+<P>OpenLCB-CAN nodes shall not transmit extended-format remote frames
+(frames with RTR set). Nodes shall operate properly when the CAN
+segment carries proper extended-format remote frames.</P>
+<P>OpenLCB-CAN nodes shall not transmit eoverload frames. Nodes shall
+operate properly when the CAN segment carries proper overload frames.</P>
+<P><BR><BR>
+</P>
<P STYLE="margin-bottom: 0cm">The first (most-significant) bit is
reserved for future use. It must be transmitted as a 1 bit, and
ignored upon receipt.</P>
<P STYLE="margin-bottom: 0cm"><BR>
</P>
+<P>Header content and sizes (Nominal decisions shown, 29 bit header):
+</P>
+<UL>
+ <LI><P STYLE="margin-bottom: 0cm">Priority bit (Always sent as 1
+ now; at front to ensure it acts like a true priority; 0 for high
+ priority, 1 for low; not checked by receivers)
+ </P>
+ <LI><P STYLE="margin-bottom: 0cm">Frame Type (1 bit) OpenLCB message
+ or CAN control message
+ </P>
+ <LI><P STYLE="margin-bottom: 0cm">Variable Field (15 bits)
+ </P>
+ <LI><P>Source NID alias (12 bits)
+ </P>
+</UL>
+<P>The order of these fields is chosen to get proper priority and
+access disambiguation via CAN's standard mechanisms.</P>
+<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
+ <COL WIDTH=64*>
+ <COL WIDTH=64*>
+ <COL WIDTH=64*>
+ <COL WIDTH=64*>
+ <TR VALIGN=TOP>
+ <TH WIDTH=25%>
+ <P>Bit 0</P>
+ </TH>
+ <TH WIDTH=25%>
+ <P>Bits 1</P>
+ </TH>
+ <TH WIDTH=25%>
+ <P>Bits 2-16</P>
+ </TH>
+ <TH WIDTH=25%>
+ <P>Bits 17-28</P>
+ </TH>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Priority: 0 high, 1 low</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Frame Type</P>
+ <P ALIGN=CENTER>1: OpenLCB Message</P>
+ <P ALIGN=CENTER>0: CAN Control Message</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Variable Field</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Source NID Alias</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>0x1000,0000</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>0x0800,0000</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>0x07FF,F000</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>0x0000,0FFF</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Solo top bit</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Top bit of 6<SUP>th</SUP> nibble from right</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>3 bits lower bits, then three nibbles</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Right-most three nibbles</P>
+ </TD>
+ </TR>
+</TABLE>
+<P STYLE="margin-bottom: 0cm">The "Variable field" has
+different meanings depending on the "Frame Type" field. CAN
+control messages are identified with a Frame Type bit of 0, to ensure
+high priority.</P>
<P STYLE="margin-bottom: 0cm"><BR>
</P>
-<H2 CLASS="western">Link State (Normative)</H2>
-<P><BR><BR>
+<H2 CLASS="western">CAN-specific Control Messages and Interactions</H2>
+<P>These are identified by the Frame Type bit being 0. They are
+formatted as shown in the following table:</P>
+<P STYLE="margin-bottom: 0cm"><BR>
</P>
-<P STYLE="margin-bottom: 0cm">(needs a diagram)</P>
-<P><BR><BR>
+<TABLE WIDTH=762 BORDER=1 CELLPADDING=2 CELLSPACING=4>
+ <COL WIDTH=317>
+ <COL WIDTH=423>
+ <TR>
+ <TH WIDTH=317>
+ <P>Name</P>
+ </TH>
+ <TH WIDTH=423>
+ <P>Variable Field</P>
+ </TH>
+ </TR>
+ <TR>
+ <TD WIDTH=317>
+ <P>Check ID (CIM) message</P>
+ </TD>
+ <TD WIDTH=423>
+ <P>MMM,NNNN,NNNN,NNNN
+ </P>
+ <P>where MMM is the message sequence number, 0x7 to 0x4 (to give
+ priority to messages later in the process)</P>
+ <P>and NNNN,NNNN,NNNN is the 12-bit Node ID section being checked</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH=317>
+ <P>Reserved ID (RIM) Message</P>
+ </TD>
+ <TD WIDTH=423>
+ <P>0x0700</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH=317>
+ <P>Mapping Reset (MR) Message</P>
+ </TD>
+ <TD WIDTH=423>
+ <P>0x0701</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH=317>
+ <P>Reserved</P>
+ </TD>
+ <TD WIDTH=423>
+ <P>All others</P>
+ </TD>
+ </TR>
+</TABLE>
+<H3 CLASS="western">CANid assignment</H3>
+<P>The common message format uses full 48-bit node ID numbers to
+identify originating nodes and in some case destination nodes. CAN
+frames use 12-bit local "NID alias" for these to save space
+in the limited-size CAN payload.
</P>
-<HR>
-<P><BR><BR>
+<P>The standard Verify Node ID Number interaction can be used to get
+the full 48-bit NID from a node for translation. At power up each
+node must obtain a alias that is locally unique. Gateways will also
+have to obtain unique aliases for remote nodes they are proxying on
+to the segment.
</P>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
+<P>Proposed algorithm, in rough form:
+</P>
+<UL>
+ <LI><P STYLE="margin-bottom: 0cm">Compute a CANid from the NID using
+ a standard algorithm.
+ </P>
+ <LI><P STYLE="margin-bottom: 0cm">Send CAN frames claiming that
+ CANid and carrying sequential parts of NID in the Variable Field
+ section of the header.
+ </P>
+ <LI><P STYLE="margin-bottom: 0cm">If error, step the algorithm in a
+ standard way and repeat until success.
+ </P>
+ <LI><P>Send a CAN frame announcing that the node has claimed an ID
+ value.
+ </P>
+</UL>
+<P>Note that there is no requirement that this alias be consistent
+from one run to the next. More detail is on a <A HREF="../documents/can/CanIDAllocation.html">separate
+page</A>.
+</P>
+<H3 CLASS="western">CAN-specific messages</H3>
+<P>Most CAN frames are one-to-one or many-to-one equivalents of
+common OpenLCB messages.
+</P>
+<P>A few additional messages are used for CAN-specific purposes.
+</P>
+<DL>
+ <DT>CIM</DT><DD>
+ Check ID Message - used as part of the <A HREF="../documents/can/CanIDAllocation.html">ID
+ allocation</A>.
+ </DD><DT>
+ RIM</DT><DD>
+ Reserved ID Message - used as part of the <A HREF="../documents/can/CanIDAllocation.html">ID
+ allocation</A>.
+ </DD><DT>
+ MR</DT><DD STYLE="margin-bottom: 0.5cm">
+ Mapping Reset - indicates that the local alias in the source address
+ field may no longer be associated with the same NID, and mapping
+ tables should be reset.
+ </DD></DL>
+<H2 CLASS="western">
+Translation</H2>
+<P>A node must be able to convert traffic on the local CAN segment
+into the common message format using only locally available
+information. This may be needed e.g. by a gateway or monitoring
+program attached to the CAN segment.
+</P>
+<P>All traffic on a CAN segment uses aliases for both Source ID
+(always) and Destination ID (when the full NID isn't known).
+</P>
+<P>If/when a full NID is needed, it can be obtained by sending a
+"Verify Node ID Number (Addressed)" message with an
+appropriate Destination Node ID in local alias form. The reply will
+eventually come back with the Source ID in local alias form and
+carrying the full NID in the message content.
+</P>
+<P>Aliases for nodes on the local segment are only valid until an
+"Initialization Complete" is seen from that alias.
+Initialization Complete indicates that a node has restarted, and may
+have another local alias. <I>(Can't use Initialization Complete, it's
+the wrong layer, need something at the CAN level. Need something like
+RIM/CIM)</I></P>
+<P>Gateways maintain the mapping between remote node's NID and local
+alias. If they need to break that mapping, e.g. because they need to
+reuse the local alias due to resource limitations in the mapping
+tables, they must send a "Mapping Reset" message to force
+nodes to drop their alias information. <I>"Mapping Reset"
+is a CAN-specific message limited to the segment, but all gateways on
+the segment must act on it.</I>
+</P>
+<P>Gateways may not be able ensure permanent validity for alias to
+remote NIDs. For example, if they have a limited routing table, they
+may need to reuse local alias. Before reusing them, they have to send
+a "Mapping Reset" frame to drop references to the old NID,
+followed by a "Initialization Complete" when the alias is
+allocated to a new NID.
+</P>
+<H3 CLASS="western">Map Acquisition</H3>
+<P STYLE="margin-bottom: 0cm">In order to acquire the map between
+CANids and NIDs, a gateway needs to be able to send a CAN frame
+requiring "everybody reply with your NID". Much like
+Ethernet gateway mapping, this needs to return the NID of just the
+specific CAN-attached hardware, not all the NIDs that can be e.g.
+reached through a gateway, so it needs to be a segment-specific
+message defined only at the CAN level. It must not be a OpenLCB
+common message.
+</P>
+<P STYLE="margin-bottom: 0cm"><I>(Need to add the actual message
+definition)</I></P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<H2 CLASS="western">OpenLCB messages in Frames</H2>
+<P><I>(provides addressed and global, even though a CAN segment is
+intrinsically global; should explain above that OpenLCB is based on
+full-global access)</I></P>
+<H2 CLASS="western">OpenLCB message format</H2>
+<P>OpenLCB common messages are carried in frames with a 1 in the
+Frame Type field. They contain message type information and/or
+address information in the 15-bit variable field, and zero to eight
+CAN data bytes.</P>
+<P STYLE="font-style: normal">For OpenLCB messages, the variable
+field is used in three forms:</P>
+<UL>
+ <LI><P STYLE="font-style: normal">Unaddressed messages – messages
+ that don't have a destination address put the low 12 bits of the MTI
+ in the variable field</P>
+ <LI><P STYLE="font-style: normal">Addressed messages – messages
+ that have a specific destination address put it in the variable
+ field, and carry the MTI in the payload. This allows filtering.</P>
+ <LI><P STYLE="font-style: normal">Stream addressed messages – as a
+ special case to improve efficiency of transfer, the streaming
+ protocol uses 12 bits of the variable field to identify a particular
+ stream transfer. This is not the same as a destination NodeID alias,
+ but performs a similar function to allow filtering while also
+ allowing multiple streams from a source.</P>
+</UL>
+<P STYLE="margin-bottom: 0cm"><I>(Global vs addressed bit – really
+only two formats here)</I></P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<P STYLE="margin-bottom: 0cm">The variable field is allocated:</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
+ <COL WIDTH=96*>
+ <COL WIDTH=160*>
+ <TR VALIGN=TOP>
+ <TH WIDTH=37%>
+ <P>Variable Field Bits 0-2</P>
+ <P>Header Bits 2-4</P>
+ <P>OpenLCB Format</P>
+ <P>0x0700,0000</P>
+ </TH>
+ <TH WIDTH=63%>
+ <P>Variable Field Bits 3-14</P>
+ <P>Header Bits 5-16</P>
+ <P>OpenLCB Variable Header Content</P>
+ <P>0x00FF,F000</P>
+ </TH>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>0 0 0</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>MTI & additional information for “simple
+ node” unaddressed messages</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>0 0 1</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>MTI & additional information for unaddressed
+ messages other than “simple node” forms</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>0 1 0</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>(Reserved, must not be sent or accepted)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>0 1 1</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>(Reserved for long-form MTIs in data area, <BR>must
+ not be sent or accepted)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>1 0 0</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>Destination Alias for datagram message non-last
+ fragment</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>1 0 1</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>Destination Alias for datagram message last
+ fragment</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>1 1 0</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>Destination Alias for non-datagram addressed
+ messages</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>1 1 1</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>Destination Alias for Stream Data Send messages</P>
+ </TD>
+ </TR>
+</TABLE>
+<P>Putting the destination alias in the header allows filtering on it
+with common CAN hardware. Putting the Stream ID in the header also
+allows filtering, and preserves the full 8-byte CAN payload for
+stream data.</P>
+<P><SPAN STYLE="font-style: normal">The specific MTI values are being
+allocated in a <A HREF="../documents/MtiAllocations.ods">separate
+worksheet</A> (<A HREF="../documents/MtiAllocations.pdf">PDF
+version</A>). In general, the MTI selection is done on the top 8 bits
+of the variable field. This is mapped to the low MTI byte in a
+standard format message.</SPAN></P>
+<H2 CLASS="western">Frame Communications Process</H2>
+<UL>
+ <LI><P STYLE="margin-bottom: 0cm">Nodes must handle full rate
+ messages, specifically including messages not addressed to them.
+ (The datagram and stream protocols provide ways for nodes to
+ indicate whether or not they have sufficient buffering for the next
+ transmission, triggering retries as needed) For long term
+ reliability, a node <U>must</U> be able to completely process an
+ entire CAN frame in the time it takes to receive the next one, which
+ may be as little as 64 bit times, or about 500 microseconds.</P>
+ <LI><P></P>
+</UL>
+<P STYLE="margin-bottom: 0cm">Discuss the use of repeaters, bridges
+and gateways w.r.t. Timing; ref physical layer. Possibility of
+reordering.</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<P STYLE="margin-bottom: 0cm">Over<FONT FACE="Times New Roman, serif"><FONT SIZE=3>load
+frame: “</FONT></FONT><FONT COLOR="#000000"><FONT FACE="Times New Roman, serif"><FONT SIZE=3>Due
+to internal conditions, the node is not yet able to begin reception
+of the next message. A node may generate a maximum of two sequential
+overload frames to delay the start of the next message.” (That's 17
+to 23 extra bit times each) (from
+<A HREF="http://rs232-rs485.blogspot.com/2009/11/can-bus-message-frames-overload.html">http://rs232-rs485.blogspot.com/2009/11/can-bus-message-frames-overload.html</A>)
+Image:
+<A HREF="http://3.bp.blogspot.com/_ycHwJEosotY/SvoMDJMGF7I/AAAAAAAAA64/3Ql4_UQnoBg/s1600/Overload%2BFrame.JPG">http://3.bp.blogspot.com/_ycHwJEosotY/SvoMDJMGF7I/AAAAAAAAA64/3Ql4_UQnoBg/s1600/Overload%2BFrame.JPG</A></FONT></FONT></FONT></P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<H2 CLASS="western">Link State (Normative)</H2>
<P><BR><BR>
</P>
+<P STYLE="margin-bottom: 0cm">(needs a diagram in the explanation
+doc)</P>
+<H2 CLASS="western"><BR><BR>
+</H2>
<H2 CLASS="western">Node ID Alias Generation</H2>
<P><BR><BR>
</P>
Modified: trunk/specs/drafts/CanMessageNetworkExpl.html
===================================================================
--- trunk/specs/drafts/CanMessageNetworkExpl.html 2010-09-23 08:47:54 UTC (rev 954)
+++ trunk/specs/drafts/CanMessageNetworkExpl.html 2010-09-23 08:48:29 UTC (rev 955)
@@ -6,9 +6,12 @@
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;11050100">
+ <META NAME="CHANGED" CONTENT="20100922;22351500">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<STYLE TYPE="text/css">
<!--
H2.ctl { font-family: "Lucida Sans" }
@@ -33,6 +36,43 @@
<HR>
<P>Below this is just a collection of pieces from other docs right
now.</P>
+<P><BR><BR>
+</P>
+<P><SPAN STYLE="font-style: normal">Some MTIs have additional status
+bits defined as part of the 2</SPAN><SUP><SPAN STYLE="font-style: normal">nd</SPAN></SUP><SPAN STYLE="font-style: normal">
+field. For example, there are two status bits associated with
+“Consumer Identified” which must be kept in the header since
+there is no room in the CAN data field. To simplify translation
+between formats, these are the low bits of the first byte after the
+MTI in a standard-form message.</SPAN></P>
+<P><BR><BR>
+</P>
+<H3 CLASS="western">Left over from Frame doc</H3>
+<P>OpenLCB common messages are converted, to the extent possible, to
+single CAN frames via a one-to-one mapping.
+</P>
+<P>The translations include:
+</P>
+<UL>
+ <LI><P STYLE="margin-bottom: 0cm">MTIs may have to be shortened,
+ depending on bit allocations.
+ </P>
+</UL>
+<P>Design decisions:</P>
+<UL>
+ <LI><P STYLE="margin-bottom: 0cm">A specific mapping from the common
+ 16-bit MTI format to a shorter CAN format is documented in a
+ <A HREF="../documents/MtiAllocations.ods">separate worksheet</A>
+ (<A HREF="../documents/MtiAllocations.pdf">PDF version</A>). The
+ common form is 16 bits to have lots of space to grow at the high
+ end, but it can be mapped into a 8 bit field for efficient CAN
+ transfer.
+ </P>
+</UL>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
<H2 CLASS="western"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="David Harris"><!-- $Id$ -->OpenLCB
Common Message Format</H2>
<P>A common message consists of several parts:
@@ -300,6 +340,14 @@
originating and/or destination NID, this can be used to obtain the
full NID.
</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<P STYLE="margin-bottom: 0cm"><I>The standard Verify Node ID Number
+interaction can be used to get the full 48-bit NID from a node for
+translation. At power up each node must obtain a alias that is
+locally unique. Gateways will also have to obtain unique aliases for
+remote nodes they are proxying on to the segment. </I>
+</P>
<H2 CLASS="western">D) Protocol Discovery</H2>
<P>OpenLCB defines a number of specific protocols for interacting
with nodes, including event exchange, datagrams, streams,
Modified: trunk/specs/drafts/CanMessageNetworkSpec.html
===================================================================
--- trunk/specs/drafts/CanMessageNetworkSpec.html 2010-09-23 08:47:54 UTC (rev 954)
+++ trunk/specs/drafts/CanMessageNetworkSpec.html 2010-09-23 08:48:29 UTC (rev 955)
@@ -6,10 +6,11 @@
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;13100400">
+ <META NAME="CHANGED" CONTENT="20100922;21343400">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<STYLE TYPE="text/css">
<!--
H2.ctl { font-family: "Lucida Sans" }
@@ -46,8 +47,145 @@
</P>
<P><BR><BR>
</P>
+<H2 CLASS="western">OpenLCB message format</H2>
+<P>(rationalize with the frame doc, that describes the 1<SUP>st</SUP>
+bit)</P>
+<P>OpenLCB common messages are carried in frames with a 1 in the
+Frame Type field. They contain message type information and/or
+address information in the 15-bit variable field, and zero to eight
+CAN data bytes.</P>
+<P STYLE="font-style: normal">For OpenLCB messages, the variable
+field is used in three forms:</P>
+<UL>
+ <LI><P STYLE="font-style: normal">Unaddressed messages – messages
+ that don't have a destination address put the low 12 bits of the MTI
+ in the variable field</P>
+ <LI><P STYLE="font-style: normal">Addressed messages – messages
+ that have a specific destination address put it in the variable
+ field, and carry the MTI in the payload. This allows filtering.</P>
+ <LI><P STYLE="font-style: normal">Stream addressed messages – as a
+ special case to improve efficiency of transfer, the streaming
+ protocol uses 12 bits of the variable field to identify a particular
+ stream transfer. This is not the same as a destination NodeID alias,
+ but performs a similar function to allow filtering while also
+ allowing multiple streams from a source.</P>
+</UL>
+<P STYLE="margin-bottom: 0cm">The variable field is allocated:</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
+ <COL WIDTH=96*>
+ <COL WIDTH=160*>
+ <TR VALIGN=TOP>
+ <TH WIDTH=37%>
+ <P>Variable Field Bits 0-2</P>
+ <P>Header Bits 2-4</P>
+ <P>OpenLCB Format</P>
+ <P>0x0700,0000</P>
+ </TH>
+ <TH WIDTH=63%>
+ <P>Variable Field Bits 3-14</P>
+ <P>Header Bits 5-16</P>
+ <P>OpenLCB Variable Header Content</P>
+ <P>0x00FF,F000</P>
+ </TH>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>0 0 0</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>MTI & additional information for “simple
+ node” unaddressed messages</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>0 0 1</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>MTI & additional information for unaddressed
+ messages other than “simple node” forms</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>0 0 0</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>(Reserved, must not be sent or accepted)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>0 1 1</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>(Reserved for long-form MTIs in data area, <BR>must
+ not be sent or accepted)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>1 0 0</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>Destination Alias for datagram message non-last
+ fragment</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>1 0 1</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>Destination Alias for datagram message last
+ fragment</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>1 1 0</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>Destination Alias for non-datagram addressed
+ messages</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=37%>
+ <P ALIGN=CENTER>1 1 1</P>
+ </TD>
+ <TD WIDTH=63%>
+ <P ALIGN=CENTER>Destination Alias for Stream Data Send messages</P>
+ </TD>
+ </TR>
+</TABLE>
+<P>Putting the destination alias in the header allows filtering on it
+with common CAN hardware. Putting the Stream ID in the header also
+allows filtering, and preserves the full 8-byte CAN payload for
+stream data.</P>
+<P><SPAN STYLE="font-style: normal">The specific MTI values are being
+allocated in a <A HREF="../documents/MtiAllocations.ods">separate
+worksheet</A> (<A HREF="../documents/MtiAllocations.pdf">PDF
+version</A>). In general, the MTI selection is done on the top 8 bits
+of the variable field. This is mapped to the low MTI byte in a
+standard format message.</SPAN></P>
+<P STYLE="font-style: normal">Some MTIs have additional status bits
+defined as part of the 2<SUP>nd</SUP> field. For example, there are
+two status bits associated with “Consumer Identified” which must
+be kept in the header since there is no room in the CAN data field.
+To simplify translation between formats, these are the low bits of
+the first byte after the MTI in a standard-form message.</P>
+<P STYLE="margin-bottom: 0cm; font-style: normal">Note that messages
+with Destinations IDs may occur in two forms: with an alias in the
+header and the MTI in the message; and with a full address in the
+data field and the MTI in the header.</P>
+<P STYLE="margin-bottom: 0cm; font-style: normal"><BR>
+</P>
+<P STYLE="margin-bottom: 0cm; font-style: normal"><BR>
+</P>
<HR>
-<HR>
<P>Below this is just a collection of pieces from other docs right
now.</P>
<HR>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
![http://3.bp.blogspot.com/_ycHwJEosotY/SvoMDJMGF7I/AAAAAAAAA64/3Ql4_UQnoBg/s1600/Overload%2BFrame.JPG">http://3.bp.blogspot.com/_ycHwJEosotY/SvoMDJMGF7I/AAAAAAAAA64/3Ql4_UQnoBg/s1600/Overload%2BFrame.JPG</A></FONT></FONT></FONT></P>](http://3.bp.blogspot.com/_ycHwJEosotY/SvoMDJMGF7I/AAAAAAAAA64/3Ql4_UQnoBg/s1600/Overload%2BFrame.JPG">http://3.bp.blogspot.com/_ycHwJEosotY/SvoMDJMGF7I/AAAAAAAAA64/3Ql4_UQnoBg/s1600/Overload%2BFrame.JPG</A></FONT></FONT></FONT></P>){kind=link}
|
From: <jac...@us...> - 2010-10-05 04:35:31
|
Revision: 973
http://openlcb.svn.sourceforge.net/openlcb/?rev=973&view=rev
Author: jacobsen
Date: 2010-10-05 04:35:24 +0000 (Tue, 05 Oct 2010)
Log Message:
-----------
very much a work in progress
Modified Paths:
--------------
trunk/specs/drafts/CanFrameTransferExpl.html
trunk/specs/drafts/CanFrameTransferSpec.html
trunk/specs/drafts/CanMessageNetworkExpl.html
trunk/specs/drafts/CanMessageNetworkSpec.html
Modified: trunk/specs/drafts/CanFrameTransferExpl.html
===================================================================
--- trunk/specs/drafts/CanFrameTransferExpl.html 2010-10-03 01:25:26 UTC (rev 972)
+++ trunk/specs/drafts/CanFrameTransferExpl.html 2010-10-05 04:35:24 UTC (rev 973)
@@ -6,16 +6,10 @@
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;23132300">
+ <META NAME="CHANGED" CONTENT="20101004;9400500">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<STYLE TYPE="text/css">
<!--
H2.ctl { font-family: "Lucida Sans" }
@@ -31,107 +25,126 @@
<P>This explanatory note contains informative discussion and
background for the corresponding “OpenLCB CAN Frame Transfer
Specification”. This explanation is not normative in any way.</P>
-<P>Have to avoid collisions by design, not by luck.</P>
-<P>OpenLCB assumes(?) a global communications fabric: any node can
-send a message to any node, and any node can send a message to all
-nodes. This document describes how CAN is used to do that.</P>
-<P>Cannot (do not assume) one of anything, including node managers,
-etc. If you allow for more than zero, it has to be any number.</P>
-<P>Fully traceability also assures no collisions.</P>
-<P>The adaptations include
+<P>The Frame Transfer layer of the OpenLCB-CAN stack likes above the
+CAN Physical Layer, and below the Message Network layer. It is
+responsible for ensuring the reliable transport of the CAN frames
+that make up OpenLCB-CAN messages. CAN provides reliable transport
+between any two nodes on a CAN segment within limitations:</P>
+<OL>
+ <LI><P>Every CAN header must be unique by construction. Collisions
+ between frames with identical headers do not result in well-defined
+ behavior, and must be avoided by design to avoid intermittent
+ problems.</P>
+ <LI><P>CAN does not provide a “link up” or “link down”
+ notification. Nodes may come and go from a CAN segment at any time,
+ and on an individual basis. In general, one can't assert that a
+ particular node is always present, always comes up first, or never
+ comes up first.</P>
+ <LI><P>CAN does not provide any indicator of which node sent a
+ particular frame. Any node can send any frame, and the receiving
+ nodes have no CAN-provided mechanism for identifying the source.</P>
+ <LI><P>On a busy segment, CAN frames are sent in a strict priority
+ order, with the priority determined by the content of the frame
+ headers. If multiple nodes have frames to send at the same time, the
+ highest priority (lowest numerical value header) frame will be sent
+ first. There is no concept of “reserved bandwidth” except
+ through frame priority, and low-priority frames may require
+ significant time to be sent.</P>
+ <LI><P>Nodes must be able to accept frames at the full CAN rate.
+ Hardware filters must be usable to help with that, but even then
+ nodes may receive adjacent frames addressed to them.</P>
+</OL>
+<P>Putting a unique source ID field in each frame ensures that the
+frames are unique (item 1 above), and provides a frame-level
+indicator of which node sent the frame for the purposes of
+monitoring, debugging, etc (item 3). Using a distributed algorithm to
+determine the value for that ID field prevents needing a single
+“manager” to provide it, thereby handling item 2. The header bit
+fields discussed below are organized to handle items 4 and 5.
</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">A 1-bit priority field has been
- added to provide a coarse high/low message priority
- </P>
- <LI><P STYLE="margin-bottom: 0cm">NID values are translated to 12
- bit forms. Those forms are dynamically allocated so as to remain
- unique.
- </P>
- <LI><P>Remapping of MTI values to make limited filtering possible.
- </P>
-</UL>
-<P>Note that these adaptions must be possible in standard CAN
-components, e.g. bridges and computer adapters must not require
-customization to operate with OpenLCB. This provides a stringent
-requirement on protocol design, in that OpenLCB CAN cannot require
-specific timing, deliberate creation of error cases or specific error
-handling.
+<P>OpenLCB-CAN is required to work with standard CAN components, e.g.
+bridges and computer adapters must not require customization to
+operate with OpenLCB. This provides a stringent requirement on
+protocol design, in that OpenLCB-CAN cannot require specific timing,
+deliberate creation of error cases or specific error handling.
</P>
-<P>The translations include:
-</P>
-<UL>
- <LI><P>The NID Source ID (SID) is mapped to a shorter form, called a
- "NID Alias" (NIDa). The method for this mapping is defined
- such that devices on the CAN segment (e.g. gateways to other parts
- of the larger OpenLCB installation) can determine the full NID that
- corresponds to a particular alias.
- </P>
- <P STYLE="margin-bottom: 0cm">Because this alias is still unique on
- the specific CAN segment, it is used in the CAN header for
- arbitration.
- </P>
- <LI><P>When possible, Destination NIDs are also mapped to the
- shorter form. In some OpenLCB messages, this is not possible, in
- which case the full NID form is sent; a bit is provided to indicate
- which format is carried.
- </P>
-</UL>
-<P STYLE="margin-bottom: 0cm">The CAN format has been allocated on
-nibble boundaries to make it easier to e.g. read dumps of packets.
-The header is considered to be right (LSB) aligned.</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Designers may wish to use CAN
- hardware filtering, but it can't be assumed to be present. We assign
- a single bit to indicate “simple node protocol” messages to make
- simple filtering possible.</P>
-</UL>
+<P>People will occasionally refer to a restriction against having
+seven 1 bits in the top 11 bits of the CAN header. There is no such
+restriction, and the statements are the result of a misunderstanding.
+There is a restriction against having seven consecutive recessive
+bits on the CAN connection, but sending seven consecutive 1 bits will
+not result in this. CAN uses a bit-stuffing technique to prevent that
+by inserting a dominant bit on the line after the fifth consecutive
+recessive bit, and removing it at the receiver.</P>
<H2 CLASS="western">Annotations to the Specification</H2>
<P>This section provides background information on corresponding
sections of the Specification document. It's expected that two
documents will be read together.</P>
<H3 CLASS="western">Introduction</H3>
<H3 CLASS="western">References and Context</H3>
+<P>Note that we reference the Node ID specification, but only to the
+extent that each node is required to have a unique Node ID. The
+Specification would work equally well with a Node ID that was
+allocated via any mechanism, and with any length from 2 to 8 bytes.</P>
<H3 CLASS="western">Frame Format</H3>
<P>OpenLCB uses a very vanilla transfer of frames, no special
features, to reduce complexity and increase robustness.</P>
<P>Standard header frames are also known as CAN 2.0A frames. Extended
header frames are also known as CAN 2.0B frames.</P>
<P>The specification is silent on the uses for standard (11-bit
-header) frames. The proper-operation require is so nodes tolerate
-them in case they're needed for e.g. bootloaders. This could also
-have been phrased as “shall ignore ...”, but the current phrasing
-is thought to be more exact.</P>
+header) frames. The proper-operation requirement is so nodes will
+tolerate them in case they're needed for other purposes. The Atmel
+bootloader () uses standard frames, for example, and the Microchip
+bootloader () can use them.
+</P>
+<P>This could also have been phrased as “shall ignore ...”, but
+the current phrasing is thought to be more exact.</P>
<P>We don't use RTR because CAN semantics require a specific use for
it, which has been built into some silicon implementations. There are
also some arbitration issues, see: CiA Application Note 802 (2005)
and <A HREF="http://www.thecanmancan.com/?tag=rtr">http://www.thecanmancan.com/?tag=rtr</A>
for more information.</P>
-<P>The MSB is likely to be used as a priority-boost bit in the
-future, e.g. so that a gateway can gain priority access to the CAN
-segment for various operations that require synchronization or
-atomicity. CAN encodes “do first” priority as 0 and “do later”
-as 1, so the specification requires that a 1 bit be sent. To preserve
-the utility of this, nodes must not require either a 1 nor 0 on
-receipt.</P>
-<UL>
- <LI><P>A 1-bit field priority field coarsely specifies the priority
- of the message in terms of CAN arbitration to be high (pri=0) or low
- (pri=1). By default, all messages are to be emitted with low
- priority selected. Receiving nodes must not check this bit.</P>
- <P STYLE="margin-bottom: 0cm">This field is intended for network
- infrastructure and server type nodes (Command Stations) that may
- from time to time experience high traffic loads and need the ability
- to pre-empt other nodes to forward messages from a busy segment or
- preempt the sending of responses to nodes over receiving new
- requests to prevent message buffer overflow. This field is separate
- from the static priority field in the MTI format specification.</P>
- <LI><P></P>
-</UL>
-<P STYLE="margin-bottom: 0cm"><I>Document no-seven-1-bits-in-top-11
-limitation to ensure future selections don't violate it.</I></P>
+<P>We don't use overload frames because not all CAN controller
+hardware can deliberately send them. We require that nodes be able to
+handle them because some CAN controller hardware will occasionally
+send them automatically.</P>
+<P>The CAN format has been allocated on nibble boundaries to make it
+easier to e.g. read dumps of packets. The header is considered to be
+right (LSB) aligned.</P>
+<P>The reserved first bit (MSB) is likely to be used as a
+priority-boost bit in the future, e.g. so that a gateway can gain
+priority access to the CAN segment for various operations that
+require synchronization or atomicity. CAN encodes “do first”
+priority as 0 and “do later” as 1, so the specification requires
+that a 1 bit be sent. To preserve the utility of this, nodes must not
+require either a 1 nor 0 on receipt.</P>
+<H2 CLASS="western">CAN-specific Control Messages and Interactions
+(Normative)</H2>
+<H3 CLASS="western">States</H3>
+<H3 CLASS="western">Control Message Format</H3>
+<P><BR><BR>
+</P>
+<H3 CLASS="western">Interactions</H3>
+<P>Communications protocols are about more than messages. The
+protocols must also specify the interactions in which the messages
+are used.</P>
+<H4 CLASS="western">ID Alias assignment</H4>
+<H4 CLASS="western">ID Alias validation</H4>
+<H4 CLASS="western">ID Alias termination</H4>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
+<P>Putting the destination alias in the header allows filtering on it
+with common CAN hardware.</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
<H3 CLASS="western">Link State</H3>
<P><BR><BR>
</P>
@@ -164,6 +177,98 @@
<H3 CLASS="western">State machine</H3>
<P>E.g. Higher level starts link control by providing a valid NID and
telling to to start off.</P>
+<HR>
+<P><BR><BR>
+</P>
+<P>Header content and sizes (Nominal decisions shown, 29 bit header):
+</P>
+<UL>
+ <LI><P STYLE="margin-bottom: 0cm">Priority bit (Always sent as 1
+ now; at front to ensure it acts like a true priority; 0 for high
+ priority, 1 for low; not checked by receivers)
+ </P>
+ <LI><P STYLE="margin-bottom: 0cm">Frame Type (1 bit) OpenLCB message
+ or CAN control message
+ </P>
+ <LI><P STYLE="margin-bottom: 0cm">Variable Field (15 bits)
+ </P>
+ <LI><P>Source NID alias (12 bits)
+ </P>
+</UL>
+<P>The order of these fields is chosen to get proper priority and
+access disambiguation via CAN's standard mechanisms.</P>
+<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
+ <COL WIDTH=64*>
+ <COL WIDTH=64*>
+ <COL WIDTH=64*>
+ <COL WIDTH=64*>
+ <TR VALIGN=TOP>
+ <TH WIDTH=25%>
+ <P>Bit 0</P>
+ </TH>
+ <TH WIDTH=25%>
+ <P>Bits 1</P>
+ </TH>
+ <TH WIDTH=25%>
+ <P>Bits 2-16</P>
+ </TH>
+ <TH WIDTH=25%>
+ <P>Bits 17-28</P>
+ </TH>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Priority: 0 high, 1 low</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Frame Type</P>
+ <P ALIGN=CENTER>1: OpenLCB Message</P>
+ <P ALIGN=CENTER>0: CAN Control Message</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Variable Field</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Source NID Alias</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>0x1000,0000</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>0x0800,0000</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>0x07FF,F000</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>0x0000,0FFF</P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Solo top bit</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Top bit of 6<SUP>th</SUP> nibble from right</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>3 bits lower bits, then three nibbles</P>
+ </TD>
+ <TD WIDTH=25%>
+ <P ALIGN=CENTER>Right-most three nibbles</P>
+ </TD>
+ </TR>
+</TABLE>
+<P STYLE="margin-bottom: 0cm">The "Variable field" has
+different meanings depending on the "Frame Type" field. CAN
+control messages are identified with a Frame Type bit of 0, to ensure
+high priority.</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
<H2 CLASS="western">On the choice of a 12-bit alias length</H2>
<P>How big should the NodeID alias field be on CAN links?</P>
<UL>
Modified: trunk/specs/drafts/CanFrameTransferSpec.html
===================================================================
--- trunk/specs/drafts/CanFrameTransferSpec.html 2010-10-03 01:25:26 UTC (rev 972)
+++ trunk/specs/drafts/CanFrameTransferSpec.html 2010-10-05 04:35:24 UTC (rev 973)
@@ -6,18 +6,18 @@
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;22344200">
+ <META NAME="CHANGED" CONTENT="20101004;9391400">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<STYLE TYPE="text/css">
<!--
H2.ctl { font-family: "Lucida Sans" }
H3.ctl { font-family: "Lucida Sans" }
+ H4.ctl { font-family: "Lucida Sans" }
-->
</STYLE>
</HEAD>
@@ -51,32 +51,28 @@
<P>OpenLCB-CAN nodes shall not transmit extended-format remote frames
(frames with RTR set). Nodes shall operate properly when the CAN
segment carries proper extended-format remote frames.</P>
-<P>OpenLCB-CAN nodes shall not transmit eoverload frames. Nodes shall
+<P>OpenLCB-CAN nodes shall not transmit overload frames. Nodes shall
operate properly when the CAN segment carries proper overload frames.</P>
-<P><BR><BR>
-</P>
<P STYLE="margin-bottom: 0cm">The first (most-significant) bit is
reserved for future use. It must be transmitted as a 1 bit, and
ignored upon receipt.</P>
<P STYLE="margin-bottom: 0cm"><BR>
</P>
-<P>Header content and sizes (Nominal decisions shown, 29 bit header):
+<P STYLE="margin-bottom: 0cm">The second (second-most-significant)
+bit is the Frame Type indicator. A value of 0 indicates a
+CAN-specific Control Message. A value of 1 indicates an OpenLCB
+Message.</P>
+<P STYLE="margin-bottom: 0cm"><BR>
</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Priority bit (Always sent as 1
- now; at front to ensure it acts like a true priority; 0 for high
- priority, 1 for low; not checked by receivers)
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Frame Type (1 bit) OpenLCB message
- or CAN control message
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Variable Field (15 bits)
- </P>
- <LI><P>Source NID alias (12 bits)
- </P>
-</UL>
-<P>The order of these fields is chosen to get proper priority and
-access disambiguation via CAN's standard mechanisms.</P>
+<P STYLE="margin-bottom: 0cm">The next 15 bits are termed the
+Variable Field. The format and contents of the Variable Field depends
+on Frame Type and are defined in later sections.</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<P STYLE="margin-bottom: 0cm">The last twelve bits (least
+significant) are the Source Node ID Alias value.</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
<COL WIDTH=64*>
<COL WIDTH=64*>
@@ -98,10 +94,10 @@
</TR>
<TR VALIGN=TOP>
<TD WIDTH=25%>
- <P ALIGN=CENTER>Priority: 0 high, 1 low</P>
+ <P ALIGN=CENTER>Reserved: Send as 1, <BR>ignore upon receipt</P>
</TD>
<TD WIDTH=25%>
- <P ALIGN=CENTER>Frame Type</P>
+ <P ALIGN=CENTER>Frame Type:</P>
<P ALIGN=CENTER>1: OpenLCB Message</P>
<P ALIGN=CENTER>0: CAN Control Message</P>
</TD>
@@ -134,73 +130,144 @@
<P ALIGN=CENTER>Top bit of 6<SUP>th</SUP> nibble from right</P>
</TD>
<TD WIDTH=25%>
- <P ALIGN=CENTER>3 bits lower bits, then three nibbles</P>
+ <P ALIGN=CENTER>3 bits, then three nibbles</P>
</TD>
<TD WIDTH=25%>
<P ALIGN=CENTER>Right-most three nibbles</P>
</TD>
</TR>
</TABLE>
-<P STYLE="margin-bottom: 0cm">The "Variable field" has
-different meanings depending on the "Frame Type" field. CAN
-control messages are identified with a Frame Type bit of 0, to ensure
-high priority.</P>
<P STYLE="margin-bottom: 0cm"><BR>
</P>
-<H2 CLASS="western">CAN-specific Control Messages and Interactions</H2>
-<P>These are identified by the Frame Type bit being 0. They are
-formatted as shown in the following table:</P>
+<P><BR><BR>
+</P>
<P STYLE="margin-bottom: 0cm"><BR>
</P>
-<TABLE WIDTH=762 BORDER=1 CELLPADDING=2 CELLSPACING=4>
- <COL WIDTH=317>
- <COL WIDTH=423>
+<H2 CLASS="western">CAN-specific Control Messages and Interactions
+(Normative)</H2>
+<H3 CLASS="western">States</H3>
+<P>A node has two states:</P>
+<UL>
+ <LI><P>Inhibited</P>
+ <LI><P>Permitted</P>
+</UL>
+<P>Nodes shall start in the Inhibited state.</P>
+<P>Nodes shall transition to the Permitted state after assignment of
+a valid Node ID alias.</P>
+<P>A node may transmit Check ID Message and Reserved ID Message
+frames while in the Inhibited state. A node shall not transmit any
+other frame while in Inhibited state.</P>
+<H3 CLASS="western">Control Message Format</H3>
+<P>The format and contents of CAN-specific Control Messages are
+defined in the following table:</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<TABLE WIDTH=813 BORDER=1 CELLPADDING=2 CELLSPACING=4>
+ <COL WIDTH=331>
+ <COL WIDTH=332>
+ <COL WIDTH=119>
<TR>
- <TH WIDTH=317>
+ <TH WIDTH=331>
<P>Name</P>
</TH>
- <TH WIDTH=423>
+ <TH WIDTH=332>
<P>Variable Field</P>
</TH>
+ <TH WIDTH=119>
+ <P>Data Bytes</P>
+ </TH>
</TR>
<TR>
- <TD WIDTH=317>
- <P>Check ID (CIM) message</P>
+ <TD WIDTH=331>
+ <P>Check ID (CIM) Message</P>
</TD>
- <TD WIDTH=423>
+ <TD WIDTH=332>
<P>MMM,NNNN,NNNN,NNNN
</P>
- <P>where MMM is the message sequence number, 0x7 to 0x4 (to give
- priority to messages later in the process)</P>
+ <P>where MMM is the message sequence number, with valid values
+ from 0x4 through 0x7</P>
<P>and NNNN,NNNN,NNNN is the 12-bit Node ID section being checked</P>
</TD>
+ <TD WIDTH=119>
+ <P>None</P>
+ </TD>
</TR>
<TR>
- <TD WIDTH=317>
+ <TD WIDTH=331>
<P>Reserved ID (RIM) Message</P>
</TD>
- <TD WIDTH=423>
+ <TD WIDTH=332>
<P>0x0700</P>
</TD>
+ <TD WIDTH=119>
+ <P>None</P>
+ </TD>
</TR>
<TR>
- <TD WIDTH=317>
+ <TD WIDTH=331>
<P>Mapping Reset (MR) Message</P>
</TD>
- <TD WIDTH=423>
+ <TD WIDTH=332>
<P>0x0701</P>
</TD>
+ <TD WIDTH=119>
+ <P>None</P>
+ </TD>
</TR>
<TR>
- <TD WIDTH=317>
- <P>Reserved</P>
+ <TD WIDTH=331>
+ <P>Mapping Enquiry Request (MRQ) Message</P>
</TD>
- <TD WIDTH=423>
+ <TD WIDTH=332>
+ <P>0x0702</P>
+ </TD>
+ <TD WIDTH=119>
+ <P>Full Node ID</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH=331>
+ <P>Mapping Enquiry Reply (MRR) Message</P>
+ </TD>
+ <TD WIDTH=332>
+ <P>0x0703</P>
+ </TD>
+ <TD WIDTH=119>
+ <P>Full Node ID</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH=331>
+ <P>Reserved; may not be sent, and must be ignored upon receipt</P>
+ </TD>
+ <TD WIDTH=332>
<P>All others</P>
</TD>
+ <TD WIDTH=119>
+ <P>To be defined</P>
+ </TD>
</TR>
</TABLE>
-<H3 CLASS="western">CANid assignment</H3>
+<H3 CLASS="western">Interactions</H3>
+<H4 CLASS="western">ID Alias assignment</H4>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
+<P STYLE="margin-bottom: 0cm">… MMM is the message sequence number,
+0x7 to 0x4 (to give priority to messages later in the process)
+</P>
+<H4 CLASS="western">ID Alias validation</H4>
+<P>A node receiving a Mapping Enquiry Request Message shall compare
+the Full Node ID in the CAN data segment to the node's own Node ID.
+If and only if they match in length and content and the receiving
+node is in Permitted state, the node shall reply with a Mapping
+Enquiry Reply Message.</P>
+<H4 CLASS="western">ID Alias termination</H4>
+<P>A node receiving a Mapping Reset Message must drop the
+</P>
+<P><BR><BR>
+</P>
+<P><BR><BR>
+</P>
<P>The common message format uses full 48-bit node ID numbers to
identify originating nodes and in some case destination nodes. CAN
frames use 12-bit local "NID alias" for these to save space
@@ -233,6 +300,8 @@
from one run to the next. More detail is on a <A HREF="../documents/can/CanIDAllocation.html">separate
page</A>.
</P>
+<P><BR><BR>
+</P>
<H3 CLASS="western">CAN-specific messages</H3>
<P>Most CAN frames are one-to-one or many-to-one equivalents of
common OpenLCB messages.
@@ -314,126 +383,89 @@
address information in the 15-bit variable field, and zero to eight
CAN data bytes.</P>
<P STYLE="font-style: normal">For OpenLCB messages, the variable
-field is used in three forms:</P>
+field is used in two forms:</P>
<UL>
<LI><P STYLE="font-style: normal">Unaddressed messages – messages
that don't have a destination address put the low 12 bits of the MTI
in the variable field</P>
+</UL>
+<DIV ALIGN=RIGHT>
+ <TABLE WIDTH=817 BORDER=1 CELLPADDING=4 CELLSPACING=4>
+ <COL WIDTH=368>
+ <COL WIDTH=419>
+ <TR VALIGN=TOP>
+ <TH WIDTH=368>
+ <P>Variable Field Bit 0</P>
+ <P>Header Bit 2</P>
+ <P>0x0400,0000</P>
+ </TH>
+ <TH WIDTH=419>
+ <P>Variable Field Bits 1-14</P>
+ <P>Header Bits 3-16</P>
+ <P>OpenLCB Variable Header Content</P>
+ <P>0x03FF,F000</P>
+ </TH>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=368 SDVAL="0" SDNUM="1033;">
+ <P ALIGN=CENTER>0</P>
+ </TD>
+ <TD WIDTH=419>
+ <P ALIGN=CENTER>OpenLCB message information</P>
+ </TD>
+ </TR>
+ </TABLE>
+</DIV>
+<P><BR><BR>
+</P>
+<UL>
<LI><P STYLE="font-style: normal">Addressed messages – messages
that have a specific destination address put it in the variable
field, and carry the MTI in the payload. This allows filtering.</P>
- <LI><P STYLE="font-style: normal">Stream addressed messages – as a
- special case to improve efficiency of transfer, the streaming
- protocol uses 12 bits of the variable field to identify a particular
- stream transfer. This is not the same as a destination NodeID alias,
- but performs a similar function to allow filtering while also
- allowing multiple streams from a source.</P>
</UL>
-<P STYLE="margin-bottom: 0cm"><I>(Global vs addressed bit – really
-only two formats here)</I></P>
-<P STYLE="margin-bottom: 0cm"><BR>
+<DIV ALIGN=RIGHT>
+ <TABLE WIDTH=817 BORDER=1 CELLPADDING=4 CELLSPACING=4>
+ <COL WIDTH=223>
+ <COL WIDTH=278>
+ <COL WIDTH=274>
+ <TR VALIGN=TOP>
+ <TH WIDTH=223>
+ <P>Variable Field Bit 0</P>
+ <P>Header Bit 2</P>
+ <P>0x0400,0000</P>
+ </TH>
+ <TH WIDTH=278>
+ <P>Variable Field Bits 1-2</P>
+ <P>Header Bits 3-4</P>
+ <P>OpenLCB Variable Header Content</P>
+ <P>0x0300,0000</P>
+ </TH>
+ <TH WIDTH=274>
+ <P>Variable Field Bits 3-14</P>
+ <P>Header Bits 5-16</P>
+ <P>OpenLCB Variable Header Content</P>
+ <P>0x00FF,F000</P>
+ </TH>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=223 SDVAL="1" SDNUM="1033;">
+ <P ALIGN=CENTER>1</P>
+ </TD>
+ <TD WIDTH=278>
+ <P ALIGN=CENTER>OpenLCB message information</P>
+ </TD>
+ <TD WIDTH=274>
+ <P ALIGN=CENTER>Destination Node ID Alias</P>
+ </TD>
+ </TR>
+ </TABLE>
+</DIV>
+<P><BR><BR>
</P>
-<P STYLE="margin-bottom: 0cm">The variable field is allocated:</P>
<P STYLE="margin-bottom: 0cm"><BR>
</P>
-<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
- <COL WIDTH=96*>
- <COL WIDTH=160*>
- <TR VALIGN=TOP>
- <TH WIDTH=37%>
- <P>Variable Field Bits 0-2</P>
- <P>Header Bits 2-4</P>
- <P>OpenLCB Format</P>
- <P>0x0700,0000</P>
- </TH>
- <TH WIDTH=63%>
- <P>Variable Field Bits 3-14</P>
- <P>Header Bits 5-16</P>
- <P>OpenLCB Variable Header Content</P>
- <P>0x00FF,F000</P>
- </TH>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 0 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>MTI & additional information for “simple
- node” unaddressed messages</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 0 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>MTI & additional information for unaddressed
- messages other than “simple node” forms</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 1 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>(Reserved, must not be sent or accepted)</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 1 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>(Reserved for long-form MTIs in data area, <BR>must
- not be sent or accepted)</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 0 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for datagram message non-last
- fragment</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 0 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for datagram message last
- fragment</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 1 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for non-datagram addressed
- messages</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 1 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for Stream Data Send messages</P>
- </TD>
- </TR>
-</TABLE>
-<P>Putting the destination alias in the header allows filtering on it
-with common CAN hardware. Putting the Stream ID in the header also
-allows filtering, and preserves the full 8-byte CAN payload for
-stream data.</P>
-<P><SPAN STYLE="font-style: normal">The specific MTI values are being
-allocated in a <A HREF="../documents/MtiAllocations.ods">separate
-worksheet</A> (<A HREF="../documents/MtiAllocations.pdf">PDF
-version</A>). In general, the MTI selection is done on the top 8 bits
-of the variable field. This is mapped to the low MTI byte in a
-standard format message.</SPAN></P>
+<P><BR><BR>
+</P>
<H2 CLASS="western">Frame Communications Process</H2>
<UL>
<LI><P STYLE="margin-bottom: 0cm">Nodes must handle full rate
Modified: trunk/specs/drafts/CanMessageNetworkExpl.html
===================================================================
--- trunk/specs/drafts/CanMessageNetworkExpl.html 2010-10-03 01:25:26 UTC (rev 972)
+++ trunk/specs/drafts/CanMessageNetworkExpl.html 2010-10-05 04:35:24 UTC (rev 973)
@@ -6,12 +6,15 @@
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;22351500">
+ <META NAME="CHANGED" CONTENT="20101004;9363200">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<STYLE TYPE="text/css">
<!--
H2.ctl { font-family: "Lucida Sans" }
@@ -36,17 +39,31 @@
<HR>
<P>Below this is just a collection of pieces from other docs right
now.</P>
+<P>The priority bit in the CAN frame is separate from the static
+priority field in the MTI format specification.</P>
<P><BR><BR>
</P>
+<P STYLE="margin-bottom: 0cm"><SPAN STYLE="font-style: normal">The
+specific MTI values are being allocated in a <A HREF="../documents/MtiAllocations.ods">separate
+worksheet</A> (<A HREF="../documents/MtiAllocations.pdf">PDF
+version</A>). In general, the MTI selection is done on the top 8 bits
+of the variable field. This is mapped to the low MTI byte in a
+standard format message.</SPAN></P>
+<P STYLE="margin-bottom: 0cm"><BR>
+</P>
<P><SPAN STYLE="font-style: normal">Some MTIs have additional status
-bits defined as part of the 2</SPAN><SUP><SPAN STYLE="font-style: normal">nd</SPAN></SUP><SPAN STYLE="font-style: normal">
-field. For example, there are two status bits associated with
-“Consumer Identified” which must be kept in the header since
-there is no room in the CAN data field. To simplify translation
-between formats, these are the low bits of the first byte after the
-MTI in a standard-form message.</SPAN></P>
-<P><BR><BR>
-</P>
+bits defined as part of the 2</SPAN><SUP><SPAN STYLE="font-style: normal">nd</SPAN></SUP>
+<SPAN STYLE="font-style: normal">field. For example, there are two
+status bits associated with “Consumer Identified” which must be
+kept in the header since there is no room in the CAN data field. To
+simplify translation between formats, these are the low bits of the
+first byte after the MTI in a standard-form message.</SPAN></P>
+<UL>
+ <LI><P STYLE="margin-bottom: 0cm">Designers may wish to use CAN
+ hardware filtering, but it can't be assumed to be present. We assign
+ a single bit to indicate “simple node protocol” messages to make
+ simple filtering possible.</P>
+</UL>
<H3 CLASS="western">Left over from Frame doc</H3>
<P>OpenLCB common messages are converted, to the extent possible, to
single CAN frames via a one-to-one mapping.
Modified: trunk/specs/drafts/CanMessageNetworkSpec.html
===================================================================
--- trunk/specs/drafts/CanMessageNetworkSpec.html 2010-10-03 01:25:26 UTC (rev 972)
+++ trunk/specs/drafts/CanMessageNetworkSpec.html 2010-10-05 04:35:24 UTC (rev 973)
@@ -6,11 +6,12 @@
<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
<META NAME="CREATED" CONTENT="0;0">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;21343400">
+ <META NAME="CHANGED" CONTENT="20101003;2384900">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
+ <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
<STYLE TYPE="text/css">
<!--
H2.ctl { font-family: "Lucida Sans" }
@@ -110,7 +111,7 @@
</TR>
<TR VALIGN=TOP>
<TD WIDTH=37%>
- <P ALIGN=CENTER>0 0 0</P>
+ <P ALIGN=CENTER>0 1 0</P>
</TD>
<TD WIDTH=63%>
<P ALIGN=CENTER>(Reserved, must not be sent or accepted)</P>
@@ -181,9 +182,9 @@
with Destinations IDs may occur in two forms: with an alias in the
header and the MTI in the message; and with a full address in the
data field and the MTI in the header.</P>
-<P STYLE="margin-bottom: 0cm; font-style: normal"><BR>
+<P STYLE="margin-bottom: 0cm"><BR>
</P>
-<P STYLE="margin-bottom: 0cm; font-style: normal"><BR>
+<P STYLE="margin-bottom: 0cm"><BR>
</P>
<HR>
<P>Below this is just a collection of pieces from other docs right
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-08 06:19:56
|
Revision: 983
http://openlcb.svn.sourceforge.net/openlcb/?rev=983&view=rev
Author: jacobsen
Date: 2010-10-08 06:19:50 +0000 (Fri, 08 Oct 2010)
Log Message:
-----------
minor edits, still needs work
Modified Paths:
--------------
trunk/specs/drafts/CanFrameTransferExpl.odt
trunk/specs/drafts/CanFrameTransferExpl.pdf
trunk/specs/drafts/CanFrameTransferSpec.odt
trunk/specs/drafts/CanFrameTransferSpec.pdf
Modified: trunk/specs/drafts/CanFrameTransferExpl.odt
===================================================================
(Binary files differ)
Modified: trunk/specs/drafts/CanFrameTransferExpl.pdf
===================================================================
(Binary files differ)
Modified: trunk/specs/drafts/CanFrameTransferSpec.odt
===================================================================
(Binary files differ)
Modified: trunk/specs/drafts/CanFrameTransferSpec.pdf
===================================================================
(Binary files differ)
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 00:57:56
|
Revision: 987
http://openlcb.svn.sourceforge.net/openlcb/?rev=987&view=rev
Author: jacobsen
Date: 2010-10-09 00:57:48 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
fix formatting
Removed Paths:
-------------
trunk/specs/drafts/CanFrameTransferExpl.html
trunk/specs/drafts/CanFrameTransferSpec.html
trunk/specs/drafts/TemplateSpec.html
Deleted: trunk/specs/drafts/CanFrameTransferExpl.html
===================================================================
--- trunk/specs/drafts/CanFrameTransferExpl.html 2010-10-09 00:55:40 UTC (rev 986)
+++ trunk/specs/drafts/CanFrameTransferExpl.html 2010-10-09 00:57:48 UTC (rev 987)
@@ -1,624 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB CAN Frame Transfer Explanation</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20101004;9400500">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- H3.ctl { font-family: "Lucida Sans" }
- H4.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-CAN Frame Transfer Explanation</H1>
-<H2 CLASS="western">Introduction</H2>
-<P>This explanatory note contains informative discussion and
-background for the corresponding “OpenLCB CAN Frame Transfer
-Specification”. This explanation is not normative in any way.</P>
-<P>The Frame Transfer layer of the OpenLCB-CAN stack likes above the
-CAN Physical Layer, and below the Message Network layer. It is
-responsible for ensuring the reliable transport of the CAN frames
-that make up OpenLCB-CAN messages. CAN provides reliable transport
-between any two nodes on a CAN segment within limitations:</P>
-<OL>
- <LI><P>Every CAN header must be unique by construction. Collisions
- between frames with identical headers do not result in well-defined
- behavior, and must be avoided by design to avoid intermittent
- problems.</P>
- <LI><P>CAN does not provide a “link up” or “link down”
- notification. Nodes may come and go from a CAN segment at any time,
- and on an individual basis. In general, one can't assert that a
- particular node is always present, always comes up first, or never
- comes up first.</P>
- <LI><P>CAN does not provide any indicator of which node sent a
- particular frame. Any node can send any frame, and the receiving
- nodes have no CAN-provided mechanism for identifying the source.</P>
- <LI><P>On a busy segment, CAN frames are sent in a strict priority
- order, with the priority determined by the content of the frame
- headers. If multiple nodes have frames to send at the same time, the
- highest priority (lowest numerical value header) frame will be sent
- first. There is no concept of “reserved bandwidth” except
- through frame priority, and low-priority frames may require
- significant time to be sent.</P>
- <LI><P>Nodes must be able to accept frames at the full CAN rate.
- Hardware filters must be usable to help with that, but even then
- nodes may receive adjacent frames addressed to them.</P>
-</OL>
-<P>Putting a unique source ID field in each frame ensures that the
-frames are unique (item 1 above), and provides a frame-level
-indicator of which node sent the frame for the purposes of
-monitoring, debugging, etc (item 3). Using a distributed algorithm to
-determine the value for that ID field prevents needing a single
-“manager” to provide it, thereby handling item 2. The header bit
-fields discussed below are organized to handle items 4 and 5.
-</P>
-<P>OpenLCB-CAN is required to work with standard CAN components, e.g.
-bridges and computer adapters must not require customization to
-operate with OpenLCB. This provides a stringent requirement on
-protocol design, in that OpenLCB-CAN cannot require specific timing,
-deliberate creation of error cases or specific error handling.
-</P>
-<P>People will occasionally refer to a restriction against having
-seven 1 bits in the top 11 bits of the CAN header. There is no such
-restriction, and the statements are the result of a misunderstanding.
-There is a restriction against having seven consecutive recessive
-bits on the CAN connection, but sending seven consecutive 1 bits will
-not result in this. CAN uses a bit-stuffing technique to prevent that
-by inserting a dominant bit on the line after the fifth consecutive
-recessive bit, and removing it at the receiver.</P>
-<H2 CLASS="western">Annotations to the Specification</H2>
-<P>This section provides background information on corresponding
-sections of the Specification document. It's expected that two
-documents will be read together.</P>
-<H3 CLASS="western">Introduction</H3>
-<H3 CLASS="western">References and Context</H3>
-<P>Note that we reference the Node ID specification, but only to the
-extent that each node is required to have a unique Node ID. The
-Specification would work equally well with a Node ID that was
-allocated via any mechanism, and with any length from 2 to 8 bytes.</P>
-<H3 CLASS="western">Frame Format</H3>
-<P>OpenLCB uses a very vanilla transfer of frames, no special
-features, to reduce complexity and increase robustness.</P>
-<P>Standard header frames are also known as CAN 2.0A frames. Extended
-header frames are also known as CAN 2.0B frames.</P>
-<P>The specification is silent on the uses for standard (11-bit
-header) frames. The proper-operation requirement is so nodes will
-tolerate them in case they're needed for other purposes. The Atmel
-bootloader () uses standard frames, for example, and the Microchip
-bootloader () can use them.
-</P>
-<P>This could also have been phrased as “shall ignore ...”, but
-the current phrasing is thought to be more exact.</P>
-<P>We don't use RTR because CAN semantics require a specific use for
-it, which has been built into some silicon implementations. There are
-also some arbitration issues, see: CiA Application Note 802 (2005)
-and <A HREF="http://www.thecanmancan.com/?tag=rtr">http://www.thecanmancan.com/?tag=rtr</A>
-for more information.</P>
-<P>We don't use overload frames because not all CAN controller
-hardware can deliberately send them. We require that nodes be able to
-handle them because some CAN controller hardware will occasionally
-send them automatically.</P>
-<P>The CAN format has been allocated on nibble boundaries to make it
-easier to e.g. read dumps of packets. The header is considered to be
-right (LSB) aligned.</P>
-<P>The reserved first bit (MSB) is likely to be used as a
-priority-boost bit in the future, e.g. so that a gateway can gain
-priority access to the CAN segment for various operations that
-require synchronization or atomicity. CAN encodes “do first”
-priority as 0 and “do later” as 1, so the specification requires
-that a 1 bit be sent. To preserve the utility of this, nodes must not
-require either a 1 nor 0 on receipt.</P>
-<H2 CLASS="western">CAN-specific Control Messages and Interactions
-(Normative)</H2>
-<H3 CLASS="western">States</H3>
-<H3 CLASS="western">Control Message Format</H3>
-<P><BR><BR>
-</P>
-<H3 CLASS="western">Interactions</H3>
-<P>Communications protocols are about more than messages. The
-protocols must also specify the interactions in which the messages
-are used.</P>
-<H4 CLASS="western">ID Alias assignment</H4>
-<H4 CLASS="western">ID Alias validation</H4>
-<H4 CLASS="western">ID Alias termination</H4>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<P>Putting the destination alias in the header allows filtering on it
-with common CAN hardware.</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<H3 CLASS="western">Link State</H3>
-<P><BR><BR>
-</P>
-<H4 CLASS="western">Throughput and Temporarily Deaf Nodes</H4>
-<P>OpenLCB requires that CAN-attached nodes be able to handle the
-full frame rate on the CAN bus. There is no guarantee that frames for
-a given node will arrive with non-zero time between then.
-</P>
-<P>Some nodes are not always able to process frames. For example, the
-node may cease processing for a short time while writing non-volatile
-memory. Higher-level protocols, e.g. configuration write datagrams,
-have mechanisms built in to prevent overrun while writing
-configuration memory, but there could be multiple activities going on
-in parallel that will result in frames arriving while the node is not
-processing.</P>
-<P>Short outages can be covered by CAN hardware buffering, so long as
-the node will eventually catch up even at full arrival rate. Outages
-long enough that frames are lost due to e.g. buffer overflow require
-node to broadcast that it's back up if hardware detected frame lost.
-This is because tehre could have been frames of some form that
-modified the OpenLCB node state, which are now lost (e.g. drop alias,
-CIM/RIM in absence, or even higher level events)
-</P>
-<P><BR><BR>
-</P>
-<P>Eventually may have to allow use of Overload Frames to throttle
-for e.g. NVRAM writing.</P>
-<P><BR><BR>
-</P>
-<H3 CLASS="western">State machine</H3>
-<P>E.g. Higher level starts link control by providing a valid NID and
-telling to to start off.</P>
-<HR>
-<P><BR><BR>
-</P>
-<P>Header content and sizes (Nominal decisions shown, 29 bit header):
-</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Priority bit (Always sent as 1
- now; at front to ensure it acts like a true priority; 0 for high
- priority, 1 for low; not checked by receivers)
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Frame Type (1 bit) OpenLCB message
- or CAN control message
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Variable Field (15 bits)
- </P>
- <LI><P>Source NID alias (12 bits)
- </P>
-</UL>
-<P>The order of these fields is chosen to get proper priority and
-access disambiguation via CAN's standard mechanisms.</P>
-<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
- <COL WIDTH=64*>
- <COL WIDTH=64*>
- <COL WIDTH=64*>
- <COL WIDTH=64*>
- <TR VALIGN=TOP>
- <TH WIDTH=25%>
- <P>Bit 0</P>
- </TH>
- <TH WIDTH=25%>
- <P>Bits 1</P>
- </TH>
- <TH WIDTH=25%>
- <P>Bits 2-16</P>
- </TH>
- <TH WIDTH=25%>
- <P>Bits 17-28</P>
- </TH>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Priority: 0 high, 1 low</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Frame Type</P>
- <P ALIGN=CENTER>1: OpenLCB Message</P>
- <P ALIGN=CENTER>0: CAN Control Message</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Variable Field</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Source NID Alias</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x1000,0000</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x0800,0000</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x07FF,F000</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x0000,0FFF</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Solo top bit</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Top bit of 6<SUP>th</SUP> nibble from right</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>3 bits lower bits, then three nibbles</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Right-most three nibbles</P>
- </TD>
- </TR>
-</TABLE>
-<P STYLE="margin-bottom: 0cm">The "Variable field" has
-different meanings depending on the "Frame Type" field. CAN
-control messages are identified with a Frame Type bit of 0, to ensure
-high priority.</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<H2 CLASS="western">On the choice of a 12-bit alias length</H2>
-<P>How big should the NodeID alias field be on CAN links?</P>
-<UL>
- <LI><P>Smaller (fewer bits) allows more payload and/or simpler
- coding of other parts of messages.
- </P>
- <LI><P>Larger allows more unique nodes to be accessed.</P>
-</UL>
-<H3 CLASS="western">Issues</H3>
-<H4 CLASS="western">Addressing</H4>
-<P>The Node ID size limits the number of unique nodes that can take
-part in communications on the CAN segment. Because Node ID aliases
-are assigned independently on each CAN segment, the only issue is how
-many different nodes are involved, not which ones they are or what
-pattern(s) are available in their address numbers.</P>
-<P>For electrical/timing reasons, a segment itself can only support a
-maximum of about 50 nodes, but communication also involves nodes off
-the segment. For example, chaining N CAN segments via bridges will
-generally make up to 50*N nodes available. We have a use case of
-chaining small numbers of CAN segments together, implying the need to
-address 500 or 1000 nodes.
-</P>
-<P>As another example, a very large network might connect many CAN
-segments via TCP/IP or other networked connections. Each CAN-attached
-node might need to communicate with a larger number of others spread
-across that network.</P>
-<P>(CAN backbone case)</P>
-<P>In some cases, want 2 aliases (source and destination), plus a few
-more bits, in 29 bits total. 29-(2*12) = 5 is a pretty compelling
-choice.</P>
-<H4 CLASS="western">Collisions during Allocation</H4>
-<P>(not talking CAN arbitration here, but two nodes trying to use
-same alias) The allocation process resolves collisions (attempt to
-use an already allocated Node ID alias), but that takes time.
-Minimizing the number of collisions is good. If the address space is
-just the size of the number of things you want to address, the
-collisions get hard /slow to resolve across multiple nodes. This
-points to having a factor of 2, at least, between the number of nodes
-to be addressed and the size of the address space.</P>
-<P>(Mostly talking about separate nodes here, not just one big
-interface node: Points to CAN backbone case)</P>
-<H4 CLASS="western">Size</H4>
-<P>Reducing size most important (so far) in the stream protocol.</P>
-<P>Events and Datagrams can be transmitted with a 16-bit alias size.</P>
-<P>To get the full payload (8 bytes) for streaming requires getting
-the rest of the protocol control, including two aliases for source
-and destination, in the 29 bit header. Allowing 1 bit for
-priority/extension, 1 for protocol control, 3 for MTI and stream
-control (all very bare minima) leads to a 12-bit node ID alias
-length.
-</P>
-<H4 CLASS="western">Simplicity</H4>
-<P>Byte vs nibble vs bit boundaries in code, when debugging the
-protocol, etc.</P>
-<P>Having extra bits available in the header allows much simpler MTI
-coding, reserving specific bits for expansion instead of codes, etc.</P>
-<H4 CLASS="western">Filtering</H4>
-<P>Having the destination short enough to be in the header allows
-automated filtering of traffic. Nodes must still deal with the full
-rate, because messages can always be adjacent in time.</P>
-<P><BR><BR>
-</P>
-<P>(Need to discuss the case of two segments being joined, to
-discover they've both arbitrated the same aliases, including with
-gateways on one or both)</P>
-<P><BR><BR>
-</P>
-<H2 CLASS="western">CAN Controller Filters</H2>
-<P STYLE="margin-bottom: 0cm">This coding has been generated such
-that simple nodes can use three hardware filters to select only
-frames that are of interest to them.</P>
-<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
- <COL WIDTH=85*>
- <COL WIDTH=85*>
- <COL WIDTH=85*>
- <TR VALIGN=TOP>
- <TH WIDTH=33%>
- <P ALIGN=CENTER>Purpose</P>
- </TH>
- <TH WIDTH=33%>
- <P ALIGN=CENTER>Mask</P>
- </TH>
- <TH WIDTH=33%>
- <P ALIGN=CENTER>Required Value</P>
- </TH>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=33%>
- <P ALIGN=CENTER>CAN-specific control messages</P>
- </TD>
- <TD WIDTH=33%>
- <P ALIGN=CENTER>0x0800,0000</P>
- </TD>
- <TD WIDTH=33%>
- <P ALIGN=CENTER>0x0000,0000</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=33%>
- <P ALIGN=CENTER>OpenLCB format addressed to this node</P>
- </TD>
- <TD WIDTH=33%>
- <P ALIGN=CENTER>0x0C00,0FFF</P>
- </TD>
- <TD WIDTH=33%>
- <P ALIGN=CENTER>0x0C00,0nnn</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=33%>
- <P ALIGN=CENTER>Other simple OpenLCB format MTIs</P>
- </TD>
- <TD WIDTH=33%>
- <P ALIGN=CENTER>0x0F00,0000</P>
- </TD>
- <TD WIDTH=33%>
- <P ALIGN=CENTER>0x0800,0000</P>
- </TD>
- </TR>
-</TABLE>
-<P STYLE="margin-bottom: 0cm">Note that whether or not filters are
-used, nodes must be able to handle all combinations of sucessive
-frames that the full CAN rate. There is no guarantee that a node will
-have time for processing between frames that it must handle.</P>
-<P><I>(but the simple-MTI stuff is at Message level)</I></P>
-<P><BR><BR>
-</P>
-<H2 CLASS="western" STYLE="page-break-before: always">From <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">Node
-ID Alias Allocation Algorithm doc</H2>
-<P>OpenLCB nodes on CAN segments do CAN arbitration by using their
-unique Node ID alias (NIDa) as part of the CAN header. This page
-documents a proposed algorithm for assigning unique Node ID aliases.
-</P>
-<H3 CLASS="western">Introduction</H3>
-<P>This method of assigning aliases and checking that they are unique
-is necessary because of the characteristics and limitations oFromf
-CAN.
-</P>
-<P>Each node has 48-bit unique id, and each wants a 12-bit local
-alias. Each assigns itself a potential 12-bit alias. The problem
-comes in determining whether this alias is in use by another node.
-</P>
-<P>If a node sends out an check message containing just the alias,
-then it could expect that another node to complain if it has the same
-alias. This would work, except in the (admittedly unlikely) case
-where both nodes send out the identical check message simultaneously.
-Neither would recognize a conflict and both would consider that they
-own the same alias. Therefore, a method needs to be found that
-guarantees that the check message(s) are unique, even if they are
-sent simultaneously.
-</P>
-<P><I>(timing of serialization of low-priority CAN nodes at network
-startup)</I></P>
-<P><I>(can store starting point, not just alias, for later use)</I></P>
-<P>Unfortunately, limitations of CAN will not allow the full 48-bit
-NodeID to be included in the check message. Doing so would violate
-CAN rules as it could not be wholly contained in the header, and
-packets with identical headers are not allowed to have differing
-data-parts.
-</P>
-<P>Therefore, the CIM/RIM method splits the NodeID into byte-sized
-parts, sends out 4 check messages (CIM = Check Id Messages, RIM =
-Reserved Id Message), each consisting of the alias and one quarter
-(12 bits) of the 48 bit id. Only if all of the CIMs *do not* conflict
-with another node (ie no RIM is received) does it guarantee that the
-alias is not in use by another node. Even if two nodes send out the
-identical packets simultaneously, at least one of these will differ
-due to a differing ID-part between the two nodes.
-</P>
-<H3 CLASS="western">Requirements</H3>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Must not require any user
- intervention.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Must be possible to map the
- assigned alias to a Node Sequence Number and vice-versa.</P>
- <LI><P STYLE="margin-bottom: 0cm">It is not required to come up with
- the same alias every time a node or segment is powered up.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Must always converge to an alias,
- regardless of when or in what order nodes come up.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Another node watching the process
- must be able to monitor how the decision was reached and what the
- result was.
- </P>
- <LI><P>It is desirable to detect duplicate (non-unique) NIDs, but
- 100% reliable detection is not required.
- </P>
-</UL>
-<H3 CLASS="western">Algorithm</H3>
-<P>Start with the six-byte unique Node ID in each node, with the
-bytes labelled N1 through N6.
-</P>
-<P>Initialize a specific full-sequence 48bit PRNG with the 48 Node
-ID.
-</P>
-<P>A:
-</P>
-<P>Take the next element from the PRNG . Derive the 12-bit value for
-TCA, the tentative alias. If TCA is zero, repeat.</P>
-<P>Start listening for CAN frames containing Check ID messages (CIMs)
-and Reserved ID Messages (RIMs). A CIM consists of an extended header
-with a 12 bit Source NIDa field, an 3 bit sequence field, a 12-bit
-TestN field, and other bits to denote that this is a Check ID
-Message. There is no other variable information in the frame. Having
-NIDa, Nn and TestN in the message ensure that CAN arbitration will
-work without error. An RIM is the same, except that it can be
-identified as being a different message for diagnostic purposes; it
-means the same thing upon receipt.
-</P>
-<P>Send four CIMs with 0 through 3 in the Nn field, the 12-bit
-quarters of the NodeID in the TestN field, and TCA in the Source NIDa
-field. During this process, if a CIM or RIM is received that contains
-the TCA value in its CI field, TCA does not belong to this node.
-Repeat from (A).
-</P>
-<P>Keep listening until your CAN hardware says your last CIM message
-has been sent and the CAN link is idle, plus 500 msec. If you cannot
-detect that condition, wait 1 second.</P>
-<P>If no CIM or RIM with this TCA value in the CI field is received
-before the end of the previous step, you've successfully allocated
-TCA as this node's source NIDa. Send an RIM with TCA in the CI field
-and go into normal operation.
-</P>
-<UL>
- <LI><P>If that message fails with an error occurring during the data
- portion of the message, it's possible that two nodes have the same
- NodeID, a fatal error. To prevent the OpenLCB being taken down, this
- node should stop trying to allocate an alias and signal the error to
- the user via some non-CAN method, e.g. LEDs, emitting smoke, etc.</P>
- <LI><P>If any other error occurs, repeat from A.</P>
-</UL>
-<P>While in normal operation, if you receive a CIM with your source
-NIDa, send a RIM, which will cause the other node to back off and try
-something else.
-</P>
-<P>It should not be possible to receive an RIM with your allocated
-source NIDa in normal operation. If you do, log an error (on whatever
-it is they log it on there) and restart the process at (A).
-</P>
-<H4 CLASS="western">Proposed alias derivation</H4>
-<P>The 12 bit alias has to be derived from a 48-bit sequence number
-in a way that keeps as much entropy as possible.</P>
-<P>Sequentially numbered nodes will have initial seeds that differ
-only in the low bits of the PRNG output. For shift-register PRNGs,
-this can present a problem, as all bytes of the result are shifting
-together. Combining bytes (or even 12-bit chunks) via XOR or add
-operations results in reduced entropy.</P>
-<P>The OpenLCB proposed PRNG (next section) uses add operations with
-a constant term to avoid this problem, so treating the 48-bit PRNG
-output as four 12-but values, which are then XORed, works well.</P>
-<H4 CLASS="western">Proposed PRNG</H4>
-<P>The proposed 48-bit PRNG is from “A 48-Bit Pseudo-Random Number
-Generator”, Heidi G. Kuehn, Communications of the ACM, Volume
-4, Issue 8 (August 1961), pages 350-352.</P>
-<P>x<SUB>i+1</SUB> = (2<SUP>9</SUP>+1) x<SUB>i</SUB> + c</P>
-<P>where c = 29,741,096,258,473 or 0x1B0CA37A4BA9.The paper actually
-describes a PRNG that uses signed arithmetic, but for our purposes
-the 48<SUP>th</SUP> “sign” bit isn't important. <I>(verify that
-about sign) (This is a byte+bit shift and add, so it's quick to
-calculate)</I></P>
-<P>Note that, unlike some other PNRGs, this one can generate a zero
-result, and can accept a zero seed.</P>
-<H3 CLASS="western">Discussion</H3>
-<P>CAN arbitration reliably avoids collisions between frames with
-unique headers. It does not guarantee arbitration between frames with
-identical headers and no data; if the timing is right, they may
-overlay each other such that only one frame appears to have been
-sent. It is very difficult to ensure that two nodes send
-initialization packets only at different times. In addition, CAN will
-eventually signal an error if two packets with the same header and
-different data payloads collide, but not all CAN interface hardware
-provides reliable indications about why that error occurred. <I>(lock
-step issue at startup)</I></P>
-<P>At the highest level, this algorithm is broadcasting the complete
-Node ID and tentative alias to see if any other node is checking the
-same tentative alias. If two nodes have taken the same tentative
-alias, at least one of the four packets used in that broadcast will
-not be identical between the two nodes, because their six-byte Node
-IDs are different in at least one bit. CAN will successfully
-arbitrate this, and the other node will receive the frame, causing it
-to back off.</P>
-<P>CAN transmissions are not atomic operations; you can receive a
-frame between the time you tell the hardware to send a frame and the
-time that frame is actually sent. It's therefore possible for both
-nodes contending for the same alias value to back off and try again.
-Using the pseudo-random number generator as a sequence number makes
-it likely that the next attempt will be made using different alias
-values in the two nodes. <SPAN STYLE="font-style: normal">The use of
-the sequence generator also makes the arbitration process faster in
-the case of sequential Node ID values. People like to use small and
-sequential numbers for things, and the sequence generator maps those
-to very different values that are less likely to collide during
-arbitration. </SPAN>
-</P>
-<P>The delays at the end of the algorithm are to ensure that higher
-latency nodes, such as software nodes working through USB convertors,
-can reply to CID messages from nodes that come up on a working link.
-OpenLCB is a soft-real-time system, and software that's interacting
-with it needs to have response times of a couple hundred milliseconds
-or better to be reliable. The algorithm provides a wait of a few
-times that to enable those programs to take part.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<H3 CLASS="western">Rate, bandwidth and throttling</H3>
-<P>29-bit extended header and 8-byte payload results in a total
-transmission taking about 135 bit times.</P>
-<P>125Kbps with max-length extended header frames is about 900
-frames/second. CAN is very good at running at 100% utilization, so
-long as nodes can keep up and a proper set of priorities is in place.</P>
-<P>CAN is designed to run at 100% usage without problem, and it's
-routine for CAN segments in other contexts to run at 100% for
-extended times. Therefore, the CAN network does not require any
-inter-frame spacing, limitations on bandwidth usage, etc; the segment
-can be allowed to run at 100%.</P>
-<P>The real limitation is whether the nodes themselves can handle the
-full rate of frame arrival. There is (currently) no mechanism in
-OpenLCB to throttle the rate of frames arriving at a node, nor is it
-easy to create one in a CAN network. The stream and datagram protocol
-have been designed to allow a node to efficiently use a very limited
-amount of buffer memory, but don't provide mechanisms to limit the
-arrival of frames.</P>
-<P>For long term reliability, a node <U>must</U> be able to
-completely process an entire CAN frame in the time it takes to
-receive the next one, which may be as little as 42 (?) bit times.</P>
-<H3 CLASS="western">CIM/RIM message content and format</H3>
-<P>The CIM/RIM algorithm for finding aliases is designed to work
-without any CAN errors. Arbitration conflicts are OK, but deliberate
-errors are not, because different CAN implementations may deal with
-them differently. During execution of the algorithm, some frames
-might have the same header. They therefore have to have the same
-contents, or else a non-arbitration error can occur.</P>
-<P>Although it might be a useful debugging tool, putting the full NID
-in the data portion of the frames can cause errors. Therefore, we
-decided not to do that.</P>
-<H3 CLASS="western">Additional References</H3>
-<P>B. Gaujal and N. Navet, “Fault confinement mechanisms on CAN:
-analysis and improvements”, IEEE Transactions on Vehicular
-Technology, pp.1103-1113, 54(3), May 2005 (An interesting analysis of
-how CAN nodes react to error rates on the CAN bus by e.g. taking
-themselves offline, etc)</P>
-<P><I>(Take some from physical layer doc)</I></P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Deleted: trunk/specs/drafts/CanFrameTransferSpec.html
===================================================================
--- trunk/specs/drafts/CanFrameTransferSpec.html 2010-10-09 00:55:40 UTC (rev 986)
+++ trunk/specs/drafts/CanFrameTransferSpec.html 2010-10-09 00:57:48 UTC (rev 987)
@@ -1,516 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB CAN Frame Transfer Specification</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20101004;9391400">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- H3.ctl { font-family: "Lucida Sans" }
- H4.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-CAN Frame Transfer Specification</H1>
-<H2 CLASS="western">Introduction (Informative)</H2>
-<P>This specification describes the mechanism for sending OpenLCB-CAN
-information via frames on a CAN segment.
-</P>
-<H2 CLASS="western">References and Context (Normative)</H2>
-<P>This specification is in the context of the following OpenLCB-CAN
-Specifications:</P>
-<UL>
- <LI><P>The OpenLCB-CAN Physical Layer specification, which specifies
- the physical layer for transporting OpenLCB CAN frames</P>
- <LI><P>The OpenLCB Node Identifier Specification, which specifies …</P>
-</UL>
-<P>“CAN” refers to the electrical and protocol specifications as
-defined in ISO 11898-1:2003 and ISO 11898-2:2003 and their
-successors.</P>
-<P>External certification of parts shall be accepted for conformance
-to these standards. Conformance with a later version of a standard
-shall be accepted as conformance with the referenced versions.</P>
-<H2 CLASS="western">Frame Format (Normative)</H2>
-<P>OpenLCB-CAN frames are sent and received using the CAN extended
-format (29-bit header) only.
-</P>
-<P>OpenLCB-CAN nodes shall operate properly when the CAN segment
-carries proper standard-format (11-bit header) frames.</P>
-<P>OpenLCB-CAN nodes shall not transmit extended-format remote frames
-(frames with RTR set). Nodes shall operate properly when the CAN
-segment carries proper extended-format remote frames.</P>
-<P>OpenLCB-CAN nodes shall not transmit overload frames. Nodes shall
-operate properly when the CAN segment carries proper overload frames.</P>
-<P STYLE="margin-bottom: 0cm">The first (most-significant) bit is
-reserved for future use. It must be transmitted as a 1 bit, and
-ignored upon receipt.</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">The second (second-most-significant)
-bit is the Frame Type indicator. A value of 0 indicates a
-CAN-specific Control Message. A value of 1 indicates an OpenLCB
-Message.</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">The next 15 bits are termed the
-Variable Field. The format and contents of the Variable Field depends
-on Frame Type and are defined in later sections.</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">The last twelve bits (least
-significant) are the Source Node ID Alias value.</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
- <COL WIDTH=64*>
- <COL WIDTH=64*>
- <COL WIDTH=64*>
- <COL WIDTH=64*>
- <TR VALIGN=TOP>
- <TH WIDTH=25%>
- <P>Bit 0</P>
- </TH>
- <TH WIDTH=25%>
- <P>Bits 1</P>
- </TH>
- <TH WIDTH=25%>
- <P>Bits 2-16</P>
- </TH>
- <TH WIDTH=25%>
- <P>Bits 17-28</P>
- </TH>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Reserved: Send as 1, <BR>ignore upon receipt</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Frame Type:</P>
- <P ALIGN=CENTER>1: OpenLCB Message</P>
- <P ALIGN=CENTER>0: CAN Control Message</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Variable Field</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Source NID Alias</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x1000,0000</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x0800,0000</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x07FF,F000</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>0x0000,0FFF</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Solo top bit</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Top bit of 6<SUP>th</SUP> nibble from right</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>3 bits, then three nibbles</P>
- </TD>
- <TD WIDTH=25%>
- <P ALIGN=CENTER>Right-most three nibbles</P>
- </TD>
- </TR>
-</TABLE>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P><BR><BR>
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<H2 CLASS="western">CAN-specific Control Messages and Interactions
-(Normative)</H2>
-<H3 CLASS="western">States</H3>
-<P>A node has two states:</P>
-<UL>
- <LI><P>Inhibited</P>
- <LI><P>Permitted</P>
-</UL>
-<P>Nodes shall start in the Inhibited state.</P>
-<P>Nodes shall transition to the Permitted state after assignment of
-a valid Node ID alias.</P>
-<P>A node may transmit Check ID Message and Reserved ID Message
-frames while in the Inhibited state. A node shall not transmit any
-other frame while in Inhibited state.</P>
-<H3 CLASS="western">Control Message Format</H3>
-<P>The format and contents of CAN-specific Control Messages are
-defined in the following table:</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<TABLE WIDTH=813 BORDER=1 CELLPADDING=2 CELLSPACING=4>
- <COL WIDTH=331>
- <COL WIDTH=332>
- <COL WIDTH=119>
- <TR>
- <TH WIDTH=331>
- <P>Name</P>
- </TH>
- <TH WIDTH=332>
- <P>Variable Field</P>
- </TH>
- <TH WIDTH=119>
- <P>Data Bytes</P>
- </TH>
- </TR>
- <TR>
- <TD WIDTH=331>
- <P>Check ID (CIM) Message</P>
- </TD>
- <TD WIDTH=332>
- <P>MMM,NNNN,NNNN,NNNN
- </P>
- <P>where MMM is the message sequence number, with valid values
- from 0x4 through 0x7</P>
- <P>and NNNN,NNNN,NNNN is the 12-bit Node ID section being checked</P>
- </TD>
- <TD WIDTH=119>
- <P>None</P>
- </TD>
- </TR>
- <TR>
- <TD WIDTH=331>
- <P>Reserved ID (RIM) Message</P>
- </TD>
- <TD WIDTH=332>
- <P>0x0700</P>
- </TD>
- <TD WIDTH=119>
- <P>None</P>
- </TD>
- </TR>
- <TR>
- <TD WIDTH=331>
- <P>Mapping Reset (MR) Message</P>
- </TD>
- <TD WIDTH=332>
- <P>0x0701</P>
- </TD>
- <TD WIDTH=119>
- <P>None</P>
- </TD>
- </TR>
- <TR>
- <TD WIDTH=331>
- <P>Mapping Enquiry Request (MRQ) Message</P>
- </TD>
- <TD WIDTH=332>
- <P>0x0702</P>
- </TD>
- <TD WIDTH=119>
- <P>Full Node ID</P>
- </TD>
- </TR>
- <TR>
- <TD WIDTH=331>
- <P>Mapping Enquiry Reply (MRR) Message</P>
- </TD>
- <TD WIDTH=332>
- <P>0x0703</P>
- </TD>
- <TD WIDTH=119>
- <P>Full Node ID</P>
- </TD>
- </TR>
- <TR>
- <TD WIDTH=331>
- <P>Reserved; may not be sent, and must be ignored upon receipt</P>
- </TD>
- <TD WIDTH=332>
- <P>All others</P>
- </TD>
- <TD WIDTH=119>
- <P>To be defined</P>
- </TD>
- </TR>
-</TABLE>
-<H3 CLASS="western">Interactions</H3>
-<H4 CLASS="western">ID Alias assignment</H4>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">… MMM is the message sequence number,
-0x7 to 0x4 (to give priority to messages later in the process)
-</P>
-<H4 CLASS="western">ID Alias validation</H4>
-<P>A node receiving a Mapping Enquiry Request Message shall compare
-the Full Node ID in the CAN data segment to the node's own Node ID.
-If and only if they match in length and content and the receiving
-node is in Permitted state, the node shall reply with a Mapping
-Enquiry Reply Message.</P>
-<H4 CLASS="western">ID Alias termination</H4>
-<P>A node receiving a Mapping Reset Message must drop the
-</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<P>The common message format uses full 48-bit node ID numbers to
-identify originating nodes and in some case destination nodes. CAN
-frames use 12-bit local "NID alias" for these to save space
-in the limited-size CAN payload.
-</P>
-<P>The standard Verify Node ID Number interaction can be used to get
-the full 48-bit NID from a node for translation. At power up each
-node must obtain a alias that is locally unique. Gateways will also
-have to obtain unique aliases for remote nodes they are proxying on
-to the segment.
-</P>
-<P>Proposed algorithm, in rough form:
-</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Compute a CANid from the NID using
- a standard algorithm.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Send CAN frames claiming that
- CANid and carrying sequential parts of NID in the Variable Field
- section of the header.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">If error, step the algorithm in a
- standard way and repeat until success.
- </P>
- <LI><P>Send a CAN frame announcing that the node has claimed an ID
- value.
- </P>
-</UL>
-<P>Note that there is no requirement that this alias be consistent
-from one run to the next. More detail is on a <A HREF="../documents/can/CanIDAllocation.html">separate
-page</A>.
-</P>
-<P><BR><BR>
-</P>
-<H3 CLASS="western">CAN-specific messages</H3>
-<P>Most CAN frames are one-to-one or many-to-one equivalents of
-common OpenLCB messages.
-</P>
-<P>A few additional messages are used for CAN-specific purposes.
-</P>
-<DL>
- <DT>CIM</DT><DD>
- Check ID Message - used as part of the <A HREF="../documents/can/CanIDAllocation.html">ID
- allocation</A>.
- </DD><DT>
- RIM</DT><DD>
- Reserved ID Message - used as part of the <A HREF="../documents/can/CanIDAllocation.html">ID
- allocation</A>.
- </DD><DT>
- MR</DT><DD STYLE="margin-bottom: 0.5cm">
- Mapping Reset - indicates that the local alias in the source address
- field may no longer be associated with the same NID, and mapping
- tables should be reset.
- </DD></DL>
-<H2 CLASS="western">
-Translation</H2>
-<P>A node must be able to convert traffic on the local CAN segment
-into the common message format using only locally available
-information. This may be needed e.g. by a gateway or monitoring
-program attached to the CAN segment.
-</P>
-<P>All traffic on a CAN segment uses aliases for both Source ID
-(always) and Destination ID (when the full NID isn't known).
-</P>
-<P>If/when a full NID is needed, it can be obtained by sending a
-"Verify Node ID Number (Addressed)" message with an
-appropriate Destination Node ID in local alias form. The reply will
-eventually come back with the Source ID in local alias form and
-carrying the full NID in the message content.
-</P>
-<P>Aliases for nodes on the local segment are only valid until an
-"Initialization Complete" is seen from that alias.
-Initialization Complete indicates that a node has restarted, and may
-have another local alias. <I>(Can't use Initialization Complete, it's
-the wrong layer, need something at the CAN level. Need something like
-RIM/CIM)</I></P>
-<P>Gateways maintain the mapping between remote node's NID and local
-alias. If they need to break that mapping, e.g. because they need to
-reuse the local alias due to resource limitations in the mapping
-tables, they must send a "Mapping Reset" message to force
-nodes to drop their alias information. <I>"Mapping Reset"
-is a CAN-specific message limited to the segment, but all gateways on
-the segment must act on it.</I>
-</P>
-<P>Gateways may not be able ensure permanent validity for alias to
-remote NIDs. For example, if they have a limited routing table, they
-may need to reuse local alias. Before reusing them, they have to send
-a "Mapping Reset" frame to drop references to the old NID,
-followed by a "Initialization Complete" when the alias is
-allocated to a new NID.
-</P>
-<H3 CLASS="western">Map Acquisition</H3>
-<P STYLE="margin-bottom: 0cm">In order to acquire the map between
-CANids and NIDs, a gateway needs to be able to send a CAN frame
-requiring "everybody reply with your NID". Much like
-Ethernet gateway mapping, this needs to return the NID of just the
-specific CAN-attached hardware, not all the NIDs that can be e.g.
-reached through a gateway, so it needs to be a segment-specific
-message defined only at the CAN level. It must not be a OpenLCB
-common message.
-</P>
-<P STYLE="margin-bottom: 0cm"><I>(Need to add the actual message
-definition)</I></P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<H2 CLASS="western">OpenLCB messages in Frames</H2>
-<P><I>(provides addressed and global, even though a CAN segment is
-intrinsically global; should explain above that OpenLCB is based on
-full-global access)</I></P>
-<H2 CLASS="western">OpenLCB message format</H2>
-<P>OpenLCB common messages are carried in frames with a 1 in the
-Frame Type field. They contain message type information and/or
-address information in the 15-bit variable field, and zero to eight
-CAN data bytes.</P>
-<P STYLE="font-style: normal">For OpenLCB messages, the variable
-field is used in two forms:</P>
-<UL>
- <LI><P STYLE="font-style: normal">Unaddressed messages – messages
- that don't have a destination address put the low 12 bits of the MTI
- in the variable field</P>
-</UL>
-<DIV ALIGN=RIGHT>
- <TABLE WIDTH=817 BORDER=1 CELLPADDING=4 CELLSPACING=4>
- <COL WIDTH=368>
- <COL WIDTH=419>
- <TR VALIGN=TOP>
- <TH WIDTH=368>
- <P>Variable Field Bit 0</P>
- <P>Header Bit 2</P>
- <P>0x0400,0000</P>
- </TH>
- <TH WIDTH=419>
- <P>Variable Field Bits 1-14</P>
- <P>Header Bits 3-16</P>
- <P>OpenLCB Variable Header Content</P>
- <P>0x03FF,F000</P>
- </TH>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=368 SDVAL="0" SDNUM="1033;">
- <P ALIGN=CENTER>0</P>
- </TD>
- <TD WIDTH=419>
- <P ALIGN=CENTER>OpenLCB message information</P>
- </TD>
- </TR>
- </TABLE>
-</DIV>
-<P><BR><BR>
-</P>
-<UL>
- <LI><P STYLE="font-style: normal">Addressed messages – messages
- that have a specific destination address put it in the variable
- field, and carry the MTI in the payload. This allows filtering.</P>
-</UL>
-<DIV ALIGN=RIGHT>
- <TABLE WIDTH=817 BORDER=1 CELLPADDING=4 CELLSPACING=4>
- <COL WIDTH=223>
- <COL WIDTH=278>
- <COL WIDTH=274>
- <TR VALIGN=TOP>
- <TH WIDTH=223>
- <P>Variable Field Bit 0</P>
- <P>Header Bit 2</P>
- <P>0x0400,0000</P>
- </TH>
- <TH WIDTH=278>
- <P>Variable Field Bits 1-2</P>
- <P>Header Bits 3-4</P>
- <P>OpenLCB Variable Header Content</P>
- <P>0x0300,0000</P>
- </TH>
- <TH WIDTH=274>
- <P>Variable Field Bits 3-14</P>
- <P>Header Bits 5-16</P>
- <P>OpenLCB Variable Header Content</P>
- <P>0x00FF,F000</P>
- </TH>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=223 SDVAL="1" SDNUM="1033;">
- <P ALIGN=CENTER>1</P>
- </TD>
- <TD WIDTH=278>
- <P ALIGN=CENTER>OpenLCB message information</P>
- </TD>
- <TD WIDTH=274>
- <P ALIGN=CENTER>Destination Node ID Alias</P>
- </TD>
- </TR>
- </TABLE>
-</DIV>
-<P><BR><BR>
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P><BR><BR>
-</P>
-<H2 CLASS="western">Frame Communications Process</H2>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Nodes must handle full rate
- messages, specifically including messages not addressed to them.
- (The datagram and stream protocols provide ways for nodes to
- indicate whether or not they have sufficient buffering for the next
- transmission, triggering retries as needed) For long term
- reliability, a node <U>must</U> be able to completely process an
- entire CAN frame in the time it takes to receive the next one, which
- may be as little as 64 bit times, or about 500 microseconds.</P>
- <LI><P></P>
-</UL>
-<P STYLE="margin-bottom: 0cm">Discuss the use of repeaters, bridges
-and gateways w.r.t. Timing; ref physical layer. Possibility of
-reordering.</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">Over<FONT FACE="Times New Roman, serif"><FONT SIZE=3>load
-frame: “</FONT></FONT><FONT COLOR="#000000"><FONT FACE="Times New Roman, serif"><FONT SIZE=3>Due
-to internal conditions, the node is not yet able to begin reception
-of the next message. A node may generate a maximum of two sequential
-overload frames to delay the start of the next message.” (That's 17
-to 23 extra bit times each) (from
-<A HREF="http://rs232-rs485.blogspot.com/2009/11/can-bus-message-frames-overload.html">http://rs232-rs485.blogspot.com/2009/11/can-bus-message-frames-overload.html</A>)
-Image:
-<A HREF="http://3.bp.blogspot.com/_ycHwJEosotY/SvoMDJMGF7I/AAAAAAAAA64/3Ql4_UQnoBg/s1600/Overload%2BFrame.JPG">http://3.bp.blogspot.com/_ycHwJEosotY/SvoMDJMGF7I/AAAAAAAAA64/3Ql4_UQnoBg/s1600/Overload%2BFrame.JPG</A></FONT></FONT></FONT></P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<H2 CLASS="western">Link State (Normative)</H2>
-<P><BR><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">(needs a diagram in the explanation
-doc)</P>
-<H2 CLASS="western"><BR><BR>
-</H2>
-<H2 CLASS="western">Node ID Alias Generation</H2>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Deleted: trunk/specs/drafts/TemplateSpec.html
===================================================================
--- trunk/specs/drafts/TemplateSpec.html 2010-10-09 00:55:40 UTC (rev 986)
+++ trunk/specs/drafts/TemplateSpec.html 2010-10-09 00:57:48 UTC (rev 987)
@@ -1,43 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB S&E Template</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;11062900">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-S&E Template
-</H1>
-<H2 CLASS="western">Introduction (Informative)</H2>
-<P>This specification describes ...</P>
-<H2 CLASS="western">References and Context (Normative)</H2>
-<P>This specification is in the context of the OpenLCB-CAN …
-Specification, which specifies …</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 00:59:00
|
Revision: 988
http://openlcb.svn.sourceforge.net/openlcb/?rev=988&view=rev
Author: jacobsen
Date: 2010-10-09 00:58:54 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
fix formatting
Removed Paths:
-------------
trunk/specs/drafts/CanFrameTransferExpl.odt
trunk/specs/drafts/CanFrameTransferExpl.pdf
trunk/specs/drafts/CanFrameTransferSpec.odt
trunk/specs/drafts/CanFrameTransferSpec.pdf
Deleted: trunk/specs/drafts/CanFrameTransferExpl.odt
===================================================================
(Binary files differ)
Deleted: trunk/specs/drafts/CanFrameTransferExpl.pdf
===================================================================
(Binary files differ)
Deleted: trunk/specs/drafts/CanFrameTransferSpec.odt
===================================================================
(Binary files differ)
Deleted: trunk/specs/drafts/CanFrameTransferSpec.pdf
===================================================================
(Binary files differ)
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 01:09:26
|
Revision: 989
http://openlcb.svn.sourceforge.net/openlcb/?rev=989&view=rev
Author: jacobsen
Date: 2010-10-09 01:09:20 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
convert format
Added Paths:
-----------
trunk/specs/drafts/CanEventTransportS.odt
trunk/specs/drafts/CanEventTransportS.pdf
trunk/specs/drafts/CanEventTransportTN.odt
trunk/specs/drafts/CanEventTransportTN.pdf
Copied: trunk/specs/drafts/CanEventTransportS.odt (from rev 986, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/CanEventTransportS.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/CanEventTransportS.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Copied: trunk/specs/drafts/CanEventTransportTN.odt (from rev 986, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/CanEventTransportTN.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/CanEventTransportTN.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 01:10:41
|
Revision: 990
http://openlcb.svn.sourceforge.net/openlcb/?rev=990&view=rev
Author: jacobsen
Date: 2010-10-09 01:10:35 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
convert format
Removed Paths:
-------------
trunk/specs/drafts/CanEventTransportExpl.html
trunk/specs/drafts/CanEventTransportSpec.html
Deleted: trunk/specs/drafts/CanEventTransportExpl.html
===================================================================
--- trunk/specs/drafts/CanEventTransportExpl.html 2010-10-09 01:09:20 UTC (rev 989)
+++ trunk/specs/drafts/CanEventTransportExpl.html 2010-10-09 01:10:35 UTC (rev 990)
@@ -1,61 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB CAN Event Transport Explanation</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;11043100">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- H3.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-CAN Event Transport Explanation
-</H1>
-<H2 CLASS="western">Introduction</H2>
-<P>This explanatory note contains informative discussion and
-background for the corresponding “OpenLCB CAN Event Transport
-Specification”. This explanation is not normative in any way.</P>
-<H2 CLASS="western">Annotations to the Specification</H2>
-<P>This section provides background information on corresponding
-sections of the Specification document. It's expected that two
-documents will be read together.</P>
-<H3 CLASS="western">Introduction</H3>
-<H3 CLASS="western">References and Context</H3>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<P>For monitoring purposes, it was proposed that a PCER message carry
-a sequence number which increments each time the associated P/C Event
-ID is sent. It is not at all clear how to do this across nodes, or
-even across Producers within a single node, as there may be more than
-one thing that can cause the same P/C Event ID to be sent by a single
-board;. We decided this would cause more problems than it solved, and
-omitted it.</P>
-<P><FONT COLOR="#000000"><FONT FACE="Times-Roman, serif"><FONT SIZE=4 STYLE="font-size: 16pt">There's
-not room in a CAN frame for both a destination NID and a EID. The
-protocol has therefore been constructed so that any message carrying
-an EID (and that isn't a datagram) is globally addressed.</FONT></FONT></FONT></P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Deleted: trunk/specs/drafts/CanEventTransportSpec.html
===================================================================
--- trunk/specs/drafts/CanEventTransportSpec.html 2010-10-09 01:09:20 UTC (rev 989)
+++ trunk/specs/drafts/CanEventTransportSpec.html 2010-10-09 01:10:35 UTC (rev 990)
@@ -1,55 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB CAN Event Transport Specification</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;13094500">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-CAN Event Transport Specification
-</H1>
-<H2 CLASS="western">Introduction (Informative)</H2>
-<P>This specification describes the protocol for transporting OpenLCB
-events via CAN segments.</P>
-<H2 CLASS="western">References and Context (Normative)</H2>
-<P>This specification is in the context of the following OpenLCB-CAN
-Specifications:</P>
-<UL>
- <LI><P>The OpenLCB Message Network Specification, which specifies …</P>
- <LI><P>The OpenLCB Node Identifier Specification, which specifies …</P>
- <LI><P>The OpenLCB Event Identifier Specification, which specifies
- ...</P>
-</UL>
-<P>“CAN” refers to the electrical and protocol specifications as
-defined in ISO 11898-1:2003 and ISO 11898-2:2003 and their
-successors.</P>
-<P>External certification of parts shall be accepted for conformance
-to these standards. Conformance with a later version of a standard
-shall be accepted as conformance with the referenced versions.</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 01:23:39
|
Revision: 991
http://openlcb.svn.sourceforge.net/openlcb/?rev=991&view=rev
Author: jacobsen
Date: 2010-10-09 01:23:32 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
reformat
Removed Paths:
-------------
trunk/specs/drafts/CanDatagramTransportExpl.html
trunk/specs/drafts/CanDatagramTransportSpec.html
Deleted: trunk/specs/drafts/CanDatagramTransportExpl.html
===================================================================
--- trunk/specs/drafts/CanDatagramTransportExpl.html 2010-10-09 01:10:35 UTC (rev 990)
+++ trunk/specs/drafts/CanDatagramTransportExpl.html 2010-10-09 01:23:32 UTC (rev 991)
@@ -1,350 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB CAN Datagram Transport Explanation</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;11041300">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- H4.ctl { font-family: "Lucida Sans" }
- H3.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-CAN Datagram Transport Explanation
-</H1>
-<H2 CLASS="western">Introduction</H2>
-<P>This explanatory note contains informative discussion and
-background for the corresponding “OpenLCB Datagram Transport
-Specification”. This explanation is not normative in any way.</P>
-<H2 CLASS="western">Annotations to the Specification</H2>
-<P>This section provides background information on corresponding
-sections of the Specification document. It's expected that two
-documents will be read together.</P>
-<H3 CLASS="western">Introduction</H3>
-<H3 CLASS="western">References and Context</H3>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just the content of the Datagram development doc
-right now.</P>
-<P><BR><BR>
-</P>
-<P>Some wire protocols can support only very short packets/frames,
-e.g. CAN with a limited header and data payload. As OpenLCB evolves,
-it will inevitably need messages larger than that. Streaming provides
-a very large payload, at some cost in setup time and complexity.
-"Datagram Support" is in between "small enough to
-always be atomic" and "large enough to justify streaming
-overhead".
-</P>
-<P>This note is a working draft proposal.</P>
-<H2 CLASS="western">Use Cases</H2>
-<P>Configuration: Simple one-value reads and writes of configuration
-data are one-to-one operations that need to exchange 4-8-16-32 bytes
-of data.
-</P>
-<P>External-network control: If the OpenLCB net is attached to single
-external networks, e.g. a DCC or LocoNet system, one-to-one
-transmission can be used to exchange native commands. E.g. “Send
-the following LocoNet message” may need to be up to 18 bytes long
-with current LocoNet definitions. Communcation to LocoNet/DCC/etc can
-be one-to-one to insure communications; return messages can be many
-one-to-one to listeners, but there's also a need for one-to-many or
-broadcast which is not addressed here.</P>
-<P>RFID tags carry 40 (vs 64, and need to plan for future growth)
-bits of payload. Adding in some status and location information,
-reporting a RFID tag requires a 8-16 byte payload, and that's likely
-to grow in the future.
-</P>
-<H2 CLASS="western">Discussion</H2>
-<P>Datagrams are a one-to-one connection between nodes. They have a
-source address and a single destination address, and only have to be
-delivered to that single destination. Delivery is guaranteed if the
-destination node is active, initialized and reachable, but it's not
-possible to guarantee in advance that a buffer is available in the
-destination to receive and assemble the datagram.</P>
-<P>At the high end, what's the maximum size for a datagram, beyond
-which it makes sense to move to a stream? The stream startup overhead
-is small, so that streams can be used for even small amounts of data.
-The maximum datagram size must be short enough that nodes can afford
-to have a fixed receive-and-process buffer for datagrams allocated,
-unlike streams that can be too large to buffer as a whole. As a
-balance between these, and to optimize certain layouts on CAN links,
-a size of 72 bytes has been selected.</P>
-<P>At the low end, datagrams should go all the way down to zero
-bytes, because they are distinct from Events.
-</P>
-<P>The datagram protocol doesn't need error correction, because
-OpenLCB is based only on reliable links. CAN, TCP/IP, etc, handle
-their own error conditions. The datagram protocol needs flow control
-and synchronization, however, as a small node might not have
-resources to accumulate a large number of datagrams that are arriving
-in an interleaved order. In order for the sending node to know it can
-free its buffer holding the transmitted message, there needs to be an
-“received OK, acknowledged” reply. In this case, “reliable
-transport” just refers to a lack of content and order errors, not
-that messages always end up effective at the remote destination.</P>
-<P>On CAN links, the datagram protocol is constrained by the need the
-limited frame size. Datagrams must be broken into multiple frames for
-transfer. The protocol must allow for the possibility that datagrams
-to a particular node can be interleaved if several nodes are
-transmitting at the same time. Note that a node can control what it
-sends, so it is possible to ensure that only one datagram is being
-sent from a node at one time, just not that only one is being
-received.</P>
-<P>We're relying on CAN not reordering frames, even in the presence
-of error recovery. That's needed in any case for streams, which are
-so large that complete internal buffering cannot be assumed.</P>
-<H2 CLASS="western">Base Protocol Proposal</H2>
-<P>In the base protocol a datagram is just a single short message
-containing the Datagram MTI and the data byte(s). There is a
-convention for a data format indicator at the start of the data
-bytes, see below.</P>
-<P>Once the datagram has been successfully received, the receiving
-node replies to the original source node with a “Datagram
-Acknowledged” message. Note that the node is not required to
-examine or process the datagram before replying; execution errors
-that happen later must be signaled using another protocol.</P>
-<P>Instead of “Datagram Acknowledged”, the receiving node may
-return a “Datagram Rejected” message tagged to represent exactly
-one of several conditions:</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">“Permanent error” - This node
- does not process datagrams, will not accept a datagram from this
- source, or for some other reason will not ever be able to accept
- this datagram. The datagram should not be retransmitted. Optionally,
- the node can mark the reply with one or more of several conditions:</P>
- <UL>
- <LI><P STYLE="margin-bottom: 0cm">“Information Logged” - the
- node supports the logging protocol and information was logged for
- later retrieval.</P>
- <LI><P STYLE="margin-bottom: 0cm">“Invalid Datagram” -
- something made the datagram improper, such as longer than the max
- permitted length. Proper datagrams might be acceptable.</P>
- <LI><P STYLE="margin-bottom: 0cm">“Source not permitted” -
- datagrams from this source will never be accepted</P>
- <LI><P STYLE="margin-bottom: 0cm">“Datagrams not accepted” -
- this node will not accept datagrams under any circumstance. A node
- can also <A HREF="../../documents/tandardInteractions.html">reject
- the interaction</A> instead of sending Datagram Rejected with this
- code.</P>
- </UL>
- <LI><P STYLE="margin-bottom: 0cm">“Buffer shortage, resend” -
- The node wasn't able to receive the datagram because of a shortage
- of buffers. The sending node should resend at its convenience.</P>
- <LI><P STYLE="margin-bottom: 0cm">“Datagram rejected, out of
- order” - Should not happen, but an internal inconsistency was
- found in the CAN frames making up a datagram. Sender can try again
- if desired.</P>
-</UL>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<H2 CLASS="western">CAN protocol proposal</H2>
-<P>The datagram protocol on CAN links uses the same structure as the
-base protocol, except for the need to split the message into frames.</P>
-<P>A node may only send one datagram at a time to any given
-destination node. A node may interleave transmission of datagrams to
-separate nodes, but this is not recommended because the longer
-transmission window increases the probability of buffer collisions in
-recipient nodes.</P>
-<P>The sender breaks the datagram content into one or more frames.
-The source NodeID alias and destination NodeID alias are contained in
-the header as usual. Two format indicators are used to mark non-final
-and final frames. The data part of the CAN frame can carry from zero
-to eight data bytes.</P>
-<P>If there are more than eight bytes to the datagram, the rest are
-send as consecutive frames. Because CAN transmission retains frame
-order between sender and receiver, no order information is added to
-the frames. The last frame is marked by a “datagram complete”
-format indicator.
-</P>
-<P>The receiving node receives the frames into a buffer. The frames
-from more than one datagram may arrive in interleaved order, in which
-case the receiving node can tell them apart using their source NodeID
-alias and store them in separate buffers. If sufficient buffers are
-not available, the receiving node rejects the datagram and it will be
-resent. Once the “datagram complete” indicator is received for a
-datagram, the node replies to the original source node with a
-“Datagram Received OK” or “Datagram Rejected” message.</P>
-<P>An interface or gateway onto a CAN link must do the datagram
-fragmentation and defragmentation locally. Buffer retries may be
-either done locally by the gateway, or by reflecting the response
-back to the original sender.</P>
-<H2 CLASS="western">CAN Examples</H2>
-<H4 CLASS="western">Normal CAN case</H4>
-<P STYLE="margin-bottom: 0cm">Datagram Segment →</P>
-<P STYLE="margin-bottom: 0cm">Datagram Segment →</P>
-<P STYLE="margin-bottom: 0cm">Datagram Segment →</P>
-<P STYLE="margin-bottom: 0cm">Datagram Segment (Complete) →</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">← Datagram Acknowledged</P>
-<H4 CLASS="western">Short CAN datagram case</H4>
-<P STYLE="margin-bottom: 0cm">Datagram Segment (Complete) →</P>
-<P STYLE="margin-bottom: 0cm">← Datagram Acknowledged</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<H4 CLASS="western">Rejected short CAN datagram case</H4>
-<P STYLE="margin-bottom: 0cm">Even a short datagram can be rejected
-with a “Temporarily unable to receive” if there's e.g. a shortage
-of buffers:</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">Datagram Segment (Complete) →</P>
-<P STYLE="margin-bottom: 0cm">← Datagram Rejected, Buffer shortage,
-Resend</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<H4 CLASS="western">Rejected interleaved CAN datagram case:</H4>
-<P STYLE="margin-bottom: 0cm">Accidental interleave, at a node that
-can't handle that:</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">Datagram Segment from A →</P>
-<P STYLE="margin-bottom: 0cm">Datagram Segment from B →</P>
-<P STYLE="margin-bottom: 0cm">← Datagram Rejected, Buffer shortage,
-Resend to B</P>
-<P STYLE="margin-bottom: 0cm">Datagram Segment from A →</P>
-<P STYLE="margin-bottom: 0cm">Datagram Segment (Complete) from A-></P>
-<P STYLE="margin-bottom: 0cm">← Datagram Acknowledged to A</P>
-<P STYLE="margin-bottom: 0cm">Datagram Segment from B →</P>
-<P STYLE="margin-bottom: 0cm">Datagram Segment (Complete) from B-></P>
-<P STYLE="margin-bottom: 0cm">← Datagram Acknowledged to B</P>
-<H2 CLASS="western">Datagram Content</H2>
-<P>There needs to be a method for identifying the content of a
-general datagram. OpenLCB is meant to be used with both very simple,
-low-end nodes, and high-end computers with multiple programs. In both
-those environments, it's inconvenient to have constraints like “the
-next datagram will carry ….” because there might be more than one
-thing going on, and it's hard to write code that knows about lots of
-global state information. It must be possible to interleave e.g.
-configuration datagrams (messages) with datagrams that are displaying
-messages. Therefore, most datagrams must carry information about
-which conversation they are part of. We call that “datagram content
-identification”.</P>
-<P>We also want those “datagram content IDs” to be small, unique,
-unambiguous, easily assigned, etc. To do that, there are two basic
-approaches:</P>
-<UL>
- <LI><P>Have a small (one-byte) ID field, and have some central
- sequential method of assignment. This is small, so doesn't use much
- space on CAN, but requires central recording of IDs.</P>
- <LI><P>Use a 6 byte field assigned the same way that node unique
- identifiers are. The protocol designer(s) uses a unique ID they
- control to identify the new protocol they are defining. This takes
- significantly more space, particularly on CAN, but is simple to
- maintain and requires no central registration.</P>
-</UL>
-<P>The plan is to use both. There will be a one-byte field which can
-be combined with flags on CAN, with certain values to escape to a
-two-byte field (reserved for future use), and to a six-byte
-fully-unique field. A separate spreadsheet is accumulating values.
-(<A HREF="../../documents/DatagramProtocols.ods">spreadsheet</A>)
-(<A HREF="../../documents/DatagramProtocols.pdf">pdf</A>)</P>
-<H3 CLASS="western">Numerology</H3>
-<P>This section discusses how big the maximum datagram payload can
-be. This is a decision that must balance buffer size versus utility
-of the protocol. Memory is scarce in a small node. Although it's
-possible to incrementally process parts of a datagram as they arrive,
-in general it will be necessary to have a buffer of the maximum
-possible size available when a datagram is arriving. (That same
-buffer can be used to send datagrams, if needed) At the same time,
-datagrams that are too small to contain a useful atomic message cause
-a lot of extra coding work.</P>
-<P>If one byte is used for the datagram format field, the first
-CAN-link datagram contains 7 payload bytes (the following datagrams
-can contain 8). The datagram format field counts as part of the
-information that the datagram is transporting, though. We could make
-the maximum datagram size nine segments, (9*8) = 72-1 data bytes, to
-ensure that even with a little bit of higher protocol, say up to 6
-bytes, 64 bytes of actual data can be delivered at a shot.</P>
-<P>Alternately, because of the binary nature of addressing, a 64-byte
-buffer size might be more convenient that a 72-byte one, even at the
-cost of some lost possible capacity in the last frame.
-</P>
-<P>For external protocols, e.g. support for LocoNet, XpressNet, DCC,
-etc, it's a great simplification if the datagrams can carry <U>any</U>
-basic message of the external protocol in a single datagram. Is 64
-data bytes then enough? NMRA DCC is up to 5 bytes, including
-addressing, so it's clearly OK even in a 1<SUP>st</SUP> CAN frame.
-Others?</P>
-<P>Our notional decision is nine segments, 72 bytes, but developers
-should code this as a constant to the extent possible.</P>
-<H2 CLASS="western">Extensions</H2>
-<P>In this version of the datagram protocol, there is no provision
-for multiple recipients of a single message. Transmission is strictly
-one-to-one. This isn't because of addressing (making them globally
-visible isn't hard), but rather the need for guaranteed buffering at
-the receiving node. In the future, we may want to provide one-to-many
-datagrams.
-</P>
-<P>The recipient needs to have a buffer into which any datagram in
-flight can be received. On a tiny node, those might be a scarce
-resource. But, without any protocol support, e.g. if datagrams were
-"fire and forget" like event notifications, you might need
-to have a very large number of those buffers. There's nothing in the
-protocol that prevents nodes A, B, C <U>and</U> D from firing off a
-datagram at node X at the same time, and having their CAN frames be
-interleaved when they arrive at X.(The stream protocol negotiates
-this in advance, but that requires time and resources only
-appropriate to large transfers) To properly receive them, X needs N=4
-buffers to reassemble them in this case. But how big an N is really
-required? It's not possible to know, so instead we add protocol
-support: X can tell nodes sending it datagrams to repeat them. That
-way X can accept as many datagrams as it has buffers (at least one),
-while telling the others to "say that again, please, I wasn't
-paying attention the first time".
-</P>
-<P>A sending node knows that it has to hang onto the datagram until
-it gets a "acknowledged" message, because if it gets a "say
-that again" it needs to still have the content to resend it. The
-"acknowledged" and "say that again" are not about
-data loss on a link, but about buffer management in tiny nodes. A
-one-to-many protocol could also do something like that, because the
-transmitter still knows how many "many" is. Global
-broadcast, like events, is hard because the <U>transmitter's</U>
-buffer management gets complicated unless it knows how many nodes are
-listening for it's reply.
-</P>
-<H2 CLASS="western">Implementation Notes</H2>
-<P>A resource-constrained node can get along with a single datagram
-buffer for both sending and receiving, but this may require that the
-node be able to abandon and recreate a datagram that it is trying to
-transmit. This can happen when e.g.</P>
-<UL>
- <LI><P>Node A creates a datagram for node B in its buffer and starts
- to send it.</P>
- <LI><P>Before starting to receive the datagram from A, node B
- creates a datagram for Node A in its buffer and starts to send it.</P>
-</UL>
-<P>Both datagrams now need a place to put the incoming datagram, but
-only have one buffer in this example. They can both send “Datagram
-rejected; buffer shortage”, but then their peer will just repeat
-the attempt to send. At least one has to drop the content from its
-datagram buffer and receive the datagram to avoid deadly embrace.
-This can also happen in other contexts too, but only when sharing a
-buffer between transmit and reception. It's therefore easiest for an
-implementation to provide for two buffers if it's likely to send and
-receive datagrams asynchronously.</P>
-<P>The datagram protocol allows all nodes to reject a datagram when
-it's been totally received. CAN and other wire protocols also allow
-an early rejection to help keep buffers clear. It's not required that
-CAN implementations use that, though.</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Deleted: trunk/specs/drafts/CanDatagramTransportSpec.html
===================================================================
--- trunk/specs/drafts/CanDatagramTransportSpec.html 2010-10-09 01:10:35 UTC (rev 990)
+++ trunk/specs/drafts/CanDatagramTransportSpec.html 2010-10-09 01:23:32 UTC (rev 991)
@@ -1,55 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB CAN Datagram Transport Specification</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;13093000">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-CAN Datagram Transport Specification
-</H1>
-<H2 CLASS="western">Introduction (Informative)</H2>
-<P>This specification describes the protocol for transporting OpenLCB
-datagrams via CAN segments.</P>
-<H2 CLASS="western">References and Context (Normative)</H2>
-<P>This specification is in the context of the following OpenLCB-CAN
-Specifications:</P>
-<UL>
- <LI><P>The OpenLCB Message Network Specification, which specifies …</P>
- <LI><P>The OpenLCB Node Identifier Specification, which specifies …</P>
- <LI><P>The OpenLCB Event Identifier Specification, which specifies
- ...</P>
-</UL>
-<P>“CAN” refers to the electrical and protocol specifications as
-defined in ISO 11898-1:2003 and ISO 11898-2:2003 and their
-successors.</P>
-<P>External certification of parts shall be accepted for conformance
-to these standards. Conformance with a later version of a standard
-shall be accepted as conformance with the referenced versions.</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 01:24:06
|
Revision: 992
http://openlcb.svn.sourceforge.net/openlcb/?rev=992&view=rev
Author: jacobsen
Date: 2010-10-09 01:24:00 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
reformat
Added Paths:
-----------
trunk/specs/drafts/CanDatagramTransportS.odt
trunk/specs/drafts/CanDatagramTransportS.pdf
trunk/specs/drafts/CanDatagramTransportTN.odt
trunk/specs/drafts/CanDatagramTransportTN.pdf
Copied: trunk/specs/drafts/CanDatagramTransportS.odt (from rev 986, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/CanDatagramTransportS.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/CanDatagramTransportS.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Copied: trunk/specs/drafts/CanDatagramTransportTN.odt (from rev 986, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/CanDatagramTransportTN.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/CanDatagramTransportTN.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 01:26:33
|
Revision: 993
http://openlcb.svn.sourceforge.net/openlcb/?rev=993&view=rev
Author: jacobsen
Date: 2010-10-09 01:26:27 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
reformat
Added Paths:
-----------
trunk/specs/drafts/CanFrameTransferS.odt
trunk/specs/drafts/CanFrameTransferS.pdf
trunk/specs/drafts/CanFrameTransferTN.odt
trunk/specs/drafts/CanFrameTransferTN.pdf
Copied: trunk/specs/drafts/CanFrameTransferS.odt (from rev 984, trunk/specs/drafts/CanFrameTransferSpec.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/CanFrameTransferS.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/CanFrameTransferS.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Copied: trunk/specs/drafts/CanFrameTransferTN.odt (from rev 984, trunk/specs/drafts/CanFrameTransferExpl.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/CanFrameTransferTN.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/CanFrameTransferTN.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 01:39:11
|
Revision: 994
http://openlcb.svn.sourceforge.net/openlcb/?rev=994&view=rev
Author: jacobsen
Date: 2010-10-09 01:39:05 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
reformat
Added Paths:
-----------
trunk/specs/drafts/CanMessageNetworkS.odt
trunk/specs/drafts/CanMessageNetworkS.pdf
trunk/specs/drafts/CanMessageNetworkTN.odt
trunk/specs/drafts/CanMessageNetworkTN.pdf
Copied: trunk/specs/drafts/CanMessageNetworkS.odt (from rev 986, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/CanMessageNetworkS.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/CanMessageNetworkS.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Copied: trunk/specs/drafts/CanMessageNetworkTN.odt (from rev 986, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/CanMessageNetworkTN.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/CanMessageNetworkTN.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 05:01:27
|
Revision: 996
http://openlcb.svn.sourceforge.net/openlcb/?rev=996&view=rev
Author: jacobsen
Date: 2010-10-09 05:01:20 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
reformat
Added Paths:
-----------
trunk/specs/drafts/GenEventIdS.odt
trunk/specs/drafts/GenEventIdS.pdf
trunk/specs/drafts/GenEventIdTN.odt
trunk/specs/drafts/GenEventIdTN.pdf
Removed Paths:
-------------
trunk/specs/drafts/GenEventIdExpl.html
trunk/specs/drafts/GenEventIdSpec.html
Deleted: trunk/specs/drafts/GenEventIdExpl.html
===================================================================
--- trunk/specs/drafts/GenEventIdExpl.html 2010-10-09 01:52:49 UTC (rev 995)
+++ trunk/specs/drafts/GenEventIdExpl.html 2010-10-09 05:01:20 UTC (rev 996)
@@ -1,53 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB Event ID Explanation</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;13232500">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H3.ctl { font-family: "Lucida Sans" }
- H2.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-Event ID Explanation
-</H1>
-<H2 CLASS="western">Introduction</H2>
-<P>This explanatory note contains informative discussion and
-background for the corresponding “OpenLCB Event ID Specification”.
-This explanation is not normative in any way.</P>
-<H2 CLASS="western">Annotations to the Specification</H2>
-<P>This section provides background information on corresponding
-sections of the Specification document. It's expected that two
-documents will be read together.</P>
-<H3 CLASS="western">Introduction</H3>
-<H3 CLASS="western">References and Context</H3>
-<H3 CLASS="western">Format</H3>
-<P>The specification doesn't require any particular human-readable
-format, but hex-pairs with separators are strongly suggested, e.g.
-01.AB.34.01.CD.E3.20.0E; decimal pairs could also be used, but in
-that case it's important to provide a way to know which is use.</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Copied: trunk/specs/drafts/GenEventIdS.odt (from rev 986, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/GenEventIdS.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/GenEventIdS.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Deleted: trunk/specs/drafts/GenEventIdSpec.html
===================================================================
--- trunk/specs/drafts/GenEventIdSpec.html 2010-10-09 01:52:49 UTC (rev 995)
+++ trunk/specs/drafts/GenEventIdSpec.html 2010-10-09 05:01:20 UTC (rev 996)
@@ -1,59 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB Event ID Specification</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;13201000">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- H3.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-Event ID Specification
-</H1>
-<H2 CLASS="western">Introduction (Informative)</H2>
-<P>This specification describes the format and allocation of OpenLCB
-event identifiers (event IDs). It is not specific to any wire
-protocol.</P>
-<H2 CLASS="western">References and Context (Normative)</H2>
-<P>This specification is in the context of the OpenLCB-CAN …
-Specification, which specifies …</P>
-<H3 CLASS="western">Format</H3>
-<P>An OpenLCB event identifier (node ID) shall be eight bytes of
-eight bits each.
-</P>
-<P>The order of bytes in an OpenLCB event ID shall be considered
-significant. The most-significant byte shall be transmitted first
-during communication operations. The most-significant byte shall be
-written first (left-most in Western format) in any human-readable
-representation.</P>
-<P>OpenLCB event IDs shall include one or more 1 bits.
-</P>
-<H3 CLASS="western">Allocation</H3>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Copied: trunk/specs/drafts/GenEventIdTN.odt (from rev 986, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/GenEventIdTN.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/GenEventIdTN.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 05:03:13
|
Revision: 997
http://openlcb.svn.sourceforge.net/openlcb/?rev=997&view=rev
Author: jacobsen
Date: 2010-10-09 05:03:06 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
now in odt format
Removed Paths:
-------------
trunk/specs/drafts/CanMessageNetworkExpl.html
trunk/specs/drafts/CanMessageNetworkSpec.html
Deleted: trunk/specs/drafts/CanMessageNetworkExpl.html
===================================================================
--- trunk/specs/drafts/CanMessageNetworkExpl.html 2010-10-09 05:01:20 UTC (rev 996)
+++ trunk/specs/drafts/CanMessageNetworkExpl.html 2010-10-09 05:03:06 UTC (rev 997)
@@ -1,453 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB CAN Message Network Explanation</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20101004;9363200">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- H3.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-CAN Message Network Explanation</H1>
-<H2 CLASS="western">Introduction</H2>
-<P>This explanatory note contains informative discussion and
-background for the corresponding “OpenLCB CAN Message Network
-Specification”. This explanation is not normative in any way.</P>
-<H2 CLASS="western">Annotations to the Specification</H2>
-<P>This section provides background information on corresponding
-sections of the Specification document. It's expected that two
-documents will be read together.</P>
-<H3 CLASS="western">Introduction</H3>
-<H3 CLASS="western">References and Context</H3>
-<HR>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P>The priority bit in the CAN frame is separate from the static
-priority field in the MTI format specification.</P>
-<P><BR><BR>
-</P>
-<P STYLE="margin-bottom: 0cm"><SPAN STYLE="font-style: normal">The
-specific MTI values are being allocated in a <A HREF="../documents/MtiAllocations.ods">separate
-worksheet</A> (<A HREF="../documents/MtiAllocations.pdf">PDF
-version</A>). In general, the MTI selection is done on the top 8 bits
-of the variable field. This is mapped to the low MTI byte in a
-standard format message.</SPAN></P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P><SPAN STYLE="font-style: normal">Some MTIs have additional status
-bits defined as part of the 2</SPAN><SUP><SPAN STYLE="font-style: normal">nd</SPAN></SUP>
-<SPAN STYLE="font-style: normal">field. For example, there are two
-status bits associated with “Consumer Identified” which must be
-kept in the header since there is no room in the CAN data field. To
-simplify translation between formats, these are the low bits of the
-first byte after the MTI in a standard-form message.</SPAN></P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Designers may wish to use CAN
- hardware filtering, but it can't be assumed to be present. We assign
- a single bit to indicate “simple node protocol” messages to make
- simple filtering possible.</P>
-</UL>
-<H3 CLASS="western">Left over from Frame doc</H3>
-<P>OpenLCB common messages are converted, to the extent possible, to
-single CAN frames via a one-to-one mapping.
-</P>
-<P>The translations include:
-</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">MTIs may have to be shortened,
- depending on bit allocations.
- </P>
-</UL>
-<P>Design decisions:</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">A specific mapping from the common
- 16-bit MTI format to a shorter CAN format is documented in a
- <A HREF="../documents/MtiAllocations.ods">separate worksheet</A>
- (<A HREF="../documents/MtiAllocations.pdf">PDF version</A>). The
- common form is 16 bits to have lots of space to grow at the high
- end, but it can be mapped into a 8 bit field for efficient CAN
- transfer.
- </P>
-</UL>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<H2 CLASS="western"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="David Harris"><!-- $Id$ -->OpenLCB
-Common Message Format</H2>
-<P>A common message consists of several parts:
-</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Node ID Number of the Source node
- (SID)
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Message Type Indicator (MTI)
- </P>
- <LI><P STYLE="margin-bottom: 0cm">In some cases, the Destination
- Node ID (DID)
- </P>
- <LI><P STYLE="margin-bottom: 0cm">In some cases, a P/C Event ID
- (EID)
- </P>
- <LI><P>Message content, as defined by the particular message type
- </P>
-</UL>
-<P>Each OpenLCB wire protocol may define local representations for
-each of these components at the transport level and below. This may
-involve replacement (e.g. using a shorter "Alias" token for
-the node ID number), reordering, and/or specific representations that
-differ from the common ones, but in all cases it must be possible to
-translate from the wire protocol message to a complete common message
-using only locally available information.
-</P>
-<P>By convention, multi-byte quantities in OpenLCB are represented in
-big-endian order. The most significant byte is sent first, and stored
-at the lowest address. This is the same as Ethernet and the common
-internet protocols, but not the same as the Intel x86 architecture.
-</P>
-<P>Reserved quantities must be created with a zero value unless
-otherwise specified. When processing a message, any reserved
-quantities must be ignored unless otherwise specified. When
-transporting a message, reserved quantities must be transported
-unchanged. The zero value sometimes indicates a non-initialized
-value.
-</P>
-<H2 CLASS="western">Node ID Numbers - NID</H2>
-<P>A node ID number is 48 bits. The NMRA will allocate number ranges
-to individuals or organizations upon request, and maintain a public
-list of assignments. A detailed mechanism for kinds of delegation has
-been <A HREF="../documents/NidUniqueAssignment.html">separately
-proposed</A>.
-</P>
-<H2 CLASS="western">Message Type Indicator (MTI)</H2>
-<P>The common Message Type Indicator (MTI) is a 16 bit quantity.
-</P>
-<P>Each specific MTI has a specific defined content <A HREF="../documents/CommonMessageDefinitions.html">documented
-elsewhere</A>, but there are a few general points.
-</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Messages are variable length. The
- specific wire protocol is responsible for carrying length
- information as needed.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">If the message carries a
- destination address, that destination node ID (destination address)
- is the first part of the message content. The form of a Destination
- Node ID is defined by the particular wire protocol, but must be
- mappable to the full Node ID of the intended destination.
- </P>
-</UL>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P>The common Message Type Indicator (MTI) is a 16 bit quantity. Note
-that specific wire protocols may remap this.</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">The most-significant 5 bits are
- reserved as 00110; nodes must send and check that value.</P>
- <LI><P STYLE="margin-bottom: 0cm">The next 7 bits are used to
- indicate the message type.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">The top two of these are used to
- form static priority groups. A 0 bit is considered to have more
- priority (can be processed first), a 1 bit less priority (can be
- processed later). The MSB makes a larger statement about priority
- than the LSB of these two. Priority processing is permitted but not
- required. The priority group bits are part of the overall message
- type.</P>
- <LI><P STYLE="margin-bottom: 0cm">The next bit is reserved as 0;
- nodes must send and check that value.</P>
- <LI><P STYLE="margin-bottom: 0cm">The lower four bits indicate a
- specific type.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">The following bit is reserved as
- 0; nodes much send and check that value.</P>
- <LI><P STYLE="margin-bottom: 0cm">The 2<SUP>nd</SUP>
- from-least-significant bit indicates that this message carries a
- destination node address (DID) when set to 1. Setting 0 means that
- the message is globally addressed. If a Destination Node ID (DID) is
- present, it is located at the start of the message content. The form
- of a Destination Node ID is defined by the particular wire protocol,
- but must be mappable to the full NID of the intended destination.
- </P>
- <LI><P>The next-to-least-significant bit indicates this message
- carries a P/C Event ID field when set to 1. Setting 0 means that the
- message does not carry a P/C event ID. If a P/C Event ID is present,
- it's at the start of the message, except after the Destination Node
- ID, if present.
- </P>
- <LI><P>The least-significant bit when set to 1 indicates this
- message carries a flag byte after the DID and/or EID determined by
- the above bits. The low bits of that byte can be relocated in CAN
- messages, see the definition of the CAN wire protocol.</P>
-</UL>
-<P>We've chosen to allocate bit fields to make decoding simpler; if
-possible, aligned on nibble boundaries to make it easy to read as
-hexadecimal numbers. Note that, as a special dispensation for CAN,
-higher priority messages (MTIs with lower numerical values) may pass
-lower priority ones; this must be taken into account when designing
-protocols.</P>
-<P STYLE="margin-bottom: 0cm">Specific values are allocated and
-documented in a <A HREF="../documents/MtiAllocations.ods">separate
-worksheet</A> (<A HREF="../documents/MtiAllocations.pdf">PDF
-version</A>). We keep them in just that one place to avoid
-conflicting updates.</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<H1 STYLE="page-break-before: always"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="David Harris"><!-- $Id$ -->OpenLCB
-Common Message Types</H1>
-<P STYLE="margin-bottom: 0cm"><I>(Removed the datagram, stream, event
-message sections)</I></P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">The content listed here is in addition
-to the originating NID, MTI and Destination Node ID, if any. The full
-format is specified in a <A HREF="../documents/CommonMessageFormat.html">separate
-note</A>.</P>
-<P STYLE="margin-bottom: 0cm">Some messages may be either addressed
-to a specific node, or globally addressed to all nodes. These are
-indicated by separate MTI values (see below).</P>
-<H2 CLASS="western">Base Messages</H2>
-<H3 CLASS="western"><A NAME="ic"></A>Initialization Complete</H3>
-<P STYLE="margin-bottom: 0cm; font-style: normal">Indicates that the
-node is complete, and once the message is delivered, reachable on the
-network.</P>
-<P STYLE="margin-bottom: 0cm">Content:</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">NID of the sending node</P>
-</UL>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">Only Global (unaddressed) form
-available.</P>
-<H3 CLASS="western"><A NAME="vynid"></A>Verify Node ID</H3>
-<P STYLE="margin-bottom: 0cm">Content: None
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">Global (unaddressed) or with specified
-destination address.</P>
-<H3 CLASS="western"><A NAME="vrnid"></A>Verified Node ID</H3>
-<P STYLE="margin-bottom: 0cm">Content:</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">NID of the sending node – this
- is sent in full 48 bit format in all wire protocols, even if an
- alternate form or alias is available elsewhere in the message</P>
-</UL>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">Only Global (unaddressed) form
-available.</P>
-<H3 CLASS="western"><A NAME="psi"></A>Protocol Support Inquiry</H3>
-<P STYLE="margin-bottom: 0cm">Content: None</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">Destination address required.</P>
-<H3 CLASS="western"><A NAME="psr"></A>Protocol Support Reply</H3>
-<P STYLE="margin-bottom: 0cm">Content: Bytes containing bits
-identifying the available OpenLCB protocols; see definitions in
-separate (<A HREF="../documents/ProtocolBitAllocations.ods">spreadsheet</A>)
-(<A HREF="../documents/ProtocolBitAllocations.pdf">pdf</A>).</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">Destination address required.</P>
-<H3 CLASS="western"><A NAME="oir"></A>Optional Interaction Rejected</H3>
-<P STYLE="margin-bottom: 0cm">Content:</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Mandatory original MTI
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Optional error code (TBD)
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Optional data content (TBD)</P>
-</UL>
-<P STYLE="margin-bottom: 0cm">Destination address required.</P>
-<H3 CLASS="western"><A NAME="tde"></A>Terminate Due to Error</H3>
-<P STYLE="margin-bottom: 0cm">Content:</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Mandatory most recent MTI
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Mandatory error code (TBD)
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Optional data content (TBD)</P>
-</UL>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">Destination address required.</P>
-<H2 CLASS="western"><BR><BR>
-</H2>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<H1 STYLE="page-break-before: always"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="Bob Jacobsen"><META NAME="CHANGEDBY" CONTENT="David Harris"><!-- $Id$ -->Standard
-Interactions</H1>
-<P STYLE="margin-bottom: 0cm">All nodes must be able to take part in
-all standard interactions.</P>
-<H2 CLASS="western">A) Node Initialization</H2>
-<P STYLE="margin-bottom: 0cm">Newly functional nodes, once their
-start-up is complete and they are fully operational, must send an
-"Initialization Complete" message.
-</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">There is no guarantee that any
- other node is listening for this. No reply is possible.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">Nodes must not emit any other
- OpenLCB message before the “Initialization Complete” message.</P>
-</UL>
-<P STYLE="margin-bottom: 0cm">Sending the IC message is required to
-insure that higher-level tools are notified that they may start to
-work with the node.
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm">After the IC message is sent, and
-before any corresponding Producer/Consumer Event Report messages are
-sent, the node must identify all events produced or consumed on the
-board via zero or more Identify Consumers, Identify Consumed Range,
-Identify Producers and Identify Consumed Range messages. These are
-not required to be in any particular order.
-</P>
-<H2 CLASS="western"><A NAME="discovery"></A>B) Duplicate Node ID
-Detection</H2>
-<P>OpenLCB nodes must have unique node IDs. To detect this across the
-entire connected OpenLCB, all OpenLCB nodes must indicate an error if
-they detect an incoming message with a Source Node ID equal to their
-own. If possible, they should indicate it at the board itself using a
-light or similar. If possible, they should emit a PCER message with
-the “Duplicate Source ID detected” global event, which will carry
-the duplicate event ID in the Source Node ID field.
-</P>
-<P>After sending the “Duplicate Source ID detected” global event,
-the node should not transmit any further messages until reset because
-this message will be received at the other duplicate-ID node(s),
-resulting in additional “Duplicate Source ID detected” global
-events and causing a possible message loop.</P>
-<P>To further improve the reliability of this detection, OpenLCB
-nodes should, but need not, emit a Verified Node ID message every 30
-to 90 seconds. As an implementation detail, it's recommended that
-CAN-attached nodes use their NIDa to pick that interval so that
-messages don't bunch up.</P>
-<H2 CLASS="western">C) Node ID Discovery</H2>
-<P STYLE="margin-bottom: 0cm">Upon receipt of a Verify Node ID Number
-message addressed to it, or an unaddressed Verify Node ID Number
-message, a node will reply with an unaddressed Verified Node ID
-Number.
-</P>
-<P STYLE="margin-bottom: 0cm">This can be used as check that a
-specific node is still reachable. When wire protocols compress the
-originating and/or destination NID, this can be used to obtain the
-full NID.
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm"><I>The standard Verify Node ID Number
-interaction can be used to get the full 48-bit NID from a node for
-translation. At power up each node must obtain a alias that is
-locally unique. Gateways will also have to obtain unique aliases for
-remote nodes they are proxying on to the segment. </I>
-</P>
-<H2 CLASS="western">D) Protocol Discovery</H2>
-<P>OpenLCB defines a number of specific protocols for interacting
-with nodes, including event exchange, datagrams, streams,
-configuration, etc. These protocols are optional, in the sense that
-not every node will implement every one.
-</P>
-<P>To determine which protocols a node implements, a Protocol Support
-Inquiry message is sent to the specific node. It will reply with a
-Protocol Support Reply message that contains one or more bytes of
-data. A specific bit position has been reserved for each defined
-protocol in a separate spreadsheet (<A HREF="../documents/ProtocolBitAllocations.ods">.ods</A>,
-<A HREF="../documents/ProtocolBitAllocations.pdf">.pdf</A> form). If
-the bit is zero or not present, the protocol is not supported and
-requests to use it will result in a error. If present and 1, the
-protocol is supported.</P>
-<P>It is not necessary to check whether a protocol is supported by a
-node before attempting to use the protocol. If it's not, the error
-handling mechanism (see below) will indicate that.</P>
-<H2 CLASS="western">E) Error Handling</H2>
-<P STYLE="margin-bottom: 0cm">There are multiple mandatory
-error-handling scenarios defined.</P>
-<H3 CLASS="western">Reject Addressed Optional Interaction</H3>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Node A receives an addressed
- message from Node B that carries Node A's NID.
- </P>
-</UL>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">The MTI indicates the start of an
- optional interaction.
- </P>
-</UL>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">If Node A does not want to take
- part in the optional interaction, it may send an Optional
- Interaction Rejected message addressed to Node B with the original
- MTI in the message content. There is no requirement that OIR be
- sent; the node may silently ignore the incoming message.</P>
-</UL>
-<P STYLE="margin-bottom: 0cm">The message content also contains an
-optional reason code and an optional data value. The use of these
-fields is to be defined.
-</P>
-<H3 CLASS="western">Reject Unaddressed Optional Interaction</H3>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Node A receives an unaddressed
- message from Node B.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">The MTI indicates the start of an
- optional interaction.
- </P>
-</UL>
-<P STYLE="margin-bottom: 0cm">If Node A does not want to take part in
-the optional interaction, it silently drops the message without
-reply.
-</P>
-<H3 CLASS="western">Reject Addressed Standard Interaction Due to
-Error</H3>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Node A is taking part in an
- addressed interaction with Node B. Either node may be able to send
- the next message.</P>
- <LI><P STYLE="margin-bottom: 0cm">Some error condition prevents Node
- A from continuing the interaction.
- </P>
- <LI><P STYLE="margin-bottom: 0cm">To terminate the interaction, Node
- A sends a Terminate Due to Error message to Node B. It then resets
- it's state so as to no longer be taking part in the addressed
- interaction.</P>
-</UL>
-<P STYLE="margin-bottom: 0cm">The message content contains the most
-recent MTI received in this interaction, a mandatory reason code and
-an optional data value. The use of these fields is to be defined.
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Deleted: trunk/specs/drafts/CanMessageNetworkSpec.html
===================================================================
--- trunk/specs/drafts/CanMessageNetworkSpec.html 2010-10-09 05:01:20 UTC (rev 996)
+++ trunk/specs/drafts/CanMessageNetworkSpec.html 2010-10-09 05:03:06 UTC (rev 997)
@@ -1,199 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB CAN Message Network Specification</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20101003;2384900">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-CAN Message Network Specification</H1>
-<H2 CLASS="western">Introduction (Informative)</H2>
-<P>OpenLCB is based on a global exchange of individual messages. This
-specification describes how messages and/or parts of messages are
-transported across CAN segments as CAN frames.</P>
-<H2 CLASS="western">References and Context (Normative)</H2>
-<P>This specification is in the context of the following OpenLCB-CAN
-Specifications:</P>
-<UL>
- <LI><P>The OpenLCB Frame Transfer Specification, which specifies …</P>
- <LI><P>The OpenLCB Node Identifier Specification, which specifies …</P>
-</UL>
-<P>“CAN” refers to the electrical and protocol specifications as
-defined in ISO 11898-1:2003 and ISO 11898-2:2003 and their
-successors.</P>
-<P>External certification of parts shall be accepted for conformance
-to these standards. Conformance with a later version of a standard
-shall be accepted as conformance with the referenced versions.</P>
-<P><BR><BR>
-</P>
-<H2 CLASS="western">Common Section?</H2>
-<P STYLE="margin-bottom: 0cm">Are some conventions included by
-reference, e.g. that all of OpenLCB is big-endian unless otherwise
-specified?</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P><BR><BR>
-</P>
-<H2 CLASS="western">OpenLCB message format</H2>
-<P>(rationalize with the frame doc, that describes the 1<SUP>st</SUP>
-bit)</P>
-<P>OpenLCB common messages are carried in frames with a 1 in the
-Frame Type field. They contain message type information and/or
-address information in the 15-bit variable field, and zero to eight
-CAN data bytes.</P>
-<P STYLE="font-style: normal">For OpenLCB messages, the variable
-field is used in three forms:</P>
-<UL>
- <LI><P STYLE="font-style: normal">Unaddressed messages – messages
- that don't have a destination address put the low 12 bits of the MTI
- in the variable field</P>
- <LI><P STYLE="font-style: normal">Addressed messages – messages
- that have a specific destination address put it in the variable
- field, and carry the MTI in the payload. This allows filtering.</P>
- <LI><P STYLE="font-style: normal">Stream addressed messages – as a
- special case to improve efficiency of transfer, the streaming
- protocol uses 12 bits of the variable field to identify a particular
- stream transfer. This is not the same as a destination NodeID alias,
- but performs a similar function to allow filtering while also
- allowing multiple streams from a source.</P>
-</UL>
-<P STYLE="margin-bottom: 0cm">The variable field is allocated:</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=4>
- <COL WIDTH=96*>
- <COL WIDTH=160*>
- <TR VALIGN=TOP>
- <TH WIDTH=37%>
- <P>Variable Field Bits 0-2</P>
- <P>Header Bits 2-4</P>
- <P>OpenLCB Format</P>
- <P>0x0700,0000</P>
- </TH>
- <TH WIDTH=63%>
- <P>Variable Field Bits 3-14</P>
- <P>Header Bits 5-16</P>
- <P>OpenLCB Variable Header Content</P>
- <P>0x00FF,F000</P>
- </TH>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 0 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>MTI & additional information for “simple
- node” unaddressed messages</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 0 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>MTI & additional information for unaddressed
- messages other than “simple node” forms</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 1 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>(Reserved, must not be sent or accepted)</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>0 1 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>(Reserved for long-form MTIs in data area, <BR>must
- not be sent or accepted)</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 0 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for datagram message non-last
- fragment</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 0 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for datagram message last
- fragment</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 1 0</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for non-datagram addressed
- messages</P>
- </TD>
- </TR>
- <TR VALIGN=TOP>
- <TD WIDTH=37%>
- <P ALIGN=CENTER>1 1 1</P>
- </TD>
- <TD WIDTH=63%>
- <P ALIGN=CENTER>Destination Alias for Stream Data Send messages</P>
- </TD>
- </TR>
-</TABLE>
-<P>Putting the destination alias in the header allows filtering on it
-with common CAN hardware. Putting the Stream ID in the header also
-allows filtering, and preserves the full 8-byte CAN payload for
-stream data.</P>
-<P><SPAN STYLE="font-style: normal">The specific MTI values are being
-allocated in a <A HREF="../documents/MtiAllocations.ods">separate
-worksheet</A> (<A HREF="../documents/MtiAllocations.pdf">PDF
-version</A>). In general, the MTI selection is done on the top 8 bits
-of the variable field. This is mapped to the low MTI byte in a
-standard format message.</SPAN></P>
-<P STYLE="font-style: normal">Some MTIs have additional status bits
-defined as part of the 2<SUP>nd</SUP> field. For example, there are
-two status bits associated with “Consumer Identified” which must
-be kept in the header since there is no room in the CAN data field.
-To simplify translation between formats, these are the low bits of
-the first byte after the MTI in a standard-form message.</P>
-<P STYLE="margin-bottom: 0cm; font-style: normal">Note that messages
-with Destinations IDs may occur in two forms: with an alias in the
-header and the MTI in the message; and with a full address in the
-data field and the MTI in the header.</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<P STYLE="margin-bottom: 0cm"><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 05:09:37
|
Revision: 998
http://openlcb.svn.sourceforge.net/openlcb/?rev=998&view=rev
Author: jacobsen
Date: 2010-10-09 05:09:31 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
reformat
Added Paths:
-----------
trunk/specs/drafts/GenNodeIdS.odt
trunk/specs/drafts/GenNodeIdS.pdf
trunk/specs/drafts/GenNodeIdTN.odt
trunk/specs/drafts/GenNodeIdTN.pdf
Removed Paths:
-------------
trunk/specs/drafts/GenNodeIdExpl.html
trunk/specs/drafts/GenNodeIdSpec.html
Deleted: trunk/specs/drafts/GenNodeIdExpl.html
===================================================================
--- trunk/specs/drafts/GenNodeIdExpl.html 2010-10-09 05:03:06 UTC (rev 997)
+++ trunk/specs/drafts/GenNodeIdExpl.html 2010-10-09 05:09:31 UTC (rev 998)
@@ -1,51 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB Node ID Explanation</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;13225300">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H3.ctl { font-family: "Lucida Sans" }
- H2.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-Node ID Explanation
-</H1>
-<H2 CLASS="western">Introduction</H2>
-<P>This explanatory note contains informative discussion and
-background for the corresponding “OpenLCB Node ID Specification”.
-This explanation is not normative in any way.</P>
-<H2 CLASS="western">Annotations to the Specification</H2>
-<P>This section provides background information on corresponding
-sections of the Specification document. It's expected that two
-documents will be read together.</P>
-<H3 CLASS="western">Introduction</H3>
-<H3 CLASS="western">References and Context</H3>
-<H3 CLASS="western">Format</H3>
-<P>The specification doesn't require any particular human-readable
-format, but hex-pairs with separators are strongly suggested, e.g.
-01.AB.34.01.CD.E3; decimal pairs could also be used, but in that case
-it's important to provide a way to know which is use.</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Copied: trunk/specs/drafts/GenNodeIdS.odt (from rev 995, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/GenNodeIdS.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/GenNodeIdS.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Deleted: trunk/specs/drafts/GenNodeIdSpec.html
===================================================================
--- trunk/specs/drafts/GenNodeIdSpec.html 2010-10-09 05:03:06 UTC (rev 997)
+++ trunk/specs/drafts/GenNodeIdSpec.html 2010-10-09 05:09:31 UTC (rev 998)
@@ -1,60 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB Node ID Specification</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;13201800">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- H3.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-Node ID Specification
-</H1>
-<H2 CLASS="western">Introduction (Informative)</H2>
-<P>This specification describes the format and allocation of OpenLCB
-node identifers (node IDs). It is not specific to any wire protocol.</P>
-<H2 CLASS="western">References and Context (Normative)</H2>
-<P>This specification is in the context of the OpenLCB-CAN …
-Specification, which specifies …</P>
-<H3 CLASS="western">Format</H3>
-<P>An OpenLCB node identifier (node ID) shall be six bytes of eight
-bits each.
-</P>
-<P>The order of bytes in an OpenLCB node ID shall be considered
-significant. The most-significant byte shall be transmitted first
-during communication operations. The most-significant byte shall be
-written first (left-most in Western format) in any human-readable
-representation.</P>
-<P>OpenLCB node IDs shall include one or more 1 bits.
-</P>
-<H3 CLASS="western">Allocation</H3>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Copied: trunk/specs/drafts/GenNodeIdTN.odt (from rev 995, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/GenNodeIdTN.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/GenNodeIdTN.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-09 05:15:03
|
Revision: 999
http://openlcb.svn.sourceforge.net/openlcb/?rev=999&view=rev
Author: jacobsen
Date: 2010-10-09 05:14:56 +0000 (Sat, 09 Oct 2010)
Log Message:
-----------
reformat
Added Paths:
-----------
trunk/specs/drafts/TcpSegmentTransferS.odt
trunk/specs/drafts/TcpSegmentTransferS.pdf
trunk/specs/drafts/TcpSegmentTransferTN.odt
trunk/specs/drafts/TcpSegmentTransferTN.pdf
Removed Paths:
-------------
trunk/specs/drafts/TcpSegmentTransferExpl.html
trunk/specs/drafts/TcpSegmentTransferSpec.html
Deleted: trunk/specs/drafts/TcpSegmentTransferExpl.html
===================================================================
--- trunk/specs/drafts/TcpSegmentTransferExpl.html 2010-10-09 05:09:31 UTC (rev 998)
+++ trunk/specs/drafts/TcpSegmentTransferExpl.html 2010-10-09 05:14:56 UTC (rev 999)
@@ -1,47 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB-TCP Segment Transfer Explanation</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;11035500">
- <STYLE TYPE="text/css">
- <!--
- H3.ctl { font-family: "Lucida Sans" }
- H2.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-OpenLCB-TCP Segment Transfer Explanation
-</H1>
-<H2 CLASS="western">Introduction</H2>
-<P>This explanatory note contains informative discussion and
-background for the corresponding “OpenLCB ... Specification”.
-This explanation is not normative in any way.</P>
-<H2 CLASS="western">Annotations to the Specification</H2>
-<P>This section provides background information on corresponding
-sections of the Specification document. It's expected that two
-documents will be read together.</P>
-<H3 CLASS="western">Introduction</H3>
-<H3 CLASS="western">References and Context</H3>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Copied: trunk/specs/drafts/TcpSegmentTransferS.odt (from rev 995, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/TcpSegmentTransferS.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/TcpSegmentTransferS.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Deleted: trunk/specs/drafts/TcpSegmentTransferSpec.html
===================================================================
--- trunk/specs/drafts/TcpSegmentTransferSpec.html 2010-10-09 05:09:31 UTC (rev 998)
+++ trunk/specs/drafts/TcpSegmentTransferSpec.html 2010-10-09 05:14:56 UTC (rev 999)
@@ -1,43 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>OpenLCB-TCP Segment Transfer Specification</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2 (Unix)">
- <META NAME="CREATED" CONTENT="0;0">
- <META NAME="CHANGEDBY" CONTENT="Bob Jacobsen">
- <META NAME="CHANGED" CONTENT="20100922;11062900">
- <STYLE TYPE="text/css">
- <!--
- H2.ctl { font-family: "Lucida Sans" }
- -->
- </STYLE>
-</HEAD>
-<BODY LANG="en-US" DIR="LTR">
-<H1><FONT COLOR="#000000"><IMG SRC="../../web/logo-ajs-dph.png" NAME="OpenLCB" ALIGN=RIGHT WIDTH=337 HEIGHT=135 BORDER=2></FONT>OpenLCB
-OpenLCB-TCP Segment Transfer Specification
-</H1>
-<H2 CLASS="western">Introduction (Informative)</H2>
-<P>This specification describes ...</P>
-<H2 CLASS="western">References and Context (Normative)</H2>
-<P>This specification is in the context of the OpenLCB-CAN …
-Specification, which specifies …</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Below this is just a collection of pieces from other docs right
-now.</P>
-<P><BR><BR>
-</P>
-<P><BR><BR>
-</P>
-<HR>
-<P>Site hosted by <FONT COLOR="#000080">
-<A HREF="http://sourceforge.net/projects/openlcb"><FONT COLOR="#000080"><IMG SRC="http://sflogo.sourceforge.net/sflogo.php?group_id=286373&type=13" NAME="graphics1" ALIGN=ABSMIDDLE WIDTH=120 HEIGHT=30 BORDER=2></FONT></A></FONT>
-</P>
-<P>This is SVN $Revision$
-</P>
-</BODY>
-</HTML>
\ No newline at end of file
Copied: trunk/specs/drafts/TcpSegmentTransferTN.odt (from rev 995, trunk/specs/drafts/Template.odt)
===================================================================
(Binary files differ)
Added: trunk/specs/drafts/TcpSegmentTransferTN.pdf
===================================================================
(Binary files differ)
Property changes on: trunk/specs/drafts/TcpSegmentTransferTN.pdf
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2010-10-12 16:20:09
|
Revision: 1023
http://openlcb.svn.sourceforge.net/openlcb/?rev=1023&view=rev
Author: jacobsen
Date: 2010-10-12 16:20:01 +0000 (Tue, 12 Oct 2010)
Log Message:
-----------
move from dev doc
Modified Paths:
--------------
trunk/specs/drafts/CanDatagramTransportS.odt
trunk/specs/drafts/CanEventTransportS.odt
trunk/specs/drafts/CanFrameTransferS.odt
trunk/specs/drafts/CanMessageNetworkS.odt
trunk/specs/drafts/CanMessageNetworkTN.odt
Modified: trunk/specs/drafts/CanDatagramTransportS.odt
===================================================================
(Binary files differ)
Modified: trunk/specs/drafts/CanEventTransportS.odt
===================================================================
(Binary files differ)
Modified: trunk/specs/drafts/CanFrameTransferS.odt
===================================================================
(Binary files differ)
Modified: trunk/specs/drafts/CanMessageNetworkS.odt
===================================================================
(Binary files differ)
Modified: trunk/specs/drafts/CanMessageNetworkTN.odt
===================================================================
(Binary files differ)
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2011-07-23 23:36:33
|
Revision: 1399
http://openlcb.svn.sourceforge.net/openlcb/?rev=1399&view=rev
Author: jacobsen
Date: 2011-07-23 23:36:27 +0000 (Sat, 23 Jul 2011)
Log Message:
-----------
update footer, reset changes
Modified Paths:
--------------
trunk/specs/drafts/TemplateS.odt
trunk/specs/drafts/TemplateTN.odt
Modified: trunk/specs/drafts/TemplateS.odt
===================================================================
(Binary files differ)
Modified: trunk/specs/drafts/TemplateTN.odt
===================================================================
(Binary files differ)
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2012-03-19 15:02:58
|
Revision: 2033
http://openlcb.svn.sourceforge.net/openlcb/?rev=2033&view=rev
Author: jacobsen
Date: 2012-03-19 15:02:47 +0000 (Mon, 19 Mar 2012)
Log Message:
-----------
Add some todo information
Modified Paths:
--------------
trunk/specs/drafts/GenMessageNetworkTN.odt
trunk/specs/drafts/GenMessageNetworkTN.pdf
Modified: trunk/specs/drafts/GenMessageNetworkTN.odt
===================================================================
(Binary files differ)
Modified: trunk/specs/drafts/GenMessageNetworkTN.pdf
===================================================================
(Binary files differ)
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <jac...@us...> - 2012-03-19 15:54:57
|
Revision: 2034
http://openlcb.svn.sourceforge.net/openlcb/?rev=2034&view=rev
Author: jacobsen
Date: 2012-03-19 15:54:51 +0000 (Mon, 19 Mar 2012)
Log Message:
-----------
add a to-do about OptionalRejected to MTIs that are not recognized; fix parenthesis alignment
Modified Paths:
--------------
trunk/specs/drafts/GenMessageNetworkTN.odt
trunk/specs/drafts/GenMessageNetworkTN.pdf
Modified: trunk/specs/drafts/GenMessageNetworkTN.odt
===================================================================
(Binary files differ)
Modified: trunk/specs/drafts/GenMessageNetworkTN.pdf
===================================================================
(Binary files differ)
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X