Hoi,

Vorab: Ich möchte jetzt hier keine vorhandene Bibliothek als schlecht
bezeichnen, aber das, was ich hier (und bei avrfreaks) gefunden habe,
hat mich nicht zufriedengestellt.
Mal wurde zum Beispiel beim String-write oder beim Bild-voll-schreiben
kein AutoWrite des T6963c Modus benutzt, der das ganze um das doppelte
beschleunigt. Dann waren nicht alle Funktionen eingebaut. Mal waren
sogar Sachen fehlerhaft implementiert (Wobei ich bei mir auch nicht den
Anspruch an komplett fehlerfreier Implementierung habe). Oder der Code
einfach nur dermaßen schlecht strukturiert.

Ich hab daraufhin eine eigene Low-Level Bibliothek gebaut. Also ohne
höherliegende Zeichenfunktionen (Rechtecke, Kreise...). Sondern nur die
eingebauten Zeichenfunktionen (SetPixel zum Beispiel).

Noch ein paar Bemerkungen dazu:
main.c ist ein einfaches Sample, dass die Funktion der Library zeigt.
T6963c.c / T6963c.h sind die Library Dateien, wobei die Header-Datei per
#include eingebunden und die .c Datei einzeln kompiliert wird.
Die Dateien "SamplePic.h" udn "CustomChars.h" gehören ebenfalls zum
Sample und definieren ein (von mir geschossenes ;)) Beispiel-bild und
ein Custom-Char.

Innerhalb der Lib sind die Basisfunktionen (Einfaches Byte-Schreiben und
Byte-lesen) als Inline ausgeführt, was die Library relativ groß macht
(Dadurch aber auch schneller). Wer das nicht möchte, weil er wenig Flash
zur Verfügung hat, kann das Attribut, sowie das "static inline" bei den
Funktionen entfernen.

Die Warteschleifen sind für 20MHz ausgelegt (Mega644) und durch 1-3 nops
realisiert. Unter langsameren Prozessoren kann man diese teilweise, oder
ganz 'rausschmeißen, wenn man noch etwas an Speed herausholen will.
(_delay_us(.0XX) hat sich hier leider als schlecht erwiesen, weil dieser
immer mindestens ein paar Taktzyklen für seinen eigenen Aufbau verheizt,
sodass ich quasi viel zu lange warte).

Die Pinbelegung kann in der Header Datei angepasst werden, wobei aber
Alle DatenPins an einem Port liegen müssen, sowie alle Controlports an
einem Port.

Die Adressen des T6963c Speichermappings können ebenfalls angegeben
werden. (CGRAM-Adresse lässt sich nicht komplett frei verschieben!).

Manche "Funktionen" sind noch als Makro ausgeführt, da diese nur eine
Kombination aus 2 vorhandenen "echten" Funktionen darstellen.

Im Ordner "CharGen" habe ich eine einfache Exceltabelle beigelegt, womit
man sich Zeichen zusammenklicken kann.

Um Grafiken wie das Beispiel-Bild in C umzuwandeln, kann man das Tool
"bmp2c" von Holger Klabunde benutzen. Klappt sehr gut (google!)

Dann mal Viel Spaß damit, und nicht das Feedback vergessen ;) ;)

PS: Bei mir läuft die Library mit einem 240x128 T6963c an einem Mega644
mit 20MHz Takt. Sollte aber ohne Probleme auch mit anderen
Größen/Mikrocontrollern funktionieren.

Hmmmm, memory mapped für einen Mega162 oder größer hast Du nicht auch
zufällig?
Das bräuchte ich nämlich...

Nope, memory mapped habe ich nichts da. Finde ich eher umständlich, da
man noch diverse Dekodierer braucht um über die Adressen die
Schreib/Lese/CodeData Pins anzusteuern. Und sooo viel schneller wirds
dadurch nicht. (Ich bin ja mit 20MHz schon schneller als der T6963c).
Der einzige Vorteil wäre nur, dass der Mikrocontroller sich im
Hintergrund um das Ausgeben des Bytes kümmert.

Naja, muss man jetzt abwägen ;)

Ich hab das ganze jetzt auch mit Bildern auf meiner Homepage:
http://klinkerstein.m-faq.de/index.php?content=T69...

Ich hab noch ein paar nebensächliche Sachen ausgemerzt, und außerdem ein
#define für's Inlining der Core-Funktionen eingefügt (T6963c.c).
Die aktuellste Version gibts immer auf meiner Homepage.
Bei avrfreaks zeigt ein Projekt immer auf meinen Webspace:
http://www.avrfreaks.net/index.php?module=Freaks%2...
Der link direkt zu meinem Webspace (Wo auch Bilder zu finden sind) ist:
http://klinkerstein.m-faq.de/index.php?content=T69...


Wenn fragen sind, so schreibe man mir einfach eine E-Mail ;)

PS: Ich reichte eventuell demnächst Grafikfunktionen nach.

Entschuldigt mich wenn ich störe, aber ich verwende zurzeit ein DMF5001
Optrex Panel, welches den Pin HALT scheinbar vom T6963c Kontrollerchip
nach aussen geführt hat. Dieses Panel bekomme ich einfach nicht zu
laufen. Aus anderen Berichten entnahm ich, das dieser Pin dauerhaft auf
einen High-Pegel zu setzen ist. Dies würde aber laut T6963C Spec doch
eher unwahrscheinlich sein. Ich wollte daher fragen, wie dieser Pin im
Code zu verwalten wäre. Das Display hat ausserdem eine 160x128
Auflösung, welche nicht gerade dem "Standard" (128x64, 240x128 usw.)
entspricht.
Die Versorgung des Panel ist in Ordnung und überprüft, blos bekomme ich
selbst mit dem HALT Pin auf High-Pegel gesetzt nicht einen anständigen
Wert (egal ob Bild oder Text) angezeigt. Ich hoffe, dass ich euch mit
diesen Fragen nicht allzu belaste, wäre aber um Lösungsvorschläge jedoch
sehr dankbar. Hatte leider selbst mit anderen T6963c Libs keine
Besserung des Zustandes. Zurzeit verwende ich einen ATMega16 mit
internem 8Mhz Takt.

Hallo,

ich versuche gerade eine kleine Grafik von 32*32 Pixel und Small-Font
"mitten ins Display" zu stellen.

Dabei ergibt sich das Bild im Anhang. Was rot eingekreist ist ist ok und
gewollt, ansonsten sollte nur eine art Sonne zu sehen sein wie links
oben mit ins Bild kopiert wurde.

Der Code hierfür ist (die in dem Thread genutzte Bibliothek benutzund
der hier:

const uint8_t g_Sonne[] = { 0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x08,0x07,0x00,0x20,0x00,0x00,0x0C,0x07,0x01,0x20,0x00,0x00,0x06,0x07,0x03,0x00,0x00,0x00,0x07,0x07,0x07,0x00,0x00,0x00,0x07,0x2F,0x2F,0x00,0x00,0x00,0x07,0x3F,0x3F,0x00,0x00,0x0C,0x03,0x3F,0x3E,0x01,0x20,0x07,0x33,0x3F,0x3E,0x1F,0x00,0x03,0x3F,0x3F,0x3F,0x3E,0x00,0x01,0x3F,0x3F,0x3F,0x3C,0x00,0x00,0x3F,0x3F,0x3F,0x38,0x00,0x00,0x1F,0x3F,0x3F,0x30,0x00,0x00,0x3F,0x3F,0x3F,0x38,0x00,0x0F,0x3F,0x3F,0x3F,0x3F,0x20,0x3F,0x3F,0x3F,0x3F,0x3F,0x30,0x0F,0x3F,0x3F,0x3F,0x3F,0x20,0x00,0x3F,0x3F,0x3F,0x38,0x00,0x00,0x1F,0x3F,0x3F,0x30,0x00,0x00,0x3F,0x3F,0x3F,0x38,0x00,0x01,0x3F,0x3F,0x3F,0x3C,0x00,0x03,0x3F,0x3F,0x3F,0x3E,0x00,0x07,0x33,0x3F,0x3E,0x1F,0x00,0x0C,0x03,0x3F,0x3E,0x01,0x20,0x00,0x07,0x3F,0x3F,0x00,0x00,0x00,0x07,0x2F,0x2F,0x00,0x00,0x00,0x07,0x07,0x07,0x00,0x00,0x00,0x06,0x07,0x03,0x00,0x00,0x00,0x0C,0x07,0x01,0x20,0x00,0x00,0x08,0x07,0x00,0x20,0x00,0x00,0x00,0x02,0x00,0x00,0x00 };

uint8_t i;
uint8_t j;

for(j=0; j<32; j++)
{
  for(i=0; i<6; i++)
  {
    T6963cWriteChunkAt_P(T6963C_ADDR_GRAPHIC+10+(40*j)+i, &g_Sonne[(j*6)+i], 1);
  }
}

Irgendwas muss ich doch falsch machen wenn da sowas komisches bei raus
kommt.

Kann viele Ursachen haben.
Gib mal mehr Details.
Welche Auflösung, was für ein Display, welche Zeichensatzgröße?
Insbesondere, wenn die Displayroutinen nicht auf jede mögliche
Zeichensatzgröße (5x8, 6x8, 7x8, 8x8) ausgelegt sind, kommen solche
Artefakte zustande.

- 240x64 Pixel Display
- 6x8 Small Font (auch passend deklariert)
- Bilder (fullscreen) sind fehlerfrei

Da die Editierfunktion leider nicht ging...

Hab die Grafik mit dem FastLCD gemacht und passend exportiert. Leider
scheint das Programm die Pixel falsch zu berechnen. Mit dem BMP2C vom
Klabunde ging es jetzt :) Interessanterweise ist jetzt auch der
Datenmüll im unteren Bild weg :D