Salvataggio in EEPROM e variazione progressiva dell'indirizzo di scrittura

Buonsera,

sto realizzando un nuovo progetto e mi sono sorti alcuni dubbi.

Partendo dal principio, sto utilizzando un micro ATtiny 45 ed un encoder rotativo che poi andrà a variarmi un uscita PWM.
I valori che potrà assumere l'encoder li ho impostati da 0 a 255.
Quello che voglio fare è salvare l'ultima posizione dell'encoder nella EEPROM in modo da non perdere il valore impostato in caso di riavvio.

Il salvataggio l'ho impostato in questo modo:

  • Se il valore dell' encoder è diverso dal precedente e se quest'ultimo è stabile per almeno 30 secondi salva il valore nella EEPROM.

Inoltre sto implementato le seguente funzione:

  • contatore di scritture in EEPROM
    Questa funzione mi conta il numero delle scritture che vengono fatte in EEPROM e quando questo contatore raggiunge un numero prestabilito mi implementa di una unità la variabile che mi gestisce l'indirizzo di salvataggio del valore dell'encoder.

RICAPITOLANDO:

  • Il micro che utilizzo ha 256 byte di memoria Eeprom e supporta (in condizioni ideali) 100 000 cicli di scrittura.
  • I byte da 0 a 3 servono per la variabile contatore (tipo unsigned long)
  • I byte da 4 a 7 servono per la variabile contatore con valore precedente (tipo unsigned long)
  • Il byte 8 serve per la variabile che mi definisce l'indirizzo di scrittura del valore dell encoder (tipo byte)
  • I byte da 9 a 255 sono utilizzabili per salvare il valore dell encoder.

Qui c'è una prima bozza della funzione sopra descritta:

void saveValue()
{
  if(encoderValue != previousEncoderValue)
  {  
  tempo = millis();
  writeOnEeprom = false;
  previousEncoderValue = encoderValue; 
  
  }
    
    if(millis() >= tempo + 5000 && encoderValue == previousEncoderValue && writeOnEeprom == false)
    { 
      writeCounter = writeCounter + 1;
      Serial.print("WRITE ON EEPROM   >>    ");
      Serial.println(encoderValue);
      Serial.print("CONTATORE SCRITTURE     >>    ");
      Serial.println(writeCounter);
      Serial.print("CONTATORE SCRITTURE PRECEDENTI    >>    ");
      Serial.println(previousWriteCounter);
      Serial.print("INDIRIZZO VALORE ENCODER    >>    ");
      Serial.println(encoderAdressValue);  
      writeOnEeprom = true;
      
    }

    if(writeCounter - previousWriteCounter > 5)
    {
      encoderAdressValue = encoderAdressValue + 1;
      previousWriteCounter = writeCounter;
      
    }
}

I miei dubbi sono i seguenti:

  • Ovviamente ci sono mille modi diversi di scrivere quello che ho fatto io, magari anche meglio... ma il mio quesito è: esiste una funzione che conta il numero delle scritture fatte nella EEPROM oppure il metodo che ho usato io è l'unica strada percorribile ?

  • A datasheet è indicato il numero di scritture massime supportate (100 000), ma avevo letto che questo numero è influenzo da molti fattori, quindi la mia domanda è: quale valore posso considerare come valore sicuro oltre al quale non è più garantito il salvataggio dei dati ?

Spero di essermi spiegato in modo chiaro.
Grazie in anticipo per le risposte :slight_smile:

100'000 scritture sono per singola cella ed è il minimo garantito ... il valore reale spesso è molto più alto.

La tecnica suggerita da Atmel per il massimo sfruttamento la trovi in allegato, assieme ad un esempio di implementazione in 'C'.

Guglielmo

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

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

Grazie !
I documenti che mi hai girato sono molto interessanti adesso mi metto subito a studiarli bene...

Da quello che ho capito ad un primo sguardo (correggimi se sbaglio), viene creato un buffer circolare, di dimensione N, ad ogni scrittura l'indirizzo viene implementato di 1 e quindi si va a scrivere nella cella accanto; in questo modo il numero di scritture diventa 100'000 *N (dimensione del buffer).

Come l'avevo pensata io andavo a scrivere sulla stessa cella fino al limite di scritture per poi andarmi a spostare su un altra cella.

La parte di lettura e riconoscimento dell'indirizzo non mi è molto chiara così in prima battuta, farò delle prove.

gpb01:
100'000 scritture sono per singola cella ed è il minimo garantito ... il valore reale spesso è molto più alto.

Quindi posso stare tranquillo e tenere come valore 100'000 se il micro resta entro le condizioni descritte a datasheet ?

P.S.
Esiste una libreria per gli O-buffer?
o dovrò crearmela una volta capito bene il loro funzionamento ?

Moce993:
Quindi posso stare tranquillo e tenere come valore 100'000 se il micro resta entro le condizioni descritte a datasheet ?

SI, certo, le 100'000 scritture le superi abbondantemente ... :wink: Ma guarda che per fare 100'000 scritture, specie per come hai disegnato la tua applicazione, ce ne vuole di tempo :wink:

Moce993:
Esiste una libreria per gli O-buffer?
o dovrò crearmela una volta capito bene il loro funzionamento ?

Mmm ... non me ne viene in mente nessuna ... magari puoi provare con S. Google :smiley:

Guglielmo

gpb01:
SI, certo, le 100'000 scritture le superi abbondantemente ... :wink: Ma guarda che per fare 100'000 scritture, specie per come hai disegnato la tua applicazione, ce ne vuole di tempo :wink:

Beh se un utente continua a variare il valore dell'encoder ad intervalli >30s, dopo soli 35 giorni ininterrotti di variazioni raggiunge il limite di scritture :smiley:

Scherzi a parte è più una mia paranoia che una reale utilità per la mia applicazione, diciamo che mi da fastidio il fatto di non sfruttare tutta la memoria e di continuare a "consumare" la stessa cella :smiley:

E comunque è sempre una cosa nuova da imparare, che magari mi potrà essere più utile in applicazioni future.

Moce993:
Beh se un utente continua a variare il valore dell'encoder ad intervalli >30s, dopo soli 35 giorni ininterrotti di variazioni raggiunge il limite di scritture :smiley:

... vero, ma ... lo ricoverano pure :smiley: :smiley: :smiley: :smiley: :smiley:

Guglielmo

Dopo aver fatto tutti questi ragionamenti, io sono andato sull'hardware: l'interruttore non agisce direttamente sull'alimentazione del circuito, ma su un mosfet con un gruppo RC sul gate che ritarda lo spegnimento del circuito. Appena aziono l'interruttore per spegnere, quindi, viene rilevato che sto spegnendo a vengono salvati i parametri che sono variati su EEPROM mentre il mosfet tiene ancora acceso per circa mezzo secondo.

Il problema è che i byte da 0 a 4 vengono comunque riscritti ad ogni spostamento dell'encoder, quindi non "consumi" quelli per salvare il valore dell'encoder ma "consumi" quelli...

SukkoPera:
Il problema è che i byte da 0 a 4 vengono comunque riscritti ad ogni spostamento dell'encoder, quindi non "consumi" quelli per salvare il valore dell'encoder ma "consumi" quelli...

Sì infatti, è stato un errore mio di valutazione ho considerato la dimensione massima della variabile come numero di scritture :sweat_smile:

Datman:
Dopo aver fatto tutti questi ragionamenti, io sono andato sull'hardware: l'interruttore non agisce direttamente sull'alimentazione del circuito, ma su un mosfet con un gruppo RC sul gate che ritarda lo spegnimento del circuito. Appena aziono l'interruttore per spegnere, quindi, viene rilevato che sto spegnendo a vengono salvati i parametri che sono variati su EEPROM mentre il mosfet tiene ancora acceso per circa mezzo secondo.

Scusa, non capisco una cosa, ti stai riferendo l'arduino UNO ed al pulsante di Reset ?

Forse mi sono spiegato male: il progetto che sto realizzando usa ATtiny45 montato su scheda custom, il quale viene alimentato da un lineare, non ho implementato alcun pulsante di reset.
L'unico evento avverso che può verificarsi è il taglio improvviso dell'alimentazione e la conseguente perdita del valore dell'encoder.

L'arduino UNO lo uso solo in fase di primo sviluppo per comodità e per avere la Seriale. :smiley:

Non mi sto riferendo all'Arduino Uno, né al pulsante di reset (???)
Ho montato l'atmega328p su millefori insieme al modulo gps, al display, un encoder e a un elemento 18650 con caricabatteria in un piccolo contenitore per leggere la velocità e suonare al superamento del limite impostato. Se ho variato il limite rispetto a quello memorizzato, quando vado a spegnere un mosfet mantiene acceso per mezzo secondo e, nel frattempo, l'atmega328p memorizza il nuovo valore.

Datman:
Non mi sto riferendo all'Arduino Uno, né al pulsante di reset (???)
Ho montato l'atmega328p su millefori insieme al modulo gps, al display, un encoder e a un elemento 18650 con caricabatteria in un piccolo contenitore per leggere la velocità e suonare al superamento del limite impostato. Se ho variato il limite rispetto a quello memorizzato, quando vado a spegnere un mosfet mantiene acceso per mezzo secondo e, nel frattempo, l'atmega328p memorizza il nuovo valore.

Quindi se ho capito bene utilizzi un pin per verificare un eventuale mancanza di corrente ?
Ed hai implementato un circuito con condensatore cha funge da "batteria tampone".

Io però volevo agire solo a livello software e la tecnica proposta da Guglielmo penso sia quella che fa al caso mio.

Però sono curioso:

  • Hai mai avuto perdita di dati con questo metodo ?
  • Se ipoteticamente parlando il condensatore si scarica troppo velocemente ed il micro si spegne perché raggiunge la tensione minima di funzionamento nel preciso istante in cui sta scrivendo nella EEPROM. Cosa succede alla cella in cui sta scrivendo ?

P.S.
Lo so sono casi limite, però ho imparato che quando una cosa non deve succedere molto probabilmente succederà :confused:

Invece così solo come curiosità generale
Cosa comanderesti in pwm, e perché è importante che alla riaccensione sia all'ultimo valore impostato?

Standardoil:
Invece così solo come curiosità generale
Cosa comanderesti in pwm, e perché è importante che alla riaccensione sia all'ultimo valore impostato?

Un motore brushless 12V DC.

  • Se il pwm va sotto una determinata soglia il motore non gira, ok allora basterebbe mettere un valore fisso in setup che ad ogni riavvio mi viene impostato.

Vero ma... una funzione che deve avere questo circuito è il mantenimento del valore impostato dall'utente qualsiasi cosa accada.

No, vado a memoria, ma la direttiva macchine vieta espressamente questa cosa
All'avvio di una macchina i motori devono essere fermi
Casomai controlla...

Standardoil:
No, vado a memoria, ma la direttiva macchine vieta espressamente questa cosa
All'avvio di una macchina i motori devono essere fermi
Casomai controlla...

L'applicazione in questione non rientra nella normativa macchine.

Non vorrei andare OT, ma nella normativa macchine se non sbaglio, nel caso che citi non basta che gli organi in movimento siano protetti ? e non raggiungibili con dito di prova ?

P.S. adesso sto provando ad implementare l'esempio proposto da Guglielmo, appena riesco a fare qualcosa lo posto magari può essere utile anche ad altri.

In che senso non è coperta dalla direttiva macchine?
Io conosco solo pochi casi
Armi
Veicoli
Velivoli
Apparecchi mossi da forza animale (tipo biciclette, aratro e risciò )
Forse, ma solo forse prototipi destinati a ricerca
Poi, non è il mio lavoro, non mi esprimo

Buongiorno,

Sono riuscito a ritagliarmi un po' di tempo per approfondire l'esperimento O-buffer nella eeprom.

Non riesco a capire una cosa, i buffer della guida (sto facendo riferimento ai documenti allegati da Guglielmo) sono a 8 celle; se non ho interpretato male il pdf ogni volta che scrivo il valore della mia variabile nel Parameter Buffer vado a scrivere un numero progressivo nello Status Buffer nella stessa posizione per entrami i buffer ed infine fatto questo vado ad implementare l'indirizzo di entrambi i buffer di 1.

Per andare a leggere l'ultimo valore salvato nel Parameter Buffer dovrò sapere su quale indirizzo andare a puntare per leggere il valore; quindi sempre dalle mie interpretazioni ( :sweat_smile: ) basta andare a confrontare i valori sullo Status Buffer quando troverò che il valore dell'ultima cella letta non è > 1 rispetto alla precedente allora saprò dove andare a puntare il mio Adress di entrambi i buffer.

Quello che non mi è chiaro è cosa succede quando vado in overflow con la variabile dell Status Buffer, se prendo ad esempio il mio caso quando arrivo al valore 255 sulla cella successiva verra scritto il valore 0,1,2.... in questo caso avrei 2 punti del buffer in cui la cella che vado a leggere non è uguale a quella precedente +1.

Non capisco come va gestita la cosa ?

P.S.
Ho ipotizzato due strade percorribili( magari entrambe errate :sweat_smile: )

1- Azzerrare lo Status Buffer ogni overflow della mia variabile (non mi piace molto come soluzione)

2- Conoscendo il numero di celle che compone il buffer e la dimensione della variabile, posso andare a prevedere dove andrà in overflow la mia variabile e quindi faccio partire il confronto dalla cella successiva.

Spero di avere espresso bene il concetto :smiley:

Scusami la domanda, ma perchè invece di un encoder non usi un potenziometro e mediante partitore resistivo ti leggi una tensione ad es. variabile da 0 a 2,5V così anche se salta il mondo, la resistenza impostata sul potenziometro non cambia e al riavvio rileggi esattamente la tensione pre catastrofe ...
Cioè il controllo da digitale lo fai diventare analogico.

Moce993:
Sì infatti, è stato un errore mio di valutazione ho considerato la dimensione massima della variabile come numero di scritture :sweat_smile:

Credo che tu non abbia capito la mia osservazione. Supponiamo di cambiare cella ogni 10 scritture e di farne 30:

  • Usi la cella 9 10 volte: BENE!
  • Usi la cella 10 10 volte: BENE!
  • Usi la cella 11 10 volte: BENE!
  • Usi la cella 8 3 volte: OTTIMO!
    - Usi le celle 0-7 30 volte: AZZ!
    Tanto valeva scrivere direttamente il valore nella prima cella e basta.