Topic permanente di programmazione newbie

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.

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

P.s. Il mio USBasp usa un ATmega 48 ;)

leo72:
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? :wink:

menniti: @ 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 :cold_sweat: Si :grin: io sono alle prese con le simulazioni degli esami e non son di grande aiuto aimè :blush:

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

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

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 :D

: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:

20*100 = 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 :D

Noto con piacere che Leo e BB si passano la palla, BB!!!! ]:D 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 ;) 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 :)

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 ;) 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} };