Nagyon köszönöm!
Itt aztán van választék, ezer hála!

Ezekről biza semmi infó a neten!
Hól lehet őket kapni, stb …?

Teljesen a gyártóra vagy szorulva!
Szerintem csak 1000-es tételben érné meg.

A gyártótól is lehet mintát venni, csak jól kell kérni.
Van magyarországi forgalmazójuk is, de velük nem mentem semmire.

Az jó, mert én csak ledet szeretnék villogtatni vele...
Közben belőttem a Coocox idét is a GCC fordítóval....

Én meg kipróbáltam az Em::Blocks IDE-t, amit vzolee ajánlott, és eddig tetszik. Simán bekonvertálta a Coocox projectem. Végre egy IDE STM32-höz, ami ingyenes és nem Eclipse-szel bohóckodik. Untam már, hogy lassabban indult a CoIDE, mint a Windows7 boot. No meg az 1.7.6. néha valami Java-s hibaüzenetet dobált.

Gondolkodom én is ARM kontrollerek tanulmányozását. Eddig PIC-eket programoztam, (továbbiakban is maradok PIC-es) ill. szoktam még Arduinokat programozni, de ott az IDE mindent eltakar, amúgy nem vagyok AVR szakértő.

A Nuvoton mennyire jó választás kezdőknek? Az olcsóság és beszerezhetőség miatt tetszik elsősorban. Fontos lenne ingyenes fejlesztő szoftver, erre nem szánok pénzt. Akkor inkább más kontrollert nézek...

Szóval mindent összevetve (sw, tutorialok, bugok, demo kártyák, stb) szempontjából hol áll a Nuvoton?

Én az ST-t tudnám ajánlani.
F429Discovery kb. 10.000Ft (postával)
Itt már kapsz egy nagyon komoly kontrollert és a letöltő hardver is rajta van.

Ha olcsóbb kéne...
F4Discovery kb. 7000Ft (postával)

F0Discovery kb. 5000Ft (postával)

Ingyenes IDE: Em::Blocks
Nekem nagyon tetszik, de kettővel fentebb toto is leírta a főbb ismérveit.

Köszi!

Úgy látom, igazad van, az ST is olcsó, több helyen beszerezhető és azért nagyobb, ismertebb gyártó.

Ha már STM32 a téma...Ez egy igen hasznos program lesz, ha majd kiforrja magát.

STM32 periféria konfigurátor program

Jelenleg csak F2xx-hoz és F4xx-hoz használható. Ma láttam és nagyon megtetszett.

Ha fogsz egy olyan ARM-ot aminek van TFT kimenete - de az SSD1963 is jó fizikailag - teszel rá egy RGB-LVDS átalakítót, és utána már mehet rá a mini-laptopok kijelzője. Azoknak LVDS bemenete van.
Arra természetesen oda kell figyelni, hogy az SSD vagy az adott ARM mekkora kijelzőt tud meghajtani. Sok ARMnál a 800x480 a max amit leírnak, bár az LCD-vel kapcsolatos regiszterek egyes részeinek mérete alapján, és a külső SDRAM mérete szerint is képes (lehet) ennel nagyobb kijelző hajtására.

Igen, én is beleástam magam az LVDS jelekbe, és azt vettem észre, hogy elég egy TTL->LVDS átalakítás, persze LVDS ic-ből is van kismillió féle.
Egyébként úgy emlékszem, mintha te foglalkoztál volna már az STM32F429 típussal, van esetleg már tapasztalat, hány fps-t tud, alkalmas lehet 800x480 felbontásban valami video lejátszásra, hang nélkül?

Nos annyi kérdésem lenne, viszont, hogy az SSD1963-al milyen kijelző köthető össze, mert nem mindnek egyformák a kivezetései? Pl.: ha ezt szeretném rákötni, akkor nem minden kivezetésnek találom meg a párját az ssd-n.

HSYNC, VSYNC, DotCLK, és RGB lábakat kell csak rákötni.

De akkor már jobban jársz az F429-el az F407 helyett. Vagy lehet mégse... mert akkor SDRAM is kell, az meg elvisz egy rakat lábat.

Szia!
Vzolee foglalkozott 429-el, ott a beépített TFT vezérlővel. Ebben nem nekem, hanem neki vannak tapasztalatai. Én a 207-et használtam, akkor 120 helyett 158MHz-en túlhajtva. A gyenge kereszt metszet ekkor az 512k SRAM volt. Az SSD-t ekkor a 800x480 kijelző 384k adatát 6 részben (16 bites a DMA számálója 64k-nál hosszabb DMA stream-et nem kezel) feltöltve úgy 45fps-t értem el. Úgy hogy ugyan ezen a buszon volt az SRAM maga is ami a képet tárolta.
Ez a sebesség mind külső mind belső vezérlőnél fölösleges, és jó magam az időzített 25pfs-es képfrissítés híve vagyok az SRAM-ból, hiszen minél nagyobb a képfrissítés, annál nagyobb az adott busz terhelése amire azért adott esetben más eszközök is lehetnek kötve pl nálam NAND flash.
Igaz most éppen másik irányban indultam el, uSD kártyát használok SRAM helyett, 4bit SDIO módban, de ez már másik sztori.

Nálam az fsmc a szűk. 407+sram+ssd1963 800x480 16bit és pár fps-nél többet nem érek el, és valahogy bedugul az SRAM adatfolyamnál az FSMC. Már mindent próbáltam, de lehet nem olyan sramom van mint kéne, nem tudom. Nand nekem is van és uSD is. Szoval, ha max power-el tolom az adatokat mondjuk SRAM->FSMC->SSD1963, akkor max pár fps, akkor is ha csqak ezzel foglalkozik a 407 és DMA-val hajtom. Mégis leterheli a CPU-t is (gondolom az adatbuszt fogja meg.)

Valami nagyon el van tolva. 4xx alapból megy 168MHz-en. Az SRAM-om ezt a sebességet 10ns-osként tudja. A panelem gyárilag valami Xar 70ns-al volt szerelve, vagy 8 rugót költöttem 512k SRAM-ra. Szóval nézd meg az SRAM-ot.
De az is kérdés hogy az SSD-t jól állítottad e be. Elsőként hagyd ki az FSMC-t és szoftveres 8080 buszal próbáld hajtani Előbb ott told a sebességet az egekbe aztán ha az ok, és az SSD veszi az ívet, akkor mehet az FSMC. Nekem nagyon nagyon tekert. De már asszem átküldtem neked a kódomat anno.

Te SPI-ben használod az uSD-t?

Igen. Az SSD az megy mint a szél, akkor van baj, ha az SRAM-hoz fordulok, pl ha onnan tolom aképet az ssd-re, akkor pár fps, ha meg még írok is az SRAM-ba, akkor meg jó ha 1 fps.
az SRAM ISSI62WV51216BLL.

Az SD-t 4 adatvonalas spi-ben használom, az szépen megy.
Egyértelműen látszik, hogy az SRAM - nál van valami, majd kiderül.
Legközelebb a 429-et választom és nem kinlódok SRAM-okkal.


Lehet veszek egy ilyen 429I discovery-t de nem tudom azt a kijelzőt le lehet e venni róla és sajátot rátenni.
Nekem akkor kéne 429 ha valami video-t is elbírna SD-ről (MJPEG) 800x480-on. Ha nem akkor erősebb kell.

Van kódom SDIO-ra. Felejtsd el az SPI-t. Ír, olvas.
Áttoltam az NXP-ről, már megy STM-en is.
Discovery-ről nem kell a kijelzőt levenni, vzolee csinált hozzá jó expansion board-ot, amin standard 40pin ki van vezetve, plug and pray. Csinálok róla képet hamarosan.
Ez így ok ez az SRAM csak utána még van egy kötőjel pl hogy -55TLI = 55ns. Ezt nézd már meg hogy a tied konkrétan milyen.
Két sor a timingje, ha gondolod áttolom a setupját, ami az időzítését rendezi.
SDRAM se mindig egyszerű. Egyenlőre nem tudom min, de 99%nál buktam el az NXP-vel, fentebb olvashattad. De nem adom fel, mert ki fogom deríteni mi a gáz, igaz közben portolom az egészet STM32-re vissza.

Jó játék lehet akkor az SDRAM-al is.

Gondolkodtam az ATMEL SAM9 vagy ilyesmiben is, hogy ne kelljen szívni, de az megint más világ.

Az SRAM 55TLI, ahogy írtad.
Ha nagyon leveszem az időzítést, akkor mocorog a kép, és pixelesedik is néha.

Most így megy:
p.FSMC_AddressSetupTime = 4;
p.FSMC_AddressHoldTime = 0;
p.FSMC_DataSetupTime = 3;
p.FSMC_BusTurnAroundDuration = 0;
p.FSMC_CLKDivision = 0;
p.FSMC_DataLatency = 0;
p.FSMC_AccessMode = FSMC_AccessMode_A;

Hogy tudjak haladni, nem csinálok a képen mozgást (scroll, meg ilyesmi) esetleg kicsi alphablending belefér. Az eredeti terveimben mindent az sram-ban csináltam volna, hogy ne kelljen a kijelzőtől adatot beolvasni.
Egy queue-be bepakolom, a controljaimat és onnan kirakom sram-ba a megfelelő prioritással, az SRAM->SSD műveletet, meg intézze a dma, Ez tök jó volt 320x240 ig, de most itt lassú az adatátvitel.

Bocs az SD-t rosszul írtam én is 4bit SDIO-t használok dma-val+FATFS, az sd io- drivert a kínai adta.
Annyi fúrcsát láttam az sd driverben, hogy tettek bele while wárakozást is, amit én nem szeretek, nekem egy szokott lenni a main-ban és kész.
Szóval lehet én vagyok a tudatlan, de mi értelme van egy DMA kezelt SDIO-nak, ha while-val megvárja míg végez a DMA?

Nem értelek titeket. Kb senkit. Miért kell erőltetni a CMSIS-t?
Nekem "saját" SDIO-van, az init "mi után mit kell csinálni" még itt kaptam egy LPC2448-ról.
Nem szeretem azokat a kínai mintákat.
Én szorosabb időzítésekre emlékszem. Mennyi a proci freki? Mennyi jut az AHB, vagy APB-re ahol az FSMC van? Nézted a system_stm32f4xx.c file-t? Abban egy tetemes rész foglalkozik az FSMC-vel ha #define DataInExtRAM unkommentelve van.

system_stm32f4xx.c nem piszkálgattam, csak amit a bootloader miatt kellett, és nekem nemsokminden van az FSMC-ről benne, de az a kevés sem használt mert nem definiált a DATA_IN_ExtSRAM.
A keil template 25Mhz kvarcot adott meg, én azt átírtam 8Mhz-re és kész.

ASYSCLK 168Mhz, HCLK 168Mhz, PCLK1 42Mhz, PCLK2 84 Mhz

Küld át kérlek a projected zippelve kérlek. A mail címem az adatlapon.

Köszi, de azt sajnos nem tehetem, ez a kijelzős sram-os rész csak egy kicsi része. Az ssd meg sram részt azt át tolhatom, mert az úgy is gázos, meg az nem titok.

Sziasztok,

végre villog a led, egy STM32F405RG ami a kártya alapja.
Az a láma megfigyelésem, hogy KEIL-al fordítva mintegy 50-szer gyorsabban villog ugyanaz a kód, mint CoIde-ben GCC-vel fordítva...

while(1)
{
for (i = 0; i < 900000; ++i);
GPIOA ->ODR |= (1<<10); // GPIOA pin10 ON
for (i = 0; i < 200000; ++i);
GPIOA ->ODR &= ~(1<<10); // GPIOA pin10 OFF toggle
}

Szóval ez noormális? Illetve mi ennek az oka?

Köszi
Attila

Meg kellene nézni a lefordított kódot (disassembly lista), mert több lehetséges magyarázat van:

1. A Keil olyan hatékony kódra fordít, hogy akár a végtelen ciklus is 50-szer gyorsabban lefut.
2. Valamelyik változó vagy számkonstans típusát a Keil és a CoIDE fordítói nem egyformán értelmezték/kezelték.
3. Esetleg a Keil és a CoIDE alatt futó programod nem egyforma CPU órajelet állított be.

Ellenőrizd a CPU frekvencia beállítását és használd a SysTick-et az időzítésre! Bővebben: Link (bocs ez NUC140 példa, de most csak ezzel szolgálhatok)

Más fordító, más kód. Nekem van egy szoftveres késleltetőm. Keil csinál belőle 5ms-ot, az adott optimalizálási szinten, de pl egy másik fordítóval már más lesz a sebesség.
Mikrokontrollernél, ha pontosan meghatározott időre van szükséged, akkor Timer, Systick timer, esetleg az RTC periódikus megszakítását tudod használni.

Az órajeleket néztem, az elvileg stimmel a konfigurációs állományok alapján...

sajnos az assembly kódhoz még ennél is hülyébb vagyok, max összehasonlítani tudnám a kettőt.

A systick van tervbe véve, ezt a fapados villogtatást csak amolyan első "sikerélménynek" fordítottam le, hogy egyáltalán lássam, hogy értem-e a folyamatot. (egy Netduino plus2-ről szedtem le a .netmf-et

Kösz, elfogadok minden magyarázatot, nekem csak DÖBBENET volt ez a különbség
a Java, C#, után.... , illetve hogy ezek szerint a pontos időzítés nem is annyira kézenfekvő dolog....

Az sincs kizárva, hogy a Keil fordítója egyszerűen "kioptimalizálta" (azaz kihagyta, mert szükségtelennek találta) valamelyik üres for ciklust.