Go Down

Topic: Celle di carico con HX711 (Read 2326 times) previous topic - next topic

gpb01

#45
May 06, 2018, 10:34 am Last Edit: May 06, 2018, 11:02 am by gpb01
Come già detto, per lo stesso problema esistono infinite soluzioni :smiley-mr-green: ...
.. ovviamente Silente e successivamente il codice che ti ho messo io (che, come ho segnalato era una ottimizzazione del suo), sono stati fatti per trattare la tua "String".

Nella reltà invece, quel codice si scrive ottimizzato in poche righe, usando il valore ottenuto dalla digitalread() come valore del bit che comunque viene shiftato e messo in un unsigned long ;)

Qualche cosa del tipo:

Code: [Select]
  for (uint8_t i = 0; i < 24; i++) {
      digitalWrite(3, HIGH);
      valore |= ((uint32_t)digitalRead(4) << i);
      digitalWrite(3, LOW);
   }

... ottimizzandolo ancora per usare direttamente i PIN e PORT (al posto delle digitalWrite e digitalRead) ed accelerare moltissimo il tutto ;)

Guglielmo
Search is Your friend ... or I am Your enemy !

gpb01

#46
May 06, 2018, 10:51 am Last Edit: May 06, 2018, 11:02 am by gpb01
... che poi, se capisco bene quello che stai facendo, in pratica tu stai simulando in bit banging il funzionamento di una porta SPI :D

Al quel punto potresti demandare il tutto alla libreria SPI e leggere il tuo blocco di 3 bytes direttamente tramite l'HW dedicato a fare ciò ... magari su una sola lettura non si velocizza molto, ma se le letture sono tante, probabilmente l'HW dedicato viaggia più veloce della sua simulazione in bit banging ;)

Guglielmo
Search is Your friend ... or I am Your enemy !

Standardoil

... dico che, più di una semplicità, è di una lentezza disarmate !
Guglielmo
mah, vedi..
Io non sono entrato nel merito dello SPI, nemmeno mi è venuto in mente
La mia domanda originale era solo: perché usare oggetto stringa?
E mi era sembrato di capire, complice una panasce', che la risposta fosse stata: è come sennò?
Io ho solo mostrato uno dei possibili come.
Che con gli operatori bitwise fosse più efficiente lo sapevo e lo avevo scritto subito
Comunque confido che tutti i compilatori moderni facciano l'ottimizzazione da soli
Prima legge di Nelson (che sono io): Se vuoi il mio aiuto dimostrami almeno che hai letto il nostro "aiutateCi ad aiutarVi"

Non bado a studenti, che copino altrove

Tu hai problema-Io ti domando-Tu non mi rispondi: vuol dire che non ti serve più

steve-cr

... che poi, se capisco bene quello che stai facendo, in pratica tu stai simulando in bit banging il funzionamento di una porta SPI :D

Al quel punto potresti demandare il tutto alla libreria SPI e leggere il tuo blocco di 3 bytes direttamente tramite l'HW dedicato a fare ciò ... magari su una sola lettura non si velocizza molto, ma se le letture sono tante, probabilmente l'HW dedicato viaggia più veloce della sua simulazione in bit banging ;)

Guglielmo
Da questo post mi sono reso conto che Arduino, per come è ora, risulta essere molto più potente di un MECT TPAC1007 con ARM969 32 bit che viene programmato in QT (parte HMI) e in ST.
Succede che da Arduino gli invio un HIGH, aspettare 21 ms (si , 21 millisecondi), fargli leggere il bit, inviare LOW e aspettare ancora 21 ms... Totale della lettura 24bit x 48 millisecondi (più di un secondo !!!). Se provo ad inviare a 20 msec. dal lato TPAC mi perdo dei bit...

Questo per dire che non è, appunto, la MCU (che tutti i produttori di PLC pubblicizzano come ultra-mega-veloce) la cosa importante, bensì il tempo di ciclo che fa si che gli ingressi e le uscite vengano aggiornati nel minor tempo possibile. Ma il tempo di ciclo dipende anche da "quante cose devo interpretare in un ciclo" e Guglielmo, appunto, ha gia scritto che meglio shiftare i bit che usare le moltiplicazioni (caro buon vecchio ASSEMBLER)...

Che dire, più vado avanti e più sono convinto che la strada dei compilatori sempre più enormi e mangiamemoria ("ma che te frega, tanto la memoria non costa nulla" dicono i programmatori della new generation) non sia la strada migliore da seguire...
Ricordo sempre che il primo Mac si chiamava 128 (erano Kbytes) e poi usci il modello Macintosh 512 (erano sempre Kbytes). E non faceva molte meno cose di ciò che fanno i computers odierni con un consumo i più di 2.000 volte la memoria di allora (Windows è almeno 1 Gbytes)...
Samantha Cristoforetti: "Mi fai fare un giro sul tuo ultraleggero?". "Certamente, però piloto io !"

gpb01

... Ricordo sempre che il primo Mac si chiamava 128 (erano Kbytes) e poi usci il modello Macintosh 512 (erano sempre Kbytes). E non faceva molte meno cose di ciò che fanno i computers odierni con un consumo i più di 2.000 volte la memoria di allora (Windows è almeno 1 Gbytes) ...
[OFF-TOPIC]
Intel + Microsoft sono i due principali colpevoli di questo andazzo ...
... in un gioco al "io faccio la CPU più potente e tu appesantisci di più il tuo codice" ... "così io vendo più CPU e tu più release di SW" ... siamo arrivati all'assurdo di avere "word processor", che un tempo giravano on pochi KB di RAM e che ora occupano GB, nonché macchine che prima con 512KB facevano grandi cose a dover avere 32GB di RAM per poter lavorare decentemente!
Che dire ... grande speculazione commerciale !
[/OFF-TOPIC]

Tornando sul tema ... comunque dalla un'occhiata alla libreria SPI ... secondo me, con i giusti parametri, puoi fare acquisizioni velocissime con un paio di chiamate ;)

Guglielmo
Search is Your friend ... or I am Your enemy !

steve-cr

Grazie della dritta. Non ci avevo pensato alla SPI.
Samantha Cristoforetti: "Mi fai fare un giro sul tuo ultraleggero?". "Certamente, però piloto io !"

Go Up