|
Ciao, a mio avviso la cosa non è cosi' compicata.
Per prima cosa il DS1233 non è vero che asserisce /RESET solo per 350 mSec. Quello che succede è che quando la tensione scende al di sotto del valore di tolleranza /RESET va basso e vi rimane fino a quando persiste la condizione. Se la tensione dovesse risalire lui attende 350mS prima di tirare su nuovamente /RESET. In tal senso 350mSec sono di delay sul ripristino della condizione di normalità. E' fatto apposta per mantenere la linea bassa mentre tutti gli altri circuiti di un microprocessore si stabilizzano prima che arrivi il reset.
Inoltre non mi serve di essere sincronizzato. La condizione rilevata dal supervisore basta in quanto il resto lo faccio via software. Appena determino la condizione di /RESET inizio a contare quante volte (quanto tempo) la linea di reset viene mantenuta bassa. Se è un glitch momentaneo e torna su prima dello scadere di una finestra predeterminata ignoro la condizione e resetto il contatore. Se permane oltre un certo tempo allora interrompo proprio il treno di impulsi verso il gate in quanto è chiaro che la batteria sta cadendo. Attendo quindi un tempo lungo intorno al secondo prima di riarmare la condizione.
Ovviamente regolando le soglie temporali di intervento posso modellare ogni comportamento, da quello istantaneo con conseguenti problemi che hai descritto a quello in cui rilevata una condizione bassa per troppo tempo interrompo tutto e non riarmo più fino a reset hardware del sistema.
La complessità aggiuntiva del software è molto limitata e come hardware si tratta solo di qualche resistenza e zener. Comunque sempre meglio di non avere proprio la funzione.
L'approccio di cambiare processore ed usare un convertitore A/D a bordo è sicuramente più oneroso a livello software in quanto devi implementare anche delle routine di calcolo almeno a virgola fissa per campionare e manipolare aritmenticamente i valori letti.
Comunque se hai qualche altra soluzione implementabile sono sempre pronto a discuterla.
Ciao, :-) Fabio.
|