Topic permanente di programmazione newbie

Ora sono al lavoro ma nelklo sketch originale questa cosa del # è spiegata, infatti la usano davanti a tutte le define, p.es., e la usando anche negli if/endif del setup (in setup svolgono la prima parte ma io la sto cambiando radicalmente per non dover resettare ogni fine operazione) e del loop ; io credo che attivi una sorta di compatibilità perché in effetti se tolgo # endif non lo accetta invece con # lo compila e lo esegue. Proverò il tuo codice al rientro

menniti: Ora sono al lavoro ma nelklo sketch originale questa cosa del # è spiegata, infatti la usano davanti a tutte le define, p.es., e la usando anche negli if/endif del setup (in setup

Stavolta ti rimando a Settembre in programmazione :grin: Il carattere # è un tag per il preprocessore che svolge vari aggiustamenti al sorgente in base alle operazioni richieste, #if e #endif servono per compilazione condizionale, ovvero se la condizione espressa nella if, solitamente legata ad una #define o un valore fornito dalla riga di comando del compilatore, è vera il codice che segue viene incluso e compilato, in caso contrario viene escluso dal programma.

astrobeed:

menniti: Ora sono al lavoro ma nelklo sketch originale questa cosa del # è spiegata, infatti la usano davanti a tutte le define, p.es., e la usando anche negli if/endif del setup (in setup

Stavolta ti rimando a Settembre in programmazione :grin: Il carattere # è un tag per il preprocessore che svolge vari aggiustamenti al sorgente in base alle operazioni richieste, #if e #endif servono per compilazione condizionale, ovvero se la condizione espressa nella if, solitamente legata ad una #define o un valore fornito dalla riga di comando del compilatore, è vera il codice che segue viene incluso e compilato, in caso contrario viene escluso dal programma.

:blush:, beh, del resto se leggi il titolo del Topic non puoi meravigliarti più di tanto; però, caro Prof XD, sulla base di questa tua lezioncina vedrò di capire a che servono tutti quegli # che ci sono. Tanto per cominciare: poiché ci sono una ventina di #include all'inizio e servono tutte (perché quelle inutili le ho levate io di crudo), ho un qualche vantaggio dal lasciarli?

@ Leo: non lo so, ho sempre pensato che trattandosi di hex andasse scritto 10 e non 16, può essere allora che stia funzionando ma che i valori in decimale siano sempre > 10 (0A se non sbaglio...); però ho provato 0x10 senza successo, vero è che la forma era quella #, quindi quando torno verifico. Dopo verrà il "bello".. Siccome l'editor di questo Forum mi fa incazz a morte scrivo un altro post perintrodurre l'argomento.

Appena avrò completato la parte di lettura della signature, con l'HVSP, sempre col prezioso aiuto di Astro, dovrò caricvare nello sketch una notevole tabella dei micro, che ho già (grazie UWE!), ma che devo implementare. Alla fine otterrò qualcosa del tipo (i valori sono inventati!)

1e950f ATmega328P 62dff9 P 1e93ff ATtiny85 62dfff S

Cioè per ogni micro devo memorizzare sia la signature che i fuse di default che la tecnica di programmazione necessaria (hvPp o hvSp). Le domande che mi vengono sono queste: Che tipo di array devo usare? Mi creerà problemi di memoria ram (ad occhio sono un centinaio di righe, ma alla fine potrei accontentarmi delle 25 relative ai processori che ho provato)? Se ho problemi potrei creare una tabella in forma di file (sarebbe anche meglio, più facilmente aggiornabile nel tempo)? Ma sarebbe accessibile dal firmware Una volta che ottengo i tre valori di signature dal micro come faccio a farli diventare una stringa unica? Che tecnica mi conviene usare per confrontare questa stringa con l'array per estrapolare le altre info? Così una volta letta la signature posso chiedere all'utente se vuole leggere i fuse, se li vuole scrivere o se vuole ripristinare quelli di fabbrica (caso bricked), ed in automatico scelgo la procedura da seguire. Che ne dite? sarebbe un bel lavoro no? Consigli?

menniti:
Ora sono al lavoro ma nelklo sketch originale questa cosa del # è spiegata, infatti la usano davanti a tutte le define, p.es., e la usando anche negli if/endif del setup

Sono casi differenti, però. Le direttive per il compilatore sono istruzioni particolari che servono a creare il sorgente originale. Ad esempio, tu puoi mettere una porzione di codice dipendente dal micro.
Faccio un esempio più concreto. Mettiamo che devi scegliere un registro in base al micro, Atmega328 o Attiny85. Se tu metti un semplice if il tuo sketch conterrà sia la porzione di codice per il primo che per il secondo. Se metti un #if allora il compilatore includerà nello sketch solo la parte che occorre, salvando spazio. Questo è un caso stupido, ma rende l’idea.

ci sono una ventina di #include all’inizio e servono tutte (perché quelle inutili le ho levate io di crudo), ho un qualche vantaggio dal lasciarli?

Dipende.

@ Leo: non lo so, ho sempre pensato che trattandosi di hex andasse scritto 10 e non 16, può essere allora che stia funzionando ma che i valori in decimale siano sempre > 10 (0A se non sbaglio…); però ho provato 0x10 senza successo, vero è che la forma era quella #, quindi quando torno verifico.

Sono 2 forme differenti per rappresentare lo stesso numero. Scrivere 0x10 o 16 sono indifferenti. E’ sempre un valore di 0b00010000 :stuck_out_tongue:

Quando hai un po’ di tempo pensa all’altra problematica :slight_smile:

menniti:
Quando hai un po’ di tempo pensa all’altra problematica :slight_smile:

Ehm… non ricordo… :sweat_smile:

:fearful: sta storia del pollo al sale ti ha ferito profondamente :P ma è il post prima della tua ultima risposta :drooling_face:

menniti: Appena avrò completato la parte di lettura della signature, con l'HVSP, sempre col prezioso aiuto di Astro, dovrò caricvare nello sketch una notevole tabella dei micro, che ho già (grazie UWE!), ma che devo implementare. Alla fine otterrò qualcosa del tipo (i valori sono inventati!)

1e950f ATmega328P 62dff9 P 1e93ff ATtiny85 62dfff S

Cioè per ogni micro devo memorizzare sia la signature che i fuse di default che la tecnica di programmazione necessaria (hvPp o hvSp). Le domande che mi vengono sono queste: Che tipo di array devo usare? Mi creerà problemi di memoria ram (ad occhio sono un centinaio di righe, ma alla fine potrei accontentarmi delle 25 relative ai processori che ho provato)? Se ho problemi potrei creare una tabella in forma di file (sarebbe anche meglio, più facilmente aggiornabile nel tempo)? Ma sarebbe accessibile dal firmware Una volta che ottengo i tre valori di signature dal micro come faccio a farli diventare una stringa unica? Che tecnica mi conviene usare per confrontare questa stringa con l'array per estrapolare le altre info? Così una volta letta la signature posso chiedere all'utente se vuole leggere i fuse, se li vuole scrivere o se vuole ripristinare quelli di fabbrica (caso bricked), ed in automatico scelgo la procedura da seguire. Che ne dite? sarebbe un bel lavoro no? Consigli?

Uhm... E' un bel blocco di dati. Facciamo un calcolo. Se ogni voce deve contenere questi dati: 1e950f ATmega328P 62dff9 P abbiamo (senza gli spazi) più di 20 caratteri, ma devi stare largo perché potresti avere qualcosa tipo ATmega1284P nel nome. Quindi diciamo una media di 25 caratteri. Se li salvi come stringa di caratteri, sei nella cacc... ;) 25*100=2500! Impossibile in RAM. Magari nella flash con PROGMEM.

Oppure... la signature la devi salvare in 3 byte, così come la leggi. Il nome devi salvarlo in formato intero. L'altro codice alfanumerico (i fuse, immagino) devi salvarli come byte anch'essi. L'ultimo come char.

Puoi usare anche un file su SD ma lo sketch cresce enormemente: aggiungi 10/12 kB solo per includere la libreria SD.

Ora che ci penso alla fine lavorerò in stand-alone e quindi niente file "esterni", né posso implementare un lettore SD, progettazione hw chiusa. E con l'eeprom potrei fare qualcosa? altrimenti mi rassegno e metto solo la trentina di micro noti sui quali ho fatto le prove, però mi piacerebbe avere la possibilità di identificare un bel numero di micro.

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.

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

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.

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

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?