Sikeresen kiméregettem, és valóban a legtöbb láb lebegő állapotban van, miután Reset módban indítottam, mégis találtam egy két érdekességet.
Mivel ez egy fejlesztő panel, nem csak az IC, így normális dolog ha mérek H vagy L szintet egy bekötött lábon.
Viszont a doksi (STM32F4-Discovery) -ban a PA15 PB4 PC11 PE3 egyértelműen freeI/O -ként van feltüntetve még is 2.94V-ot mértem rajta.
Ezek közül a PE3-as alternatív funkciói között a TRACED0/FSMC_A19 található aminek nincs köze szerintem a BOOT folyamathoz (USART/SPI/I2C).
Valami anomália csak van.
Ráadásul ezen a panelen nincs kivezetve az összes láb, így elképzelhető ilyen probléma akár a H porton is, amire ezen a panelen keresztül nem tudtam rájönni.
Esetleg véleményetek elképzelésetek lenne erről?

Folytattam a projektet, és írtam a Discovery-re egy kis progit, amivel a PE3-as lábat alacsony szintre állítom indulás után. majd BOOT módban elindítottam és a lábat kíméletlenül felhúzta 2,94V-ra.

Sziasztok!

Megint én egy újabb hibával.
Eclipse->project->properties->C/C++ Build->Settings->ARM Windows GCC Assembler, majd jobb oldalon
Command:
arm-none-eabi-as
All options:
-x assembler-with-cpp -DUSE_STDPERIPH_DRIVER -DUSE_STM32F4_DISCOVERY -DSTM32F4XX (és az include-ok)

Erre azt írja ki, hogy:
c:\Program Files\GNU Tools ARM Embedded\4.7 2013q1\bin\arm-none-eabi-as.exe: unrecognized option `-x'
make: *** [src/startup_stm32f4xx.o] Error 1

És tényleg nincs benne -x kapcsoló megnéztem.
Hogy lehet megváltoztatni az All options mezőt, mivel itt csak read only-ban mutatja.
Egyéb ötlet?

Melyik startup és system_stm32f4xx.c filet kell használni?
Ahányat használok annyi féle hibát kapok.

Megkérnék valakit, akinek működő eclipses környezete van, legyen szíves exportáljon ki nekem egy akármilyen projektet a projekt beállításokkal együtt (Windows-ra). Nagyon szépen megköszönném. Szerintem nem én vagyok a béna a google alapján.
Esetleg egy másik ingyenes környezet, ahol C++-ban lehet fejleszteni és nem kell hozzá széthekkelni az egész gépet?

Hello! az "-x -assembler-with-cpp" opcio letezik, csak nem az as-nak, hanem a gcc-nek kell megadni.

Üdv!

Nekem ez a leírás bevált: http://www.sectiongo.com/main/setup-eclipse-debug-environment-for-s...board/

Nem tudom mikor kezdted az eclipse arm környezettel való foglalkozást, de nekem kb 1 hónap tömény szívás volt mire sok-sok féle leírás alapján gyakoroltam az összeállítást.
Én egy darabig a CooCox ide-t használtam ezáltal mgszoktam az eclipse környezet beállításait. És utána már könyebb volt összekalapálni.
És legvégül visszatértem a keil-hez, mert a debuggere ennek megy a legjobban (szerintem).
Remélem tudtam segíteni.

Ja: Ha mindenképp színtiszta eclipse-t akarsz(bár mintlejebb írták minden környezet az) akkor ajánlom a Chibi-Studiot. Ez a ChibiOS-hez beállított eclipse, csak felrakod és működik, benne van minden. Annyi, hogy ha nem akarod, akkor nem include-olod be a ChibiOS headereket.(bár ez csak ötlet egy próbát megér).

Üdv!

Ismét STM32F4 kérdés: az mindegy, hogy FSMC <-> RAM átvitelhez melyik DMA melyk stream-ának melyik csatornáját használom?

Pontosabban azt kikukáztam, hogy Memory to Memory copy csak a DMA2-n van.
Azt is megtaláltam, hogy ha perifériával akarok DMA-t használni, akkor az melyik stream melyik csatornáján elérhető(táblázat).
Viszont Mem-Mem copy esetén nem találtam semmi utalást. Vagy ilyen üzemmódban szabadon használható bármelyik stream/csatorna?

Én az FSCM(SRAM) és az FSMC(SSD1963) közti kommunikációra a DMA2Stream0-t használtam.
SRAM: 16bit, post increment, 64000 (PacketNr) elem szuszra
SSD1963: 16bit, no increment, fogadván a 64000-elemet (de már csak a 0x2C, jöhetnek a pixeladatok ömleszve) részhez.
Én ugyan ezt a csatornát használtam tényleges Memory-Memor copy-hoz, legyen szó külső vagy belsőről, bármilyen kombinációban. Úgy tapasztaltam hogy ahol a DMA táblázatban nincs beírva konkrét periféria, az használható a célra amire te szeretnéd.



Aztán ennek az ISR-je:

Megjött a nagyobb lábszámú arm, mostmár össze akartam rakni a külső sram-al a kijelzőt.
Valamiért nem megy, pedik a discovery-vel is ugyanezt a kijelzőt használtam.

Mellékeltem a kapcsolást. A kijelző az NE4-en van A23-A24 címvonallal multiplexelve RS az A15 re van kötve. Mellékeltem a kapcsolást.
Alap demó kóddal (csak FSMC semmi framebuffer semmi DMA) a kijelző gyönyörűen megy.
Ahogy bekapcsolom a framebuffer(egyelőre most még itt is belső ram)DMA combo-t a kijeélző össze vissza szivárványosodik, meg csíkozódik.
A kijelzőt a demo program így címzi:




Ennél a módnál simán kiszámolható a cím és nem működik.

A framebuffert egyelőre piros színnel töltöttem fel, de a kijelzőt ez nem nagyon érdekli.

A discovery407-en a kijelző az NE1-en csücsült multiplex nélkül RS az A16 volt és ezen a címen ment:


Nem is értem mi alapján jöhetett ki ez a 0x6001FFFE cím, de működött.
Elvileg mivel 16bites adatbuszról beszélünk, így a címtartomány 25-0 bitjei belra shiftelődnek egyet.
Lényeg a lényeg, most visszaértem a kályhához. Azt hittem megértettem a címzést de a kijelző nem erről árulkodik.

Mit nézhettem el?
Hogy érted hogy: ?

Igazából a kijelzőnek ehhez nincs köze, ezt tisztán FSMC.
Nekem A0 az RS, és:


DMA nélkül, belső SRAM-ból próbálj egy (akár kissebb), képet kipakolni, amit IMage2LCD-vel csináltál.
Nálam 800x480 kijelzőn, 76800 byte-nyi Picture tömbből (byte-os adatok miatt), a full szoftveres kiküldés így alakul. (MSB fist az Image2LCD beállítása)


Amíg ez nem működik tökéletesen, addig ne állj át az FSMC-n kívül semmiféle hardveres-DMAs támogatásra.
Azt meg soha nem értettem, hogy minek ilyen magas Address lábra feltenni a kijelzőt...

Épp ez az, hogy írtam, a normál FSMC meghajtás tökéletesen megy, bármit kirakok, kirajzolok, kiírok. A baj ott kezdődik, ha bekapcsolom a DMA-t akkor nem működik a kijelző. A framebuffer tartalmát nem látom megjelenni, (ami most csupa piros szin). A jelenség, hogy vagy teljesen fehér a kijelző, vagy pixelekből áttűnik színes csíkokba. ( ugyanez a kód működött a discovery-vel hiszena multkor ezt tárgyaltuk végig, most annyi a változás, hogy nagyobb lábszámu arm lett és a kijelző NE1 helyett NE4-re került.

Kipróbáltam, működik.

így:




Egy kis képből kitöltöttem a kijelzőt. Ezért nemértem DMA miért nem jó.
Ja és én SSD1289 kijelzőzt használok abban nincs 0x2C regiszter.

DMA már csak 0x2C-vel úgy értem hogy:

Ezt kiküldöd a kijelzőre, mintha nem is lenne DMA. Ilyenkor a DMA ki van kapcsolva, egyébként is a DMA2Stream0 beállítása legyen Single Burst.


Majd bekapcsolod a DMA-t, megadod a FrameBuffer kezdő értékét amit én onnan tudok hogy így definiáltam, a külső SRAM kezdő pontjára. Persze ha neked a kép most belül van, akkor ezt valahová belülre pozícionáld.


Ha a kijelzőn több pont van mint 65535 amit a DMA tud (francé nem lehetett oda 32bites számlálót tenni?), akkor kell neked egy számláló ami a DMA Interrupt alatt egy switch-case szerkezettel leválogatsz, hogy a kijelző mely szeletét küldöd ki éppen.
Ha pedig az utolsó részét küldted ki akkor a következő komplett képkiküldés előtt, újra ki kell adni hogy 0x2A, 0x2B, 0x2C stb...

Az már külön érdekes, hogy amikor azt kellett számolnom hogy honnan indul a TFTRAM-ból a következő 64000 pixel akkor elsőnek ezt csináltam:
1. 80 sor. kezdőcím: 0x6400 0000, és indulhat a 0xFA00 (64000) mennyiségő pixel.
2. Ebből arra következtettem hogy DMA2_Stream0->PAR = 0x6400FA00; lenne mint 640001 pixel és tovább.
3. HÁT NEM!!! A kijelőzőm 800 széles, case 0: = 0-79, case 1: 80-159, case 3: 160-239 sorokig, stb stb. 6 case alatt jut el 480-ig, teljes képig. Szóval az Nx80 sorok bázis címeit a DMA2Steram0 Source megadásakor kettővel szorozni kellett, mármint azt az értéket amit a 0x6400 000-hoz hozzá adtam.

Bocsi, mindig elfelejtem!
Használsz valami debugert?
Ha összevissza a kijelző, akkor nem jó a DMA source beállítsa. Próbáld meg amit fentebb írtam, a bázis címhez amit hosszá adsz, szorozd kettővel.

Igen értem, ezt én is hasonlóan csináltam a Discovery-vel, de ott bekapcsoltam a dma-t és működött.

Most ha bekapcsolom a DMA-t, akkor megjelenik a kép, majd a kép kifehéredik szép finoman olyan fehérre, hogy már csak világít a kijelző és a képet elnyomja, mintha a gammát felhúzná. Ha nem kapcsolom be a DMA-t akkor tökéletesen működik a kijelző.

A dma:

Discovery-n ez működött, csak a DMA_InitStructure.DMA_Memory0BaseAddr címet írtam át a jelenlegi kezdőcímre.

A TFTRAM-nak minek adsz kezdőcímet? nem jó neki, hogy oda rakja ahová tudja? vagy azzal csak ráállítod a külső sram területre?

Van stlink2 debuggerem jtag mód, meg valami trace, csak ha az egész tftram-tömböt figyeltetem akkor lassú a debugolás.

Azért kell szorozni kettővel, mert az adatlap azt írja, ha 16bites adatvonalat használsz, akkor a címvonalak alsó 25 bitje balra tolódik és az A0 kiesik. Lásd melléklet.

Mekkora a kijelző?
Hány X elemű DMA ciklus fut le mire kint a kép?
Ha elsőre a kép jól megjelenik akkor a bibi ott lesz amikor az utolsó szelet után, újra elsővel akarod kezdeni a dolgot. Nézd meg hogy az utolsó szeletről az elsőre lépve, pl a szeleteket számoló nálam PacketNr újra nullázva van e, mert akkor a DMA vezérlő már túlfutva a ScreenBuffer címen a memória más szeleteit küldi.
Aztán azt is nézd meg, hogy utolsó szeletről elsőre lépve, újra megkapja a a 1289 a kép pozícióinak adatait, a kép sarkait.

Nekem volt olyan hogy:
DMA2Stream0-hoz tettem egy Breakpoint-ot. Nyomkodva a RUN-t szépen pakolta ki a 80 soros szeleteket.
Majd az utolsó után kifagyott, az egész képernyő fekete lett.
Soha nem jöttem rá mi volt a baj.
Kitöröltem az egész DMA kezelőt, a fent említett módszerrel, újra írtam és jó lett.

TFTRAM-nak azért adtam címet, hogy egyfelől ott legyen ahol én akarom, a külső SRAM legelején, másfelől, a megadott kezdőcím adatot én utána felhasználtam a DMA2Steream0 SourceAddress címének a kiszámolásakor. Nem akartam egy pointert csak ezért használni.
Nem kell a TFTRAM tömböt nézni, csak a DMA2Steram0 regisztereket.
Nem szeretem CMSIS-t. Itt van neked 22 sor kód, és nem látni a mélyére hogy mi történik...

A kijelzőre egyelőre csak egy 38400-as blokkot rakok ki és utána nullázomk a koordinátákat, így minden kanyarnál előlről kell kezdje a dma a kirakást.

Minden breakpointnál elvileg megcsinálja a koordináta nullázást és a tftram-ban is benne, aminek benne kell legyen.

DMA_PeripheralInc_Enable , hogy a TFTRAM tömbön végig tudjon menni, a
DMA_MemoryInc_Disable, mert ott nincs min lépkedni.

Tovább kísérletezek.

Azért kell szorozni kettővel, mert az adatlap azt írja, ha 16bites adatvonalat használsz, akkor a címvonalak alsó 25 bitje balra tolódik és az A0 kiesik. Lásd melléklet.

Ezt mondom... CMSIS...
Lehet hogy nem SingleShot-on volt a DMA-d?
Ötlet:

Futasd le a CMSIS-es DMA configod.
Utána ne csinálj semmit.
Tedd utána az én konfigom.
És nézd meg mely regiszterek hogy változtak DMA2Stream0-ba.

Volt egy kitörölt hozzászólásod hogy az én konfigommal megy. Most akkor megy vagy nem?

Nem nem az volt a baj, csak a kijelző befagyott, azért maradt rajta a kép.
A baj az volt, hogy az lcd initet a demo-bol vettem ki és a konfig végén nem volt lezárva a parancs 0x22-vel, így a dma konfigolatlan kijelzőre pakolt.

Most ott tartok, hogy a külső sram-ból a dma átteszi a tartalmat a kijelzőre, de van benne egy luk, amit kihagy. Kb a kijelző 1/4-e.

Én 1 hónapot szenvedtem azzal, hogy az SRAM-ot a Keil gyári "use ext sram" rutinjával használtam. A gond csak az volt hogy "fentről" nézve egyel kevesebb volt az Address láb pre-config-olva gyárilag, igy 384k helyett az kép első 256k-ja ment ki, majd újra az SRAM elejéből lett véve adat hogy a képernyő fel legyen töltve... 1 hónap, számos ősz hajszál, + mindenféle tehetségtelennek összehordtam magam.

Egyébként kérdezni akartam, hogy SD-ramot is lehet rápakolni az FSMC-re? Mert a multkor láttam, hogy arról diskuráltak itt, igaz ott LPC-ről volt szó, ha jól emlékszem.

Sok kínlódás után Keil alatt is sikerült beüzemelni a semihosting módot Nuvoton Nuc140 és Nulink-Me esetén. Valahol azt olvastam, hogy a Cortex-M0 gyártók közül az NXP és a Nuvoton mikrovezérlői támogatják a semihosting módot.

Sajnos, sehol sincs rendesen leírva, illetve ami a "NuMicro Cortex-M0 Keil ICE driver user manual"-ban le van írva, az már rég nem úgy van.... (nincs is olyan könyvtár/file, amit aszerint másolni kellene).

Pedig alapjában véve egyszerű:
1. A startup_NUC1xx.s állomány legelején a SEMIHOSTED makró értékét át kell írni, hogy ne FALSE, hanem TRUE legyen.


2. A system_NUC1xx.h állomány elején ki kell venni a komment jelet az alábbi definíció elől.


A projekt újrafordítása és a debug módban történő futtatása során a printf() függvényhívások a Nu-Link emulátoron keresztül a Keil IDE-nek küldi ki az üzeneteket, amelyek a View menü Serial Windows / UART #1 meüpontjában megnyitható ablakban fognak megjelenni, ahogy a képen is látható, a jobb alsó sarokban.

LPC1788-nak láttam az SDRAM-ra olyan lábakat kötve, amivel az STM-nél nem találkoztam. Ebből arra következtetek, hogy STM32F2xx nem támogatja az SDRAM-ot. És mintha az FSMC leírásában sem láttam volna.

STM32F42x/43x szériánál van SDRAM támogatás is. Előbb is bele tehették volna

Az egyelőre nem létező termék... annyira, hogy még a részletes doksit se találni az STM weboldalán, csak egy adatlap van, mérsékelt mennyiségű információval.

Értem, most, hogy a kijelző hibátlanul működik a külső sram-mal, mostmár az a kérdés, hogy hagyjam -e full sebességen frissíteni a kijelzőt, vagy egy timerrel inkább időzítsem?

Gondolok itt arra, hogy ha az sram-ot másra is szeretném használni framebuffer-en kívül,(mert hely az van még benne 512kx16), akkor nem e fogja a folytonos LCD<->SRAM DMA művelet megfogni a buszt és esetleg a más sram terület elérését lassítani?
Valami külfldi fórumon olvastam, hogy állítólag a cortexMx ekben a külső sram elérés nincs cache-elve, ezért nagyságrendekkel lassabb a belső sram-nál, bár én eddig meg vagyok elégedve a sebességgel.

Nekem a külső SRAM -> (külső) SSD-re a sebesség 120MHz helyett túlhajtva 158MHz-ig úgy alakult hogy 42fps. Minden teljes képfrissítés után volt a DMA2Stream0 Interrupt rutinba egy bit toggle és azt néztem logikai analizátorral.
Nos ezek után döntöttem el hogy ez sok. Csináltam azt, hogy:
25 kép/s, egy kép 6 szelet => 150 szelet/s kell folyamatosba.
Csináltam 1/150s-os Timer0Interrupt-ot, és mindig az indította a DMA2Stream0-t.
Esetleg azt is meg lehet csinálni, hogy "egyenletesebb" legyen az FSMC terhelése az SRAM irányába hogy nem 6 szelet (nálam a 800x40 kijelzőre így adódott), hanem minden egyes sor egy DMA Burst.
Ez már csak fantázia kérdése, kinek hogy kényelmes.