Volendo memorizzare dei dati in Arduino il problema non si pone, e fin qui ci siamo. I metodi sono diversi.
Però se ho, per esempio, una pompa dosatrice, e devo settare un dosaggio utilizzando due tasti (+) e (-) per incrementare e decrementare il valore, poi quando spengo l'apparecchiatura il valore si azzera.
Va bene, scrivo sulla EEPROM, ma quando / quanto ?
Ad ogni pressione del tasto (+) e ad ogni pressione del tasto (-) ? (elevati cicli di scrittura)
Oppure dopo qualche secondo che non premo nessuno dei due tasti (risparmio cicli di scrittura)
Oppure allo spegnimento del macchinario? (pochissimo cicli di scrittura, ma soluzione complicata...)
Dato che il limite dei 100.000 cicli di scrittura esiste, mi domandavo come facevano i produttori di PLC (Mitsubishi Alpha o Siemens LOGO), che hanno dei registri ritentivi (come li chiamano loro) ma che poi è un accrocchio firmware che scrive continuamente ma ha magari gli stessi limiti e forse io mi sto ponendo un problema che non esiste...
Schneider Zelio, poi, monta un ATMEGA128, quindi dovrebbe avere lo stesso problema di Arduino.
Soluzione 4, usare celle di EEPROM diverse per massimizzare.
Ma ... forse ti fai troppi problemi.
Anche se memorizzi ad ogni pressione +/- quante volte al giorno capita ? Che valori?
Quando sono settati esempio valore 20, solo alla sua variazione premi +/- giusto ?
Quindi quante volte si stima premeranno i pulsanti al giorno ?
Fai 100.000 / questo numero e forse scopri che possono premere N volte al giorno per cento anni
Quindi se uso celle diverse "moltiplico" i cicli?
Cioè mettiamo uso 2 celle ma ne ho a disposizione 1024, posso avere 100.000 cicli di scrittura moltiplicati per 512 ?
nid69ita:
Soluzione 4, usare celle di EEPROM diverse per massimizzare.
Esatto, se veramente occorre (... ma prima valuta per quanti anni vai avanti prima di raggiungere i 100'000 aggiornamenti) buffer circolare ... vedi allegati ...
steve-cr:
Quindi se uso celle diverse "moltiplico" i cicli?
Cioè mettiamo uso 2 celle ma ne ho a disposizione 1024, posso avere 100.000 cicli di scrittura moltiplicati per 512 ?
Quello si, i 100.000 sono per ogni singola cella.
Come per le SD, infatti suggeriscono di non eliminare sempre le foto (addirittura formattando) in una SD quando ne hai fatte poche perchè così le prossime foto sono di nuovo memorizzate in stesse celle.
Il limite di 100000 scritture vale per ogni singola cella.
Ma poi tieni conto che quello è un limite garantito, nel senso che ogni cella dura ALMENO per quel numero di scritture, ma non è che poi muoia alla 100001a scrittura...
Comunque in casi come il tuo, quel che faccio io di solito è scrivere in EEPROM qualche secondo dopo l'ultima pressione del tasto, in modo da risparmiare almeno le scritture dei "valori intermedi".
Perfetto!
Il limite dei 100.000 "ogni cella" mi era sfuggito, pensavo che contasse il solo fatto di scrivere!
Quello della cancellazione foto su SD non l'avevo mai pensata ( ma effettivamente va dato per scontata, ora che lo so !!! )
Quello di memorizzare dopo qualche secondo che non premo più nulla era la soluzione migliore che mi era venuta in mente, ma sembra che avevo visto bene.
Si, effettivamente il limite dei 100.000 non è male, ma pensavo al "repeat" che metto al tasto se lo tengo premuto in modo da velocizzare l'incremento del counter del dosaggio. In quel caso memorizzo quando tolgo il dito dal tasto.
Per le SD non mi pare. Non c'e' un chip sopra. Una penna USB si. Neppure un harddisk stato solido lo fa, è il sistema operativo che lo fa (infatti non usare winxp con HD SSD perchè non sà fare questa gestione)
Penso poi che una macchina fotografica proprio non gestisca il wear-leveling. Magari le professionali fascia alta ?
Almeno è quello che io sò.
Boh, non è il mio campo, potresti avere ragione. Però su Wikipedia leggo:
On most contemporary flash memory devices, such as CompactFlash and Secure Digital cards, these techniques are implemented in hardware by a built-in microcontroller. On such devices, wear leveling is transparent and most conventional file systems can be used on them as-is.
Il wear-leveling di solito e' integrato nel controller che interfaccia le celle di memoria con il dispositivo utilizzatore ... Per le chiavette USB ed i dischi SSD c'e' praticamente sempre, mentre sulle SD e' una lotteria, anche se un controller c'e', alcuni produttori lo implementano, ma molti no, dato che e' comunque un costo sviluppare un'algoritmo proprietario per quello ... mentre ovviamente, su qualsiasi memoria in cui puoi scegliere tu la cella, non c'e' alcun wear-leveling ...
nid69ita:
Per le SD non mi pare. Non c'e' un chip sopra. Una penna USB si. Neppure un harddisk stato solido lo fa,
Sulla SD c'è eccome il controller che le gestisce e che provvede a far "circolare" i dati su tutta la SD evitando di scrivere sempre sugli stessi blocchi, che poi questa gestione sia fatta bene sulle SD dei produttori seri, p.e. Sundisk, e fatta in modo pessimo sulle SD anonime cineseria, quelle che costano poco e durano meno, questo è un altro paio di maniche.
Stessa cosa vale per gli SSD, la gestione dei blocchi è fatta localmente dal loro controller, non centra nulla il sistema operativo, a parte l'operazione TRIM non supportata da XP, cosa che rallenta leggermente le operazioni di scrittura sul SSD però questo non significa che con XP non si devono usare gli SSD.
Il motivo per cui i costruttori di SSD consigliano di non riempirli per oltre il 70-75% della loro capacità è proprio per lasciare la possibilità di far "ruotare" i blocchi di nand utilizzati, in modo da non scrivere troppo spesso sugli stessi blocchi, cosa che accorcerebbe notevolmente la vita del SSD-
L'endurance della nand flash usata per gli SSD è compresa tra 10.000 e 1.000.000 di riscritture per ogni blocco, vale il solito discorso, se prendete un SSD Samsung, o altro produttore primario, siete tranquilli che lo cambiate prima che la sua vita utile arrivi al termine perché l'endurance è alta, se prendete un SSD cineseria quasi sicuramente lo buttate in poco tempo perché ha la stessa endurance di un AVR.
Il TRIM è una cosa diversa, a differenza del wear leveling, che è gestito localmente dal controller del SSD, è gestito dal sistema operativo, è una informazione che il S.O. passa al controller del SSD per dirgli quali sono i blocchi che può riutilizzare perché il relativo contenuto è stato cancellato definitivamente.
Quindi, da quello che salta fuori dalla discussione, nei PLC industriali "piccoli" (siano Mitsubishi Alfa o Siemens LOGO! ma anche Schneider Zelio) c'è qualcosa che assomiglia ad un wear-leveling ?
Perché io che li uso da anni con programmi abbastanza pesanti utilizzo sempre una o due pagine del display dove metto dei contatori per avere poi delle medie statistiche.
E sono tutti contatori indipendenti l'uno dall'altro. Ma se dovessi riscrivere le stesse celle di memoria al cambio di uno solo di questi contatori, la mia EEPROM durerebbe forse qualche giorno o al massimo un paio di mesi.
steve-cr:
Quindi, da quello che salta fuori dalla discussione, nei PLC industriali "piccoli" (siano Mitsubishi Alfa o Siemens LOGO! ma anche Schneider Zelio) c'è qualcosa che assomiglia ad un wear-leveling ?
Solitamente i PLC hanno una EEPROM ad elevata endurance, non meno di 1.000.000 di scritture, esterna al micro, è li sopra che mettono i dati non volatili, inoltre sicuramente li memorizzano solo quando sono consolidati, p.e. conferma da parte dell'utente oppure dopo diversi secondi che non c'è nessuna variazione degli stessi.
Con la EEPROM di un AVR scrivendola ogni 15 minuti, 24/7, ci metti quasi 3 anni per finire le 100.000 scritture minime, senza wear-leveling, se lo usi il periodo può diventare decine di anni, dipende da quanti byte ti servono.
steve-cr:
... oppure la batteria tampone che c'è all'interno alimenta direttamente il processore (e solo quello) e allora il problema non si pone....
Non è ammesso dalle vigenti normative, i dati devono essere salvati su un supporto non volatile, la batteria va bene solo per mantenere la data/ora o parametri che non ha alcuna importanza se vanno persi.
Secondo me la batteria tampone (ma anche solo un elettrolitico che mi dia qualche decimo di secondo) serve anche al firmware per accorgersi che l'alimentazione è stata tolta, salvare tutto il salvabile e poi spegnersi...
Penso sia fattibile.
