Go Down

Topic: autoReset con ponticello (Read 1 time) previous topic - next topic

Janos

Premetto che non ho seguito tutta la discussione, ma per fare il reset con u piedino, per risolvere il problema del tempo che il reset deve essere attivo, perché non utilizzare un multivibratore monostabile?

leo72

Sì, difatti era la soluz. proposta da superlol.
Cmq un NE555 ha bisogno di circuiteria accessoria, un Tiny in standalone no.

pablos

Puo' sembrare inutile o una stupidaggine che qualcosa debba verificare se il controllore si inchioda. Ti viene spontaneo dire, se si inchioda è perchè ha sbagliato qualcosa nel software, secondo me non è sempre così.
Pensa, se un sistema nel suo complesso fosse in grado di capire se qualcosa è andato storto e fa ripartire tutto, nel mio programma quando Arduino riparte scrive nel log che c'e' stato un restart, tu potresti vederlo dal log se effettivamente c'e' stato un autorestart ed eventualmente risolvere il problema in un secodo tempo, ma il tutto sarebbe in grado di stare inpiedi senza il tuo intervento. Ovviamente il restart resetterebbe tutti gli stati, ma anche qui nel mio piccolo software tutti gli output vengono salvati e riletti al riavvio per riportare tutto come era prima del reset.
Anche una modifica dei setup richiedono un riavvio che sia remoto o locale, ecco perchè ritengo che un autoreset sia importante
ciao
no comment

leo72

Se devi fare solo il log di un reset, non è un grosso problema. Basta che nel tuo sketch, in setup(), ci sia una registrazione dell'avvio. Quindi, ogni votla che lo sketch parte salva data e ora. E' un riavvio, quindi abbiamo risolto il problema che volevi salvate tutte le volte che la scheda veniva resettata.

Adesso veniamo al "come". Un circuito completamente esterno è da scartare, perché deve essere attivato manualmente (da un segnale via telefono o dal micro stesso) per cui non va bene: non potrebbe capire cosa succede all'interno della scheda.
Se pensi di usare un reset software, devi esser certo che il tuo codice non si pianti mai, altrimenti non potrebbe funzionare. Dicendo che se il tuo codice si infila in un loop infinito, questo potrebbe dipendere da tante cose (non so cosa fa e come lo fa, il tuo sketch).

Resta la soluzione del watchdog, magari impostato per un tempo molto lungo, il più possibile lungo (non per tempi dell'ordine dei ms). E qui forse potresti trovare la soluzione. Imposti il watchdog su questo tempo e se lo sketch si infila in un vicolo cieco, viene resettato.

AnTrea

A questo punto, non esiste un reset software per il wiznet?
Arduino, MODs e DIY: blackstufflabs.com

leo72

Non conosco i Wiznet, non so come funzionano.

astrobeed


Adesso veniamo al "come". Un circuito completamente esterno è da scartare, perché deve essere attivato manualmente (da un segnale via telefono o dal micro stesso) per cui non va bene: non potrebbe capire cosa succede all'interno della scheda.


State facendo un sacco di confusione, prima di tutto se il micro va in crash per motivi software oppure a causa di disturbi elettrici, ed è questa la causa più frequente, non c'è modo di resettarlo da software visto che è stato perso il controllo, il reset deve essere da hardware tramite circuiteria indipendente, ovvero il watchdog.
Se il micro non ha un suo watchdog interno esistono appositi ic esterni che svolgono questa funzione, in pratica sono dei timer programmabili che se non ricevono un impulso su un loro pin entro il tempo limite attivano il reset del micro agendo direttamente sul relativo pin, ovviamente questa soluzione prevede l'utilizzo di un pin del micro sul quale il software deve generare l'impulso di ripristino entro il tempo limite.
Il reset da software si usa solamente se è necessario far partire del software ausiliario normalmente non eseguito, p.e. un bootloader che voglio attivare a richiesta dal software sul pc senza dover resettare il micro a mano, in questo caso il jump alla locazione zero è il modo classico di procedere per ottenere il reset software se non è presente la specifica istruzione assembly RESET che effettua un vero e proprio reset hardware.
Per quanto riguarda l'eventuale log degli errori che richiedono un reset non è possibile farlo a software per il semplice motivo che nel momento in cui il micro si pianta non puoi eseguire nessuna operazione prestabilita visto che o si è bloccato nel vero senso della parola oppure esegue operazioni a casaccio, alcuni micro hanno un apposito registro che riporta gli eventuali stati che hanno causato il reset o una sospensione temporanea dell'esecuzione come nel caso del brown out, registro che è gestito in hardware e viene resettato solo dalla condizione POR (Power On Reset) o manualmente da software.

leo72

Ma è quello che ho detto io nei precedenti interventi  ;)

Se il codice è piantato, un reset software (il classico "jump") non funziona perché il flusso del programma non arriverebbe mai a richiamare la funzione.

Se il micro è controllato esternamente da un altro circuito che "veglia" mediante la conta di un impulso su un pin, anche in questo caso il segnale andrebbe dato via software, e come lo fai: con un interrupt il segnale arriverebbe sempre ma non è detto che sia tutto il micro piantato. La CPU potrebbe essere in un loop infinito dello sketch ma l'interrupt dovrebbe comunque proseguire, giusto?

A 'sto punto il watchdog mi pare l'unica soluzione percorribile.

Il log non è invece difficile. Basta metterlo nel setup(), così da registrare tutte le volte che il micro viene riavviato. Se poi vogliamo fare le cose fatte bene, esiste un registro che tiene conto di quale causa ha scatenato il reset, se esterno o interno (watchdog). All'avvio basta verificare che non sia un reset esterno (pulsantino) e loggare la data e l'ora del riavvio.

superlol

ma fare un salto a 0x00 non equivale a mantenere la memoria ram?

in tal caso si può fare un "backup" della ram da salvare ai crash e vedere se qualcosa non torna..
Il nuovo forum italiano sull'elettronica: http://www.electroit.tk/ <--- Nuovamente online!

leo72


ma fare un salto a 0x00 non equivale a mantenere la memoria ram?

In teoria sì.

Quote

in tal caso si può fare un "backup" della ram da salvare ai crash e vedere se qualcosa non torna..

Servirebbe un dispositivo esterno per leggerla e salvarla in un file senza alterarla.
Che io sappia non ci sono istruzioni di Arduino che permettono (come nel caso della EEPROM interna) di leggere/scrivere direttamente nella SRAM: devi usare l'assembly direttamente. Però si pone un problema: nella SRAM vengono creati l'heap e lo stack, oltre alle variabili dichiarate dall'utente. Al riavvio il suo contenuto verrebbe alterato. Servirebbe un circuito esterno che:
1) venga informato del reset sull'Arduino o Atmega328
2) blocchi il micro tenendo un segnale LOW sul pin di reset
3) avvii un sistema di comunicazione ISP verso il micro per dare un dump della SRAM in un file
4) sblocchi il micro rilasciando il segnale sul pin di reset

Lo vedo complesso

Ma, io ho un arduino uno v1 con ethernet shield prima versione, quella senza i contatti per li poe, che è acceso da circa 6 mesi ininterrottamente e non da problemi.
Devo dire che:

  • Il traffico di rete è bassissimo, potocollo telnet.

  • Il circuito è dopo un gruppo di continuità e non si possono verificare strani transienti sull'alimentazione che fermino il codice dell'arduino, senza resettarlo, mentre arrivano pacchetti sulla ethernet.


Aggiungo che durante le prove che avevo fatto con quell'hardware degli strani problemi con il web server li avevo avuti.
In questi giorni sto provando una v2 con la nuova ethernet shield, quella con i contatti per il poe, e funziona tutto alla grande, con invii di files multipli dalla sd, senza blocchi o rallentamenti.

Alberto

Go Up