Sto cercando di districarmi nel datasheet della RA4M1, e mi sono un po incartato, secondo quanto trovo nelle tabelle i pin del CANbus CTX0 e CRX0 corrispondono a P102 e P103 (pin 45 e 46), pero' anche a P401 e P402 (pin 2 e 3), ed anche a P109 e P110 (pin 34 e 35) ... presumo che uno possa scegliere quale usare, ma nella versione "nano", gli unici portati fuori, almeno secondo la pagina di Futura, sono P102 e P103, uno dei quali e' pero' uno dei 6 pin PWM, che mi servono tutti ... AAARGH ...
Mi sa che farei prima a crearmi lo stampato per la versione a 64pin, e portarmi fuori da solo tutto quello che potrebbe servire (tanto vista la scarsissima corrente disponibile per pin, dovrei comunque infilarci buffer a pioggia, risparmierei spazio, e vedo che la presa USB e' connessa direttamente senza altre interfacce, altra complicazione evitata)
Peccato, mi sarebbe piaciuto di piu usare la schedina pronta ... comunque avrei probabilmente dovuto impacchettare un sacco di roba in modi "creativi" (non e' che lo spazio abbondi, nel bussolotto dell'elettronica di un ROV)
Me la ricordo ... il problema piu grosso e' che le schede che vanno nel bussolotto stagno, hanno forma e dimensioni abbastanza inusuali ... queste, per essere precisi:
Le "anse" servono per fissarle a due barre filettate M8 mediante dadi e rondelle isolanti (non fori, cosi in caso di riparazione e' piu comodo sfilare solo quella da lavorare), che le tengono ferme tutte insieme ed impilate dentro il cilindro, che ha un diametro interno di circa 12cm o poco piu, i lati tagliati piatti servono per la circolazione dell'aria e per far passare alcuni cavi (ed inoltre cosi rimane nei 100x100mm, che non e' male), mentre altri cavi sono fascettati alle barre filettate passando nelleaperture delle anse.
La schedina che mi hai linkato (che in effetti costa quanto una MCU da brevi o rs) ci starebbe, su una di queste schede, e potrei montarla "alla rovescia", sfruttando anche lo spazio che rimarrebbe sotto per altri componenti ... devo studiarci su, grazie.
Ok, fra datasheet ed user manual, piu un po di scarsa documentazione della schedina, ritengo che la RA4M1 in formato demoboard sia probabilmente la soluzione migliore, sia come ingombri che come caratteristiche ... ho provato a crearla come componente ed a posizionarla, e resta abbastanza spazio per buffer vari, e nel frattempo ne ho ordinate un paio di quelle con gli I/O a 5V.
A questo proposito, suppongo che per la poca roba che viaggia a 3.3V dovro' mettere dei traslatori di livello, ma l'opposto sarebbe stato peggio, come ingombri.
> Guglielmo: mi sembra tu la stia gia usando, puoi per favore dirmi se il controller CANbus interno ha bisogno solo del transceiver (ad esempio TJA1050 o simile), oppure se serve metterci anche il controller ? (mi sembra di aver capito che dovrebbe bastare il transceiver, ma chiedere non fa male)
Poi se non riusciro' a programmarla, mi avrai sulla coscenza (scherzo )
Si, anche se parlano di un transceiver a 3.3V, mentre preferisco usare il piu possibile roba a 5V, come appunto il TJA o altri simili (di alcuni ne ho un paio a casa, avanzati dalla riparazione di interfacce CAN usate per programmare i carrelli elevatori, ma comunque il loro prezzo e' abbastanza basso) ... il resto devo ancora studiarmelo bene.
A proposito, dubbio che mi e' venuto, non e' che il CAN e' "bloccante" durante l'attesa dei dati come alcune interfacce seriali, vero ? ...
Questa mi era sfuggita ... usero' una LIR, cosi si ricarica con l'alimentazione quando sara' in uso ... anche se per ora sono ancora alle prime sezioni, nello specifico trovare un sistema che mi generi i PWM per i gruppi dei motori tutti proporzionali fra loro, dato che avevo previsto l'uso di 4 motori orizzontali agli angoli inclinati fra i 30 ed i 45 gradi, e due verticali in testa ed in coda ... poi quando arrivano le RA4M1 ed inizio a studiarci su, te ne accorgerai, dovresti riuscire a vedere la colonna di fumo del mio cervello fin dalla Svizzera
Non ho guardato l'implementazione della libreria CAN di Arduino UNO R4 ...
... purtroppo, non mi meraviglierebbe se lo fosse, vista la "qualità" delle librerie per R4
Guglielmo
P.S.: dando un occhiata velocissima vedo che usano degli interrupts e delle callback ... spero non sia bloccante, ma la devi provare.
In ambiente Arduino, io ho usato senza troppi sbattimenti questa libreria che non è nient'altro che un wrapper del driver originale ESP-IDF.
Ci sono altre librerie, ma dopo svariate prove, questa è quella con cui mi sono trovato meglio.
Per quanto riguarda il discorso del bloccante o meno, dipende tutto da come hanno implementato il software, ad ogni modo puoi sempre inserire la gestione della comunicazione in un task FreeRTOS dedicato (sia con ESP32 che con RA4M1).
... ed io è una vita che continuo a tenere corsi e webinar su FreeRTOS™ ... quand'è che partecipi ad uno di questi ed impari a sfruttarne tutte le potenzialità?
Il prossimo webinar è 22/23 Ottobre 2025 ... quando mi danno il codice sconto per chi segue il forum, metto il link
Mellon scrive che il consumo dipende molto da marca e modello.
Lui ha implementato la strategia di scrivere su una memoria I2C, tipo quella presente nel modulo rtc ds3231, e poi scaricare tutto nella SD quando si riempe.
Senza, al massimo scriverei ogni minuto altrimenti con intervalli più ampio.
Alla fine montano quasi tutte dei moduli Espressif ESP32, quindi non c'è molto altro da aggiungere a livello di elettronica ed in sostanza vanno tutte bene.
Visto che lo scopo mi pare di capire sia "per studio", io ti consiglio di prendere una dev-board ESP32-S3 con doppia porta USB cosi puoi sfruttare il debug hardware JTAG integrato anche con Arduino IDE.
