Képzési kurzus avr
Ebben a cikkben megvizsgáljuk az esetleges problémákat, ha az EEPROM-nal dolgozunk. Néhány ezek közül kapcsolódó hardver oldalon a mikrokontroller, így kárt a EEPROM csökkentett feszültség és korlátozottan rendelkezésre álló erőforrás EEPROM, és egy részét a szoftver, például a EEPROM megszakítások. Az EEPROM-ban tárolt adatok tárolásának megbízhatóságát javító problémák és módszerek megoldásának módja.
Az AVR egyik régi problémája az EEPROM adatok romlása a mikrokontroller leállításával. Ez két esetben fordulhat elő:
- Ha a tápfeszültség bizonyos érték alatt van, akkor az EEPROM-ban lévő bejegyzés nem fog megfelelően végrehajtani.
- Alacsonyabb tápfeszültség mellett a mikrokontroller nem tudja megfelelően végrehajtani a parancsokat.
Ezek az EEPROM adatok károsíthatók az alábbi irányelvek betartásával:
- Az AVR mikrokontrollert vissza kell állítani, ha a tápfeszültség normálérték alatt van. Ehhez külső tápfeszültség felügyelőket vagy a beépített Brown-out Detector (BOD) alkalmazható. A beépített érzékelőt a mikrokontroller - BODEN és BODLEVEL biztosíték bitjei vezérlik. BODEN - engedélyezi / letiltja az érzékelő működését, és a BODLEVEL - határozza meg működésének szintjét.
Ha a mikrokontroller újraindítása az EEPROM felvételi folyamat során történik, az írási művelet csak akkor végezhető el, ha a feszültségszint elegendő.
- Továbbá sok fejlesztő azt javasolja, hogy ne használják a 0th cell EEPROM `a-t, mert a tartalom a leggyakrabban sérült, amikor a mikrokontroller tápellátása csökken.
Az EEPROM-hoz való írásmód több lépésből áll. Emlékezz erre a sorrendre:
Az EEWE bitet 4 órai cikluson belül kell beállítani az EEMWE bit beállítása után. Ha ez nem fordul elő megszakítások miatt, az EEPROM-ban lévő bejegyzés nem kerül végrehajtásra. Ez könnyen elkerülhető a 4. lépést megelőző megszakítások letiltásával és az 5. után is, hogy megoldja őket.
A fentiek leírják az EEPROM olvasási eljárását.
Ezt a következő módon kezelheti:
- Ne használja az EEPROM olvasásait és írja meg a megszakításokat.
Ez különösen igaz az írási műveletre, mert lassú, és egy belső RC oszcillátorral történik. Például a mega16 adatlapon jelezzük, hogy az EEPROM-hoz való íráskor egy belső frekvenciaváltót használunk 1 MHz frekvenciával (függetlenül a CKSEL bitek biztosíték beállításaitól), és a rögzítési idő 8,5 ms. Nagyon sok időt vesz igénybe a megszakítás.
- A megszakítások megakadályozása az EEPROM (azaz olvasás) teljes eljárásának folyamata alatt, vagyis az elején.
- Használjon zászlókat (szemaforek) az EEPROM-hoz való munka végrehajtásának jelzésére.
Mielőtt végrehajtaná a felvételt a fő programhurokban (vagy feladat, ha operációs rendszert használ), állítsa be a program zászlót, és a megszakítás (vagy egyéb feladat) ellenőrizze.
Az EEPROM korlátozott erőforrással rendelkezik. Az Atmel biztosítja, hogy az EEPROM felülírási ciklusainak száma nem kevesebb, mint 100 000. Az ábra elég nagy, de ez akkor érhető el, ha gyakran és hosszú ideig ír az EEPROM-hoz.
Az EEPROM erőforrás "növelésére" két módszer létezik.
Az első egyszerű, és csak akkor írja le az adatokat az EEPROM-ba, ha megváltoztatták az értéküket.
A második trükkös, és nem egy memóriakártyában (vagy egy cellacsoportban, ha többnyelvű változók kérdése), de többször is, és írja be azokat.
Tegyük fel, hogy egy bájtot kell tárolnunk az EEPROM-ban. 8 bájtot osztunk ki, és minden alkalommal a következő cellába írjuk, amikor eljutunk az utolsó cellába, majd írjuk be az elsőbe. És így egy körön, mint körkörös pufferben. Ha mindegyik EEPROM cella 100 000 erőforrással rendelkezik, majd 8 cellában írja le, akkor egy forrást kapunk, amely felülbírálja a 800000 bájtot.
A fordító által a deklarált, de nem használt változókat gyakran törli az optimalizálás során. Ha ilyen változókra van szükség, akkor hozzá kell adnia az előttük változó kulcsszót.
Ha a saját funkcióit használja az EEPROM használatához, problémái lehetnek a nagy fordítói optimalizálással kapcsolatban. A fordító ugyanazokat a (látószögű) részeit kombinálja egy kódprogramba egy alprogramba, és megzavarhatja a funkció logikáját. Ennek megakadályozásához vagy letiltja a funkció optimalizálását, vagy letiltja a hívások közötti optimalizálást egy függvényhez vagy fájlhoz. Ennek módja a fordítótól függ. Rendszerint erre vannak bizonyos kulcsok és pragmas.
Az EEPROM-ban az adatok tárolásának megbízhatóságának javításának egyik legegyszerűbb módja a többségi foglalás módja. A módszer lényege abban áll, hogy az adatok tárolására páratlan számú memóriacellát hozzárendelnek, az adatok mentésekor a rekord minden kiválasztott cellához kerül. Az olvasás során - mindet elolvassák, de a tartalomra vonatkozó döntést az egyenlőség (N + 1) / 2 sejtek alapján fogadják el.
Tekintsünk egy példát egy adatbájt háromszoros többségi fenntartására. Bájt tárolásához három bájt EEPROM-ot használnak, és a tartalom döntése a 2 bájt egyenlőségén alapul. A kód az IAR AVR fordítóhoz tartozik.
Egy másik módszer a tárolt adatok megbízhatóságának növelésére az ellenőrző összegek, például a CRC használata. Nem alkalmaztam ezt a módszert a gyakorlatomban, ezért nem tudok sokat mondani róla.
1. Így írtam róla.
2. Megpróbálom hozzáadni később. És __root is.
3. Nem hallottam ilyen finomságokról.
1. Igen, tényleg írt. Che-t hiányzott))
3. Még mindig ellentmondásos és filozófiai szempont. Egyes guruk azt mondják, hogy az EEPROM megegyezik a vakuval. Vagyis oldalakon vannak írva, csak az EPROM vezérlője rejti elénk. És hogy a 100000 maximális újraírási szám fogalma nem minden egyes bájtra vonatkozik, hanem az oldalra. Ezen a témán az AVR fénykorában sok vita volt, de ez nem volt a lényeg.
Az Atmelovskaya apronata (AVR101: High Endurance EEPROM Storage) azt állítja, hogy körkörös puffer használatával növelhető az eeprom erőforrás. Az oldalról nincs semmi mondás. Miért nem hisznek?
Ui Az xmega eepromban valóban oldalak szervezik.
Idézet:
A lényeg az, hogy akkor a majorizációnak csak akkor van értelme, ha a majorizált sejtek egymástól távol állnak egymástól, nyilvánvalóan különböző "oldalakon".
A fő ötlet nem az erőforrás mentése, hanem a változó értékének garantálása (vagy annak jelzése, hogy változás történt a hibában).
Idézet:
Kétséges cselekvés. Igen, és az eeprom a BOD-e-val és a helyes sémával nem repül (mint a gyakorlat mutatja).
2. Nunu)) "Nincs semmi az oldalról, miért nem hisznek?" Ez az Atmelovsky stílus. Én például - nem hiszek. Mert itt veszünk övék azonos adatlap a Megu 644 (doc8272.pdf), és könnyen megtalálni a kifejezésre szakaszban 27.7.5 programozása EEPROM: „Az EEPROM szervezik oldalain, lásd 27-8 oldalon 301”. És közel lemez: ATmega644A / ATme ga644PA EEPROM mérete: 2KBytes, EEPROMpagesize 8 bájt.
Tehát nem annyira egyszerű :)
Tovább.
I: "Az a lényeg, hogy akkor a majorizációnak csak akkor van értelme, ha a majorizált sejtek" messze "vannak egymástól, természetesen különböző" oldalakon ".
---
Ön: "A majorizálás jelentése nem az erőforrás megmentése, hanem annak biztosítása, hogy biztosítsa a helyreállítását"
.
És arról beszélek, hogy a majorizáció egy erőforrást takarít meg? Igde?)) Úgy értem, hogy az önértékelés nem függ az EEPROM PAGE állóképességétől.
Tovább.
Önnek. "Kétséges cselekvés: Igen, és az eeprom a BOD-e-vel és a helyes sémával nem legyek (mint a gyakorlat mutatja).
Ismét nincs ott! Mit rohan az étel? Az EEPROM oldalának tartósságáról szól a sejtek korrupciója! Helyes vezetékezés és kitartás HOGYAN kapcsolódik? A BOD'om is - hogyan?
Ön nyilvánvalóan sok "felfedezéssel" rendelkezik))
Véleményem szerint ez még mindig paranoia. Ha egy változót tölt egy oldalon, az EEPROM kapacitása egyszerűen nagyságrendekkel csökken. A 27. részben pedig a programozásról és az EEPROM-ról beszélünk kívülről. Ki akadályozza meg őket a külső programozás, oldalanként és belső byte-byte használatával.
"Írja be, hogy minden byte felülírható, és ilyen ciklusok - 100K".
Ez a te találgatásod. Ott nincs írva.
Ha elfogadod az igazat, akkor az igazi erőforrás eeprom 100K / 8, azaz 12.5K. Programjaimban nincsenek megtakarítva a tárolt adatok különböző oldalakon. És vannak olyan adatok is, amelyek egy oldalon találhatók és gyakran újra írhatók (persze, mivel az erőforrás 100 KB ciklus per bájt).
Úgy gondolom, hogy 10 évig, amikor az AVR-mel dolgozom, több mint egy évvel az EEPROM elutasításával kellett volna szembenéznem a 12K erőforrással. De nem, ez nem így van.
Mert - nem hiszem. Hacsak nem támogatott, írj egy kérelmet. de lustán írni a polgárokról.
Tsytata magától:
Itt van, amit a datashitban:
Msgstr "Az EEPROM oldalakon van rendezve".
Mi még nem világos? ))
Nem "rögzített", nem "programozott" - és eredetileg "Szervezett", mint egy oldal!
Elhiszni, hogy nem hisz a lelkiismereti szabadság kérdése.
Számomra - ha a helyzetnek több értelmezése van - alkalmazzák a legszigorúbbakat.
Jó, hogy ez összhangban van a bennfentesek véleményével - közvetlenül az Atmel-tól))
- Továbbá sok fejlesztő azt javasolja, hogy ne használják a 0th cell EEPROM `a-t, mert a tartalom a leggyakrabban sérült, amikor a mikrokontroller tápellátása csökken.
Nem volt rá, de nem használok mikrokontrollert a munkához, szóval ez nem mutató. Az ilyen ajánlásokat sok fórumon hallottam.