Newsgroup: it.hobby.elettronica.digitale
Titolo: Affidabilita' eeprom

Salve a tutti,
Sto scrivendo un programma per un pic 16f876 e sono costretto ad
utilizzare la eeprom interna al micro.
La vita utile del circuito e' stimato intorno ai 4 anni.
In pratica il circuito e' alimentato in parallelo ad un carico:
Quando il carico e' acceso, e' acceso anche il circuito.
Quando il carico e' spento, lo e' anche il circuito.
L'accrocco deve tenere il conto di quante ore rimane attivato il carico
(ogni 100.000 ore deve dare un allarme per effettuare una manutenzione)
Ho pensato di tenere il conto delle ore di funzionamento all'interno
della eeprom in modo da mantenere il conto anche a circuito spento.
Una volta riacceso il carico, riprende anche il conteggio(dal punto
 indicato dal contenuto della eeprom).
Dato che l'hardware non mi permette di salvare il numero delle ore
nel momento esatto in cui si sta per togliere tensione al circuito, devo 
lavorare
con l'idea che l'alimentazione puo' venire meno in qualsiasi momento.
Ho pensato di aggiornare la eeprom ogni 10 minuti di funzionamento ottenendo
un errore limitato a pochi minuti nel conteggio delle ore per ogni
accensione-spegnimento-accensione.
Il punto e' questo :
se scrivo su una stessa locazione della eeprom ogni 10 minuti(4320 volte al 
mese), in teoria
per quanti mesi mi rimane affidabile questa locazione?
Dato che i tempi di sviluppo devono essere stretti non ho intenzione di 
usare le celle eeprom
in rotazione per distribuire "l'usura", in quanto mi complicherebbe troppo 
il firmware.
Ribadisco che il tutto dovrebbe rimanere affidabile per almeno 4 anni.
Grazie anticipatamente per le risposte.
 Massimo
IW0HKG 

 ha scritto nel messaggio 
news:47bb4b52$0$36444$4faf...@reader5.news.tin.it...

Ciao, ho avuto anche io questa esigenza e ti conviene progettare un 
circuitino che faccia calare l'alimentazione del micro lentamente 
segnalandoglielo: per salvare i tuoi dati tutto sommato hai bisogno di una 
ventina di ms. Prova a dare un'occhiata al datasheet del MAX691 ad esempio. 
In questo modo probabilmente non hai più bisogno della rotazione 

 In questo modo probabilmente non hai più bisogno della rotazione 
Quoto. Anche io ho fatto così.
Un'alternativa che ho usato ma che dipende dal "duty-cycle" di 
accensione del carico e da esigenze ulteriori è di usare una batteria 
ricaricabile per mettere in tampone il micro. Così lo spegnimento del 
carico lo rilevi semplicmente tramite un interrupt, aggiorni il 
contatore e torni a dormire :)
Il consumo è praticamente nullo.
Ancora, altra idea già sperimentata: non è il micro a essere in tampone 
ma un comunissimo RTC. All'accensione e allo spegnimento leggi l'ora e 
la salvi in memoria. Così hai anche i tempi precisi - sia nel senso di 
ore:minuti:secondi sia nel senso di stabilità temporale.
Ciao!
Marco / iw2nzm

 Ribadisco che il tutto dovrebbe rimanere affidabile per almeno 4 anni.
Bhe allora, se non vuoi risolverlo via firmware, l'unica soluzione è 
quella che ti hanno già consigliato: aggiungi hardware per rilevare lo 
spegnimento e salvi solo solo in quel frangente lì.
Ciao

 Ribadisco che il tutto dovrebbe rimanere affidabile per almeno 4 anni.
secondo me non ha senso preoccuparsi di 10 minuti su 4 anni se non hai un 
TCO per tenere conto del tempo che passa
considera anche che, per applicare la soluzione che ti hanno già proposto, 
potresti utilizzare un pic con LVD a bordo (serve proprio per far scattare 
un interrupt quando la tensione di alimentazione scende sotto una certa 
soglia che tu imposti)
-ice- 

 ha scritto nel messaggio 
news:ZsSuj.250068$%k.37...@twister2.libero.it...

Hai centrato il punto.
Da una lunga telefonata intercorsa ieri con chi mi ha fornito l'hardware e' 
emerso che effettivamente non mi serve una precisione eccezionale nel 
conteggio, anzi.
Su 100.000 ore di funzionamento posso tranquillamente
permettermi anche 100 ore e piu' di errore.
Molto probabilmente il carico verra' spento si e no una ventina di volte in 
4 anni.
Se porto l'aggiornamento della eeprom a 30 minuti o piu'  invece che 10 
dovrei rientrare nei 4 anni in cui il circuito deve essere affidabile.
Quanto detto da Capoccetta, il collega Marco trapanese, Francesco Sacchi, 
rimangono comunque alternative valide
se mi dovesse capitare qualche applicazione in cui la precisione e la 
coerenza temporale sono importanti e, soprattutto, nei casi in cui ho piu' 
voce in capitolo nella progettazione dell'hardware........
Ringrazio tutti coloro che mi hanno risposto per la loro gentilezza e la 
disponibilita'.
Non escludo che avro' altri quesiti da porre in merito.
Ciao
Massimo IW0HKG 

 dovrei rientrare nei 4 anni in cui il circuito deve essere affidabile.
solo per completare il discorso, in modo che possa eventualmente tornare 
utile a chi si troverà in futuro in questa situazione, aggiungo un'ulteriore 
possibilità: usare una eeprom ferromagnetica esterna su bus i2c (leggi e 
scrivi tutte le volte che vuoi) oppure una nvram (è una sram con batteria al 
litio incorporata che viene attivata in modo autonomo, 10 anni di 
memorizzazione garantita in assenza di alimentazione, non ha limiti di 
lettura/scrittura)
-ice- 

 wrote in message

Solo per essere precisi,
L'allarme non deve essere dato ogni 100.000 ore (circa 12 anni), ma
ogni 6 mesi di funzionamento (circa 5000 ore).
100.000 ore e' un altro parametro della macchina che con la mia
applicazione ci azzecca poco.E' un errore di valutazione che mi e'
sfuggito nel primo post e ho ripetuto nel successivo.
Quindi anche il  punto del post in cui mi riferisco al rapporto di
errore di 100 ore su 100.000 non deve essere preso in considerazione.
Chiedo scusa per la confusione.
Ciao
Massimo IW0HKG

 il firmware.
A pensarci un attimo non è mica così difficile scrivere qualcosa di grezzo 
(ma funzionale)!
Se hai blocchi di eeprom da 8 bit, puoi contare fino a 256. Mettiamo che 
riesci ad usarne 2, in modo da considerare una variabile da 16 bit, ognuna 
delle due locazioni verrà utilizzata 65536 volte. Se scrivi il tuo programma 
in modo che programmi gli indici della memoria da scrivere, è sufficiente 
una lettura delle prime 2 locazioni per capire se è il caso di cambiare 
cella, ed eventualmente shiftare il proprio lavoro nelle 2 locazioni 
successive.
Sono stato abbastanza chiaro ?
Qualcosa del genere, considerando che la EEprom è inizializzata a 0xFF e che 
si vada avanti decrementando
void main {
    unsigned int16 iCount;
    unsigned int8 iAddress;
    //ti consiglio di perdere un po' di tempo qui, per non stuzzicare 
elementi
    //critici come la EEprom in condizioni di alimentazione instabile
    delay_ms(5000)
    //trova la posizione
    iAddress = 0;
    iCount = eeprom_read(iAddress);
    iCount |= eeprom_read(iAddress+1);
    while (iCount) {
        iAddress += 2;
        iCount = eeprom_read(iAddress);
        iCount |= eeprom_read(iAddress+1);
    }
    //se arriva qui ha trovato una locazione decrementabile
    //iAddress dà informazioni sul numero di memorizzazioni e quindi del 
tempo passato
    // TODO: iniziare il ciclo di conteggio e memorizzazione!
    while(1) {
    .....
    //(delay??  abbi cura che il delay sia ragionevolmente accurato!!)
    iCount--;
    eeprom_write(iAddress, (unsigned int8)(iCount & 0x00FF) );
    eeprom_write(iAddress+1, (unsigned int8)(iCount >> 8) );
    //ogni volta che si ripete controlla: se si è appena memorizzato uno 
zero cambia indirizzo
    if (!iCount) iAddress += 2;
    }
}
Chiaro che il giochino puoi farlo anche con variabili a 8 bit!! Ho detto 
16bit così di getto perchè 2^16 = 65536.
Il codice non è testato, l'ho scritto così al volo, ma in linea di massima 
dovrebbe funzionare.
Non utilizzi in maniera lineare la tua memoria, ma eviti di superare il 
massimo numero di scritture garantite
Ciao
CG 

     }
idem
Ciao!
Marco / iw2nzm

 Direi iCount |= eeprom_read(iAddress+1) << 8;
Anzi meglio ancora con cast:
iCount |= (int16) eeprom_read(iAddress+1) << 8;
Marco / iw2nzm

 massimo numero di scritture garantite
Altro appunto: ricavare il numero di ore di funzionamento richiede di 
contare il numero di locazioni a 0, moltiplicarlo per 256 e sommare il 
complemento a 2 dell'ultima locazione *non* a 0xFF
Ciao

 complemento a 2 dell'ultima locazione *non* a 0xFF
Errato: sommare (0xff - valore dell'ultima locazione non a 0xff) :-)
Ciao

 Sono stato abbastanza chiaro ?
si si, ma lo sai che visto cosi' non sembra niente male?!
Effettivamente si puo' fare in pochissimo tempo dato che e' una cosa 
piuttosto "porca" :) . L'unico problemino
e che in assembly sto un po' piu' scomodo.
Che compilatore usate per il C?
Io usavo il borland C++ sotto DOS e sono passati un bel po' di anni. Ma con 
le risorse di un PIC si riescono a fare cose interessanti in C???
Cosa mi consigliate?
Ciao
Massimo IW0HKG 

 Cosa mi consigliate?
Si riescono a fare un sacco di cose carine in C, specie se stai sui PIC18 e 
superiori.
Con un PIC12 riesci a fare quello che ti serve, a maggior ragione con un 
16F876.
Prenditi quale demo....oppure guarda un po' cosa trovi sul mulo.
Al momento io sono un beta tester di MikroC (
www.mikroe.com
) (ho una licenza 
gratis....), e ho usato in passato il CCS PIC C (
www.ccsinfo.com
), anche se 
il migliore dicono sia quello di microchip.
Quello che so per certo č che il MikroC demo č limitato a 2k di ROM e per 
questo utilizzo dovrebbe avanzare alla grande!
Una volta creato l'HEX lo scarichi sul micro come preferisci
Ciao!
CG 

 niente!!! :)))
Bhe, in 5 minuti l'hai scritto, in 5 minuti io e Marco abbiamo fatto 
una breve review ed adesso il codice è funzionante: con poco lavoro da 
parte di più persone abbiamo ottenuto un bel risultato :-)
Quello che è successo è un esempio di collaborazione e dei vantaggi 
derivanti dall'open-source :-)
Ciao