Newsgroup: it.hobby.elettronica.digitale
Titolo: Sgrunt alla paginazione

Ciao!
Sto usando una M95320 (EEPROM seriale da 32 kbit) e come al solito non 
si può scrivere l'intero array ma occorre gestire a manina la 
paginazione (si soli 32 byte).
Ho quindi due domande:
1) La mia funzione di scrittura generica è:
void M95320_Write(uint16_t address, uint16_t len, uint8_t src[]);
che richiamerà quante volte necessario una funzione interna per 
segmentare secondo le pagine.
Quale è un modo semplice per scomporla in n chiamate ogni volta che si 
incontra il limite di pagina (32 byte)?
Io pensavo a qualcosa del genere:
prima chiamata
address_1 = address
len_1 = ((address / 32) + 1) * 32 - address
chiamate successive
address_n = address_{n-1} + 1;
scrivo blocchi di 32 byte fino ad esaurimento scorte
2) Visto che odio la paginazione, ci sono in giro EEPROM / Flash SPI di 
varia capacità che NON deleghino all'utente la paginazione? Dove cioè il 
contatore interno si incrementi byte dopo byte lungo tutta la dimensione 
della memoria.
2bis) Ma quale è il vantaggio di avere una memoria da 32 kbit (o più) 
scrivibile a soli 32 byte per volta?
Grazie :)
Marco / iw2nzm

 
la dimensione della pagina dipende dalla architettura 'interna' della 
flash/eeprom se ho capito bene internamente il dispositivo scrive sempre 
tutta la pagina


 tutta la pagina
Come sopra, capisco che la paginazione sia un'esigenza *interna* ma 
l'utente che vantaggio ne trae? A me sembra più una limitazione che si 
potrebbe risolvere con la logica interna alla memoria stessa, sbaglio?
Ciao!
Marco / iw2nzm

 dozzina di volte
Aggiustato per il mio contesto funziona alla perfezione ed è molto 
meglio della mia proposta!


 potrebbe risolvere con la logica interna alla memoria stessa, sbaglio?
Quello che ti sfugge è che i dati non vengono mica scritti byte per byte
mentre li trasferisci sul bus SPI. In realtà essi vengono trasferiti
velocemente in un buffer SRAM (grande appunto come una pagina), ma
dopodiché per trasferire effettivamente il buffer nella pagina della EEPROM
serve un tempo enormemente più grande, dell'ordine di grandezza dei
millisecondi. E ovviamente sarebbe stato molto più aleatorio e insensato
dire all'utente "oh, stai attento che quando passi la boundary della pagina
devi smettere di trasferire i dati sul bus SPI per N millisecondi". :)
-- 
emboliaschizoide.splinder.com

 devi smettere di trasferire i dati sul bus SPI per N millisecondi". :)
Beh è esattamente quello che succede! Quando devo interrompere la 
scrittura per reindirizzare la pagina devo aspettare parecchi ms proprio 
per dare il tempo di scriverla effettivamente in memoria.
Nella mia idea questo è il tipico caso di un protocollo xon/xoff dato il 
  buffer limitato. Ma non vedo nessuna relazione con il fatto di dover 
inviare un nuovo comando di scrittura e un nuovo indirizzo solo per 
incrementarlo di uno :)
Ciao!
Marco / iw2nzm

scrivibile a soli 32 byte per volta?
Non ne vedo, io ad esempio ho usato le ST M24512 perchè costano molto meno delle
ramtron ma almeno hanno un buffer di 128 bytes, che mi basta per salvare lo
stato macchina dopo una mancanza rete.
--
ciao
  Stefano

 per dare il tempo di scriverla effettivamente in memoria.
Sì, ma nel frattempo il bus SPI lo rilasci. L'unica utilità
dell'autoincremento l'avresti se potessi scrivere uno stream continuo di
dati con un singolo comando, ma dato che questo non è generalmente
possibile...
-- 
emboliaschizoide.splinder.com

 possibile...
Ok, ricevuto!
Marco / iw2nzm

 potrebbe risolvere con la logica interna alla memoria stessa, sbaglio?
E' presto detto.
Capita sovente che un'improvvisa mancanza di alimentazione alla scheda
impedisca il salvataggio di parametri nelle EEPROM precedentemente
mantenuti in RAM per questioni di accesso veloce e frequente
variazione.
In tal caso, si usa supervisionare la tensione prima del filtro (ad
es. subito dopo il ponte) per generare un interrupt non mascherabile
in grado di fare un corretto shut-down al micro.
Il tempo di shut-down, però, è limitato dalla carica del condensatore
di filtro perché, scaricato quello oltre un certo limite, scatta anche
il reset e buona notte al secchio.
Le EEPROM a pagine permettono un rapido trasferimento dei dati dal
micro ed effettuano una scrittura parallela.
Se scrivessero un byte alla volta, occorrerebbe sequenziare la
moltitudine di parametri da salvare ed il tempo sarebbe eccessivo.
Mi ci sono scornato personalmente.
E' chiaro che si incasina il software, ma il trucco sta nel disporre
nella RAM del micro i parametri da trasferire già organizzati in
sequenza, anche a sacrificio di qualche byte.
Per cambiare un solo byte, occorre leggere la pagina, metterla in un
buffer, cambiare il dato, riscrivere la pagina.
Ovviamente disabilitando le interruzioni od usando dei flag semaforo.
Piccio.

 micro ed effettuano una scrittura parallela.
Nel senso che i dati da salvare li fai stare in un'unica pagina e quindi 
la scrittura rimane veloce?
Se intendevi questo io nel caso indicato utilizzo la EEPROM interna al 
micro per salvare le variabili da mantenere e uso la memoria esterna 
solo per i dati veri e propri. In caso di power failure se stavo 
scrivendo qualcosa interrompo subito e salvo nella EEPROM interna le 
variabili compresa l'ora della mancanza di alimentazione e lo stato 
della scrittura.
Onestamente trovo più plausibile - o meglio, di primaria importanza - la 
motivazione di dalai lamah e cioè che durante il tempo di memorizzazione 
posso rilasciare il bus SPI.
Dico questo perché in un certo qual modo il tempo di scrittura sarebbe 
più o meno lo stesso in entrambi i casi: scrivendo una pagina di 32 byte 
(esempio) hai 5 ms di attesa, se scrivesse 1 byte alla volta saremmo sui 
150 us a spanne.
Ciao!
Marco / iw2nzm

 150 us a spanne.
Il caso specifico riguardava il microwire.
Il tempo di scrittura di un byte o di una intera pagina era
praticamente identico.
Nell'I2C si risparmia qualcosa nel protocollo di trasmissione perché
non si devono re-inviare start, stop, indirizzi ecc.
Effettivamente con la paginazione sarebbe prudente scrivere anche il
CRC.
In caso di interruzione di alimentazione, potrebbe non esserci il
tempo di verificare i dati una volta scritti.
Piccio.

 praticamente identico.
