Fórum témák
» Több friss téma |
WinAVR / GCC alapszabályok: 1. Ha ISR-ben használsz globális változót, az legyen "volatile" 2. Soha ne érjen véget a main() függvény 3. UART/USART hibák 99,9% a rossz órajel miatt van 4. Kerüld el a -O0 optimalizációs beállítást minden áron 5. Ha nem jó a _delay időzítése, akkor túllépted a 65ms-et, vagy rossz az optimalizációs beállítás 6. Ha a PORTC-n nem működik valami, kapcsold ki a JTAG-et Bővebben: AVR-libc FAQ
A linkernek a -nostartfiles -t meg kell adni, ekkor nem csinál interrupt táblát. Ezután:
Végül az rjmp is kimaradt, közvetlenül az interrupt táblába írtam a kódot, így összességében 3 órajelet nyertem, most 29 ciklus alatt fut le.
Más interruptot nem akarok úgysem, sőt a cli()-ket is ahol lehetett kigyomláltam.
Az ügyben érdeklődnék az AVR-ekben járatos kollegáktól, hogy van-e valaki, aki már foglalkozott midi jel feldolgozásával ?
Sziasztok!
Régi problémám vettem mivel ismét van egy kevés időm foglalkozni vele. Ez nem más mint az adatrögzítés és adattárolás. A lényeg, hogy percenként szeretnék eltárolni 4 hőmérsékleti értéket az aktuális dátummal és időponttal. Illetve, ha hiba történik valahol akkor ennek a kétjegyű kódját. Nézegettem az EEPROM-okat. 24LC128-I/SN talán jó is lenne. 128k elvileg elég. Ha megtelt akkor elkezdeném mindig felül írni a legrégebbi adatokat. Két gondom van. Egyik, hogy félek lassú lesz a másik, hogy 1.000.000 ciklus vajon meddig lesz elég. Nézegettem az SD kártyás megoldásokat is, de az meg talán fölösleges lenne. Ti hogyan oldjátok meg az adattárolást loggolát? Mit javasoltok?
Ennél egy mezei EEPROM egyszerűbb, gyorsabb, hibatűrőbb, és talán még olcsóbb is.
Egy régi P1-P2-es lapban találsz, akkor ingyen van. Ezeket a bolhán gombokért utánad dobják. Arra ügyelj hogy DIP tokozású legyen, és foglalattal!
Nem egészen értem, hogy hogy mennyi ideig lesz elég?
Azt írod 1 millió írási ciklust tud, percenként akarsz rögzíteni adatot. Azt hiszem minden adott, hogy kiszámold mikor nyuffan ki. Lassú biztos nem lesz semmilyen eeprom erre a feladatra. SD kártya még ennél is hamarabb meghalna szerintem.
Arra nem jöttem rá, hogy hogyan számoljam ezt ki. Egy ciklus alatt hány bit-et ír ki?
Ha mondjuk egy írás alkalmával pl. ezeket szeretném kiírni: 201303110810245305451602 Ez tartalmazza a dátumot, órát és 4 hőmérsékletet egy tizedes pontossággal.
Az eeprom bájtonként írható. Tehát ha az adatlap azt mondja, hogy 1millió írási ciklusa van, akkor minden bájtot 1 milliószor írhatsz meg.
Találd ki, hogy kódolod ezt le : "201303110810245305451602" Nézd meg hány bájtot fog elfoglalni, aztán lehet kalkulálni. A hozzászólás módosítva: Márc 11, 2013
Ha jól sejtem akkor ez pont 3byte lenne?
Viszont, ha az 1M írás minden byte-ra vonatkozik akkor én előbb pusztulok el mint az EEPROM.
Hát, szerintem több lesz 3 bytenál. Viszont jó eséllyel tényleg sokáig elkocog majd az EEPROM.
Újra számolgattam persze megint lehet, hogy tévedek:
Elvileg ez 24 bájt. Ha ezt percenként kiírom 60x naponta 24x akkor kb. 6 nap alatt tellik meg a 128k EEPROM. Ha ez 1M-szer tehetem meg akkor, ha jól számolok ez kb. 450 év.
Fogjuk rá.
Hát, én az évet legrosszabb esetben 1 byte-on tárolnám.
Ha 2013-tól indulsz, akkor először 256 év múlva jelentkezik majd a probléma, de akkor is könnyen kezelhető lesz. De ha azt szeretnéd, hogy az ükunokáid unokáinak is működjön, akkor mondjuk 2 byte-on egyszer(!) letárolod az évet, utána meg valami apró logikát, hogy ne álljon fejre, amikor szilveszteri buli alatt az unoka az öregapja AVR-jével akar részegen felvágni. ))
Ne felejtsd el, hogy azt is le kéne tárolni hogy "hányadik" mezőben van az aktuális érték.
Kis gondolkodással rá lehet jönni hogy ez nagyobb kihívás mint maga a tárolás. Aztán ne feledd hogy amikor elindul a proci, meg kell találnia az aktuális "érvényes" mezőt, azaz szinkronizálni kell. Egy 1 megabites EEPROM esetén ez eltarthat egy darabig... A lehető legegyszerűbb, ha egy mezőt megírsz, majd a következő írása UTÁN kitörlöd. A törléskor olyan adatnak kell bekerülnie amit "üres"-ként tudsz detektálni. Hátránya hogy kétszer jobban használódik, kivéve ha az EEPROM-nál van külön "törlés" utasítás. A másik megoldás az egybites indextábla. A törölt bájtok 0b11111111 értékűek. Ha az EEPROM támogatja, a biteket egyenként lehet beállítani(törölni viszont csak egyszerre). Tehát ha 0b00111111 van az indextáblában akkor tudod hogy a második 3-4 bájtos mezőben vagy. Előnye hogy bekapcsoláskor a szinkronizálás időigénye a töredékére csökken. Megjegyzem hogy ATMega esetében a "törlés" és a "bitenkénti beállítás" is támogatott. A hozzászólás módosítva: Márc 11, 2013
Csak elméleti kérdés, de hátha:
Mindenképpen külső EEPROM-ot. Használnék. Mi lenne, ha egy fix címen tárolnám az utolsó adat címét? Így egy esetleges RESET után tudom, hogy hol kell keresnem azt, hogy hol volt az utolsó sikeres írás. Vagy ez nem járható? [off] Elnézést, de EEPROM-mal még sosem foglalkoztam.
Na ezért említettem hogy ez a rész az igazi kihívás! Mert ha Te egy fix címen tárolod a címet,
akkor ugyanarra a helyre írsz folyamatosan. És az a rész fog leghamarabb elhasználódni...
Erre én is gondoltam. Gyakorlatilag ezt a bizonyos címet állandóan használom. Így biztos, hogy percenként egyszer írok oda. Ami már annyira nem kecsegtető. Alig 2 év lenne az élettartam.
Akkor használok több címet erre a célra vagy tényleg nem tudom még. Esetleg valakinek építő ötlete?
Szerintem googlizz 5 percet egy kész algoritmus után.
Nem kell mindig feltalálni a kereket.
Azt teszem/fogom tenni. Még keresgélem a lehetőségeket. Kicsit idegenkedem az EEPROM-tól, de egyenlőre úgy látom, hogy ennél csak maceránsabb megoldások vannak. SRAM, flash memoria, ds kártya.
Az utóbbi lenne a legszimpatikusabb, de ahogyan látom a feladathoz a legkörülményesebb is. Keresgélek AVR dataloggereket ott mindenhol sd tártyát használnak.
EEPROM Byte illetve Page módban írható.
Ha 1 byte-t változtatsz meg, akkor is a teljes lapot felülírja! A 24LC128-as 64byte lapmérettel dolgozik. Azaz ha beírok az eepromba 0...63-ig, akkor a 0...63 blokkot 64x írtam! Minden egyes cellát! Számolás: 24LC128: 128kbit = 16kbyte = 16384 byte. 16384 / 64 = 256 db page Minden page min 1M írható, így ha 1 adatod 32 byte-ba fér és a secenként írsz, akkor: 2 sec: 1 page. Ebből van 256. Így a körbeírás: 256*2 sec = 512 sec (8.5 perc). Ebből van 0.5M (mert 1 blokk 2 írást jelent). Ez 8.5p (512 sec) * 500.000= 256000000 sec = 71111 óra = 2962 nap = ~8.1 év. A garancia 3 év felett ritkán van
EEPROM Byte alapú írása tökegyszerű...
A Flash, SD-kártya sokkal macerásabb....
Nem is beszélve arról hogy az 1 millió a technológiailag "garantált", és 1 millió írás felett
nem fog felrobbanni az EEPROM hanem működik tovább, csak később egyes bájtok, lapok már nem biztos hogy a beírt értéket fogják visszaadni. Ha 10 évnél tovább tervezel akkor... 1: cseréld az EEPROM-ot 2: tarts fenn egy "bad sector" táblát is, amit nem árt tükrözni. A hozzászólás módosítva: Márc 11, 2013
24lc512 - 4x méret, 2x pageméret.
Így 8 év -> 16 év a növekedés Sőt, 8 db 24LC512 felfűzve, ez 8x lesz Na addigra kukactáp vagyok amire lehal a chip....
Ha gyorsan és "ész nélkül" kell írni, na arra pont az FRAM az ideális.. (SPI)
Kísérletezőknek is jó, mert végtelenszer írható/olvasható, könnyen címezhető(mint az SRAM ugye) gyors(SPI), és nem felejt.. Igaz nem túl olcsó. De ellenben "ész nélkül" írható
"végtelenszer"
Annak is van ám élettartama.
Idézet: „Annak is van ám élettartama.” Az adatlapból idézek : • Unlimited Read/Write Cycles Na most ugye ez magyarra lefordítva: _Végtelen_ olvasási/írási ciklus-t jelent, bár mennyire is zavaró ez. Kb. egy éve készítettem egy áramkört, amiben Ramton FRAM-ot használok, és próbából,(vagy inkább gonosz poénból) a program hasznos funkciói mellé írtam egy olyan részt, hogy kb. 25ms gyakorisággal az első 16 címre változó adatokat írok, majd visszaolvasom és ellenőrzöm. Hiba esetén az áramkörön világít egy led. A fejlesztés óta nem láttam világítani, pedig majdnem egy éve folyamatosan üzemel az áramkör. Egy kis matek házi: Ha ~300 napja üzemel, és 25ms-onként van írva/olvasva, akkor az eddig mennyi ciklus? Lehet kiégett a led??? Szerintem
Aham, én még a TI -s FRAM -os MCU adatlapjára gondoltam, ott azért megneveztek egy meglehetősen óriási nagy számot az írási lehetőségekre.
Én meg nem vagyok gondolat olvasó
|
Bejelentkezés
Hirdetés |