next topic »

[Reply #15 on:]

 

[Reply #16 on:]

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.

Ciao Uwe

[Reply #17 on:]

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.

[Reply #18 on:]

La SRAM è fatta per durare teoricamente all'infinito.
O forse ti riferisci alla Flash? Questa è data per 10.000 cicli di scrittura.

[Reply #19 on:]

La RAM (SRAM o DRAM ma anche FRAM) non ha effetti di deterioramento percui il numero di scrittura/lettura é illimitato.
Ciao Uwe

[Reply #20 on:]

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

ciao

[Reply #21 on:]

Scusami. Non mi sembra sensato programmare un alogaritmo di compressione dati per poter gestire 1kByte di EEprom. Mi sembra che perdi piú spazio per la tabella di codifica che guadagni con da codifica.
 Ok, se usi solo caratteri puoi risparmiare qualcosa ma costa di meno (lavorao é anche denaro anhce se é tempo libero) aggiungere un EEprom o Fram esterna.
Ciao Uwe

[Reply #22 on:]

Si è vero che spendi spazio per la decodifica, però è anche sproporzionato il rapporto flash 256k - eeprom 4k.
Comunque io non mi metto a farla di sicuro 

ciao

[Reply #23 on:]

La seconda possibilitá di deterioramento é che dei elettrodi si bloccano al'interno del ossido e blocca la possibiltá di mettere cariche sul gate floante.

E' la piu' probabile!

In pratica l'effetto tunnel si basa sulla capacita' che possiedono le particelle quantistiche di attraversare una barriera di potenziale piu' alta dell'energia che avrebbero a disposizione, pero' ad ogni iterazione di scrittura e cancellazione ci sono delle perdite energetiche i cui effetti si accumulano nel tempo e fanno degenerare il sottilissimo ossido del floating gate alzandone anche la barriera di potenziale

Togli e metti togli e metti di pochissimo alla volta ma sommato nel tempo, dopo 10^6 volte che lo fai, hai alzato sensibilmente la barriera di potenziale, e, vero che nel giochino quantistico si gioca con particelle che sono capaci per effetto tunnel di attraversare una barriera di potenziale piu' alta dell'energia che avrebbero a disposizione, ma ora il problema non e' mettere elettroni ma toglierli, e per toglierli ti serve fare dichiamo dal drain, e per farlo ti serve molta piu' energia, ed e' toppa per non fare danni, perche' se lo fai (ipotizznado che tu lo possa fare p.e. usando campi elettrici maggiori, alcune vecchie flash hanno Vpp esterna) magari il drain resta sano ma alteri sicuramente le proprieta' dielettriche del gate che e' sottilissimo e male sopporterebbe il tutto.

La cella e' finita, epitaffio di stato logico ='(

[Reply #24 on:]

Si è vero che spendi spazio per la decodifica, però è anche sproporzionato il rapporto flash 256k - eeprom 4k.
Comunque io non mi metto a farla di sicuro 
ciao

Di quale microcontroller parliamo?
Ciao Uwe

[Reply #25 on:]

http://arduino.cc/it/Main/ArduinoBoardMega2560
questo

[Reply #26 on:]

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

Se parliamo di parole ripetute spesso, puoi già farlo con una semplice tabella di sostituzione.
Ad esempio, se nei messaggi o nel testo che devi memorizzare compaiono spesso parole come "errore", "riprova", "inserisci", "dati", "lettura", ecc... puoi crearti un array in cui metti questi termini e da cui richiami con un semplice indice.
Ad esempio. Mettiamo che hai la stringa "errore dati. riprova", e che hai un array contenente nelle prime 4 celle:
errore
dati
riprova
inserisci

basta stamapare (o inviare) termini[0]+termini[1]+termini[2]. Se poi devi scrivere "inserisci dati", basta inviare termini[3]+termini[1].

Se però parliamo di un vero e proprio algoritmo di compressione, la vedo dura sfruttare questo sistema per salvare i dati in pochi kB di dati, come ha detto Uwe le tabelle per decomprimere i dati porterebbero anch'esse via dello spazio per cui alla fine il guadagno dello spazio recuperato sarebbe pareggiato dal costo per il setup iniziale.
Piuttosto se i dati non sono moltissimi puoi usare direttamente la Flash con PROGMEM oppure, soluzione alternativa e forse più economica, una comune SD che è proprio la soluzione adottata dallo shield Ethernet: le schede SD altro non sono che Flash di grosse dimensioni formattabili con un filesystem di modo che è possibile salvare un file direttamente.