Szépen megy a cucc, bár az a csíkozódás, még mindíg ottvan, ha sötétebb tónusú a kép.
Nem a meghajtás, vagy a program hibája, olyan mintha az lcd saját maga generálná.

Viszont ékezetes karakterekkel baj van, hiába generáltam le őket mégsem jelennek meg. Lehet, hogy a char tartományon kívül esnek, tehát 127 fölé?

Ha a kép csíkos, és nem direkt vannak benne (az adatokban), akkor a kijelző vezérlőddel lehet valami, nincs pontosan hozzá állítva az aktuálisan használt TFT kijelzőhöz.
A karaktereidhez nem tudok hozzá szólni, nem ismerem a vezérlődet.

Hát sajnos másképp nemtudom leírni a jelenséget, de olyan minta amikor anno az HBO dekóder nem volt tökéletes és halványan látszott a tv képernyőjén a csíkozódás, főleg, amikor sötétebb volt a kép.
Sajnos másképp nem tudom leírni a jelenséget.
Akkor is ott van, ha lcd init után reset-be rakom a cpu-t és a kijelzőt magára hagyom.

Lövésem nincs mit lehetne paraméterezni még ezen, vagy min múlik a dolog. SSD1289

Azok a csíkok a TV-n akkor voltak ha a sor és képszinkron nem volt tökéletes.
A TFT-n erre van a front/back porch mind HSYNC, mind VSYNC esetében.
A hiba ott lesz szerintem tuti. De van itt egy csávó Peppe, ő jobban vágja.
Egyébként ha csinálsz róla egy képet hogy hogy néz ki most, az tbbet mutat 1000 szónál.

Már próbáltam fotózni, videózni, de sajnos nem látszik belőle semmi. Szemmel látható halványan. Csak az veszi észre, aki folyamatosan figyeli a kijelzőt

Itt egy video

Nem tudok jobbat készíteni, amin látszik is.

Kedves Ciw,

cpt.zoltan.simon kolléga jól mondta. A back és a front porch a hunyó a dologban. Finom hangolás kell csak. Ilyennel én is szívtam sokat. A TFT adatlapja sokat elárul a megfelelő értékekről. Nekem volt 7 féle 4,3" TFT-m és mind más értékekkel volt megfelelő. Kitartás

Tipp: állóképpel probáld beállítani a csíkozodást

Az ékezetes betűket szerintem el kell felejteni. Sokkal több macera van vele mintha csak sima angol menüt csinálnál.

Hát köszönöm, akkor próbálkozom, mindenesetre megnyugtató, hogy csak beállítás kérdése. Én már kezdtem volna valami hw hibára gyanakodni.

Ettôl komolyan a falra tudok mászni! Mitôl lenne macera az ékezetes betû? A karaktergenerátorban elfér, nem? Mondjuk ISO-8859-2 kódolással. Mi ezzel a macera? Egy byte egy karakter. És ha 127 fölötti a kódja az ékezetes karaktereknek? Maximum akkor van vele macera, ha a forrásszövegbe nem tudod beleírni az ékezetes karaktereket, mert olyan a fejlesztôrendszer... Azt nem vitatom, strcmp() és társai okozhatnak meglepetéseket, mert az 'é' az vagy több (unsigned) vagy kevesebb (signed), mint az 'f', de semmiképpen nem eggyel az 'f' elôtt van. De ettôl még a printf("Jó napot!"); az jó lesz.

Egyik fordító sem kedveli az ékezetes betűket. Ettől kezdve nem igazán tudod megadni a szövegeket. Hacsak nem trükközöl vele. A kiírás nem nagy macera, tényleg úgy van ahogy mondod. Pl: SD kártyáról felolvasott szöveggel már bajban leszel.

Én már megmásztam ezt a létrát és cpt.zoltan.simon kolléga is.

Én nekem van olyan termékem amin választható a nyelv, és nem csak magyar, de német nyelv is választható. Megoldás nagyon egyszerű, csak a szöveg kiírásnál következő pointert is figyelembe kell venni. Konstansként programban tárolt szövegben az á az a', ó az o' az ő pedig o".
Prímán beírható, és igen is szeretik a felhasználók ha a készülék az ő nyelvükön beszél, még ha ez a programozónak felesleges macerának is tűnik.

8-bites alkalmazásom is van ami SD-ről olvasott UTF-8 kódolt textet is meg tud jeleníteni. És amikor a készüléknek van orosz cirill választható nyelve is, meg német is, azt azért szeretik.
És a printf is működik, hisz a __write függvényt amúgy is definiálni kellene...

Szerk: Killbillnek - az én megoldásommal tökéletesen működik az strcmp is, és minden más string kezelő függvény. Használom is.

Nem hinnem, hogy barmelyik forditot zavarna az ekezetes betu. A gcc-t legalabbis nem zavarja. Az ISO-8859-2 vagy (-1) szovegeket tokeletesen kezeli, nincs vele semmi gond. Neki tok mindegy, hogy a macskakormok kozott mi van, byte-rol byte-ra leteszi konstanskent, szerintem. A létrákról meg csak annyit, hogy ha 1987-ben nem okozott ez a dolog nekem problemat a CP/M-es Manx 'C' forditval, akkor ma sem okoz a gcc-vel. Bar akkor az volt a megoldas, hogy a { [ es tarsai helyett voltak az ekezetes betuk, mert a Terta printer kodtablajaban is ott voltak. A gepemen meg csinaltam egy ekeztetes karakterkeszletet is, es mar meg nem mondom, milyen billentyukombinacira valtotta a karaktergenerator EPROM legfelso cimvezeteket az operacios rendszer... Azt viszont nem ertem, hogy hogy jon ide az SD kartya.

Topi: neked az strcmp az "a'" es "a" kozott hogyan komparal?

Kérdésed nem nagyon értem, de igyekszem választ adni rá. Úgy, mint bármi más stringet.

Ok, de ez ket teljesen kulonbozo string. Ez nyilvan nem egyforma.

En arra gondoltam az strcmp()-s felvetesemmel az elozo hsz-ben, hogy, ha pl. van harom szovegem: "Andor", "Ádám" es "Béla", akkor az strcmp()-n alapulo sort hibasan fogja oket rendezni, mert az "á" semmikeppen nem az "a" es a "b" kozott lesz, míg a magyar ábécé szerint ez lenne a sorrend. De termeszetesen speci custom strcmp-vel ez is megoldhato. Bar talan van erre valami szabvany megoldas is az ANSI C fuggvenykonyvtarban, nem tudom. Bevallom, sosem kellett rendeznem magyar szovegeket. Kiirni kellett, es azzal nem is volt baj. Pontosan, ahogy mondtad, volt olyan keszulekunk nekunk is 1-2 eve, ami angol, magyar es nemet nyelven beszelt. Vindozon irtuk, mplab alatt 'C'-ben, pic32-re.

ANSI C-ben nemigen fogtok ilyesmiket találni, lévén az egy elég régi amerikai valami.
Modernebb rendszerekben találhattok rendes locale támogatást, azzal az strcmp-nek is tökéletesen kell működnie. Mikrokontrolleres környezetbe az uclibc tökéletes, és szerintem van olyan szintű locale támogatás benne, hogy az ezekhez a dolgokhoz elég legyen.

Sziasztok !

STM32F4 -en I2S konfig problemaba utkoztem. 32k * 32b * 2 csatorna beallitassal 2 048 000 Hz CK (bitclock) orajelnek kellene lenni, ehelyett 300+ kHz orajel van. Az MCK is csak 2.6 MHz, ennek 32k*256=8 192 000 Hz-nek kellene lenni.

Idezem a konfig ide tartozo reszet:






Az Init() vegen:


Es a foprogramban:



Valami problema a pll konfig korul lehet. (?)
Valakinek van otlete?

Én ezt használom fontgenerátornak és bevált. De nem jelennek meg az ékezetes karakterek.
Lehet a kiírásnál kéne figyelni, hogy milyen kód jön és, ha ékezetes, akkor azt kirakni?

Én egy delphis kis programot írtam évekkel ezelőtt ami tetszőleges TrueType fontból legenerálja a karaktereket, és lehetőséged ad külön-külön beleszerkeszteni (néha kis méretben bele kell nyúlni a betűbe).
Képekre is azt használom, ha valami kijelzőn ábrákat kell megjeleníteni. De érdekesnek tűnik ez a program is.

Évekkel ezelőtt szintúgy generáltam egy 8, 16 és 24 bit magas karakter táblát, ANSI kódkészlettel ( Bővebben: ANSI ). És másolom ahova csak kell. Szépen egyesével korrigált betűk, normál és félkövérben. Általában csak a definíciós fejrészét kell átírni és egy az egyben átemelhető.

Annyi trükköt csináltam csak, hogy az ANSI táblában kalaposak és tildések a hosszú ékezetes betűk, így nekem kalapos kódon, de nem kalapos karakter van megrajzolva.
GCC-ben pedig prímán lehet ANSI karaktereket írni, semmi átfordítás nem szükséges, csak a tömbben helyes pozíción kell lennie.

Szerk: Annyi elő és utófeldolgozás van, hogy én fix szélességben (könnyű memória ugrás miatt) tárolom, de a kiírásnál a fix szélesen tárolt betűket is proporcionálisként kezelem, kiíráskor valós időben illeszti össze a karaktereket az előző-következővel.
Hosszú í ékezete a következő karakter fölé tud nyúlni, az i és az a nem egyforma széles.
Ez már csak szőrszálhasogatás, de sokkal szebb és helytakarékosabb kijelzőkön a proporcionális karakter megjelenítés.

Értem, ezis valami hasonló, csak nyílt kódú, de szuperül működik, és alapból szélességgel együtt tárolja a karaktereket, és kiírásnál figyelembe veszi a szélességet. Jó cucc. Persze az AntiAlias miatt itt sem lehet 10-esnél kisebb karaktert generálni.

Mondjuk érdekes ez az ANSI kódolás, mert nekem a keil alapból abban működik, mégsem igaz az általad mellékelt táblázat.

Régen én igaz text lcd-n de én a régi dos pozíciókban tároltam az ékezetes karaktereket. Pl. é=130

Ez azért van, mert az "ANSI" kódkészlet (mai nevén: US-ASCII) egy amerikai szabvány, ergó magasról tesznek az ékezetes karakterekre. Ez pontosan abban nyilvánul meg, hogy 127-ig van definiálva a karakterkészlet. Az, hogy a Windows, vagy a Visual Studio mit és hogy használ ezek felett, az nem része a szabványnak.
Ha rám hallgattok, akkor valódi, ékezetes karakterekre megálmodott szabványokat használtok. Melegen tudom ajánlani pl. az ISO8859-2 (becenevén: Latin2) szabványt, abban minden magyar betűnek van helye.

Értem, hogy szabvány, meg minden, de ebből:



Nem lesz ez: "almát", mert ugye ha megfeszülök a char akkor is csak 0-127. az 'á' kódja meg ASCII 160 ugye.
Vagy castoljam minden alkalommal unsigned-re.
Ráadásul a azok a szabványok nem azért tudnak olyan bőkezűen bánni a karakterekkel, mert több bájton tárolja őket?
Megnéztem egy bájt 0-255 tárol, de mondjuk pl a keilben írhatok én ASCII 225 öt az nem á lesz hanem ß. Viszont, ha ALT+0225 akkor á lesz

Tehát:
- az, hogy mit mutat a szövegszerkesztőd (és milyen bináris karakter kerül a C forrásodba), az a szövegszerkesztőd (IDE-d) beállításaitól függ; rendes környezetben azért meg lehet mondani neki, hogy milyen karakterkódolást használjon,
- a char-ba nagyon könnyedén bele lehet rakni az ASCII 160-as karakterkódot, és a char mögött levő tárolóterületre a 160-as byte érték fog kerülni; igaz, ha ezek után ezt a char értéket előjeles feldolgozásnál használod, akkor a (160-256)=-96-os értéket fogja használni a fordító; ha viszont a char értéket átcastolod implicit vagy explicit módon unsigned char típusra, rögtön vissza is alakul 160-ná,
- nem kötelező char-t használni a tömbhöz, lehet unsigned char-t is, igaz, így egy halom standard könyvtári függvénynél kell majd castolgatni, mert ők a sima char-t szeretik,
- ha elég egy standard karakterkészlet tartalma, akkor hasznos dolog 8-bites karakterkészleteket használni (pl. ISO8859-x), ha több (sok) karakterkészletet kell tudni támogatni, ad abszurdum távol-keleti karakterkészleteket is kell, akkor marad az UTF-8, aminek persze ára van: más standard könyvtári függvényeket kell használni (ha nincs, akkor még kell is varázsolni), csomó művelet lassabb lesz, nem lehet triviálisan tudni előre, hogy hány karaktert tartalmaz egy byte-halmaz.

A latin2 ugyan úgy 1 byte-on tárol. Az hogy a buffered char-ként van definiálva attól még 8 bites (és nem hét), tehát abba a 160-at betárolni minden gond nélkül bele lehet.



Ha te innentől úgy kezeled, hogy char-ként adod át, de a font táblában mielőtt indexét feloldod (unsigned char) vagy (unsigned char *) típuskényszerítést alkalmazol, akkor semmi gondod nem lesz.

A char és unsigned char között semmi különbség nincs tárolás szempontjából, kizárólag műveletvégzéskor van közte különbség. Arra meg figyelj.

Szerk: Ha meg a fordítód háklis rá, akkor meg escape szekvenciával add meg valamilyen formában:

Az még hozzátartozik a dologhoz, hogy a char nem feltétlenül signed. Pl. nekem a linux-os 4.5.2 arm-eabi-gcc-n a char az alapból unsigned. Amúgy meg -funsigned-char, és garantáltan unsigned lesz a char.

Köszönöm mindenkinek, a kiokosítást, így mostmár értem, és nem is tűnik olyan veszélyesnek.
Könyvtári függvényből csak a legáltalánosabbakat használom, ott meg figyelek a cast-olásra.

Topi: Ez az escape szekvenciás beadás eszembe sem jutott köszi!.

Sziasztok!
HY35A 3.5" TFT SSD1963-as vezérlővel, STM32F407 Discovery portján 8-bites módban szeretném hajtani (PORTE majdnem üres). Sok túrás után menni is látszik a dolog, de nincs piros szín. Init után a RAMban lévő szemétben sincs piros. Viszont tudok olyan adatot adni neki, amitől leáll a kijelző, kifehéredik.
Már átnyálaztam a fél NETet, másnak is vannak hasonló gondjai, de azt írták, hogy biztosan felcserélte a kijelző lábait...(persze...). Abban kérnék segítséget, hogy ha valaki vésett 8-bites meghajtást 320x240-es SSD-s TFT-hez Discoveryre, egy egyszerű tesztprogramot megosztaná velem (hogy kiderüljön, én vagyok a sülthal vagy a kijelző). Nyelv mindegy.
Előre is köszönöm a segítséget!
JAni

0xF0 regisztert "Set Pixel Data Interface" állítod?

Igen, 00=> 8 bit. Már megpróbáltam 16/24-bites LCD meghajtást is, akkor sincs piros. Ahogy a kép alján látszik a bekapcs szemétben sincs. A fentmaradó biteket a csatlakozón tényleg lehúzza az SSD testre, tehát ott sincs keresgélnivalóm. Ami érdekes, hogy a 0x3A parancs az újabb pdf-ben "reserved" lett, 1-2 INIT forrásban még láttam használni. Tehát ez már mindig csak 6-6-6 bitesen adja az LCD felé...lehet, erről az LCD nem tud??? 36-38 vezeték megy az LCDre...lehet, vissza kell rajzolnom...Brrrr.
T350MTQN a TFT típusa, most az után turkálok, max rámérek szkóppal direktbe, de mondjuk ha nincs REDdata, akkor is megette a fene, mert az SSD hajtja, ott kellene még okosodni.
JAni

Mellékelek egy demo kódot, hátha segít.

A PIC-ből kezdek kiszeretni...Hi-Tech C hibás fordításai kezdenek idegesíteni...ICD2 állandóan elszáll...drága....stb. Újítani kellene.
Gyúr valaki Nuvoton procit ?
ChaipCad-nál olcsón gyorsan beszerezhetők, széles választékban és elég jól összefogottan dokumentált.
BSP Lib kicsit le van maradna a CMSIS csak 1.3...gondolom ez nem nagy gond.
Először az STM Discovery-t nézegettem, de ez induláshoz emészthetőbbnek tűnik.
Tapasztalatok ? Tanácsok ?
Köszi.....

Köszönöm, átnézem!
Előbb most szétkapom a kijelzőt és megnézem, egyáltalán kaphat-e RED adatot.
Kipróbáltam 16-bites adatbusszal és tapizásra változott a kép, tehát normálisan bekapja az adatokat, csak kifelé nem megy RED, de ez ma kiderül. Sajnos benne van az is, hogy hibás a kijelző és a környezetemben nincs olyan, akinél tesztelhetném.
JAni