Ho usato avrdude per leggere i fuse byte del microcontrollore originale montato sulla 2009, il risultato è questo:
Low fuse: 0xff
High fuse: 0xda
Extended fuse: 0x5
Il comando usato è questo:
avrdude -p m328p -c avrispmkii -P usb:40:03 -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h
Ora avendo avuto a che fare con i datasheet e con i fuse so per certo che l'extended del 328 ha solo i primi 3 bit che hanno significato, questi impostano Brown-out Detector trigger level, che di default vale 0xff, cioè non c'è impastata nessuna soglia.
Il valore non rientra nemmeno tra quelli riservati spiegato nel datasheet.
Ora mi chiedo se le altre 2009 hanno anche questa impostazione fuori range e cosa comporta?
Se osservi il file /arduino-0021/hardware/arduino/boards.txt vedrai le impostazioni predefinite dei fuse.
Per la 2009 l'efuse è proprio a 0x05.
FuseCalc dice che ci sono dei bit indefiniti quindi possono essere letti o 0 o 1.
Il risultato non cambia.
Però riporta per un valore 0xFF un corrispondente valore 0x07, non 0x05. 0x05 lo imposta solo usando il BOD a 2,7V.
Quindi immagino che di default i micro 328 dell'Arduino abbiano invece il BOD attivo: anche le UNO hanno questo fuse a 0x05
Ok grazie leo, il mistero è risolto.
Quando in un byte fuse ci sono dei bit a cui non è assegnata nessuna funzione il valore dei bit rimanenti possono essere passati ad avrdude
negati o no.
Il valore di default è 0xff (255) che negato ~0xff = 0
ora il valore 0x5 negato vale ~0x5=0xfa, che equivale ad impostare BODLEVEL a 2.7 volts.
Ok, però perchè se il datasheet (pag-296 tab27-6) riporta che i bit a cui non è assegnata alcuna funzione sono impostati ad 1, si usa il valore negato mancando di coerenza.
0x7 è il valore di default 0xFF considerando i bit non assegnati tutti posti a zero, cioè 00000111.
Non so se può servire una conferma, è un comportamento di cui solo ora onestamente e finalmente capisco la ratio, quindi mi sembra corretto fornire info a mia volta, non voglio fare la sanguisuga mascherata.
Il programmatore HV a cui sto lavorando, se programmo l'EFuse a 0x05, alla successiva lettura dei valori memorizzati mi restituisce in effetti 0xFA e se mando 0x07 (ma anche altri valori che ora non ricordo) mi restituisce 0xFF, ma poiché io via software non glielo sto dicendo di sicuro credo che sia il micro che si auto-imposti questi valori come hai appena spiegato, quindi non serve stare lì a studiare metodi di conversione perché secondo me se la vede lui.
La conferma è legata al fatto che se invece mando direttamente 0xFA o 0xFF i valori vengono memorizzati così come sono.
Il programmatore HV a cui sto lavorando, se programmo l'EFuse a 0x05, alla successiva lettura dei valori memorizzati mi restituisce in effetti 0xFA e se mando 0x07 (ma anche altri valori che ora non ricordo) mi restituisce 0xFF, ma poiché io via software non glielo sto dicendo di sicuro credo che sia il micro che si auto-imposti questi valori come hai appena spiegato, quindi non serve stare lì a studiare metodi di conversione perché secondo me se la vede lui.
Ciao Manny, io però se tramite avrdude scrivo 0x5 poi questo leggo, quindi non ci ho capito più niente chi è che fa la conversione nel tuo caso?
Perchè se non la fai tu tramite codice sorgente la fà il micro? boooo
E se la fà il micro com'è che il mio non la fà, non è che il polacco ti ha dato dei micro intelligenti?
PS: non ti fare prendere la mano perchè se no da un discorso proficuo va a finire a chiacchere e barzellette, io farò il possibile.
Io ora ho questo problema d'affrontare:
dopo avere letto i fuse, devo aggiornare la GUI in modo che mi mostri i checkbox marcati correttamente.
Ancora non ho provato a mandare alla GUI il valore 0x5, ma sono quasi certo che mi mostrera i fuse bit marcati al contrario.
Un attimo. Come ha spiegato Mauro, esistono delle equivalenze di valori perché i bit non utilizzati possono essere in un qualunque stato indefinito. E ci sono delle equivalenze per cui $FF corrisponde a $07 dato che per il micro avere 0b11111111 oppure 0b00000111 è indifferente.
Però si tratta sempre di avere il BOD disattivato (1 corrisponde a NON impostato, nella logica dei fuse). Un conto è avere $05/$FA: questa è l'impostazione predefinita di Arduino, come puoi vedere Mike dal file boards.txt.
Quindi penso che sia normale trovare $FA dopo che hai programmato in HV il micro se ciò lo hai fatto con l'IDE di Arduino.
@Mauro:
alcuni micro vogliono i valori opposti di quelli che dice FuseCalc, quelli segnati in rosso per capirsi. Ad esempio, se prendi gli Attiny85 e cerchi di programmare l'efuse con $FF otterrai un errore da parte di avrdude che ti informerà che la verifica dell'efuse non è andata a buon fine. Se invece programmi il micro con il valore in rosso, $05, $07 ecc... l'operazione va a buon fine.
Allora, posto che io non sono un programmatore, quindi non sono in condizioni di fornirti tutte le risposte che ti servono, mi limito a darti tutte le informazioni che ho. Uso un software scritto dalla Mightyohm che però sto adattando al mio schema hardware, molto diverso dal loro, anche se il loro mi è servito per l'idea di partenza, senza che vai a perderci tempo, posso assicurarti che nello sketch (che invio banalmente tramite i/f usb-seriale ad un 328 in stand alone) non avviene alcuna conversione del valore che immetto tramite serial monitor, tale valore viene memorizzato in una variabile "efuse" che viene pari pari usata nella stringa di scrittura del fuse.
Allo stesso modo lo sketch va, a mia richiesta, a leggere i fuse del micro collegato e li mostra in hex.
Da qui deduco che è il micro a fare questa conversione, oppure potrebbe essere l'IDE, al momento della lettura, ma io qui mi perdo completamente e inizierei a dire sciocchezze.
Comprendo la tua perplessità e il tuo ragionamento logico, ma io le prove le ho fatte su 7 diverse famiglie di micro e il polacco mi ha fornito solo i 328, alcune addirittura mi sono arrivate direttamente da ATMEL, ma naturalmente il problema riguarda solo quelle che hanno un E_Fuse, quindi mi pare solo gli ATmega.
Sulla tua ultima frase non ci capisco nulla, a parte che tu dici che scrivi 0x05 ma ritieni che la GUI ti mostrerà 0XFA, se è così sarebbe la prova che la conversione la fa l'IDE, nel mio caso e non, come io pensavo, il micro?
@ Leo: con questo intervento mi pare che tu stia confermando l'ipotesi che la conversione la faccia il software; posso solo prenderne atto, non è campo mio. Riguardo i valori "in rosso" se ricordi fu proprio la mia prova con lo 0x07 che mi permise di riuscire ad applicare per la prima volta ai 328 la tecnica che tu stavi sperimentando con i tiny85; infatti anche i 328 a volte s'incavolano se NON gli dai 0x07
C'è però da aggiungere una cosa importante, a questo punto: Io ottengo questa situazione ANCHE con la mia I/F MCP2200 ed il Windows HyperTerminal, quindi stando assolutamente alla larga da Arduino & IDE, allora forse la problematica sale più in alto, a livello del S.O. o in generale dei serial software?
@Mike:
una domanda, per capire meglio. Ma se tu ad un micro mandi l'HV (12V) cosa leggi dopo sui fuse?
Se resetti in HV il micro, dovrebbero venir resettati anche i fuse, per cui verranno reimpostati tutti i loro bit al valore di default, che è $FF/$07, ossia con i bit su NON impostato (che è 1).
Se invece leggi altri valori, e non usi l'IDE, allora c'è qualcosa che non torna.
Io non ho mai provato a mandare semplicemente 12V al reset senza programmare i fuse, se è questo che intendi; la prova puoi farla da solo, programma un micro vergine per 16MHz e poi alimentalo a 5V e mandagli 12V tramite una R da 1K al pin reset, secondo me non succede assolutamente nulla ed il micro ti continua a funzionare a 16MHz.
Io credo che i 12 volt applicati al reset servano per effettuare una commutazione interna di qualcosa che a 5V non commuta, permettendoti di agire sui fuse in modo diretto, NON a resettarlo di crudo.
Io sto lavorando in modo da far partire i 12V dopo aver scritto i valori dei fuse sullo schermo, per spegnerli subito dopo il write nel micro; sto usando un pin del 328 master per mandare i 5V allo step-up (sempre tramite un TR amplificatore) quando confermo l'operazione di scrittura, così genero i 12V e li mando al reset, scrivo i fuse e poi mando in LOW il pin del 328 e spengo lo step-up.
Ah, ok.
Pensavo ad un reset "bruto" coi 12V, una specie di fiammata alla "ratto" tanto per capirsi ]:D. Invece no, ho dato un'occhiata allo schema di quel programmatore HV che c'è in rete ed è come dici tu. I 12V vengono mandati al pin di reset al posto dei 5V ma poi viene programmato il micro nella solita maniera, ossia con i pin MOSI/MISO/SCK (SPI insomma).
leo72:
Ah, ok.
Pensavo ad un reset "bruto" coi 12V, una specie di fiammata alla "ratto" tanto per capirsi ]:D. Invece no, ho dato un'occhiata allo schema di quel programmatore HV che c'è in rete ed è come dici tu. I 12V vengono mandati al pin di reset al posto dei 5V ma poi viene programmato il micro nella solita maniera, ossia con i pin MOSI/MISO/SCK (SPI insomma).
Lascia stare ratto, l'ultima volta che ci trovammo a parlare di HV gli si drizzarono i baffetti, non pensando che per High Voltage si intendessero SOLO 12V, lui sperava di poter usare i suoi 30KV, spero non l'abbia fatto, altrimenti all'anagrafe ora c'è un 328 che non è mai esistito, dubito che ne sia rimasta traccia, tra le mani di quel giovane assassino.
Comprendo la tua perplessità e il tuo ragionamento logico, ma io le prove le ho fatte su 7 diverse famiglie di micro e il polacco mi ha fornito solo i 328, alcune addirittura mi sono arrivate direttamente da ATMEL, ma naturalmente il problema riguarda solo quelle che hanno un E_Fuse, quindi mi pare solo gli ATmega.
Comunque era una battuta, non penso seriamente che ci siano delle differenze tra i tuoi micro ed il mio.
Ho dato uno sguardo veloce al software http://mightyohm.com/files/hvrescue21/HVRescue_Shield212_sketch.zip
e non mi pare ci sia conversione di valore, però ho guardato molto velocemente. Io dico che c'è una conversione, cioè vengono
modificati i primi 3 bit e gli altri sono fissi ad uno.
alcuni micro vogliono i valori opposti di quelli che dice FuseCalc, quelli segnati in rosso per capirsi. Ad esempio, se prendi gli Attiny85 e cerchi di programmare l'efuse con $FF otterrai un errore da parte di avrdude che ti informerà che la verifica dell'efuse non è andata a buon fine. Se invece programmi il micro con il valore in rosso, $05, $07 ecc... l'operazione va a buon fine.
Ok questo non lo sapevo, quali sono questi micro almeno le sigle che conosci tu, cosi modifico logica altrimenti,
faccio un programma che funziona con alcuni micro e con altri nisba.
leo72:
Ah, ok.
Pensavo ad un reset "bruto" coi 12V, una specie di fiammata alla "ratto" tanto per capirsi ]:D. Invece no, ho dato un'occhiata allo schema di quel programmatore HV che c'è in rete ed è come dici tu. I 12V vengono mandati al pin di reset al posto dei 5V ma poi viene programmato il micro nella solita maniera, ossia con i pin MOSI/MISO/SCK (SPI insomma).
Lascia stare ratto, l'ultima volta che ci trovammo a parlare di HV gli si drizzarono i baffetti, non pensando che per High Voltage si intendessero SOLO 12V, lui sperava di poter usare i suoi 30KV, spero non l'abbia fatto, altrimenti all'anagrafe ora c'è un 328 che non è mai esistito, dubito che ne sia rimasta traccia, tra le mani di quel giovane assassino.
Mi erano sfuggiti questi due bei commeni
Beh.. dei 7 Atmega e dei 3 Attiny che ho comprato nessuno è ancora defunto ne si è mai brikkato... ora vedete voi chi sono quelli che li trattano male
Comprendo la tua perplessità e il tuo ragionamento logico, ma io le prove le ho fatte su 7 diverse famiglie di micro e il polacco mi ha fornito solo i 328, alcune addirittura mi sono arrivate direttamente da ATMEL, ma naturalmente il problema riguarda solo quelle che hanno un E_Fuse, quindi mi pare solo gli ATmega.
Comunque era una battuta, non penso seriamente che ci siano delle differenze tra i tuoi micro ed il mio.
Lo so, infatti mi riferivo al lato serio della tua affermazione, che aveva una sua logica, però nei giorni scorsi qualcuno aveva tirato fuori una mezza battuta sui micro "usati" venduti dal Polacco, ma più che altro per dirti che il problema non è solo dei mega328.
Ho dato uno sguardo veloce al software http://mightyohm.com/files/hvrescue21/HVRescue_Shield212_sketch.zip
e non mi pare ci sia conversione di valore, però ho guardato molto velocemente. Io dico che c'è una conversione, cioè vengono
modificati i primi 3 bit e gli altri sono fissi ad uno.
Io non sono in grado di valutare corretamente quello sketch, sto facendo implementazioni e manipolazioni, ma la sostanze di lettura e scrittura non la tocco, almeno per ora. Mi pareva solo di aver visto che il dato che mi richiede e che scrivo tramite tastiera del PC, poi viene usato direttamente nella stringa di write del fuse, ecco perché penso non sia convertito in altro valore; però questa cosa voorei capirla, non mi dispoacerebbe se alla fine avessi una risposta certa, visto che a mia volta dovrò spiegarla in qualche modo questa problematica, e non amo improvvisare; se lo guardi meglio fammi sapere.
alcuni micro vogliono i valori opposti di quelli che dice FuseCalc, quelli segnati in rosso per capirsi. Ad esempio, se prendi gli Attiny85 e cerchi di programmare l'efuse con $FF otterrai un errore da parte di avrdude che ti informerà che la verifica dell'efuse non è andata a buon fine. Se invece programmi il micro con il valore in rosso, $05, $07 ecc... l'operazione va a buon fine.
Ok questo non lo sapevo, quali sono questi micro almeno le sigle che conosci tu, cosi modifico logica altrimenti,
faccio un programma che funziona con alcuni micro e con altri nisba.
Ok, ciao.
Io mi pare di averli trovati solo degli atmega328 e nei tiny85 anche se, in realtà, sono quelli con cui lavoro di più, quindi potrebbe riguardare altri la cosa. Però se non sbaglio, il valore dell'EFuse (come dicevo prima) in alcuni micro nemmeno è previsto (basta selezionare il micro nel FuseCalc e vedi sparire la terza cella), inoltre la programmazione dell'EFuse non è sempre obbligatoria, visto che FF è quasi sempre di default, quando è previsto è sufficiente NON programmare l'EFuse e si supera la cosa, secondo me. Però ciò che dice Leo è vero nella programmazione tramite ISP dove, peraltro, abbiamo visto che i fuse non vengono toccati se non tramite caricamento del bootloader, cosa non fattibile nei tiny85; Con l'HV, ripeto, il micro accetta qualsiasi valore e poi però mostra quello corretto.
Su differenti micro l'efuse controlla differenti cose.
Ad esempio sui 328 e sui 644 controlla il BOD, mentre sui Tiny84/85 controlla l'autoprogrammazione (SELFPRGEN). In pratica, infatti, sui Tiny io non li tocco mai. Li ho toccati per test sul 328 per attivare/disattivare la funzione BOD
leo72:
Su differenti micro l'efuse controlla differenti cose.
Ad esempio sui 328 e sui 644 controlla il BOD, mentre sui Tiny84/85 controlla l'autoprogrammazione (SELFPRGEN). In pratica, infatti, sui Tiny io non li tocco mai. Li ho toccati per test sul 328 per attivare/disattivare la funzione BOD
Su differenti micro l'efuse controlla differenti cose.
Ad esempio sui 328 e sui 644 controlla il BOD, mentre sui Tiny84/85 controlla l'autoprogrammazione (SELFPRGEN). In pratica, infatti, sui Tiny io non li tocco mai. Li ho toccati per test sul 328 per attivare/disattivare la funzione BOD
Azz, io avevo capito che alcuni micro considerano un bit fuse programmato quando posto a 1 anzichè a zero come consueto.
Ripeto la logica è sempre quella: 1 non programmato Zero programmato, o no?
Ok, avrdudequi funziona con AVRISP MKII, vorrei iserire anche il programmatore che hai tu (adafruit) e poi aggiorno il repo, così ti do la possibilità
di provarlo (non hai scuse).
Ma non ho idea cosa accade quando colleghi il tuo programmatore, mi servirebbe l'output di hal-device, sempre che c'è sulla tua distrò.
I fuse hanno logica "inversa":
1 sta per NON programmato, 0 per programmato
Adesso sono con Xubuntu 11.04 e HAL non c'è, e manco c'è sul mio portatile dove ho Arch.
Però se ti interessa, il mio USBtinyISP restituisce questi ID al sistema, che poi Udev usa per i permessi: http://arduino.cc/forum/index.php/topic,36567.0.html
Adesso sono con Xubuntu 11.04 e HAL non c'è, e manco c'è sul mio portatile dove ho Arch.
Però se ti interessa, il mio USBtinyISP restituisce questi ID al sistema, che poi Udev usa per i permessi:
Ok, quindi lo vede come usb e non come usb-serial, questo vuol dire che tu usi l'argomento -P usb giusto, oppure
c'è un modulo del kernel e quindi c'è anche un device file tipo ttyUSBx o altro.
Se è così, lo vede come vede avrisp mkii, e quindi lo aggiungo subito.
