Forum: Mikrocontroller und Digitale Elektronik LCD DEM240160 mit UC1698 wie Bildspeicher auslesen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Wolle G. (wolleg)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

von Wolle G. (wolleg)



Bewertung
0 lesenswert
nicht lesenswert
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.

von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
Anfrage noch einmal nach oben

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht kann ich doch noch das Interesse an dem Problem wecken.

von Tom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Funktioniert denn das Beschreiben schon richitg?
Welche Aufösung und welche Farbtiefe hat Dein Display?

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Curby23523 N. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :).

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tom (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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
von Tom (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert

von Tom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolle G. (wolleg)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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)

von Tom (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.
von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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

von Tom (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
}

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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

von Tom (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tom (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Tom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.