LCD Dot-Matrix 122x32 - Befehle ok, aber keine Daten

[Dex (Gast)]

Hallo zusammen,

jetzt muss ich doch mal hier nachfragen. Hab jetzt schon mehrere Tage 
lang rumgefrickelt, aber jetzt bin ich doch mit meinem Latein am Ende. 
Vielleicht kann mir hier jemand helfen.

Es geht um ein Pollin LCD-12232 Display. Bzw. um den darauf verbauten 
SED1520 (2x) Controller.
Ich habe schon diverse Bibliotheken dazu gefunden und ausprobiert, 
jedoch ohne Erfolg.
Schließlich bin ich dazu übergegangen das Datenblatt zu wälzen und hab 
die entsprechenden Befehle zu Testzwecken erst mal hard-codiert. Also 
die entsprechenden Bits einfach auf die zugehörigen Pins geschaufelt.
Ergebnis dabei:
Ich schaffe es das Display an uns aus zu machen und den Befehl "Static 
Drive ON" bzw OFF auszuführen.
Damit ist dann aber auch Ende.
Immerhin zeigt mir, dass der Befehl "Static Drive ON" funktioniert, dass 
das Display offenbar richtig angeschlossen ist und ich die Befehle 
richtig zusammensetze.
Aber ich schaffe es nicht irgendetwas anderes zu tun.
Wenn ich Daten schreiben möchte, egal was, passiert einfach garnichts. 
Kein zucken keine verirrten Pixel. Null.
Ich fürchte, ich übersehe einfach irgendetwas, worauf ich aber gerade 
ums verrecken nicht komme. Das Display scheint ja in Ordnung zu sein.
Vielleicht hat jemand ja mal nen Tip.
Ich bedanke mich schon mal. :)

Ich häng meinen Testcode mit an. Wie gesagt, das ist einfach nur 
Bitgeschubse frei nach Datenblatt, nix Schönes ;-)

#define F_CPU 16000000UL

#define SED1520_A0 (1 << 0)
#define SED1520_E1 (1 << 1)
#define SED1520_E2 (1 << 2)
#define SED1520_RW (1 << 3)
#define SED1520_RES (1 << 4)
#define SED1520_En (1 << 5)

#define En_L _delay_us(100); PORTC &= ~SED1520_En
#define En_H PORTC |= SED1520_En; _delay_us(100)

#include <util/delay.h>
#include <avr/io.h>
#include "SED1520_DG/SED1520.h"

int main(void)
{
  DDRD = 0xFF;      //PORTD: OUT
  DDRC = 0xFF;      //PORTC: OUT
  PORTC = 0x00;
  PORTD = 0x00;      //Reset PORTC/D
  
  PORTC = 0b00010000;    //Reset Display
  _delay_us(100);
  PORTC = 0b00000000;
  _delay_us(100);
  PORTC = 0b00010000;    //Reset HIGH --> 68er MPU
  _delay_us(100);
  
  PORTC = 0b00010010;    //Set controller 1 ON
  En_H;        //68er MPU Enable HIGH
  PORTD = 0b10101111;
  En_L;        //68er MPU Enable LOW
  PORTC = 0b00010100;    //Set controller 2 ON
  En_H;
  PORTD = 0b10101111;
  En_L;
    
  PORTC = 0b00010011;    //Write data to controller 1
  En_H;
  PORTD = 0b10101011;    //Data
  En_L;
  PORTC = 0b00010101;    //Write data to controller 2
  En_H;
  PORTD = 0b10101111;    //Data
  En_L;
  _delay_ms(2000);
  
    while(1)   //Blink display
    {
    _delay_ms(500);
    PORTC = 0b00010010;    //Controller 1
    En_H;
    PORTD = 0b10100101;    //Static drive ON
    En_L;
    
    _delay_ms(500);
    PORTC = 0b00010010;    //Controller 1
    En_H;
    PORTD = 0b10100100;    //Static drive OFF
    En_L;
  }
}

[Karl H. (kbuchegg)]

Ich hb mir bei meinen Versuchen immer etwas zur Regel gemacht

Ich halte die Steuerleitungen im inaktiven Zustand.

Falls es irgendwelche offensichtlichen Modusleitungen gibt, dann werden 
die hetzt eingestellt

Danach werden die Datenleitungen angelegt

Und erst dann generiere ich die jeweiligen Steuerpulse, in dem ich aus 
dem inaktiven Zustand in den aktiven und wieder zurück schalte.

Der Trick an der ganzen Sache besteht darin, zu identifizieren mit 
welcher Leitung ganz zum Schluss gewackelt werden muss, damit der andere 
Baustein zu arbeiten anfängt.

  PORTC = 0b00010010;    //Set controller 1 ON
  En_H;        //68er MPU Enable HIGH
  PORTD = 0b10101111;
  En_L;        //68er MPU Enable LOW
  PORTC = 0b00010100;    //Set controller 2 ON
  En_H;
  PORTD = 0b10101111;
  En_L;

so ein Durcheinander mit Datenanlegen und Pulsgenerierung gibt es bei 
mir ganz selten. Und meistens funktionieren die Dinge bei mir auf 
Anhieb, wobei es dann auch ziemlich egal ist, ob der Baustein die 
fallende oder die steigende Flanke zur Datenübernahme benutzt.

Und bevor ich laufend solche Portorgien schreibe, schreibe ich mir 
einmalig eine Funktion (in diesem Fall dann eben 2 Funktionen), in denen 
ich die Übertragung gestalte. Das ist mir nämlich persönlich zu blöd, da 
jedes mal rumzufrickeln und im Code per Copy/Paste das nächste Kommando 
auszuprobieren. Da ist es dann auch kein Problem mehr, in diesen 
Funktionen die Pinnamen zu benutzen und nicht irgendwelche Binärorgien, 
bei denen ich ständig kontrollieren muss, ob ich mich bei den 0-en und 
1-en nicht irgenwo verzählt habe. Wenn ich dann auch noch aufpasse, ob 
im Datenblatt über dem Signalnamen ein Strich ist, dann ist die Sache 
recht einfach.

void writeData( uint8_t byte )
{
  A0 auf High                 Modus einstellen: Write data
  R/W auf Low

  Datenbyte anlegen           Danach die Daten

  Enable auf High             jetzt gilts: mach mal
  Enable auf Low
}

void writeCommand( uint8_t byte
{
  A0 auf Low                  Modus einstellen: Write Command
  R/W auf Low

  Datenbyte anlegen           Das Commando auf den Bus

  Enable auf High             .... und: mach mal
  Enable auf Low
}

Das einzige was jetzt noch sein kann, das ist, dass da ein paar delay 
notwendig sind. Da halte ich mich daran, dass man meistens beliebig 
langsam takten darf und fang erst mal grosszügig an. Schneller stellen 
kann  ich dann immer noch.

[Karl H. (kbuchegg)]

Karl Heinz schrieb:

> Das einzige was jetzt noch sein kann


In deinem Fall kommt dann noch die Aufteilung auf die beiden Controller 
dazu, die richtige Verteilung über die Chip Select Leitungen

[Dex (Gast)]

Danke erst mal für die ausführliche Antwort.
Das Bitgeschubse war eh nur zu Testzwecken, als fertiges Programm hätte 
ich das nie gemacht ;-)
Aber auch, wenn ich das mit einer Funktion in der beschriebenen Form 
mache, dann hab ich dasselbe Ergebnis.
Nur Static ON/OFF funktioniert, Daten schreiben funktioniert nicht.
Allerdings ist mir grad aufgefallen, dass der Controller das eigentlich 
garnicht können dürfte, was er tut^^
Wenn ich mit dem Static ON nur einen Controller anspreche, dann ist die 
untere (oder obere, je nach Controller) Hälfte des Displays an. Das 
wären dann 16*122 Pixel.
Eigentlich kann der SED1520 doch nur 16*61 Pixel maximal, oder hab ich 
da was missverstanden?
Vielleicht hat ja doch das Display ne Macke weg. Wenn die die untere 
oder obere Hälfte leuchtet, würde das ja bedeuten, dass beide Controller 
zur Hälfte arbeiten. Wenn man genau hinsieht, erkennt man auch, dass in 
dem Streifen die linke Hälfte etwas dunkler ist als die rechte. (Sieht 
man leider nicht mit meiner Handycam, sonst würd ich ein Bild machen)
Ich glaub ich kauf mir einfach ein anderes Display.
Danke trotzdem für die Hilfe

[spess53 (Gast)]

Hi

>Wenn ich mit dem Static ON nur einen Controller anspreche, dann ist die
>untere (oder obere, je nach Controller) Hälfte des Displays an. Das
>wären dann 16*122 Pixel.
>Eigentlich kann der SED1520 doch nur 16*61 Pixel maximal, oder hab ich
>da was missverstanden?

Ja. Der SED1520 kann max. 80x32 Pixel treiben. Bei dem Display bedient 
jeder Controller 61x32 Pixel (rechte und linke Displayhälfte). Welches 
Pollin-Display meinst du eigentlich genau?

MfG Spess

[OldMan (Gast)]

Ist Dir im Datenblatt und auch in der kurzen Beschreibung folgendes 
aufgefallen:
PIN 4 CL H/L External Clock (2KHz)

Der Takt muss permanent anliegen, sonst tut sich nichts.

[Dex (Gast)]

Pollin vertreibt das unter DG-12232. Unter der Haube stecken zwei 
SED1520.
Der Takt wird von nem NE555 mit RC-Kreis geliefert. Nachgemessen: 
1,98kHz 0/5V liegt an. Allerdings keine 50% Dutycycle sondern eher 70%. 
Aber das sollte nix ausmachen.
Der SED1520 hat 16COM Ports und 61SEG Ports (80 hat der SED1521), also 
sollte der doch eigentlich nur 16x61 Pixel schaffen, oder? Mich 
irritiert grad, dass der die 16COMs irgendwie auf 32 aufbohrt. Aber das 
sind technische Details, die wsh nix mit meinem Problem zu tun haben.

[spess53 (Gast)]

Hi

Diese Bemerkung in der Beschreibung:

LCD-Kontrastspannung –5...0 V

Ist dir schon aufgefallen?

MfG Spess

[Dex (Gast)]

Jep, hab ich gesehen.
Liegt aktuell auf GND. Wenn ich das Display mit Static ON einschalte, 
sit der Kontrast ok. Dafür lohnt es sich nicht eine Ladungspumpe zu 
bauen.
Hab auch Testweise mal eine 1,5V Batterie angeschlossen ohne 
Veränderung.

[spess53 (Gast)]

Hi

> Wenn ich das Display mit Static ON einschalte,
>sit der Kontrast ok.

Lass doch das Gefummel mit Static ON.

Ich habe mal meine uralte Init, allerdings in Assembler, herausgekramt. 
Die sieht so aus und hat vor 15 Jahren problemlos funktioniert:

                   .cseg

initdisp:          select2                  ;2.Hälfte initialisieren
                   rcall initdisp10
                   select1                  ;1.Hälfte initialisieren 
initdisp10:        nop
                   nop
                   sbi ctl_out,resx         ;68-mode
                   ldi r17,dispoff           ;Display off
                   rcall wr_cmd

                   lds r17,line1
                   ori r17,strtline         ;startline 0
                   rcall wr_cmd

                   ldi r17,adccw            ;ADC forward
                   rcall wr_cmd

                   ldi r17,statcoff         ;normal
                   rcall wr_cmd

                   ldi r17,duty32           ;Duty 1/32
                   rcall wr_cmd

                   lds r17,page1
                   ori r17,pageadr
                   rcall wr_cmd             ;Page setzen

                   lds r17,col1
                   ori r17,setcol           ;spalte 0
                   rcall wr_cmd

                   ldi r17,rmwend           ;read-modify-Write off
                   rcall wr_cmd

                   ldi r17,dispon           ;Display on
                   rcall wr_cmd

                   rcall clrdisp
                   ret

MfG Spess