T6963C kijelző és a CGRAM?

Hogyha sikeresen O/PLED illetve hagyományos alfanumerikus - esetleg tán grafikus kijelzővel gyűlik meg a baja valakinek:)
Avatar
cassis
DrótVégénSzéndarab
Hozzászólások: 16
Csatlakozott: 2012. február 5. vasárnap, 7:00

Hozzászólás Szerző: cassis »

Nekem továbbra is nagyon zavaros a kijelző néhány regiszterének beállítása. (vezérlő: T6963)
Single Scan módban (már azt sem tudom ezt hogyan lehetne átállítani dual scan -ra ) :( a memóriafelosztás az adatlap szerint következő.
Text Area: 0x0000 - 0x7FFF
Graphic Area: x8000 - 0xF7FF
CG RAM Area: 0xF800 - 0xFFFF

Dual Scan -ban más, de az most nem érdekes. (Egyáltalán mire jó a dual Scan üzemmód?) :cry:

Az alábbi regiszterekkel a Text / Graphic területeket lehet konfigurálni:
Set Text Home Address: indicates the leftmost and uppermost position.
Set Text Area: adjust the columns of the display.
Set Graphic Home Address: indicates the leftmost and uppermost position.
Set Graphic Area: adjust the columns of the graphic display.

Amikor karaktereket 0x0000 tól kezdem írni a VRAM ba, azok rendere meg is jelennek. Mikor a 0x8000 ra állított Address Pointer után írni kezdek a Graphic területre (OR mode, Graphic display on) ráír a text sorra. Ugyan a "Set Graphic Home" megadja azt a memoriabeli címet, ami a bal felső pozícióba kerül, de mit tegyek, ha pl. a 20. sorba akarok rajzolni?
Mellesleg, a graphic területre írt byte -ból csak az első jelenik meg helyesen (a 8*8 kockából a felső sorban), a következő írás hatása a következő karakterhelyen jelentkezik a mintázat (megint csak a felső sorban), de ott már nem a beírt bitminta látható. :cry:
Egyébként azt vártam volna, hogy a következő címre írt byte a 8*8 as mátrix következő sorában fog megjelenni és így tovább teljesen feltöltve a 8 sort, csak utána lép tovább a másik 8*8 as mátrixpontra.
Mivel "OR" módban vagyok az sem világos miért törlődik a karakter, és helyette csak a graphic adat látszik. :cry:
A hozzászólást 1 alkalommal szerkesztették, utoljára cassis 2012. április 4. szerda, 18:16-kor.
Avatar
winnerbt
Elektronbűvölő
Hozzászólások: 907
Csatlakozott: 2007. március 25. vasárnap, 6:00

Hozzászólás Szerző: winnerbt »

Csak szólok, hogy nagyon ajánlott az adatbusszal sorbakötni mondjuk 100ohm-okat. Ugyan is pl. M128-nál ISP felprogramozáskor a PORT-ok valamit kiadnak, nálam szerencsétlen esetben pont LCD olvasás<=>PORT kimenet előfordul, a felvett áram növekedéséből jöttem rá, hogy keresztbeköszönnek.
- A sebességgondnál akkor pakolhatod be a NOP-okat, bár nekem eddig nem volt gondom, igaz itthon csak T6963C-s vezérlőjű LCD-k vannak. Ezt az RA-t ki kellene már próbálnom :)
-
Single scan: egyszerre, fentről lefelé beviszi az összes sort
Dual scan: Felső sor + a középső sor megy be, az alsó/felső sort egyszerre viszi be (nagyobb kijelzőknél van értelme, hogy ne ...mondjuk 1/128-ad legyen a kitöltési tényező
-
"ráír a text sorra."
Az a dolga. A TEXT layer és a Grafikus layer "egymás felett" van. Gyakorlatilag, mint ha fóliára írnál. A két layer egymáshozrendelését tudod beállítani, pl EXOR-nál egy fekete nyégyzet inverzre változtatja az alatta lévő TEXT-et.
"következő írás hatása a következő karakterhelyen jelentkezik"
Most hirtelen nem tudom, de akkor a bytekiosztás ott vízszintes.
Kétféle létezik, az egyiknél vízszintesen vannak a byte-ok egy sorban, a másiknál függőlegesen áll a beírt byte, de ott is balról jobbra halad.
Ha nem a beírt bitminta látszik:
1. nem megfelelő a logikai karakterméret, 8-bites mintát akarsz betenni 6-bites helyre (2 bit nem fog látszani)
2. A másik layer-en van valami és az egymáshozrendelés miatt más az eredmény.
Ha grafikus layeren dolgozol, kapcsold ki a TEXT layert, akkor annak kell látszania, amit bevittél.
A memóriakiosztás szokott vicceskedni, hogy van olyan, amin csak 8K RAM van (vagy32K) és érdekesen vannak kidekódolva.
Mi a típusa a Te kijelződnek?
JAni
Avatar
cassis
DrótVégénSzéndarab
Hozzászólások: 16
Csatlakozott: 2012. február 5. vasárnap, 7:00

Hozzászólás Szerző: cassis »

Köszi a választ!
A kijelző típusa: JM240128A
Datasheet: http://www.jm.pl/karty/240128A.pdf
Igazad van, tehettem volna 100 ohm -okat a buszba, de annak ellenére hogy eleinte még terveztem, a panelgyártásnál már elfelejtettem őket. :cry: Mindenesetre hiányuk jelenleg nem zavarja a tesztet. (Remélem)
Kikapcsoltam a szöveges felületet, most a bitminták a program byte -oknak megfelelően jelennek meg (tehát a byte kiosztás vízszintes). A logikai karakterméretre figyeltem, az rendben: FS=0 ra állítva, vagyis 8 bites.
Kiküldtem 5 byte ot: szépen ott is vannak egy sorban, azonban kis kihagyás után néhány pixel - az első sorban látszólag random módon kb. a képernyő feléig - még kirajzolódik. Hát ez mitől lehet?
Megcsináltam a kiolvasást is a VRAM ból, majd soros porton kiküldtem a PC be. Érdekes módon minden byte rendben kiovasható, egyezik is a bevittel; ha tovább olvasok akkor csupa 0x00 -t látok a VRAM ban. Mégis ott az említett pixelsor. :cry:

Még két dolgot ismét megkérdeznék, mert nem nagyon világos:

1. Értve a fóliás hasonlatot, de közelebbről hogyan kell elképzelni a két layert egymásfölöttiségét. Én úgy gondolom, hogy ugyan egymás felett vannak, de pixelek között a programozható OR/EXOR/AND teremt kapcsolatot. Tehát a logikának megfelelően fog az adott pont világítani vagy marad sötét. (Az még nem világos miként lehet praktikusan használni ezt megoldást, feltéve ha egyszerre mindkét layer be van kapcsolva és nincs fix helye ábrának - szövegnek)
2. A Single/Dual Scan esetén mit értettél "beviszi az összes sort" + "középső sor megy be" alatt? Mivel az én kijelzőm nagy méretű, valószínűleg nekem is érdekes lesz a dolog. Ennek be/ki kapcsolását hol lehet állítani?
Avatar
winnerbt
Elektronbűvölő
Hozzászólások: 907
Csatlakozott: 2007. március 25. vasárnap, 6:00

Hozzászólás Szerző: winnerbt »

Szia! Ilyenem persze pont nincs itthon, JM16L van (kék-fehér-CCFL).
Az, hogy megjelenik a bevitt pixel másutt is, tuttira memória konfigurálási gond (vagy címzárlat a RAMnál).
1. A layerkezelés aránylag egyszerű a T6963-nál, SED133x-nél 5x bonyolultabb. A terítő logika kiolvassa a karakterkép 1 sorát, majd elmegy a grafikus layer 1. bytehoz, beolvassa, elvégzi a kért logikai műveletet és beteszi a sorpufferbe (majd ez viszi ki az LCD meghajtó regisztereknek). természetesen szinkron logika az egész. Az OR akkor jó, amikor egy grafikát akarsz rátenni szövegre vagy (nivel van CGRAM) egy másik grafikára. Tipikus pl. egy "jelalakot a raszterra" vagy műszerre a mutató. EXOR általában inverzre-váltásra használják, az AND-ot meg maszkolásra.
2. A scan-módok kötöttek, Te nem tudod csak úgy büntetlenül bizergálni. Az alap az, hogy Te a kijelzőt egy kontrolleren keresztül látod, de nagy többségben ez a kontroller hiányzik (sajnos manapság egyre többről). Magát az üveget 2db shiftregiszter (általában 64 vagy 80bites) hajtja. A folyamat multiplex meghajtású, tahát berotálunk az X-reg-be egy sort, megjelenik, rotáljuk a következő sort, utána az Y-reg-et (amiben 1 bit van csak 1-ben) léptetjük. A single-scan működik így.
Dual-scannél is kétféle megoldás van.
a.: az első sor regiszter kimenete a 64-ik sor bemenetére kerül (y=128-as LCD-nél), vagy elölről, vagy hátulról, így 1 sor kivitele igazából 2 sor adatait tartalmazza (0 és 64).
b.: A pixel órajel felfutó élénél a 0-ik sor regisztere lép, lefutónál a 64-ik, így 1 órajel alatt a buszról 2 sor adatainak pixele tud bevándorolni.
De Te ezt nem tudod befolyásolni, mert a gyártó az üveg meghajtókat így madzagolta össze. (na, jó, lehet darabolni meg kötözgetni).
Dual-scan-es LCD-ket csak nagyon nagyoknál láttam, mert a vezérlők azért HW-ből nagyon tudják ám nyomni az adatokat.
(512x240-es már dual-scan-es)
Találtam itt egy 8K memóriás 240x128-as CGRAM feltöltést, majd hátha tudod használni. Ez biztos működik, élő cuccból ollóztam:

Kód: Egész kijelölése

Cgram2:                                                     'Nagy szßmok felt÷ltÚse

$asm
  push r24

 ldi r24,&H81                                               ' exor+external CGRAM
  !call _GWrite_Cmd

  ldi r24,&H3                                               '2000h-21ffh  CGRAM  
  !call _GWrite_Data
  clr r24
  !call _GWrite_Data
  ldi r24,&H22                                              ' OFFSET regiszter irasa
  !call _GWrite_Cmd


  ldi r24,&H0
  !call _GWrite_Data
  ldi r24,&H1c                                              '1400h a CGRAM eleje
  !call _GWrite_Data
  ldi r24,&H24                                              ' cursor reg irasa
  !call _GWrite_Cmd

  pop r24
$end Asm

Restore Cgram_data4                                         'BIGNUM pixeladatok
For Cgct = 1 To 424                                         '10x4x8 + 4x8 +4x8 +4x8
Read Beda 'adat valahonnan
$asm
  push r24
  lds r24,{beda}
 !call _GWrite_Data
  ldi r24,&Hc0                                              ' write + inc ADP
 !call _GWrite_Cmd
  pop r24
$end Asm
Next Cgct
Return
Szerintem ott van a kutya elásva, hogy a Bascom nem minden méretű kijelzőt konfigol fel jól. Erre tipikus, hogy az egy sorba jutó karakterek számításánál csonkol, tehát 6-bites karakter esetén egy x=240-es kijelzőnél nem tudsz a grafikus layerre a jobb utolsó oszlopba rajzolni...meg ilyenek, én a saját konfigot ajánlom.
JAni
Avatar
cassis
DrótVégénSzéndarab
Hozzászólások: 16
Csatlakozott: 2012. február 5. vasárnap, 7:00

Hozzászólás Szerző: cassis »

Köszi a választ, világos a dolog. A Single/Dual Scan bemutatását feltették ugyan a doksiba, de sok értelme nem volt ezekszerint.
A layerek kezelése is ok, ha működik a panel gyakorlatban is egyértelmű lesz.
Valóban memóriakezelési gondom lehet, zárlat elvileg nincs azt már kimértem, de még utánnanézek a dolognak.
Azt be kell ismernem, hogy a vezérlőm PIC alapú, de azért kérdeztem itt, mert láttam, hogy a fórum jobban pörög nálatok ebben a témában.
Avatar
winnerbt
Elektronbűvölő
Hozzászólások: 907
Csatlakozott: 2007. március 25. vasárnap, 6:00

Hozzászólás Szerző: winnerbt »

Azért van a scan a doksiban, mert a vezérlő tudja, de hogy ki-mit épít köré LCD meghajtókból, az már rajta múlik. Van olyan LCD-m, aminél az első 7 oszlop a sor végén van, tehát elcsúsztatták 7-el. Szabadni-szabad, de minek ugye, csak vakargatja az ember a fejét. (merci műszerfal pl.)
Szóval lehet, nálad a RAM többször látszik és elkeveredtek a címek, szóval erre rá kell jönni, mondjuk 0-tól teleírod 100db 1-255-el, és nézed, hol jelenik meg karakter illetve pixel, szóval lehet játszani.
A CGRAM túrás úgy megy, hogy kiírsz 0-255 karaktereket, aztán felülre írod az 55-AA-kat, és amikor kezdenek megváltozni a karakterek, akkor jó címen vagy.
JAni
Avatar
cassis
DrótVégénSzéndarab
Hozzászólások: 16
Csatlakozott: 2012. február 5. vasárnap, 7:00

Hozzászólás Szerző: cassis »

Sajnos az ünnepek miatt kicsit háttérbe került a GLCD projekt. :cry:
Most belenéztem a memóriába, és tényleg 2X látszik a RAM.

Alap beállítások:
Text Home Address: 0x0800
Graphic Home Address: 0x0000

Ezután Address pointer Set = 0x0000 állítás után kiküldök 5 darab (grafikus) 0xCC -t, majd egy Address Pointer Set = 0x0800 állítás után két sornyi karaktert.
Amikor visszaolvasom a VRAM -ból szépen látni is 0x0000 -tól az 5 darab 0xCC -t , majd a 0x0800 -tól a 60 darab karakterkódot. :lol:
Tovább olvasva a VRAM -ot mindez ismét megjelenik 0x8000 címtől kezdve (fix 0x8000 eltolással). :cry: Persze ezzel rendesen el is romlik a kijelző képe. (mellesleg nemtudom miért látszik egyáltalán, mivel 0x8000 címmel van feljebb. Ez pedig már eléggé nagy, hogy az ott lévő adat ne férjen rá a képernyőre.)
Mit lehet a RAM duplikálás ügyében tenni?
Minden írás után törölni kellene a "felső" RAM -ban megjelenő klónt? Ez nem tűnik korrekt megoldásnak.

És amit még nem értek az az Offset register szerepe. Vele a CGRAM elejét- végét lehet állítani a VRAM ban. Mi értelme van ezt állítgatni? Így még arra is figyelni is kell, hogy ne lógjon bele a grafikus - text RAM területre.
Avatar
winnerbt
Elektronbűvölő
Hozzászólások: 907
Csatlakozott: 2007. március 25. vasárnap, 6:00

Hozzászólás Szerző: winnerbt »

a pdf-ből nem derül ki, mennyi RAM van rajta. Nézd már meg, hogy 8K vagy 32K van (több nem szokott).
Ha a max 32K rajta van, az ugyebár lazán 0000h és 8000h-nál ugyanúgy látszik.
JAni
Avatar
kapu48
Elektronbűvölő
Hozzászólások: 3375
Csatlakozott: 2008. augusztus 29. péntek, 6:00

Hozzászólás Szerző: kapu48 »

Az enyémen az gyári ajánlás:

Kód: Egész kijelölése

• T6963C RAM Interface 
A külső RAM tárol adatokat kijelző (szöveg, grafika és külső CG adatok). Meg lehet szabadon kiosztott memória területet (8 Kbyte max).

ajánlása:
                Cím H			 Cím Dec		     Méret:
TEXT RAM  	  0000H – 0BFFH	0 – 3071		   3072 Bytes
Graphic RAM 	0C00H – 17FFH	3072 – 6113		3072 Bytes
CG RAM 		  1800H – 2000H	6114 – 8191		2048 Bytes
Ha elkezdek számolni!
240*128/8=3840 Byte kellene 2 *
Ami nem fér bele a fenti 8Kbyte ajánlásba!


Viszont még nem tudom valóságban ezt, hogyan szervezik a Bascom lib-ben?
Avatar
cassis
DrótVégénSzéndarab
Hozzászólások: 16
Csatlakozott: 2012. február 5. vasárnap, 7:00

Hozzászólás Szerző: cassis »

Sajnos a konkrét kijelzőmodulról nekem sincs több információm. Ezidáig a pl. itt fellelt adatlap szerint dolgoztam (ez is T6963 -as és 240X128 ):
http://www.lcd-module.com/eng/pdf/zubehoer/t6963.pdf
Itt a .pdf 6. oldalán lévő blokkséma szerint a modulon 8 K RAM -van. Ez szinkronban is van az adatlap 20. oldalán lévő single screen RAM mérettel.
A 22. oldal szerint pedig a dual scan összaeállításban két 4K ra bontják a RAM -ot.
Ha az enyémben 32K van, az azt jelenti, hogy az utolsó cím 0x7FFF lenne.
Felette is tudok olvasni, ami akár a RAM körbefordulását is jelenthetné (elfogyó címbusz miatt), de ebben az esetben miért zavarodik meg a kijelző?
Inkább arra gondolok, hogy a kijelzőm dual scan -os, és valamiért párhuzamosan írok az alsó fél képernyőre is. (talán ezért látszik a képernyőn is valami az alsó felén? - igaz az csak valami maszatféle)
A hozzászólást 6 alkalommal szerkesztették, utoljára cassis 2012. április 11. szerda, 16:56-kor.
Avatar
Robert
Elektronbűvölő
Hozzászólások: 10191
Csatlakozott: 2005. december 9. péntek, 7:00

Hozzászólás Szerző: Robert »

Hülye ötlet - abszolút a partszélről:
Beírsz a 0x0000-s címtől 5 byte-n át 0x55-t.
Elkezded kiolvasni. Ahol újra 0x55-t kapsz vissza, ott a RAM vége :) .
Avatar
cassis
DrótVégénSzéndarab
Hozzászólások: 16
Csatlakozott: 2012. február 5. vasárnap, 7:00

Hozzászólás Szerző: cassis »

Igen, ezen már túl vagyok. 0x8000 után tudom újra kiolvasni mindazt amit korábban beleírtam.
Avatar
Robert
Elektronbűvölő
Hozzászólások: 10191
Csatlakozott: 2005. december 9. péntek, 7:00

Hozzászólás Szerző: Robert »

Akkor a memóriád mérete: 32kbyte (vagyis itt olvasod vissza először)
De tipp 2: memória ír és visszaolvas, amíg azonosat kapsz vissza. És persze random számmal írni és a visszaolvasás ugyanaz a random szám kell lennie...
Így az esetleges címzési anomáliákat is kiejted.
Avatar
cassis
DrótVégénSzéndarab
Hozzászólások: 16
Csatlakozott: 2012. február 5. vasárnap, 7:00

Hozzászólás Szerző: cassis »

Közben rájöttem: a 0x8000 -tól való újraolvasás nem valami "hiba" következménye, hanem az elfogyó címbusz miatti 0x0000 tól való újraolvasást jelenti. :idea:
Azt gondolom eléggé körbejártam már ezt a kérdést: ugyan nem random számmal, hanem karakterrel + byte grafikával a neki megfelelő home address címtől bármit írtam be nekik, mindig a fenti eltolás jött ki (Előtte 0x00 val töltöttem fel a VRAM ot, lényegében volt egy clean).
RS232 porton csak azokat a címeket és a hozzá tartozó kiolvasott adatot küldöm ki, amelyik nem egyenlő nullával, így könnyen át tudom tekinteni a VRAM tartalmat. (ugyan vártam azt is, hogy amikor a CGROM -ot olvasom - legyez az beállítva bárhova is - nullától különböző értékeket kapok)
Mivel látom, hogy címzésileg oda írok, ahova akarok, végképp nem értem miért lesz a képernyőn nem megfelelő bitmintázat, maszatolás?

És még egy régebbi kérdés, amire kérnék választ:
És amit még nem értek az az Offset register szerepe. Vele a CGRAM elejét- végét lehet állítani a VRAM ban. Mi értelme van ezt állítgatni? Így még arra is figyelni is kell, hogy ne lógjon bele a grafikus - text RAM területre.
Avatar
kapu48
Elektronbűvölő
Hozzászólások: 3375
Csatlakozott: 2008. augusztus 29. péntek, 6:00

Hozzászólás Szerző: kapu48 »

A szemetelés oka lehet, ha nem tartod be az előző doksi 5.oldalán levő képen ajánlott minimális időzítéseket és jelváltás sorrendet.
Válasz küldése