Ma la linea can non ha un clock Sono solo 2 fili...
Buh, dovrei studiarmela un po...

per clock di trasmissione non intendevo un clock fisico, era riferito alla cadenza con cui una ecu mette a disposizione le informazioni.
Col sistema delle priorità funzionano anche altri bus, da cui la bosch ha preso iniziativa, perfezionando il tutto

Eppure leggendo l'articolo postato da vitoos, c'e' scritto:
"La struttura della rete è del tipo MultiMaster-MultiSlave, cioe' composta da nodi master, in grado di trasmettere e di ricevere dati, e nodi slave destinati a ricevere dati e trasmetterli solo su richiesta del master"
"La struttura è generalmente semplificata con l'adozione di un unico nodo master"

si, perchè ripeto, si parla di diagnosi, in questo caso è definito un protocollo di comunicazione KW2000 che permette al tester di fare domande e ricevere risposta dalle ecu interrogate (quando funziona tutto bene ) ...

Ed i protocolli come coesistono sulla stessa rete senza cozzare I messaggi del tester devono avere lo stesso layer 1, poi il payload ovviamente puo' essere diverso...

Qua ne parlano un po in dettaglio...
http://en.wikipedia.org/wiki/CAN_bus

I protocolli di comunicazione sono standardizzati perciò basta leggersi le specifiche. Quello che non conosciamo sono i protocolli a più alto livello.
Il clock si recupera facilmente, per esempio con un pll. La gestione di accesso al mezzo si fa lo stesso e con ottimi risultati soprattutto con così pochi nodi.

Secondo me, si prende un micro che integra nativamente il protocollo can, lo si usa come sniffer poi bisogna riuscire a capire come vengono incapsulate le informazioni.

c'è solo un tester e tante ecu, o almeno, potrebbero essercene uno per ecu ma non ha molto senso.
Dico questo perchè il tester si presenta sulla rete con un indirizzo diverso per ogni ecu interrogata
Esempio di diagnosi con indirizzamento a 11 bit per ecu motore -> indirizzo tester 0x7B, indirizzo motore 0x7A
se invece deve parlare con la ecu abs -> indirizzo tester 0x7D, indirizzo motore 0x7C
In pratica il tester manda la domanda con l'indirizzo 0x7B, la ecu motore sentendo quell'indirizzo, sa che la trama è riferita a lei e risponde con l'indirizzo 0x7A.
Sono 2 cose ben distinte le trame di diagnosi (indirizzi da 0x700 a 0x7FF) con le trame di dato (da 0x000 a 0x6FF).
Di uguale hanno soltanto il protocollo basso livello (CAN), indirizzo + 8 byte di dato. La diagnosi ha un protocollo di alto livello, i dati no.

Il clock sulla rete si 'auto sintonizza' in base alla velocita' della rete stessa. Penso che il primo che spara un broadcast detti la velocita' e gli altri is adattino. Ma come fanno ad evitare un drift della frequenza col tempo? ci sono risincronizzazioni?
Mettiamo che l'id 0 (il piu' importante) spara il primo messaggio a 10khz, il dispositivo che manda il messaggio dopo (secondo la priorita' di id) centra il clock, aspetta 6 cicli dopo la fine del primo messaggio, poi trasmette col clock del master. Ammettiamo a questo punto che il master voglia ritrasmettere dopo i 6 cicli di clock, cosa deve fare, risincronizzarsi sul segnale dell'ultimo dispositivo che ha trasmesso? Questo con l'andare del tempo credo che senza accorgimenti di risincronizzaizone crei un drift di frequenza.

Ci sono PLL che in pochi baud si agganciano con una precisione dell'ordine delle parti per milione. La frequenza ovviamente è fissa, ci si aggancia per compensare i drift.