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.
Datum:
Hmmmm, memory mapped für einen Mega162 oder größer hast Du nicht auch zufällig? Das bräuchte ich nämlich...
Autor:
Simon K.
(simon)
Datum:
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 ;)
Autor:
Simon K.
(simon)
Datum:
Ich hab das ganze jetzt auch mit Bildern auf meiner Homepage: http://klinkerstein.m-faq.de/index.php?content=T69...
Autor:
Simon K.
(simon)
Datum:
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.
Datum:
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.
Datum:
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.
Datum:
- 240x64 Pixel Display - 6x8 Small Font (auch passend deklariert) - Bilder (fullscreen) sind fehlerfrei
Datum:
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
Datum:
Hallo, Die Lib funktioniert bei mir leider nicht richtig, aber ich nehme an, dass der Fehler einen halben Meter vor dem Monitor sitzt. Zwar wird das LCD richtig initialisert und es kann auch Text dargestellt werden, aber der Text wird nicht klar dargestellt. Der Text wird praktisch zwei mal dargestellt, einmal "stark" und einmal in x-Richtung versetzt "schwach". Sobald ich den Stecker ziehe und dem ganzen den Strom wegnehme, wird der Text kurzzeitig so dargestellt, wie er sein sollte. Hier kurz die wichtigsten Codes:
int main(void) { //Initialize //OR mode, internal CG, Text and Graphic, Blinking Cursor T6963cInit( T6963C_MODE_OR | T6963C_CG_INTERNALROM, T6963C_TEXT_GRAPHIC | T6963C_CURSOR_BLINK ); T6963cPutStringXY(0, 0, "Dies ist eine doch sehr lange Reihe "); T6963cPutStringXY(1, 1, "Dies ist eine doch sehr lange Reihe "); T6963cPutStringXY(2, 2, "Dies ist eine doch sehr lange Reihe "); T6963cPutStringXY(3, 3, "Dies ist eine doch sehr lange Reihe "); T6963cPutStringXY(4, 4, "Dies ist eine doch sehr lange Reihe "); T6963cPutStringXY(5, 5, "Dies ist eine doch sehr lange Reihe "); T6963cPutStringXY(6, 6, "Dies ist eine doch sehr lange Reihe "); T6963cPutStringXY(7, 7, "Dies ist eine doch sehr lange Reihe "); while(1) { ; } return 0; } |
mit
//Physical Description #define T6963C_ADDR_CGRAML 0x1800 //Lower half of CG (Chars 00-7F) #define T6963C_ADDR_CGRAMH T6963C_ADDR_CGRAML + 0x80*8 //Higher half of CG (Chars 80-FF) #define T6963C_ADDR_GRAPHIC 0x0400 #define T6963C_ADDR_TEXT 0x0000 #define T6963C_TEXT_COLS 40 //40 bytes for 6x8 Font, 30 for 8x8 Font #define T6963C_TEXT_ROWS 8 #define T6963C_GRPH_COLS T6963C_TEXT_COLS #define T6963C_GRPH_ROWS 64 #define T6963C_FONTWIDTH 6 |
in der .h-Datei. Verwendet wird ein Atmega32 und ein GLCD mit 240x64 Pixeln. Mir ist klar, dass ich die 8 Funktionenaufrufe "geschickter" machen könnte, aber ich war irgendwie zu faul und C&P schien mir einfacher :D. Morgen wird ein Bild hinzugefügt. Zur Zeit sieht es wegen den Lichtverhältnissen nicht sehr gut aus für ein Bild :-). BTW: Wieso wird _GRAPH_COLS gleich _TEXT_COLS gesetzt?? Versteh ich ehrlich gesagt nicht, aber auch wenn ich _GRAPH_COLS auf 240 setze bessert sich nichts. Vielen Dank!
Datum:
Hallo, ich glaube, ich brauche Hilfe... Ich nutze die Libary mit einem Mega( und einem LMG7420 mit T6963. Ich habe es soweit, das ich Text da hinbekomme, wo er hin soll. Leider ist der Grafikbereich um ca. 1/4 nach Links verschoben(der Katzenkopf(im Original) ist einmal Links und dann wieder rechts im Display. Beim 8x8 Modus klappte das, aber wenn ich das Display auf 6x8 stelle, dann stehe ich vor diesem Problem. Nebenbei wird mein eigener Character(vorher der "play-pfeil" halbiert, die linke hälfte fehlt dann) Eine veränderung von #define T6963C_GRPH_COLS 30 nach #define T6963C_GRPH_COLS 40 hat nur wenig bewirkt, aber immerhin ist die Linie unten rechts im Display weg(die ist von meinem Rahmen den ich selbst gezeichnet habe). Scheinbar gibt es da ein Problem mit em Speicherzeiger o.ä. Hat da jemand ein ähnliches Problem und eine Lösung parat? Gruß Clyde
Datum:
@Clyde H. (clyde): Ich hatte das gleiche Problem. Manche Displays können den 6x8 Modus schlicht nicht, weil die intern entsprechend verdrahtet sind. Dazu gab's auch schon mal einen Beitrag: Beitrag "Re: Display mit T963C"
Datum:
Guten Morgen und danke für den Link. Leider half mir das nicht so ganz... Der Textmodus klappt bei mir einwandfrei, auch der Zeilenumbruch bei mehr als 40 Zeichen funktioniert ohne Pixelversatz. Nur der Grafikmodus ist versetzt, so wie in Deinem verlinkten Thread beschrieben. Habe ich was überlesen oder hängt es doch noch wo anders... Werde heute Abend mal die MD-Pins kontrollieren und gucken, wie die belegt sind. Gruß Clyde
Datum:
Habe mal geguckt, aber noch nicht gemessen... MD0 und 1 liegen auf Masse MD2 ebenfalls und MD3 scheint NC oder woanders angeschlossen zu sein(MD3 auf GND schliesse ich aus, weil dem Layout nach ein direkter kontakt möglich wäre.FS0 ist auch GND. Falls wichtig, es ist ein 4,91Mhz Quarz installiert sowie 2x LC7942 und 3x LC7940 evtl. hilft es. Gruß Clyde
Datum:
Hallo wieder, zur Info in eigener Sache... Den Grafikbereich habe ich immer noch nicht in Griff... Aber, das mit den eigenen Zeichen(CharGen) war mein Denkfehler, da im 6x8 Modus ja die ersten 2 Bits ignoriert werden und ich mein "Grad" Zeichen ganz links gesetzt habe, wurde die hälfte abgeschnitten (habe ja nur 4 Pixel in die Breite gezeichnet). Wenn ich eine Linie von 0-240(ich weiß, wären eigentlich 241 Pixel aber bei 239 ändert sich auch nix bewegendes am Grundproblem) zeichen lasse, dann sind die letzten 60 Pixel im Display leer. Wenn ich von 0-19 zeichnen lasse, fehlen rechts 7 Pixel... Irgendwie komisch, oder? Wer hat ähnliche Probleme? Gruß Clyde
Datum:
Ich will die Library keineswegs schlecht reden, aber mir hat es ungemein geholfen, als ich mich selbst mit den Routinen und dem Datenblatt vom Controller (T6963C) beschäftigt habe. Wie hast die die Home-Adresse vom Grafik und Text-Bereich definiert?
Datum:
Hallo, ich habe nichts weiter am Originalcode geändert ausser die Ports zur Ansteuerung, da ich ja nen Mega8 nutze und keinen 32er. Ich versuche mich auch da durch zu wuseln, aber die Operatoren und Bitverschiebungen sind mir noch ziemlich bömisch... Gruß Clyde
Datum:
Guten Morgen, es war mein Fehler Schande... Ich habe die Version hier im Thread genommen, mit der Version von Simon´s HP klappt es! Gruß Clyde
Autor:
Simon K.
(simon)
Datum:
Clyde H. wrote: > Guten Morgen, > > es war mein Fehler Schande... > Ich habe die Version hier im Thread genommen, mit der Version von > Simon´s HP klappt es! Gut zu wissen :-) Hab nur ratlos zuschauen müssen. Schade, dass ich in den ersten Beitrag keinen Link mehr zu meiner Seite hinzufügen kann. Wie auch immer: http://de.klinkerstein.m-faq.de/index.php/T6963c_Library
Datum:
Simon K. wrote:
> Gut zu wissen :-)
Das sagste wohl, vor allem weil ich immerwieder mal gucke, auch wegen
dem uWebServer :-)
Manchmal ist man sich selbst im weg, aber somit wird es für andere evtl.
direkt ersichtlich:-D
Datum:
Hallo Ich habe das Programm erfolgreich zum laufen gebracht. Nun möchte ich mehrere Bilder nacheinander anzeigen lassen. Das funzt auch soweit, nur muss ich dazu die #define T6963C_GRPH_COLS immer denm jeweilligem Bild anpassen. Nun wollte ich die T6963C_GRPH_COLS als Variable definieren, habe dazu in der T6963c.h extern uint8_t T6963C_GRPH_COLS eingebunden und inder main.c sie als Global initialisiert. Wenn ich hier den Wert gleich zuweise, funzt es. Wenn ich in der main, kurz bevor ich das Bild aufrufe, den Wert zuweise gehts nicht. Als wenn er die Variable in der main nich mehr kennt???? Gruss Frank
Datum:
Hallo, gäbe es eine Möglichkeit die Anzahl der verwendete PINS zu reduzieren. Momentan werden 13 für den T6963C benötigt. Wie könne man das reduzieren. Evtl. könnte man so ein Display auch per I2C ansteuern, aber ich denke dafür ist der I2C Bus zu langsam. Gruss, Stefan
Datum:
Du könntest alle Pins über Schiebregister ansteuern, das ginge dann mit 3 Pins für's Display. Macht die Sache aber nicht unwentlich langsamer. Gruß Fabian
Autor:
Simon K.
(simon)
Datum:
Naja, langsam oder "zu langsam" ist ja immer relativ. Wie schnell muss das Display denn geupdatet werden? Für 1 mal pro Sekunde reicht sowas dicke.
Datum:
Ich habe so ein Display an I2C angeschlossen. Bei 400kHz ist es doch sehr zäh, Textdarstellung ist ok. Mehr als 600kHz macht leider meine RTC nicht mit, liegt aber ja auch außerhalb der Spezifikation.
Datum:
Interessanter wäre darum die Pins des Displays an z.B. 595er Schieberegister zu hängen. Die kannste mit bis zu 20MHz befeuern. Da dürfte eher wieder das Display die Bremse werden. Die 20MHz schafft man natürlich mit nem AVR nimmer... Gruß Fabian
Datum:
Hallo zusammen, Versuche gerade die aktuellste Version der lib für ein 128x64 Display und Grafikausgabe umzubiegen. Ich scheine aber an der falschen Stelle anzusetzen. Die per BMP2C konvertierten Bilder werden falsch und auch nur bis zur vertikalen Hälfte angezeigt. Welche Werte in der t6963c.h müssen denn nun angepasst werden ? Mein Ansatz war T6963C_GRPH_ROWS 64 T6963C_TEXT_ROWS 8 alles Andere habe ich so belassen wie es ist. FS ist auf LOW für 8x8. Funktioniert aber nicht. Hat irgendjemand da einen kleinen "Anstoss" ;) ?
Datum:
Hallo, hat schon jemand versucht, mit dieser LIB größere Fonts zu erstellen? Ich habe bei anderen Libs(Niko Sachs) davon gelesen aber nutze die von Simon K.(und bin damit zufrieden und komme gut klar) Nun wüsste ich gerne, wo ich ansetzen müsste bei der Lib um die entsprechenden Zusatzprogramme für Simon K´s Lib nutzen zu können für größere Fonts. Vielen Dank. Gruß Clyde
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten