EEPROM o SD?

Ciao a tutti, sto progettando il mio nuovo controllore di temperatura per le mie camere di fermentazione della mia birra. Senza addentrarmi nelle funzionalità (non perchè non voglia ma perchè sono ancora in fase di progetto) vi spiego un "problemino": Dalle mie parti (chi di dovere abbia in gloria il gestore) tolgono la corrente MOLTO spesso per cui la necessità primaria è che al riavvio il bimbo riprenda a funzionare con gli stessi settings di prima. Da ciò la naturale deduzione di andarli a scrivere nella EEPROM. Leggo però che le celle sono certificate per al massimo 100.000 riscritture che sembrano tantissime ma forse non lo sono proprio del tutto...io avrò diverse decine di parametri da salvare e dovrò farlo diverse volte nell'arco del funzionamento (variazioni di setpoint, accensioni manuali ecc.) e quindi qui la domanda: pensavo già di inserire un lettore di SD per fare del data logging e mi chiedevo se secondo voi può essere altrettanto efficace andare a scrivere/leggere una sorta di file .INI che appunto asserva allo scopo della memorizzazione dei settings quanto l'utilizzo della EEPROM...che ne dite?

Grazie
Andrea

Ciao, considera che scrivere sull'sd comporta un certo tempo per aprire il file, scrivere e chiudere il file in sicurezza. Certo esiste anche un certo tempo necessario a scrivere sull'EEPROM. Perché ti dico questo? Perché devi considerare il caso peggiore, ovvero manca la corrente mentre stai scrivendo... :confused:
Credo che potreti valutare la strategia suggerita anche in altri casi sul forum ovvero tramite un pin e apposito hardware (che se ti interessa come strategia puoi approfondire in seguito visto che sei in fase di progetto) verifichi se manca la corrente, in tal caso avvi la procedura di salvataggio dei dati in EEPROM il tutto supportato da supercondensatore/batteria dimensionato in modo tale da supportare il micro per il tempo necessario al salvataggio dei dati, in tal caso le 100.000 scritture sono moooolte, in più se segui quanto indicato da ATmel per utilizzare al massimo rendimeno la eeprom (usandola tutta in modo "circolare") sicuramente potrebbe essere una strada percorribile.

Ciao, grazie! In realtà i vari settings verranno memorizzati nel supporto nel momento in cui saranno inseriti manualmente dalle varie videate di setup, non ho valori di processo da memorizzare....se sfig....ehm sfortuna vuole che la corrente vada via finchè l'utente HA HA HA HA finchè io inserisco i valori allora dovrò avere la pazienza di inserirli di nuovo dopo....certamente la EEPROM sarebbe più gestibile, però il limite di 100.000 per cella.....mah

Se è così valuta tu in tal caso c'è poca differenza, io preferirei l'EEPROM che sulla uno è di 1Kb, non so quanti parametri hai ma se anche occupassero esattamente 1K e ipotizzando che ogni volta che fai la birra TUTTI variano (perché il metodo update della EEPROM prima valta se il valore è effettivamente variato altrimenti non scrite... e le letture sono infinite) dopo più di 100.000 processi produttivi di birra (perché non è detto che a 100.000 si rompa anzi...) credo che il problema non sia più tuo :slight_smile:

Come dice @fabpolli, 100.000 volte che salta l'alimentazione , o anche 100.000 birre se tutte le volte vari dei parametri, presumo che anche volendo non basti un'intera vita per poterci arrivare.
E considera anche un'altra cosa, una SD a 100.000 cicli non ci arriverebbe mai . muore molto prima.
Esiste comunque anche una terza possibilità, usare une Eeprom esterna, che mediamente ha una vita garantita di 1.000.000 di cicli di scrittura/cancellazione
Se poi la usi in modo circolare ( scrivendo su tutta la Eeprom ) , con una 24lc256 di cicli ne fai quasi 1 Miliardo

Mi avete convinto :slight_smile: … per quanto riguarda la gestione circolare delle celle (se ho capito cosa si intende ma penso di sì), dovrei mettere in piedi un algoritmo che determini da solo un “offset” per la gestione delle celle ma che dopo sia in grado anche di utilizzarlo per le letture, giusto? Cioè mi spiego: supponiamo di scrivere i primi X indirizzi, poi in lettura devo andare da 0 a X, la volta successiva da X+1 a X*2 ma questo offset poi lo devo utilizzare anche in lettura, giusto? Cioè dovrei memorizzarmelo da qualche parte, right?

the_dragonlord:
… per quanto riguarda la gestione circolare delle celle …

Segui questa (in allegato) application note di Atmel, con tanto di esempio … :wink:

Guglielmo

AVR101 - High Endurance EEPROM Storage.pdf (47.3 KB)

Atmel - High Endurance EEPROM Storage.c (4.31 KB)

Ragazzi, cerchiamo di essere pratici: scegli una cella e scrivi tranquillamente lì tutte le volte che serve, senza farti seghe mentali sulle 100000 scritture. L'unica accortezza che devi avere è di scrivere, appunto, solo quando serve, ad esempio, quando esci dal menù di configurazione.

Visto che poi parli di schermate di setup, immagino che avrai dei pulsanti: pensa a quante volte li premerai per navigare tra i menù e impostare i parametri. Sei sicuro che sopportino più di 100000 pressioni?

Se la EEPROM viene usata solo per salvare dei preset da un menù prima di arrivare a otre centomila scritture di una cella sicuramente “muore” prima Arduino perché ci vogliono moltissimi anni prima di arrivare alla fine della vita utile della EEPROM
Facendo un semplice conto, anche ipotizzando di cambiare 10 volte al giorno i vari preset e usare l’impianto tutti i giorni occorrono 10000 giorni per arrivare al limite minimo garantito di scritture, ovvero più di 27 anni.
Tra parentesi non è che a 100000 scritture la EEPROM cessa di funzionare, semplicemente è un valore minimo garantito, la durata reale è maggiore e comunque si perdono solo poche celle per volta e non tutte assieme.
Altamente consigliato l’utilizzo del metodo update, messo a disposizione dalle avrlibc, che invece di scrivere incondizionatamente le celle EEPROM prima verifica il contenuto con il valore fornito e scrive solo se è differente, cosa che permette di usare una semplice funzione di aggiornamento della EEPROM ogni volta che si esce dal menù senza scrivere necessariamente tutte le celle interessate anche se non è necessario.

Codice di esempio per la gestione delle EEPROM con la creazione delle variabili da memorizzare, lettura, scrittura delle stesse tramite metodo update.

#include <avr/eeprom.h>

/************** AvrLibc EEMEM function *****************
  uint8_t   eeprom_read_byte (const uint8_t *__p) __ATTR_PURE__
  uint16_t  eeprom_read_word (const uint16_t *__p) __ATTR_PURE__
  uint32_t  eeprom_read_dword (const uint32_t *__p) __ATTR_PURE__
  float           eeprom_read_float (const float *__p) __ATTR_PURE__
  void          eeprom_read_block (void *__dst, const void *__src, size_t __n)

  void  eeprom_write_byte (uint8_t *__p, uint8_t __value)
  void  eeprom_write_word (uint16_t *__p, uint16_t __value)
  void  eeprom_write_dword (uint32_t *__p, uint32_t __value)
  void  eeprom_write_float (float *__p, float __value)
  void  eeprom_write_block (const void *__src, void *__dst, size_t __n)

  void  eeprom_update_byte (uint8_t *__p, uint8_t __value)
  void  eeprom_update_word (uint16_t *__p, uint16_t __value)
  void  eeprom_update_dword (uint32_t *__p, uint32_t __value)
  void  eeprom_update_float (float *__p, float __value)
  void  eeprom_update_block (const void *__src, void *__dst, size_t __n)

*********************************************************/

/* non modificare assolutamente l'ordine dei parametri */
// dichiarazioni EEMEM preset
unsigned int EEMEM orario_1_EEP;  // orario 1
unsigned int EEMEM orario_2_EEP;  // orario 1
unsigned int EEMEM orario_3_EEP;  // orario 1
unsigned int EEMEM orario_4_EEP;  // orario 1
unsigned int EEMEM temp_EEP;      // temperatura

// legge preset da EEPROM
void Read_Preset()
{
  Ton_1 = eeprom_read_word(&orario_1_EEP);
  Toff_1 = eeprom_read_word(&orario_2_EEP);
  Ton_2 = eeprom_read_word(&orario_3_EEP);
  Toff_2 = eeprom_read_word(&orario_4_EEP);
  temp_preset = eeprom_read_word(&temp_EEP);
}

// scrive preset su EEPROM
void Write_Preset()
{
  eeprom_update_word(&orario_1_EEP, Ton_1);
  eeprom_update_word(&orario_2_EEP, Toff_1);
  eeprom_update_word(&orario_3_EEP, Ton_2);
  eeprom_update_word(&orario_4_EEP, Toff_2);
  eeprom_update_word(&temp_EEP, temp_preset);
}

La nota “/* non modificare assolutamente l’ordine dei parametri */” è una warning relativa al fatto che una volta inizializzata la EEPROM se si modifica l’ordine di dichiarazione delle variabili i loro valori poi risultano falsati, questo perché cambiano gli address fisici della EEPROM utilizzati dal codice, sono gestiti in automatico dalle relative funzioni delle avrlibc.
Se è necessario modificare le variabili, o il loro ordine, la EEPROM deve essere nuovamente inizializzata con gli eventuali valori di default.

SukkoPera:
Ragazzi, cerchiamo di essere pratici: scegli una cella e scrivi tranquillamente lì tutte le volte che serve, senza farti seghe mentali sulle 100000 scritture.

E’ quello che tra le righe sostenevo con… non è un problema tuo considerando che la produzione di birra sicuramente occupa più di un giorno o è highlander o chissene… :slight_smile:

Una cosa che mi disturba:
Secondo me il tempo di mancanza rete é una grandezza che si deve considerare. La fermentazione continua sopra una certa temperatura e secondo me va considerata.
Percui metterei un RTC e se scegli un modello con RAM puoi usare quella per memorizzare i dati.
Ciao Uwe

... senza contare magari anche una bella batteria robusta di backup, o un gruppo di continuita ? ... :wink:

Non conosco i dettagli del tuo software ma potresti prevedere un 'bookmark' per far riprendere automaticamente il processo dal punto in cui è mancata la corrente, la soluzione di fabpolli è quella che adotterei anch'io, uno o due supercaps e un sensore che valuti la corrente, i condensatori ti permetterebbero di scrivere su EEPROM/SD il bookmark.
Se la soluzione contempla anche il periodo di fermentazione, allora un RTC è obbligatorio, aldilà che i blackouts siano magari di pochi minuti.

the_dragonlord:
Ciao, grazie! In realtà i vari settings verranno memorizzati nel supporto nel momento in cui saranno inseriti manualmente dalle varie videate di setup, non ho valori di processo da memorizzare....se sfig....ehm sfortuna vuole che la corrente vada via finchè l'utente HA HA HA HA finchè io inserisco i valori allora dovrò avere la pazienza di inserirli di nuovo dopo....certamente la EEPROM sarebbe più gestibile, però il limite di 100.000 per cella.....mah

Etemenanki:
... senza contare magari anche una bella batteria robusta di backup, o un gruppo di continuita ? ... :wink:

Se i blackouts sono 'corti' questa ti toglie tutta la logica backup/restore da implementare

Anche perché se la mancanza di corrente è "tanto tempo", il riscaldamento o il raffreddamento "ormai è tardi".
Nel senso che sballa tutto il procedimento di produzione della birra.

E infatti, tutto sta a capire quanto sono lunghi i blackouts, se sono relativamente brevi un gruppo di continuità va bene in ammostamento boil raffreddamento fermentazione etc
Se sono lunghi in ogni caso devi intervenire manualmente perchè qualunque sia il processo in atto rovinerà inesorabilmente il risultato...

Si, non mi sono espresso chiaramente probabilmente … un gruppo di continuita’, in modo da garantire l’alimentazione a tutto per almeno una decina di minuti, in modo da non far rovinare quanto c’e’ nei serbatoi in caso di interruzioni brevi … piu una batteria di backup sull’alimentazione, con opportuni diodi, in modo che il sistema possa salvare tutto e spegnersi in caso l’interruzione duri piu dell’autonomia del gruppo … in questo secondo caso, con un trasformatorino, oppure anche all’uscita dell’alimentatore delle logiche, si prende un segnale che dice al micro “e’ partita l’alimentazione” (cosa che succedera’ DOPO l’esaurimento dell’autonomia del gruppo di continuita’), ed a questo punto la batteria consente di salvare lo stato, il tempo, eccetera, ed andare a nanna … se poi magari nei prossimi 5 o 10 minuti (o comunque entro il tempo massimo calcolato in cui le miscele non si rovinano) la corrente ritorna, il micro potra’ leggere i dati salvati, vedere quanto tempo e’ trascorso dall’RTC, e decidere se continuare il processo compensando il ritardo, oppure se e’ passato troppo tempo ed ormai non c’e’ piu nulla da fare … :wink: