Reset arduino

Dopo aver corretto alcuni bug del mio programma mi serve un sistema che mi resetti l'arduino in casi critici! ho provato ad inserire il watchdog ma devo aver sbagliato qualcosa e l'arduino mi si resettava di continuo, e non c'era versi di ricaricare il programma, ho dovuto usare un altro arduino come programmatore e ricaricarci il boot loder...

l'altra soluzione che ho provato e collegare il PIN reset con un pin digitale e in caso di necessita mandare l'uscita bassa! non funziona...mando l'uscita bassa, si resetta ma non parte finchè non stacco materialmente il cavetto tra pinreset e pin9 (si resetta di continuo..) ho anche provato a dare 2 istruzioni di seguito prima low e poi high per cercare di fare un impulso senza che la porta mi rimanga bassa e lo faccia resettare di continuo...ma non funziona.. eppure setto l'uscita alta nella fase di setup e la reimposto alta come prima istruzione del loop...

come posso fare per resettare questo maledetto via soft? sarebbe ottimo usare il watchdog ma ora ho paura a reinserirlo nuovamente, visto che causa tempi stretti ho montato glia rduini e smotarli non sarebbe facile

Il reset avviene collegando a massa il pin reset, non collegandolo ad un pin digitale/analogico

Forse dirò un'eresia, insultatemi pure Non si potrebbe usare un transistor NPN tipo bc547 per portare la massa al pin reset da un'uscita digitale?

mettere un pin digitale uscita bassa è come metterlo a massa ... per il watch dog avete idee?

va collegato a GROUND

Va semplicemente portato a 0 logico, poi che lo fai tramite un pulsante collegandolo a GND oppure tramite un out digitale non cambia nulla. Direttamente dal data sheet del 328 sezione 8.2 Reset Source:


• External Reset. The MCU is reset when a low level is present on the RESET pin for longer than the minimum pulse length.


ah si? io avevo sempre letto che non funzionasse in questo modo. Proverò sicuramente...

Dove l'avresti letto ? In questi casi fa testo solo il datasheet del componente.

Non capisco una cosa: ma perché resettare il uC? A che ti serve? Non puoi prevedere una condizione di reimpostazione a zero delle variabili interne?

La domanda della necessitá di resettare il Microcontroller é giusta da chiedere. Se il programma si blocca dopo un po di tempo e solo un reset risolve il problema vuol dire che c'é un errore nel programma. Io indagerei in questa direzione.

Il reset esterno (dal pin RESET) ha una ben preciso percoso di essere eseguito.

Quando viene messo a massa il pin di reset il controller interrompe l' esecuzione del programma e mette i valori di default nei registri interni (anche i Pin I/O). Dopo che il segnale di reset ritorna inattivo (a HIGH) il controller aspetta un certo tempo (selezionabile da dei fuse bit) perché si stabilizza la tensione di alimentazione (pensato durante l'accensione) e riprende l' esecuzione del programma all' indirizzo di memoria memorizzato nel vettore reset (un indirizzo a 2 Byte). Quello salta nel Arduino al Bootloader.

Ogni comando dopo che il reset parte non vienen eseguito!!

Se metti un uscita a L , il comando seguente di metterla a H non verrá eseguito. Dovrebbe funzionare collegare un uscita al pin di reset e portarlo a LOW. Nel tempo dove non viene generato un reset il pin deve essere definito come entrata perché senó non é possibile nessun altra fonte di reset (pulsante reset o DTS dal interfaccia USB) Se questo non funziona si puó mettere tra pin di uscita e Reset un condensatore da 0,1µF. Cosí il peset viene triggerato sul cambio di stato da H a L ( come fatto tra Interfaccia USB e ATmega.

Ciao Uwe

@ Astrobeet:

Direttamente dal data sheet del 328 sezione 8.2 Reset Source:

la sezione é 10.2 http://www.atmel.com/dyn/resources/prod_documents/doc8161.pdf

Ciao Uwe

uwefed: la sezione é 10.2 http://www.atmel.com/dyn/resources/prod_documents/doc8161.pdf

Dipende dalla revisione del data sheet, mi sono appena accorto che quello che uso è di qualche mese più vecchio dell'ultima release, praticamente dicono le stesse cose però cambiano diverse cose nell'impaginazione. In tutti i casi è sempre meglio fare riferimento alla release più recente dei data sheet.

astrobeed: Dove l'avresti letto ? In questi casi fa testo solo il datasheet del componente.

Pardon, ricordavo male, era semplicemente fortemente sconsigliato, qui http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1242921510/6 è Massimo Banzi che dice

  1. Collegare un piedino digitale al piedino "Reset" sulla scheda ma la Atmel non garantisce che funzioni (la spiegazione è abbastanza tecnica e rasenta la masturbazione mentale)

Per generare un impulso non credo che basti scrivere digitalWrite HIGH seguito da digitalWrite LOW perchè (se funziona come i PLC) le uscite vengono processate tutte a file ciclo, quindi tu avresti sempre lo stato LOW sull'uscita.

Per generare un impulso della durata di un ciclo macchina devi settare l'uscita e resettarla al ciclo successivo con l'aiuto di una variabile.

es

se variabile è alta uscita = bassa

se variabile é bassa uscita = alta variabile = alta

e poi comunque non credo che funzioni per 2 motivi:

  • L'impulso può non avere la durata sufficiente per effettuare il reset
  • Devi usare sempre un transistor per invertire la logica perchè l'uscita non può essere già alta appena accendi il micro, quindi l'arduino continuerebba a resettarsi all'infinito

Secondo me devi usare un transistor NPN che quando l'uscita va alta manda il pin di reset a massa.

il problema è che il uC si blocca...e non si capisce il perchè...e si blocca non in corrispondenza di un evento, ma a caso...temo sia colpa della ethernet...non si pianta il programma, ma semplicemente funziona male..a questo punto penso sia colpa della ethernet, con un contatore di pacchetti persi ho intenzione di pilotare un relè che mette a massa il pin reset quando, mi sembra l'unica soluziobne

Non potrebbe dipendere da cadute di tensione? Che cosa hai oltre lo shield ethernet?

Ambrogio: Per generare un impulso non credo che basti scrivere digitalWrite HIGH seguito da digitalWrite LOW perchè (se funziona come i PLC) le uscite vengono processate tutte a file ciclo, quindi tu avresti sempre lo stato LOW sull'uscita.

Per generare un impulso della durata di un ciclo macchina devi settare l'uscita e resettarla al ciclo successivo con l'aiuto di una variabile.

es

se variabile è alta uscita = bassa

se variabile é bassa uscita = alta variabile = alta

e poi comunque non credo che funzioni per 2 motivi:

  • L'impulso può non avere la durata sufficiente per effettuare il reset
  • Devi usare sempre un transistor per invertire la logica perchè l'uscita non può essere già alta appena accendi il micro, quindi l'arduino continuerebba a resettarsi all'infinito

Secondo me devi usare un transistor NPN che quando l'uscita va alta manda il pin di reset a massa.

comunque il micro non funziona come un plc quindi se nello stesso ciclo mandi alto e poi basso un pin lui lo esegue cosi :)

GianfrancoPa: Pardon, ricordavo male, era semplicemente fortemente sconsigliato, qui http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1242921510/6 è Massimo Banzi che dice

Premesso che io sto facendo un discorso in generale per quanto riguarda il controllo del pin RESET, cioè si può usare un'uscita digitale per farlo, poi se l'utilizzo di un pin del micro per eseguire questa operazione crea problemi non lo so, in teoria non dovrebbero esserci, però se lo dice ATmel ovviamente è così. Volendo è possibile resettare il programma, ma non il micro, usando l'assembler inline ed eseguire una JMP 0, cosa che normalmente risolve la stragrande maggioranza dei problemi dovuti a crash del software o loop infiniti, il reset hardware del micro serve molto raramente.

Dopo essermi riletto il thread linkato, mi par di capire che: 1) il metodo dell'autoreset tramite pin non va bene perché al reset il micro imposta tutti i pin su alta impedenza, quindi in pratica annulla il segnale di LOW che il pin di reset sta ricevendo col risultato che il tempo per cui il micro ha "sentito" il segnale di reset potrebbe non essere sufficiente a richiamare il reset. Il tutto si traduce nell'ingresso del micro in una specie di stato di trance, in cui è a metà tra un reset completo ed un blocco... XD 2) il reset software del "JMP $0000" funziona a metà, nel senso che: 1) deve essere chiamato dal codice; 2) lascia la RAM intatta per cui tutte le variabili continuano a contenere i valori che avevano al momento del riavvio dello sketch 3) il metodo del watchdog pare creare dei problemi.

Secondo me la soluzione finale è quella di scrivere del codice migliore (cioè con più test alle spalle), così da eliminare la necessità di dover "sbloccare" il micro tramite un reset che, a mio parere, dovrebbe servire solo quando il micro va in blocco come effetto di cause esterne (corto o simili).

Il data sheet dell'ATmega 328p riporta che la durata minima dell'impulso per il reset deve essere di 2.5us, con il clock a 16 MHz sono 40 cicli macchina. Sul data sheet non è elencata la sequenza delle operazione, e i tempi, durante il reset hardware, sicuramente sta su qualche nota tecnica che non ho voglia di mettermi a cercare, però è molto facile che tra le prime cose che vengono eseguite c'è proprio la disattivazione di tutti i pin del micro, stato di alta impedenza, col risultato che l'impulso di reset dura meno dei 2.5us attesi con relativi problemi. In tutti i casi il reset hardware del micro da software non serve a nulla per il semplice che se è necessaria questa operazione vuol dire che si è letteralmente piantato e di conseguenza non è possibile gestire questa cosa da software. Il reset hardware del micro può essere utilizzato da altri componenti esterni al micro per vari motivi, per esempio per reinizializzare il tutto dopo un determinato evento oppure da un watchdog esterno, se non viene reinizializzato periodicamente resetta il micro per riavviarlo. Anche il reset hardware non cancella la memoria RAM, però reinizializza tutti i registri macchina, eseguendo una jmp 0x00 si esegue il reset software che non riporta alla condizione di default i registri macchina però li reinizializza come previsto da programma. La ram può essere sia cancellata che non cancellata automaticamente, dipende dalle opzioni utilizzate in fase di compilazione, c'è una porzione di programma, che l'utente non vede, introdotta dal compilatore che serve per inizalizzare l'ambiente di lavoro. Toccherebbe verificare, magari è una prova che faccio oggi pomeriggio, se la compilazione dello sketch, rammento che alla fine diventa un programma in C compilato tramite GCC, tra le opzioni prevede la cancellazione della ram oppure no, in tutti i casi non è un problema perché è buona norma preinizializzare sempre tutte le variabili globali, e quelle statiche, nel momento in cui vengono create, per quelle locali non serve perché sono a perdere. Mentre il reset hardware da software non serve praticamente a nulla, quello software tramite salto alla prima locazione della memoria flash è una pratica usuale perché serve si usa per attivare particolari funzioni del software, p.e. attivare il bootloader da comando invece che solo tramite reset, oppure per sbloccare una situazione critica tramite un interrupt su un timer, una specie di watchdog implementato a software. L'uso del watchdog hardware con Arduino funziona senza problemi a patto di saperlo usare.

non sono cadute di tensione...è alimentato a 12 volt con una batteria tampone e caricabatterie da allarme!.. ho il 2009, la sheild ethernet, collegato ad un access point e una scheda relè! avevo pensato alle extratensioni generate da un contattore 3kw 380v, a l'ho staccato e fa uguale deve essere un problema della ethernet