Grafikdisplay 320x240 ansteuern

    Zitat von Pesi

    da sollte das aber dann recht leicht gehen mit der Transparenz, erst den Bereich aus dem Controller in's RAM zurücklesen (das geht ja, oder? - auch mit Autoincrement?), dann nur die Bytes überschreiben, wo der Text ein Pixel hat, und dann wieder zurück...

    Dann kann man aber nur einmal Text an eine bestimmte Stelle schreiben.
    Soll der Text anschließend aktualisiert werden, haut das so nicht mehr hin.


    Dann müsste man im schlimmsten Fall ein komplettes Redraw veranlassen, oder (wenn der Text einfach über einem Hintergrundbild liegt) den entsprechenden Bildausschnitt neu aus Data-Zeilen oder von Flashcard etc. einlesen uns so weiter.


    Ist alles machbar, wird mit der Zeit auch gemacht, aber künftig werde ich eher intelligente Displays einsetzen, statt dieses hier aufwändig "zu Fuß" anzusteuern.


    Habe dem Betreiber dieses Shops schon versprochen, bei MoSteuS künftig auf seine "intelligenten Displays" zu setzen:
    http://mikrocontroller-praxis.…lay/TFT-Grafik-Farbe.html


    Das entlastet den Hautpcontroller ganz immens, der ja mit dem Bus-Kram schon ordentlich zu tun hat. Ich hätte sowieso sowas in der Art gebaut; gibt es aber schon fertig - wunderbar!
    Alle Displays dieser Serie sind über das gleiche, 10-polige Folienkabel anschließbar. Ich werde also diese Buchse vorsehen, dann kann jeder das Display seiner Wahl dranpappen.


    Der Clou: Die Displaymodule beinhalten schon einen Slot für 'ne Speicherkarte.
    Und der Betreiber des Shops will für mich eine Möglichkeit implementieren, dass man mit 'nem externen Controller nicht nur wie bisher die Displays per Hochsprachenbefehle ansteuern kann, sondern auch auf den Inhalt der Speicherkarte Zugriff bekommt!
    Dann muss ich für speicherhungrige Anwendungen nicht mehr unbedingt 'ne eigene Flashkarte vorsehen, sondern nutze einfach die auf dem Displaycontroller vorhandene.


    Natürlich kann man weiterhin auch das Dingens von Mikroelektronika verwenden, aber diese hier sind eine flexible und preisgünstige Alternative.


    320x240 Pixel ohne Touch:
    http://mikrocontroller-praxis.…be/XV-TFT60D-35-3224.html


    Mit Touch:
    http://mikrocontroller-praxis.…/XV-TFT60D-35-3224-T.html

    Habe das Tool von Mikroelektronika mal ausprobiert.
    Hmmm, das gibt einen sehr merkwürdigen, aufgeblähten Code raus.


    Habe mal den Windows-Font Courier Standard 10 Punkte importiert.
    Schauen wir uns mal diesen Output-Schnipsel an:


    Code
    $05, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00,  ' Code for char  
$05, $00, $00, $00, $00, $00, $00, $00, $00, $FC, $05, $00, $00, $00, $00, $00, $00,  ' Code for char !
$06, $00, $00, $00, $00, $00, $00, $1C, $00, $00, $00, $1C, $00, $00, $00, $00, $00,  ' Code for char "
$08, $00, $00, $00, $01, $10, $07, $F0, $01, $1C, $07, $F0, $01, $1C, $01, $10, $00,  ' Code for char #


    Und wundern wir uns zunächst über die erste Zeile, die ein Leerzeichen repräsentieren soll. Warum beginnt die mit $05?
    Dann wundern wir uns noch mehr über die zweite Zeile, die ein Ausrufungszeichen darstellen soll.


    So sieht es im Programm aus:




    Hier werden übrigens 17 Bytes rausgehauen, wo 13 reichen würden.
    Selbst um 90 Grad gedreht wären nur 16 Bytes nötig.


    Wenn ich das erstmal anhand anderer Zeichen kapiert habe, wie die Daten zu verstehen sind, wäre es wohl angesagt, da noch einen eigenen Konverter drüberlaufen zu lassen, der das komprimiert.


    Edit: Habe das Datenformat begriffen, bis auf die linke Spalte, die kann aber offenbar einfach ignoriert werden.
    Das Ausrufungszeichen wird durch FC 05 repräsentiert, mal nur die relevanten Bytes betrachtet.
    Vertauschen wir die beiden Bytes: 05 FC.
    Jetzt das Bild im Geiste um 90 Grad nach rechts drehen und dann links drei Felder mehr vorstellen, so als ob es 16 statt 13 wären.
    Dann findet man 05 FC problemlos wieder.


    Schade ist halt, dass das Datenformat unnötig Platz belegt, zumindest in diesem Fall.
    Pro Zeichen vier Bytes mehr als notwendig. Macht bei 96 Zeichen (ASCII 32 bis 127) 384 Bytes unnötig belegten Speicher. 23,5% Platzverschwendung.


    Wenn jemand 'nen simplen Konverter strickt, der das per Knopfdruck umfrickelt, wäre das echt toll!

    So wie ich das sehe, sind die Daten spaltenweise angeordnet. Wenn der Zeichensatz höher als 8 Pixel ist, dann werden zwei Byte, also 16 Bit pro Spalte benötigt. Angeordnet sind die Daten jeweils als oberes Byte (die oberen 8 Pixel der Spalte) zuerst, dann unteres Byte, wobei das most significant Bit im Byte jeweils den untersten Pixel des vom Byte dargestellten Spaltenteils bezeichnet. Das erste Byte des Zeichens gibt dann noch die tatsächliche Zeichenbreite an (von Anfang der Definition bis zur letzten Spalte, welche nicht leer ist), damit eben Zeichensätze mit variabler Zeichenbreite dargestellt werden können.
    Ich kenne weder die Interna der X-GLCD Lib von mikroe noch die genaue Anordnung der Bytes im jeweiligen Display, also kann ich nicht sagen, ob die Zeichen-Definition notwendigerweise in dieser Art geschehen muss bzw. ob es möglicherweise von der Darstellungsgeschwindigkeit her sinnvoll ist, es eben so zu definieren, damit möglichst auf zeitaufwendige Daten-Umformatierungen vor der Ausgabe verzichtet werden kann.


    Gruss
    Neni

    Dreckiger, schneller Hack meinerseits:


    http://www.EDV-Dompteur.de/download/Fontkonverter.zip


    Anleitung und Quelltext in VB.Net liegt bei.
    Das Programm konvertiert eine Ausgabedatei vom GLCD Font Creator:
    http://www.mikroe.com/eng/prod…ew/683/glcd-font-creator/
    ... per einfachem Doppelklick in ein Format, das man direkt in Bascom includen kann.


    Fast ganz ohne der in meinem letzten Posting erwähnten Optimierung; es wird lediglich die überflüssige erste Spalte entfernt und der Code halt auf Bascom umgestrickt.
    Könnte man genausogut mit 'nem Editor in 10 Minuten von Hand erledigen, aber so geht es halt flotter.


    Viel Spaß!

    Zitat von synvox

    Das erste Byte des Zeichens gibt dann noch die tatsächliche Zeichenbreite an (von Anfang der Definition bis zur letzten Spalte, welche nicht leer ist), damit eben Zeichensätze mit variabler Zeichenbreite dargestellt werden können.

    Öi, das ist klug! Vielen Dank für diesen Hinweis!
    Hmmm, dann ist das ja gar nicht sinnvoll, dass mein Konverter die erste Spalte entfernt ...
    Haben wir also jetzt schon einen Punkt, für das erste Update!


    Noch ein guter Punkt ist mir gerade eingefallen:
    Per Default importiert das Tool von Mikroelektronika die Zeichen 32 bis 127.
    Da bleiben die Umlaute auf der Strecke.


    Bei den beiden Fonts, die ich neulich anderweitig guttenbergte, waren die Umlaute (die ja normalerweise höhere Positionen belegen), auf 127 bis 133 gemappt.
    Meine Idee: Man stellt im GLCD Font Creator eine entsprechend höhere Zahl ein, so dass auch die Umlaute enthalten sind und mein Fontkonverter entfernt alle sonstigen Zeilen, so dass von ASCII 32 angefangen bis 133 alles vorhanden ist, mit den Umlauten und dem "ß" in den letzten Zeilen.


    Und wenn ganz viele User betteln (womit ich zugegebenermaßen nicht rechne), dann baue ich vielleicht auch noch einen Fileselector ein.
    Und schreibe noch die ASCII-Nummer in den Kommentar hinter jedem Zeichen.