µC + 2x MCP2515 per filtraggio

Ciao!

Sto pensando un po' e non riesco a capire.

Ho acquistato una scheda STM32 (o Nucleo F303K8)) e ho collegato due chip MCP2515 a questa. Finora, l'invio e la ricezione funzionano perfettamente.

Quello che vorrei realizzare, in realtà, è collegare un'unità centrale (headunit) a un chip MCP2515 e il display associato all'altro. Ciò che uno riceve, l'altro lo trasmette, e viceversa.
Vorrei, da un lato, capire da quale dispositivo provengono le diverse notifiche e, dall'altro, poter filtrare le notifiche in base a specifiche identificazioni. Questa è la teoria. In linea di principio, questo sistema funziona già, MA: non appena un gran numero di dati arriva in rapida successione (ad esempio, quando si apre un menu complesso), i messaggi vengono persi e, ovviamente, l'apertura del menu fallisce.
Sembra proprio che non riesca a recuperare i dati dal buffer di ricezione (RX) abbastanza velocemente. Non importa cosa provi a fare (ho creato un buffer di trasmissione (TX) separato, ho dato priorità più alta alla ricezione, ho disabilitato l'output seriale, ecc.), niente sembra funzionare. Funziona in modo così inaffidabile .

Prima di continuare a cercare di ottimizzare ogni minimo dettaglio per far funzionare il tutto: il mio progetto è davvero realizzabile? Quello che sto facendo ora per me sarebbe solo un "plus", e non è necessario che funzioni al 100%, ma pensavo che potesse semplificarmi le azioni future, se riuscissi a filtrare in modo efficace i dati rilevanti per il dispositivo di destinazione. Idee?

Saluti.
Sven.

Hai collegato i pin di interrupt del MCP2515 a ciascuno dei pin di ingresso dello STM?
Ogni MPC segnala, tramite questo meccanismo, lo stato del buffer dal punto di vista dell'hardware.
Non ho perso nemmeno un singolo fotogramma.

Ciao,

Quello che intendi fare, il mio dispositivo FIS Blocker lo fa allo stesso modo: si inserisce tra (nel mio caso) la radio e l'unità di controllo del veicolo nel bus CAN dell'infotainment. È basato su un STM32F4, che ha 2 interfacce CAN integrate. Quindi, ci si evita tutta quella complicata procedura SPI.

Non ho mai avuto problemi di frame drop. Il microcontrollore STM32 funziona a 186 MHz e le interfacce CAN vengono interrogate tramite interrupt.

Utilizzi polling, istruzioni di attesa o, eventualmente, output seriali inutilmente lenti?
Dai un'occhiata a una scheda di sviluppo STMF4.

Lo STM32 è effettivamente abbastanza veloce, in modo che, con una programmazione adeguata, non dovrebbero andare perse nessuna informazione.

Credo di aver trovato il problema ieri sera, tardi. Probabilmente non si trattava di un problema software, ma di un problema di contatto tra un transceiver e il suo MCP2515... insomma, un problema di connessione su una breadboard . Osserverò la situazione.

Ho riscontrato, tramite un analizzatore Saelae Logic, che in un momento casuale c'era un'attività anomala sul bus SPI, ma non ricevevo nuovi interrupt dal dispositivo MCP. Questo suggeriva che il mio microcontrollore richiedeva ripetutamente spazio libero nei buffer di trasmissione, ma sembrava che nessuno fosse disponibile.

Ma grazie per i suggerimenti .

La breadboard è così spesso il problema.

Ecco una traduzione:

"Solo un consiglio: dai un'occhiata al Teensy 3.6, è compatibile con Arduino, ha 2 interfacce CAN, uno slot SD, è piccolo e molto, molto veloce. Basta collegare due transceiver CAN da 3.3V e caricare i programmi per il supporto dual CAN." È difficile trovare un modo più semplice.

Il Nucleo ha anche un'interfaccia CAN, ma non mi è del tutto chiaro come gestire la temporizzazione in questo caso. Ho bisogno di un cavo molto particolare per il sistema di infotainment dell'Opel, precisamente con una velocità di 95,238 kbps.