Wie unter Beitrag "Display DEM240160A mit UC1698u einzelne Bildpunkte setzen" schon einmal gefragt, geht es hier um das Zurücklesen von Bildspeicherzellen. Im Anhang ein Teilprogramm, wo zunächst versucht wurde, die Zeile= 100/Spalte=10 in die Zeile=102/Spalte=10 zu kopieren. Dazu wurde in die Speicherzelle geschrieben: Daten_schreiben(0x88); Daten_schreiben(0x80); Dies ergibt 3 Punkte auf dem LCD. --> i.O. Lese ich mit der Funktion: --void speicherzelle_lesen(unsigned char x_wert,unsigned char zeile)-- die Speicherzelle aus, dann erhalte ich an Stelle von 0x88, 0x80 für byte1 = 0x00 und byte2 = 0x8C. Das passt nicht zusammen. Kann jemand meine Fehler entdecken? bzw. wie macht man es richtig?
Leider noch kein Echo. Ich hänge mal das Datenblatt an. Vlt. gibt es jemanden, der Lust und Interesse hat, sich die Zusammenhänge mal näher anzusehen. Lesen und Schreiben wird auf S. 16 abgehandelt. Vielen Dank im Vorraus.
Hi Diesen Satz "For 8-bit / 16-bit interface, the first 1 byte / 2 bytes of read, respectively, is a dummy read. Please ignore the data read out." (vor (3) GET STATUS &PM) hast du gelesen? MfG Spess
spess53 schrieb: > (vor (3) GET STATUS &PM) hast du gelesen? > > MfG Spess gelesen ja. Aber, ob ich es auf Grund meiner spärlichen Englischkenntnisse richtig umgesetzt habe, ist fraglich. Deshalb u.a. auch mein Hilfeersuchen. Ich habe es so verstanden, dass man das erste byte bei der Auswertung weglassen muss. Deshalb wurden in meinem Programm 3 bytes ausgelesen. void speicherzelle_lesen(unsigned char x_wert,unsigned char zeile) { spalte =x_wert; zeile_setzen(zeile); spalte_setzen(spalte); Daten_lesen(); byte1=SP; //gelesen 0x00 Daten_lesen(); byte2=SP; //gelesen 0x8C Daten_lesen(); byte3=SP; //gelesen 0x71 } Auch wenn man byte2 und byte3 verwendet, (0x8C, 0x71) stimmt das Ergebnis nicht mit den eingegebenen Werten (0x88, 0x80) überein. Evtl. muss man die erhaltenen bytes durch Bitschubserei und Verknüpfungen noch verarbeiten? Oder, es ist der falsche Ansatz.
Vielleicht kann ich doch noch das Interesse an dem Problem wecken.
Funktioniert denn das Beschreiben schon richitg? Welche Aufösung und welche Farbtiefe hat Dein Display?
Tom schrieb: > Funktioniert denn das Beschreiben schon richitg? Ich würde sagen: Ja Nähere Einzelheiten wurden unter: Beitrag "Re: Display DEM240160A mit UC1698u einzelne Bildpunkte setzen" beschrieben. Die Funktion "void bildpunkt_setzen(void)" schreibt einen Bildpunkt in eine Spalte/Zeile. Um nun die bereits geschriebenen Punkte zu kennen, soll die Speicherzelle zunächst gelesen werden, um danach mit dem neuen Punkt verknüpft werden zu können. Jedenfalls, so hatte ich es mir gedacht > Welche Auflösung und welche Farbtiefe hat Dein Display? Es handelt sich um eine monochrome grafische Flüssigkristallanzeige mit 160 Zeilen zu je 240 Bildpunkten.
wolle g. schrieb: > Um nun die bereits geschriebenen Punkte zu kennen, soll die > Speicherzelle zunächst gelesen werden, um danach mit dem neuen Punkt > verknüpft werden zu können. > > Jedenfalls, so hatte ich es mir gedacht > >> Welche Auflösung und welche Farbtiefe hat Dein Display? > Es handelt sich um eine monochrome grafische Flüssigkristallanzeige mit > 160 Zeilen zu je 240 Bildpunkten. schreibe doch die Bildpunkte in ein µC Array dann weiss der µC welche gesetzt sind und kann diesen Inhalt ändern und dann neu schreiben. Nicht jedes Display kann rückgelesen werden und wie du merkst ist es eh nicht einfach, einfacher dein neues Bild selber in ein eigenes RAM schreiben und den Bildinhalt komplett austauschen. Bei Farb TFT kann ich z.B. den vorher gesetzen Bildpixel auf black setzen bevor ich die anderen Bildpunkte neu setze, geht schneller als alles Löschen wenn Rücklesen nicht möglich ist.
wolle g. schrieb: > Es handelt sich um eine monochrome grafische Flüssigkristallanzeige mit > 160 Zeilen zu je 240 Bildpunkten. Das sind ja gerade mal knappe 5kB. Warum behälst du nicht ein komplettes Abbild im RAM? Oder fehlt dir ausreichend RAM? Welcher Prozessor genau? Irgendwie verstehe ich nicht, was du mit der Verknüpfung bereits vorhandener/nicht vorhandener Pixel erreichen willst.
So ganz komm ich nicht mit: Du hast ein monochromes Display. Darunter verstehe ich 1 Bit pro Pixel (schwarz/weiss). Im Datenblatt vom Controller steht aber was von 12 bzw. 16 Bit pro Pixel. Das können auch Graustufen sein. Warum schreibst Du 0x8880 (0b1000 1000 1000 0000) um einen Pixel zu setzen? Warum nicht 0xFFFF? Was wird zurückgelesen, wenn Du 0xFFFF in den Pixelspeicher schreibst? Hast Du ein Oszilloskop um die Signale zu prüfen?
Tom schrieb: > Im Datenblatt vom Controller steht aber was von 12 bzw. 16 Bit pro > Pixel. WO bitte liest du das? Dies ist ein klassisches monochromes Display, welcher parallel oder mit SPI betrieben werden kann :).
wolle g. schrieb: > Tom schrieb: >> Funktioniert denn das Beschreiben schon richitg? > Ich würde sagen: Ja > Nähere Einzelheiten wurden unter: > Beitrag "Re: Display DEM240160A mit UC1698u einzelne Bildpunkte setzen" > beschrieben. Ob das Beschreiben tatsächlich so richtig ist, das kann ich nicht beurteilen. Aber ich kann jeden beliebigen Punkt auf der Anzeige setzen. Nach meinen Kenntnissen besteht die Anzeige aus 160 Zeilen (y-wert) und 80 Spalten zu jeweils 3 Bildpunkten-->240 Bildpunkte (x-wert) H.Joachim S. schrieb: > Warum behälst du nicht ein komplettes > Abbild im RAM? Wenn ich es richtig verstanden habe, dann hat der UC1698 bereits einen Bildspeicher und es gibt auf Seite 16 des DB. auch den Befehl zum Auslesen. Ich hoffte, ich finde hier im Forum auf die Schnelle Jemanden, der schon weiter ist, als ich es bin. Nachdem jetzt die Diskussion anläuft, habe ich jetzt wieder Hoffnung geschöpft, um das Problem zu lösen. > einfacher dein neues Bild selber in ein eigenes RAM > schreiben und den Bildinhalt komplett austauschen. Einen kompletten Austausch will ich ja gerade vermeiden. Die EKG-Kurve soll sich punktweise verfolgen lassen, damit keine Punkte verloren gehen. (kontinuierliche Aufzeichnung des Signals) Im Prinzip läuft es schon. Nur dann, wenn 3 hintereinander folgende Punkte einer Spalte in einer Zeile (Speicherzelle) dargestellt werden sollen, dann fehlen an dieser Stelle 2 Punkte.
wolle g. schrieb: > Einen kompletten Austausch will ich ja gerade vermeiden. > Die EKG-Kurve soll sich punktweise verfolgen lassen warum soll das mit meinem Vorschlag nicht gehen? Wie lange dauert ein komplettes Beschreiben vom Display? Wie schnell kann man Änderungen erfassen? Es ist Unsinn schneller zu Schreiben als man es auf dem Display verfolgen kann! Für meine Uhranzeige oder ADC Werte gebe ich genau 4x in einer Sekunde ein LCD update. Ich verstehe nicht was du mitteilen möchtest, du kannst ja 100x schneller werden, nur sieht das niemand mehr oder das wird ein Geflimmer auf der Anzeige.
Angehängte Dateien:
-
uc1698_read.png
140 KB
Curby23523 N. schrieb: > WO bitte liest du das? Im zweiten Beitrag ist ein Datenblatt angehangen. Da steht auf der Titelseite: w/ 16-bit per RGB On-Chip SRAM Auf Seite 16 ist das Lesekommando beschrieben (siehe Anhang). Das sieht für mich nicht nach 1 Bit/Pixel aus... Ob Code, Displaycontroller und verwendetes Display zusammenpassen, weiß ich nicht.
Joachim B. schrieb: > warum soll das mit meinem Vorschlag nicht gehen? > > Wie lange dauert ein komplettes Beschreiben vom Display? > Wie schnell kann man Änderungen erfassen? > Es ist Unsinn schneller zu Schreiben als man es auf dem Display > verfolgen kann! Dein Vorschlag würde schon gehen. Aber mir gefällt die Methode des Bildtausches nicht. Ich habe zwischenzeitlich schon mehrere "EKG-Geräte" gebaut. U.a auch mit einem sogn. e-paper. Hier reizte mich vor allem die kleine Bildgröße bei rel. hoher Auflösung und dem Kontrast bei Sonneneinstrahlung. Ich möchte ca. 2 Herzschläge sehen und habe deshalb aktuell für 240 Bildpunkte eine Abtastrate von 7,5ms gewählt, d.h. es werden 1,8s dargestellt. Dann wird gelöscht und die Kurve baut sich danach wieder kontinuierlich neu auf. Bei dem sogn. e-paper wurde das Austauschverfahren angewendet. Mich störte daran, dass ein Teil der Bilddaten verloren gegangen sind. (Löschzeit, neues Bild aufbauen) sowie die Wartezeit. Aber das kann bei jedem anders sein. Zwischenzeitlich sind die e-paper "gestorben". Warum??
:
Bearbeitet durch User
wolle g. schrieb: > Aber mir gefällt die Methode des Bildtausches nicht. wieso? ob du nun den Bildpunkt aus dem Display ausliest, löschst und neu schreibst oder ob du den Bildpunkt aus dem Schattenram ausliest auf Null setzt den neuen schreibst und nur die Änderungen also 2 Bildpunkte überträgst den gelöschten und den neuen PBildpunkt ist doch dasselbe. Es muss nicht zwingend der ganze screen neu beschrieben werden und evtl. gehts im µC Ram schneller als das Auslesen und Setzen aus/zu dem epaper. wolle g. schrieb: > Zwischenzeitlich sind die e-paper "gestorben". Warum?? dazu lieferst du zuwenig Infos 1. Verdrahtungsfehler 2. Pech 3. falsche Spannung 4. mech. Beanspruchung 5. kein run IN, kein burn IN durchlaufen (Badewannenkurve) 6. Ausschußware die die Tests ab Werk nicht genügten und so nebenbei in den Handel kamen die Möglichkeiten warum was kaputt geht gibts ja viele.
Joachim B. schrieb: > wolle g. schrieb: >> Zwischenzeitlich sind die e-paper "gestorben". Warum?? > dazu lieferst du zuwenig Infos > 1. Verdrahtungsfehler > 2. Pech Das "warum" war nicht so ernst gemeint. 1x Flachbandkabelverbindung zerstört (mein Verschulden), 2x unbekannte Ursachen (Pech?) Curby23523 N. schrieb: > Tom schrieb: >> Im Datenblatt vom Controller steht aber was von 12 bzw. 16 Bit pro >> Pixel. > > WO bitte liest du das? Dies ist ein klassisches monochromes Display, > welcher parallel oder mit SPI betrieben werden kann :). Kann es sein, dass Du das Display näher kennst? Welchen Fehler könnte ich gemacht haben? bzw. welche Möglichkeiten gibt es, um den Bildspeicher auszulesen?
:
Bearbeitet durch User
Tom schrieb: > Hast Du dieses Display? > http://www.display-elektronik.de/filter/DEM240160A_FGH-PW.pdf Ja!!
wolle g. schrieb: > Ja!! Ok. Und wie sind bei Dir Pin 11 und Pin 12 (BM0/BM1) beschalten? Das sollte man mit dem Multimeter prüfen können.
Angehängte Dateien:
-
141-5c_FKA_240x160_EKG8-.TIF
150 KB
Tom schrieb: > Ok. Und wie sind bei Dir Pin 11 und Pin 12 (BM0/BM1) beschalten? ich hänge mal den Schaltplan an. (ohne EKG-verstärker)
Angehängte Dateien:
-
4wire.png
85 KB
wolle g. schrieb: > ich hänge mal den Schaltplan an. Als PNG hätte es mein Browser direkt anzeigen können. Außerdem: die GND-Leitung ganz 'oben' lang zu ziehen, ist recht verwirrend. Bei mir kommt GND 'unten' hin oder bei einer bipolaren Versorgung in die Mitte. Zum Thema: BM0 und BM1 liegen (lt. Plan) auf GND. Damit wird (zusammen mit DB13 und DB15) der 4-wire-SPI-mode aktiviert. Als erstes lese ich da im Datenblatt (Seite 41) das in diesem Modus nur Schreiben unterstüzt wird. Wenn Du zurücklesen willst, wirst Du auf einen parallelen Mode umschwenken müssen.
Beitrag #5402027 wurde vom Autor gelöscht.
Tom schrieb: > Als PNG hätte es mein Browser direkt anzeigen können. Ein Bilddateiexport als *.png ist bei Target 3000 nicht möglich, nur *.tif habe ich gefunden > Außerdem: die GND-Leitung ganz 'oben' lang zu ziehen, ist recht > verwirrend. > Bei mir kommt GND 'unten' hin oder bei einer bipolaren Versorgung in die > Mitte. Es gibt bei meinem Gerät zwei verschieden Masseleitungen, für digitale Signale --> DVss und für analoge Signale--> AVss Beide Masseleitgn. werden erst im Sternpunkt an der Batterie zusammen geführt. Normalerweise ist bei mir Masse auch "unten" und zusätzlich noch in doppelter Strichstärke oder als Symbol Tom schrieb: > Wenn Du zurücklesen willst, wirst Du auf einen parallelen Mode > umschwenken müssen. M. E sollten meine Schaltung und das Programm dem parallelen 8080/8bit-Modus entsprechen. Seite 7 -- BM0 und BM1 = 0
Angehängte Dateien:
-
141-5c_FKA_240x160_EKG8--1.png
59 KB -
BM0_BM1.png
78 KB -
parallel_mode.png
42 KB
wolle g. schrieb: > Ein Bilddateiexport als *.png ist bei Target 3000 nicht möglich, nur > *.tif habe ich gefunden Dann verwende einen Bildkonverter. Ich kann z.B. Irfanview empfehlen. > M. E sollten meine Schaltung und das Programm dem parallelen > 8080/8bit-Modus entsprechen. Seite 7 -- BM0 und BM1 = 0 Da habe ich nicht genau genug hingeschaut. Nicht nur BM0 und BM1 sind entscheidend, sondern auch DB13 und DB15. > Es gibt bei meinem Gerät zwei verschieden Masseleitungen, für digitale > Signale --> DVss und für analoge Signale--> AVss In Deinem Fall würde ich DB15 nicht an AVss sondern an DVss anzuschließen. Laut Deinem Schaltplan hängt AVss vom Controller nur an DB15. Ist das richtig so? Trotzdem scheint der 8080/8-Bit-Mode aktiv zu sein. Warum verwendest Du unötigerweise globale Variablen beim zurücklesen? Hast Du zuviel Assembler programmiert? Ich würde das so schreiben:
1 | unsigned char Daten_lesen(void)// WR=1 --> Daten aus Bild-RAM holen uc1698 |
2 | {
|
3 | unsigned char value; |
4 | // 5.4 5.3 5.2 5.1 5.0
|
5 | // RD WR RST CD CS
|
6 | P4DIR = 0x00; // 0x00 --> setzt P4 als Eingang, 0xff setzt P4 als Ausgang |
7 | P5OUT = 0x1e; // 1 1 1 1 0 |
8 | P5OUT = 0x0e; // 0 1 1 1 0 CS=0 = aktiv |
9 | P5OUT = 0x1e; // 1 1 1 1 0 |
10 | value = P4IN; |
11 | P5OUT = 0x1f; // 1 1 1 1 1 |
12 | return value; |
13 | }
|
14 | ...
|
15 | byte1 = Daten_lesen(); |
16 | byte2 = Daten_lesen(); |
17 | byte3 = Daten_lesen(); |
Außerdem hätte ich mir für die Displaykommandos ein nettes Headerfile geschrieben um lesbaren Code zu haben. Also so
1 | Steuerbefehl(SET_POWERCONTROL|3); |
2 | Steuerbefehl(SET_TEMPCOMP|1); |
3 | Steuerbefehl(SET_LCDMAPPING|6); |
4 | Steuerbefehl(SET_RAMADDRCONTROL|1); |
5 | Steuerbefehl(SET_COLORPATTERN|0); |
6 | ...
|
statt so
1 | Steuerbefehl(0x2B); /* set internal power control:13nF<LCD capacitance loading <22nF, 0010 1011 */ |
2 | Steuerbefehl(0x25); /* Set Vbias temperature compensation to -0.05%/Degree C, 0010 0101*/ |
3 | Steuerbefehl(0xC6); /* Set SEG from SEG384-->SEG1 COM from COM1--> COM160,alt=0xc2, 1100 0010 */ |
4 | Steuerbefehl(0x89); /* Set RAM address control: 0x88 to 0x8F, 1000 1001 */ |
5 | Steuerbefehl(0xD0); |
Mit welcher Taktfrequenz betreibst Du Deinen Mikrocontroller? Warum deaktivierst Du /RD bevor Du den Wert eingelesen hast? Probiere das mal aus:
1 | unsigned char Daten_lesen(void)// WR=1 --> Daten aus Bild-RAM holen uc1698 |
2 | {
|
3 | unsigned char value; |
4 | // 5.4 5.3 5.2 5.1 5.0
|
5 | // RD WR RST CD CS
|
6 | P4DIR = 0x00; // 0x00 --> setzt P4 als Eingang, 0xff setzt P4 als Ausgang |
7 | P5OUT = 0x1e; // 1 1 1 1 0 |
8 | P5OUT = 0x0e; // 0 1 1 1 0 CS=0 = aktiv |
9 | value = P4IN; |
10 | P5OUT = 0x1f; // 1 1 1 1 1 |
11 | return value; |
12 | }
|
Tom schrieb: > Laut Deinem Schaltplan hängt AVss vom Controller nur an DB15. > Ist das richtig so? Eigentlich nicht ganz. Bei der gefertigten Leiterplatte fehlte ursprünglich der Anschluss D15 an der Buchse. War nachträglich die einfachste Korrekturlösung. >Dann verwende einen Bildkonverter. Ich kann z.B. Irfanview empfehlen. Wenn ich *.tif aufrufe, dann wird bei mir zum Öffnen Microsoft Office Document imaging vorgeschlagen. --> funktioniert >Warum verwendest Du unötigerweise globale Variablen beim zurücklesen? >Hast Du zuviel Assembler programmiert? >Ich würde das so schreiben: Ich bin nur ein Programmierlaie und solche Feinheiten kann ich gar nicht beurteilen. Eigentlich kann ich auch Englisch an Stellen, wo man genauso gut Deutsch verwenden kann, nicht leiden. Dadurch ist es für mich auch nach Jahren das Programm noch gut lesbar >Warum deaktivierst Du /RD bevor Du den Wert eingelesen hast? >Probiere das mal aus: Ich denke, es muss zum Auslesen eine steigende Flanke an RD erzeugt werden und das, bevor CS=1 wird. (S.40, aber so richtig habe ich es noch nicht verstanden) Ich hoffe ja immer noch, dass jemand schon weiter ist als ich
Angehängte Dateien:
-
timings.png
13 KB
wolle g. schrieb: > Wenn ich *.tif aufrufe, dann wird bei mir zum Öffnen Microsoft Office > Document imaging > vorgeschlagen. --> funktioniert Schön für Dich. Ich habe hier nirgends einen Rechner auf dem Windows läuft... Tom schrieb: > Mit welcher Taktfrequenz betreibst Du Deinen Mikrocontroller? > Warum deaktivierst Du /RD bevor Du den Wert eingelesen hast? Warum beantwortest Du meine Fragen nicht? Wenn /RD auf low geht, kommen spätestens nach 60 ns die Daten. Wenn Du /RD wieder hoch ziehst, hast Du noch 15 ns Zeit die Daten zu lesen. Mehr garantiert das Datenblatt nicht. Also: Schritt 1: /CS auf low ziehen Schritt 2: /RD auf low ziehen Schritt 3: 60 ns warten Schritt 4: Daten einlesen Schritt 5: /RD und /CS wieder auf high legen
Tom schrieb: >> Mit welcher Taktfrequenz betreibst Du Deinen Mikrocontroller? Die Taktfrequenz beträgt 8MHz, also rel. langsam. > Also: > Schritt 1: /CS auf low ziehen > Schritt 2: /RD auf low ziehen > Schritt 3: 60 ns warten > Schritt 4: Daten einlesen > Schritt 5: /RD und /CS wieder auf high legen Deinen Vorschlag habe ich getestet. Leider das gleiche falsche Ergebnis. als Schritt 3 habe ich eine Verzögerung __delay_cycles(1)--> 125ns eingebaut (wenn ich richtig gerechnet habe). Irgendwo ist noch der Wurm drin.
Angehängte Dateien:
-
64k_mode.png
39 KB -
read_data_format.png
35 KB
wolle g. schrieb: > Irgendwo ist noch der Wurm drin. 1. In Deinem Code steht:
1 | // 5.4 5.3 5.2 5.1 5.0 |
2 | // RD WR RST CD CS |
Aus dem Schaltplan entnehme ich: P5.0 = Display Pin 17, RST P5.1 = Pin 16, WR0 (/WR) P5.2 = Pin 15, WR1 (/RD) P5.3 = Pin 14, CD P5.4 = Pin 13, CS0 Wie ist denn die tatächliche Verschaltung? 2. Du verwendest in der Initialisierung den 4k-Mode:
1 | Steuerbefehl(0xD5); /* Set color mode to 4K color, 1101 0101*/ |
Dabei werden drei Bytes zum Display gesendet um damit zwei Pixel zu setzen. Um es erstmal zu vereinfachen würde ich den 64k-Mode verwenden:
1 | Steuerbefehl(0xD6); /* Set color mode to 64K color, 1101 0110*/ |
Pixel setzen sollte dann so gehen:
1 | void bildpunkt_setzen( |
2 | unsigned char spalte, |
3 | unsigned char zeile, |
4 | unsigned char rot, // 0..31 (0x00..0x1f) |
5 | unsigned char gruen, // 0..63 (0x00..0x3f) |
6 | unsigned char blau) // 0..31 (0x00..0x1f) |
7 | {
|
8 | zeile_setzen(zeile); |
9 | spalte_setzen(spalte); |
10 | Daten_schreiben( (rot << 3) | (gruen >> 3)); |
11 | Daten_schreiben( ((gruen & 0x7) << 5) | (blau); |
12 | }
|
Das Format entspricht dem, was dann im Speicher steht und so auch wieder ausgelesen werden kann.
Hallo Tom, > Um es erstmal zu vereinfachen würde ich den 64k-Mode verwenden: > Steuerbefehl(0xD6); /* Set color mode to 64K color, 1101 0110*/ Das war ein sehr guter, wenn nicht, sogar der entscheidende Vorschlag. Recht vielen, vielen Dank für Deine Geduld mit mir. Zum Testen habe ich Deinen Vorschlag etwas abgewandelt: Für Daten_schreiben( (rot << 3) | (gruen >> 3)); Daten_schreiben( ((gruen & 0x7) << 5) | (blau); habe ich z. B. für den ersten Punkt Daten_schreiben(0xF0); Daten_schreiben(0x00); für den zweiten Punkt Daten_schreiben(0x0F); Daten_schreiben(0x00); oder 1. und 3.Punkt Daten_schreiben(0xF0); Daten_schreiben(0xF0); geschrieben. Jedenfalls erscheinen in der Speicherzellenkopie (im meinem Beispiel Zeile 102/Spalte 10) jetzt die Bildpunkte an der richtigen Stelle. > Wie ist denn die tatächliche Verschaltung? Die Frage ist berechtigt. Schaltplan und verwendete Schaltung stimmen nicht überein. Im Prinzip, richtiger Mist. Es gibt bei mir das EKG-Gerät und eine Versuchsanlage zum Experimentieren, wo über Stiftleisten alle µC –Anschlüsse zugänglich sind. Meine hier gezeigten Testprogramme waren auf die Versuchsanlage zugeschnitten. mal etwas anderes: Der Ansteuerschaltkreis U1698 ist doch, so sehe ich das, für eine farbliche Darstellung gedacht. Dafür gibt es RGB-Dioden. o.ä Nun meine Frage: Wie macht man aus den unterschiedlichen Werten R4,R3,R2,R1,R0 usw. die unterschiedlichen Farben? Oder, wo könnte man nachlesen?
wolle g. schrieb: > Wie macht man aus den unterschiedlichen Werten > R4,R3,R2,R1,R0 usw. die unterschiedlichen Farben? Üblicherweise ist R4 das MSB und R0 das LSB. Du kannst mit 5 Bit 32 'Rotstufen' machen. Für grün gibt es meistens ein Bit mehr, das Auge ist da empfindlicher und bei 5 Bit pro Frabe würde eins übrigbleiben. Bei einem ähnlichen Display mit 64k-Farbe habe ich ungefähr sowas im Quellcode stehen:
1 | #define BLACK 0x0000
|
2 | #define RED 0xf800
|
3 | #define GREEN 0x07e0
|
4 | #define BLUE 0x001f
|
5 | #define YELLOW 0xffe0
|
6 | #define WHITE 0xffff
|
Vergleiche mit der Speicherbelegung weiter oben und Du erkennst das Muster :-) Die restliche Theorie steht hier: https://de.wikipedia.org/wiki/Additive_Farbmischung Dein Display missbraucht offenbar einen Farbdisplaycontroller für ein monochromes Display. Da entspricht je eine Farbe einem Pixel. Ich versuche solche Spezialfälle immer in den Zugriffsfunktionen zu verstecken, damit man später 'Standardroutinen' für Textausgabe, Linien, Kreis u.ä. verwenden kann.
Tom schrieb: > Üblicherweise ist R4 das MSB und R0 das LSB. Du kannst mit 5 Bit 32 > 'Rotstufen' machen. Für grün gibt es meistens ein Bit mehr, das Auge ist > da empfindlicher und bei 5 Bit pro Frabe würde eins übrigbleiben. Das mit der Farbmischung hatte ich mir schon gedacht. Um aus den 5 Bit 32 'Rotstufen' machen zu können, bräuchte man dann doch noch tausende Digital-Analogwandler? Oder wie könnte das funktionieren?
Das ursprüngliche Problem ist zwischenzeitlich gelöst. Wen es interessiert, findet unter Beitrag "MSP430F1611- gegenseitige Beeinflussung der Timer?" ein Programmbeispiel. Passt zwar nicht direkt zum Thema, aber gibt es eine Erklärung zu wolle g. schrieb: > Das mit der Farbmischung hatte ich mir schon gedacht. > Um aus den 5 Bit 32 'Rotstufen' machen zu können, bräuchte man dann > doch noch tausende Digital-Analogwandler? Oder wie könnte das > funktionieren?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.