88 / 100
controllo
tecnica
Luglio/Agosto 2015
n
Automazione e Strumentazione
88
fase di progettazione delle applicazioni
di controllo e di configurazione iniziale
del sistema, è possibile ridurre (e, in
molti casi, evitare) l’inserimento di stuff
bit anche nell’intestazione del messaggio
[4]
. Occorre tuttavia ricordare che, tipi-
camente, l’intestazione di ogni messag-
gio CAN non varia fra successive istanze
di trasmissione dello stesso, per cui l’e-
ventuale presenza di stuff bit in tale parte
del messaggio non introduce alcun jitter.
Purtroppo le tecniche esistenti non sono
in grado di gestire le porzioni di trama
legate ai meccanismi di rilevamento
degli errori e, in particolare, il campo
relativo al
controllo di ridondanza
ciclico
(CRC), calcolato autonomamente
dal controller CAN. Anche prevedendo
tutte le contromisure indicate in prece-
denza, eventuali stuff bit introdotti nel
campo CRC possono causare jitter di
comunicazione residui di entità massima
pari a 4 tempi di bit
[5]
.
In questo articolo viene descritto un
meccanismo, denominato
Zero Stuff-bit
CRC
(
ZSC
)
[6]
, che permette di preve-
nire l’inserimento di stuff bit nel campo
CRC. Ove accoppiato con opportune tec-
niche di codifica per il campo dati, come
ad esempio 8B9B, ciò permette di fatto
l’eliminazione degli stuff bit dall’intera
trama di messaggio CAN. Nel seguito,
l’uso combinato delle due tecniche ZSD
e ZSC verrà indicato genericamente col
termine di codifica
Zero Stuff-bit
(
ZS
).
Nell’ambito delle attività di
ricerca condotte presso IEIIT-
CNR è stato sviluppato un
codec
s/w ZS, basato su 8B9B
e ZSC ed ottimizzato per piat-
taforme
embedded
, in grado di
effettuare codifica e decodifica
di un messaggio CAN in tempi
dell’ordine di pochi microse-
condi. Il codec ha un
footprint
di circa
2 KB
e può essere
incorporato direttamente, e con
grande facilità, sia in nuovi
progetti sia in dispositivi già
esistenti.
A titolo di esempio si tenga presente che,
sfruttando un paradigma di accesso al
mezzo trasmissivo tale da evitare l’ar-
bitraggio previsto da CAN (ad esempio,
utilizzando un comunissimo schema di
tipo master-slave) in una rete operante a
500 Kb/s, tale codec è in grado di ridurre
i jitter di comunicazione da circa 50 µs a
meno di
0.5 µs
.
Nel caso in cui la codifica ZS venga
effettuata in h/w direttamente nel con-
troller CAN, i jitter di trasmissione pos-
sono essere di fatto annullati, pur mante-
nendo una completa compatibilità con i
controller convenzionali e le implemen-
tazioni di ZS basate su codec s/w.
Un ulteriore beneficio derivante dall’im-
piego delle codifiche ZS è la diminu-
zione della probabilità di errore residua
di circa due ordini di grandezza.
Segnale sul bus CAN
A livello fisico, il segnale trasmesso
sul CAN bus adotta una codifica di tipo
non-return to zero
(NRZ) con
bit stuf-
fing
(BS). Ogni qualvolta vengono rile-
vati 5 bit consecutivi allo stesso livello
nella sequenza di bit trasmessa sul bus, il
controller CAN del dispositivo trasmetti-
tore introduce automaticamente uno stuff
bit di valore opposto. Come è noto, gli
stuff bit permettono un’adeguata sincro-
nizzazione dei circuiti di decodifica nei
controller CAN dei ricevitori, e vengono
rimossi prima della decodifica del mes-
saggio.
È opportuno ricordare che solo il
pre-
fisso
(S) della trama è soggetto a bit stuf-
fing (
►
figura 2
). CAN prevede infatti
che il suffisso, di dimensioni predefinite
e limitate, non sia interessato da tale
codifica.
Formato delle trame CAN
Una
trama
di messaggio CAN (F) è com-
posta da quattro sezioni, come mostrato
nella parte inferiore della
►
figura 2
:
-
intestazione
(H): comprende il bit di
inizio trama (SOF), il campo di arbi-
traggio, costituito dall’identificatore
del messaggio (ID) e dal bit di richie-
sta remota (RTR), e il campo di con-
trollo, composto da 2 bit riservati e dal
campo lunghezza dati (DLC);
-
dati
(D): memorizza le informazioni
che devono essere scambiate a livello
applicativo, anche conosciute come
payload
(P); ogni tecnica di codifica
jitterless dei dati CAN opera un’op-
portuna codifica di P prima di copiare
il suo valore in D;
-
controllo
(R): CRC su 15 bit, calco-
lato dal trasmettitore su tutti i campi
che lo precedono (utilizzando un poli-
nomio generatore specifico di CAN) e
verificato da ogni ricevitore;
-
suffisso
(U): posto a fine trama,
include il delimitatore di CRC
(CDEL), il campo di acknowledge-
ment (ACK slot) ed il relativo deli-
mitatore (ADEL), nonché il campo
di fine trama (EOF). Poiché U non è
soggetto a bit stuffing, esso è di fatto
irrilevante per la trattazione che segue.
Complessivamente, una trama può
quindi essere descritta come
F = H \ D \ R \ U
dove “\” denota l’operazione di concate-
nazione fra stringhe di bit.
Bit stuffing e campo CRC
Prevenire l’inserimento di stuff bit nel
campo CRC non è un’operazione banale,
poiché tale campo viene cal-
colato dal controller CAN
sulla base di tutto il messaggio
secondo regole fisse e predefi-
nite. Nel seguito, il calcolo del
CRC effettuato da CAN viene
modellato come una funzione
c
(•), cioè:
R =
c
(M)
dove il
messaggio
M coincide
con la parte di trama coperta dal
CRC (dal bit di SOF fino alla
fine del campo dati):
M = H \ D
L’idea fondamentale per prevenire gli
stuff bit in CAN è che, sebbene il valore
di R non possa essere impostato diret-
tamente dall’utente, esso può tuttavia
Figura 2 - Formato della trama CAN e ZS