Non ho trovato soluzioni online, per cui chiedo qua se qualcuno ha risolto la questione di come usare la seconda UART (la prima interferisce sul caricamento e quindi bisogna scollegarla ogni volta che si compila).
Dal datasheet di Esp-wroom (che è quello utilizzato) i IO 16 e 17 sono quelli dedicati alla UART 2, però in questo modulo vedo solo un collegamento sulla porta che sul mio PCB è siglata P5(ma in altri fogli elettronici vedo che la chiamano P1 o J1) che riguarda la UART 1
Dalla foto che aggiungo qua sotto non si caposce dove vanno a finire le piste della UART 2, visto che sembra che vadano dall'altra parte del PCB che è coperta dal display (o forse non sono proprio collegate?)...cosa capite da questa immagine? (siglate con R16 e R17)
Su un ESP32 i pin UART sono liberamente assegnabili e sì, i pin predefiniti per UART2 sono 16 e 17. Non ho idea di quale immagine stai mostrando nella terza immagine, ma comunque puoi assegnare qualsiasi pin disponibile all'UART usando (google translate)
Serial.begin(BAUD, CONFIG, RX, TX); // or Serial2.begin() , CONFIG is typically 'SERIAL_8N1'
La terza immagine mostra le saldature del Wroom sullo stampato e immagino che quei buchi su R16 e R17 sono passanti e quindi questi 2 GPIO sono utilizzati per altri scopi che, dalle prime 2 immagini non si capisce dove vadano a finire, nè tantomeno si può vedere dall'altra parte dello stampato perchè sono coperti dal display.
Questi 2 pin non hanno una traccia che li porta da qualche parte (perlomeno guardando questo lato).
Si potrebbe saldare direttamente 2 cavetti e vedere se mandando comandi alla UART 2 vengono visti da un oscilloscopio.
Oppure prima di fare saldature, vedere se per caso sono stati inviati ance loro all'uscita della UART 1 (cosa che mi pare improbabile).
Purtroppo questi 2 pin e anche altri (visto che dovrò attacargli anche un GPS) nelle prime 2 immagini fornite dalla casa non si capisce dove siano collegati.
Il convertitore da USB a TTL avrà un effetto sul pin RX in particolare impedendo il normale utilizzo di quel pin. Ma come affermato prima puoi praticamente assegnare 2 pin qualsiasi a qualsiasi UART senza interferire comunque con il caricamento (in effetti i pin predefiniti per UART1 di solito non sono utilizzabili poiché sono anche collegati al flash sulla maggior parte delle schede)
Ok...però devo anche collegare un GPS per cui altri 3 pin se ben ricordo.
Secondo me in questa versione yellow hanno lesinato sui connettori e quindi su possibili espansioni.
Diciamo che è meno configurabile rispetto a un normale ESP32 con display separato, l'unica cosa positiva è la presenza del lettore di SD che con le traccie così corte dà meno problemi rispetto alle SD utilizzate, e il display già collegato è un altro lato positivo
Il problema è che sta usando una scheda che non espone molti pin liberamente utilizzabili, per questo avevo consigliato OTA in modo da rendere pienamente utilizzabile anche UART0
Non è così, i pin disponibili sono utilizzati quasi tutti per le altre periferiche già a bordo.
Flash, SD, fotoresistore, Display, Touch, Led RGB etc etc
Naaaa....OTA no....muhahahah
Il problema del flash l'avevo superato già con uno switch che escludeva la UART0 quando dovevo uppare lo sketch, però in fase di programmazione risulta utile anche il serial monitor che se utilizzi UART0 non hai
Io non intendo ArduinoOTA che funziona una volta su tre. Nel core ESP32 per Arduino ci sono già un paio di esempi già pronti e vanno alla grande.
Ad ogni modo se non è un'opzione che ti piace, puoi comunque valutare altre strade e mantenere questo modulo che senza dubbio è molto comodo.
Ad esempio la presenza del connettore P3 ti lascia ampie possibilità utilizzando dei moduli i2c.
Sì diciamo che è una soluzione che può risultare comoda per alcune soluzioni, ma scomoda per altre, in quanto lascia pochi pin disponibili e configurabili.
Le schede SD ad esempio cerco di evitarle e preferisco usare SPIFF
E in genere basta una SPIFF ridotta, 3 di ram per il programma e 0 OTA
Attualmente sto considerando la connessione UART a un ODB2 della macchina e quindi i 3 MB per il programma e 1 MB SPIFF (escludendo quindi BluetoothSerial.h che occupa un botto di ram) e usando elmduino library che offrono già una buona decodifica dei messaggi in arrivo da ODB2.
Il GPS mi serve essenzialmente per sincronizzare l'ora e come altimetro.
E probabilmente utilizzerò quindi unESP32 classico con il suo Touch 3,5 pollici
Con il quale avevo già fatto questa applicazione: https://forum.lvgl.io/t/a-precision-table-clock-with-wind-advisor/8304
Quello è già collegato a GPIO 16 e 17, che sono i pin predefiniti per UART2 e il LED sembra essere attivo BASSO. Se non usi il LED e non avvii l'UART, dovresti essere in grado di usare UART 2
Questi sono i pin che puoi assegnare anche a un UART, tieni presente che puoi alternare le impostazioni se vuoi usarlo per qualcos'altro, anche durante il corso del programma
Hai ragione, i pin dell'UART2 vanno al led che sinceramente messo qua dietro non mi interessa.
Metto un'immagine presa da + lontano e si vede che IO 16 e 17 non sono quelli contrassegnati con R16 e R17 ma sono + a sinistra e vanno al led (che sinceramente potevano evitare di mettere)
Per cui penso proprio di usare un classico ESP32 con touch 3,5 , usare la UART2 per il modulo OBD2 e collegare UART1 al GPS (NEO-6M With Antenna) quando il programma è in fase finale
Come base uso questa (per Arduino Nano) tagliata in due per adattarla a ESP32, che con le viti offre una connessione migliore che non i Dupont
CMQ si potrebbe anche dissaldare il led e utilizzare il pin 16 e 17 per la UART2 mettendogli un connettore coi 3 pin tx rx e gnd.
Stamane ho misurato i volt sul connettore seriale dell' OBD2 e mi dà 3,4 V che và benissimo anche per la seriale di ESP32 senza bisogno di metter il partitore di tensione
Lo spazio per saldare è proprio minimo se lasci il led, inoltre, visto che la seriale del mio ODBII lavora a 3,4V è meglio tenere le cose separate.
Di basette ne avevo già per Aduino Nano e col flessibile ci si mette un attimo a tagliarle
