Eeprommiin laskurin arvon tallennus toistuvasti

[dsl]

Mikrokontrollerin eeprommiin pitää tallentaa laskurin arvo. Laskuri
kasvaa aina yhdellä. Eeprommiin voi tallentaa vain 10 000 kertaa,
mutta laskurin arvot kulkevat 0:sta 100 000:een koko laitteen
elinkaaren aikana. Käytettävissä on muutama kymmenen tavua eeprommia
(joku pic tai atmega, ei vielä valittu).

Eli siis perinteinen normaali tallennus aina samaan kohtaan
eeprommuistia ei taida onnistua, koska tallennuskertoja tulee liikaa.

Voisiko laskurin arvon koodata esim Gray-koodiksi, jolloin joka kerta
tallennettaessa muuttuisi vain yksi bitti? (Laskurihan kasvoi aina
yhdellä.) Ja tallennus niin, että jokainen laskurin bitti tallennetaan
omaan tavuunsa eeprom muistissa.

Vai onko gray-koodikaan hyvä tapa? Kokemukset ja linkit aiheesta ovat
tervetulleita:-)

[Kristian Ukkonen]

Post by dsl
Mikrokontrollerin eeprommiin pitää tallentaa laskurin arvo. Laskuri
kasvaa aina yhdellä. Eeprommiin voi tallentaa vain 10 000 kertaa,
mutta laskurin arvot kulkevat 0:sta 100 000:een koko laitteen
elinkaaren aikana. Käytettävissä on muutama kymmenen tavua eeprommia
(joku pic tai atmega, ei vielä valittu).
Eli siis perinteinen normaali tallennus aina samaan kohtaan
eeprommuistia ei taida onnistua, koska tallennuskertoja tulee liikaa.
Voisiko laskurin arvon koodata esim Gray-koodiksi, jolloin joka kerta
tallennettaessa muuttuisi vain yksi bitti? (Laskurihan kasvoi aina
yhdellä.) Ja tallennus niin, että jokainen laskurin bitti tallennetaan
omaan tavuunsa eeprom muistissa.
Vai onko gray-koodikaan hyvä tapa? Kokemukset ja linkit aiheesta ovat
tervetulleita:-)

Käytä 20 8-bittistä tavua.. Jokaisella 10 16-bittisellä tavulla
lasket 10000 asti, ja sitten siirryt seuraavaan.. Noin jokaiseen
tulee vaan 10000 kirjoituskertaa. Laita vielä yksi tavu, jossa on
nykyisen laskuritavun luku N (joka on 0-9), niin tiedät suoraan
laskurin arvon eli N*10000+nykyisen laskuritavun arvo..

Kristian Ukkonen.

[Ari Laitinen]

Post by dsl
Vai onko gray-koodikaan hyvä tapa? Kokemukset ja linkit aiheesta ovat
tervetulleita:-)

Gray koodaus voisi olla hyvä tapa. Ongelmasihan on juurikin jakaa muutokset
tasaisesti kaikkiin tavuihin, joissa säilytät laskurin arvoa.

Jos tarvitset laskea 100000 asti niin tuo onnistuu 17 bitillä, jotka vievät
kolme tavua. Jos sijoitat 6 bittiä per tavu yhteensä kolmeen tavuun tulee
muutoksia yhä liian paljon per tavu. Joudut jakamaan tavittavat bitit 10
tavuun eli kaksi bittiä per tavu.

Gray koodaamiseen on valmiita kaavoja http://en.wikipedia.org/wiki/Gray_code

Toinen konsti olisi tehdä ryömivä laskuri. Siinä laskuri liikkuu eteenpäin
siten, että alussa lasku alkaa tavusta 0, johon lasketaan 0..254 ja ylivuoto
siirretään seuraavaan tavuun. Kun on saavutettu arvo 254,39 niin
asetetaankin 0. tavun arvoksi 255, joka mitätöi sen. Seuraavan kerran
lasketaankin sitten alkaen tavusta 1.

Algoritmi on hyvin yksinkertainen ja se käyttää kutakin tavua 254*39+1
kertaa = 9907. Laskenta siis etenee näin

0,0,0
1,0,0
2,0,0
..
253,0,0
254,0,0
0,1,0
1,1,0
2,1,0
..
253,1,0
254,1,0
0,2,0
1,2,0
2,2,0
..
253,39,0
254,39,0
255,39,0
255,40,0
255,41,0
255,42,0
..
255,254,39
255,255,39
255,255,40
255,255,41
...

[Mika Iisakkila]

Post by Kristian Ukkonen

Post by dsl
Mikrokontrollerin eeprommiin pitää tallentaa laskurin arvo. Laskuri
kasvaa aina yhdellä. Eeprommiin voi tallentaa vain 10 000 kertaa,
mutta laskurin arvot kulkevat 0:sta 100 000:een koko laitteen
elinkaaren aikana.

Käytä 20 8-bittistä tavua.. Jokaisella 10 16-bittisellä tavulla
lasket 10000 asti, ja sitten siirryt seuraavaan.. Noin jokaiseen
tulee vaan 10000 kirjoituskertaa. Laita vielä yksi tavu, jossa on
nykyisen laskuritavun luku N (joka on 0-9), niin tiedät suoraan
laskurin arvon eli N*10000+nykyisen laskuritavun arvo..

Varmaan ihan hyvä systeemi, en tosin tainnut tajuta sitä tuosta
selostuksesta :D Ainakin siinä on se huono puoli, että yksittäisen
slotin kirjoituskertoja käytetään hyvin pitkälle ennen kuin siirrytään
seuraavaan, ja joku kerta se vielä napsahtaa ei-toimivan puolelle.

Kirjoituskerrathan palavat varmaankin per tavu eikä per bitti, eli
biteittäin gray-koodaamisesta ei ainakaan ole iloa.

Itse varmaan kierrättäisin N kpl laskurislotteja siten, että
seuraavaksi isompi arvo kirjoitetaan aina seuraavaan slottiin.
Käyttöönotettaessa kaikki alustetaan nollaan, ja bootin yhteydessä
kelataan kaikki laskurit läpi jotta saadaan suurin entinen lukema;
sitten jatketaan taas. Siinä yhteydessä voidaan myös hylätä lukemat,
jotka eivät kuulu monotoniseen sarjaan siltä varalta, että värkki on
esimerkiksi kipannut kesken päivityksen ja slottiin on tallentunut
soopaa.

Ärsyttäväksihän tämän tekee tuo 100.000, joka ei mene järkevästi
mihinkään tavujakoon. Jos eepromissa on ahdasta, pitää ehkä pakata ne
17 merkitsevää bittiä jotenkin muuten kuin kolme tavua per laskuri.

Mutta kas, suurinta tallennettua arvoa säilövän slotin
järjestysnumerosta saadaan yksi digitti (N-kantaisessa
lukujärjestelmässä) lisää. Eli jos slotteja on 10 ja niissä on
sisällöt:

2 2 2 1 1 1 1 1 1 1

...on viimeksi tallennettu arvo 13, ja seuraava tallennuspaikka on
neljäs slotti, johon pannaan sitten kakkonen. Ja nyt koko hoidon
pitäisi mahtua 10x2 tavuun, jos suurin tallennettava arvo on 100.000
ja kirjoituskertoja sallitaan 10.000. Tämä taitaa olla suunnilleen
sama kuin tuo Kristianin idea, paremmin hajautettuna vain.

[Ari Laitinen]

Post by Mika Iisakkila
Kirjoituskerrathan palavat varmaankin per tavu eikä per bitti, eli
biteittäin gray-koodaamisesta ei ainakaan ole iloa.

Kyllä on sillä muutokset jakaantuvat tasaisesti kaikkiin bitteihin eikä vain
ensimmäisiin.

[dsl]

Tässä on tullutkin hyviä ideoita Kristianilta, Arilta ja Mikalta.

Itseasiassa gray tai balanced gray algoritmit ovat aika työläitä
kontrollerille. Itselleni tuli mieleen näiden herrojen myötä nyt
sellainen vaihtoehto, että mikrokontrolleri ohjelmassa käyttetään
laskuria unsigned long tyyppisenä lukuna (32 bittiä). Tämä
tallennetaan lähes tavalliseen 24-bittiseen eli kolmeen 8-tavuiseen
muuttujaan eeprommissa. Jokainen näistä tavuista pitää tallentaa
erikseen 8-bittisellä mikrokontrollerilla.

Ylin tavu vaihtuu vain kerran 65 tuhannen kieppeillä 00->01. (Ei
ongelmaa)
Keskimmäinen tavu vaihtuu 256 välein eli (100000/256=) 390 kertaa. (Ei
ongelmaa)

Alin tavu vaihtuu liikaa (100 000 kertaa), joten se jaetaan 16 eri
tavuun. Kun tallennus suoritetaat tasapuolisesti kaikkiin tavuihin
lähes vuoronperään, niin 100 000 kohdalla jokaiseen tavuun on
kirjoituttu (100000/16=) 6250 kertaa. Alintavu muodostaa 16 paikkaisen
taulukon. Indeksi taulukon oikeaan kohtaan saadaan keskimmäisen tavun
neljästä alimmaisesta bitistä (keskimmäinen_tavu & 0x0f). Jokaiseen
taulukon kohtaan tllennataan siis 256 perättäistä laskurin arvoa
kerralla ja sitten siirrytään seuraavaan tavuun.

[Kristian Ukkonen]

Post by Kristian Ukkonen
Käytä 20 8-bittistä tavua.. Jokaisella 10 16-bittisellä tavulla
lasket 10000 asti, ja sitten siirryt seuraavaan.. Noin jokaiseen
tulee vaan 10000 kirjoituskertaa. Laita vielä yksi tavu, jossa on
nykyisen laskuritavun luku N (joka on 0-9), niin tiedät suoraan
laskurin arvon eli N*10000+nykyisen laskuritavun arvo..

Eli ajatus olisi että olisi tavuja (n on siis int vektori):
n = {1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
mistä eka kertoo mikä seuraavista on todellinen laskuritavu.
laskurin senhetkisen arvon laskenta tyyliin
(n[0]-1)*10000+n[n[0]]
ja lisäys
if (n[n[0]] > 9999) n[0]++; // tarkasta raja
n[n[0]]++; // lisää yhdellä

Eli laskenta menisi
1 0 0 0 0 0 0 0 0 0 0
1 1 0 0 0 0 0 0 0 0 0
1 2 0 0 0 0 0 0 0 0 0
...
1 9999 0 0 0 0 0 0 0 0 0
1 10000 0 0 0 0 0 0 0 0 0
2 10000 1 0 0 0 0 0 0 0 0
2 10000 2 0 0 0 0 0 0 0 0
...
2 10000 9999 0 0 0 0 0 0 0 0
2 10000 10000 0 0 0 0 0 0 0 0
3 10000 10000 1 0 0 0 0 0 0 0
...

ja noin joka 16bit tavua tulee käytettyä maksimissaan 10000 kertaa..
Jos vaan tilaa eepromissa löytyy, tuo on aika idioottivarma tapa tehdä..

Kristian Ukkonen.

[Ari Saastamoinen]

Post by dsl
Mikrokontrollerin eeprommiin pitää tallentaa laskurin arvo. Laskuri
kasvaa aina yhdellä. Eeprommiin voi tallentaa vain 10 000 kertaa,
mutta laskurin arvot kulkevat 0:sta 100 000:een koko laitteen
elinkaaren aikana. Käytettävissä on muutama kymmenen tavua eeprommia

EEPROMeihin en ole tutustunut, joten mutuilen jotain FLASH- ja
EPROM-kokemusten kautta. Voiko EPROMissa tyhjentää yksittäisen byten,
vai onko siinä joku eraseblokki samoin kuin FLASHeissa? Mikä operaatio
tuota muistia vanhentaa? AIka monissa muistityypeissä on muistin
(muistipaikan) tyhjentäminen se, joka tuota elinkaarta lyhentää. Jos
tuo käyttämäsi EEPROM on jotain saman tyyppistä, niin algoritmi
kannattaa suunnitella niin, että tyhjennyksiä tulee mahdollisimman
vähän. Siis jos on joku eraseblokki, niin tuo koko blokki kannattaa
käyttää kokonaan ennenkuin se tyhjennetään, ja samaa bittiä ei kannata
käännellä jatkuvasti edestakaisin, joten ensin tyhjennys
(lopputuloksena todennäköisesti pelkkiä ykkösiä) ja sitten nollataan
bittejä yksitellen, näin ollen yhteen muistipaikkaan voidaan
kirjoittaa kahdeksan kertaa ilman tyhjennystä. Ja sitten tuosta
kehitellä eteenpäin. (Tosin kuten sanoin, niin EEPROMien ominaisuudet
ei ole mulle tuttuja, ja voi olla että niitten käyttöön tämä
täyttöidea ei ole järkevä)

[dsl]

Post by Ari Saastamoinen

Post by dsl
Mikrokontrollerin eeprommiin pitää tallentaa laskurin arvo. Laskuri
kasvaa aina yhdellä. Eeprommiin voi tallentaa vain 10 000 kertaa,
mutta laskurin arvot kulkevat 0:sta 100 000:een koko laitteen
elinkaaren aikana. Käytettävissä on muutama kymmenen tavua eeprommia

EEPROMeihin en ole tutustunut, joten mutuilen jotain FLASH- ja
EPROM-kokemusten kautta.  Voiko EPROMissa tyhjentää yksittäisen byten,
vai onko siinä joku eraseblokki samoin kuin FLASHeissa? Mikä operaatio
tuota muistia vanhentaa?  AIka monissa muistityypeissä on muistin
(muistipaikan) tyhjentäminen se, joka tuota elinkaarta lyhentää.  Jos
tuo käyttämäsi EEPROM on jotain saman tyyppistä, niin algoritmi
kannattaa suunnitella niin, että tyhjennyksiä tulee mahdollisimman
vähän.  Siis jos on joku eraseblokki, niin tuo koko blokki kannattaa
käyttää kokonaan ennenkuin se tyhjennetään, ja samaa bittiä ei kannata
käännellä jatkuvasti edestakaisin, joten ensin tyhjennys
(lopputuloksena todennäköisesti pelkkiä ykkösiä) ja sitten nollataan
bittejä yksitellen, näin ollen yhteen muistipaikkaan voidaan
kirjoittaa kahdeksan kertaa ilman tyhjennystä.  Ja sitten tuosta
kehitellä eteenpäin.  (Tosin kuten sanoin, niin EEPROMien ominaisuudet
ei ole mulle tuttuja, ja voi olla että niitten käyttöön tämä
täyttöidea ei ole järkevä)
--
  1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
      paukku voi aiheuttaa hairiota.        - Iso-Kiinalaisen kayttoohje

Flashin ja eeprommin suurin ero on tyhjennys. Eeprommiin voidaan
kirjoittaa yksittäisiä tavuja eikä tarvitse mitään lohkoja tyhjennellä
missään välissä.

Jokainen yksittäinen tavu voidaan kirjoittaa 10t kertaa. Sitä en osaa
sanoa, että onko tavun sisällöllä merkitystä kirjoituskertoihin.

[Pasi Ojala]

Post by Ari Saastamoinen
Voiko EPROMissa tyhjentää yksittäisen byten,

Anteeksi lopun leikkaaminen, olet siinä ihan jäljillä, ehdotan vähän
samaa.

Eli EEPROMissa kuten single-level-cell flasheissa erasointi kääntää
bitit ykkösiksi ja ohjelmointi kääntää nollabitit nolliksi. EEPROMissa
voidaan erasoida yksittäisiä tavuja, siis normaali kirjoitusoperaatio
luultavasti aina erasoi tavun. FLASHeissä erasointi tehdään itse.
(Multi-level-cell FLASH vaatii että erasointien välissä on vain yksi
kirjoitusoperaatio.)

FLASHeillä tulisi kyseeseen bittien kääntö nollaksi yksi kerrallaan,
silloin yhteen tavuun tulisi 8 kirjoitusta, ja sitten mentäisiin
seuraavaan tavuun. Esim. SPI FLASH -piirillä joka tukee 4kB erase-pagea
Saadaan laskettua 32760 joka erasointia kohti kun erään ehdotuksen
kierroslaskuri N talletetaan ekaan tavuun.

Vaihtoehtoinen tapa on tehdä uusi 4 tavun tietue kunnes 4kB on käytetty
ja sitten erasoida ja aloittaa alusta.

EEPROMilla toimii samanlainen kierrätys, erasointi vain tapahtuu
automaattisesti. Ja jos laskuri menee aina ylöspäin, riittää tuosta 4kB
alueesta etsiä suurinta arvoa (0xffffffff jätetään huomiotta).

Olisi kiinnostavaa testata erasoiko EEPROM kirjoitettavan paikan aina
vaikka se ei olisi tarpeen (silloin kun ohjelmoitava arvo kääntää
vain olemassa olevan ykkösen nollaksi).

[Timo Neuvonen]

Mikrokontrollerin eeprommiin pitää tallentaa laskurin arvo. Laskuri kasvaa
aina yhdellä. Eeprommiin voi tallentaa vain 10 000 kertaa, mutta laskurin
arvot kulkevat 0:sta 100 000:een koko laitteen elinkaaren aikana.
Käytettävissä on muutama kymmenen tavua eeprommia (joku pic tai atmega, ei
vielä valittu).

Bittimaailmassa tulee välillä turhaankin tavoiteltua täydellisyyttä vaikka
sovellus ei sitä vaatisi. En tiedä mitä tapahtumia tässä lasketaan, ts.
pitääkö laskennan olla absoluuttisen tarkka? Jos sähkö pääsääntöisesti ei
katkea kirjoituskertojen välillä, ja satunnaisia pieniä sähkökatkoista
johtuvia virheitä voisi sallia, niin yksi hyvin helppo tapa on pitää laskuri
rammissa, ja vain silloin tällöin päivittää sisältö eeprommin. Tai voisi
tehdä rammipohjaisen laskurin joka laskee esim. 16 saakka ja sitten
nollautuu, ja vain nämä ylivuodot lasketaan sinne eeprommiin, jolloin
eeprommiin tarttisi vain 2-tavuisen laskurin.

--
TiN

[Tomppa]

Post by dsl
Mikrokontrollerin eeprommiin pitää tallentaa laskurin arvo. Laskuri
kasvaa aina yhdellä. Eeprommiin voi tallentaa vain 10 000 kertaa,
mutta laskurin arvot kulkevat 0:sta 100 000:een koko laitteen
elinkaaren aikana. Käytettävissä on muutama kymmenen tavua eeprommia
(joku pic tai atmega, ei vielä valittu).
Eli siis perinteinen normaali tallennus aina samaan kohtaan
eeprommuistia ei taida onnistua, koska tallennuskertoja tulee liikaa.
Voisiko laskurin arvon koodata esim Gray-koodiksi, jolloin joka kerta
tallennettaessa muuttuisi vain yksi bitti? (Laskurihan kasvoi aina
yhdellä.) Ja tallennus niin, että jokainen laskurin bitti tallennetaan
omaan tavuunsa eeprom muistissa.
Vai onko gray-koodikaan hyvä tapa? Kokemukset ja linkit aiheesta ovat
tervetulleita:-)

Tee tallennus rammiin ja varmennus paristolla.
Vain sähkökatkon tms aikana pikainen tallennus eeprommiin. ?

[Juha Lyytikäinen]

Post by Tomppa
Tee tallennus rammiin ja varmennus paristolla.
Vain sähkökatkon tms aikana pikainen tallennus eeprommiin. ?

..tai kondensaattori sähkönsyöttöön ja tulojännitteen tunnustelu
keskeytysnastaan. Kun tulojännite katoaa niin silloin on viellä aikaa
kondensaattorin voimalla tehdä tallennus pysyvään muistiin.

[Tomppa]

Post by Juha Lyytikäinen

Post by Tomppa
Tee tallennus rammiin ja varmennus paristolla.
Vain sähkökatkon tms aikana pikainen tallennus eeprommiin. ?

..tai kondensaattori sähkönsyöttöön ja tulojännitteen tunnustelu
keskeytysnastaan. Kun tulojännite katoaa niin silloin on viellä aikaa
kondensaattorin voimalla tehdä tallennus pysyvään muistiin.

Niin. Samapa tuo kummalla varavoimalla.

[LM]

Post by dsl
Mikrokontrollerin eeprommiin pitää tallentaa laskurin arvo. Laskuri
kasvaa aina yhdellä. Eeprommiin voi tallentaa vain 10 000 kertaa,
mutta laskurin arvot kulkevat 0:sta 100 000:een koko laitteen
elinkaaren aikana. Käytettävissä on muutama kymmenen tavua eeprommia
(joku pic tai atmega, ei vielä valittu).
Eli siis perinteinen normaali tallennus aina samaan kohtaan
eeprommuistia ei taida onnistua, koska tallennuskertoja tulee liikaa.
Voisiko laskurin arvon koodata esim Gray-koodiksi, jolloin joka kerta
tallennettaessa muuttuisi vain yksi bitti? (Laskurihan kasvoi aina
yhdellä.) Ja tallennus niin, että jokainen laskurin bitti tallennetaan
omaan tavuunsa eeprom muistissa.
Vai onko gray-koodikaan hyvä tapa? Kokemukset ja linkit aiheesta ovat
tervetulleita:-)

Mikset testaa eeprommuistipaikkaa tarttuiko uusi data? Jos ei, siirry
seuraavaan. Jossain pitää olla myös eeprommimuistissa laskuri/osoitin
joka kertoo missä oikea luku on. Se ei ainakaan muutu kuin joka (noin)
10000 kerta.

[Jukka Marin]

Post by dsl
Mikrokontrollerin eeprommiin pitää tallentaa laskurin arvo. Laskuri
kasvaa aina yhdellä. Eeprommiin voi tallentaa vain 10 000 kertaa,
mutta laskurin arvot kulkevat 0:sta 100 000:een koko laitteen
elinkaaren aikana. Käytettävissä on muutama kymmenen tavua eeprommia
(joku pic tai atmega, ei vielä valittu).

Entäs ulkoinen EEPROM? Kestävät miljoona kirjoituskertaa.

Toinen tapa on jakaa arvon LSB useamman tavun kesken (kuten joku ehdottikin).

-jm

[Mika Iisakkila]

Tuli vielä pari juttua mieleen. Ensinnäkin se prosessori on rautaa, ei
softaa, eikä siis hirveästi optimoi mitään käyttäjältä salaa. Jos
johonkin tavuun tilataan kirjoitus, se tekee sen. On siis ehkä
hyödyllistä tarkistaa tavuittain (tai mikä se toteutuksen
kirjoitusatomi sitten on) muuttuuko siinä oikeastaan yksikään bitti
ennen kuin ryhtyy mahdollisesti turhaan kirjoittamaan uutta arvoa.

Toisekseen riippuu siitä toteutuksesta kuinka moni muistibitti
kullakin kirjoituksella kuluu. Melkein kaikki integroitua EEPROM:ia
sisältävät prossut, joita itselle tulee mieleen, tekevät sen
tavuittain. Uusi tavu kirjoitetaan johonkin puskurirekisteriin ja
sitten komennetaan kirjoitus varsinaiseen EEPROM:iin (koska se kestää
yleensä todella pitkään verrattuna rekisterin ronkkimiseen).
Edelliseen kappaleeseen viitaten, se todennäköisesti rassaa kyseisen
kirjoitusatomin joka bittiä riippumatta siitä, muuttuiko yksittäinen
bitti vai ei. Tämä tekee sen yksinkertaisen gray-koodauksen turhaksi:
ei hyödytä mitään, jos vain yksi tavun bitti vaihtuu, kun kaikki
kahdeksan kirjoitetaan kuitenkin.

Mutta kai tämä on jo aika akateemista, onhan näitä ratkaisuja jo
lueteltu...

Tähänhän kannattaa tietenkin kirjoittaa simulaattoriohjelma, jos ei
kärsivällisyys riitä valitun ratkaisumallin teoreettiseen
validointiin :)

[Juha Lyytikäinen]

Post by Mika Iisakkila
Edelliseen kappaleeseen viitaten, se todennäköisesti rassaa kyseisen
kirjoitusatomin joka bittiä riippumatta siitä, muuttuiko yksittäinen
ei hyödytä mitään, jos vain yksi tavun bitti vaihtuu, kun kaikki
kahdeksan kirjoitetaan kuitenkin.

Eikös täällä jo todettu että muistin tyhjennys on ykkösbittien
kirjoitusta muistiin ja kirjoitus siten vain nolla bittien asettamista.

Kuluttaako siis FF arvon asetus muistia olenkaan?
Muistinkirjoituslaskuri varmaan pyörähtää mutta kuluuko muisti oikeasti?

[Mika Iisakkila]

Post by Juha Lyytikäinen

Post by Mika Iisakkila
Edelliseen kappaleeseen viitaten, se todennäköisesti rassaa kyseisen
kirjoitusatomin joka bittiä riippumatta siitä, muuttuiko yksittäinen
ei hyödytä mitään, jos vain yksi tavun bitti vaihtuu, kun kaikki
kahdeksan kirjoitetaan kuitenkin.

Eikös täällä jo todettu että muistin tyhjennys on ykkösbittien
kirjoitusta muistiin ja kirjoitus siten vain nolla bittien asettamista.
Kuluttaako siis FF arvon asetus muistia olenkaan?
Muistinkirjoituslaskuri varmaan pyörähtää mutta kuluuko muisti oikeasti?

Ei siellä mitään laskureita ole. Veivaaminen kuluttaa muistialkioita,
ja jossain vaiheesa ne sitten eivät enää toimi riittävän
luotettavasti. Tämä riittävä luotettavuus on tilastollinen suure, joka
on jollakin tavalla arvioitu niin, että datalehteen voidaan kirjoittaa
muistielementtien kestävän 100.000 kirjoitusta jollakin
todennäköisyydellä (eikä suinkaan niin, että nyt tuli 100.001:s
kirjoitus, taidanpa olla loppuunkulunut bitti ja lakata heilumasta).

Ja tuohon jälkimmäisen kappaleesi kysymykseen tuskin tietävät
vastausta muut kuin piirivalmistajan insinöörit. Yleisellä tasolla
sitä on ihan turha pohtia, voi olla noin tai voi olla olematta. Sitä
minä vaan spekuloin, että kun tarvittavat toiminnot kuitenkin
yritetään saada implementoitua mahdollisimman vähillä transistoreilla
= piiripinta-alalla, niin ei sinne turhan päiten ryhdytä toteuttamaan
jotain himmeitä testejä siitä, että mikä bitti nyt oikeasti vaihtui.
Jos muistiblokki on erasoitavissa = uudelleenkirjoitettavissa tavun
pätkinä, niin sellaisia siellä sitten erasoidaan ja kirjoitetaan.

Ihan rehellisiä N x 1 bitin EEPROM:eja en muista havainneeni kuin
erilliskomponentteina viimeksi joskus 20 vuotta sitten.

[Jari Kaija]

Post by dsl
Vai onko gray-koodikaan hyvä tapa? Kokemukset ja linkit aiheesta ovat
tervetulleita:-)

Taas "hirviän vaikeita" neuvoja tarjolla :-)

Pistät silleen, jotta, jottakun:

Tarkistetaan muistipaikasta, jotta onko laskuri
jo 9999 tai suurempi, jos on, käytetään seuraavaa
muistipaikkaa, jossa tehdään sama vertailu. Näin
tehdään niin pitkään, kunnes löytyy muistipaikka,
jossa luku ei ole vielä "liian suuri" ja lisätään sitten
sinne taas "yksi kerta".

[Jari Kaija]

Post by Jari Kaija

Post by dsl
Vai onko gray-koodikaan hyvä tapa? Kokemukset ja linkit aiheesta ovat
tervetulleita:-)

Taas "hirviän vaikeita" neuvoja tarjolla :-)
Tarkistetaan muistipaikasta, jotta onko laskuri
jo 9999 tai suurempi, jos on, käytetään seuraavaa
muistipaikkaa, jossa tehdään sama vertailu. Näin
tehdään niin pitkään, kunnes löytyy muistipaikka,
jossa luku ei ole vielä "liian suuri" ja lisätään sitten
sinne taas "yksi kerta".

Tai sitten niin, jotta käytetään yksi "infobyte" kertomaan,
jotta monennessako "laskuripankissa" ollaan menossa
ja mennään sen mukaan aina seuraavaan.

Tuolloin voisi tehdä niin, että käytetään samaa kahden
byten muistipaikkaa tuplasti, eli lasketaan ensin ne 4096
ja sitten sen täytyttyä aloitetaan homma alusta ja lisätään
infopankkin arvoa yhdellä. Kun se on kaksi, niin siirrytään
seuraavaan jne.


TAI

Käytetään edelleenkin infobyteä ja siirretään kolmen
byten pointteria muistialueella siten, että aina kun alin
byte on rullannut 10000 kertaa, niin pointterin arvoa
kasvatetaan yhdellä, jotta saadaan seuraavakin byte
äärirajoilleen jnejnejnejne....

[Ari Laitinen]

Post by Jari Kaija
Tarkistetaan muistipaikasta, jotta onko laskuri
jo 9999 tai suurempi, jos on, käytetään seuraavaa
muistipaikkaa, jossa tehdään sama vertailu. Näin

Tuo tuhlaa tavuja koska joka toista tavua käytettäisiin vain muutaman
kerran.

Post by Jari Kaija
tehdään niin pitkään, kunnes löytyy muistipaikka,
jossa luku ei ole vielä "liian suuri" ja lisätään sitten
sinne taas "yksi kerta".

Silloin menee 20 tavua yhteen laskuriin.

Eihän tämä ole ongelma, jos niitä on liikaa, kuten yleensä on.

[Jari Kaija]

Post by Ari Laitinen

Post by Jari Kaija
Tarkistetaan muistipaikasta, jotta onko laskuri
jo 9999 tai suurempi, jos on, käytetään seuraavaa
muistipaikkaa, jossa tehdään sama vertailu. Näin

Tuo tuhlaa tavuja koska joka toista tavua käytettäisiin vain muutaman
kerran.

Post by Jari Kaija
tehdään niin pitkään, kunnes löytyy muistipaikka,
jossa luku ei ole vielä "liian suuri" ja lisätään sitten
sinne taas "yksi kerta".

Silloin menee 20 tavua yhteen laskuriin.
Eihän tämä ole ongelma, jos niitä on liikaa, kuten yleensä on.

Njoo, luikkos jo loputkin ehdotukseni ilman bittien kanssa pelehtimistä...