Ehhez nem kell feltúrni az adatlapot, az MCU honlapján is ott áll. hogy "full speed", azaz 12 megabit/s. Bővebben: Link De eddig nem mondtad, hogy neked a High-speed mód is kell.

Bocsi. Én a 2.0 alatt a 480-at értettem. Mea culpa

A cimmel kapcsolatban: HCSD kartyanal a blokk szamat kell megadni, nem HCSD kartyanal pedig a byte cimet. Annak viszont a blokkmerettel oszthatonak kell lennie. (asszem) Tehat, ha 512 byte-os blokkokat hasznalsz, akkor 512-vel oszthato kell legyen.

A FIFO-rol nem tudok semmit. En eleve DMA-val hasznaltam az MCI-t, es ugy mukodott is rendesen. Kiveve, hogy amikor az MCI interrupt bejott, hogy kesz a muvelet, akkor meg a memoriaban nem volt bent az egesz olvasott blokk, mert a DMA meg szüttyögött vele, igy kulon meg kellett varnom a DMA befejezodeset is.

A CMD17-re ugyanugy valaszol a kartya, mint a tobbi parancsra, csak utana elkezdi ontani az adatot, ha nem volt semmi hiba a paranccsal. Kimegy a CMD17, erre a kartya valaszol. Ha hibat jelzett, akkor itt a vege. Ha nem volt hiba, akkor egy ido utan elkezdi kuldeni az adatot. Amikor mind megjott, akkor beolvastad a szektort.

Viszont a kartyanak olvasas vagy iras elott ki kell adni a blokk meretet, amit a cmd16 csinal.
Ezt csak egyszer kell megcsnalni, amikor inicializalod a kartyat.

Okés, akkor most azt is találd ki, hogy hány MHz-es legyen az a CPU minimum. Mert egy 100-200MHz-es Cortexből nem fogsz kihajtani 480Mbps-t.

A CMD17 kiment rendben, a visszajövő válasz 0x0900 volt, tehát nincs hiba. Egy CMD13-al kiderült, hogy a kártya TRAN módban van, szintén jó, a CMD17-re a status bitek azt mutatják hogy minden rendben "COMMAND SENT", "CRC OK", "RESPONSE OK".
Viszont nem jönnek az adatok. A kártya 2Gig. Ha SD_CMD(17, 0x00,0) megy ki akkor az jön vissza hogy hibás cím, ha mondjuk azt kérem tőle hogy SD_CMD(17,0x2000,0), akkor rendben a cím.
Egy idő után a STATUS FLAGek megváltoznak. DATA TIMEOUT ami leginkább szemet szúr, meg hogy RX FIFO EMPTY. Szóval nem jön semmi, ez tuti.
Elkérhetem az SDinit-ed folytatását? Találtam még egy két 4-bit es mód leírását, érdekes a legtöbben azt írják hogy CMD17 után a kártyának még küldeni kellene olyat hogy 0xFFFFFF00, - bár sehol nem magyarázzák el minek, max annyit hogy biztos ami biztos - és hogy utána fognak az adatok csorogni.

Az SDinit folytatasa alatt mit ertesz? Odaadom az egeszet, de AS IS es LPC2378. Elegge multitask, meg van benne sok trukkos dolog, nem lesz elsore egyertelmu. Evekkel ezelott irtam, ma mar biztos maskepp csinalnek ezt-azt. Es van benne olyan is, amit nem egeszen ertek..

Van valami haszna is ennek a tippnek? Kész boardokból vagy van, vagy nincs. Ha nincs, szerintem elfelejtem az egészet. Csak egy kósza gondolat volt, dobok rá búcsúpuszit, és nem szorongatom, hanem könnyű szívvel elengedem, és majd integetek neki egy piros pöttyös zsebkendővel, meg öreg napjaimban azon fogok szomorúan nosztalgiázni, vajon mennyivel lett kevesebb az életem és az egész emberiség boldogsága csak azért, mert most nem találtam ilyen boardot készen? Ez így elég drámai?

Egyébként tippelni valahova 400 mhz-re tippelnék. Egy 32 bites cpu quadruple buffereléssel 400 mhz órajellel szerintem már esélyes tud lenni elbánni 480 mbps adatfolyammal valami elfogadható hatásfokkal. Különben meg szabad a gazda, mi a legalsó létező korlát?

Köszönöm!

Látom ott kezdődik hogy van benne 100ms szünet a CMD17 után 18MHz CLK mellett.

Klasszikus ökölszabály: 1MHz CPU - 1Mbps sávszélesség. A kérdés arra vonatkozott, hogy a 480Mbps-re vágysz, vagy csak szimplán kevés a 12Mbps. 100-200Mbps-t szerintem ki lehet csikarni egy 150-200MHz-es Cortex M3/M4-ből, azokból pedig vannak kívánatos új modellek Ethernettel, HS USB-vel, SDRAM támogatással. Az LPC1850/1857/4350/4357, az STM32F427/429/437/439 pl. mind ilyenek. LPC4357-tel már láttam a neten demo boardokat. A SAM9260-nak is vannak HS USB-t tudó 400MHz-es utódai, azokra is talán érdemes keresgélni: AT91SAM9G25/35/45

Számolgattam kicsit, és valahol 95..98 mbyte / 7 sec a mozgatni való hasznos adat összesen - 115 mbps körüli sebességre jön ki. Nyers adatban még plussz a scsi drive filter keretezése, és az usb alsó réteg overhead. Kicsi szerencsével 200 alatt marad egészében (nem számoltam ki pontosan), de nem sokkal. Akad azért tartalék a 480-hoz képest, de olyan nagyon a cpu-nak sem lesz ideje lazsálni. A típusokat köszönöm, elkezdek körbeleskelődni.

Rosszul latod, mert ha 371-es sorra gondolsz, akkor az csak azt allitja be, hogy az MCI maximum 100ms-ig var a cmd17 utan az adatra. Ez a timeout. Es a komment arra utal, hogy az odairt ertek (1800000) az 18MHz kartya orajel eseten 100ms. Merthogy az idot ennel a regiszternel az eppen beallitott SD kartya orajelekben merve kell megadni. Tehat 18MHz-nel 18 millio az egy masodperc. az 1.8 millio az 1 tized masodperc.

Köszönöm a javítást. Jelenleg Németbe vagyok ipari alpinon, szóval nem fogom tudni kipróbálni a dolgot, viszont azóta is olvasok nagyon sokat. Sehol nem jövök rá hogy CMD17 után miért küldenek még 4byte-ot 0xFFFFFF00-t a kártyának, mondván hogy csak utána jön az adat. Igaz ezt szinte csak SPI-vel olvastam, egy vagy két helyen csinálták 4-bit mode-ra "just for sure". Akárhogy is, de menni fog.

Biztos én vagyok a béna, de usb device-al felszerelt normális development boardot valahogy nem könnyű találni. Menet közben jutott eszembe, hogy talán meg is lehetne fordítani a kérdést. Microchipéknél létezik olyan stack, ami demo project usb scsi drive pic-ekhez. Vannak hasonló libek bármelyik arm proci családhoz, amelyik usb hs device-al van szerelve?

Meg lehet nézni, hogy csinálják a nagyok. Bővebben: Link

Microchipnél tudtommal FSUSB a felső határ, arra SD kártyán kívül mást nemigen érdemes kötni (mármint tömegtároló kategóriában).

MC-éknél valóban az FS a felső korlát, azért is nézelődöm ARM-éknál.

A linket köszönöm, de az természetileg is másik project. Amivel én próbálkozom, annak az a kemény pontja, hogy usb device-ként kell viselkednie az eszköznek, és azon keresztül felkínálni scsi felületet. A linkelt cuccok hostként viselkednek a tényleges adattároló felé, és ftp (vagy nbd) protokollon keresztül kínálják fel a kapacitást etherneten. Ha olyat akarnék csinálni, jó lenne hozzá bármelyik tesco gazdaságos dev board. De nem olyat akarok csinálni.

Üdv!

TFT Frame buffernek használok IS62wv51216 típusú sram-ot.
Az a kérdésem, hogy miért nem tudok ebbe eltárolni 2 db tömböt?


Scatter file:


startup file eleje:


Heapot is használom rendesen, de valamiért nem fér el, már fordításnál hibát jelez.

Kerülő megoldás: kétdimenziós tömb, X=2, Y=76800.

Köszi, de látszólag megoldódott (lefordul) az volt a baj, hogy a linkerben a heapot is áttettem a külső ramba, holott én azt belöl akarom használni.

De jól számolok, hogy elvileg beleférek ebbe a ram-ba?

A ram 512K*16 (8Mbit) tehát 1048576byte, de mivel 16bites, ezért ez feleződik, 524288 word.
Ha jól számolom akkor ebbe pontosan 6 db uint16_t típusú 76800 elemű tömb fér el?

Egesz pontosan 6.826..db 76800 elemu uint16_t tomb fer bele.
Hogy erted azt, hopg "ezert felezodik". Ez 1 megabyte ram, amit hasznalhatsz byte-osan is, 16 bitesen is (mellesleg az ARM vilagban a 16 bit az a half word), vagy akar 32 bitesen, azaz word-osen.

Mert nem tudom, hogy a keil-nek mekkorának állítsam be a ram méretét.
Az fsmc 16bit (half word) kezeli és a ramnak is 16 bites adatvonala van, de az nincs megadva, hogy a ram fizikai méretét, byte-osan kell megadni mintha 8bites lenne, vagy az adatvonalnak megfelelően 16bites ként.

Üdv!

Keil arm fordítóban a log() függvény miért nem jól számol?
Van valami trükkje?

Mit nem szamol jol? Ne haragudj meg, ha ez neked termeszetes, de: log() - e alapu, log2() - kettes alapu, log10() tizes alapu. Zsebszamolon a log a 10-es alapu, es ln az e alapu.

Aza baj, hogy mplab c30- al a log() függvényt használó rutin jól működik.
Áttéve a keil-be nem jól számol és debug-olva a log() függvénynél téved, de nekem számológéppel nem sikerült produkálnom a keil függvénye által produkált eredményt.

Eddig ez jól működött:

Akkor passz. Hat. ha ugyanarra a bemenetre mast ad, mint a zsebszamolo (log(2.71828) = 1), akkor hibas. Mas otletem nincs.

Segítségetek kérném:
Keil jobb oldalán szeretném megjeleníteni az core_cm3.h 296-311 soraiban definiált NVIC nevű regisztert, hogy végre engedélyezzem és ellenőrizzem a 45-ös számú megszakítást az SDCard-ot.
Nos, sokfajta regiszter csoport van, de ezt sehogy sem tudom felvarázsolni a képernyőre, csak külön ablakként, ami nekem most éppen nem megfelelő. Szóval ahogy a képen látszik, az a nem jó. Ott jobb oldalt kellene lennie.
Valaki valami ötlet?

Nekem simán bedokkolja.
Ragadd meg az ablakot és a képernyőn megjelenik egy + jelhez hasonló dokkoló, és amelyik oldalára ráhúzod az ablakot arra a szélre dokkolja az ablakot.

Nem az a gond hogy hol van. Hanem az hogy a regiszterek neve és teljes 32 bites hex értéke nem jelenik meg úgy mint a jobb oldalon.
A gond igazából az hogy engedélyezném LPC1788ban az NVIC rendszer SDCARD megszakítását, és nem tudom hogy melyik ISER regiszterben van a hányadik bit. Ehhez kellene nekem a jobb oldali style.

Nincs logf () ? STM32f4 -re mintha hasznaltam, es mintha CMSIS.

UM10470 75-os oldal.

ISER0 29-es bit. (1<<29)

Az elso 32 megszakitas az ISER0, a kovetkezo 32 az ISER1 regiszterben van. (Bar 1788-on utobbiban csak 9 hasznalt.)

Ha a megszakitas szamabol levonsz 16-ot, akkor megkapod, hogy az NVIC hanyadik megszakitasarol van szo. Az elso 16 megszakitast nem az NVIC kezeli. Igy aztan a 45-16=29 a te bited. Mivel ez < 32, az ISER0 tartalmazza. Ha a 33-dik lenne, akkor az ISER1 1-es bitje lenne.

Köszönöm! Hasonló módszerrel de csak sikerült kisakkozni.
Mondjuk azt még mindig nem tudom miért nem lehet megjeleníteni azt amit szeretnék, úgy ahogy én szeretném, de nov 4-el kijött a Keil5, remélem az képben lesz.