MCP2551 è un convertitore da UART a CAN?

Voglio fare uno sniffer CAN bus per 250 kbit / s usando il mio computer. Dopo alcune ricerche ho scoperto che MCP2551 è una sorta di regolatore del livello di tensione per lo strato fisico della CAN. Tenendo presente questo, mi chiedo se questa configurazione potrebbe funzionare. Voglio solo registrare i messaggi scambiati a scopo di test automatizzato, non far parte della comunicazione:

PC <-> USB-UART (forse CP2102, perché ne ho già uno) <-> MCP2551 <-> CAN bus

In caso contrario, che tipo di segnali devono entrare nell'MCP2551 per farmi parte del bus?

usb microchip can

— rnunes
fonte

Risposte:

Puoi farlo, ma quello che otterrai sul tuo bus CAN sarà UART usando i livelli di tensione CAN. È necessario fornire all'MCP2551 i messaggi del protocollo CAN se si desidera comunicare con i dispositivi CAN sul bus. Lo stesso per l'ascolto: i messaggi CAN sono così diversi dal formato UART che UART non saprà cosa farne. Avrai almeno errori di frame per tutto il tempo e non otterrai il contenuto del messaggio.
Questa immagine mostra la struttura di un messaggio CAN:

inserisci qui la descrizione dell'immagine

Ci sono molti microcontrollori in giro che hanno un'interfaccia CAN, senza il ricetrasmettitore. È per questi che è stato progettato l'MCP2551. In passato abbiamo usato NXP LPC2294, che ha 4 interfacce CAN. Ognuno di loro ha bisogno di un MCP2551 per connettersi a un bus CAN. I controller più recenti di NXP includono la famiglia LPC1800 , di cui tutti i membri supportano CAN.

— stevenvh
fonte

Ho completamente dimenticato i bit di avvio / arresto di UART e probabilmente alcune situazioni CAN "start / top bit". Probabilmente proverò a trovare una soluzione utilizzando uno stack CAN sul PC usando FTDI come gpio che finirà per trasmettere a MCP2551

— rnunes

@rnunes - Non sono solo i bit di avvio / arresto. Senza questi, una trasmissione UART è solo un byte a 8 bit. Un messaggio CAN è molto più complesso, con indirizzamento, priorità e controllo degli errori. Non puoi confrontare i due.

— Stevenvh,

Ma usando FTDI lavorerò poco a poco (in pratica, è un USB <-> GPIO molto veloce), non byte per byte come con UART. Sto già cercando quei MCU CAN, ma preferirei spendere soldi per ora (è un progetto di hobby per studenti) e ho già l'FTDI. Se concludo con le mie ricerche che l'FTDI non sarà in grado di farlo, proverò a utilizzare un MCU CAN.

— rnunes,

Lo stack sarà responsabile della gestione di tutto (ad es. Bit stuffing) e lo trasmetterà bit per bit a MCP2551. L'unico problema che sto riscontrando in questo momento è la latenza FTDI, perché ne ho bisogno per essere veloce e regolare, ma lo misurerò in seguito.

— rnunes,

@rnunes - Ma ciò che viene fuori dal CP2102 (SiLabs, non FTDI) sono byte , non bit. Non puoi fermarlo dopo un po '. Avrai bisogno sia del CP2102 di interfacciare il tuo microcontrollore con USB sia di un microcontrollore che supporti CAN + l'MCP2551. O un microcontrollore che può anche fungere da dispositivo USB. Quindi non è necessario il CP2102.

— Stevenvh,

Ho realizzato un'interfaccia USB / CAN utilizzando FT2232H in modalità MPSSE (dimentica UART), MCP2515 e MCP2551. MCP2515 è il pezzo chiave che ti manca qui. Studia bene cosa fa. È il controller CAN effettivo che esegue framing, ACK, generazione e verifica del checksum, filtro dei messaggi e altre cose meno ovvie che un nodo CAN è tenuto a fare dallo standard. Se si desidera uno sniffer, MCP2515 ha una modalità di solo ascolto che garantisce nessuna trasmissione sul bus. MCP2551 è semplicemente un adattatore di livello fisico stupido, simile a un MAX232 per RS-232 o ADM485 per RS-485.

Ora questa architettura è tutt'altro che perfetta in quanto la tecnologia FTDI MPSSE non ha sostanzialmente alcun supporto per gli interrupt (credo che utilizzi solo trasferimenti USB di massa dietro le quinte), quindi devo interrogare frequentemente il controller per nuovi messaggi. Ciò comporta un notevole carico sul controller host USB ma non garantisce che nessun messaggio venga perso (MCP2515 può memorizzare internamente fino a 2 messaggi ricevuti se si abilita la "modalità overflow", solo uno in caso contrario). Una soluzione di gran lunga migliore sarebbe un corretto microcontrollore con periferiche CAN e USB integrate come STM32F105 (103 non possono utilizzare USB e CAN contemporaneamente). Vedi questo progetto per un'implementazione funzionante esattamente di questa idea. LPC18xx come suggerito da Stevenh funzionerà anche, ma LPC17xx è probabilmente più economico e più facile da trovare.

— spina
fonte

In questo caso, il pooling non è un problema, ma sì, la soluzione ideale sarebbe usare un MCU con controller CAN che funzioni come buffer di messaggi CAN. Da ora proverò a utilizzare la prima configurazione che hai scritto. Grazie

— rnunes

+1 L'uso del chip FTDI per parlare direttamente con un controller CAN senza un uC è pulito. A parte ciò FTDI è uscito FT221X, che è un bridge dedicato da USB a SPI. (Esiste anche un modello diverso da USB a I2C.)

— Nick Alexeev

Dato che vuoi ascoltare un bus CAN esistente quando capisco la domanda, non puoi davvero usare un UART. I segnali CAN e UART sono totalmente diversi.

In teoria si potrebbe guardare la linea di ricezione CAN che esce dall'MCP2551 e decodificare il traffico CAN. Non sarà facile, ma è teoricamente possibile. Senza hardware CAN specializzato, dovrai campionare alcune volte più velocemente della velocità in bit CAN e decodificare quel flusso di bit nel software in seguito. Probabilmente dovrai registrare a circa 1 Mbit / s per decodificare CAN a 250 kbit / s.

L'uso di un microcontrollore sarà molto più semplice. Il PIC 18F2580 e altri processori simili hanno una periferica CAN integrata. L'hardware esegue tutta la decodifica a livello di bit e riceve interi frame CAN. Il processore può quindi inviare sul PC i frame CAN ricevuti tramite la sua UART.

— Olin Lathrop
fonte