Unterschiede GLCD/LCD betreiben

[BlackDevil]

Servus

Mich würden mal die Softwareseitigen unterschiede interessieren.

Beispiel: Fortschrittsbalken
Sowas kann ich mit einem normalen DOT-Matrix oder aber auch mit einem Grafik LCD machen. Beim normalen LCD würd ich die Zeichen | setzen ( [|||||||||] ) oder eben Pixel für Pixel selbst setzen. Beim GLCD würd ich auch Pixel für Pixel selbst setzen. Glaub ich.

Naja blödes Beispiel. Mich würden mal die Unterschiede und die möglichkeiten eines GLCD interessieren. Möchte demnächst mal was mit einem GLCD machen


Grüße

 

[dino03]

Hallo,

Beim normalen LCD würd ich die Zeichen | setzen ( [|||||||||] ) oder eben Pixel für Pixel selbst setzen. Beim GLCD würd ich auch Pixel für Pixel selbst setzen. Glaub ich

sieh dir mal die Seite für LCD4Linux an. Da sind etliche Character-LCDs bis
aus letzte ausgereizt. Mit animierten Icons, Bargraphen, ... usw
Da kann man mal sehen was alles möglich ist

Gruß
Dino

 

[BlackDevil]

Das hilft mir nich zu den unterschieden Ich mein klar, ich kann auf beiden einen Bargraph darstellen. Schlussendlich schubs ich auf beiden Seiten Pixel durch die Gegend, frage ist halt nur der Unterschied

 

[Markus]

Hallo BlackDevil,

vielleicht hilft Dir folgende vereinfachte Erklärung:

Von der physikalischen Seite her sind LCD und GLCD zunächst gleich. Es gibt in Flüssigkristall eingelagerte Schichten / Elemente die durch elektrische Spannungen angeregt ihre lichtdurchlässigen Eigenschaften verändern und Licht entweder durchlassen oder nicht durchlassen. Jeder einzelne Punkt so so separat angesteuert.

Bei LCD-Displays werden mehrere Bildpunkte meist zu einem Zeichen zusammengefasst für das in dem zugehörigen Controller die entsprechenden Bildmuster hinterlegt sind. z.B. 8x5 Pixels ergeben häufig ein Zeichen.
Du kannst in diesen Display nicht auf einzelne DOTs (Bildpunkte) zugreifen sondern Du kannst Dur sagen, an welcher Position welches Zeichen dargestellt werden soll. Viele Display bieten noch die möglichkeit im Speicher des Controllers ein Zeichen selbst zu definieren aber das war es dann schon.
Bei der Positionierung eines Zeichens kannst Du in x und y auch nicht einzelne Bildpunkte angeben sondern nur Zeichenpositionen.

Bei GLCD ist das anders. Hier kann jeder einzelne Bildpunkt vom Benutzer gesteuert werden. Damit ist es möglich, Kreise, Linien und Bilder zu zeichnen. Bitmaps können in das Display geladen werden und und und.
Diese Display haben oft zwei Betriebsmodi, nämlich einen Textmodus der dem eines LCD-Display ähnelt und in dem Du vordefinierte Zeichen auf bestimmte Positionen setzen kannst. Die Positionierung ist dabei viel detailierter da sie auf Pixel-Ebene basiert. Außerdem können eigene komplette Zeichensätze geladen werden. Zweitens hast Du eben den vollen Grafikfunktionsumfang.

Fazit:
LCD Vordefinierte Zeichen auf festen Zeilen und Spalten
DLCD die Gesamte Welt der Grafik auf Pixel-Ebene

Hmmm, war das jetzt etwas verständlicher ?!?!

Grüße,
Markus

 

[BlackDevil]

Das macht smir jetzt klar. Ist das selbe, nur das ich bei dem einen jeden Pixel selbst steuern kann und bei normalen LCD nur Pixelblöcke nutzen kann.

Bei normalen LCD sieht man das im Testmode ja anhand der [ ] Kästchen.


Jetzt ergibt da Sinn. Einen Kreis könnte ich beim LCD nur in einen dieser Blöcke malen sofern es das als Zeichen gibt oder als Zeichen definieren. Bei einem GLCD kann ich den Kreis über die ganze Fläche malen und bin frei.

Cool


Noch eine Frage: Wenn ich ein LCD nehme und da über Rs232 in das EEPRom über ein Design Tool am PC Grafiken einlade, zB einen Bargraph, wie steuer ich das dann? Oder Lad ich da nur den Rahmen rein und den sich vergrößernden Balken macht mein ATMega?

Grüße

 

[Markus]

Hmmm,

Noch eine Frage: Wenn ich ein LCD nehme und da über Rs232 in das EEPRom über ein Design Tool am PC Grafiken einlade, zB einen Bargraph, wie steuer ich das dann? Oder Lad ich da nur den Rahmen rein und den sich vergrößernden Balken macht mein ATMega?

Das habe ich jetzt nicht verstanden. Du wirst ein LCD nicht direkt mit einer RS232 an Deinen PC anschließen können, es sei denn Du verwendest ein komplexeres Modul mit µC der dann die Daten entgegennehmen kann und zum Display senden kann. Meist haben die Dinger dann aber aufwändigere Protokolle.
Du wirst also wenn Du ein LCD nackt hast nicht drum herum kommen auf jeden Fall einen Mega einzusetzen der die Steuerung des LCD macht und der kann dann auch alles machen. Rahmen, Punkte, Balken ist für GLCD's kein Problem. Auch die Definition von benutzerspezifischen Zeichen macht der mega und die Daten werden bei der Initialisierung in den Speicher des Displays geschoben.

Grüße,
Markus

 

[BlackDevil]

http://www.lcd-module.de/pdf/grafik/edip240-7.pdf über RS232 ansteuerbar mit einer Software.

Es gibt ja für diverse GLCDs Tools die Grafiken erstellen. Dient mir das dann einfach dazu das ich mir den Code nich selbst überlegen muss? Und wie würde ich einen Bargraph aufbauen?

Ich will mir nix vorkauen lassen, ich würds auch so hinkriegen, nur bevor ich was urst kompliziertes mach was einfacher geht frag ich

 

[Dirk]

Es gibt ja für diverse GLCDs Tools die Grafiken erstellen. Dient mir das dann einfach dazu das ich mir den Code nich selbst überlegen muss? Und wie würde ich einen Bargraph aufbauen?

Für eine Bargraph-Ausgabe würde ich normalerweise keine fertige Grafik(en) nehmen, es sei denn, der Bargraph besitzt einen Farbverlauf (Gradienten) und in dem Fall würde die Grafik nur eine Pixelzeile breit oder hoch sein.

Der Grafikspeicher von S/W Dotmatix Displays ist in der Regel byteweise aufgebaut, das heisst, ein Byte steht für 8 Pixel. Es ist schwer, hier einen Algorithmus zu beschreiben, da dieser der Anordnung bzw. Adressierung des Grafikspeichers angepasst werden muss, damit die Ausgabezeit möglichst gering ist. Ich würde an deiner Stelle erst einmal versuchen, ein Grafikdisplay anzusteuern und einen Pixel auszugeben. Danach eine Routine für den Bargraph zu schreiben, dürfte dann eigentlich kein Problem mehr sein.

Dirk

 

[BlackDevil]

ich würde mir halt wahrscheinlich was urst kompliziertes überlegen

Für den Bargraph:
Den Rahmen würde ich über ein Array definieren (welche Pixel halt leuchten sollen) und den rest über dreisatz
Nur als Beispiel

 

[dino03]

Hallo,

so etwas macht man nicht über Arrays sondern über Funktionen. Ich hab
irgendwo noch Grafik-Routinen für den ZX-Spectrum in Basic rumfliegen.
Die sind zwar uralt (1980?) aber die gelten immer noch
Da sind zB Routinen zum zeichnen von Elipsen, Kreisen, Linien, Flächen füllen, ...
dabei. Muß ich nur mal wiederfinden. War glaube ich mal irgend ein Sonderheft
oder was weiß ich. Da muß man bei ner Linie nur die Anfangs- und Endkoordinaten
angeben und den Rest macht die Routine. Du mußt eigentlich nur vorher ne
Funktion basteln, die ein Pixel an einer bestimmten Koordinate auf dem LCD
setzen/löschen kann.

Such dir bei der Koordinatenberechnung Byte oder Word-grenzen oder andere
Zusammenhänge raus um das zu berechnen. Das geht mit einfachen Befehlen
ohne große Mathematik meißt sehr schnell.

Als Beispiel ...
Wenn zB das LCD 240 Pixel horizontal hat und die Byteweise zusammengefaßt
sind ...
|76543210|76543210|76543210|76.... <= Das sind die Bits in den Bytes
Dann kann man mit einer Schiebeoperation um 3 Bit die Nummer des Bytes
berechnen was man ansprechen muß in den 3 Bits die man rausschiebt hat
man dann die Bitposition innerhalb des Bytes. Such dir digitale Zusammen-
hänge. Fang nicht an mit höherer Mathematik weil dein LCD sonst beim
zeichnen enschläft Der Prozessor hat dann zuviel mit den Berechnungen
zu tun.

Bei 240 Pixel / 8Bit => wären das dann 30Byte pro Pixelzeile.
Evtl hat das Display ja 2 Schattenbytes. Also eigentlich 32Byte pro Zeile.
Dann kann man den Anfang der nächsten Zeile auch wieder mit ner Bitverschiebung
berechnen. Oder man arbeitet mit Index-Tabellen so wie ich es bei mir für
die Zeichenadresse bei den Character-LCDs gemacht habe.

Wenn du mit Multiplikation und Division anfängst, wird die Pixel und Zeichen-
ausgabe auf jeden Fall schnarchlangsam werden.

Gruß
Dino

 

[dino03]

Berechnung von Pixelpositionen (Beispiel)

Ich will das nochmal etwas genauer erklären ...
Wir nehmen mal an, der Displayspeicher ist mit den Pixeln folgendermaßen aufgebaut ...
LCD mit 60Pixeln horiz. und 40 Pixelzeilen vertikal ...


CodeBox LCD-RAM

--- Aufbau des GLCD-Speichers (Beispiel) ---

                         1          2          3           4          5  

sichtbare Px  01234567 89012345 67890123 45678901 23456789 01234567 89012345 6789....



        Bits  76543210 76543210 76543210 76543210 76543210 76543210 76543210 76543210



Pixelzeile 0 | Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 |



Pixelzeile 1 | Byte 8 | Byte 9 | Byte 10| Byte 11| Byte 12| ...



Pixelzeile 2 | Byte 16| Byte 17| Byte 18| Byte 19| Byte 20| ...



Pixelzeile 3 | Byte 24| Byte 25| Byte 26| Byte 27| Byte 28| ...

           :

           :

Pixelzeile 39|Byte 312|Byte 313|Byte 314|Byte 315|Byte 316|Byte 317|Byte 318|Byte 319|

Um die Pixelposition im Speicher zu berechnen könnte man nun folgendermaßen
vorgehen ...
x=45 , y=23

x wird um 3 Positionen nach rechts geschoben ...
45(dez) = 00101101(bin) ... => ...

| 00101101 |
| 00010110 | 1 ... 1Bit geschoben
| 00001011 | 01 ... 2Bits geschoben
| 00000101 | 101 ... 3Bits geschoben (3Bits = mögliche Werte 0..7)

... => ... 00000101 | 101 ...
00000101(bin) = 5(dez) Also Byte Nummer 5 , 101(bin) = 5(dez) also Bit 5

Mit den rausgeschobenen 3 Bits kann man also 8 verschiedene Zustände(Werte)
darstellen. Das sind unsere 8 möglichen Bits in dem Byte der Speicherstelle.

Um es universell zu machen, bauen wir uns für die Pixelzeilen eine Index-Tabelle ...

0 => 0
1 => 8
2 => 16
3 => 24
...
39 => 312

beim Eintrag 39 ist also der Wert 312 drin. Das ist die Anfangsadresse der
39en Pixelzeile im GLCD-Speicher.

Wir adressieren jetzt mit dem y-Wert des Pixels (das ist 23) die Tabelle und
holen die Anfangsadresse der Pixelzeile 23 raus => das müßte 184 sein.
Diesen Wert addieren wir jetzt zu unserer Bytenummer in der Zeile.
Also 184+5=189

Also ist unser Pixel x45/y23 auf Adresse 189 das Bit Nr 5

Ich habe die Werte eingefärbt damit man die Berechnung besser verfolgen
kann.

Auf diese Art kann man sehr schnell und ohne die CPU stark zu belasten
die Speicheradressen des GLCD-RAMs berechnen wo etwas gesetzt oder
gelöscht werden muß.

Denn mal viel Spaß

EDIT : Grad gemerkt das die Bit-Nr nicht oben zur Speichertabelle des GLCD paßt.
Die Bits sind gegenüber der Nummer spiegelverkehrt. Aber das Prinzip sollte soweit
klar werden. Darauf kam es mir an ...

Gruß
Dino

 

[BlackDevil]

Wobei die Bit Schubserei noch darauf ankommt welche Sprache man benutzt und ob das Display nicht einen Bus inside hat. Soweit ich weis kann man bei der I2C Steuerung direkt ansteuern:

Start | BYTE 1 | BYTE 2 | BYTE 3

Meine ich jedenfalls ... das erleichtert das ganze doch ein wenig. Ansonsten ist es wie RAM Ansteuern: Doof, weil man sich die Adresse rausfriemeln muss
Ich besorg mir mal ein Display von Tigall wenns meine Finanzen zulassen und dann schau ich mal



Danke

PS: Für die Berechnung von Bögen gibts tolle Algorithmen, den einen hab ich schon wieder vergessen *g*. Es gibt auch Algorithmen für Linien zu Zeichnen, auch das funzt super. Hab ich mal in Matlab mit dem Haus vom Nikolaus probiert (Matlab ist eh Super um Algorithmen zu testen, dann hat man gleich Pseudocode für C)

 

[dino03]

Hallo,

Wobei die Bit Schubserei noch darauf ankommt welche Sprache man benutzt und ob das Display nicht einen Bus inside hat. Soweit ich weis kann man bei der I2C Steuerung direkt ansteuern:

Start | BYTE 1 | BYTE 2 | BYTE 3

das was ich da gezeigt habe hat noch garnix mit der Ansteuerung des GLCDs
über den Bus zu tun sondern ist lediglich die Berechnung der Pixelposition
im Grafik-RAM des GLCDs.

Gruß
Dino

 

[BlackDevil]

Klar war das die Ansteuerung des Grafik RAM des Displays.

Bei normalen Speicher RAMs gibt es ja mehrere Versionen, die die über Daten- und Adressleitungen angesprochen werden und die die über Bussysteme angesprochen werden. Bei ersteren muss man sich überlegen welchen Bereich man Adressiert, wieviel Speicher man Adressiert, wie die Adressen lauten und so weiter und so fort.
Bei RAMs mit einem Bus (SPI, I2C) "pump" ich den Kram einfach ins Ram. Natürlich mit einem vom Hersteller vorgegebenen Telegramm.

So denk ich mir das bei GLCDs auch. Es gibt welche mit Daten und Adressleitungen. Da muss ich mir überlegen wo ich was hinschreibe (gezielt) damit entsteht was ich möchte. Hab ich eins mit Bus "pump" ich den Kram einfach rein - natürlich auch hier so wies der Hersteller möchte - und ich bekomme was ich will.

Oder seh ich das grundlegend falsch? ICh denke eigentlich nicht.

Die ganze Adressierei hab icheh nich so richtig verstanden, ich bin da noch total verwirrt von der Vorlesung

 

[dino03]

Hallo BlackDevil,

Klar war das die Ansteuerung des Grafik RAM des Displays.

Bei normalen Speicher RAMs gibt es ja mehrere Versionen, die die über Daten- und Adressleitungen angesprochen werden und die die über Bussysteme angesprochen werden. Bei ersteren muss man sich überlegen welchen Bereich man Adressiert, wieviel Speicher man Adressiert, wie die Adressen lauten und so weiter und so fort.
Bei RAMs mit einem Bus (SPI, I2C) "pump" ich den Kram einfach ins Ram. Natürlich mit einem vom Hersteller vorgegebenen Telegramm.

Nein, Nein, Nein Leider voll daneben ...
Wie gesagt ist es NICHT die Ansteuerung des Controllers oder des RAMs was
ich da geschrieben habe. Und mit einfach nur Daten ins RAM pumpen wirst du
absolut Schiffbruch erleiden. So einfach ist es leider nicht.

Aus deinem Beitrag #12 ...

Meine ich jedenfalls ... das erleichtert das ganze doch ein wenig. Ansonsten ist es wie RAM Ansteuern: Doof, weil man sich die Adresse rausfriemeln muss

Genau das mach ich mit der Berechnung. Wenn du den Punkt an Position
x/y auf dem Display setzen willst, dann berechnet dir der Algorithmus die
Adresse und die Bitnummer im RAM des GLCDs die du ansprechen mußt damit auf dem Display ein Punkt zu sehen ist.

So denk ich mir das bei GLCDs auch. Es gibt welche mit Daten und Adressleitungen.

Aber mit den Adress- und Datenleitungen kannst du NICHT DIREKT auf das
RAM zugreifen sondern nur auf die Register des LCD-Controllers. Der
schreibt dann die Daten die du angeliefert hast in das RAM.

Da muss ich mir überlegen wo ich was hinschreibe (gezielt) damit entsteht was ich möchte. Hab ich eins mit Bus "pump" ich den Kram einfach rein - natürlich auch hier so wies der Hersteller möchte - und ich bekomme was ich will.

Dann bekommst du überhaupt nichts. Das ist so als ob du irgendwas in einen
Raum reinschreist. Da wird nix passieren.

Oder seh ich das grundlegend falsch? ICh denke eigentlich nicht.

Die ganze Adressierei hab icheh nich so richtig verstanden, ich bin da noch total verwirrt von der Vorlesung

Genau so sehe ich das mal ... Ich würde mal sagen "Back to the roots" oder
wie am Flipper ... "Freispiel - du darfst nochmal"

Du brauchst ...
1. Routinen um das GLCD überhaupt anzusprechen (Daten senden/empfangen)
2. Routinen um Adressen im RAM des GLCD zu berechnen wo das Pixel hinsoll
3. Deine Zeichenroutinen die Linien, Kreise, Texte zeichnen können.

Routine 3 greift auf Routine 2 zu und die wieder auf Routine 1.

Also viel Arbeit. Du redest im Moment nur von Routine 3 und willst die Daten
ohne irgend einen Sinn und Verstand einfach zum GLCD senden. Ohne das
du dem Controller auch nur einen sinnvollen Befehl gibst oder ihm sagst
an welche Adresse des RAMs er das schreiben soll. Der macht das schon.
Ist ja alles Plug-N-Pray. Das ist es eben nicht.

Lies dir mal ein Datenblatt richtig durch und verinnerliche die interne Struktur
eines GLCDs mit dem Controller, dem RAM, usw.

Hört sich jetzt evtl ein bischen hart an aber so wird das garnix. Da hast du
nur Frust weil das GLCD dir einfach nur den Stinkefinger zeigt.

Gruß
Dino

 

[BlackDevil]

eine Leitung die mit DA bezeichnet ist, bezeichnet meist einen Daten und Adressbus. Bei RAMs ist das da so, das ich den zum Beispiel an das Modul für "externes RAM" am AVR anschliese. Ich muss mir dann für Chip Select, Read und Write einen Algorithmus oder eine Logik überlegen damit ich an die richtige Adresse schreibe wenn ich sage "schreibe an Adresse xy das und das".

Ein GLCD hat diese Leitungen ebenfalls. Und ob ich nun schreibe "Ich sag dem Controller was er zu tun hat" oder ih sage "Ich sag dem GLCD was es zu tun hat" kommt aufs selbe raus, das zweite is nur nicht so genau. Das ich nicht direkt die Pixel ansteuer ist mir durchaus klar.

Und im Falle eines Displays habe ich meine Zeilen mit Byteweise Pixeln. Will ich nun auf Pixel 20 zugreifen muss ich mir das entsprechende Byte und das entsprechende Bit rausfummeln. Das istaber nix anders wie beim RAM wenn ich in die Zelle 0x05FA schreiben will.

Und wofür gibt es Displays mit I2C denen ich die Daten fast direkt schicken kann wenn das gar nicht geht? Versteh ich noch nicht.

Nunja ich werd mir mal eines besorgen und mir das mal anschauen. Von Fleury gibt es ja auch treiber, vll kann man den Adaptieren.

Mir konnte jedenfalls noch niemand das rausfriemeln von Adressen erklären, weder in der Vorlesung noch im Netz. Vielleicht bin ich zu blöd dafür

 

[dino03]

Hi BlackDevil,

Und ob ich nun schreibe "Ich sag dem Controller was er zu tun hat" oder ih sage "Ich sag dem GLCD was es zu tun hat" kommt aufs selbe raus, das zweite is nur nicht so genau. Das ich nicht direkt die Pixel ansteuer ist mir durchaus klar.

Das ist genau das selbe. Weil du beim GLCD IMMER den Controller ansprichst.
Du kannst NICHT direkt auf das RAM zugreifen!

ATmega ------dein Datenbus------|||-----GLCD-Controller-------Grafik-RAM
eigenes Gebastel . . . . . . . . . ||| . . . . Innereien des GLCD

bei dem ||| ist der Schnitt zwischen deiner externen Welt an der du rumlötest
zur internen Welt des GLCDs. An der Stelle ist für dich Schluß mit direktem
Zugriff.

Und im Falle eines Displays habe ich meine Zeilen mit Byteweise Pixeln. Will ich nun auf Pixel 20 zugreifen muss ich mir das entsprechende Byte und das entsprechende Bit rausfummeln. Das istaber nix anders wie beim RAM wenn ich in die Zelle 0x05FA schreiben will.

Und wofür gibt es Displays mit I2C denen ich die Daten fast direkt schicken kann wenn das gar nicht geht? Versteh ich noch nicht.

Nunja ich werd mir mal eines besorgen und mir das mal anschauen. Von Fleury gibt es ja auch treiber, vll kann man den Adaptieren.

du schmeißt da einige Sachen ziemlich übel durcheinander. Mir scheint es, als
ob du im Moment den Wald vor Bäumen nicht siehst. Es ist ein riesen Unterschied
ob du direkte RAM-Adressen anlegst und dann ein Byte in die adressierte
Speicherstelle schreibst oder ob du eine Adresse für ein Register anlegst
in das dann die Adresse der RAM-Speicherstelle geschrieben wird in die
das Byte was du danach anlegst geschrieben werden soll. Beim ersten mal
hast du direkten Zugriff auf das RAM und beim zweiten mal nur INDIREKT
über die Register des Controllers. Da der Controller aber nicht nur ein Register
hat must du die ja auch irgendwie adressieren. Und diese Adresse legst du
an deinem GLCD an und NICHT die Adresse der RAM-Zelle.

Mir konnte jedenfalls noch niemand das rausfriemeln von Adressen erklären, weder in der Vorlesung noch im Netz. Vielleicht bin ich zu blöd dafür

Genau das hab ich dir erklärt. Das Problem ... Du schmeißt die Berechnung
der Speicherstelle für dein Pixel und die Ansteuerung des Controllers im GLCD
durcheinander. Das mußt du auseinanderhalten.

Gruß
Dino

 

[dino03]

Hallo BlackDevil,

ich hoffe mal, ich hab dich jetzt nich total abgeschreckt

Sieh dir mal in folgendem Datenblatt die Seiten 7+8 an.
Anhang anzeigen SED1520_DotMatrixLCD.pdf

Vor allem auf Seite 8 ist gut zu sehen das man über das Interface des
Grafik-Controllers (da kommt der AVR ran) nur auf die Register des
Controllers zugreifen kann. Das Grafik-RAM steckt auf dem Chip des
Controllers. Du hast keinen direkten Zugriff da drauf. Und das hat auch
einen wichtigen Grund.

Stell dir mal vor, der Controller will grade Daten aus dem RAM lesen um sie
auf dem Flüssigkristall anzuzeigen (irgendwie muß das ja sichtbar werden).
Wenn du jetzt einfach direkt auf sein RAM zugreiffen könntest und auf
eine andere Adresse schreiben würdest wie er grade lesen will, dann
bringst du erstens sein ganzes Display-Timing durcheinander und zweitens
würde er die Daten an der Stelle auf dem LCD anzeigen, die du grade für eine
andere Position auf dem Display geschrieben hast. Also hast du bei jedem
zugriff von dir auf das RAM des Controllers kurzzeitig Grütze auf dem LCD.

Darum auch der indirekte Zugriff über die Register des Controllers. Er nimmt
deine Daten in seinen Registern an und schreibt sie in das RAM wenn er
dafür Zeit hat und nicht wenn du das willst weil er für die Steuerung der
LCD-Signale ein festes Zeitraster hat. So wie beim Fernseher die 50Hz
Bildwiederholfrequenz. Da kannst du auch nicht einfach mal nen Bild
raus lassen weil die Elektronik auf die Fernbedienung reagieren muß

Soviel erst mal über den Zugriff auf LCD/GLCD-Displays.

Was hast du denn für Verständnisprobleme bei Adressierung ? Wie du da
letztens geschrieben hast ist da einiges unklar ... evtl kann ich ja helfen ...

Gruß
Dino

 

[BlackDevil]

Hi BlackDevil,


Das ist genau das selbe. Weil du beim GLCD IMMER den Controller ansprichst.
Du kannst NICHT direkt auf das RAM zugreifen!

ATmega ------dein Datenbus------|||-----GLCD-Controller-------Grafik-RAM
eigenes Gebastel . . . . . . . . . ||| . . . . Innereien des GLCD

bei dem ||| ist der Schnitt zwischen deiner externen Welt an der du rumlötest
zur internen Welt des GLCDs. An der Stelle ist für dich Schluß mit direktem
Zugriff.

Sag ich ja - es ist egal ob ich sag "Ich pumps ins GLCD" oder "Ich pumps in den Controller"

du schmeißt da einige Sachen ziemlich übel durcheinander. Mir scheint es, als
ob du im Moment den Wald vor Bäumen nicht siehst. Es ist ein riesen Unterschied
ob du direkte RAM-Adressen anlegst und dann ein Byte in die adressierte
Speicherstelle schreibst oder ob du eine Adresse für ein Register anlegst
in das dann die Adresse der RAM-Speicherstelle geschrieben wird in die
das Byte was du danach anlegst geschrieben werden soll. Beim ersten mal
hast du direkten Zugriff auf das RAM und beim zweiten mal nur INDIREKT
über die Register des Controllers. Da der Controller aber nicht nur ein Register
hat must du die ja auch irgendwie adressieren. Und diese Adresse legst du
an deinem GLCD an und NICHT die Adresse der RAM-Zelle.


Genau das hab ich dir erklärt. Das Problem ... Du schmeißt die Berechnung
der Speicherstelle für dein Pixel und die Ansteuerung des Controllers im GLCD
durcheinander. Das mußt du auseinanderhalten.

Gruß
Dino

Es ist auch recht verwirrend - wis auchn ich wenn etwas recht fiktiv und mengenmäsig viel ist (Adressierung und die überlegung wo wie was passiert) braucht nen MOment bis ich das ine hab, bin halt blöd


Wo ich Probleme mit der Addressierung hab? Weis ich auch nicht, damals war das im Zusammehang mit dem externen RAM-Modul vom Atmega ud damit etwas verwirrend ^^

Edit: In der PDF ist von Dot Matrix die rede, hier war aber doch von GLCDs die Rede oder?

Edit: Das Display hier hat I2C und SPI. Ich kann damit Daten zum LCD schicken. Ich versteh das so, dass ich mir da keine Gedanken zur Adressierung machen muss weil ich die Daten mit dem entsprechenden Befehl über I2C schicke und sich das LCD drum kümmert..

 

[dino03]

Hi BlackDevil,

nur schon mal ne kurze Info vorweg. Den Rest schau ich mir nochmal genau an wenn ich Zeit habe ...

Edit: Das Display hier hat I2C und SPI. Ich kann damit Daten zum LCD schicken. Ich versteh das so, dass ich mir da keine Gedanken zur Adressierung machen muss weil ich die Daten mit dem entsprechenden Befehl über I2C schicke und sich das LCD drum kümmert..

Das was du da schreibst hört sich ungefähr so an ...
Wenn ich bei Ethernet Glasfaser statt Kupfer nehme muß ich mir um die
IP-Adressen keine Gedanken mehr machen. Dann kann ich die Daten einfach
so auf das Interface pumpen.

Das eine ist die Adressierung und das andere ddie Schnittstellenphysik.

Oder anders ausgedrückt ... Layer 1/2 (SPI, I2C, Parallel) und Layer 3
(Adressierung, Daten, ...)

Was dir der Controller vom GLCD an Arbeit bei der Berrechnung abnehmen kann,
kann dir nur das Datenblatt sagen. Alles andere sind Spekulationen. Ich würde auf
jeden Fall davon ausgehen das du ziemlich viel selber machen mußt. Über alles
andere solltest du dich freuen

Gruß
Dino