è possibile utilizzare due can bus transceiver "back-to-back"? Ad esempio, prendendo due di questi:
formatting link
E collegando l'RXD di uno con il TXD dell'altro e viceversa. Mi serve per realizzare dei segmenti di can bus isolati tra loro così che un guasto su una linea non mi inchiodi tutta la rete.
Per questo motivo non mi basta isolare a livello digitale la comunicazione tra il micro e il transceiver, in quanto la rete viene creata dopo, a livello di CANL e CANH.
Per cui pensavo di inserire questi segmenti isolati subito dopo aver creato la rete, di tipo stella.
Direi di no. Quando su uno dei due lati un dispositivo forza un bit dominante, i due transceiver si trasformeranno in una specie di "flip-flop" e forzeranno lo stato dominante per sempre da entrambe le parti.
Fra l'altro non funzionerebbe comunque, perché se da una parte un sensore impazzisce e forza uno stato dominante per sempre, anche l'altra rete sarebbe tenuta dominante per sempre.
Devi mettere due controller CAN che si girano i messaggi fra loro e capiscono intelligentemente quando uno dei due bus è in fail.
scusate se mi intrometto qui, ho una domanda a proposito di CAN Bus: oltre CAN_H e CAN_L, e' obbligatorio e/o necessario collegare anche il GND ? secondo voi, in una rete dove una trentina di nodi hanno i 3 segnali collegati tra loro, mentre altri 4 nodi usano solo CAN_H e CAN_L, come e' possibile che i tutto funzioni regolarmente ? considerate anche che lo stadio con il driver can e' galvanicamente isolato in ogni nodo, ossia non ci sono altri percorsi per il GND, oltre al cavo del bus.
mumble, non lo vedo. Vediamo dove sbaglio. Il nostro ipotetico circuito è formato da un segmento CAN a sinistra, i due transceiver incrociati al centro e un altro segmento CAN a destra.
Se sul segmento di sinistra c'è un bit dominante, l'RXD del primo transceiver sarà 0. Questo è collegato al TXD del secondo che quindi forzerà a sua volta un bit dominante sul CAN di destra.
E fin qui ci siamo, abbiamo ripetuto lo stato del bus.
Quello che non capisco è perché questo stato viene forzato *per sempre*. Io mi aspetto che quando sul bus a sinistra il bit diventa recessivo, i due transceiver ripetono tale bit sul bus di destra e lo stesso a parti invertite.
Cosa sto trascurando?
Nel nostro caso la "protezione" è meramente fisica. Cioè ci interessa proteggere elettricamente il resto della rete nel caso di sovratensioni che possano distruggere un segmento. Per questo cercavo i transceiver optoisolati.
Questa era la prima proposta che avevo fatto. Ma dal momento che sarebbero almeno 8 i segmenti da isolare si voleva cercare di ridurre i costi. Visto che però si tratta di poche unità mi sa che è comunque la strada migliore.
In pratica mi potrebbe bastare un micro generico con due seriali e due transceiver isolati esterni.
Aspetta forse ho capito. Quando il bit dominante viene ripetuto sul bus di destra, questo viene letto e forzato anche sul bus di sinistra (che era già in questo stato).
Se ora il device a sinistra volesse trasmettere un bit recessivo non verrebbe visto sul bus perché abbiamo il transceiver di destra che continua a forzare un bit dominante.
Funziona senza massa per lo stesso motivo per cui funziona ethernet senza massa: essendo galvanicamente isolato, ogni transceiver "adatta" i segnali al suo potenziale di riferimento.
Stai trascurando il fatto che i transceiver CAN (esattamente come quelli RS485) "riportano" in ingresso il bit che trasmettono. Quindi quando il secondo transceiver forza il bit dominante sulla CAN di destra, riceverà anche tale bit e il suo RXD andrà a zero, e quindi anche il TXD del primo transceiver. Ed ecco che si è formato un latch!
Nel momento in cui ci metti un micro io ne metterei uno con due controller CAN. Anzi, con tre (vedi ad esempio gli Stellaris), così con un solo nodo isoli tre linee.
ma ethernet usa nativamente 2 fili per canale (td+/td- oppure rd+/rd-) non e' contemplato il GND, e ha i trasformatori di disaccoppiamento, quindi non mi sembra un paragone corretto. il CAN usa 3 fili per definizione, o sbaglio ?
comunque, secondo te, collegare un nodo solo con CAN_H e CAN_L, lasciando GND staccato, non e' un errore ?
Si ci ero arrivato anche se in ritardo, come mio solito :) Vedi l'altro post.
In effetti vedo che micro con più di un CAN controller si trovano solo in fascia alta (ARM, dsPIC, AT32).
Vedrò cosa scegliere, gli stellaris mi stanno un po' antipatici :) Senza contare che la finestra di ricerca parametrica non funziona, almeno qui da me.
Qui funziona! Ad esempio mi risulta che lo Stellaris con 3 CAN che costa meno sia il LM3S8530 (10 euro su digikey per singole quantità). E siccome non erano contenti in questo prezzo ti danno anche una porta ethernet. :)
A meno che non esistano MCU con 3 CAN che costano meno (è probabile: guarderei prima di tutto Renesas e Freescale), questa è sicuramente la soluzione più economica: un controller CAN esterno almeno 2-3 euro li costa.
Ci sono due modi per alimentare la parte "esterna" di un transceiver CAN isolato. Il primo è che il dispositivo disponga di un DC/DC isolato che alimenta la parte esterna, il secondo è che la parte esterna venga alimentata da una tensione proveniente da fuori. Mentre nel secondo caso devi per forza collegare GND (se non altro perché è il "ritorno" della tua alimentazione esterna), nel primo non è strettamente necessario: siccome i pin CANH e CANL sono collegati tramite resistenze di pullup/pulldown al GND/VCC generato dal DC/DC, i livelli saranno automaticamente traslati ai potenziali presenti sul CAN bus.
Il protocollo CAN pero' dovrebbe garantire che in caso di guasto il transceiver vada in stato passivo, ma volendo segmentare la rete, questa soluzione non ti protegge: un transceiver guasto in stato dominante blocca comuque entrambe le linee..
Il che, in caso di guasto dell' hardware di centro stella, ti manda in fault tutti tuoi segmenti... Se usi un unico componente attivo (Micro) l'affidabilita' del tutto e' pari a quella del solo micro, anche avendo piu' controller CAN interni.
Mah! se quello che intendi realizzare è una rete ridondata allora tutti i nodi CAN dovrebbero disporre di due linee CAN indipendenti.
In ogni caso, ogni repeater introdotto sulla linea introduce un ritardo di cui va tenuto conto e quindi considerare anche il massimo bit-rate raggiungibile al netto dei ritardi di propagazione del segnale da un segmento bus all' altro. A.
Beh questo è ovvio, ma se salta l'hw di centro stella (lato master) non mi interessa più nulla dei vari segmenti. Il problema era l'opposto: se si inchioda / distrugge un segmento, gli altri 7 dovrebbero continuare a funzionare.
In realtà la specifica iniziale era relativa unicamente alla protezione elettrica. Se a causa di una scarica o sovratensione si guasta una delle
8 schede slave, le altre non devono risentirne. Poi abbiamo capito che occorre anche monitorare il bus affinché si possa isolare uno slave impazzito che tiene inchiodato il bus.
Per cui il "nodo" di centro stella sarà in realtà costituito da 8 doppi controller can (o 4 tripli). Mentre gli slave essendo punti terminali non necessitano di ulteriore segmentazione.
Bit-rate? Quello ritengo sia costante. Piuttosto saranno i pacchetti a essere ritardati del tempo necessario a riceverli e ritrasmetterli. Per cui dovrei semmai considerare il tempo di ciclo applicazione (domanda risposta) piuttosto che guardare il livello fisico. Sbaglio ancora?
Non bastavano i classici tranzorb sulla linea? Oppure lo stato di lavoro degli slave e' cosi' critico?
Mi pare un pochino ciccia... come soluzione per una rete CAN :-)
Poiche' il protocollo CAN prevede che tutti i nodi attivi diano conferma (ACK) del messaggio, e questo avviene in un ben determinato slot temporale del frame (vado a memoria: mi pare 2Tbit dopo la CRC), se indroduci dei ritardi sulla propagazione di un messaggio (ad es. opto lenti, repeater 'passivi' o cavi inadatti), si rischia che non funzioni nulla perche' alcuni o tutti i nodi daranno un ACK ritardato e quindi fuori dai tbit a disposizione. Ad 1Mbit, il tbit e' di 1us, quindi se hai ad esempio degli opto lenti che introducono 1us di delay, la rete a 1Mbit non funzionera' mai. Non e' il tuo caso, se usi un controller per ricevere un messaggio da un lato del bus e ritrasmetterlo su un altro lato :-) A parte il ritardo introdotto dal tempo di processing della CPU, perche' di fatto, a parte la capacita' della linea ed eventuali opto, non ci sono altri ritardi.
Più o meno, c'è un master e 8 slave. Per motivi di cablaggio tutti gli slave sono connessi direttamente al nodo del master.
Diciamo che potrebbe succedere che un 260 VDC possa cortocircuitarsi sulla linea del bus...
Non ho capito cosa intendi. Il can è necessario perché gli slave sono fatti così (non li ho fatti io). La segmentazione serve per quanto detto sopra.
Beh questo però non succede se metto in mezzo un micro che fa da bridge. Comunque la massima velocità prevista è di 115k. Probabilmente posso scendere ancora.
Appunto :)
Per isolare utilizzerei i citati iso1050 che con le velocità in gioco mi sembrano adatti.
Ciccia nel senso che controlli pochi slave per bus :-)
La butto li'... potresti optimizzare usando una sola CPU, che può essere il master stessp, e una piccola CPLD per collegare in 'parallelo' gli otto tranceiver di cui, di ogni canale, controlli un enable. Una volta determinato che il BUS non funziona, escludi un canale alla volta e determini quale e' in fault...
Curiosità: tu o qualcuno che utiilzza gli Stellaris mi riassume la situazione attuale circa l'ambiente di sviluppo? Ai tempi dei Luminary c'era una discreta confusione, ora come stanno le cose?
Credo che ormai anche l'ambiente di TI sia relativamente consolidato, ma personalmente trovo IAR imbattibile. Per la connessione al target ho sia un J-LINK (che è l'emulatore consigliato da IAR, costicchia) sia un kit di sviluppo a basso costo - hai presente quello con Ethernet e il display OLED? - che puoi anche usare come emulatore JTAG. IAR lo chiama "LMI FTDI" o qualcosa del genere.
Ma siccome parlavi di confusione (che non mi risulta esserci mai stata con IAR, supportato perfettamente sin dai tempi di Luminary) immagino che ti riferissi ai tool open; in tal caso non so aiutarti. Se usi gli ambienti di sviluppo free in quanto "free as speech", hai tutta la mia ammirazione; se invece li usi in quanto "free as beer", desisti. Come dice un vecchio detto salace, questi tool sono gratis solo se il tuo tempo non vale nulla. Se il tuo tempo vale qualcosa, allora vale sicuramente di più di qualche centinaio di euro di un ambiente di sviluppo commerciale.
Che è quello che uso io ;) Parlo della scheda di sviluppo per il 6965.
Esattamente. CodeSourcery, Eclipse, Zylin ecc...
Beh non sempre è così. Per esempio per gli Atmel AVRStudio e winAVR non sono poi così malvagi.
Gli IDE che avevo visto non costavano certo qualche centinaio di euro. Ora verifico di nuovo. Comunque avevo provato anche qualche demo di questi prodotti commerciali ma avevano un sacco di problemi, soprattutto per quanto riguarda la programmazione e il debug in system.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.