Sziasztok!

Végignéztem a fórum témákat, és nem találtam olyat ami kifejezetten a nagyméretű és gyors memóriákkal, az SD-RAM - okkal foglalkozna.
Úgy érzem, nem csak engemet érdekel a téma, ezért úgy döntöttem, nyitok egyet.
Biztos vagyok benne hogy a témával kapcsolatban guglival is értékes infókat lehet szerezni(ahogy az összes többinél),
de úgy érzem, másokat is érdekel, és ha megosztjuk egymás tapasztalatait akkor gyorsabban lehet pontosabb infókhoz jutni.

Az alapprobléma:
VGA illesztőt szeretnék AVR mikrokontrollerrel megvalósítani.
A monitor meghajtása, szinkron-és színjelek előállítása nem probléma, nem is erről szól a téma.
A kisebb AVR-ek szűkre szabott SRAM memóriája miatt még a 80x25-ös karakteres képernyő megjelenítése is problémát okoz, hát még egy grafikus...

Találtam egy oldalt ahol valaki egy SD-RAM csipet tett a rendszerébe, és azt címezgeti folyamatosan az AVR:
Bővebben: Link
Ez úgy működik, hogy a sötét időben(hsyn, vsyn) az AVR beleírja a memória megfelelő rekeszeibe a karakter grafikus kódját, majd amikor rajzolásra kerül sor, az AVR sorban végigpásztázza a memóriamodult.

Az elgondolás jó, mert az SD-RAM-ok ára a béka s*gge alatt van, gyorsak és nagy méretűek lehetnek.
Egy 128MB-os, egyoldalas SD-RAM egyetlen csipje 8 bites adatbusszal rendelkezik, kapacitása 16 megabájt, emiatt a címszélessége 24 bit.

Ami nehézséget okoz:
- az SD-RAM csipek felületszereltek, kicsi a lábtávolság, ráadásul nehéz sérülésmentesen leforrasztani a panelről.
- mivel DRAM, frissíteni is kell
- késleltetése van: CLK2, CLK2.5, CLK3
- egztikusan hangzó(de valamiért ismerős) vezérlőjelei is vannak, : /CKE, /RAS, /CAS, BA0, BA1, stb...

Elvileg a frissítéssel nincs nagy para, mert a kontroller olyankor frissítheti amikor épp nem kell a memóriát használni.
Az alacsony órajel(max 25MHz) miatt a késleltetés is minimális lehet, egyetlen órajelnyi késleltetés nem a világ.
Ha a késleltetést vezérelni is lehet, akkor mindig tudjuk, mikor kerül ki értékes adat az adatbuszra.
A felületszerelt százlábú problémáját úgy küszöbölném ki, hogy nem egy csipet, hanem egy egész modult hajtanék meg.
A modul adatbusza 64 bit, aminél nem lehet probéma ha csak 8-at vagy még kevesebbet használunk...
A címbuszon sem probléma ha nem használjuk mind a 32 bitet, a nem használt címlábakat földre kell kötni.

Manapság, amikor az AVR-ek is előszeretettel jönnek nagy lábsűrűségű tokozásban, furcsa az a mondatod, hogy az SD-RAM IC-k nehezen forraszthatóak . Egy normális hőlégfúvóval gond nélkül letermelhetőek és felrakhatóak, bár ezutóbbi wellerrel is elkövethető egyszerűen, némi gyakorlással. A vezérlőjelek sem túl vészesek: Sor/oszlopcím jelenlétét jelzik (Row Address select, Column address select), illetve a több bankos szervezésnél az egyes bankokat jelölik ki, valamint engedélyezés a komplett áramkörre. A frissítés az, ami bonyolultabb lesz,a címdekódolás egy egyszerű történet. De erről és az SD működéséről a wikiben szerintem bőséges infót találhatsz.

Való igaz, viszont nem mindenkinek van "normális hőlégfúvója", és én valami ritkább lábsűrűségű AVR csodával(ha nem is DIP-essel) kívánom megoldani...

Ezért hoztam be, hogy egy egész modult kéne meghajtani, mert ott már adott egy szabványos felület.
Míg a különböző modulokon helyet foglalő csipek különböző kiosztásúak is lehetnek, és nem mindegyikről van megfelelő leírás.

Nincs ott sem szabványosabb meghajtás, mintha egyedi IC-kkel dolgoznál. Nem tudom, mekkora kapacitásra lenne szükséged, de sok, régi S3-as VGA-n van egészen nagy lábközű, meg foglalatos modul, azokkal könnyebben boldogulsz.

Szia!

Ha már azt tervezed, hogy a megjelenítőt magad építed fel, akkor a V-RAM -okat ajánlom a figyelmedbe. A Video RAM-ban nem csak dinamikus ram van, hanem egy gyors léptető regiszter is, amit a dinamikus ram egy lapjával egyszerre lehet feltölteni.

Bár nem SD-RAM, végülis a problémát megoldhatja.
Ha jól értelmezem, ez 256K x 4 bit, azaz 128 kilobájtos?
Ez esetben csak akkor elegendő egyetlen csip ha 16 színt használok és a 640x350-es (EGA) felbontást.
Mivel olcsó, 4 darab beszerzésével 256 szín és 800x600 is megengedhető, max a 4 bites adategységek összeszinkronizálása lesz ügyes dolog.
800x600-nál a fennmaradó több mint 43 kilobájt jó lesz a karakterek(80x25-nél 2k), esetleg fontok(32x32 pixel és 256 karakter: 32K) tárolására.
A léptető regiszter az még jól jöhet valamire...

Nagyobb, akár több megabájtos adattárolásra már húzós lenne az illesztés.
Mindenesetre a topikot szeretném ha nem zárnánk le fél nap után, szerintem jó téma lehet a későbbiekben is, és idővel másokat is érdekelhet a dolog.

Nyárra tervezek egy SD-RAM projektet beilleszteni a naptáramba, már csak alkalmazást kell kitalálnom, milyen egyszerű dologra kellhet legalább 4MB memória...

Közben kezdem kapizsgálni.
Tulajdonképpen ez a VRAM is egy DRAM akar lenni?

Első ránézésre megrökönyödtem hogy miért 9 címbit van, mikor 256K szónál 18 kellene.
Aztán magamtól rájöttem: ott van ugye a RAS és CAS bemenet, amelyek állásától függ hogy sor vagy oszlop címet adunk neki.
Illetve a késleltetésre is rájöttem. A CAS latency(legalábbis olvasásnál) ugye azt jelenti,
hogy ennyi idő után számíthatok valid adatra az adatbuszon, miután kiadtam az oszlop címet?
A RAS latency ugyanez, csak sorcímre érvényes, és ez általában jóval nagyobb(adatlap szerint kb. 4-szeres) mint a CAS latency.

Videokimenet esetében, ha van elég cím egy sorban, akkor elegendő a CAS-al számolni?
Megnéztem az adatlapot is, ott 50ns alatti hozzáférési idők vannak. Ha a CAS-t hozzáveszem akkorm mondjuk 100ns-nak veszem a teljes késleltetést a cím kiadás és kiolvasás között. Ez egy 20MHz-es kontrollernél 2 órajelnyi idő.
Valahogy így kell számolni a VRAM-okkal?

Még ír egy olyat az adatlap: 8 ms frissítési periódus. Ezt soronként kell megcsinálni?
Ez kicsit bajos lehet, mert ha a képernyőt 60Hz-en frissítem és monitor egy sorába a DRAM egy sorát teszem ki és utána frissítem, akkor 16.6ms lesz...
Vagy a sötét résznél(a sor rajzolás után) frissítek egy másik sort is, így egy kép kirajzolása közben a memóriában ugyanaz a sor 2-szer frissül.

Gondolom SD-RAM memóriáknál is ilyen problémák jönnek elő...

Szia!

- Dram: Egy memória cella mátrix, aminek van sor- (Row address) és oszlopcíme (Column address). Egy adat eléréséhez szükséges címet, a kivezetések számának csökkentése miatt, két részletben kell megadni. Először a Raw address-t kell beállítani, érvényesíteni a RAS lefutó élével, aztán a Column address-t kell beállítani, majd érvényesíteni a CAS jel lefutásával. A Raw address egy lapot választ ki, a Column address a lapról egy adatot. A lap kiválasztása egy frissítései ciklust is indít, innen jön az eltérő latency idő... A kimeneten normál dram olvasása esetén az adat csak a CAS alacsony ideje alatt jelenik meg, íráskor a CAS lefutó éle vesz mintát az adatból.
- Fast Page Mode Ram megengedi, hogy egy kiválasztott lapról több adatot olvassunk ki, ekkor csak az oszlop címeket kell beadni, és érvényesíteni a CAS jell lefutásával, a RAS jelet alacsony szinten kell tartani.
- EDO ram -nál a kimeneten egy regiszter is van, amibe az olvasott adat bekerül, és a regiszter kimenete külön jellel engedélyezhető.

- Frissítés: Egy lap frissíthető úgy, hogy csak a Raw address-t adjuk meg. Ekkor a lapon levő összes adat frissül. Vannak olyan dram-ok, amiben a frissítási számláló is helyet kapott és a CAS before RAS módszerrel nem kell kívülről címet beadni.
- Frissítési idő: A megadott idő alatt az össze lapot frissíteni kell. pl.: 8ms alatt mind az 512 lapot. Ha jól alakítod a címzést, a kép megrajzolásához szükséges olvasás a frissítést is megoldja...

- V ram: Annyiban különbözik a Dram -tól, hogy egy lappal megcímezhető adatmennyiség a tokon belül átírható egy léptető regiszterbe, ami lényegesen nagyobb órajellel léptethető (33MHz). A belső léptető regiszterbe a képernyő egy (rész)sorának adatait beleírva, a (rész)sor rajzolásához nem kell több memória ciklus, viszont a frissítésről külön kell gondoskodni. A belinkelt típusban 512 fokozatú 4 bit széles léptető regiszter van.

4 bit/pixel, <512 pixel/sor, <512 sor... Ez pont a TMS44C251 -re van kitalálva...
Egy sor adata egyszerre átmásolható a shit regiszterbe, onnan kiéptethető a gyors színtáblázatra (RAM-DAC), onnan mehet az R, G, B kimenetre. A mikrokontroller felé a normál adat ki/bemenetekkel lehet kommunikálni. A kioltás alatt soronként egyszer egy transfer ciklust kell csinálni, hogy a sor adata a shift regiszterbe kerüljön át. A sor fennmaradó idejében a kontroller módosíthatja a memória tartalmát. Még annyi kell, hogy a vízszintes kioltás a shift regiszter léptető órajelét kapuzza...
A kioltás megszakítást kérhet a kontrollertől, az feltölti a következő sor adatával a léptető regisztert. A sor ideje alatt végre kell hajtani még egy - két más lapra vonatkozó frissítást is..
A felhasznált vram tokok számát az alkalmazott RAM-DAC áramkörhöz lehet igazítani...>>

A doksit olvasva az 512 szavas SRAM-ot nem értettem, szóval ez lenne a léptetőregiszter.
Gondolom átíráskor egy egész lap átmásolódik ebbe a léptetőregiszterbe(vagy a regiszterből egy lapra), és a léptetőregiszter az átírást leszámítva független a DRAM többi részétől(RAS/CAS címzés, DRAM írás/olvasás).

Az SC - Serial Clock gondolom egy egész szót léptet, és az órajele különbözhet a kontrollerétől.
Ha mindent jól értelmezek, egy ilyen olcsó VRAM mellett a kontrollernek nem kell a rajzolással bejlódnia, és ezek lennének a feladatai:
- monitor szinkronjelek kiadása
- DRAM feltöltése a pixelinformációkkal(rajzolás)
- minden sor elején átírni a soron következő lapot a léptetőregiszterbe
- ha túl ritkán váltok lapot akkor a sor elején több lapot is frissíteni kell 1-1 lapváltással
- a rajzolás kezdetén engedélyezi, a végén tiltja a shift regiszter (külső generátorral előállított) órajelét.

Kár, hogy nem a VGA vezérlős topikban írtad le, akkor tuti el lehetne fogadni megoldásnak.

Látom közben megválaszoltad.
Úgy néz ki, hamarosan gyártani fogom a 16 színt és 800x600 pixelt kezelő VGA illesztőmet...

Létezik-e hasonló árkategóriában olyan VRAM, ami egy lapon 1024 szót tud? Az se hátrány ha Magyarországon meg tudom venni...

A 4 bit szószélesség tökéletes lesz 16 szín előállítására(mint az EGA esetében),
de az 512 szó a 640x480 vagy 800x600 felbontásnál már kevésnek bizonyul.
A képernyő közepén egy lap átírása a léptetőregiszterbe nem túl kellemes,
ahogy egy másik VRAM csipre való átkapcsolás sem...

én inkább edo rammal próbálkoznék első körben! az sd már szinkronizált és van olyan nyavalya is, mint pipelining, amit persze nem muszáj használni ha jól tévedek.
én épp most vadásztam egy 1MB-os EDO modult. 30 pines SIMM memória, le se szedem az ic-ket, simán ráforrasztok. címbuszra shift regiszter, azt meg az avr spi portjára. elvileg menni fog, de tuti elmegy vele pár nap majd

Az EDO-ból az 1MB modul elég kicsi, a legkisebb amivel találkoztam az 4MB volt, a legnagyobb 32MB.

Azt hiszem, neked FP-RAM - od van, ez az EDO előtti 30 pines modul. Kb. ilyen:
Bővebben: Link

Az EDO 32 bites, az FP-RAM 8. Ezért van az, hogy egy 486-os gépbe elég egyetlen EDO, de egy Pentiumhoz már párosával kell a 64 bites(külső) adatbusz miatt.
Ugyanúgy, egy 386/486 gépbe annak idején négyesével pakolgattam be az FP-RAM-okat.
A legkisebb 256KB, a legnagyobb 4MB ami volt nálam, és még hever otthon egy teásdobozzal...

akkor nem edo, valami ősi cuccból guberáltam. egyébként annak idejénről én is 72 pines edo-ra emlékeztem.
de találtam adatlapot hozzá, miszerint a chip 1M szót tárol, egy szó pedig 4bit.
jó móka lesz ez.

Úgy emlékszem, ezek a modulok 8 bites szószélességgel rendelkeznek.
Ha a tiéden 8 csip van, akkor nem lehet 4 bites szószélességű egy modul, legfeljebb 1.
Az 1M darab szó stimmel, 8 csippel pont 1 megás lesz, és ez a legelterjedtebb.

A használatot hogy képzelted el? Van arról vmi leírásod?

hát, itt akadtam el én is. de ezen 3db chip van, ebből az egyik úgy fest, csak paritást számol. (?) ahhoz nem találtam adatlapot.
a pontos működés még nekem is homály, wikiről próbálok okosodni.
/ras elé simán tehető egy gyors shift regiszter, spi-ról meghajtani is egyszerű.

Szia!

Sajnos ezeket a video ramokat nem lehet felfűzni, mint a shift regisztereket, nagyobb kapacitásúról még adatlapot sem találtam hirtelenjében...
Egy ötlet azért még maradt: 2*(2 db TMS44C251) jár párhuzamosan, az egyik ram-ban a páros, a másikban a páratlan oszlopban levő pontokat tároljuk. A soros kimenetet a képpont frekvenciával multiplexáljuk, a léptetést a felével végezzük, a kép felénél átmegyünk a másik párosra...
A másik megoldás, hogy hagyományosabb dram-ot használsz fel, de ebben az esetben a memória kiolvasása kötött időzítéssel kell menjen: a soridő aktív része alatt a felbontásban szereplő számú memória ciklust meg kell tudni csinálni. Elég nagy kihívás egy mikrokontrollernek, a kioltás alatt lehet csak a módosításokat elvégezni.
A sebességi követelményeken úgy lehet segíteni, hogy egy ciklussal több pont adatát olvassuk ki és tároljuk egy-egy regiszterben, a regiszterek kimenetét multiplexáljuk a pont kirajzolási sebességével. A pc-s világból 8 (9) illetve 32 (36) bites modulok maradtak meg. A 8 bitessel egyszerre 2, a 32 bitessel 4 pont adatát lehet egyszerre kiolvasni.

Ha sikerülne egy pont kirajzolása alatt 2 memőri ciklust is elvégezni, akkor az első kiszolgálja a megjelenítést, a második a módosítást..

Először is elnézést kérek hogy bele wau csak olvasgatom ezt a vezérlős időzítős RAM-os dolgot és felmerült bennem, hogy nem lenne-e egyszerűbb egy PCI-ós S3 virge 64 vezérlése? Azon ott a GPU ami elvégez minden feladatott....

Egy SPI portos FRAM, vagy SRAM lassú lenne? Most nincs kedvem utánnaszámolni, de kapható 16 megás SPI busszal is, és az AVR-ek is tudnak 8 megát (úgy emlékszem). Ráadásul címezgetni sem kellene, csak beletolni az adatot...

Hello!

Az SPI buszos RAM nagyon lassú lenne, az SRAM meg irtó drága a méretéhez képest.
Címezni meg minden memóriát kell, ennyi erővel egy kondenzátorba is tolhatod az adatot...

Most elvonatkoztatnék a kívánt alkalmazástól(VGA), és arra koncentrálok hogy minél nagyobb, gyorsabb, olcsóbb memóriát tudjak kezelni, pl. SD-RAM - ot.

Hello!

Minden hozzászólásnak örülök, egyébként az általad leírt megoldás életképtelen.
Bár SD-RAM-okról van szó, azért leírom mi a probléma VGA ilyen módon történő vezérlésével:

Gondolom tisztában vagy azzal a fogalommal hogy PCI Plug&Play, és a PCI 33Mhz-es frekvenciájával is.
Ez a kettő dolog miatt egy PCI videokártya nem csatolható egyszerűen semmilyen mikrokontrollerhez.

A neten kizárólag ISA videókártyás megoldásokat találni.
Hátránya, hogy nem mindegy milyen típust dugsz bele, működő példányokat nem tudsz kereskedelmi mennyiségben beszerezni, különösképpen a megjelölt típusokból nem.
Lényegében küzdened kell azért hogy egy használható példányt kezedbe végy.

Ahány videókártya, annyi féle programozás.
A hordozhatóság érdekében BIOS is van a kártyákon, általában 32kB EEPROM-ba égetve.
Ez az EEPROM hordozza a kártyaspecifikus rutinokat, mint pl. a képernyőmód beállítások, elektronsugárvezérlő regiszterek programozása, szabvány VGA és VESA módok, metaadatok, stb.
Természetesen ez x86-os kód, és esélyed sincs mikrokontrollerre olyan programot írni ami bekapcsoláskor kikeresi a BIOS-ból a megfelelő kódrészt és lefordítja a kontroller nyelvére.

Ez úgy működik hogy elindítanak egy PC-t a videókártyával, beolvassák az "int 10h"-hoz tartozó memóriacímről a VGA beállító szubrutint(kb. 2kbyte), visszafejtik a bináris kódot x86-ra, ugrások esetén újabb részeket olvasnak be.
Ehhez persze ismerni kell nemcsak az x86 utasításkészletet hanem a regiszterek(ax,bx,cx, ES : DI) viselkedését az int10h környezetében, ugyanis ezekkel történik a paraméterek átadása, nem a stack-en!
Gondolom érezhető hogy ez nem kis feladat egyetlen videókártyával sem. És ekkor még csak egyetlen videókártyatípust tudsz kezelni...

Úgy értem page read-nél csak egyszer kell címezni, aztán "tolni a képébe a 0x00"-kat, és jönne az adat, egy sor egy lap, meg gyors kód... szerintem így kb 27*8*Tclk idő lenne egy sor olvasása. 8 megával az kb 27 uS, ez alatt pásztáz a képernyő... 7-et vagy 8-at ami 228 uS.

Mondjuk nekem az AVR-VGA párosítástól is égnekállt a hajam, mi ezt FPGA-val csináltuk, gyanítom hogy van valami külső icd, és azzal trükközöl.

Ha meg külső sd-ram-ot szeretnél illeszteni, akkor nem értem miért az AVR-hez ragaszkodsz. millió architechtúra van ami hardverből támogatja ezt, kezdve a 8051-től a DSP-kig, de akár AVR32 is. Ez nem arra való, lassú lesz.
Persze ha jutsz valamire osszd meg, mert érdekes.

Nem használok semmilyen külső ICD-t meg huncutságot.
Nemrég készítettem egy órát, ami VGA monitorra rajzol 800x600@60 felbontáson.
A szinkronjeleket és a színjeleket is ugyanaz az ATMega48 állította elő.
Ezen kívül 4 darab nyomógombot is kezel, és terveztem rá RS-232 kommunikációt is ami nem készült el teljesen.

Itt a baj a sebességgel és a memória mérettel volt:
Az 512KB memóriába még egy 80x25 karakteres képernyő karakteradatai sem férnek el(hát még a színadatok!), de a 256 karakter bittérképe a 4KB programmemória felében már elfér.
A sebességre is bőven volt panasz, 2x4 pixelidő kell egy bit kiküldéséhez mert 20MHz-en jár a kontroller, míg a pixelórajel 40MHz.

Ezért (is) akarok egy SD-RAM kezelést megvalósítani, függetlenül a felhasználási területtől.
Az SD-RAM kezelése más alkalmazásokhoz, mások számára is használható, ezért döntöttem a topik megnyitása mellett.

Elnézést, az "IC" szeretett volna lenni.
Ha jól sejtem innen származik az ötlet, van ott kód is.
Amúgy használsz turpisságot, egy atmega48 max működési sebessége 16Mhz, te meg overclockoltad. De valóban alábecsültem az az atmegák képességeit.
Javaslom, ha karakteres üzemmódban szeretnéd használni, akkor a karakterek térképét a programmemóriába pakold, az gyorsan olvasható lpm-el. Oké, nincs ennyi memória benne, de ha lespórolod a fél asci-t vagy veszel egy atmega88-at akkor az meg van oldva. A kiírandó szöveget ha egy multimaszteres I2C buszra pakolt memóriában tárolod, akkor azt lehet kívülről is írni, meg annak nem kell olyan gyorsnak lennie. Ezzel a karakteres mód megoldható. Az SD-RAM-ra meg kigondolok holnap valamit. Mondjuk eléggé portlábtemető, de ígéretesnek tűnik.

Pont azt ecseteltem, hogy a karakterek grafikus kódja belefér 2KB memóriába!
Az ASCII karakterek 8x8 méretűek, azaz 8 bájton tárolható a kódjuk.
256 karakter esetében ez 2048 bájt lesz, erre elegendő az ATMega48, nem kell hozzá külső memória.
A kontroller max frekvenciája 20MHz, overclockról csak 25MHz-nél beszélhetünk, amin természetesen ugyanúgy működik.

Külsó memória legfeljebb ahhoz kell, hogy a karakterek 1 bájtos kódjait egy 80x25 táblába bele tudjam szervezni. Ez 2000 bájtot jelent, ami nem írható a flash-re, mert futásidőben változik.

A legnagyobb baj a kontroller sebességével van: egyetlen pixel kirajzolásához legjobb esetben is minimum 3 órajel kell. Ebből kettőt levesz az SRAM-ból történő olvasás és egyet a kiíratás. Igaz, csak 8 bitenként kell kiolvasni, a többinél elég shiftelni.
A dolog további hártánya, hogy a processzoridő tetemes részét lefoglalja a rajzolás, a rajzoláson kívüli időben a pixelkódok kikeresése a táblázatból és a rajzoló pufferbe való beillesztése. Eközben kommunikálni is kéne.
Ha kis felbontást és frissítési frekvenciát használunk, a kontroller akkor is legfeljebb a pixel órajelen tud menni, a legkisebb előforduló pixelórajel 25MHz. Ha a 20MHz-ről járó kontroller 40MHz-es pixelidejű felbontást kezel akkor élből feleződik a felbontás.

Eddig még mindig karakteres képernyőről beszéltünk, holott nekem grafikus kell, pixelenként kezelhető.
A topik legelején írtam egy linket, ami nem közvetlenül, de végső soron ugyanarra a készülékre mutat.
Onnan származik az igény és ötlet, hogy SD-RAM-ot szeretnék AVR kontrollerekhez igazítani.

SD-RAM vagy egy elég nagy szószélességű memória esetében megoldható, hogy egy teljes szót shiftregiszterekbe töltünk, amit pixelórajelen járatunk.
Egy SD-RAM modul 64 bit széles, fekete-fehér képnél 64 órajelenként kell a shiftregisztert feltölteni. Ez bőven elegendő külső parancsok fogadására és a memória pixelekkel való feltöltésére.

A részleteket, hogy hogy gondolom az egész VGA dolgot inkább nem írom le mert a topikot SD-RAM kezelésre nyitottam, és amíg ezt tárgyaljuk azalatt elvész a lényeg...

Sziasztok!
Engem is érdekelne az SD ramok kezelése, hogy menniy ideig tartja az adatot frissítés nélkül, hogy zajlik a frissítés, mennyire komplikált a használata? Mivel MP3 lejátszót fejlesztek, gondoltam sokkal előnyösebb ha van benne dinamikus ram. Nézegettem az adatlapokat de van benne olyan dolog ami számomra még idegen, pl.: CAS before RAS frissítés..

Igazából a legrégebbi DRAM-ok is igényelnek frissítést, pár hozzászólással előtted leírták. Majdnem a legelején.
Hamarosan elkezdek DRAM-okkal is foglalkozni, és amint eredményt érek el, megpróbálkozom az SD-RAM modulokkal.

Az XMEGA-k alapból kezelik az SDRAM-ot, és még a frissítést is elvégzik autómatikusan. Az egyetlen gond, hogy csak 4-bites módban használható, és a címtartomány is eléggé szűkos.
Én is sokat gondolkodtam az SDRAM alkalmazásán egy LCD-s megjelenítő kapcsán, de inkább az SRAM mellett döntöttem. Az 512kB-os méretűek még megfizethetők.
SDRAM-ot - szerintem - csak AVR32-vel érdemes használni. Esetleg még szóba jöhet egy külső illesztő (pl. PLD-vel), amivel az MCU normál módban (nem multiplexelt címbuszon) tud kommunikálni, és a frissítést is lekezeli maga. (Bár így is macerás...)

Sziasztok!

Minden olvasás - írás frissíti azt a lapot amiről az olvasás - amire az írás történik. A lap címet a RAS jel lefutása érvényesíti - tárolja a memóriában levő lap cím tárolóba. A frissítés annyit jelent, hogy egy olvasást hajtunk végre egy lapra, de a kiolvasott adadt nem kell... Kénytelenek vagyunk a felejtés elkerülése miatt...

A frissítés kétféle módon hajtható végre:
- Beírunk egy sorcímet a RAS jellel - Minden típusnál használható. A cím számlálásáról a külső egységnek kell gondoskodnia.
- Hidden refresh: Ha a kimenő adatot a CAS jel alacsony szintjénél elegendő ideig kell tartani, a RAS jelle kezdeményezhető egy frissítési ciklus.
- A CAS before RAS módra képes memóriákban benne van a frissítési cím számláló. Ha a RAS lefutó élénél hamarabb fut le a CAS, akkor nem a címvezetékről veszi a frissítési címet, hanem a belső számlálról.

Az adatlapon úgy találod meg a maximális tárolási időt, hogy mekkora idő alatt kell az összes lapot frissíteni: 4mS / 256 lap - 8ms / 512 lap 16ms / 1024 lap....
Ez azt jelenti, hogy minen lapról olvasni vagy frissíteni kell ennyi idő alatt. Tehát kb. 15 - 16us -onként kell olvasni / frissíteni egy lapot.