Newsgroup: it.hobby.elettronica.digitale
Titolo: Scritture ripetute su SD card

Ciao,
 
La mia domanda è leggermente OT ma sono sicuro che chi
conosce meglio questi problemi legge il NG.
 
Sto scrivendo una cosa per arduino e ho bisogno di sapere
l'ultimo istante in cui c'è stata alimentazione
(ovviamente è un dato che mi serve quando riparte), non 
serve una tolleranza mostruosa e anche dieci secondi mi 
vanno bene. Ho una shield della solita adafruit con una SD 
e un RTC, uso la libreria SdFat. Fin qui tutto bene, ho il 
logging dei dati che mi servono.
 
Allo scopo pensavo di creare un file il cui nome
contenesse una codifica del tempo fornito dal RTC. Ho solo
sette caratteri (uno è di prefisso per distinguerlo da
altri files) quindi potrei calcolarlo con un offset che
non è il 1970 ma il __TIME__ di compilazione ed esprimerlo 
in decasecondi.
 
Ammesso che la cosa possa funzionare (confesso che non ho
fatto i conti per vedere se ci sta) arrivo al problema: si
tratta di SD di quelle arcaiche anche se suppongo sia
possibile o anche consigliabile usare una microSd recente
con adattatore, e mi chiedo come gestiscano il filesystem.
 
In altre parole se un file da cancellare e creare ogni 10 
secondi viene scritto sempre sulle stesse celle è chiaro 
che butterò la SD in pochi giorni. Mentre se il controller 
è abbastanza furbo da ruotare le celle forse ce la posso fare.
 
Il problema è generale, e vi chiedo come si affronta la
questione di minimizzare i danni da scrittura su una SD a
livello di codice.
 
grazie :)
 
Apx
 
-- 
- Ciao, ho visto le tue foto su Facebook
   chiamami al 347******9
- Non ti sembra esagerato darmi subito il
   tuo numero?
- Sono un chirurgo plastico, posso aiutarti.
 

 fatto i conti per vedere se ci sta)
 
Non ci sta, se non per qualche giorno... ma resta il 
problema di come usare correttamente una SD


 logging dei dati che mi servono.
 
Non conosco arduino, ma anni fa ho avuto il problema su dei micro (ST) di
salvare dati su memorie ritentive i2c allo spegnimento o black-out.
 
Ho usato nell'alimentatore condensatori elettrolitici da alta capoacità ed
usando un interrupt che controlla la frequenza di rete, ho attivato un
sottoprogramma per la scrittura dei dati.
 
Sono oltre 15 anni che non sgarra una sola volta!
 
Per il problema sd, su un raspberry, salvo costantemente i log del router,
migliaia di righe al giorno, ruotate in 90 files giornalieri, e non ho problemi
per almeno un paio di anni, che è l'intervallo di sostituzione della sd (micro
sd hc kingston classe 10 16GB) che faccio solo per mia sicurezza.
 

Scrivilo solo quando manca la corrente! Puoi usare un condensatore
 o una pila alcalina o al litio...
 
 
-- 
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
 

 condensatore o una pila alcalina o al litio...
 
Ehehe soluzione hardware che avevo già realizzato in altro
modo (in sostanza è sotto UPS e si apre un relè quando
manca la rete) ma volevo fare qualcosa di diverso per
renderlo del tutto autocontenuto.
 
Alla fine ho risolto scrivendo in modo append i vari
timestamps; dato che servono solo per acquisire il tempo
di ultimo funzionamento il file può anche diventare
gigante, cosa desiderabile per ruotare le celle il più
possibile.


 livello di codice.
 
fat16\32 prevede quello che dici, ma potresti verificarlo da windows con 
un programma di recupero file.

Autocontenuto?... Un condensatore o una pila, mica un gruppo
 elettrogeno! :-)


 gruppo elettrogeno! :-)
 
Intendevo dire in senso boh, mentale, non quello di
mettere delle cose dentro una scatola. Adesso funziona già
passabilmente: solo un arduino con la shield SD+RTC et 
voila alla partenza si ricorda quando l'alimentazione è 
mancata ^_^


In data  giugno 2019 alle ore 12:34:02, Franco Af  
<nonvalidanonv...@falsa.fal> ha scritto:

Non ho capito se il circuito sia ancora da costruire o si debba  
arrangiarsi con ciò che c'è,scusa se aggiro la domanda,in quanto cerco di  
evitare scrittura ripetuta(ma---non ricordo.. la SD card non è una Flash  
appunto gestita internamente con algoritimi che la fanno sembrare una  
memoria Random?:
Non è possibile aggiungere una EEPROM I2C o SPI?La scrittura in questa  
sarebbe molto più rapida
,un detector di mancanza di rete come già suggerito,o di calo di DC(che  
sarebbe separata da quella che alimenta il micro da un diodo e mantenuta  
da un bel 1000 uf)farebbe scattare un interrupt che chiamerebbe la  
scrittura.
Ho avuto necessità di fare qualcosa di simile e avevo chiesto aiuto  
qui,nel mio caso dovevo anche cercare di sopravvivere al blackout
Non ho trovato di meglio che interrupt->software reset(per ripartire in un  
punto noto subito,troncando qualsiasi sub sub subroutine)->Salvataggio in  
EEPROM(interna al micro STM32KL01,32 bit 0,7 euro con EEPROM interna) e  
STOP Mode
 
---
Questa email è stata esaminata alla ricerca di virus da AVG.
http://www.avg.com
 
 

 STOP Mode
 
Ciò che dissi io alcuni post fa.
 
Al limite, anzichè una eeprom i2c o spi, una ram batterizzata con la classica
2032 o 2016.
 
 
-- 
Non ci sono più le galline di una volta...
Adesso si sono informatizzate, e fanno le uova con già la data!

 euro con EEPROM interna) e STOP Mode
 
a questo punto meglio le fram, costano un po' di più ma valgono molto di 
più.

Il 26/06/19 11:08, Franco Af ha scritto:

Sbaglio o le FRAM sono limitate non solo in scrittura ma anche in lettura?
 
Altra soluzione: un moduletto RTC DS3231 i2c (due neuri e mezzo sulla 
baia) e sfruttare la RAM interna già batterizzata. Letture e scritture 
illimitate.
 
 

 illimitate.
 
ma l'rtc è ovvio, ma ci vuole la batteria

> se non ricordo male (non vado a riguardare) sui migliaia di miliardi di
 
*sulle migliaia :)
 
 

 passabilmente: solo un arduino con la shield SD+RTC
 
Ah, non avevo letto altrimenti postavo qua.... l'RTC (che immagino abbia 
una sua batteria) dovrebbe avere un qualche 10 byte di SRAM utente, 
quindi non serve tutta la storia della SD, puoi salvare tutto sull'RTC;)

 l'ultimo istante in cui c'è stata alimentazione
(CUT).
 
Probabilmente mi sfugge qualcosa,ma la domanda stupida la faccio comunque: se devi memorizzare solo un timestamp, non puoi utilizzare la EEPROM di Arduino?
 
m.

Anche quella ha un numero di riscritture limitato: riscrivendo la
 stessa cella ogni 10 secondi, ci fa tre o quattro
 mesi.
La cosa assurda è riscrivere continuamente qualcosa che servirà
 una volta ogni centomila! L'unica soluzione ragionevole è
 scrivere solo quando serve.


  mesi.
 
Secondo le specifiche (100.000 cicli erase/write) sono 10-12 giorni, secondo qualcuno che ha fatto delle prove siamo sui 3-5 milioni di cicli, quindi un anno e mezzo. Ovviamente dipende da cosa devi fare e qual è il grado di affidabilità richiesta, per cui magari sei costretto a lavorare nelle specifiche del costruttore, anche se il test nel "mondo reale" ti permetterebbe di stare molto più tranquillo:
 
https://www.avrfreaks.net/forum/eeprom-endurance-and-pages?name=PNphpBB2&file=viewtopic&t=85029
 
https://www.avrfreaks.net/forum/eeprom-endurance-and-pages?name=PNphpBB2&file=viewtopic&t=85029
 
 
m.

Il 15/07/19 12:48, mr ha scritto:

A me un ATMEGA328 ha iniziato a scantinare dopo 10 milioni di cicli 
(stress test di alcuni giorni sulla stessa cella). Ma appunto non farei 
mai un progetto "reale" che ecceda i 100mila nella vita utile prevista.

Grazie a tutti, non mi ero dimenticato ma il thread, per
fortuna, si è lentamente espanso. Ora che posso tornare 
sul mio problema intanto provo con la memoria del RTC poi 
se fallisce tenterò le altre soluzioni.
 
 
 
-- 
- Perché hai fatto sesso con lei?
- Era ferma e nuda, cos'altro avrei dovuto fare?
- Ehm... L'autopsia.