Mi spiegate questo indirizzamento a 3 Bytes?

Ciao ragazzi,
sto scrivendo uno sketch che deve leggere porzioni di un file nella SD quando riceve un determinato comando via seriale.
Il comando contiene l'indirizzo di partenza da cui leggere ed e' composto da 3 bytes che si incrementano in questo modo:

a b c
00 00 00
00 08 00
00 10 00
00 18 00
00 20 00
...

quando il byte 'b' raggiunge il valore F8, al giro sucessivo ricevo 00 00 01 (00 F8 00 --> 00 00 01).

Il byte 'a' si incrementa invece al sucessivo giro di 00 F8 FF (00 F8 FF --> 01 00 00)

Scusate la mia ignoranza, forse e' una banalita' ma qualcuno mi spiega un modo furbo per creare 3 bytes che si incrementano in questo modo e magari anche come leggere correttamente l'indirizzo?

Grazie

Direi che se lo guardi bene quello è un indirizzo in esadecimale che si incrementa ogni volta di 0x800 ...

Se dichiari un 'unsigned long' e ad ogni giro lo incrementi di 0x800 ottieni proprio:

0x00000000
0x00000800
0x00001000
0x00001800
0x00002000
...

Esempio di ciclo:

unsigned long i;
...
for ( i = 0; i < _tuo_limite_superiore_; i += 0x800 ) {
   ...
   ...
   ...
}

Guglielmo

Grazie Guglielmo per la risposta ma qualcosa ancora non torna.... i bytes 'a' e 'c' si incrementano con una logica diversa.
Io penso che ci sia un incremento sia di 8 Bytes nell'indirizzo ma l'ordine dei tre non e' quello corretto.

Infatti l'indirizzamento è ACB

... ma de che state a parla' ? ? ? :o :o :o

Quello è un normalissimo conteggio con incremento 0x800 (2048 decimale) ed i valori sono in esadecimale, se li trasformate in decimale, partendo da zero, e incrementando di 2048 avete:

0      : 0x00000000
2048   : 0x00000800
4096   : 0x00001000
6144   : 0x00001800
8192   : 0x00002000
...

... in pratica sono blocchi da 2K

Guglielmo

gpb01:
Quello è un normalissimo conteggio con incremento 0x800 (2048 decimale)
... in pratica sono blocchi da 2K

No, perché ha detto che dopo 0x00F800 diventa 0x000001, quindi è corretto quello che dice Brunello, di fatto i 3 byte "a", "b" e "c" vanno considerati (per qualche ragione che a me sfugge) come "a" "c" "b" quindi la sequenza sarebbe:

0x000000
0x000800
0x001000
...
0x00F800
0x000001  <- questo è il "riporto"
0x000801
0x001001
...
0x00F801
0x000002  <- Secondo "riporto"
...

che a tutti gli effetti, invertendo i due byte "b" e "c" diventerebbe una ben più comprensibile e lineare sequenza passo 8:

0x000000
0x000008
0x000010
0x000018
...
0x0000F8
0x000100
0x000108
0x000110
...
0x0001F8
0x000200
... eccetera

Per cui il programma per generare questa sequenza è banalmente un ciclo passo 8, dove però il dato, convertito in 3 byte, ha il secondo e terzo invertiti.

docdoc:
No, perché ha detto che dopo 0x00F800 diventa 0x000001 ...

... solo quello sarebbe banalmente risolvibile (un limite superiore o un IF), quello di cui effettivamente NON mi ero accorto è che:

  1. 00 F8 00 --> 00 00 01 ... quindi qui sembrava un limite a F0 00 ma ...

  2. 00 F8 FF --> 01 00 00 ... e questo effettivamente m'era sfuggito ... mea culpa ... :-[

Strano contatore ... che senso ha ?

Guglielmo