Image Processing Reference
In-Depth Information
Local time
Cycle time
NTU
=
Time trigger 1
Time mark 1
=
Time mark 2
Sync mark
Time trigger 2
SOF
detected
=
Time mark 3
Time trigger 3
Ref mark
Valid RM
detected
+
-
=
Time mark
n
-1
TX-ref trigger
=
Cycle time
Time mark
n
Watch trigger
(a) Synchronization of the cycle time
(b) Scheduling driven by the cycle time
FIGURE .
Time-triggered operation in TTCAN.
issampledonthebusasynchronizationeventisgeneratedineverynetworkcontrollerthatcausesthe
local time to be copied in a sync mark register. After the message has been completely read, a check
is made by controllers: if the SOF bit was related to a valid RM, the sync mark register is loaded into
the reference mark register. At this point, the cycle time can be evaluated simply as the difference
between the current local time and the reference mark (see Figure .a).
Two kinds of RM are actually foreseen: in level implementations this message is -byte long,
whereas level relies on a -byte RM that is backward compatible with level ; from a practical point
of view, three more bytes are appended for distributing the global time (as seen by the TM).
Protocol execution is driven in every node by the progression of the cycle time. In particular, a
number of time marks are defined in each network controller as either transmission or receive trig-
gers, which are used for sending messages and validate message receptions, respectively, as shown in
Figure .b. As soon as the cycle time equals a particular time mark, the related trigger is raised. It
is worth noting that TTCAN does not require that each node knows the schedule of all messages in
the network. Instead, only details of the messages the node sends or is interested in are needed.
Two triggers, that is the TX-ref trigger and the watch trigger, are not used for exchanging data. he
former is employed by potential TMs to trigger the generation of RM. he latter, instead, is used to
detect the absence of RMs on the network (which implies a faulty condition).
From a general perspective, TTCAN requires slight (and mostly inexpensive) changes to the inter-
nal architecture of current CAN chips. In particular, transmit and receive triggers and some counters
and registers for managing the cycle time are basically needed for ensuring time-triggered operations.
Even though level could be implemented completely in software, specialized hardware support
can reduce noticeably the burden on the processor for managing time-triggered operations. As level
compliant controllers have to provide support for drift correction and calibration of the local time,
they need the controller hardware to be explicitly modified.
The structure of TTCAN modules is very similar to that of conventional CAN modules. In partic-
ular, only two additional blocks are needed, i.e., the trigger memory and the frame synchronization
entity. The former is used for storing the time marks of the system matrix that are linked to mes-
sage buffers held in the controller's memory. The latter, instead, is used to control time-triggered
communications.
At present, some controllers are available off-the-shelf that comply with the TTCAN specifications,
so that this solution is no longer mainly theoretical, but can be actually embedded in new projects.
