|
Datum:
|
Hallo, ich habe ein OLED-Display EA W162-X9LG: http://cdn-reichelt.de/documents/datenblatt/A400/D... In dem Datenblatt gibt es eine Tabelle zum Befehlssatz. Dort steht, dass ich zwischen character mode und graphic mode wählen kann. Was ist der Unterschied zwischen diesen beiden Modi?
|
Datum:
|
Hallo, ohne jetzt speziell auf dein Display einzugehen. Im Charachtermode, gibt das Display automatisch Zeichen aus einem internen Zeichensatz an von der Zeichengröße vorgegebenen Positionen aus. Das scheinen bei dir 2 Zeilen a 16 Zeichen zu sein (mal aus der Bezeichnung abgeleitet). Dem Controller gibst du dabei die Position vor (X und Y) und das Zeichen (z.B. 'A'). Im Grafikmode kannst/musst du jedes Pixel einzeln setzen somit kannst du dort alles darstellen was du willst. Auch da kannst du Text erzeugen musst den Zeichensatz dazu aber in deinem Controller vorhalten. Sascha
|
Datum:
|
Ein Blick in das angegebene Datenblatt zeigt: Richtiger Grafik-Mode IST NICHT. Wie bei den üblichen 44780-LCD-Displays, gibt es hier 8 "Character", die man als 5x7-Pixel selbst definieren kann. Das Sinus-Bildchen auf der 1. Seite oben-Mitte ist schon das Maximum der "GRAFIK"-Fähigkeiten. mit 7 verschieden hohen "Säulen". Oha, da bleibt noch ein selbst zu definierender "Character" übrig, da die Höhe NULL auch mit SPACE darstellbar ist! ;-)
|
Datum:
|
Angehängte Dateien:
-
Userdefchars.jpg
6,56 KB, 104 Downloads
Jakob schrieb: > Ein Blick in das angegebene Datenblatt zeigt: > Richtiger Grafik-Mode IST NICHT. > > Wie bei den üblichen 44780-LCD-Displays, gibt es hier 8 > "Character", die man als 5x7-Pixel selbst definieren kann. > > Das Sinus-Bildchen auf der 1. Seite oben-Mitte ist schon das > Maximum der "GRAFIK"-Fähigkeiten. mit 7 verschieden hohen > "Säulen". > > Oha, da bleibt noch ein selbst zu definierender "Character" > übrig, da die Höhe NULL auch mit SPACE darstellbar ist! ;-) Hallo, probier mal das zum Test: Was siehst Du? (Beim Attiny2313 den SPH -String ausremmen) ciao gustav Neue Zeichen werden durch den Display Clear Befehl beim nächsten Start gelöscht und müssen neu erzeugt werden.
:
Bearbeitet durch User
|
Datum:
|
@ Karl B. (gustav) Hm, deinen ganzen Assembler-Code habe ich jetzt nicht durchgeackert. Berichtige mich bitte, wenn ich danebenliege: Wechselst du während der Ausgabe mal schnell die "User-Defined Characters" aus, um damit auf mehr als 8 darstellbare "User-Defined- Characters" zu kommen? - Hab ich noch nie probiert. Klappt das? Auf deinem Bild sind nur 8 "ungewöhnliche" Zeichen sichtbar. Das geht ohne Trick. - Ist kein Beweis. Wie kommt man damit dem angedeuteten Grafik-Mode näher???
|
Datum:
|
P.S. Beim Sinus-Bildchen bleiben sogar ZWEI selbst definierbare Zeichen übrig: Die maximale Säule gibt es schon bei Ausgabe 0xFF = 255.
|
Datum:
|
Jakob schrieb: > Wechselst du während der Ausgabe mal schnell die "User-Defined > Characters" aus, um damit auf mehr als 8 darstellbare "User-Defined- > Characters" zu kommen? - Hab ich noch nie probiert. Das geht. Aber nur mit den jeweils aufzurufenden Routinen. Nochmals: Das CharakterROM hat unten noch freie Adressen (kommt davon, dass ASCII-Fernschreibcode erst bei höheren Zahlen anfängt.) Mehr als 8 Zeichen geht nicht, weil die Adressierung dann in einen anderen Befehlsmodus wechselt: Datenblatt: DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0 L H X X X X X X Set CGRAM Adress also Code: ldi temp, 0b01000000 (oder 0x40) dann Kommando an Display also RS-Bit auf Low und ein Enableimpuls So, jetzt ist das Display im User-Defined Character mode und wartet auf weitere Eingaben. Jetzt kommt's: Das ist im Datenlatt garnicht oder nur unzulänglich erklärt. Jetzt gehe ich wieder mir RS auf high in den Datenübernahmemodus und gebe meine Pixelwerte ein. Im einfachsten Falle: ldi temp, 0xFF Daten-an-LCD-Routine (RS auf high, Enableimpuls) .. .. .. achtmal dasselbe Dieser Charakter gibt mir einen vollen schwarzen Balken aus und ist im Programm dann mit ldi temp, 0x00 in der Datenausgaberoutine aufrufbar. Sonst kann ich ja Charakters direkt ausgeben z, B. ldi temp, 'A' Jetzt muss man die Nummer direkt angeben, also 0x00, 0x01, bis 0x07 Vorsicht Falle: Charakter 0x01 wird jetzt so programmiert: Set CGRAM = 0x40 plus 8 0x48 weil ich die Routine ja achtmal durchlaufe. entsprechend für 0x02 = 50 0x03 = 58 0x04 = 60 0x05 = 68 0x06 = 70 0x07 = 78 mehr geht nicht, weil die 80 ja schon einen anderen Befehlsmodus aufrufen würde. ciao gustav
|
Datum:
|
Angehängte Dateien:
-
UCH_03.png
18,1 KB, 64 Downloads
.... wichtig ist auch noch, dass richtig initialisiert wird. D.h. die Init-Routine könnte (stark verkürzt) so aussehen: 30 30 30 20 28 08 01 06 10 0C 01 Dann sollte möglichst zur Sicherheit noch vor der Charakter-Ausgabe eine Positionierungsangabe erfolgen. Die Pixelei: siehe angehängtes Bildchen (uups. dupliziert) ciao gustav
:
Bearbeitet durch User
|
Datum:
|
Hi >Das geht. >Aber nur mit den jeweils aufzurufenden Routinen. Was hat das mit einem Grafik-Mode zu tun? Das sind ganz normale Funktionen des HD44780. Leider schweigt sich EA über den Typ des Display-Controllers aus. Mit den Angaben aus dem Datenblatt kann man nicht viel anfangen. @ gustav (Gast) Deine Programme scheinen genauso ausufernd zu sein wie deine Ausführungen hier im Forum. Deine 'userdefchars.asm' kann man problemlos auf die Hälfte bis ein Drittel eindampfen. MfG Spess
|
Datum:
|
Jakob schrieb: > Wechselst du während der Ausgabe mal schnell die "User-Defined > Characters" aus, um damit auf mehr als 8 darstellbare "User-Defined- > Characters" zu kommen? - Hab ich noch nie probiert. Das sollte beantwortet werden. Da ist noch ein Fehler drin. Ich gehe vom Proggi aus, wo die Adressen "automatisch" (im Z-Pointer) mit temp2 hochgezählt werden. Für jede Zeile also eine extra Adressenangabe und eine Pixel-Daten-Eingabe. Hatte schon gedacht, dass das Prog irgendwie noch verschlankt werden kann. Vorher war es noch größer, da hatte ich pro Charakter noch eine extra Printschleife drin. (das Label Print_01 kann auch noch raus, sorry...) Alles auf eine lpm- zurechtzustutzen geht deswegen nicht, weil ich einmal nullterminierte Tabelle für den "Normaltext" in Zeile 1 nehme, zum andern ja die Null darstellen muss, und dabei noch ein paar Befehle mehr brauche um die Schleife achtmal bei Adresseninkrement zu durchlaufen. Wie sieht Dein Assemblerprogramm denn aus? ciao gustav
:
Bearbeitet durch User
|
Datum:
|
Gefällt's Ihro Gnaden @Spess jetzt besser? (grins...das läuft sogar....) ciao bello gustav
|
Datum:
|
Hi
>(grins...das läuft sogar....)
Sicher? Beispiel:
Verzoegerung2: push temp push temp1 push temp2 in temp, SREG push temp ldi zeit, 0xFF ldi zeit1, 0x20 ; Verz_Schleife2: dec zeit cpi zeit, 1 brlt Verz_Schleife2 ldi zeit, 0xFF dec zeit1 cpi zeit1, 1 brlt Verz_Schleife2 pop temp out SREG, temp pop temp2 pop temp1 pop temp ret |
Da 0xFF..0x80 kleiner als 1 (-1..-128) sind wird nur einmalig zeit bis 0x7F (127) herunter, eigentlich hoch, gezählt und danach die Routine (da 0x20>1)verlassen. Ist das so gewollt? Das Sichern der temp-Register ist eh Unsinn, da sie nicht benutzt werden. Für SREG gilt ähnliches.
lpm ; erstes Byte des Strings nach R0 lesen ... mov temp, r0 |
Alle aktuellen AVRs beherrschen lpm register (Register r0..r31) Das waren nur zwei Beispiele. Es gibt noch mehr. Wäre für mich kein Grund zum Grinsen. MfG Spess
|
Datum:
|
Und hier noch eine universelle Delayschleife nach Steve Wozniak:
.def del = r18 ; delay counter
; steve wozniak's wait routine - this time for AVR
; this is the extended routine with del^3
; this wait routine is ingenious and handles wide ranges of delay
; as a hommage to steve i port it to all my embedded systems.
wozwait: push del
wwait2: push del
wwait1: subi del,1
brne wwait1
pop del
subi del,1
brne wwait2
pop del
subi del,1
brne wozwait
ret
|
Aufruf mit einen beliebigen Wert in 'del' (R18) - je grösser, desto länger das Delay. Ich klingel die benötigten Zeiten pro Taktfrequenz einmal mit dem Simulator aus.
:
Bearbeitet durch User
|
Datum:
|
Hi >Und hier noch eine universelle Delayschleife nach Steve Wozniak: >... Der grundlegende Fehler bei Karl B. (gustav) ist die Verwendung von signed Befehlen (brlt) auf unsigned Operanten. MfG Spess
|
Datum:
|
spess53 schrieb: > Der grundlegende Fehler bei Karl B. (gustav) ist die Verwendung von > signed Befehlen (brlt) auf unsigned Operanten. Ich finde auch, das sie viel zu viele Register belegt und unnötig Krams sichert - ganz, wie du schon gesagt hattest. Die Woz Routine benötigt genau ein Register und den Stack und kommt problemlos von µs bis Sekunden.
|
Datum:
|
Freut mich, dass am eigentlichen Prog wohl zunächst nichts zu meckern übrigbleibt. Nun zu den in die Pfanne gehauenen Warteschleifen: Diese Schleifen sind noch aus dem "alten" Programm einfach gedankenlos von irgendeiner Internet-Seite (irgendein altes Mikrocontroller.net-Tutorial) abkopiert worden. Ich verwende sie nach Möglichkeit nicht mehr. (Dienen ausschließlich dem Zweck, Euch hier zur Weißglut zu bringen.) ---- Das Sichern der temps ist dann eine liebgewonnene Angewohnheit. Kann aber essenziell sein. Zum Beispiel, wenn man Argumente mehrfach hintereinander sendet, wie bei der LCD-Initialisierung ganz zu Anfang ( 3x hex30 ) und zwischenzeitlich dieselben Register für Zeitschleifen verwendet. Das hatten wir ja vorgestern angemeckert, das zuviele Male dasselbe geladen würde. Jetzt wäre es ohne push und pop voll in die berühmte Hose gegangen. Gelle? Wurde ja auch als "include"-Datei im Kommentar gekennzeichnet, die als Programmschnitzel für verschiedene andere Proggis verwendet werden könnte, von denen man nicht weiß, ob sie d i e Register noch für Arithmetics etc. brauchen. Die "brlt"-Sache gefällt mir auch nicht. Vielleicht geht es auch mit brlo oder Knopf an die Backe nähen und irgendwelche Flags abfragen, was es - auf Teufel komm raus - noch so zu bieten hat. ---- Es geht mit folgenden 16-Bit-Schleifen IMHO besser und übersichtlicher. (Die Befehlsdurchläufe lassen sich wenn gewünscht, besser berechnen, ohne sich vielleicht in dem "Knäuel" zu verheddern.) vielen Dank für Ihro Gnaden Aufmerksamkeit, untertäniglichst ciao gustav
|
Datum:
|
Was soll da falsch sein? erstes Byte des Strings nach R0 lesen ist bloß ungenügend klar formuliert Zitat: "http://www.avr-asm-tutorial.net/avr_de/testlpm.html"; lesen: LPM ; Lese das Byte, auf das Zeiger Z zeigt in Register R0 Zufrieden?
|
Datum:
|
Hi >Freut mich, dass am eigentlichen Prog wohl zunächst nichts zu meckern >übrigbleibt. Falsch. Ich habe nur keine Lust dein Progamm Zeile für Zeile auseinander zu nehmen und Romane dazu zu schreiben. Z.B. Deine 72 Befehle zum Laden vom CG-RAM
ascii_00: ; Charakters zuordnen ldi temp, 0x40 ; und Pixel definieren rcall kommando ... ascii_07: ldi temp, 0x78 ; "Set CGRAM address"-Steuerbefehl ... ret |
sehen bei mir so
ldi ZL,low(tabelle<<1)
ldi ZH,high(tabelle<<1)
ldi t17,8*8
rcall set_cgram
...
;-----------------------------------------------------------
; CG-Ram laden
; in : Z - Tabelle
; r17 Anzahl Zeichen (á 8 Byte)
.if use_set_cgram == 1
set_cgram: push r17
push r18
ldi r18,cgram_set
rcall lcd_wrcmd
set_cgram10: lpm r18,Z+
rcall lcd_wrdat
dec r17
brne set_cgram10
pop r18
pop r17
ret
.endif
|
aus. Macht das gleiche, ist aber eine Idee kürzer. >Die "brlt"-Sache gefällt mir auch nicht. >Vielleicht geht es auch mit brlo brlo ist genau so falsch, weil für signed Operanden. Sieh dir mal die Tabelle '3. Conditional Branch Summary' in www.atmel.com/images/Atmel-0856-AVR-Instruction-Set-Manual.pdf an. Einfach so:
ldi r16,10
aaa: dec r16
brne aaa
|
MfG Spess
|
Datum:
|
Hi >Was soll da falsch sein? >erstes Byte des Strings nach R0 lesen Nicht falsch, aber überholt lpm - [Z] nach r0 lpm rd - [Z] nach r0...r31 lpm stammt aus Zeiten der AT90Sxyz. Alle aktuellen kennen AVRs den lpm-Befehl der direkt in das Zielregister, ohne Umweg über r0, lädt. MfG Spess
|
Datum:
|
|
Datum:
|
print_0: lpm temp, z+ ; erstes Byte des Strings nach temp lesen inc temp2 ; und Adresse Postincrement cpi temp2, 0x09 ; insgesamt achtmal Pixelwerte holen breq print_end0 ; wenn 9, dann zu print_end0 ;mov temp, r0 ; Inhalt von R0 nach temp kopieren --- enfällt rcall ausgabe ;adiw ZL:ZH, 1 ; Adresse des Z-Pointers um 1 erhoehen entfällt bei Z+ rjmp print_0 ; zum Anfang springen, um naechstes ; ; Byte zu holen print_end0: ret Vorsicht Falle: der Attiny 4313 machts, der 2313 glaube ich nicht. da kommt im Studio4.18 die Assemblerfehlermeldung "no such instruction" Das Z+ !! danke für tip
:
Bearbeitet durch User
|
Datum:
|
Hi >Vorsicht Falle: der Attiny 4313 machts, der 2313 glaube ich nicht. >da kommt im Studio4.18 die Assemblerfehlermeldung "no such instruction" Nö. Aus Instruction Set Summary ATTiny2313: LPM Load Program Memory R0 ← (Z) None 3 LPM Rd, Z Load Program Memory Rd ← (Z) None 3 LPM Rd, Z+ Load Program Memory and Post-Inc Der uralte AT90S2313 (Include-Datei 2313def.inc) kennt nur 'lpm'. ATTinys kennen die erweiterten lpm-Befehle. MfG Spess
|
Datum:
|
Hm, ohne es genauer zu betrachten, erzeugt Karl B. (gustav) da einige zusätzliche "user defined Characters" deren Verwendbarkeit für eine Grafikausgabe z.B. mit einem Tiny-µC, der mit seinen beschränkten Resourcen erst mal die Daten erfassen, auswerten und bereitstellen muss, bisher nicht nachgewiesen hat. Hat schon mal wenig mit der Fragestellung des TO zu tun. Aber vielleicht lernen wir anderen was: Erzähl also nicht so viel, zeig es uns! Datenerfassung, Auswertung und grafische Darstellung! Vorgabe: Maximal 50% der Ressourcen eines Tiny44. Punkteabzug, aber noch "interessant", wenn es 50% eines Tiny84 sein müssen.
|
Datum:
|
Hi >Hm, ohne es genauer zu betrachten, erzeugt Karl B. (gustav) >da einige zusätzliche "user defined Characters" deren >Verwendbarkeit für eine Grafikausgabe z.B. mit einem Tiny-µC, >der mit seinen beschränkten Resourcen erst mal die Daten >erfassen, auswerten und bereitstellen muss, bisher nicht >nachgewiesen hat. Wenn du den Typ des Displaycontrollers von EA nennst bekommst du mehr Infomationen. MfG Spess
|
Datum:
|
Jakob schrieb: > Ein Blick in das angegebene Datenblatt zeigt: > Richtiger Grafik-Mode IST NICHT. > > Wie bei den üblichen 44780-LCD-Displays, gibt es hier 8 > "Character", die man als 5x7-Pixel selbst definieren kann. Also, wo steht im mit obigem Link aufrufbaren Datenblatt irgendetwas von Graphik-Mode. Sollte so etwas sein, schicke ich eine Beschwerde an Reichelt wegen unlauteren Wettbewerbs bzw. bewusster Irreführung der Kunden. Meine Displays von POLLIN funktionieren, wie sie es sollen. Hier ein echtes Graphik-LCD: LCD-Modul TG12864B-05 Grünes, grafisches LC-Display (128x64 Pixel) mit integriertem Controller (kompatibel zu KS0108) und LED-Hintergrundbeleuchtung. Geeignet zum Betrieb am PC-Druckerport (LPT). Der Rest des Threads sollte doch die Userdef Chars behandeln Grafik-Mode ist nicht. Wenn man einen galoppierenden Gaul mit dem Hitachi-Controller hinkriegen will, kostet es schon viel Mühe. Den ersten Ansatz dafür habe ich hier geleistet. Mehr it nicht drin. ciao gustav
|
Datum:
|
Angehängte Dateien:
-
Reichelt_LCD.jpg
60,1 KB, 59 Downloads
Suchergebnis: Da können 3 Fonts ausgewählt werden, sonst nichts an Extras.
|
Datum:
|
Hi >Also, wo steht im mit obigem Link aufrufbaren Datenblatt irgendetwas von >Graphik-Mode. Auf S.4 unter Cursor/Display Shift/Mode/Pw r >Sollte so etwas sein, schicke ich eine Beschwerde an Reichelt wegen >unlauteren Wettbewerbs bzw. bewusster Irreführung der Kunden. Was hat Reichelt damit zu tun? Das ist das Original Datenblatt von ELECTRONIC ASSEMBLY. Und das ist für OLED-Displays und nicht für LC-Displays. Die OLED-Controller sind zwar weitestgehend kompatibel mit den HD44780, haben aber ein paar Befehle zusätzlich. Ich habe hier noch ein dieser Displays herum liegen. Wenn ich Zeit habe werde ich die mal genauer testen. MfG Spess
|
Datum:
|
spess53 schrieb: > Wenn du den Typ des Displaycontrollers von EA nennst bekommst du mehr > Infomationen. Das ist mal wieder typisch. In der Produktbeschreibung im Prospekt ist nichts, was beanstandenswert wäre. Aber jeder, der sich ein wenig mit LCDs oder ähnlichen Displays nur annähernd etwas genauer befasst hat, wird doch bei der Angabe des Controllertyps sofort stutzig. TECHNISCHE DATEN * INTEGRIERTER KONTROLLER (HD44780-ÄHNLICH) Dass man zwischen 3 "Fonts" auswählen kann, scheint das Besondere. Wieso da Graphik-mode steht, müsste man mal den Hersteller fragen, was er sich dabei gedacht hat. Reichelt kann da auch nichts dafür, bitte reuigst um Vergebung Ihro Gnaden. Überall auch "subject to change - Änderungen vorbehalten etc." (Will meine Kundennummer bei Reichelt auch nicht verlieren wegen unablässiger Querulanz.) Testen kann ich's nicht, habe keine Oleds. ciao gustav
:
Bearbeitet durch User
|
Datum:
|
Hi >Aber jeder, der sich ein wenig mit LCDs oder ähnlichen Displays nur >annähernd etwas genauer befasst hat, wird doch bei der Angabe des >Controllertyps sofort stutzig. Warum stutzig? >TECHNISCHE DATEN >* INTEGRIERTER KONTROLLER (HD44780-ÄHNLICH) Ist auch nicht falsch. Ich habe das OLED-Display W162-XBLW einfach auf eine Platine aus der laufenden Fertigung gesteckt und es hat ohne Änderungen an der Software anstandslos funktioniert. MfG Spess
|
Datum:
|
spess53 schrieb: > Warum stutzig? Grafikmodus und HD447780 das macht doch stutzig.... so wäre es sinngemäß korrekter Wenn ich nach LCD und Grafikmodus suche, bekomme ich andere Controller-Standards serviert.
|
Datum:
|
Nur ein Suchergebnis purer Zufall: Wo ist da was von HD44780 die Rede? LCD-Grafikdisplay Technologie mit Display-RAM Ausführung mit Controller UC1701
|
Datum:
|
Warte noch auf Email-Antwort vom Hersteller des vom TO benutzten Displays insbesondere, wie der Begriff "Graphic Mode" hier nun zu verstehen ist. Bis dahin... bitte etwas Geduld. Abwarten und Tee trinken ciao gustav
|
Datum:
|
Hi >Grafikmodus und HD447780 >das macht doch stutzig.... so wäre es sinngemäß korrekter Nicht alles was du nicht kennst gibt es nicht. Such mal nach den ST7920 von Sitronix. Und auch Beitrag "HD44780 (Pollin DV20208) Zeichenbreite stimmt nicht" MfG spess
|
Datum:
|
Hallo, hier Antwort des LCD-Herstellers (sinngemäß) "...Es ist ein HD44780 kompatibler Controller. Er kann dasselbe wie der eben genannte. Er kann zusätzlich aber noch OLED Spannungen generieren und als Grafikcontroller arbeiten. Der Controller könnte beim EA W162-X9LG auch vom "Schreib-" in den "Zeichenmodus" gesetzt werden, doch entstünde hierbei nach 8 Pixeln eine Lücke von 4 Pixeln Höhe, da auf dem OLED-Glas ein Zwischenraum zwischen erster und zweiter Zeile fest eingefügt ist, so dass nicht über die gesamte Fläche gezeichnet werden kann..." Zitat Ende Laut Datenblatt müsste IMHO dann in der Initialisierungsroutine anstelle 0x17 0x1F erscheinen, um den "Graphic mode" zu aktivieren. ciao gustav
|
Datum:
|
Hi
>hier Antwort des LCD-Herstellers (sinngemäß)
Interessant wäre der Typ des Displaycontrollers.
Aber ich habe mal etwas gesucht und bin auf den WS0010 von WINSTAR
gestoßen. Der stimmt soweit mit den Angaben von EA überein.
MfG Spess
Thread beobachten
Seitenaufteilung abschalten