fotosettore:
allora ...
mi posso accontentare di una lettura di un unico file che contiene tutto
ho simulato la ricerca dell'ultima riga su 200 : circa 180 ms
Curiosità... con quale metodo esegui la ricerca della "chiave" all'interno del file?
Io ho parlato di SD perchè il principio di fondo è valido a prescindere, cambiano solo i dettagli, tipo memorizzare il numero di riga piuttosto dell'indirizzo del primo byte, passare per un file system oppure no, ecc.
Se la struttura è quella del file con dati per riga, è sufficiente l'inizio (primo byte o num riga è un dettaglio che mi devo rinfrescare, ma ininfluente al fine della discussione di principio), poi si legge fino al return, tanto le letture sono comunque sequenziali, avere l'offset o cercare il return dovrebbe pesare uguale.
Viste le tue specifiche sulle lunghezze dei dati, ti consiglio di ragionare a lunghezza fissa. Userai un po' più di memoria, ma se cambi un dato non devi riscrivere tutto quel che segue.
Con le eeprom puoi allinearti alle pagine interne per ottimizzare le letture (magari mi ricordo male, ma mi pareva che fosse possibile fare letture sequenziali e fossero più efficienti se fatti per pagina, ma verifica perchè la mia memoria da pesciolino rosso a volte fallisce miseramente), anche qui al costo di un po' di spazio sprecato.
Se la lettura sequenziale dell'intera memoria (qualunque essa sia) resta entro tempi accettabili, inutile complicarsi la vita con cache intermedie, le potrai aggiungere in seguito in caso di necessità.
I dettagli più spicci, sono lasciato come facile esercizio per il lettore ;D
docdoc, intervieni pure, io ho scritto così solo perchè questi dettagli non me li ricordo in modo affidabile.
Maurizio
fotosettore:
mi posso accontentare di una lettura di un unico file che contiene tutto
Bene!
il secondo è che si hanno a disposizione "solo" 10mila cicli erase/write, che per un prodotto che non deve essere smanettato e per giunta con modulo esp32 saldato su stampato risulta poco efficiente.
Perdonami ma non ho capito bene quale sia il problema, e soprattutto perché non sia risolvibile.
Visto che dici di fare al massimo un aggiornamento al giorno, per ridurre il numero di accessi alla flash ti basterebbe alla partenza caricare i dati dalla flash alla memoria, e poi in caso di un aggiornamento leggi i dati da remoto e li scrivi nella flash per cui avresti un accesso (in lettura) alla partenza del device, e poi uno per ogni aggiornamento, il che con 10.000 cicli (che poi sono un valore generalmente "minimo" prima di un eventuale errore) avresti 5.000 giorni di "vita" o, nel caso peggiore di un aggiornamento al giorno, 2.500 giorni ossia vari ANNI.
Inoltre a questo punto eviterei del tutto spiffs, inutile se devi gestire solo un file: metti i dati tutti sequenziali nella flash in una struttura di dimensione fissa e la leggi in una struct.
Quali problemi ci vedi in questo diverso approccio? Mi sfugge qualcosa?
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.