ElectroYou

Ciao Forum, credo sia il mio primo post del 2024 quindi con infinito ritardo buon anno a tutti.

Vorrei connettere alcuni arduini a uno di questi due "micro", per alleggerirgli una parte del carico. Sto pensando nello specifico a un campionamento di un segnale analogico, campionamento rapido quanto è possibile a un arduino, una serie di elaborazioni nello stesso arduino di lettura (es. media, mediana, dispersione, etc.) e a ulteriori ed eventuali elaborazioni nel ESP che si occuperebbe anche della comunicazione verso la LAN.

Tempo fa mi ero occupato di cercare qualcosa e scrivere qualche sketch di prova ma solo tra arduini. Credo che scelsi il RS485 ma ho cancellato i vecchi esperimenti. Ora ho "scoperto" che esistono gli ESP e questo cambia tutto, dato che costano una frazione di un arduino e hanno prestazioni globali imparagonabili e tutte a loro favore.

Una cosa che ricordo è che incontrai difficoltà per trasmettere lo zero che almeno in un protocollo di comunicazione segnala il fine buffer. Ma qualsiasi numero codificato in binario ha uno zero da qualche parte; girando in rete si consigliava di usare una print e trasmettere la sequenza ASCII, ma questo non è mai un sistema veloce. Suppongo sia meglio trasmettere direttamente il numero binario.

Prima che me lo diciate voi è ovvio che sto mescolando cose diverse e appunto, chiedo per fare ordine. Quello che vorrei è:

1) Implementazione senza ricorrere a funzionalità e costrutti esoterici tipo interrupt o simili. Mi accontenterei di poter trasmettere una sequenza di zeri e uno di lunghezza condivisa tra lato trasmissione e lato ricezione, in modo accessibile a un dilettante come sono; mi accontenterò della velocità permessa da una soluzione che io sia in grado di implementare.

2) Che possa connettere un master a diversi slave. Non mi serve una totale bidirezionalità ma mi basta che lo slave sia in ascolto e risponda a seconda del comando ricevuto.

3) Che si possa debuggare facilmente. Tra i miei confusi ricordi c'è quello che viene usata la seriale, e molti modelli di Arduino ne hanno solo una. RIcordo anche che comprai una specie di decoder e che con un software Pulseview potevo sniffare il traffico abbastanza facilmente. Ricordo bene? In questo caso potrei anche occupare il solo sistema di comunicazione che alcuni arduini hanno, dal momento che potrei intercettare il flusso dati in entrambe le direzioni; cercherei nei cassetti dove ho messo questo oggettino e potrei utilizzarlo.

Infine mi pare di ricordare che gli ESP emulano qualche funzionalità che in Arduino è nativa, se non sbaglio proprio la seriale, e che questo di fatto quasi allinea le prestazioni degli ESP a quelle di Arduino, beninteso in specifiche aree applicative. Anche questo potrebbe avere un peso ma non lo so.

Ovviamente qualsiasi suggerimento anche non solo strettamente limitato al problema è benvenuto.

Grazie :)

Potresti provare con I2C.
https://docs.arduino.cc/learn/communication/wire/
Hai solo 2 fili che corrono fra l'arduino e i vari ESP32 in fila uno dietro l'altro

il bus I2C ha un range di pochi metri e un baud rate basso

For reference, shielded 22 AWG twisted pair cables have capacitance in the range of 100-240 pF/m. So the maximum bus length of an I2C link is about 1 meter at 100 Kbaud, or 10 meters at 10 Kbaud. Unshielded cable typically has much less capacitance, but should only be used within an otherwise shielded enclosure.

se intendevi usare RS485 forse perche ti servono distanti?

Visto quanto detto al punto 1, non ho capito se la velocità è determinante o no. Pare di no. Qual è il limite? 10 pacchetti al secondo? 100? 1000?

Detto ciò si, la trasmissione di valori binari in byte, non convertiti in altre rappresentazioni (che sempre altri byte sono, ma di più), è più efficiente/veloce. Ma in ogni caso serve un piccolo overhead per sincronizzazione, indirizzamento slave, ed eventuale rilevazione errori.

Le prime due cose con i2c sarebbero gestite a livello hardware (o software dalle librerie di emulazione i2c), e non ci sarebbe il "problema" del byte di sincronizzazione che non deve comparire nei dati. Avremmo però, se non ricordo male, il limite dei 64 byte massimi per pacchetto (il buffer software delle librerie i2c).

Nel caso della seriale il buffer è anche di 64, ma mentre viene riempito dai dati in arrivo da un lato, può essere letto e svuotato dall'altro, per cui una comunicazione seriale potrebbe anche essere continua, a patto che non si trasmettano nell'unità di tempo più byte di quelli che vengono letti dal ricevente.

Intanto grazie a tutti per le risposte fin qui. Ora inizio a ricordare che avevo considerato RS485 perché non sapevo esistessero e pure da tanto tempo gli ESP con la WiFi integrata. Ho appunto ripreso l'argomento della comunicazione con Arduino perché il problema di sensori distanti e la scheda aggiuntiva LAN sono venuti meno.

Il "pretesto" per la comunicazione più o meno veloce è che vorrei esaminare la forma d'onda della tensione di rete. Ho una moria continua di HD su PC diversi quindi non credo possa trattarsi di un problema del singolo PC, la rete elettrica ha interruzioni quasi giornaliere e magari c'è qualche problema. So che direte che per campionare una forma d'onda se pure a 50 Hz un Arduino non basta e lo so. L'idea è di leggere a loop, calcolare alcune grandezze caratteristiche tipo media, massimo, minimo, etc per un certo intervallo di tempo e trasmettere quei dati già aggregati. L'ESP di turno farà essenzialmente da bridge e già che ci sono gateway per MySensors, ancora devo vedere.

Quindi anche trasmettere poco meno di 200 bytes ogni 200 ms dovrebbe bastare. Già che c'ero ho chiesto di una comunicazione veloce perché un domani può servire. Soprattutto ricordo che avevo iniziato un grosso progetto tipo "coltellino svizzero" che inglobava watchdogs, temporizzatori, etc, trasmettendo tutto in binario; come ovvio, dal corrispondente programma in C++ che leggeva la seriale mi sono ritrovato lo zero come terminatore indesiderato e altrettanto ovviamente ineliminabile.

Spero che con un intervallo di 200 ms si riesca anche a chiamare itoa() senza troppo caricare il processore, ricordo solo che ci sbattei la testa per mesi su questo problema. Per questo decisi che appena avrei ripreso in mano il progetto avrei fatto fare tutti i conti possibili direttamente sul dispositivo di acquisizione in modo da trasmettere a frequenza più bassa ma in ASCII.

lemure64 ha scritto:mi sono ritrovato lo zero come terminatore indesiderato e altrettanto ovviamente ineliminabile

Ci sono tantissimi modi per far si che questo non accada o non sia un problema. Ma dipende da "come" sei in grado di leggere i byte in arrivo. Se usi una funzione che termina quando riceve uno zero binario, allora si diventa un problema.

Io ho solo seguito tutti i tutorial che ho trovato, tanto è vero che sistematicamente le risposte al mio stesso problema erano varianti di "converti in ASCII così sarai sicuro che lo zero segnala fine buffer".

Sul C++ l'unica libreria che mi funzionò sotto windows aveva una sola funzione di lettura che restituiva il numero di bytes letti nel buffer passato come argomento, non c'era altro. Ovviamente si fermava al primo zero, come poi l'esame del traffico mi confermava.

Stupidamente ero arrivato a racchiudere il payload tra due triplette di caratteri non zero, salvo scoprire immediatamente che lo zero stava appunto da qualche parte dentro i delimitatori. OK, prendo il premio del gonzo del 2022 (perché poi ho lasciato perdere tutto per disperazione; posso gestire un problema alla volta ma LAN, seriale, eccetera... meno male che ho scoperto che esiste il ESP32 così almeno la rete non mi dà problemi).

Ci sono comunque ancora molte ambiguità nella richiesta. Riprendiamo i punti del primo post.

1) Le seriali in Arduino e ESP sono hardware e funzionano già sotto interrupt, in modo invisibile all'utente. Il baud rate si può settare anche a 115200 b/s. La velocità effettiva finale di comunicazione tra i processi dipende invece da altre scelte di design del software.

2) Un master (adesso bisogna dire controller ) che interroga diversi slave (adesso bisogna dire periferiche ) non è un problema né hardware né software, basta che nella richiesta ci sia un campo indirizzo.

3) Debuggare facilmente... boh.

Detto ciò, in una comunicazione byte per byte Ardu<->ESP realizzata da sè, il problema dello zero binario non esiste. Se semplicemente si riceve byte per byte in un array, si può ceare qualsiasi tipo di protocollo/pacchetto. Esiste come già accennato il problema della sincronizzazione, cioè di riconoscere univocamente inizio e fine di un pacchetto.

Non mi è chiaro cosa intendi con sequenza di zero e uno. Byte di valore solo zero o uno, o bit bitmappati all'interno di byte? (per cui con 10 byte trasporti 80 bit 0 o 1)