T6963c und Custom-Chars / Characters

[Simon K. (simon)]

Moin,

Ich hätt da gern mal ein Problem ;)

Ich habe letztens hier im Forum ein 240*128 T6963c Display gekauft 
(Danke nochmal dafür!) und begonnen daran rumzubasteln und mir eine 
kleine C-Lib zu schreiben. (Das, was in der Codesammlung war hat mich 
nicht befriedigen können ;)).

Es lief auch eigentlich alles auf Anhieb. Teilweise sind zwar Sachen 
EXTREM schlecht dokumentiert (nicht nur im Datenblatt - auch im Rest des 
Internets). Als Beispiel das Auto Writing: Fast alle Quellen sagen, dass 
nach einem Auto-Write Command ein STA3 Bit-check gemacht werden muss. Es 
muss aber ein STA0/1 Check gemacht werden, was ich in einem 
verschlungenen Thread-Beitrag hier im Forum gefunden habe.

Nunja, jedenfalls geht es darum Custom Chars darzustellen. Ich setze per 
"SET OFFSET POINTER" den CGRAM Bereich des Chips auf 1800-1FFF:

  //Set CGRAM Address to 1800-1FFF
  T6963cPutData(3);
  T6963cPutData(0);
  T6963cPutCmd(T6963C_CMD_SETOFFSET);

Die Routinen funktionieren übrigens. Ich denke nicht, dass dort der 
Fehler liegt.

Anschließend lade ich an Adresse 1C00 (1800 + 80h*8 Weil Zeichen 0-7F 
aus dem internen CGROM kommen) die 8 Bytes meines Custom Chars.
Sieht in etwa so aus:

const uint8_t g_CustomChars[128*8] PROGMEM =
{
  0,  24,  28,  30,  30,  28,  24,  0,

};

  T6963cWriteChunkAt_P(T6963C_ADDR_CGRAMH, g_CustomChars, sizeof(g_CustomChars));

Mit dem gleichen Befehl fülle ich auch den Grafik-RAM (aus dem Flash). 
Hier kann der Hund also ebenfalls nicht begraben liegen.

Danach schreibe ich an die Text-Adresse einen Teststring. Normale 
Zeichen (Also diese, die an 0-7F liegen und aus dem internen CGROM 
kommen) klappen perfekt. Sobald ich aber Zeichen 80h ausgeben will kommt 
nicht mein Custom Char. Nein, es kommt auch kein zufälliges Bitmuster, 
weil eventuell der RAM-Write für das Zeichenmuster fehlgeschlagen ist. 
Nein, es kommt der entsprechende Extended ASCII Code 
(http://asciitable.com/).

Ç

Schreibe ich mal testweise andere Extended ASCII Codes, werden auch 
diese ausgegeben.

Jetzt die Frage: Ist etwas an meinem Vorgehen falsch? Was mich wundert 
ist, dass im T6963c garkein CG für Extended ASCII Codes vorhanden ist. 
Kann es sein, dass auf meinem Display irgendwo ein ROM in den 
Speicherbereich gemappt ist, wo extended ASCII Codes drinstehen? Dann 
könnte ich mir aber nicht erklären, warum die Zeichen ebenfalls korrekt 
angezeigt werden, wenn ich beim OFFSET-POINTER mal testweise einen 
anderen Speicherbereich einstelle.

Weiß jemand Rat? Das Display ist ein DG-24128-06

[Simon K. (simon)]

Ich habe mal die Library vervollständigt und auskommentiert.

Im Sample ("main.c") findet man dann in der Schleife wo 10 Zeilen 
ausgegeben werden auch die Ausgabe des ersten Customchars.

Stattdessen wird aber nicht das von mir designte Play-Symbol angezeigt 
sondern "Ç".

Vielleicht findet ja jemand etwas.

Vielen Dank im Voraus.

[pumpkin (Gast)]

Moin Simon,

mit Customs auf dem T6963 hab ich mich noch nicht befasst, aber mich 
wundert dass dein 'Ç' ja eigentlich im CG enthalten ist (0x60 beim type 
0101). Sicher dass du die richtigen Adressen setzt? Mir ist so als wenn 
man noch den Modus 'external ROM' einstellen kann/muss/sollte?


> Fast alle Quellen sagen, dass nach einem Auto-Write Command ein STA3
> Bit-check gemacht werden muss. Es muss aber ein STA0/1 Check gemacht
> werden, was ich in einem verschlungenen Thread-Beitrag hier im Forum
> gefunden habe.

Erst STA0/1, dann immer STA3. Klappt bei mir wunderbar.


> schlecht dokumentiert

Die Leute bei Toshiba haben sich da wirklich nicht mit Ruhm bekleckert.


pumpkin

[Simon K. (simon)]

pumpkin wrote:
> Moin Simon,
>
> mit Customs auf dem T6963 hab ich mich noch nicht befasst, aber mich
> wundert dass dein 'Ç' ja eigentlich im CG enthalten ist (0x60 beim type
> 0101). Sicher dass du die richtigen Adressen setzt? Mir ist so als wenn
> man noch den Modus 'external ROM' einstellen kann/muss/sollte?

AAarrrrggghhh. Das ist es.

>
>> Fast alle Quellen sagen, dass nach einem Auto-Write Command ein STA3
>> Bit-check gemacht werden muss. Es muss aber ein STA0/1 Check gemacht
>> werden, was ich in einem verschlungenen Thread-Beitrag hier im Forum
>> gefunden habe.
>
> Erst STA0/1, dann immer STA3. Klappt bei mir wunderbar.

Jau, sag ich doch. Leider steht das aber so nicht im Datenblatt.

>> schlecht dokumentiert
>
> Die Leute bei Toshiba haben sich da wirklich nicht mit Ruhm bekleckert.

In der Tat nicht.

Okay, das Problem ist ziemlich ärgerlich: Das "normale" ASCII Charset 
ist um 0x20 nach unten verschoben. In meiner PutChar/PutString Funktion 
ziehe ich deshalb 0x20 vom übergebenen Zeichen ab. Leider ist das aber 
völliger Mumpitz, wenn ich ein CustomChar ausgeben will. Das ist 
natürlich nicht irgendwie verschoben.

Sprich: Wenn ich \x80 angegeben hab, hat er 0x60 draus gemacht. Hier 
liegt natürlich kein Customchar.

KLATSCH

Also erst prüfen ob das übergebene Zeichen < 0x80 ist. Wenn ja: 0x20 
abziehen. Ansonsten nicht.

PS: Warum fall ich eigentlich immer wieder auf meine eigene Aussage 
rein? "Hier kann der Fehler nicht liegen. Funktioniert ja problemlos in 
anderen Situationen". Und genau dort liegt dann der Fehler :|

[pumpkin (Gast)]

Wie einfach das Leben sein kann  ;^)


> Leider steht das aber so nicht im Datenblatt.

T6963C Datenblatt, 1998-10-20 Seite 21/46 Figure (b).


> Also erst prüfen ob das übergebene Zeichen < 0x80 ist. Wenn ja: 0x20
> abziehen. Ansonsten nicht.

Klingt etwas unelegant, mach dir doch für Customs eine neue Funktion. 
Bei ASCII's arbeitest du scheinbar mit der Symbolik (also nicht mit den 
nativen Werten) aber bei Customs willst du plötzlich die nativen 
hex-Werte. Etwas inkonsistent  ;^)


pumpkin

[Simon K. (simon)]

pumpkin wrote:
> Wie einfach das Leben sein kann  ;^)
>
>
>> Leider steht das aber so nicht im Datenblatt.
>
> T6963C Datenblatt, 1998-10-20 Seite 21/46 Figure (b).

Jup, genau da steht's nämlich falsch:
- Address-Pointer-Set
- STA0,1 abwarten
- Auto Write aktivieren
- STA3 abwarten
- Daten Schreiben
- STA3 abwarten
- Auto Write Reset

Nach dem Auto-Write muss man aber STA0,1 abwarten, bevor man anfängt 
Daten zu schreiben.

>
>> Also erst prüfen ob das übergebene Zeichen < 0x80 ist. Wenn ja: 0x20
>> abziehen. Ansonsten nicht.
>
> Klingt etwas unelegant, mach dir doch für Customs eine neue Funktion.
> Bei ASCII's arbeitest du scheinbar mit der Symbolik (also nicht mit den
> nativen Werten) aber bei Customs willst du plötzlich die nativen
> hex-Werte. Etwas inkonsistent  ;^)

Jup, aber das ist reiner Komfort: Wenn ich eine Zeichenkette mit Custom 
Chars schreiben will (Also die Custom Chars nicht einzeln schreiben 
möchte), dann möchte ich das mit zum Beispiel "Test \x80" machen. Geht 
aber dann nicht mehr.