Salve a tutti, sono arrivato nel progetto alla parte eeprom e avrei bisogno di qualche delucidazione.
Ho scritto una piccola paginetta login su flash, dove alla prima connessione arduino invia una pagina di login e uno status del sistema compresi i parametri ip, gatway e tutto il resto salvato su eeprom
sono 12 righe da esattamente 100 caratteri ciascuna
Avendo 4k a disposizione come misuro quanto spazio ho usato? devo considerare un byte per ogni carattere?
100*12=1,2k?
Questo esempio qui sopra come viene allocato in memoria? da dove parto a leggere il primo byte con la funzione EEprom.read dal momento che non gli ho specificato le posizioni?
Quello che vorrei fare è usare uno sketch che scriva tutto quello che mi serve su eprom e poi cambiare lo sketch che vada a leggere la memoria, non vorrei che a ogni reset riscrivesse di nuovo tutto, non è necessario farlo sempre, è possibile no?
Si ho notato. nella flah metti variabili costanti che comunque le perdi al reset.... bene non è quello che mi serve, deve essere butatto tutto su eeprom, avrò sbattermi un po'
si ma 4k dannazione!!! neanche nome e cognome ci sta!!
Grazie Luca, quando 20 anni fa mi sono diplomato in elettronica nelle sezioni elt c'erano ancora le valvole studiare le memorie varie era pura fantascienza, l'anno dopo hanno rimosso le valvole e inserito i microprocessori + ram ecc. Cosa che andava fatta 10 anni prima. Povera Italia.
Qindi ritornando alle 12 righe da 100 char, dovrei convertire i caratteri in byte, allocarli partendo dal primo (mi pare 0x50 devo verificare il DS) e occupo così 1,2k?
sì, la corrispondenza è un carattere = un byte (includendo ovviamente anche spazi, "a capo" etc...)
utilizzando una eeprom esterna hai anche una modalità di lettura "continua" che ti consente di leggere un'intera sequenza di caratteri in un buffer, es: http://arduino.cc/playground/Code/I2CEEPROM
pablos:
Si ho notato. nella flah metti variabili costanti che comunque le perdi al reset....
No.
Nella Flash memorizzi delle variabili che non possono essere modificate.
Diventano tipo costanti. Ma la grossa differenza arriva ora.
Quando nello sketch la CPU incontra un'istruzione per gestire una variabile, essa cosa fa?
legge il valore dalla Flash
crea nella SRAM una variabile contenente quel valore
a quel punto continua con l'esecuzione del programma gestendo la variabile dalla SRAM.
Qualunque valore tu debba creare, la CPU lo farà sempre nella SRAM. Anche una stringa non sfugge a questa regola: la CPU prima la copierà nella SRAM e dopo la leggerà. Ecco perché la memoria si consuma velocemente.
Con PROGMEM si usa invece la possibilità di leggere il valore di una variabile (che non è necessariamente una stringa ma può essere anche un byte, ad esempio) direttamente dalla Flash, senza prima copiarla nella SRAM. Ovviamente si possono gestire solo costanti, cioè dati che non cambiano di valore.
Capito sei stato chiaro, poi con gli indirizzi e company ci sarà da ridere, però me lo studio, quello che intendevo prima è:
Posso scrivere 500 caratteri consecutivi da uno sketch apposito di scrittura
EEPROM.write(0, carattere to byte[0]) fino a EEPROM.write(499, carattere to byte[499])
poi butto via questo schetch e carico un web server normalissimo che nel client.print mi scrive i caratteri
da EEPROM.read(0, byte[0]) fino a EEPROM.read(499, byte[499])
la mia pagina web iniziale sarà per sepre nella eeprom giusto? fino a quando ovviamente non vado a riscrivere
Qualsiasi sketch che vado a mettere resetto, spengo, accendo, la pagina è sempre lì?
Altrimenti che memoria sarebbe
Chiedo prima di mettermi a tirare giù programmi e chissà magari qualche santo
Se funziona bene con una i2c da 2048 potrei mettere tutto li sono molti file... magari più veloce che leggere da SD (questo non lo so ancora) ..ma sarebbe fantastico!
siccome scriverò molte volte per provare, mi chiedevo quando scrivo 500 volte con il write tolgo 500 cicli di vita dai 100.000 o ne tolgo 1 per ogni cella?
Oggi sono in vena di domande scusate, ma dai non ne faccio quasi mai
grazie ciao
Sì, generalmente si fa così. Si programma la EEPROM con uno sketch "programmatore" dopo di che si carica lo sketch che userà i dati in EEPROM.
L'uso di una EEPROM esterna non cambia la procedura. Ricordati però che qualunque valore tu leggerai dalla EEPROM verrà riversato in una variabile, quindi non leggere tutti i 500 byte insieme altrimenti la CPU crea un array di 500 byte nella SRAM.
Scritture: ogni scrittura togli 1 "vita" alla cella di memoria che hai usato, non a tutta la EEPROM.
uwefed:
1 vita a ogni cella o 1 vita ad ogni cella del blocco che contiene la cella?
Ciao Uwe
Bisogna vedere il costruttore sotto che condizioni ha fatto i test, secondo me, e quindi cosa intenda per "endurance". Generalmente le EEPROM sono strutturate per essere accessibili a singoly byte per cui se anche un solo elemento di un byte si rovina quel byte è perso.
In poche parole:
L' ossido che isola il gate flotante con i cicli di cancellazione/scrittura si deteriora e perde l' isolazione facendo scaricare la carica portata sul gate flotante.
Questo vuiol dire che la cella di memoria non si rompe di botto ma perde dopo un po di tempo il suo stato logico quando sono immagazinati elettroni sul gate. Qusto si verifica solo se lo stato logico che corrisponde la presenza di elettroni sia memorizzato in quella cella (non scrivo H o L perchße dipende dalla tipo di cella). Se in quella cella viene memorizzato lo stato logico senza cariche il valore é stabile e la cella di memoria funziona senza dare problemi. Se in quel bit viene memorizzato lo stato logico che corrisponde a delle cariche queste possono scaricarsi dopo un po di tempo.
La seconda possibilitá di deterioramento é che dei elettrodi si bloccano al'interno del ossido e blocca la possibiltá di mettere cariche sul gate floante.
La cosa si peggiora quando si usano celle multilevel dove a secondo della quantitá di carica immessa sono memorizzato piú di un bit.
Bene, grazie per la tua spiegazione ai livelli sub-atomici :), facciamo così, ho 200 chance circa mi segno tutte le volte che vado a scrivere e vediamo cosa succede, anche se presumo che parta prima la sram ormai dopo 6 mesi di scrivi riscrivi mi aspetto da un momento all'altro che muoia.
Si volevo dire flash scusate.
Ho scritto i 500 byte e funziona perfettamente, bisognerebbe inventare una libreria per zippare le innumerevoli parole lunghe e ripetute codificandole in qualche modo, si potrebbe risparmiare un 25-30% di mem
Grazie per le info
Vox clamantis in deserto ... non è sempre vera io ascolto i consigli