sfondo

Sto sviluppando un progetto che richiederà le modeste specifiche del microcontrollore di:

• 8 ADC a 12 bit, 10 kHz
• 1kB di RAM
• 48-QFN o ingombro ridotto
• Protocollo di comunicazione resistente al rumore e agli errori daisy chain a 20 kbps

I requisiti di elaborazione del segnale sono piuttosto bassi e la maggior parte può essere esportata nel processore principale del sistema. Le prime tre specifiche sono facili da soddisfare e possono essere eseguite per meno di $ 2 in quantità. Tuttavia, la comunicazione avverrà in un ambiente molto elettricamente rumoroso, quindi le reti vulnerabili al rumore come LIN e I2C sono fuori. Un ulteriore argomento contro LIN è che mi piacerebbe far funzionare il tutto a 5 V o 3,3 V e che i ricetrasmettitori LIN richiedano 12 V e quindi richiederebbero un regolatore o un filo extra per ogni scheda sensore. Inizialmente ho scelto CAN per questo compito. Tuttavia, i controller CAN aggiungono costi considerevoli e sono curioso di sapere se ciò può essere fatto nel software.

CAN Livello fisico

La specifica CAN definisce i livelli Data Link e Physical del modello di riferimento della rete OSI. Per implementare il livello fisico esistono molti circuiti integrati a 8 pin economici, come NXP TJA1040 / 50 , Maxim MAX3058 / 59 , Microchip MCP2551 e TI SN65HVD1050 . L'implementazione del livello fisico con convertitori D / A o amplificatori operazionali sarebbe difficile, se non impossibile, quindi questi circuiti integrati valgono $ 1 o meno e costano.

CAN Data Link / Protocol Layer

Per il livello Data Link, alcuni microcontrollori aggiungono i moduli del protocollo CAN ai livelli di comunicazione UART, I2C e SPI di base. Tuttavia, questi sono significativamente più costosi dei chip di base.

Studio del costo dei moduli del protocollo CAN

A sostegno di questa affermazione, ecco alcuni micro popolari nelle versioni CAN e non CAN, dal:

• ATmega16 - ATMEGA16M1 (con CAN): $ 3,87, ATMEGA168A (senza CAN): $ 3,23
• dsPIC - DSPIC33FJ64MC802 (con CAN): $ 6,14, DSPIC33FJ64GP202 (no CAN): $ 5,48
• PIC18 - PIC18F2480 (con CAN): $ 6,80, PIC18F24J10 (senza CAN): $ 2,10
• Cortex-M3 - STM32F103C4T6A (con CAN): $ 6,50, STM32F100C4T6B (no CAN): $ 2,73

Per essere onesti, ho confrontato solo microcontrollori con dimensioni di memoria equivalenti, tuttavia, molte delle versioni non CAN sono disponibili con dimensioni di memoria inferiori a un prezzo inferiore. I controller CAN esterni, come il Microchip MCP2515 , costano quasi $ 2, quindi è ovviamente più conveniente avere la CAN integrata nel microcontrollore se ne hai l'opzione.

È interessante notare che la parte ATmega è di gran lunga la parte equipaggiata con CAN più economica nell'inventario di Digikey.

Funzione del livello del protocollo CAN

Il modulo CAN presente nei microcontrollori dsPIC procede come segue:

Il modulo CAN bus è costituito da un motore di protocollo e da buffering / controllo dei messaggi. Il motore del protocollo CAN gestisce tutte le funzioni per la ricezione e la trasmissione di messaggi sul bus CAN. I messaggi vengono trasmessi caricando prima i registri dati appropriati. Lo stato e gli errori possono essere verificati leggendo i registri appropriati. Qualsiasi messaggio rilevato sul bus CAN viene verificato per errori e quindi confrontato con i filtri per vedere se deve essere ricevuto e memorizzato in uno dei registri di ricezione.

Questo sembra abbastanza fattibile nel software.

La domanda

È possibile utilizzare un livello di protocollo software per implementare le specifiche CAN solo con un microcontrollore UART economico e un ricetrasmettitore CAN? In tal caso, esistono implementazioni open source?

In alternativa, i ricetrasmettitori CAN possono essere utilizzati con UART per implementare un protocollo personalizzato? Sto bene con una topologia a master singolo; Capisco che l'arbitrato può essere difficile da ottenere in un protocollo personalizzato.

Penso che implementare il protocollo CAN solo nel firmware sarà difficile e ci vorrà un po 'per ottenere il giusto. Non è una buona idea

Tuttavia, i tuoi prezzi sono alti. Ho appena controllato e un dsPIC 33FJ64GP802 nel pacchetto QFN vende per 3,68 USD su microchipdirect per 1000 pezzi. Il prezzo sarà inferiore per i volumi di produzione reali.

La periferica CAN hardware fa alcune cose reali per te e l'incremento del prezzo non è affatto vicino a quello che stai rivendicando.

Inserito il:

Dato che sembri determinato a provare il percorso del firmware, ecco alcuni degli ovvi problemi che vengono in mente. Molto probabilmente ci saranno altri problemi che non mi sono ancora accaduti.

Vuoi fare CAN a 20 kbit / s. Questa è una velocità molto lenta per CAN, che sale a 1 Mbit / s per almeno 10s di metri. Per darti un punto dati, lo standard di segnalazione a bordo della nave NMEA 2000 è layerd su CAN a 200 kbit / s, e ciò significa che va da un'estremità all'altra di una nave di grandi dimensioni.

Potresti pensare che tutto ciò di cui hai bisogno sia un interrupt per bit e puoi fare tutto ciò di cui hai bisogno in quell'interrupt. Non funzionerà perché ci sono diverse cose che succedono in ogni bit di CAN. Due cose in particolare devono essere fatte a livello di sub-bit. Il primo sta rilevando una collisione e il secondo sta regolando la velocità in bit al volo.

Esistono due stati di segnalazione su un bus CAN, recessivi e dominanti. La recessiva è ciò che accade quando nulla guida l'autobus. Entrambe le linee sono unite da un totale di 60 Ω. Un normale bus CAN implementato da chip comuni come l'MCP2551 dovrebbe avere terminatori da 120 Ω su entrambe le estremità, quindi un totale di 60 Ω che tira passivamente le due linee differenziali. Lo stato dominante è quando entrambe le linee sono attivamente separate, da qualche parte a circa 900 mV dallo stato recessivo, se ricordo bene. Fondamentalmente, questo è come un bus open collector, tranne per il fatto che è implementato con una coppia differenziale. Il bus è in stato recessivo se CANH-CANL <900mV e dominante quando CANH-CANL> 900mV. Lo stato dominante segnala 0 e il recessivo 1.

Ogni volta che un nodo "scrive" un 1 sul bus (lascialo andare), controlla se qualche altro nodo sta scrivendo uno 0. Quando trovi il bus nello stato dominante (0) quando pensi che stai inviando e il il bit corrente che stai inviando è un 1, quindi significa che anche qualcun altro sta inviando. Le collisioni contano solo quando i due mittenti non sono d'accordo e la regola è che chi invia lo stato recessivo si arresta e interrompe il suo messaggio. Il nodo che invia lo stato dominante non sa nemmeno che sia successo. Ecco come funziona l'arbitrato su un bus CAN.

Le regole di arbitrato del bus CAN significano che devi guardare il bus a metà strada attraverso ogni bit che stai inviando come 1 per assicurarti che qualcun altro non stia inviando uno 0. Questo controllo di solito viene eseguito a circa 2/3 del modo nel bit ed è la limitazione fondamentale sulla lunghezza del bus CAN. Più è lento il bit rate, maggiore è il tempo per la propagazione del caso peggiore da un'estremità del bus all'altra, e quindi più lungo può essere il bus. Questo controllo deve essere eseguito ogni bit in cui si ritiene di possedere il bus e si sta inviando un bit.

Un altro problema è la regolazione della velocità in bit. Tutti i nodi su un bus devono concordare il bit rate, più da vicino che con RS-232. Per evitare che piccole differenze di clock si accumulino in errori significativi, ogni nodo deve essere in grado di fare un po 'più lungo o più corto del suo valore nominale. Nell'hardware, questo viene implementato eseguendo un clock da circa 9x a 20x più veloce della velocità in bit. I cicli di questo orologio veloce sono chiamati quanti del tempo. Ci sono modi per rilevare che l'inizio di nuovi bit sta vagando rispetto a dove pensi che dovrebbero essere. Le implementazioni hardware quindi aggiungono o saltano un po 'quanti quanti minuti in una nuova sincronizzazione. Esistono altri modi per implementarlo purché sia ​​possibile adattarsi a piccole differenze in fase tra i tempi di bit previsti e i tempi di bit misurati effettivi.

Ad ogni modo, questi meccanismi richiedono che varie cose vengano fatte in vari momenti entro un po '. Questo tipo di tempistiche diventerà molto complicato nel firmware o richiederà che il bus venga eseguito molto lentamente. Supponiamo che tu abbia implementato un sistema time quanti nel firmware a 20 kbit / s. Con un minimo di 9 quanti di tempo per bit, ciò richiederebbe un interrupt di 180 kHz. Questo è certamente possibile con qualcosa come un dsPIC 33F, ma consumerà una frazione significativa del processore. Alla frequenza di istruzione massima di 40 MHz, si ottengono 222 cicli di istruzione per interrupt. Non dovrebbe richiedere così tanto tempo per eseguire tutti i controlli, ma probabilmente 50-100 cicli, il che significa che il 25-50% del processore verrà utilizzato per CAN e che dovrà anticipare tutto ciò che è in esecuzione. Ciò impedisce a molte applicazioni di questi processori di eseguire spesso, come l'impulso mediante il controllo dell'impulso di un alimentatore a commutazione o driver del motore. La latenza del ciclo 50-100 su ogni altro interrupt sarebbe un punto fermo completo per molte delle cose che ho fatto con chip come questo.

Quindi spenderai i soldi per fare CAN in qualche modo. Se non nella periferica hardware dedicata destinata a tale scopo, quindi ottenere un processore più grande per gestire l'overhead del firmware significativo e quindi gestire l'imprevedibile e possibile latenza di interruzione di grandi dimensioni per tutto il resto.

Poi c'è l'ingegneria frontale. La periferica CAN funziona e basta. Dal tuo commento, sembra che il costo incrementale di questa periferica sia di $ 0,56. Mi sembra un vero affare. A meno che non si disponga di un prodotto di volume molto elevato, non è possibile recuperare i considerevoli tempi e spese necessari per implementare CAN solo nel firmware. Se i tuoi volumi sono così alti, i prezzi che abbiamo menzionato non sono comunque realistici e il differenziale per aggiungere l'hardware CAN sarà inferiore.

Davvero non vedo questo senso.

Usiamo il PIC18F25K80 . Sebbene non abbia un DSP, è ~ $ 2 in quantità. È quasi un sostituto diretto del PIC18F2480 di cui parli. Usiamo il compilatore CCS e il loro stack software per CAN che è probabilmente portato da Microchip. Funziona bene per tutto ciò di cui ho bisogno e provato.

Se sto leggendo bene, sembra che tu voglia bit-bash funzionalità CAN usando solo un UART e un firmware intelligente. Fidati di me, questo non funzionerà mai - suggerisco di leggere un buon testo sulla complessità di CAN o CANopen. Avrai eliminato tutti i risparmi che stai cercando andando lungo questo percorso.

Userei un microcontrollore con un modulo CAN e passerei i $ 2 in più, o hai pensato a un protocollo diverso compatibile con un UART, come Modbus su RS-485 ?

Sto anche pensando al protocollo CAN di bit-banging su un PIC µC, quindi per favore EricM, se lo hai fatto davvero, per favore rispondi e dì almeno, quale bitrate con quale frequenza core di PIC18F o DSPic hai. Grazie!

In generale: RS 485 sarebbe la soluzione al problema principale richiesto, ma sarebbe anche possibile utilizzare transceiver CAN- (o anche FlexRay) con comunicazioni UART non full duplex (punto 2 punto) come tutti quei protocolli utilizzare la codifica NRZ.

Ma in UART / V24 / RS232 il full duplex viene utilizzato principalmente senza pensarci in dettaglio, quindi forse dovrai mettere un po 'di cervello sulla superloop o sulla macchina di stato della tua applicazione ...

Ma torniamo al CAN-bitbanging: sto lavorando con CAN da molti anni e non ho mai visto un'implementazione di bitbanging, ma per quanto posso pensare, dovrebbe funzionare per bit-time fino a 100kBit con µC moderni come DSPic o ARM ecc. (con core a 80 MHz o superiore ...)

Almeno se si considera solo il read-back ... L'invio significherebbe un certo sovraccarico nella preparazione delle strutture bit in modo che non sia raggiungibile il 100% di bus bus, ma in CAN più del 65% è raro ...