Topic permanente di programmazione newbie

Allora riprendo la problematica dell'array perché non capisco come impostarlo e comunque vorrei una soluzione ottimale.
Devo memorizzare, per ogni micro:
signature, modello, fuse, tipo programazione
1e950f ATmega328P 62dff9 P
1e93ff ATtiny85 62dfff S
Ho inoltre necessità di inserire un'ulteriore info, cioè se il micro ha/non ha l'EFuse, non tanto per la lettura, che mi darebbe sempre FF quanto per l'eventuale scrittura per errore (devo pensare all'utente hobbysta), non credo possa succedere qualcosa ma l'utente, vedendo invariato quell'FF penserebbe ad un malfunzionamento.
Cosa mi conviene fare, tenendo conto che per ora memorizzo solo una quarantina di micro e certamente uso il PROGMEM per scrivere in flash, in previsione di un elenco molto più lungo?
Ho pensato alla stringa unica:
1e950f62dff9PATmega328P
1e93ff62dfXXSATtiny85
in questo modo avrei: i primi 6 car per la sign, i secondi 4 per L/Hfuse, quindi 2 per l'Efuse o XX per noEfuse, 1 car per la modalità di programmazione, tutto il resto, che è l'unico dato a lunghezza variabile, a partire dal 14° car fino alla lunghezza della stringa.
Che ne pensate? So che questo è molto dispendioso in termini di memoria, ci sono soluzioni che mi permettono comunque una facile estrapolazione dei parametri e minor occupazione di memoria?

menniti:
Allora riprendo la problematica dell'array perché non capisco come impostarlo e comunque vorrei una soluzione ottimale.

Io al tuo posto procederei inizializzando tre array multidimensionali, ovviamente posti nella flash, in questo modo:

char Stringa[20] [20] = { {"ATmega328p"},
                          {"ATMEGA644"},
                          {"ATMEGA2560"}
                        };
                        
byte signature [20] [3] = { {0x1E,0x1C,0x1D},
                                 {0x1E,0x1C,0x1E},
                                 {0x1E,0x1C,0x1F}
                               };  

byte fuses [20] [4] = { {0xff,0xff,0xff,0xff},
                             {0xff,0xff,0xff,oxff},
                             {0xff,0xff,0xff,oxff}
                           };

Premesso che i valori numerici li ho messi a caso, poi tocca mettere quelli corretti, abbiamo tre array composti da 20 righe di tot colonne, il numero della riga è l'indice univoco (quante righe dipendono dal numero di micro che vuoi inserire), ricavato dalla signature, che ti permette di trovare tutti gli altri parametri.
In pratica hai un array di stringhe che contiene la descrizione del micro, 20 caratteri dovrebbero bastare e sono pari ad una singola riga del display così hai meno problemi di formattazione dei messaggi, poi hai due array di valori unsigned int che contengono le signature, 3 colonne per tot righe, e la stessa cosa per i valori dei fuse posti in un terzo array composto da 4 colonne e tot righe.
Non appena hai trovato i tre byte della signature non devi fare altro che scorrere il relativo array per righe leggendo i tre byte delle colonne, confronti i valori e se corrispondono hai trovato l'indice per accedere agli altri due array per avere la descrizione e i fuse.
Lo so che detto a parole sembra complicato, ma in realtà è semplicissimo da implementare, se hai problemi questa parte di codice te la scrivo io.

Non sembra complicato, certo ci devo ragionare per comprenderlo bene, faccio delle prove (ora sono al lavoro, se ne parla in serata al rientro) e ti saprò dire. Alcune info:

  • a che serve il 4° byte sui fuse?
  • come faccio a memorizzare il fatto che un micro abbia o no l'EFuse? Non posso basarmi sul valore FF che potrei trovare in un micro che ha l'EFuse ma che è settato su FF
  • dove posso memorizzare una sigla P o S per sapere che tipo di programmazione mi serve? (è per usi futuri, visto che ora ho implementato l'automatismo)

menniti:

  • a che serve il 4° byte sui fuse?

Per eventuali informazioni accessorie, vedilo come un 8 bit flag, p.e. esempio per sapere se usare il modo P o S etc.

astrobeed:

menniti:

  • a che serve il 4° byte sui fuse?

Per eventuali informazioni accessorie, vedilo come un 8 bit flag, p.e. esempio per sapere se usare il modo P o S etc.

Ottima idea, mi creo delle combinazioni sia per l'Efuse che per P/S, alla fine sono 4 in tutto.
Grazie e a stasera!

Perchè non memorizzi il catalogo dei micro in una eeprom esterna ,così ti puoi allargare con il numero dei micro supportati a tutti i pdip.

BrainBooster:
Perchè non memorizzi il catalogo dei micro in una eeprom esterna ,così ti puoi allargare con il numero dei micro supportati a tutti i pdip.

Ma perché deve complicarsi la vita quando ha 32k di flash a disposizione, hai voglia a memorizzare micro :smiley:

:cold_sweat: dici che bastano per tutti i micro a 8 bit pdip?

BrainBooster:
Perchè non memorizzi il catalogo dei micro in una eeprom esterna ,così ti puoi allargare con il numero dei micro supportati a tutti i pdip.

Perché ormai l'HW è definito e non può usare componenti aggiuntivi. Inoltre avere tutto in un unico firmware è per lui molto vantaggioso, dato che il firmware sarà disponibile per il download dal sito della rivista. Quindi la gente dovrà flashare 1 sola cosa. (così ho capito)

ok, capito.
Ma per espansioni future... :wink:

BrainBooster:
:cold_sweat: dici che bastano per tutti i micro a 8 bit pdip?

Facciamo due conti utilizzando le matrici che ho consigliato a Michele, ipotizzando di memorizzare i dati di 100 micro abbiamo quanto segue:

20100 = 2000 byte per le descrizioni
3
100 = 300 byte per le signature
4*100 = 400 byte per i fuse e i dati accessori

Totale 2700 byte

Direi che volendo ci entra pure tutto il catalogo Atmel delle mcu a 8 bit e avanza molto spazio :smiley:

Noto con piacere che Leo e BB si passano la palla, BB!!!! ]:smiley: dopo tutta la questione di ieri ancora parliamo di modifiche hardware?
:fearful:
Leo, hai capito benissimo XD, in realtà i firmware da flashare saranno tre:
micro master PC
micro master stand-alone
micro key+lcd
i primi due sono alternativi, cioè metto l'uno o l'altro, perché non credo di riuscire a tirare fuori un unico firmware in grado di riconoscere la presenza dell'altro micro e gestire i messaggi seriali di conseguenza. Ricordo a tutti che TUTTE LE LINEE sono occupate e non potevo usare la comunicazione I2C quindi li ho collegati tramite seriale standard; in pratica sul pcb master ho un connettore seriale che all'occorrenza mi serve come presa per un convertitore usb-seriale esterno (per collegamento al PC) oppure per il dialogo col PCB keypad+LCD20x4, gestiti da un altro 328P che ovviamente avrà il suo firmware.
Tutto sarà gratuitamente scaricabile dal sito di Elettronica In, a questo punto mi pare che la soluzione di Astro sia perfetta, non penso nemmeno che si arrivi ad un centinaio, e comunque una parte sarebbero incompatibili con i segnali, credo, quindi perdere un paio di K di flash è qualcosa di fattibilissimo, addirittura mi verrebbe la tentazione di usare la ram a questo punto :wink: che ne dite?
Comunque fra poco mi metto al lavoro, ho altri dubbi da levarmi:
ho letto che il tiny2313 usa un HVSP un po' "potenziato", con un paio di segnali in più, no problem, ma voglio capire ora cosa succede col riconoscimento automatico; inoltre sono curiosissimo di provare un ATmega8 che avevo fatto fuori a suo tempo, proprio morto, non bricked :blush:, ma che qualche segno di vita forse lo dava, vediamo che succede anche qui.

A dopo :slight_smile:

menniti:
credo, quindi perdere un paio di K di flash è qualcosa di fattibilissimo, addirittura mi verrebbe la tentazione di usare la ram a questo punto :wink: che ne dite?

In realtà non credo che metterai più di 20 modelli diversi di micro, anche perché puoi inserire solo quelli disponibili in case dip il che esclude molti modelli di micro, p.e. il MEGA2560.
Rifacendo i conti per 20 modelli abbiamo :

20x20 = 400
20x3 = 60
20x4 = 80

Totale 540 byte.

Sicuramente entrano senza problemi nella ram visto che te ne serve poca per far funzionare lo sketch, però a mio avviso i dati statitici è sempre bene caricarli nella flash piuttosto che nella ram o nella EEPROM.

La riga dell'array della signature mi dà errore di compilazione:

41: error: hexadecimal floating constants require an exponent
42: error: expected initializer before 'signature'

l'istruzione è questa:

char byte signature [3] [20] = { {0x1E,0x95,0x0F},
{0x1E,0x93,0x0D},
{0x1E,0x91,0x0A},
{0x1E,0x93,0x0C}
};

Beh, il compilatore ha ragione. O char o byte, mica puoi dichiararlo di 2 tipi diversi XD
E poi hai invertito le dimensioni dell'array, nel tuo modo vuoi creare un array di 3 elementi da 20 caratteri l'uno, a te serve l'opposto, quindi:

byte signature [20] [3] = { {0x1E,0x95,0x0F},
{0x1E,0x93,0x0D},
{0x1E,0x91,0x0A},
{0x1E,0x93,0x0C}
};

leo72:
Beh, il compilatore ha ragione. O char o byte, mica puoi dichiararlo di 2 tipi diversi XD

Questo è colpa mia, quando ho fatto copia e incolla è successo un casino del quale non mi sono accorto, ci va solo byte, adesso correggo l'esempio originale.

E poi hai invertito le dimensioni dell'array, nel tuo modo vuoi creare un array di 3 elementi da 20 caratteri l'uno, a te serve l'opposto, quindi:

No queste sono giuste, 3x20 e non 20x3, visto che è la signature.

Compila con 3x20 e vedi se non ti da errore. :stuck_out_tongue:
3 elementi da 20 caratteri l'uno, qui abbiamo invece il caso inverso: dobbiamo memorizzare tanti elementi da 3 caratteri l'uno, serve una matrice x*3, con x che è il numero di signature da contenere

leo72:
Compila con 3x20 e vedi se non ti da errore. :stuck_out_tongue:

Mi sa che stamattina sto ancora dormendo, hai ragione anche i due valori dell'inizializzazione sono invertiti tra loro, questo è quello che succede quando si scrive al volo del codice senza provarlo. =(

astrobeed:
Mi sa che stamattina sto ancora dormendo, hai ragione anche i due valori dell'inizializzazione sono invertiti tra loro, questo è quello che succede quando si scrive al volo del codice senza provarlo. =(

Dalle mie parti si dice che "sbaglia anche il prete all'altare" :wink:

Diciamo che la mia dichiarata in Topic fatale ignoranza non mi ci ha fatto capire nulla, al solo comando "byte" ero arrivato ma non capivo l'errore successivo, evidentemente quello dell'inversione, ed il fatto che la prima istruzione avesse 20, 20 non mi ha aiutato a capire.
COmunque ieri sera ho messo a punto grosso modo l'impostazione del 4° byte dell'array signature, mi servono 6 valori per le possibili combinazioni di EFuse e Tipo di Programmazione; sono state fondamentali le prove hw che ho descritto nell'altro Topic. Grazie a tutti, oggi altra giornataccia, ci sentiamo appena possibile.