Hallo,
ich habe ein OLED-Display EA W162-X9LG:
http://cdn-reichelt.de/documents/datenblatt/A400/DS_OLED_EA.pdf
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?
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
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! ;-)
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.
@ 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???
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
....
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
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
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
Hi
>(grins...das läuft sogar....)
Sicher? Beispiel:
1
Verzoegerung2:
2
push temp
3
push temp1
4
push temp2
5
in temp, SREG
6
push temp
7
ldi zeit, 0xFF
8
ldi zeit1, 0x20
9
;
10
Verz_Schleife2:
11
dec zeit
12
cpi zeit, 1
13
brlt Verz_Schleife2
14
ldi zeit, 0xFF
15
dec zeit1
16
cpi zeit1, 1
17
brlt Verz_Schleife2
18
pop temp
19
out SREG, temp
20
pop temp2
21
pop temp1
22
pop temp
23
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.
1
lpm ; erstes Byte des Strings nach R0 lesen
2
...
3
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
Und hier noch eine universelle Delayschleife nach Steve Wozniak:
1
.def del = r18 ; delay counter
2
; steve wozniak's wait routine - this time for AVR
3
; this is the extended routine with del^3
4
; this wait routine is ingenious and handles wide ranges of delay
5
; as a hommage to steve i port it to all my embedded systems.
6
wozwait: push del
7
wwait2: push del
8
wwait1: subi del,1
9
brne wwait1
10
pop del
11
subi del,1
12
brne wwait2
13
pop del
14
subi del,1
15
brne wozwait
16
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.
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
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.
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
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?
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
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:
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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