Funzionamento comunicazione RS485 Arduino

pcf ansiagorod snipped-for-privacy@libero.it ha scritto:

Prova prima ditto a invertire i canali a scanso di equivoci.

pcf ansiagorod snipped-for-privacy@libero.it ha scritto:

Ho visto l'analizzatore ma fanno solo l'8 canali, quale intendi x 16?

Ciao gruppo,

Sto cercando di mettere in piedi una piccola libreria per gestire la comunicazione con i modulini RS485, quelli lunghi e stretti che si trovano ovunque.

Al momento, dopo parecchio sudare, il software sembra fare quello che vorrei. In breve il messaggio viene trasmesso N volte e vengono confrontate con la prima tutte le trasmissioni con N > 1; se sono tutte uguali il messaggio si intende ricevuto.

Ho provato con due sketch banalissimi. Semplicemente al momento della ricezione, la stringa di caratteri viene mandata sulla seriale senza fare calcoli né altro. Grazie al mio nuovo giocattolino, l'analizzatore logico e PulseView riesco a vedere la comunicazione. Per avere le seriali libere per il debug, per la comunicazione ho usato la libreria di serie SoftwareSerial. So che ci sono alternative migliori ma a me interessa sempre la minima dipendenza da tutto quello che è possibile e non mi serve comunicazione veloce sennò andrei con la LAN.

Ho provato a catturare cosa succede al massimo della frequenza che mi permette tutto l'insieme, ovvero 16 MHz. Gli arduini sono un Mega per trasmettere e un Nano per ricevere.

Ecco, fino a che non si 'zooma' molto, la stringa parte prima che la stringa N sia arrivata. Ho ingrandito per quanto possibile ed effettivamente c'è un piccolo intervallo, solo che inizia con la ricezione dell'ultimo byte senza aspettare il bit di stop (se si chiama così). In calce c'è la schermata. Si può vedere che i due bit si sovrappongono. Tra ricezione del carattere e trasmissione ci sono poco meno di 123.7 us.

Ora, il massimo che ho controllato in vita mia sono state le operazioni matematiche ma non so niente di come valutare la velocità con l'IO di questi hardware. Tutto va come vorrei andasse, all'ultima ripetizione prevista parte la risposta; ma se ci fosse un bug che non vedo e che si manifesterebbe chi sa in quali condizioni?

Infine, cosa posso leggermi su queste cose? La rete sembra stranamente povera ma sicuramente sono io che non so cercare.

Grazie come sempre

Pulseview, che puoi prendere aggratis da qua:

poi ho preso il clone dell'analizzatore Sealeleleleleleleale, un az-Delivery a 15 euro e non so come io abbia fatto a scrivere qualcosa per Arduino fino a questo momento. Ora che ho avuto il giocattolo vedo che sarebbe meglio 16 canali invece di

Sigrok supporta un mare di roba.

Il 19/04/2023 10:52, asdf ha scritto:

questo "potrebbe" essere interessante:

Il 19/04/2023 11:37, Marco colandrea ha scritto:

SigRok e' eccezziiunale veramente, soprattutto per la marea di protocolli che consente di decodificare, e sempre in crescita Anch'io l'ho usato con quei trappoletti da 10-15 euro 8 canali che in teoria dovrebbero andare a 24 MHz ma poi oltre i 12/16 MHz non si va

Qualcuno dei presenti (o anche tra gli assenti) ha provato a sparare il firmware sopra su un raspberry? Sarebbe un gran bel colpo, attrezzare un Raspberry Pico a fare da logic analyzer 16 canali a 100 MHz, diconsi 100 mega-hertsss !!!

Dai fuori il volontario, qua serve qualcuno che sappia dove mettere le mani, e poi spieghi a noi della banda scarsotti :) :)

Per i miei scarsissimi spazi e goffaggine tecnico-manual-intellettuale è una pregiudiziale totale. Ho un sacco di modulini traslatori di segnale ma finirei col tavolo pieno di fili, breadboards e quant'altro. :(

RobertoA snipped-for-privacy@tiscalinet.it wrote in news:u1oeha$hmn$ snipped-for-privacy@dont-email.me:

Ah ecco, mi pareva strano, sempre sulle spalle altrui.

-- sst snipped-for-privacy@mamber.net wrote in news: snipped-for-privacy@4ax.com:

btg: btg1qwla7jncpfs6jdeud7y9ar67wkl634ns0sus6rm btc: bc1q8jhm0jd3zrz8r4c0xc4chrxdqr0ek4ys4h4ejr

Dubito fortemente che una mcu clockata a 133 MHz possa lavorare in lettura a quelle velocità. Forse con la PRU dei processori Sitara delle Beagleboard ci si avvicina, aggiungendo hardware esterno per aumentare i canali, ma non credo con la RPi Pico.

Per es.

Bello sto BeagleLogic, ma lo vendono o e' un esperimento?

Si, vero, che vada a 133MHz e che legga a 100 MHz suona un po' strano, ma questo c'e' sul link indicato da Marco Colandrea Riporta esattamente "100 MHz sampling rate, 1 sample per sys tick" Da dire che si trovano gienti che l'RP2040 lo fanno andare a 400 MHz, altri addirittura oltre il GHz ghiacciandolo per bene Ma non credo che il microLA descritto faccia uso di queste tecniche Non conosco l'architettura del RP2040 ma da una rapida lettura vedo che dispone pure di un dma controller, e questo mi fa pensare che la lettura ingressi possa essere sganciata dall'attivita' cpu ed andare via per conto suo con prestazioni ben maggiori rispetto al classico ciclo di lettura fatto via codice, che ai 100 Megasample/sec non ci arriverebbe Inzomma, e' vero che va a 133 MHz standard, ma alcuni indizi che possa leggere anche 100 MHz ci sono Come (e se) lo possa fare nella realta' poi e' da scoprire

lo fa per l'I/O, con certe limitazioni ha un "coprocessore" dedicato che va a velocita' piena con istruzioni specializzata alla movimentazione dei dati dai pin verso delle fifo, a loro volta gestibili via DMA dal lato CPU una istruzione per ciclo di clock ( a sua volta programmabile ) e' una vecchia idea, quella dei coprocessori di I/O, tipica del mondo mainframe di una volta

come esempio qualcuno ha implementato un USB host in SW