a misc.h fájlban is átállítottad a vektortáblát?



Én két nepig szívtam miatta és sosem volt jó a bl.

Az alábbi függvény

Ezt tartalmazza:
VTOR = param1+offset. Azaz 0x08000000+0x8000 = 0x08008000 lenne.

Misc.h-ban definiált NVIC_VectTab_FLASH-t nem láttam sehol felhasználva (csak én használtam a main-ben). Se a CMSIS, se startup semmi nem használta ahogy látom.

Vagy tévedek, és rossz helyen néztem?

Azért írtam, mert nekem sem működött addig, míg át nem írtam.

Jól értelmezed én is így értelmeztem, de nekem addig nem működött amíg a misc.h ban át nem lőttem.


Egy próbát megér állítsd át a misc.h-ban, a SetVectorTable meg kommentelheted is szerintem.

És egy kis idézet:

Üdv!

Úgy gondltam, amíg megérkezik a fejlesztőcucc, addig kipróbálom a jelenlegi kialkítást, úgy, hogy a belső ramot használom és a kijelző egy részét töltöm csak fel.

Tehát a kijelzőm SSD1289 és 320*240 felbontású.
A sima rutinokkal gyönyorűen működik, (most egyelőre DMA nélkül) úgy gondoltam, hogy csinálok egy 32 k tömböt (a kijelző fele) és azt simán kimásolom a FSMC címre nekem 0x60020000 on van a kijelző. És ha minden oké akkor a kijelzőn megjelenik a kép, amit előzőleg bemásoltam a tömbömbe.
De sajnos nem ez történik a kijelzőn semmi nem jelenik meg.

Kérdés: asima inithez képest mit kell máskép initelni a kijelzőnél, hogy pixeldatát küldhessek neki?

Szia!
Most nem nagyon vagyok képben, mert az árvízen szívok, de próbálok figyelni.
SSD1289-hez nem értek. Én a 1963-at használom.
Gondolom azért nem jelenik meg, mert előbb a parancsot kell adni a kijelzőnek, aztán kell elkezdeni a memória területet feltölteni a kijelzőre.

Mostmár megy, csak ugye nekem egy tömb első elemének a címét kellett átadnom és kihagytam előle az & operátort.

A dma isr-ben letiltom a dma-t visszaállítom az lcd koordinátáit 0.0-ra és a timer2 50hz isr-ében engedélyezem újra, csak nekem nincs szinkronban a rajzolás az lcdvel.
Ha mondjuk egy kitöltött kockát mozgatok, akkor vibrál, mert a kocka még felibe-harmadába van kész, amikor a timer/dma páros meg közben pakolgatja a kijelzőbe az adatokat.
Amúgy baromi gyors eddig én azt hittem, hogy az lcd tud ennyit.
Sok sikert az árvíz ellen!

Köszönöm! Kipróbáltam, és debug init után a VTOR ugyan úgy maradt. Legelső ASM sorban már rossz (de sajnos ekkor még flag aktív és eldobná - de rossz helyre)

Most úgy fejleszerintem, hogy visszatettem 0-ra a kezdőcímet, aztán amikor Release-t fordítok akkor azt meg 0x8000-el arrébra fordítom. Főprogram bootloader nélkül 0-án megy. De nem tud valamiért indulni offset-elt VTOR-al...
Gyanítom, hogy ez az openocd hibája.

Keil MDK és az STM32F0 Discovery kártyát próbálom összebarátkoztatni - vegyes sikerrel. Most ennek a leírásnak az útmutatóját próbálom követni (bár ez STM32F4, de az eltéréseket eddig sikerült áthidalni).

Most a 11. szekciónál tartok (View Variables Graphically with the Logic Analyzer ), de ha az útmutató szerint próbálom bekapcsolni a Trace enable opciót, akkor lehülyéz: "Trace HW not present". Ha ez tényleg így van, akkor a Cortex-M0-nál nem lehet használni a logikai analizátort? Vagy valami svédség van a beállításoknál?

Trace-hez ULINK debugger kell. ST-Link-el nem működik!
Keil honlap lap alja

Az előző hozzászólásomban linkelt dokumentumban egyértelműen a Discovery kártya ST-link/V2 debuggerét használják. Tehát ezzel is menni kellene.

Ez mondjuk nem az a trace, amire én gondoltam. A megfelelő .ini fájlt megadtad a debugger beállításoknál?

Természetesen, hiszen az útmutató külön felhívta rá a figyelmet.

És egészen pontosan milyen .ini fájlt használsz? Csak mert a 407-hez való biztosan nem jó! Tedd fel ide, hátha ki lehet belőle hozni valamit. A Trace tab-en a Core Clock korrektül be van állítva, elég kényes rá.

Hmmm, ez volt a kisebbik baj. A nagyobbik baj az, hogy az adatlapokban történő kutakodás után az derült ki, hogy STM32F0-ban egyáltalán nincsenek olyan bitek, amelyeket itt be kellene állítani (DBGMCU_CR regiszter TRACE_IOEN=1, TRACE_MODE<1:0> =00). Ez akkor semmiképp sem fog menni...

Sajnos nagyon úgy tűnik, hogy a meglátásod helyes!

Most kivételesen nem tudok örülni neki, hogy igazam van.

Coocox CoIDE és Nuvoton Cortex-M0 (NuTiny-SDK-NUC140) páros esetében sikerült beüzemelni a semihosting funkciót. Ez azt jelenti, hogy debugolás közben üzeneteket is kiírathatunk a PC-re, a debuggeren keresztül.

Semihosting beállítása
----------------------------

1. A Repository ablak Peripherals fülére kattintva jelöljük ki (pipa) a COMMON szekcióból
a Semihosting komponenst! Ez valószínűleg magával vonja (ha nem, akkor jelöljük be!) a Retarget printf és a C Library komponenseket is.

2. A főprogramba csatoljuk be a semihosting.h fejléc állományt!

3. A projektbe automatikusan felvett printf.c állományba is csatoljuk be a a semihosting.h fejléc állományt, emellet definiáljuk felül a PrintChar() függvényt így:



4. A Configuration ablak Link lapján a Library paraméter beállítását állítsuk át Semihosting-ra!

5. A Configuration ablak Debugger lapján tegyünk pipát a Semihosting enable elé!

6. Az alábbi kis program lefordítása és a Debugge elindítása után a CoIDE jobb alsó sarkában megjelenik egy Semihosting nevű ablak, amelyben - kissé darabosan ugyan - de sorra megjelennek a kiírások. Akkor történik kiírás, amikor a néhány karakteres buffer megtelik...

Kiíratás SH_Sendchar(), SH_SendString() vagy akár printf() függvényhívással történhet.




Előzmények: CooCox CoIDE és a NuTiny-SDK-NUC140 kártya összebarátkoztatása

Most akkor megy? Sikerült a tömb első elemét megadni indirekt címnek?
Vibrál? Az nem lehet, nekem folyamatos volt. Valós időben mértem az FPS-t, mert minden teljes képfrissítés után (6x80 sor) billentettem egy lábat és mértem a frekvenciát. Milyen képsebességet értél el? Én ha feltúrom a gépeket, lehet még videókat is találok róla.
Tudtad használni a kódot, vagy annak részeit amit kaptál?

Amikor a DMA végez a kirajzolással, akkor beállítok egy jelzőflaget, ami jelzi a főprogramnak, hogy most rajzolhatok a framebuffer-be, így mire a következő Timer megszakítás jön addigra megvan rajzolva az új kép és így már hibátlan, nem vibrál, nincsenek félig kirajzolt adatok.
Én nem mértem sebességet, de majd leesett az állam a különbségtől a sima LCD kurzormozgatós rajzoláshoz képest. Folyamatos a kép. Tökéletes a cucc. Remélem ha meg lesz a külső SRAM-os verzió, akkor sem fog sokat lassulni. Ráadásul még marad hely, az SRAM-ban, hogy rétegeket hozhassak létre.

Képdekódoló eljárásból van amit szabadon lehet használni. Szeretnék animált gifet megjeleníteni, de eddig csak fizetős könyvtárak voltak.

Elmondom neked, hogy valami bibi lehet a programoddal, mert ha a DMA folyamatosan tolja a képet, akkor nem villoghatna a képed. Nem tudom milyen frekin dolgozik most az STM-ed, de ha egy félkép kijelzés közben beleírsz az SRAM-ba akkor se szabadna villognia, mert hát 25Hz fölött a speed, és a következő frissítésnél (amit a sebességnél fogva a szem nem képes követni), már mindennek ki kell kerülnie a képre. Nekem nem villogott, amikor 16 bitnyi színskálával kiszíneztem a teljes képernyőt.
Van külső SRAM-os cuccom, igaz 207-es de a 40fps-t tudta. És úgy hogy ugyan azon az FSMC buszon volt az SRAM amiből ki kellett szedni a kép adatot, és ugyanarra a buszra kellett kiküldeni az SSD1963-ra. A 407-nek van 192k belső SRAM-ja, tehát abba azért elférne egy kisebb video buffer.
Mutasd már meg nekem kérlek a DMA interrupt részt kérlek. Én a kijelző 0-5ig terjedő egyenként 80 soros szektorait a DMAcounter nevű számlálóval tartottam kordában, és amikor az 5-lett, akkor nullázva a következő alkalommal már újra a bal felső sort kezdtem.
Milyen felbontású kijelzőre fogsz írni?

Itt a kód ,most jól működik. Egyébként ez a flages dolog régen is működött, a videokártyáknál is volt ilyen flag anno.

Most a belső ramot használom tesztre 320*240 kijelzővel.

Úgy látom akkor tudtál meríteni az én progimból...
Mi volt a hiba?
Fura volt a kód, aztán rájöttem hogy ez nem SSD1963.
Előbb Timer nélkül csináld meg, és nézd meg hogy mennyi a max sebesség.
És akkor kiderül mit tud a procid, és finomíthatod az FSMC időzítését is.
Timer-es részt (buszterhelés csökkentésére) hagyd a végére.

Igen, köszönöm, a kódot, sokat tanultam belőle.

Ja és tényleg egyszerűbb az init a cmsis nélkül, végülis pic-nél sem használtam a mikrochip librarit ha nem volt muszály. Mire összelapátolom a fájlokat a cmsis-hez addigra kézzel beállítom.

Hogy mi volt a baj? a kijelző osc beállítása

Igy szokott ez lenni. Értékadó utasításokkal direktbe a regiszterekbe sokkal egyszerűbb, mint a CMSIS-ek értelmezése, szintaktika, stb stb. CMSIS számomra csak az OSI layer egy fél szelete, csak lassít, bonyolít és nem látod tőle a lényeget. Szerintem.

Viszont az a baj, hogy nincsenek ékezetes karakterek

Akármilyen karakterkészlet kódot vadászok a CE verziónek se híre se hamva.

Nem értem. Mihez nincs ékezetes karakter? Ha a TFT-re akkor nem kell vele foglalkozni, úgyis mindent neked kell megrajzolni. És olyan lesz amilyet te csinálsz. Én a HD44780 karakterkészletét koppintottam le, 5x7 formában. Akárhogy is, a videómemória fölött az 512k SRAM-ba el fog férni fölötte egy ASCII tábla.

Értem, csak amik nekem vannak karakterkészletek több méretben abban nincs ékezet. Most akkor sajátot kell konvertálni.

Jónagyokat!
Érdeklődnék, van -e bárkinek bare-metal tapasztalata on-chip TFT vezérlővel lehetőleg NXP LPC típuson. Annyira bare-metal hogy a CMSIS libeket is hanyagolnám. Most kezdek nekiállni, és hátha lesz egy két meglepi, amit átugranék, érdeklődés hiányában.

Üdv!

Én meg keresném az STM32 SFU (secure firmware upgrade) leíráshoz való firmware demót, de nem találom, csak a doksiját.
A titkosítás nélküli az már megy pendrive-ról tudok upgradelni, de nekem a titkosított mód kellene.

Illetve mégegy az STM32-nél hogyan lehet azt megcsinálni, hogy ne tudják kiolvasni a kódot belőle? Tehát írni mindíg tudjam, de kiolvasásnál csak nullákad adjon.

Bővebben: Link Read Protection kell neked.