Centralina per funzioni di illuminazione di fari controllati in rete

Ciao,

Sono nuovo/a qui e nel mondo del canottaggio.

Vorrei realizzare un sistema di controllo per i fari di un veicolo basato sulla piattaforma MQB di Volkswagen, in modo che le funzioni di illuminazione siano controllate in base ai messaggi CAN.
I fari secondari sono collegati al sistema di controllo dell'illuminazione (55).
Ho già installato sul tavolo un gateway (19), una centralina del sistema di bordo (09), un modulo di controllo dell'illuminazione (55), ho cablato gli interruttori sullo piantone dello sterzo e anche la struttura di base funziona.

L'idea di base è quella di installare l'unità di controllo degli abbaglianti come unico componente nell'altro veicolo, su una piattaforma PQ25, separatamente, e fornire le informazioni CAN necessarie tramite un Arduino o un STM32. Vorrei utilizzare i vecchi uscite del gruppo fari, che accendono e spengono le funzioni luminose, come segnali di ingresso per la mia elettronica aggiuntiva, e generare messaggi CAN per l'unità di controllo degli abbaglianti a partire da questi segnali.
Il problema è che, durante la configurazione delle luci, la protezione dei componenti è attiva, il che mantiene costantemente accesa la luce di posizione e impedisce l'attivazione degli abbaglianti, anche se le impostazioni degli interruttori e le funzioni luminose vengono correttamente rilevate nella diagnostica del sistema di regolazione automatica dei fari.
Considerando che il modulo 55 non ha protezione dei componenti e quindi non necessita di essere programmato, ipotizzo che venga trasmesso un segnale sul CAN indicante che la protezione dei componenti è attiva, e che per questo motivo il sistema non si sente ancora "a suo agio". Ho riscontrato lo stesso comportamento anche quando attivo l' LWR (luce regolabile in altezza) senza altri partecipanti al bus, inviando semplicemente un segnale "on" su Kl15 sul CAN.

Purtroppo, il mio adattatore RKS CAN non è ancora arrivato per collegarmi al bus, perché quando utilizzo un Arduino e can tool, si verificano numerosi problemi non appena mi connetto al veicolo e vengono perse molte comunicazioni a 1 Mbit/s.

Ecco quindi la mia domanda: qualcuno ha maggiori informazioni su quali dati specifici siano necessari ai partecipanti al bus CAN Extended per funzionare, oppure se un messaggio di questo tipo, come "protezione dei componenti" o simili, viene trasmesso sul bus?

Cordiali saluti.
Max.

È interessante notare che il mio adattatore RKS KCan è finalmente arrivato, e si è scoperto che si tratta effettivamente di un bus con una velocità di 500 kbit/s. Con l'Arduino, ho dovuto impostare sempre a 1 Mbit/s sia in can tool che durante la trasmissione con il MCP2515.

Ciao.

sline ha scritto:

È interessante notare che il mio RKS KCan è finalmente arrivato e si è scoperto che si tratta effettivamente di un bus con una velocità di 500 kbit/s. Con l'Arduino, ho dovuto impostare sempre 1 Mbit/s nel software CAN Tool, anche quando invio dati utilizzando l'MCP2515.

Purtroppo, per quanto riguarda la protezione dei componenti, non posso esserti di grande aiuto, perché in passato ho avuto poca esperienza in merito.

La tua discrepanza nei bitrate: per caso, l'oscillatore di quarzo del controller CAN è stato impostato in modo errato?

Non conosco il MCP2515, ma per l'MCP2518 si utilizzano 4 MHz con PLL, e 20 MHz e 40 MHz senza PLL. Immagino che sia simile anche per il chip precedente. Basta consultare la scheda tecnica; molto probabilmente la frequenza di clock è impostata in modo errato oppure è stato saldato un oscillatore diverso da quello previsto.

Cordiali saluti, Rainer.

CAN-Diagnose ha scritto:

La tua discrepanza nei bitrate: per caso, l'oscillatore di quarzo del controller CAN è stato impostato in modo errato?

Così è, non avevo impostato correttamente il tempo.

Ora ho caricato una traccia proveniente da un sistema CAN Extended di un T6.1. A questo punto, il faro sembra funzionare correttamente e riesco a controllare tutte le funzioni luminose.
La lista dei messaggi inviati è molto lunga e molti di essi contengono checksum o byte variabili, quindi devo trasmettere molte informazioni tramite l'Arduino per simulare il resto del bus e estrarre i messaggi necessari.

Come sta il progetto con Arduino? Il microcontrollore ATMega 328P è davvero adatto allo scopo? Ho la preoccupazione che lo spazio di memoria possa essere limitato. Per questo motivo, ho pensato che un STM32 con controller CAN integrato potrebbe essere una scelta migliore?

Max.

sline ha scritto:

E invece, cosa ne pensiamo dell'Arduino? Il microcontrollore ATMega 328P è davvero adatto a questo scopo? Ho la preoccupazione che lo spazio di memoria possa essere limitato. Per questo motivo, ho pensato che un STM32 con controller CAN integrato potrebbe essere una scelta migliore? Max

Ciao Max, il 328p è sicuramente adatto per questa applicazione. Ho realizzato un'interfaccia che acquisisce dati analogici del motore, calcola i dati di taratura e li invia alla rete marina NMEA2000. È stata implementata anche una gestione completa della rete, e c'è ancora spazio per altro.
Nuovi progetti li realizzo con il microcontrollore MEGA128DB48 (che offre maggiore memoria, RAM e porte di input/output, oltre a un convertitore analogico-digitale a 12 bit), mantenendo le stesse dimensioni dei componenti (7x7 mm).

Cordiali saluti, Sigi.

Sembra una buona soluzione. Ora che ho risolto anche il problema dei fari, sembra che l'intero progetto possa essere realizzato con un numero relativamente basso di ID sul CAN bus. In pratica, la lampada funziona come dovrebbe, anche senza centralina e gateway. Sto inviando direttamente al Can Extended.

Werde daher sowieso erstmal mit dem Arduino einen Prototyp bauen und das Fahrzeug mit den neuen Leuchten ausstatten um das ganze zu testen, dann ergeben sich sowieso die nächsten Probleme.

Max.