next topic »

[Reply #30 on:]

Con la EEPROM peggio perché sono solo 1024 byte.
Usa la Flash con PROGMEM, è l'unica soluzione praticabile. Non puoi crearti 1,5 kB di tabella in memoria, devi pensare che nella RAM ci stanno poi anche tutte le variabili create a runtime dal tuo sketch per cui se va in carenza di risorse poi il programma potrebbe avere comportamenti strani come variabili con valori strani od altro. E non mi pare il caso visto che devi flashare dei fuse.

[Reply #31 on:]

Con la EEPROM peggio perché sono solo 1024 byte.
Usa la Flash con PROGMEM, è l'unica soluzione praticabile. Non puoi crearti 1,5 kB di tabella in memoria, devi pensare che nella RAM ci stanno poi anche tutte le variabili create a runtime dal tuo sketch per cui se va in carenza di risorse poi il programma potrebbe avere comportamenti strani come variabili con valori strani od altro. E non mi pare il caso visto che devi flashare dei fuse.

OK studierò questo comando e gli array, insomma prima sbatto un po' la testa e poi chiederò aiuto, mi pare più giusto, anche perché così si impara sul serio, lo sto vedendo con Astro con la storia delle signature, essere riuscito a leggere il primo bye sia in P che in S è un ottimo risultato e mi ha aiutato a capire i passaggi che mi ha poi suggerito Astro. Ora con l'S devo ancora tentare, perché penso di aver capito il meccanismo, in questo modo ho imparato le tecniche ed il modo in cui vanno lette ed applicate quelle tabelle, un bel risultato per usi futuri!

[Reply #32 on:]

Posso farti una domanda? Ma perché implementare le firme di 100 micro se poi sui tuoi zoccolini ce ne andranno qualche decina, non di più? Tutti i micro non DIP nonché quelli non supportati dall'IDE sono tagliati fuori dalle mani dell'hobbista medio, dall'utente di Arduino per intendersi. Penso potresti ridimensionare il progetto e circoscrivere i dati ai soli chip che poi possono essere manipolati.

[Reply #33 on:]

Posso farti una domanda? Ma perché implementare le firme di 100 micro se poi sui tuoi zoccolini ce ne andranno qualche decina, non di più? Tutti i micro non DIP nonché quelli non supportati dall'IDE sono tagliati fuori dalle mani dell'hobbista medio, dall'utente di Arduino per intendersi. Penso potresti ridimensionare il progetto e circoscrivere i dati ai soli chip che poi possono essere manipolati.

Infatti è quello che alla fine farò; l'idea è che uno strumento di questo tipo ha delle belle potenzialità anche al di fuori del campo hobbystico, quindi prevedere tutti i tipi di PDIP potrebbe avere una sua valenza. La cosa che mi stimola, ma non è momento, ora devo pensare solo alla pubblicazione e ho tempi abbastanza stretti, è il fatto che a forza di leggere quel DS mi sono fatto l'idea che forse è possibile programmare un micro con la modalità HVPP o HVSP, e non mi riferisco solo ai fuse, però non ho approfondito, ma se fosse vera questa cosa, con l'opportuno software diventerebbe un vero e proprio programmatore AVR , sarebbe bello no?
Ma siccome tutto dipenderebbe dal firmware, inutile prevedere qualcosa che per ora non posso fare, quindi mi limito ai 25 modelli che ho descritto nella Tabella che allegherò, più qualche altro (p.es. le varianti ATmega328 noP e similari, le varianti V, A, AP), alla fine penso saranno una quarantina, penso di potercela fare.

[Reply #34 on:]

Beh, si tratta tutto di firmware alla fine.
L'USBtinyISP usa un Tiny2313 per programmare i micro, l'USBasp usa un ATmega8, l'Arduino usa un Atmega8U2. Cambiano i direttori d'orchestra ma la musica è la stessa.

[Reply #35 on:]

Mike , sei riuscito a fare il confronto alla fine ? mi son poi reso conto che la define era sbagliata 
Scusate ma non ho avuto il tempo di rileggere tutto il topic ...

P.s. Il mio USBasp usa un ATmega 48 

[Reply #36 on:]

Beh, si tratta tutto di firmware alla fine.
L'USBtinyISP usa un Tiny2313 per programmare i micro, l'USBasp usa un ATmega8, l'Arduino usa un Atmega8U2. Cambiano i direttori d'orchestra ma la musica è la stessa.

Quindi, come vedi, le sue potenzialità vanno MOLTO ben oltre l'idea da cui è nato il progetto ma, come detto, questa è un'altra storia...

@ ratto93: ancora non ho fatto la prova, purtroppo sono alle prese con oltre 200 pagine di compiti scritti da valutare ed io sono uno molto scrupoloso, così quando boccio nessuno osa fare questioni come invece avviene tante volte con più di qualche collega che riesce a fare in due ore il lavoro che io faccio in 3-4 giorni, mi capisci vero? 

[Reply #37 on:]

@ ratto93: ancora non ho fatto la prova, purtroppo sono alle prese con oltre 200 pagine di compiti scritti da valutare ed io sono uno molto scrupoloso, così quando boccio nessuno osa fare questioni come invece avviene tante volte con più di qualche collega che riesce a fare in due ore il lavoro che io faccio in 3-4 giorni, mi capisci vero? 

Tenendo conto che solitamente sono dall'altra parte del manico del coltello 
Si 
io sono alle prese con le simulazioni degli esami e non son di grande aiuto aimè   

[Reply #38 on:]

Non ti funziona, ma non dovrebbe nemmeno compilarlo, perché gli "#" non ci devono essere e tantomeno ci deve essere la endif

Code:

Serial.print("SIGNATURE: ");
   if (read_signature1 < 0x10) Serial.print("0");
 
 Serial.print(read_signature1, HEX);

OK, funziona sia con 16 che con 0x10, era proprio un problema di sintassi del comando; problema risolto.

[Reply #39 on:]

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?

[Reply #40 on:]

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:

Code:

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.

[Reply #41 on:]

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)

[Reply #42 on:]

• 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.

[Reply #43 on:]

• 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!

[Reply #44 on:]

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.