[RISOLTO] ATMega328 - Arduino AVR ISP - set fuse

Non guardate l'ora del post, sto andando a lavoro e prima scrivo due righe...
Ieri sera ho provato a caricare il Blink sugli arduino standalone (Panduino) che ho fatto.
Con la guida di Menny non ho avuto problemi, all'occorrenza ho disabilitato il reset con resistenza e condensatore.
Sebbene l'upload vada a buon fine ho dei risultati stranissimi.

Il blink con delay 1000... lampeggia ogni 18 secondi circa.
Se sposto il delay a 10 il lampeggio è più rapido, circa un 1 secondo.

L'unica differenza che vedo io, ma me ne accorgo solo ora, è che i chip che ho comprato sono:
ATmega 328P-PU con una piccola sigla " 1112 "
Mentre il chip sulla 2009 ha la sigla " 1123 ".
Altre differenze non noto, a livello hardware.

Idee di cosa possa essere?
Grazie

il numero "in più" che leggi sui due ic, altro non è che lotto di produzione con notazione anno-numero settimana. quindi non ci dovrebbero essere differenze funzionali nei due atmega.
Clock non a 16mhz?
Fuse errati?

La differenza di tempo tra i due test è strana, nel primo caso hai un rapporto 1:18 nel secondo caso 1:100, comunque verifica attentamente il valore del quarzo, le capacità di carico, le saldature e la continuità delle piste, i fuse.

Anche a me pare che sia un problema di fuse, dato che i chip vergini senza bootloader sono impostati di fabbrica a 1 MHz, e tornerebbe anche dato che lei dice che ha 1 lampeggio ogni 18 sec. circa, che è simile al rapporto 1:16 che si ha con il clock dell'Arduino, di 16 MHz appunto.
Sul delay(10) non mi pronuncio: 10*16=160->0,16s, dovrebbe essere un lampeggio molto rapido. Aspettiamo la Dany che ci dia dei dati più precisi sul micro.

leo72:
Anche a me pare che sia un problema di fuse, dato che i chip vergini senza bootloader sono impostati di fabbrica a 1 MHz, e tornerebbe anche dato che lei dice che ha 1 lampeggio ogni 18 sec. circa, che è simile al rapporto 1:16 che si ha con il clock dell'Arduino, di 16 MHz appunto.

Infatti in prima battuta suggerisce che non ha settato correttamente i fuse del clock e del prescaler 1:8, l'ATmega sta ancora funzionando a 1 MHz come da chip nuovo, forse il secondo test l'ha fatto con 100, il 10 potrebbe essere un refuso, e i conti tornerebbero.

Non era un refuso, ho davvero settato delay 10, però potrei sbagliarmi nel tempo del lampeggio veloce... Misurando ad occhio potrebbero essere 500 ms od altro... Mettiamola così, non era veloce come dovrebbe essere a 10.
Il quarzo è a 16, le saldature mi sembrano ok per quanto ho potuto verificare con il tester.
Se mi dite come riprogrammare i fuse nel primo pomeriggio sono a casa e faccio un tentativo, io mi ero limitata a seguire la guida di menny copiando pari pari i passaggi.
Scusate se scrivo sintetica ma sono dall'iphone

DanielaES:
Scusate se scrivo sintetica ma sono dall'iphone

Se non hai settato i fuse allora il tuo ATmega sta lavorando a 1 MHz invece di 16, tutti gli AVR nuovi hanno il fuse del clock settato per l'oscillatore rc interno, 8 MHz, e il prescaler 1:8 attivo.

Con la scusa del pranzare a casa ho risolto, stasera dico come e quando e percome ed aggiorno il titolo.
Però mi Sa che nella guida di menny manca un pezzo, o forse non l'ho letta bene io ieri sera, al momento non l'ho davanti.
Ora menny di sicuro mi gambizza...

Semplicemente, quando vuoi far cambiare i fuse al micro devi prima caricare il bootloader e poi, sempre con la procedura ISP, lo sketch che ovviamente sovrascriverà il bootloader, se stai usando le mie board virtuali.
La procedura ISP cambia i fuse SOLO se fai l'operazione del bootloader, se invece la usi direttamente per lo sketch i tempi operano in modo stranissimo.
Pag. 54 della Guida:

Nota importante: nelle immagini seguenti vedremo anche la configurazione Arduino-ISP-Breadboard minimal, con la quale si potrà effettuare il caricamento di sketch, ma deve essere ben chiaro che il buon fine di questa tecnica presuppone che il chip abbia già i fuses settati per lavorare a 8MHz o 1MHz; ciò significa, in poche parole, che la prima volta che si prepara un chip a lavorare con una di queste frequenze, l’operazione deve essere fatta o con due Arduino o con Arduino ed una breadboard in configurazione completa, cioè con quarzo, condensatori, ecc.; questo vale sia che il chip sia vergine, sia che il chip abbia già un bootloader standard a 16MHz, con o senza uno sketch.
Inoltre, se una qualsiasi operazione su chip a 8MHz/1MHz non va a buon fine è molto probabile che non si riesca più a programmarlo con la breadboard minimal, bisogna quindi ripartire dal caricamento del bootloader con breadboard standard o con Arduino target.
È bene tener conto di queste indicazioni, diversamente si andrà incontro ad una sicura serie di insuccessi!

Non ti gambizzo perché non tocco roba pelosa, specialmente se di natura maschile :grin:

menniti:
La procedura ISP cambia i fuse SOLO se fai l'operazione del bootloader, se invece la usi direttamente per lo sketch i tempi operano in modo stranissimo.

Perche' mettere in campo le "stranezze" ?

io direi semplicemente che per cambiare i fuse si deve passare per il caricamento del bootloader, anche se il bootloader non ti serve, se carichi solo uno sketch in ISP i fuse restano come erano, non e' che si mettono in condizioni "strane"

Il perche' non si riesce a cambiare i fuse tramite caricamento sketch non e' dato sapere, o almeno per ora nessuno alk mondo lo ha spiegato :slight_smile:

Testato:

menniti:
La procedura ISP cambia i fuse SOLO se fai l'operazione del bootloader, se invece la usi direttamente per lo sketch i tempi operano in modo stranissimo.

Perche' mettere in campo le "stranezze" ?

io direi semplicemente che per cambiare i fuse si deve passare per il caricamento del bootloader, anche se il bootloader non ti serve, se carichi solo uno sketch in ISP i fuse restano come erano, non e' che si mettono in condizioni "strane"

Il perche' non si riesce a cambiare i fuse tramite caricamento sketch non e' dato sapere, o almeno per ora nessuno alk mondo lo ha spiegato :slight_smile:

Se fai le centinaia di prove che ho fatto io le stranezze le vedi eccome! Non c'è un confine netto tra cambiano i fuse/non cambiano i fuse. Esempio se hai un micro impostato a 8MHz interno e ci carichi su uno sketch ISP per un micro a 16MHZ NON hai necessariamente i tempi dimezzati, ed un sacco di cose del genere; a volte fain la stessa manovra due volte ed i valori dei tempi sono completamente differenti; mi è capitato proprio l'altro giorno, mentre testavo il mio Programmatore ISP, di vedere il classico blink in cui l'accensione durava un secondo e lo spegnimento 16 secondi, me la dai una spiegazione tecnica senza tirare in ballo "stranezze"?
Ciò che è certo (e vale solo per la xx8 family) è che il caricamento del bootloader imposta i fuse in base ai valori della board virtuale, ciò che NON è assolutamente certo è cosa succede quando invii uno sketch ISP usando una board virtuale impostat in modo differente dal micro, poco ma sicuro.
Poiché intanto ho terminato anche l'HV Programmer appena ho un po' di tempo voglio provare a leggere i valori dei fuse quando vedo queste "stranezze", per capire se comunque la programmazione ISP di uno sketch non cambi qualcosa anche senza il caricamento del bootloader.

menniti:
Ciò che è certo (e vale solo per la xx8 family) è che il caricamento del bootloader imposta i fuse in base ai valori della board virtuale, ciò che NON è assolutamente certo è cosa succede quando invii uno sketch ISP usando una board virtuale impostat in modo differente dal micro,

Invece la cosa è chiarissima e semplicissima, per scrivere i fuse devi darli sotto forma di comando ad avrdude, p.e. la riga di comando che usa l'IDE 1.0 per caricare il bootloader tramite sketch isp è la seguente:

...\Arduino\arduino-1.0\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -cstk500v1 -P\\.\COM4 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xde:m -Ulfuse:w:0xff:m

Mentre per programmare uno sketch tramite Arduino come isp è la seguente dove non sono indicati i fuse.

..\Arduino\arduino-1.0\hardware/tools/avr/bin/avrdude -CD:\Elettronica\Arduino\arduino-1.0\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -cstk500v1 -P\\.\COM4 -b19200 - flash:w:C:\DOCUME~1\IMPOST~1\Temp\build3418427712630493306.tmp\BlinkWithoutDelay.cpp.hex:i

Generalizzando possiamo dire che se vuoi programmare anche i fuse, validi per il 328, quando invii uno sketch devi aggiungere i seguenti comandi alla riga per avrdude:

-Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xde:m -Ulfuse:w:0xff:m

Dal punto di vista di avrdude caricare il bootloader o uno sketch è la stessa identica operazione.

Quello che dici è scienza esatta, sono prove che abbiamo fatto tante volte con successo; però io sto parlando della programmazione ISP tramite IDE 0022, senza riga di comando; infatti parlo della sola famiglia xx8 in quanto in tutte le altre i fuse sono programmabili SOLO tramite linea di comando.
Usando l'IDE 0022 (parlo di questa versione che è la mia) tu puoi inviare tramite ArduinoISP il bootloader o uno sketch.
Nel primo caso il micro viene programmato con i fuse contenuti nella board settata nell'IDE ed è pronto per ricevere sketch via seriale.
Nel secondo caso lo sketch "danneggia" il bootloader ed infatti lo usiamo solo per circuiti in stand-alone; ma se inviamo uno sketch ad un micro tramite ArduinoISP il micro non prende i fuse della board settata, ma succedono cose disparate. Tutto qui.

menniti:
Nel secondo caso lo sketch "danneggia" il bootloader ed infatti lo usiamo solo per circuiti in stand-alone; ma se inviamo uno sketch ad un micro tramite ArduinoISP il micro non prende i fuse della board settata, ma succedono cose disparate. Tutto qui.

Guarda che la spiegazione è in quello che ho postato prima, se programmi il bootloader da IDE, non importa se 0022 o 1.0, vengono inviati anche i comandi per i fuse, se programmi solo sketch non vengono inviati i comandi per i fuse, se vuoi modificarli devi aggiungere alla riga di comando di avrdude i necessari comandi, e sono validi per tutti i modelli di AVR e non solo per alcuni.

Testato:
Il perche' non si riesce a cambiare i fuse tramite caricamento sketch non e' dato sapere, o almeno per ora nessuno alk mondo lo ha spiegato :slight_smile:

Chi ha progettato l'IDE ha fatto sì che i fuse fossero cambiati solo durante la flashatura del bootloader. Considera che tutto ruota intorno all'Arduino, che è una scheda impostata per lavorare sempre ad una data frequenza, quindi non è necessario impostare il clock al micro tutte le volte che mandi uno sketch, lo fai una volta sola quando metti il bootloader, e poi il chip è pronto all'uso, rimanendo sempre nella configurazione impostata.

Cmq anche caricare uno sketch con avrdude da terminale non altera i fuse, per cambiarli devi espressamente specificarlo. Così come puoi cambiare i fuse al micro SENZA cancellare la flash.

astrobeed:

menniti:
Nel secondo caso lo sketch "danneggia" il bootloader ed infatti lo usiamo solo per circuiti in stand-alone; ma se inviamo uno sketch ad un micro tramite ArduinoISP il micro non prende i fuse della board settata, ma succedono cose disparate. Tutto qui.

Guarda che la spiegazione è in quello che ho postato prima, se programmi il bootloader da IDE, non importa se 0022 o 1.0, vengono inviati anche i comandi per i fuse, se programmi solo sketch non vengono inviati i comandi per i fuse, se vuoi modificarli devi aggiungere alla riga di comando di avrdude i necessari comandi, e sono validi per tutti i modelli di AVR e non solo per alcuni.

Sì, stiamo dicendo la stessa cosa, per me è tutto chiaro.

e no, non e' la stessa cosa, permettimi :slight_smile:

io, astro e leo stiamo dicendo che non ci sono stranezze (in piu' loro hanno chiarito anche il perche')

cioe' l'ide arduino e' programmato appositamente per cambiare i fuse solo con il caricamento bootloader, tu invece riferisci "stranezze"

Volendo, essendo opensource l'ide, si potrebbe modificare in modo da cambiare i fuse anche durante il caricamento di skcetch via ISP

Caspita, la discussione è andata avanti parecchio :slight_smile:
Cmq come dicevo ho risolto, ho provato (a monte della discussione) a scrivere il bootloader, e poi caricare lo sketch... ora funziona tutto, anzi ricordatevi di guardare le foto che posto nel topic di aggiornamento :slight_smile:

menniti:
Semplicemente, quando vuoi far cambiare i fuse al micro devi prima caricare il bootloader e poi, sempre con la procedura ISP, lo sketch che ovviamente sovrascriverà il bootloader, se stai usando le mie board virtuali.

Menny, la tua guida è davvero ottima, la riprova è che una come me - che a dirla tutta nemmeno sapeva bene cosa stava facendo - in un numero limitato di tentativi è riuscita nell'intento.
Al di la di questo, però, secondo me dovresti specificare meglio questa questione nella guida.
Hai fatto uno sforzo notevole per rendere ultra comprensibili tutti i passaggi ma, secondo la mia niubbagine, questa questione è rimasta criptica.
La pagina che hai riportato, che avevo letto, parla di preparare un chip per lavorare a frequenze di 8 o 1 MHz... che non centra molto con il problema che ho avuto io :
Sicuramente per chiunque abbia esperienza quella nota è immediatamente comprensibile, ma per chi ci capisce poco la questione è diversa.
Si compra un chip vergine, il chip vergine è di fabbrica settato ad una frequenza diversa dai 16 canonici di arduino. Non è possibile settare i fuses caricando uno sketch. I fuses possono essere settati solo tramite bootloader.
Se si compra un chip vergine la prima ed obbligatoria operazione per avere i classici 16MHz deve essere mettere il bootloader.
Questa cosa dovrebbe essere scritta a lettere capitali ad inizio guida :stuck_out_tongue:

Ripeto la guida è ottima ma manca una spiegazione chiara su questa questione.
Sempre in my humble opinion :slight_smile:

@ Testato: ho spiegato chiaramente cosa sono le stranezze a cui mi riferisco e le ribadisco: lo stess osketch, caricato diverse volte su diversi chip, settati ad una stessa frequenza, usando una board virtuale con fuse settati per una frequenza diversa, danno comportamenti differenti e STRANI.
Altrimenti SPEGATEMI questo comportamento:
Micro settato a 16MHz (convinto invece che fosse vergine e quindi a 1MHz)
Carico via ISP il blink
Sulla board ISP Programmer il led si accende per 1 secondo, si spegne per 16 secondi, si accende per 1 secondo e così via.
Ho provato a "simulare" questa cosa ripetendo l'"errore" ma stavolta ho avuto un comportamento diverso
Non me li sono segnati, ma di questi comportamenti anomali ne ho visti a decine, e mi riferisco ai tempi in cui facevo prove per la guida.

@ Daniela: prendo atto, ma a mia memoria è la prima volta che qualcuno mi fa questa obiezione, probabilmente perché la prima operazione della Guida è proprio il caricamento del bootloader a 16MHz, quindi magari molti avranno fatto questo test e si saranno trovati bene; comunque appena possibile aggiungo un paragrafetto in cui scrivo chiaramente questa cosa. Tutto è migliorabile, anche la tua attenzione.... :wink:

menniti:
@ Daniela:prendo atto, ma a mia memoria è la prima volta che qualcuno mi fa questa obiezione
Tutto è migliorabile, anche la tua attenzione.... :wink:

Menny... non era un obiezione, non siamo ad un processo :slight_smile:
Riportavo la mia esperienza con la tua guida, sperando ti potesse essere utile.
Non avendo letto nulla che indicasse di seguire un ordine preciso, sono andata liberamente secondo le esigenze :slight_smile:
Tutto qui...

@ Testato: ho spiegato chiaramente cosa sono le stranezze a cui mi riferisco e le ribadisco: lo stess osketch, caricato diverse volte su diversi chip, settati ad una stessa frequenza, usando una board virtuale con fuse settati per una frequenza diversa, danno comportamenti differenti e STRANI.
Altrimenti SPEGATEMI questo comportamento:
comportamenti anomali ne ho visti a decine, e mi riferisco ai tempi in cui facevo prove per la guida.

Ragazzi ma, sembra a me, o c'è un pochino di tensione sul forum ultimamente?
Cmq, se (condizionale!) ho capito quello di cui state parlando... confermo il comportamento strano.
Due chip vergini, caricato lo stesso blink con delay 1000.
Sul primo il led lampeggiava ad intervalli di 18 secondi, sul secondo ad intervalli di 14.
Magari i secondi non saranno precisi, perché li contavo ad occhio, ma la differenza era chiaramente verificabile.