Skip to content

Commit fc30aee

Browse files
pavel-kirienkopavel-kirienko
committed
can.tex update
1 parent f35c5d6 commit fc30aee

1 file changed

Lines changed: 97 additions & 21 deletions

File tree

‎specification/transport/can/can.tex‎

Lines changed: 97 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,25 @@ \section{Cyphal/CAN}\label{sec:transport_can}
66
Throughout this section, ``CAN'' implies both Classic CAN 2.0 and CAN FD, unless specifically noted otherwise.
77
CAN FD should be considered the primary transport protocol.
88

9+
\subsection{Definitions}
10+
11+
\begin{description}
12+
\item[Node-ID] A 7-bit numerical identifier of a node, in the range $[0, 127]$.
13+
Nodes on the same Cyphal/CAN network shall have distinct node-IDs.
14+
15+
\item[Subject-ID] A 16-bit numerical identifier of a publish-subscribe subject, in the range $[0, 65535]$.
16+
Cyphal/CAN v1.0 supported only the 13-bit subject-ID range $[0, 8191]$.
17+
18+
\item[Service-ID] A 9-bit numerical identifier of a remote procedure call service, in the range $[0, 511]$.
19+
Cyphal v1.1 only uses service-ID 511 for unicast exchanges; the remaining IDs are only useful for interaction
20+
with pre-v1.1 nodes.
21+
22+
\item[Transfer-ID] A cyclic counter taken modulo 32 that distinguishes consecutive transfers originated by
23+
the same source node on the same subject or service. Used for duplicate suppression and for ordering the
24+
frames of a multi-frame transfer. The sender increments it once per transfer; the receiver applies a timeout
25+
to bound its state.
26+
\end{description}
27+
928
\subsection{CAN ID field}
1029

1130
Cyphal/CAN transport frames are CAN 2.0B frames.
@@ -18,11 +37,18 @@ \subsection{CAN ID field}
1837
However, future revisions of Cyphal/CAN may utilize CAN 2.0A as well,
1938
so backward compatibility with other high-level CAN bus protocols is not guaranteed.
2039

21-
Cyphal/CAN utilizes two different CAN ID bit layouts for message transfers and service transfers.
22-
The bit layouts are summarized on figure~\ref{fig:transport_can_id_structure}.
23-
Tables~\ref{table:transport_can_id_fields_message_transfer} and~\ref{table:transport_can_id_fields_service_transfer}
24-
summarize the purpose of each field and their permitted values
25-
for message transfers and service transfers, respectively.
40+
Cyphal/CAN defines three CAN ID bit layouts, summarized on figure~\ref{fig:transport_can_id_structure}:
41+
the \textbf{v1.1 message transfer} format with a 16-bit subject-ID;
42+
the \textbf{v1.0 message transfer} format with a 13-bit subject-ID, retained for wire compatibility with
43+
Cyphal/CAN v1.0 nodes; and the \textbf{service transfer} format, shared by both versions.
44+
The two message formats are discriminated by the value of CAN ID bit~7:
45+
v1.0 messages have bit~7 cleared, while v1.1 messages have bit~7 set.
46+
A v1.0 receiver silently discards v1.1 message frames because they fail the v1.0 reserved-bit check at bit~7,
47+
which allows a v1.1 network to coexist with legacy v1.0 nodes on the same bus.
48+
Tables~\ref{table:transport_can_id_fields_message_transfer_v11},
49+
\ref{table:transport_can_id_fields_message_transfer_v10},
50+
and~\ref{table:transport_can_id_fields_service_transfer}
51+
summarize the fields of each layout.
2652

2753
% Please do not remove the hard placement specifier [H], it is needed to keep elements ordered.
2854
\begin{figure}[H]
@@ -31,13 +57,54 @@ \subsection{CAN ID field}
3157
\footnotesize
3258
\begin{tabular}{|l|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|c|} \hline
3359
%
34-
% Message transfer
60+
% v1.1 16-bit message transfer
3561
%
36-
\multirow{2}{*}{\textbf{Message}} &
62+
\multirow{2}{*}{\textbf{Message 16-bit}} &
63+
\multicolumn{4}{c|}{Service, not message} &
64+
\multicolumn{1}{c|}{\multirow{2}{*}{R}} &
65+
\multicolumn{16}{c|}{\multirow{2}{*}{Subject-ID}} &
66+
\multicolumn{1}{c|}{\multirow{2}{*}{V}} &
67+
\multicolumn{7}{c|}{\multirow{2}{*}{Source node-ID}}
68+
\\\cline{2-4}
69+
70+
&
71+
\multicolumn{3}{c|}{Priority}
72+
&
73+
&
74+
&
75+
\multicolumn{16}{c|}{} &
76+
&
77+
\multicolumn{7}{c|}{}
78+
\\
79+
80+
\textbf{Values} &
81+
\multicolumn{3}{c|}{$[0, 7]$} &
82+
$0$ &
83+
$0$ &
84+
\multicolumn{16}{c|}{$[0, 65535]$} &
85+
$1$ &
86+
\multicolumn{7}{c|}{$[0, 127]$}
87+
\\\hline
88+
89+
\textbf{CAN ID bit} &
90+
28 & 27 & 26 & 25 & 24 & 23 & 22 & 21 & 20 & 19 & 18 & 17 & 16 & 15 &
91+
14 & 13 & 12 & 11 & 10 & 9 & 8 & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0
92+
\\\hline
93+
94+
\textbf{CAN ID byte} &
95+
\multicolumn{5}{c|}{3} & \multicolumn{8}{c|}{2} & \multicolumn{8}{c|}{1} & \multicolumn{8}{c|}{0}
96+
\\\hline
97+
98+
\multicolumn{30}{c}{} \\ \hline % Table separator
99+
100+
%
101+
% v1.0 13-bit message transfer
102+
%
103+
\multirow{2}{*}{\textbf{Message 13-bit}} &
37104
\multicolumn{4}{c|}{Service, not message} &
38105
\multicolumn{4}{c|}{Anonymous} &
39106
\multicolumn{13}{c|}{\multirow{2}{*}{Subject-ID}} &
40-
\multicolumn{1}{c|}{\multirow{2}{*}{R}} &
107+
\multicolumn{1}{c|}{\multirow{2}{*}{V}} &
41108
\multicolumn{7}{c|}{\multirow{2}{*}{Source node-ID}}
42109
\\\cline{2-4} \cline{7-9}
43110

@@ -121,8 +188,27 @@ \subsection{CAN ID field}
121188
\caption{CAN ID bit layout}\label{fig:transport_can_id_structure}
122189
\end{figure}
123190

124-
\begin{CyphalSimpleTable}[wide]{CAN ID bit fields for message transfers}{|l l l X|}
125-
\label{table:transport_can_id_fields_message_transfer}
191+
\begin{CyphalSimpleTable}[wide]{CAN ID bit fields for 16-bit v1.1 message transfers}{|l l l X|}
192+
\label{table:transport_can_id_fields_message_transfer_v11}
193+
Field & Width & Valid values & Description \\
194+
195+
Transfer priority & 3 & $[0, 7]$ (any) & Section~\ref{sec:transport_transfer_priority}. \\
196+
197+
Service, not message & 1 & $0$ & Always zero for message transfers. \\
198+
199+
Reserved bit 24 & 1 & $0$ & Discard frame if this field has a different value.
200+
Occupied the anonymous flag in Cyphal/CAN v1.0;
201+
anonymous transfers are not supported in v1.1. \\
202+
203+
Subject-ID & 16 & $[0, 65535]$ (any) & Subject-ID of the current message transfer. \\
204+
205+
Version bit 7 & 1 & $1$ & Always one for v1.1 message transfers. \\
206+
207+
Source node-ID & 7 & $[0, 127]$ (any) & Node-ID of the origin. \\
208+
\end{CyphalSimpleTable}
209+
210+
\begin{CyphalSimpleTable}[wide]{CAN ID bit fields for 13-bit v1.0 message transfers}{|l l l X|}
211+
\label{table:transport_can_id_fields_message_transfer_v10}
126212
Field & Width & Valid values & Description \\
127213

128214
Transfer priority & 3 & $[0, 7]$ (any) & Section~\ref{sec:transport_transfer_priority}. \\
@@ -134,22 +220,12 @@ \subsection{CAN ID field}
134220

135221
Reserved bit 23 & 1 & $0$ & Discard frame if this field has a different value. \\
136222

137-
% The asymmetric requirement to transmit only 1 and accept any value is due to the need to ensure compatibility
138-
% with the implementations following the v1-alpha spec, where the width of the subject-ID field was 15 bit
139-
% (two bits wider). We keep the most significant bits set to ensure the compatibility of the regulated subject-IDs
140-
% between v1-alpha and v1-beta. Ensuring the compatibility of unregulated subject-IDs is far less important because
141-
% generally, they are easily changeable.
142-
%
143-
% Such backward-compatible change renders these two bits unusable for the possible future expansion of the
144-
% subject-ID field, but this is fine, because shall the expansion become imminent, we can always flip R7 from 0
145-
% to 1, and thus pave the way for a completely new bit layout format with a wider subject-ID. Meanwhile, R21 and
146-
% R22 can be leveraged for some additional optional features.
147223
Reserved bit 22 & 1 & $1$, any & Transmit $1$; ignore (do not check) when receiving. \\
148224
Reserved bit 21 & 1 & $1$, any & Transmit $1$; ignore (do not check) when receiving. \\
149225

150226
Subject-ID & 13 & $[0, 8191]$ (any) & Subject-ID of the current message transfer. \\
151227

152-
Reserved bit 7 & 1 & $0$ & Discard frame if this field has a different value. \\
228+
Version bit 7 & 1 & $0$ & Always zero for v1.0 legacy message transfers. \\
153229

154230
Source node-ID & 7 & $[0, 127]$ (any) & Node-ID of the origin.
155231
For anonymous transfers, this field contains a pseudo-ID instead,

0 commit comments

Comments
 (0)