Fórum témák
» Több friss téma |
Találtam 1 részletes adatlapot.
STM32F405xx/07xx, STM32F415xx/17xx, STM32F42xxx and STM32F43xxx adv...t MCUs De az belső LCD vezérlésről itt sem írnak semmit! Esetleg valaki tudna erre doksit? 
Sajnos a DM00071990.pdf-ben is csak említve van pár szó a "Chrom-ART Accelerator™ (DMA2D)" -ról meg hogy tud 2 layert meg color-key-t stb. Szerintem várhatunk még pár hónapot, hogy teljes legyen a leírás, lehet, most szülik.
Nem ismerem a TFT-vezérlőjét, de kizárt, hogy bitenként kellene állítgatni.
Az FSMC is össze-vissza van definiálva a GPIO portokra, mégis egyetlen utasítással kirakhatsz 16 bitet egy regiszter írásával.
Az RM0090-ben (DM00031020.pdf) mar var par szo rola.. 1700 oldal.
Bővebben: Link
Gondolod? A masik is Sep 2013. En nem uj, hanem mas. Ez ugyanis nem adatlap, hanem reference manual. Azt vettem eszre az elmult 1 heten, hogy nem tudok ugy hozzaszolni a HE-n valamihez, hogy az jo legyen. Ha segitek, akkor vagy nem valaszolnak, vagy degradaljak a dolgot.
Én arról beszélek, amit kapu48 szerdán belinkelt. Az ugyanez a doksi volt, csak februári (rev 4) kiadás. Legalábbis szerdán még az volt fenn ugyanezen a címen (tudom, mert megnéztem, és nem is értettem, hogy minek van ott reference manual, ha nincs benne minden perifériája a chipnek).
Szerintem túlreagálod a dolgot...
Jogos a pont. kapu48 linkjet nem vettem eszre, csak a kovetkezo postban levo DM000718890-et. Ezert menetem el az ST oldalara, ahol lattam a datasheet-et, es inkabb letoltottem a ref. manualt.
Nem reagalom tul, csak kicsit feszultebb vagyok az elmult het egyeb tortenesei miatt. A postokkal kapcsolatban meg figyelmetlen voltam. Tenyleg volt par dolog az elmult napokban itt a HE-n, ami elgondolkoztato, es toled meglepett ez az iras. De igy mar tiszta a dolog, nem te vagy a hunyo, bocs.
Egyszeruen az van , hogy vannak akik nagyon korrektek, masok meg az elfogyott sult galambot emlegetik, mert irtak nehany fuggvenyt es azt hiszik, amit; masoknak meg nem szokasa valaszolni.
Sziasztok ! Valaki meg tudna mondani, hogy stm32f4discovery es Keil eseten hogy tudom megnezni az RCC->I2SPR regiszter erteket ? Debug modban nem latszik az erteke. Az ASM-bol meg nehez kihamozni, mert ismerni kellene az rx ertekeit adott esetben.
(Az PLLI2SCFGR erteket ki tudom olvasni, ez a system_akarmi fileban van.) Koszi.
Megoldas: 3 -as szintu optimalizacioval egyes reg.ek ertekeit nem latni, 0 szintu opt.val mar lathato !
Helló mindenkinek!
 Probléma: NXP LPC1788. SDRAM + TFT kijelző. A kijelzőn a fényképkép nem fluktuál ebből arra következtetek, hogy az SDRAM beállítása jó, az adatok benne nem csúsznak szét. A képen viszont hibás függőleges csíkok vannak egyenletesen vagy 10 pixelenként. Tökéletesen függőlegesek. TFT timing hiba lenne? Simi
Sziasztok!
Egy kis problémám van a linux-os arm fordító beállításával. Ezt a hibaüzenetet kapom: "undefined reference to `__aeabi_uidivmod'" A fordító amit használok: gcc-linaro-arm-linux-gnueabi-2012.01-20120125_linux A mikrovezérlő amire szeretnék fordítani: AT91SAM7SE512 Valaki tudna ebben segíteni? Előre is köszönöm! Üdv!
Az már biztos, hogy RGB módban van hajtva az ST429discovery.
Szépen mérhető a DCLK, HSYNC, VSYNC.
Az a TFT egy "standard" kiosztású? Lehetne oda 40-es FFC csatit forrasztani?
48 lába van az LCD-nek, nem tűnik standardnak.
Viszont az összes LCD láb ki van vezetve a tüskesorra, így utólag könnyen ráköthető. És mivel a hozzá adott kijelző csak soros parancs után éled fel (ha jól vettem ki az adatlapjából), így nem is kell vele foglalkozni/leszedni ha külsővel szeretnéd használni. Sőt... azt még hajthatod együtt vele soros kommunikációval, így egyszerre két kijelzővel is operálhatsz.
Ezt azert mondja, mert nem talalja a gcc konyvtarat, amit hozza kell linkelnie a cuccodhoz. Par kerdes: A C fordito linuxon fut, ugye? Es a mikrovezerlon is linux fog futni?
Nekem speciel van a /usr/local/lib/gcc/arm-eabi/4.5.2 konyvtarban egy libgcc.a file, es abban van az emlitett fuggveny. Szoval neked vagy nincs a forditohoz szukseges libgcc.a (meg meg jopar dolog) vagy nem ott keresi a fordito, ahol kell. Valahogy meg lehet kerdezni a compiler-t, hogy hol keresi a libeket, csak nem tudom, hogy hogyan  Utanajarok.
nekem az arm-eabi-gcc -print-search-dirs hatasara kiirja, hogy hol keresi a libeket. Es valoban ott keresi oket, ahol vannak.
Üdv újra!
STM32F407 -el szeretnék kiolvasni eg NAND flash-ból, jelesül K9F1G08UOD-ből, de az első három byte 0xFF majd utána az adatok amiket bele írtam, majd a lap utolsó két byte-ja 0x00. Ez mitől lehet? A mintakód is ezt csinálja, illetve a sajátom is. Természetesen így a beírt adatokból is elvész az utolsó 5 byte.
Megoldódott a probléma:
Érdekes, hogy ilyen fajta megoldást használnak (én nem nagyon szeretem feltartani a procit ilyenekkel) de működik. A másik, hogy nem világos az adatlapból, hogy a hibás blokk kezelést nekem kell megoldani, vagy a flash magától kezeli és én semmit sem veszek észre belőle? Vagy a SpareArea-ba nekem kéne bejegyezgetni, hogy az adott lapon tárolható-e adat? A hozzászólás módosítva: Okt 11, 2013
Idézet: „A másik, hogy nem világos az adatlapból, hogy a hibás blokk kezelést nekem kell megoldani, vagy a flash magától kezeli és én semmit sem veszek észre belőle?” A NAND flash maga általában semmi ilyesmit nem csinál - ezért olcsó a NAND flash. Vagy megcsinálja neked a proci NAND flash kezelője, vagy neked kell ezt is lekódolni. Az STMF4 doksiban a 37.6.6 pont alatt olvashatsz a hardveres ECC támogatásról, ennyi segítséget kapsz, a többit (pl. blokk reallokálás) neked kell intézni. Ez pl. egy kommerciális megoldás. A Linux forrásában is találsz FTL (Flash Translation Layer) kódot, mivel a régi, azóta nagyjából kihalt PCMCIA flash kártyák szintén NAND flasht tartalmaztak.
Hát ez nem nagy öröm, bár én nem akarom meghajtóként használni a NAND-ot, csak bitmap-eket tárolok rajta, tehát egyszer ráírom és utána csak olvasok róla. Ekkor is kell ezzel az FTL- el foglalkozni, vag csak ha sokszor írom a flasht?
Elvileg ez is támogatja a NAND-ot. Nekem fontos lenne az OS- nélküli megoldás  A hozzászólás módosítva: Okt 12, 2013
Szerintem előfordulhat, hogy valamelyik blokkba már elsőre sem tudsz hibátlanul írni. Nem kell feltétlenül OS-t használnod, elég belőle kimásolni a kódot
A hozzászólás módosítva: Okt 12, 2013
Hát én csak fizetősöket találok
 .Lehet mellényúlás volt ez a NAND? Van valami jobb alternatíva helyette? Vagy érdemes egyszer kiszenvedni a kódot aztán nincs vele gond?
Alternatíva? Pl. SD kártya. Ha ilyen sok-sok MB kell. Ha pár MB elég, akkor SPI soros flash.
A linux kernel forrása biztosan nem fizetős, azért említettem. Olyat készen amúgy sem fogsz kapni, amit csak bemásolsz, és gondolkodás nélkül használhatod, még a fizetősöknél is kell gondolkodni.
Persze, nem is akarom én munka nélkül megúszni, csak több infóra lenne szükségem, mert nem tudom mit kell csinálnom a hibás blokkokkal és a sparearea-val.
Az eddigi leírások elég szegényesek számomra. Gondolom kiolvasás mindíg jó inkább az írásnál lehet gond, hogy az új adat már nem írható be teljesen, vagy nem törölhető a blokk. Így kéne csinálni: ? 1. mondjuk az 1-es lapra szeretnék beírni adatot. 2. az írási, vagy törlési hibát jelzi mondjuk egy ECC interrupt. 3. itt keresek egy jónak titulált blokkot, mondjuk a 2-est és beírom az adatomat, majd mondjuk egy külső (megbízhatóbb helyre) letárolom, hogy mostantól az 1-es blokk valójában a 2-es. Ez így elég baromságnak hangzik, lehet jobb lett volna a NOR flash, vagy ott is kell ilyen varázslatokra készülni? Szerk: Az sd-vel az a bajom, hogy azt el lehet távolítani a panelről A hozzászólás módosítva: Okt 12, 2013
Idézet: Már amelyiket... „Az sd-vel az a bajom, hogy azt el lehet távolítani a panelről.”  Bővebben: Link Idézet: „mert nem tudom mit kell csinálnom a hibás blokkokkal és a sparearea-val.” Azért nem ördöngősség: a NAND flash legelső vagy legutolsó blokkja NOR flashből van kialakítva (olvasd el a chip doksiját), így az nem tud rossz lenni. Ebben kell tárolni valami infót, amiből lehet tudni, hogy melyik blokk helyére melyik lépett (nyilván a flash végéből kell behelyettesíteni, és annyival csökken a kapacitás). Vagy ha nem fér el ebben a blokkban, akkor meg valami mutatót, hogy melyik blokkokban van ez a lista. Olvasásnál nincs mit tenni: ha nem jó az checksum, akkor annyit tudsz csak, hogy az információ elveszett, nyilván itt a működés nem lehetséges. Szerintem csak írásnál van értelme a reallokálásnak, és természetesen minden írás után vissza kell ellenőrizni, hogy valóban jó lett-e az írás (különben reallokálás jön). Idézet: „a NOR flash, vagy ott is kell ilyen varázslatokra készülni?” A NOR flashben ez belül meg van csinálva. Cserébe sokkal kisebb kapacitású, és drágább is. Idézet: „Az sd-vel az a bajom, hogy azt el lehet távolítani a panelről” Az SD kártyát mikrokontrollerek jellemzően SPI felületen használják, az SPI soros flash IC-k ezzel a felülettel kompatibilisek (a parancsok nem pont ugyanazok, de csak kis szoftver módosítás kell). Az SPI soros flashek belül NOR flashek, ezért kisebbek és drágábbak. Az SD kártyák tudnak gyorsabb, SD felületet is, amit viszont csak pár mikrokontroller tud kihasználni (az STM32F4-ben mintha lenni ilyen). Olyan IC-k is léteznek, amik az SD kártya tudásával megegyeznek (SD felületet is tudnak, és egyező parancsokkal mennek, belül NAND flash van, tehát nagy kapacitást tudnak), és felforraszthatók a panelre. Apró hiba, hogy ezeket nehézkes beszerezni, meg jórészt BGA tokozásban vannak...
Ha már SD kártyáról van szó: SDIO módban szeretném használni, LPC1788-al. Van e valakinek doksija az SDOI.org oldalról? Jelenleg ott tartok hogy:
CMD0 (reset) CDM55 (next command will be application specific) ACMD41 (send operation conditions) erre jön a válasz hogy: Reply COMMAND: 0x003F; Response0: 0x00FF8000; Ezután még jönne egy CMD2 CMD3, és itt érne véget az init, legalábbis az én leírásom szerint. Mivel van vagy 4 Response format (és mindnek külön regiszter), ám az én dokumentumaimban, az egyes parancsok-ra adott válaszok, és azok bitenkénti leírása nem szerepel, ezért kérném a segítségeteket, hátha már valaki foglalkozott vele nagyon alulról. |
Bejelentkezés
Hirdetés |
