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 ;-)
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.
1
PORTC = 0b00010010; //Set controller 1 ON
2
En_H; //68er MPU Enable HIGH
3
PORTD = 0b10101111;
4
En_L; //68er MPU Enable LOW
5
PORTC = 0b00010100; //Set controller 2 ON
6
En_H;
7
PORTD = 0b10101111;
8
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.
1
void writeData( uint8_t byte )
2
{
3
A0 auf High Modus einstellen: Write data
4
R/W auf Low
5
6
Datenbyte anlegen Danach die Daten
7
8
Enable auf High jetzt gilts: mach mal
9
Enable auf Low
10
}
11
12
void writeCommand( uint8_t byte
13
{
14
A0 auf Low Modus einstellen: Write Command
15
R/W auf Low
16
17
Datenbyte anlegen Das Commando auf den Bus
18
19
Enable auf High .... und: mach mal
20
Enable auf Low
21
}
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 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
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
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
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.
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.
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.
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: