Embedded Systems: Communication - Intranet...

Politecnico di Milano

© 2006 - Luca Pizzamiglio

Embedded Systems: Communication

Embedded Systems: comunicazione real-time

Lecturer:

Prof. William [email protected]

Communication © 2006 - Luca Pizzamiglio- 2 -

Sommario

La comunicazione RT

Introduzione

Il bus CAN

Il livello fisico

Il livello dati

Gestione degli errori

Il bus TTP

Il bus ByteFlight

Estensioni RT per ethernet

RTNET

Rether


Sommario

La comunicazione RT

Introduzione

Il bus CAN

Il livello fisico

Il livello dati


Il bus TTP

Il bus ByteFlight


RTNET

Rether


Introduzione

La comunicazione basata su bus soffre di un

problema nella garanzia dei vincoli real-time

La causa principale è dovuta all’arbitraggio

Se l’arbitraggio favorisce l’attore sbagliato, una

comunicazione può non avvenire nei tempi previsti e

si verifica un fallimento

Le prestazioni massime di un bus sono fisse

Se arrivano troppe richieste, il bus può risultare

inadeguato

Gestione con code di priorità

Le ritrasmissioni modificano i tempi di trasmissione

in modo impredicibile


Introduzione

In generale, vi sono due approcci alla gestione real-

time di un bus

Gestione ad eventi (CAN) – event driven

Gestione a tempo (TTP) – time driven

Oltre a queste due filosofie, se ne affianca una

mista che cerca di riunire i vantaggi dei due

approcci

Si sovrappone una gestione time driven con una parte

event driven


Introduzione

Il protocollo ethernet non ha nessuna garanzia real-

time

La politica di accesso al link, la CSMA/CD, non

garantisce caratteristiche di determinismo

Le contese sono risolte con ritardi generati su base

statistica

Non ci sono garanzie sui tempi di attesa

Si presenteranno due approcci che estendono

ethernet fornendo garanzie real-time

RTNET – protocollo TDMA

Rether – protocollo a token


Sommario

La comunicazione RT

Introduzione

Il bus CAN

Il livello fisico

Il livello dati


Il bus TTP

Il bus ByteFlight


RTNET

Rether


Il bus CAN

Il protocollo CAN – Controller Area Network – è uno

standard ISO – ISO 11898 – per le comunicazioni

seriali

Nasce per il settore automotive, ma al giorno d’oggi

è usato anche in altri settori, tra cui quello

dell’automazione industriale

Lo standard, in riferimento alla pila ISO-OSI, copre

solo il livello fisico e e il livello dati.

Le altre funzionalità vengono demandate ad altri

protocolli di livello superiore (Higher Level Protocol)

Il livello fisico non è strettamente specificato, ma

sono suggerite alcune realizzazioni di riferimento


Il bus CAN – il livello fisico

Lo standard prevede due possibili livelli fisici

High speed CAN

Low speed CAN

Entrambi questi standard utilizzano una

trasmissione differenziale su una coppia di cavi

Esiste uno standard, legato all’automotive,

suggerito in SAE J2411, caratterizzato da un singolo

filo

Comunque è previsto un riferimento di massa comune



La codifica prevista è la Non Zero Returning

Riduce la banda necessaria

Necessita di bit di stuffing

Per motivi di sincronizzazione, ogni 5 bit uguali viene inserito un bit opposto (il bit di stuffing) che dovrà essere riconosciuto ed eliminato dal ricevitore

Lo standard definisce i bit come recessivi e dominanti rispetto alle operazioni logiche AND e OR

A seconda del tipo di cablaggio il bit dominante sarà 0 o 1

Si rendono possibili entrambe le implementazioni

Tratteremo l’OR wiring, utilizzando 1 come bit dominante e 0 come bit recessivo



High speed CAN

Trasmissione fino a 1 Mbit/s su distanza massima di 40m

Doppino intrecciato

Impedenza di 120 Ohm per annullare la rilfessione dei segnali

Low speed CAN

Trasmissione fino a 125 Kbit/s

Doppino intrecciato

I dispositivi collegati gestiscono in modo completo tutti i problemi che possono sorgere a livello fisico

Detto anche CAN Fault Tolerant

Single wire CAN

Trasmissione fino a 33Kbit/s su un solo filo

Necessario un riferimento a massa comune


Il bus CAN – il livello dati

Il punto chiave del bus CAN è la gestione delle comunicazioni orientata al contenuto

A questo livello le comunicazioni sono tutte in broadcast – non è previsto un indirizzamento diretto vero una particolare periferica

Ogni messaggio ha una intestazione che contiene un identificatore di messaggio, che rappresenta la priorità del messaggio rispetto agli altri

Le priorità sono:

stabilite in fase di progetto

sono statiche, non dinamiche

devono essere univoche per ciascun tipo di messaggio

– Due diverse stazioni non devono poter trasmettere messaggi con lo stesso identificatore (priorità)



Vi sono due tipi di messaggio, oltre a diversi messaggi di

segnalazione

RF – Remote Frame

Frame senza campo dati che sollecita l’invio di un valore

DF – Data Frame

Frame di trasmessione dati

EF – Error Frame

Rileva un errore e provoca la ritrasmissione

OF – Overload Frame

Viene inviato da un nodo sovraccarico per ritardare la

trasmissione del pacchetto successivo

IS – Interframe Space

Precede ogni DF e RF e ha una funzione separatrice



I messaggi Data e Remote Frame sono composti da:Start Of Frame

un solo bit 1 con due scopi– distinguere i Data e Remote Frame dagli altri messaggi

– sincronizzare i ricevitori

Arbitration Fieldcontiene l’identificatore del messaggio

Remote Trasmission Requestdistingue tra RF e DF, con priorità al DF

Control Fieldspecifica la lunghezza del Data Field (4 bit) e 2 bit sono riservati per usi futuri

Data Field (solo DF)contiene i dati e può avere una dimensione tra 0 e 8 bytes

CRC Fieldsequenza di controllo d’errore (16 bit)

ACKcampo che può essere sovrascritto da qualsiasi nodo per segnalare un’errore di ricezione e chiedere la ritrasmissione del dato

End Of Frame7 bit uguali a zero per segnalare la fine della trasmissione



L’arbitraggio avviene direttamente sul bus a livello di identificatore di messaggio (Arbitration Field)

Ciascuna stazione trasmittente, mentre trasmette, monitora il bus

Qualora ci fosse un conflitto con un identificatore più alto (basso), l’OR (AND) wiring cambia il valore presente sul bus

Tutte le stazioni trasmittenti che perdono l’arbitraggio diventano ricevitori del messaggio

Questo meccanismo garantisce tempi di trasmissione certi ai messaggi con più alta priorità

La priorità deve essere scelta opportunamente dal progettista


Il bus CAN – la gestione degli errori

La gestione degli errori avviene al livello dati

La presenza di diversi tipi di protezione dagli errori insiti nel protocollo stesso, ha garantito una larga diffusione del protocollo CAN

Protezione sul messaggio

CRC

ACK

Frame check

Protezione a livello di bit

Monitoring

Bit stuffing

Autoesclusione delle stazioni riceventi

Se presentano una percentuale di errori elevata, per non compromettere l’intero bus con continue ritrasmissioni, le stazioni riceventi possono autoescludersi



La protezione sul messaggio

CRC a 16 bit

Nel messaggio viene incluso un codice a correzione d’errore di 16 bit calcolato sui dati inviati

ACK

Il segnale di ack chiede la ritrasmissione del messaggio nel caso in cui il controllo CRC o l’identificazione delle componenti del messaggio falliscano

Protezione sui bit

Il monitoring dello stato del bus permette al trasmettitore attivo di identificare propri errori, nonchè errori globali

Il bit stuffing garantisce la sincronizzazione in caso di sequenze di bit identici superiori a 5 elementi



Autoesclusione

Ogni stazione gestisce due contatori

Errori rilevati o segnalati da altri durante la trasmissione

Errori in ricezione

I contatori vengono incrementati da ciascun errore identificato con le metodologie precedenti assegnando anche una gravità

In base al valore assunto dai due contatori, la stazione si pone in uno dei seguenti stati

Error active: il numero di errori è accettabile e la stazione partecipa alla trasmissione

Error passive: la stazione commette un numero elevato di errori; la segnalazione di errore non genera automaticamente la ritrasmissione

Bus off: la stazione commette un numero di errori che comprometterebbe la rete. La stazione non partecipa alla rete, ma si mette in modalità di ascolto. Può riprendere le trasmissioni solo quando il bus è libero e non partecipa alle contese.

– Il nodo resta in attesa di 11 o più bit recessivi consecutivi che costituiscono lo spazio minimo tra due frame consecutivi


Il bus CAN – TTCAN

TTCAN è un protocollo di alto livello che, basandosi

su un’infrastruttura CAN, gestisce la trasmissione

dei dati sia in modalità time-triggered sia in

modalità event-triggered

TTCAN è l’acronimo di time-triggered CAN

È definito nello standard OSI 11898-1

L’utilizzo di TTCAN permette di gestire i controlli in

catena chiusa mediante CAN e di migliorare le

prestazioni di CAN caratterizzando le esigenze

temporali di ciascun tipo di segnale

Segnali periodici

Segnali associati ad eventi



Ogni stazione possiede un livello software che gestisce la sincronizzazione mediante il riconoscimento di un reference frame

Tutte le stazioni sono sincronizzate e ogni stazione sa dopo quanto tempo dal reference frame deve iniziare a trasmettere

Il periodo di tempo che intercorre tra due reference frame è detto frame cycle e non è necessariamente costante

Si possono servire le diverse esigenze con periodi differenti

La somma dei diversi frame cycle fornisce il tempo di ciclo



Il singolo frame cycle è suddiviso in finestre

Alcune dedicate a particolari messaggi o stazioni

Altri lasciati all’arbitraggio per l’invio di messaggi

event-triggered

Reference

Message

Reference

Message

Reference

Message

Reference

Message

Message A

Message A

Message A

Message A

Msg C

Arb

Msg U

Msg R

Message M

Message M

Arbitration

Arbitration

Msg CMessage M

Message M

Message D

Message D

Msg C

Msg C

Msg C

Frame

Cycle 0

Frame

Cycle 1

Frame

Cycle 2

Frame

Cycle 3


Sommario

La comunicazione RT

Introduzione

Il bus CAN

Il livello fisico

Il livello dati


Il bus TTP

Il bus ByteFlight


RTNET

Rether


Il bus TTP

Il TTP (Time Triggered Protocol) è basato su TDMA

(Time Driven Multiple Access) statico al bus da

parte delle diverse stazioni

Questo approccio si contrappone al bus CAN

Il bus CAN gestisce l’accesso in modo event-triggered

attraverso la risoluzione delle contese

Lo scheduling statico delle trasmissioni garantisce

ad ogni stazione di poter comunicare, ed essere

quindi ascoltata, ad intervalli predefiniti

Non si corre il rischio di rinvii indefiniti

Lo scheduling statico può portare a un tempi di bus

inutilizzati e a un basso utilizzo della risorsa


Il bus TTP

Il bus TTP è stato ottimizzato sia per una topologia a stella sia per una topologia ad anello

Ad ogni modifica della topologia deve seguire una riconfigurazione di tutte le stazioni

Nel caso di un nuovo nodo trasmittene, è necessario riconfigurare tutti i nodi al fine di riservare uno slot di trasmissione per il nuovo nodo

Viste le caratteristiche principali del bus TTP, si intuisce che questo protocollo è indicato per le applicazioni “mission critical”

In queste applicazioni non è fondamentale lo sfruttamento del bus, ma deve essere garantito il ritardo massimo da quando un nodo vuole trasmettere a quando il nodo può effettivamente comunicare


Il bus TTP – il livello fisico

Il bus TTP è stato implementato e testato su diversi tipi di

livello fisico (tra cui anche sul bus CAN)

Attualmente, è stato definito uno standard specifico per la

realizzazione di un bus TPP

Lo standard, purtroppo, non è disponibile pubblicamente, ma

se ne conoscono le caratteristiche principali

Tensione di funzionamento compresa tra -12 V e +20 V

Throughput: 25Mbit/s in modalità sincrona, 5Mbit/s in

modalità asincrona

Funzionalità di wake-up e sleep integrate nel livello fisico

Autodiagnosi e sezionamento della rete in caso di probelmi

elettrici a livello fisico

Disponibile anche con comunicazione su fibra ottica


Il bus TTP – il livello fisico

La sincronizzazione del clock non è gestita in modo

centralizzato

La sincronizzazione si basa sulla conoscenza a priori

delle durate della trasmissione

Ogni stazione può calcolare la deviazione tra il

proprio clock e quello del trasmettitore ed allinearsi

Sono state testate topologie sia a stella che a bus

Per aumentare la robustezza ai guasti, sono state

testate anche architetture a stella con più centri

stella, in modo tale da scongiurare il blocco del

sistema per un guasto al controller di centro stella

(Single Point of Failure)


Il bus TTP – arbitraggio

In un bus con gestione TDMA pura, non esistono casi

di contesa e l’arbitraggio avviene in modo

puramente statico e deterministico

L’arbitraggio è stabilito nella fase di progettazione

del sistema

Ad ogni nodo è assegnata una parte della banda

disponibile, suddividendo in time slot di durata

differente ciascun round TDMA.

Ogni stazione può trasmettere solo nel time slot ad

essa assegnato

Ogni stazione ha quindi garanzie di banda e ritardi di

trasmissione certi


Il bus TTP – gestione degli errori

Un guasto ad una stazione corrisponde al suo time

slot inutilizzato

Il sistema di interfacciamento al bus fa sì che una

stazione guasta non posso scrivere nei time slot a lei

non assegnati, evitando di bloccare tutto il bus in

caso di singolo malfunzionamento (nodi fail silent)

La protezione sui dati trasmessi viene affidata ai

livelli di comunicazione superiori

La garanzia di continuità di funzionamento del bus è

dimostrata nell’ipotesi di guasto singolo

Un solo errore grave si verifica nello stesso istante nel

sistema


Sommario

La comunicazione RT

Introduzione

Il bus CAN

Il livello fisico

Il livello dati


Il bus TTP

Il bus ByteFlight


RTNET

Rether


ByteFlight

ByteFlight è un bus seriale ad alta velocità sviluppato per applicazioni automotive da:

BMW

Motorola

ELMOS

Infineon

Siemens EC

Steinbeis

IXXAT

Attualmente è utilizzato da BMW nella produzione di serie delle vetture serie 7

È utilizzato ad Avidyne per la produzione di materiale avionico


ByteFlight – il livello fisico

Il bus, studiato per la fibra ottica con topologia a

stella, unisce le caratteristiche di un protocollo

event-driven e di uno time-driven, sfruttando i

vantaggi di ciascuna soluzione

Le prestazioni (10Mbit/s) e il campo applicativo per

cui è stato studiato, mostrano un collegamento

fisico particolarmente soggetto a disturbi di natura

elettromagnetica

Per questo motivo, il livello fisico si base su POF –

fibre ottiche plastiche in half-duplex e con topologia

a stella


ByteFlight – il livello fisico

Nonostante il notevole costo e la complessità nella

gestione dei segnali ottici, i vantaggi che se ne

derivano giustificano le scelte effettuate

L’isolamento elettrico dei vari componenti

L’immunità del sistema da blocchi dovuti a guasti

sorti in una stazione

A patto di ridurre le prestazioni, è possibile

utilizzare normali connessioni in rame con doppino

ritorto

Esistono anche controllori commerciali che fungono

da bridge tra più bus CAN e ByteFlight


ByteFlight – FTDMA

L’accesso al bus è definito FTDBA – Flexible Time Division Multiple Access

Tutti gli elementi che accedono al bus hanno una base temporale comune, generata dal segnale di SYNC che contraddistingue l’inizio di un ciclo

Ogni stazione può essere configurata come SYNC Master e gli altri si allineano al segnale ricevuto

Il tempo di ciclo è suddiviso in time slot

L’utilizzo dello slot è regolato dal protocollo e implementato in hardware

Durante ogni slot viene incrementato un contatore, che ogni stazione confronta con l’identificativo assegnato al messaggio che deve trasmettere

Se l’identificativo corrisponde, la stazione impegna il bus e trasmette

Se nessuna stazione ha un messaggio da trasmettere con quell’identificativo, dopo un breve periodo di tempo di attesa, il contatore viene incrementato e la procedura si ripete



I messaggi con ID basso sono serviti in tempi brevi,

mentre quelli con vincoli meno stringenti sono

serviti solo quando il bus è libero

Si riesce a garantire un tempo di risposta

deterministico per i messaggi con priorità alta e un

utilizzo elevato del bus da parte degli altri messaggi

quando è libero

In altre parole, il tentativo di ByteFlight è quello di

fornire il determismo dei protocolli time-driven con

lo sfruttamento del bus dei protocolli event-driven.



A trasmette un messaggio con ID 4, mentre B

trasmette due messaggi con ID 1 e 7

Le attese per gli ID 2,3,5,6 sono molto brevi

01

01 07

070400

00 04

A

B

SYNC


ByteFlight – formato dei messaggi

I messaggi sono formati da:

6 bit di start

Un byte per l’ID

La lunghezza del messaggio

Il payload – max 12 byte

Due CRC finali

Questi due CRC garantiscono una distanza di Hamming pari a 6

Ogni byte di dati è separato da un bit di stop e un bit di start

La fine del messaggio è composta da due bit posti a zero

ID IDLEN D0 D11 CRCL


ByteFlight – gestione degli errori

Poichè non si possono effettuare ritrasmissioni immediate, la gestione degli errori viene effettuata a livello di messaggio e di sistema

A livello di messaggio ne viene controllata l’integrità e la rispondenza alle specifiche

Se è il caso, viene generato un messaggio d’errore e la ritrasmissione avviene dopo il minimo intervallo di idle

Se si è persa la sincronizzazione tra i vari elementi, non avviene alcuna ritrasmissione fino a quando il sistema non si è risincronizzato nuovamente

Il centro stella partecipa attivamente effettuando controlli di sistema, escludendo stazioni che violano il time slot di trasmissione e controllando le prestazioni del canale ottico

Ogni transceiver si autoesclude in caso di violazione dei vincoli fisici


Sommario

La comunicazione RT

Introduzione

Il bus CAN

Il livello fisico

Il livello dati


Il bus TTP

Il bus ByteFlight


RTNET

Rether


Estensioni RT su ethernet

Ethernet è un protocollo non real-time

Il suo meccanismo di arbitraggio per la risoluzione delle

contese non fornisce garanzie di determinismo

La risoluzione delle contese avviene ripetendo la

trasmissione dopo un tempo di attesa casuale

Statisticamente, le due stazioni che si contendono il bus

aspettano due tempi diversi

Scaduto il tempo di attesa e si riprova a trasmettere

Non si può escludere, almeno dal punto di vista teorico,

che le stazioni possano soffrire di rinvii indefiniti

Si analizzeranno due estensioni per ethernet che forniscono

alcune garanzie real-time

RTNET

Rether


RTNET

RTNET è un protocollo OpenSource, con

caratteristiche real-time basato su RTAI,

un’estensione RT di Linux

RTNET sfrutta hardware ethernet classico, non

richiede interfacce particolari

Realizza UDP/IP, ICMP e ARP in modo deterministico

Fornisce un socket BSD standard per l’utilizzo con il

kernel RTAI e processi utente real-time

La gestione delle contese avviene attraverso RTmac,

un protocollo a livello mac che gestisce l’accesso

alla risorsa


RTNET

RTNET gestisce il traffico non real-time (TCP/IP)

sulla stessa interfaccia di rete sulla quale passa il

traffico real-time

Permette di realizzare su un unico cavo entrambe le

tipologie di traffico senza però impattare le

prestazioni real-time

Ovviamente, l’impatto è limitato alle prestazioni non

real-time

Il progetto ha natura accademica, anche se è

maturato e, oggi, si può considerare piuttosto

stabile


RTNET - RTmac

RTmac realizza un sistema che fornisce garanzie

temporali di risposta su una struttura fisica già

esistente e che non fornisce nessun tipo di

determinismo temporale

La tecnica utilizzata da RTNET è quella di costruire

un sistema TDMA sopra il CSMA/CD esistente

In altre parole, si istruiscono le diverse perficerche

imponendo un tempo preciso di trasmissione, in modo

da evitare che accadano contese e il CSMA/CD

introduca l’indeterminismo temporale


RTNET - RTmac

Il protocollo RTmac consta di tre fasi:

Distribuzione da parte di un master di un invito a tutti i client contenente la configurazione di RTmac

Scambio degli indirizzi fisici (i MAC address) e delle configurazioni arbitrarie di ciascun client

Sincronizzazione finale dopo le fasi di inizializzazione

Tutte le periferiche interfacciate sulla rete devono essere compatibili con RTNET

A priori deve essere stabilito, assegnato e implementato il ruolo di master

La rete deve essere quindi dedicata, non è possibile miscelare diverse reti

La rete è quindi dedicata a messaggi RT

La trasmissione di messaggi non real-time avviene incapsulandoli in messaggi RT

L’header MAC è molto semplice e contiene solo le informazioni essenziali

Tipo di pacchetto

Il pacchetto realizza un tunnelling di messaggi non RT


RTNET – TDMA v2.1

Il protocollo TDMA usato prevede la sincronizzazione iniziale dei vari membri della rete mediante un pacchetto speciale Start Of Frame - SOF

Dopo il SOF, tutti i partecipanti calcolano il tempo che deve intercorrere prima del proprio time slot

La divisione in time slot, le loro durate e il loro assegnamento viene stabilito durante la fase di inizializzaione e resta immutata fino ad una nuova inizializzazione dell’intera rete

Se è previsto il tunnelling di dati non RT, si riservano un certo numero di time slot

Il numero di questi time slot viene stabilito in modo da rispettare tutte le richieste temporali dei nodi RT


RTNET – RTcfg

RTcfg è il protocollo che realizza la configurazione

di RTNET nella fase di inizializzazione della rete

Gli ultimi sviluppi, hanno introdotto in RTNet la

capacità di hot-plugging e quindi la configurabilità

dinamica dell’intera rete

In caso di guasto di un nodo, non è necessario far

ripartire il sistema

I messaggi di configurazione di RTcfg sono inviati da

un gestore centralizzato che rileva, gestisce e

segnala ogni situazione particolare, comprese le fasi

iniziali


Rether

Rether – Realtime ETHERnet – si propone di gestire il

problema delle collisioni mediante un meccanismo

di token, che viene passato tra le varie stazioni

della rete

In questo modo, Rether può garantire una certa

banda a ciascuna stazione

Il protocollo si propone di essere assolutamente

trasparente verso il software di alto livello

Il protocollo è integrato nei driver di accesso allo

hardware ethernet standard

Garantisce la compatibilità con i protocolli UDP, TCP

e RTP


Rether

Vengono fornite una serie di primitive (API) che permette l’utilizzo da parte degli applicativi utente delle caratteristiche real-time

Le applicazioni non real-time sfrutteranno la parte di banda non occupata dalle applicazioni real-time

Il protocollo ha la possibilità di cambiare la propria modalità di funzionamento da token a CSMA/CD quando non sono presenti comunicazione RT

Ovviamente, tutte le stazioni presenti nella rete devono avere dei driver che supportano Rether

La rete viene idealmente suddivisa in nodi RT (real-time) e nodi NRT (non real-time)

I nodi non corrispondono necessariamente a nodi fisiciamente separati

I nodi RT possono mandare un messaggio in broadcast che richiede il passaggio alla modalità di funzionamento a token, ovvero real-time


Rether – modalità RT

I nodi real-time sono numerati in sequenza

Il primo nodo della sequenza genera il token di

trasmissione RT

Il protocollo stabilisce due tempi:

Tempo di token: tempo durante il quale un nodo può

trattenere il token

Tempo totale tra la creazione e la distruzione del

token

Questi tempi sono generati per garantire

La banda richiesta da ciascuna stazione

I tempi di risposta richiesti



Il nodo RT che detiene il token

Se deve trasmettere, effettua la trasmissione per una durata massima pari al tempo di token, passando poi il token al nodo RT successivo nella sequenza di numerazione

Se non deve trasmettere, il nodo RT passa subito il token al nodo RT successivo nella sequenza di numerazione

Il passaggio dei token avviene in questo modo fino al raggiungimento dell’ultimo nodo RT

L’ultimo nodo RT inoltre il token al primo nodo NRT

Il token è contrassegnato da un suo tempo di validità, entro il quale le trasmissioni NRT devono essere terminate



Il token viene fatto girare tra le varie stazioni NRT

fino allo scadere del suo tempo di validità o al

raggiungimento dell’ultimo nodo NRT

Se una stazione NRT non riesce a concludere la

trasmissione entro il tempo di validità del token,

sarà la prima a ricevere il token nel round

successivo

Le sezioni del protocollo più complesse riguardano

Inizializzazione dei tempi

Variazione dei tempi


Rether – inizializzazione

Quando un nodo RT ha terminato la propria

trasmissione, invia in broadcast un messaggio di fine

RT

Quando tutti i nodi RT hanno terminato la

trasmissione, la rete torna in modalità CSMA/CD

Il meccanismo si basa sul fatto che tutti i nodi

dispongono di una lista dei nodi RT, che mantengono

aggiornata ad ogni ricezione dei messaggi di

broadcast di fine RT


Rether – inizializzazione

Quando la rete si trova in modalità standard, il

messaggio di switch-to-RT viene gestito in CSMA/CD

I token inizia a girare e quando i nodi RT lo

ricevono, stabiliscono quanta banda riservarsi

comunicandola in broadcast

Se un nodo NRT necessita di trasmissione RT, lo può

annunciare in broadcast quando riceve il token

Ogni nodo, nel riservarsi la banda, esegue dei test di

ammissibilità

Se la banda non è sufficiente, la richiesta di

trasmissione RT fallisce


Bibliografia

M. Inzaghi, “Protocolli e reti Real-Time”, dispensa

per il corso di Sistemi Embedded, AA 2004/2005

http://www.kvaser.de

http://www.can-cia.org

http://www.ee.ualberta.ca/archive/vmefaq.html

http://www.byteflight.com

http://www.tttech.com

http://www.ttpforum.org

http://www.rts.uni.hannover.de/rtnet

http://www.ecsl.cs.sunysb.edu/tr.TR6.ps.Z

http://canfestival.sourceforge.net

http://www.kvaser.de/

http://www.can-cia.org/



http://www.ee.ualberta.ca/archive/vmefaq.html

http://www.byteflight.com/

http://www.tttech.com/

http://www.ttpforum.org/

http://www.rts.uni.hannover.de/rtnet

http://www.ecsl.cs.sunysb.edu/tr.TR6.ps.Z

http://canfestival.sourceforge.net/

Embedded Systems: Communication - Intranet...

Documents

Transcript of Embedded Systems: Communication - Intranet...