Nel pomeriggio ho pensato che la tua fosse una domanda ipotetica
steve-cr:
Quindi se come MSB ricevo un 1 poi spiegami come lo trasformo in numero decimale dato che mi mancano le altre 23 cifre binarie... E comunque non ha senso trasformarlo 24 volte...
nel pomeriggio ho crreduto la tua fosse una domanda retorica, poi ci ho pensato bene, e complice una panascè di troppo forse ho capito che la tua non è domanda ipotetica
questo è il tuo codice, preso dal mesagio numero 7
void setup() {
pinMode(3, OUTPUT);
pinMode(4, INPUT);
digitalWrite (3,LOW);
Serial.begin(9600);
}
void loop() {
unsigned long int numero=0;
if (digitalRead (4) == LOW) {
for (int i=0; i <= 24; i++){
digitalWrite (3,HIGH);
// data = digitalRead (4);
// NO NO, niente Stringhe
numero=numero*2+digitalread(4);
// mi ricordassi la sintassi degli shift di bit farei anche prima
//delay (1);
digitalWrite (3,LOW);
}
Serial.println (numero);
}
}
lo ho corretto qui, vedi se compila
ti ho lasciato commenteta una sola riga, dove ipostavi la variabile data
subito dpo hai la versione numerica
se compila ho buona confdenza che vada
casomai lasciami passare la sbornia
buonanotte
Standardoil:
Nel pomeriggio ho pensato che la tua fosse una domanda ipotetica
nel pomeriggio ho crreduto la tua fosse una domanda retorica, poi ci ho pensato bene, e complice una panascè di troppo forse ho capito che la tua non è domanda ipotetica
questo è il tuo codice, preso dal mesagio numero 7
void loop() {
unsigned long int numero=0;
if (digitalRead (4) == LOW) {
for (int i=0; i <= 24; i++){
digitalWrite (3,HIGH);
// data = digitalRead (4);
// NO NO, niente Stringhe
numero=numero*2+digitalread(4);
// mi ricordassi la sintassi degli shift di bit farei anche prima
//delay (1);
digitalWrite (3,LOW);
}
Serial.println (numero);
}
}
lo ho corretto qui, vedi se compila
ti ho lasciato commenteta una sola riga, dove ipostavi la variabile data
subito dpo hai la versione numerica
se compila ho buona confdenza che vada
casomai lasciami passare la sbornia
buonanotte
Figo! Magari la prossima volta vado sulla Panascé anche io
Guglielmo, cosa dici? E' di una semplicità disarmante!!!
Come dice la regola, "solitamente la soluzione e la via più semplice..."
Il discorso simpatico è che funziona su ogni MCU con ogni linguaggio di programmazione, nel senso che non si spostano bit a sinistra e non devi tenerne la conta in una DWORD...
E' semplicemante ina operazione aritmetica...
Silente c'era arrivato prima ma si stava ancora "incasinando" con l'identazione di una stringa, mentre è ancora più semplice perché il numero binario fine a se stesso non mi interessa...
... dico che, più di una semplicità, è di una lentezza disarmate !
Ma siete matti ad usare su piccole MCU a 8 bit operazioni matematiche (moltiplicazione) invece che, dove possibile, gli shift ? ? ? .... non ho verificato ... mi auguro solo che il compilatore, estremamente più ottimizzato di voi , si accorga che state facendo una moltiplicazione per due (che è uno << 1) e la trasformi lui in uno shift ... così da riportare in "come va fatto" quello che state facendo !
Come già detto, per lo stesso problema esistono infinite soluzioni ...
.. 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:
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
... che poi, se capisco bene quello che stai facendo, in pratica tu stai simulando in bit banging il funzionamento di una porta SPI
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
gpb01:
... 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
gpb01:
... che poi, se capisco bene quello che stai facendo, in pratica tu stai simulando in bit banging il funzionamento di una porta SPI
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)...
steve-cr:
... 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
, si accorga che state facendo una moltiplicazione per due (che è uno << 1) e la trasformi lui in uno shift ... così da riportare in "come va fatto" quello che state facendo ! 
...