Go Down

Topic: Autoreset, questo sconosciuto (Read 11511 times) previous topic - next topic

astrobeed


in pratica la R va tra +5V e il positivo del C? Allora evidentemente si è trattato di un'errata interpretazione dei collegamenti, in precedenza, visto che anche lì c'erano una R da 120 e un C da 10µF in serie rispetto al +5, solo che il negativo del C invece che sul Reset era collegato a massa, mentre sul reset andava il punto di giunzione R-C.


Con la r in serie al condensatore tra +5V e il condensatore chiuso verso GND non limiti in nessun modo la corrente che scorre attraverso il condensatore da 100nf, l'energia la prende dal condensatore da 10 uf e non attraverso la resistenza, questa serve solo garantire una ricarica veloce del condensatore, che comunque attraverso la 10k avviene lo stesso in meno di un secondo (partendo dalla scarica completa) quindi assolutamente inutile abbassare questo valore.
In pratica potrebbe bastare la sola resistenza da 120 ohm tra +5V e reset, è in parallelo alla pull up da 10k del reset, ma a differenza del condensatore da 10 uf, che ha una limitata quantità di energia, questa può far scorrere indefinitamente fino a 42 mA, cosa che in caso di errori/distrazioni può creare non pochi problemi.

Quote

Un dubbio: col "vecchio" sistema era possibile fare ripetuti upload sul chip stand alone ma non era ovviamente possibile aggiornare l'eventuale sketch (magari per fare una prova "locale") su Arduino, è sempre la stessa cosa, o abbiamo qualche miglioria in tal senso?


Non cambia nulla perché se tieni bloccato l'autoreset di Arduino non puoi caricare un nuovo sketch a meno che non premi fisicamente il tasto di reset.

Michele Menniti

Grazie, posso approfittare sull'argomento "reset"?
Sto facendo un po' di prove con l'HVFuse, per la programazione del chip mediante l'applicazione di una tensione di 12V al pin reset del chip, per circa un secondo, il tempo di programmare i fusibili. Sto sperimentando dei circuitini che mi permettono di "eliminare" due smd (così faccio un pcb realizzabile senza problemi): un booster che tira fuori 12V a partire dai 5 di Arduino ed un circuito npn-pnp per switchare la tensione di 12V al reset usando un impulso HIGH proveniente da un pin di Arduino. Mi manca un elemento fondamenlate: la corrente richiesta dal pin reset a 12V affinché si possano programmare i fusibili. Questo dato mi serve sia per capire se il booster che sto provando va bene (dovrebbe erogare circa 20mA) che per calcolarmi la R di limitazione dei 12V verso il reset del chip.
Puoi darmi qualche indicazione o al limite qualche schema alternativo? Ripeto l'esigenza è fare un pcb semplice da montare (non per me che sarei attrezzato...) e risparmiare qualche cent.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

astrobeed


che per calcolarmi la R di limitazione dei 12V verso il reset del chip.


Il data sheet non riporta la corrente massima richiesta dal reset quando gli si collegano i 12 Volt, però se la memoria non mi inganna non servono più di pochi uA, quindi una bella resistenza in serie da 1k giusto per limitare la massima corrente che può fluire su quella linea.
Al limite basta fare una semplice verifica strumentale, metti in serie al reset la r da 1k, fornisci il 12V e controlla con l'oscilloscopio (DSO) come varia la tensione ai capi della resistenza che in questo caso diventa uno shunt per la misura della corrente.

Michele Menniti

Bene, la prova la faccio per curiosità, ma se sono pochi µA sono a posto, il booster va benissimo, resta lo schema per l'ampli di tensione, da quanto ho capito devo per forza usare un npn che pilota un pnp, altrimenti il solo npn (in uscita dal micro ho un impulso HIGH per il pilotaggio) non conduce nella configurazione a collettore comune. La conferma me la dà proprio la configurazione del chip smd che devo eliminare, fatta in questo modo, anche se speravo di "cavarmela" col solo npn.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

MauroTec

Quote
Dal punto di vista elettronico viene sfruttato il segnale standard della RS232 DTR (Data Terminal Ready) che normalmente si trova a 1 logico e va a 0 durante la trasmissione dei dati.


Ok, ho seguito tutte le discussioni e voglio fare alcune considerazioni dal lato software:
perchè è necessario resettare arduino board sempre è comunque?
In effetti il DTR messo alto fà parte della prodedura di riconoscimento fatta da avrdude quando comunica con la board. Comunicare con la board significa in sostanza comunicare con il software installato nel micro, software che è il conosciutissimo bootloader.

Avrdude invia dei dati in seriale e si aspetta una determinata risposta, quando questa non è corretta avrdude visualizza il messagio stk500 not in sync (o simile).

Quindi la procedura di reset serve per dialogare con il bootloader, perchè questo entra in azione solo dopo il reset.

Dalla lettura dei post capisco che quando una board arduino viene usata come programmatore ICSP, questo auto reset su questa board non è gradito.
Quindi se ho capito bene, lato software basterebbe mettere nella configurazione dell'ide un flag, es autoreset.disable = true.

Quanto detto mi fa pensare al fatto che il programma ICSP da mettere su arduino non prevede l'uso di un bootloader, cioè non ha necessità di "switchare" tra bootloader e user code, ma dall'altro lato leggo che per la uno board il nuovo bootloader risolve il problema.

La cosa mi interessa lato software per il programma che sto sviluppando (arvdudequi). Al momento sono fermo per vari motivi (uno attendo di fare aquisti, micro ecc).
Alla fine la domanda è:
La cosa è risolvibile lato software evitando di abilitare il DTR, quando si sta usando la board con il programma ICISP?
Ci sarebbe da vedere se questo segnale deve comunque essere cambiato perchè previsto dal protocollo implementato dal programma ICISP, se fosse così non c'è verso di aggire lato software, se non modificando il bootloader come sembra sia stato fatto per l'optiboot, anche se la cosa non mi convince.

Non ho le idee molto chiare in merito, posso chiarirmele leggendo il codice, ma se c'è qualcuno che le ha già più chiare delle mie (idee) lo ascolterei con piacere.

Ciao.
AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

Michele Menniti

Ciao MT, in poche parole:
usando Arduino come ISP a volte ci si scontra con questo problema dell'autoreset che impedisce di caricare sun un chip stand alone il bootloader o uno sketch qualsiasi. Il problema è legato al singolo hardware, si può verificare indifferentemente su una UNO o 2009 o anche su una compatibile, se si verifica, su quella board si verifica sempre. P.es. la mia UNO funziona senza problemi, la mia 2009 invece richiede la disabilitazione.
L'intervento hardware non è invasivo e serve comunque solo per questi casi.
Se ci fosse un flag software sarebbe certamente comodo, ma dubito che l'IDE lo preveda, invece questo nuovo optiboot "scoperto" da leo sembra risolvere il problema sulle UNO (almeno sulla sua), ma lo lascia sulle 2009, il cui bl è diverso.
Spero di esserti stato utile.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

astrobeed

#21
Jun 20, 2011, 01:55 pm Last Edit: Jun 20, 2011, 01:58 pm by astrobeed Reason: 1

perchè è necessario resettare arduino board sempre è comunque?


Infatti non è necessario, serve resettare solo per avviare il bootloader o per sbloccare una condizione di crash o loop eterno.

Quote

In effetti il DTR messo alto fà parte della prodedura di riconoscimento fatta da avrdude quando comunica con la board.


No, Avrdude non sa nemmeno cosa sia DTR, è un segnale standard della RS232 ed è gestito in automatico dall'hardware/software della seriale, non importa se è una vera com o una seriale virtuale, inoltre la stato alto è quello normale per DTR anche se la seriale non è in uso.

Quote

Dalla lettura dei post capisco che quando una board arduino viene usata come programmatore ICSP, questo auto reset su questa board non è gradito.


Il problema autoreset ISP a quanto pare si pone solo con la UNO, sulla 2009 non c'è o comunque è raro che si verifichi, dovrebbe essere legato alle diverse temporizzazione usate dall'optiboot e dal bootloader della 2009, non ho indagato a fondo su questa cosa.
In realtà il vero motivo per bloccare l'autoreset è l'uso pratico di Arduino quando serve comunicare tramite la porta seriale USB, ogni volta che la apri Arduino viene resettato perché DTR cambia di stato.

Quote

Quindi se ho capito bene, lato software basterebbe mettere nella configurazione dell'ide un flag, es autoreset.disable = true.


Non è così semplice, o meglio sarebbe possibile farlo sulla UNO visto che l'USB è gestita da un micro tramite il quale sarebbe possibile gestire il reset in diverso modo, p.e. tramite uno specifico comando inviato dall'IDE e non tramite un segnale della RS232.

Quote

Quanto detto mi fa pensare al fatto che il programma ICSP da mettere su arduino non prevede l'uso di un bootloader, cioè non ha necessità di "switchare" tra bootloader e user code, ma dall'altro lato leggo che per la uno board il nuovo bootloader risolve il problema.


Ribadisco quanto sopra, la questione ISP è secondaria, il vero problema è che l'autoreset resetta Arduino ogni volta che apri la seriale virtuale indipendentemente dal fatto che lo programmi o meno, per verificarlo basta che apri il terminale seriale mentre gira uno sketch e puoi constatare da solo come Arduino resetti ogni volta che lo fai.
Volendo si può bypassare la questione reset ogni volta che si apre la Vcom da un eventuale programma utente che riceve i dati da Arduino, ma non è una cosa semplicissima da mettere in atto e non è detto che il linguaggio di programmazione lo permetta.
Rimane comunque il fatto che spesso e volentieri la verifica/ricezione dati da Arduino viene fatta tramite il terminale dell'IDE o altro programma emulazione terminale che resettano sistematicamente Arduino ogni volta che si apre la comunicaizone.

Quote

La cosa è risolvibile lato software evitando di abilitare il DTR, quando si sta usando la board con il programma ICISP?


Si se sai come farlo e se disponi dei giusti strumenti di lavoro software, ma varrebbe solo per un software utente e non per l'IDE.

Quote

Ci sarebbe da vedere se questo segnale deve comunque essere cambiato perchè previsto dal protocollo implementato dal programma ICISP, se fosse così non c'è verso di aggire lato software, se non modificando il bootloader come sembra sia stato fatto per l'optiboot, anche se la cosa non mi convince.


Anche il bootloader non sa cosa sia DTR, e non gli serve saperlo, non esiste nessuna modifica al bootloader che può risolvere la questione visto che DTR altro non fa che portare il pin reset a 0 logico, non puoi bloccare l'autoreset dal bootloader.

Michele Menniti

Ciao Astrobeed, il mio penultimo intervento richiede la tua opinione, l'ultimo invece contrasta (per "esperienza") con un paio di tuoi punti, riguardo il problema con la 2009 (mie prove) e riguardo la questione dell'optiboot (almeno da quanto sostiene leo nel topic che ha aperto un paio di giorni fa).
Mi dai questi chiarimenti?
Grazie
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

astrobeed

Fatta la prova con il condensatore da 1uf, funziona perfettamente e la risposta del reset è praticamente identica a quella con il condensatore da 10 uf, idem per DTR.
Se metto una resistenza da 100 ohm in serie al condensatore per limitare il picco di corrente su DTR, si arriva al limite sul reset, nel mio caso ho rilevato 0 logico per 1.2 us, e infatti Arduino viene programmato, il che vuol dire che a seconda delle varie tolleranze ci si può trovare sia con l'autoreset bloccato che funzionante.
Tenuto conto che la resistenza in serie al condensatore era solo una precauzione al limite delle "pippe mentali", in realtà non ci sono problemi se non c'è, se proprio si vuole metterla deve essere al massimo da 33 ohm.


astrobeed


Mi dai questi chiarimenti?


Partendo dal fatto che dei test su qualche UNO e qualche 2009, che per giunta forniscono risultati completamente opposti, ha valenza statistica 0 penso che a questo punto se non si fa una analisi attenta e dettagliata del fenomeno è impossibile dire la vera causa e quando è realmente necessario bloccare l'autoreset con lo sketch ISP.
La modifica all'optiboot che risolverebbe la questione non l'ho controllata, anzi non ho nemmeno guardato se è disponibile il sorgente, per il semplice motivo che non mi interessa, però al massimo risolve la questione ISP, ma non il vero problema del reset ogni volta che si apre la Vcom come ho puntualizzato qualche post sopra.

leo72

L'Optiboot v.4 risolve il problema dell'autoreset usando lo sketch ArduinoISP. E' disponibile anche il sorgente: se vai al thread che ho linkato nel mio post, puoi scaricartelo e guardartelo.

A differenza tua, però, che punti a disabilitare l'autoreset su Vcom, il mio problema era appunto trovare un modo per far funzionare quello sketch senza condensatori. E con l'Optiboot v.4 risolvo.

OT:
gli Attiny sono andati, non sono riuscito a capire il motivo. Gli attacchi li ho fatti come sempre, ormai in automatico da quante volte ho collegato i pin. Il condensatore tra +5V e RST l'ho provato anche per programmare un Atmega328 e con quello non ho avuto problemi, mentre di Attiny ne ho "fritti" 2 su 2.

MauroTec

Ciao Atrobeed ricordi questo post http://arduino.cc/forum/index.php/topic,60774.msg439382.html#msg439382

Quote
No, Avrdude non sa nemmeno cosa sia DTR, è un segnale standard della RS232 ed è gestito in automatico dall'hardware/software della seriale, non importa se è una vera com o una seriale virtuale, inoltre la stato alto è quello normale per DTR anche se la seriale non è in uso.


Allora, vediamo se riusciamo a capirci, concordo con quanto dici, ma obbietto dicendo la seguente:
La seriale tipica dei pc è molto differente dalla comunicazione seriale implementate es sulla 2009, mancano alcuni segnali, cioè ci sono ma non vengono collegati al micro, tranne DTR che viene collegato come hai detto tu.
Il DTR come vedi da codice python è impostabile, è posso assicurarti che se non eseguo la sequenza:
Code: [Select]

print "Clear DTR and RTS to unload the RESET capacitor"  
ser.setRTS(False)
ser.setDTR(False)
print "attende x tempo"
time.sleep(1)
print "Set DTR and RTS back to high"
ser.setRTS(True)
ser.setDTR(True)

Il bootloader se mi risponde mi dice cose strane insomma non mi dice che è in sync.

Quindi a raggion veduta il DTR è gestibile, lo posso mandare su o giù prima di aprire il device, occhio che qui si può capire male, diciamo che posso aprire il device file impostando il DTR = false, dopo aver aperto il device posso modificare lo stato di tutti i flags, se lo posso fare in python lo si può fare in C++ e in java.
C'è solo una cosa che obbliga ad aprire un device a chiuderlo e riaprirlo ed è il baudrate, in quanto non mi risulta sia possibile modificarlo a caldo.

@Menny
Scusa ho anglofizato il tuo nick, non t'incazà :smiley-mr-green:
Allora avevo capito bene, non si capisce perchè in alcuni casi l'autoreset rompe ed in altri no.

Però non posso indagare sulle reali cause che fanno fallire l'operazione di scrittura, non ricordo se nel connettore
ICISP arrivi il reset, se si probabilmente è qua il problema, se per ipotesi prima di scrivere il micro su breadboard il programma ICISP invia il reset a questo pin e questo è connesso al pin reset di arduino questo si autoresetta.
Io l'ho sparata perchè non posso fare questi esperimenti al momento.

Ciao.
AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

astrobeed


L'Optiboot v.4 risolve il problema dell'autoreset usando lo sketch ArduinoISP. E' disponibile anche il sorgente: se vai al thread che ho linkato nel mio post, puoi scaricartelo e guardartelo.


Appena ho un attimo di tempo gli do uno sguardo.

Quote

gli Attiny sono andati, non sono riuscito a capire il motivo. Gli attacchi li ho fatti come sempre, ormai in automatico da quante volte ho collegato i pin. Il condensatore tra +5V e RST l'ho provato anche per programmare un Atmega328 e con quello non ho avuto problemi, mentre di Attiny ne ho "fritti" 2 su 2.


Questo è un bel mistero, però è ancora più strano che riesci a vederli dal programmatore e riprogrammarli, il danno che illustri non dovrebbe permettere questa cosa.

leo72

Oltretutto l'Optiboot v4. è anche più "compatto" rispetto a quello di serie. Inoltre risolve il problema dell'errato upload di sketch più grandi di ca. 30 kB nonostante lo spazio sul micro (32256 byte) permetterebbe l'operazione.

Guarda, se non sai spiegartelo tu, figurati io  XD
So solo che è comparso un segnale fisso HIGH di 4,80V sul 7° piedino (quello collegato al pin 13 dell'Arduino in modalità ISP) e che la tensionein uscita su un pin impostato su HIGH è di 4,80V ma non riesce a far illuminare un LED, immagino quindi che la corrente che ne esce sia ben sotto alla richiesta media di un LED (15/20 mA). Curiosamente anche cambiando piedino di output il risultato non cambia.
Il LED non è bruciato perché ho provato a cambiarlo e dà sempre lo stesso effetto. Ho cambiato anche resistenza ed addirittura anche a collegare il LED senza resistenza ma la luce prodotta è pochissima (si intravede appena in condizioni di scarsa illuminazione). Ho notato inoltre stamattina una tensione di 4,80V anche in uscita dal pin di reset! Quindi in pratica il pin è "forato" e perde corrente da tutte le parti  :smiley-roll-sweat:

Michele Menniti


OT:
gli Attiny sono andati, non sono riuscito a capire il motivo. Gli attacchi li ho fatti come sempre, ormai in automatico da quante volte ho collegato i pin. Il condensatore tra +5V e RST l'ho provato anche per programmare un Atmega328 e con quello non ho avuto problemi, mentre di Attiny ne ho "fritti" 2 su 2.


se sei sicuro che sono morti allora RIP 8) altrimenti, ripeto, conservali.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Go Up