mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Pollin TIAN MA A2C00096100 LCD Modul


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.
Autor: google (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das derzeit bei Pollin erhältliche Automotive Display 
https://www.pollin.de/p/lcd-modul-tian-ma-a2c00096100-121581 hat mit an 
Sicherheit grenzender Wahrscheinlichkeit einen PCF2119 als Controller, 
siehe Anhänge. Das ist eine Info, die dem beigefügten "Datenblatt" 
fehlt.

Achtung, elektrisch noch nicht getestet.

Autor: google (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte leider ein falsche Datei angehängt.

Autor: Mario L. (mlatzig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tipp!

Ich war gerade provisorisch dabei, mittels Breadboard das LCD mal 
anzusteuern, mache aber nun für heute Schluss... Hier nun mein 
enttäuschendes Ergebnis:

Ich habe mein Display erst mit 5V betrieben. Obwohl ich mich mit 
Bitbanging durch alle Adressen durchgehangelt hatte, habe ich keinen Ack 
vom LCD zurückbekommen.

Dann habe ich die Betriebsspannung für mein Dev-Board auf 3,3V 
runtergeregelt, nun bekomme ich beim Slave Address Byte mit 0b01110101 = 
0x75 (also SA=0,RW=1) ein Ack, seltsamerweise bei 0b01110100 = 0x74 kein 
Ack (RW=0). Auch wenn ich in allen Fällen noch, wie im Datenblatt 
beschrieben, versuche ein Control Byte (z.B. 0x00) und Daten Byte zu 
senden, bekomme ich darauf folgend kein Ack mehr. Bei mir ist also 
einiges noch im Argen (evtl. sollte ich es mit einem anderen 
Widerstandswert bei den Pull-Ups als mit 4,7k probieren)...

Da ich aber bei der o.g. Adresse eine Reaktion erhalte, vermute ich, 
dass dein Tipp für den PCF2119 schon mal nicht so verkehrt sein kann :-) 
Falls du oder jemand anderes es praktisch ausprobiert, gibt es 
vielleicht mehr Erfolg.

: Bearbeitet durch User
Autor: google (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Beschaltung stimmt? Zwischen VDD und VSS sowie zwischen VLCD und VSS 
je ein 1µF-Kondensator? Mit 5V sollte es auch gehen.

Kann leider gerade nicht testen.

Autor: Mario L. (mlatzig)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin nun etwas weiter...
Hatte die Masse vom Mikrontroller auf dem Breadboard falsch eingesteckt 
;-)

Hier ist mal grob das Schaltbild, wie ich es derzeit aufgebaut habe.

Ich habe derzeit 1uF an VDD=5V und 2x100nF an VLCD (hatte auch schon 
einen Elko dran).

Die Acks bekomme ich nun jederzeit auch bei R/W mit Slave Address Byte 
0x74/0x75.

Bevor ich mit I2C kommuniziere, führe ich am RESET Pin einen HI-LOW 
Impulse durch... (10ms HI, danach LOW bleibt auf Low, Warte 10ms vor der 
ersten I2C-Sequenz)

Ich versuche nun, versch. Initialisierungssequenzen zu schicken, in etwa 
wie auch im Datenblatt Tabelle 44 (Seite 64ff):

Hier mal im Pseudo-Code (hab es hier bei mir in Assembler auf nem 
ATmega328p) von dem, was ich derzeit absende:
i2c_start();
i2c_write(0x74);         // Slave Addr Byte (SA=0/RW=0)
i2c_write(0x00);         // Control Byte (CO=0/RS=0)
i2c_write(0x20);         // Function Set (Base + Standard, 1 Line, 1:18 Multiplex)
i2c_write(0x0E);         // Display Ctl (Disp On, Cursor On)
i2c_write(0x06);         // Entry Mode (Addr Increment, No Shift)
i2c_stop();

i2c_start();
i2c_write(0x74);         // Slave Addr Byte (SA=0/RW=0)
i2c_write(0x00);         // Control Byte (CO=0/RS=0)
i2c_write(0x21);         // Function Set (Base + Extended, 1 Line, 1:18 Multiplex)
i2c_write(0x42);         // HV_gen (3 voltage multiplier)
i2c_write(0x08);         // Icon_ctl (Char Mode, No Icon Blink, Direct Mode Off)
i2c_write(0xE0);         // VLCD_set bit (VA=0x20)
i2c_write(0xA0);         // VLCD_set bit (VB=0x20)
i2c_stop();

i2c_start();
i2c_write(0x74);         // Slave Addr Byte (SA=0/RW=0)
i2c_write(0x40);         // Control Byte (CO=0/RS=1)
for (int i=0; i<40; i++) {
    i2c_write(0x41);     // Send 'A' (0x41)
}
i2c_stop();


Ich würde eigentlich erwarten, wenn ich mit dem Generator rumspiele, 
dass ich eine Spannung am VLCD messen müsste. Ich messe da immer 0V, 
oder denke ich da falsch?

Bisher sehe ich nichts auf dem LCD...

Ich werde ab Morgen versuchen, das, was ich ins DDRAM geschrieben habe, 
auch wieder zu lesen, um herauszufinden, ob ich zumindest von der Logik 
her richtig mit dem LCD kommuniziere. Bisher habe ich nur versucht, 
einen BF_AC Read zu machen. Es wird dann immer 0 zurückgeliefert...

Hat jemand sonst eine Idee oder wurde was übersehen?

Autor: google (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guck mal hier:
https://developer.mbed.org/users/okini3939/code/PCF2119/file/27f430d086f3/PCF2119.cpp

Das scheint sehr brauchbar zu sein. Das wollte ich als Basis nutzen, 
wenn ich mal zum Testen komme.

Autor: Mario L. (mlatzig)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
So, es hat nun geklappt! Es war mal wieder ein Wackler beim Breadbord an 
der LCD-Versorgung. Ich ätze auch lieber eine Prototyp-Platine als mit 
dem Breadboard zu arbeiten. Meine Erfahrungen sind damit nicht so 
berauschend.

Der Schaltplan ist weiterhin so aufgebaut. Versorgungsspannung ist 5V.

Also die Initialisierung erfolgt nun so:
i2c_start();
i2c_write(0x74);         // Slave Addr Byte (SA=0/RW=0)
i2c_write(0x00);         // Control Byte (CO=0/RS=0)
i2c_write(0x20);         // Function Set (Base + Standard, 1 Line, 1:18 Multiplex)
i2c_write(0x06);         // Entry Mode (Addr Increment, No Shift)
i2c_write(0x0E);         // Display Ctl (Disp On, Cursor On), Cursor nicht sichtbar, warum?
i2c_write(0x21);         // Function Set (Base + Extended, 1 Line, 1:18 Multiplex)
i2c_write(0x04);         // Disp_conf (Column: Left to Right, Row: Top to Bottom)
i2c_write(0x42);         // HV_gen (3 voltage multiplier)
i2c_write(0x08);         // Icon_ctl (Char Mode, No Icon Blink, Direct Mode Off)
i2c_write(0xB0);         // VLCD_set (VA=0x30), =5.66V, VLCD gemessen ist bei mir 5,83V
i2c_write(0xC0);         // VLCD_set (VB=0x00) Disabled
i2c_write(0x20);         // Function Set (Base + Standard, 1 Line, 1:18 
i2c_stop();

Die DDRAM Addressen für die 20 Zeichen sind seltsam verteilt:
0x1A,0x1B,0x1C,0x1E,0x1F,0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0E,0x0F

Bei den CGRAM Addressen 0x00-0x1F für die Icons bin ich mir erst recht 
noch im Unklaren.

Das linke Ordner-Icon ("Icon 1" im Datenblatt von Pollin gennant) ist 
bei mir seltsamerweise an CGRAM Adresse 0x0A, Bit5. Die restlichen Icons 
habe ich noch nicht aufgeschlüsselt...

Persönlich ist mir das aber schnurz, weil man die Addressen & Bits ja 
auch noch in der Software später mappen könnte...

Achja, das LCD verwendet CGROM Charset "A".

Autor: google (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Herzlichen Glückwunsch, Du bist der aktuelle Pollin-LCD-Guru des Forums. 
;-)

Im Ernst, vielen Dank für Deine Arbeit. Ich kann das leider frühestens 
Sonntag nachvollziehen, wenn ich die Zeit dafür bekomme. Familie und Co. 
eben ...

Autor: Mario L. (mlatzig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, die wichtigste Information in diesem Beitrag war ja zu wissen, 
welcher Controller dahinter steckt ;-)

Die letzten LCD-Sortimente von Pollin waren Grütze. Ich bestelle diese 
Sortimente erst einmal nicht mehr, ebenso keine VFD-Sortimente. Habe 
hier schon soviele Gläser rumliegen, ebenso eimerweise LEDs, weiss 
garnicht wohin damit...

Autor: google (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mario L. schrieb:

> Habe
> hier schon soviele Gläser rumliegen, ebenso eimerweise LEDs, weiss
> garnicht wohin damit...

Wieviele und welche LCD-Gläser/Module (keine LED oder VFD) hast Du und 
was willst Du im Paket dafür haben?

Autor: c-hater (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mario L. schrieb:

> Naja, die wichtigste Information in diesem Beitrag war ja zu wissen,
> welcher Controller dahinter steckt ;-)

So isses.

> Die letzten LCD-Sortimente von Pollin waren Grütze.

Auch dieses Display ist eigentlich Grütze, weil offensichtlich aus einer 
Ausschuss-Serie. Das alleine erklärt, warum Pollin es zu diesem 
sensationell günstigen Preis anbieten kann...

Der Knackpunkt sind die Icons 30..36. (leicht schräger senkrechter 
Balken zwischen der 17. und 18. Char-Stelle des Displays). Die lassen 
sich nicht als solche benutzen. Das allein wäre noch nicht wirklich 
schlimm, auf diesen blöden Balken könnte man sicher locker verzichten.

Richtig schlimm wird es erst dadurch, dass sie, anstatt das zu tun, was 
sie sollen, im Character Mode die leftmost-Spalte von Character 18 
spiegeln. Da hat wohl der Layouter einen klitzekleinen Fehler beim 
Leiterbahnen-Häkeln gemacht...

However: Damit werden die letzten zwei Zeichen der Textzeile für die 
meisten Zwecke praktisch unbenutzbar. Das ist schon eine sehr herbe 
Einschränkung...

Die restlichen Icons verhalten sich hingegen, wie sie sollten. Das 
CGRAM-Mapping hänge ich einfach mal an.

Autor: c-hater (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:

> Auch dieses Display ist eigentlich Grütze, weil offensichtlich aus einer
> Ausschuss-Serie.

Ich ziehe diese Bemerkung zurück, die war eindeutig zu voreilig.

> Der Knackpunkt sind die Icons 30..36. (leicht schräger senkrechter
> Balken zwischen der 17. und 18. Char-Stelle des Displays). Die lassen
> sich nicht als solche benutzen.

Das stimmt zwar, ist aber nicht die ganze Wahrheit.

Als Icon im engeren Sinne ist dieser Balken zwar tatsächlich nicht 
ansteuerbar. Aber als Zeichen im Charactermode. Nämlich über die 
DDRAM-Adresse $0d. Er stellt also einfach ein normales Zeichen dar, das 
allerdings im Gegensatz zu den anderen aus nur einer einzigen Spalte 
besteht, nämlich der, zu der Bit4 der jeweiligen Zeichendefinition 
gehört, was der leftmost-Spalte normaler Zeichen entspricht.

Für die naheliegende Nutzung als "Aussteuerungsanzeige" o.ä. stehen auch 
schon die passenden Zeichen im mitgelieferten Charset "A" bereit, 
nämlich auf den CGROM-Zeichenpositionen $99..$A0 (benutzt wird, wie 
gesagt, nur eine Spalte des Bitmusters).

Für's Stromsparen kann man eine Art Zwischenstufe zwischen dem vollen 
Displaymodus und dem extrem stromsparenden Iconmodus realisieren, in dem 
auch dieser Balken verfügbar bleibt, Das macht man einfach dadurch, dass 
man in den 1:9-Mux umschaltet. Dann sind nur die Zeichen auf den 
DDRAM-Adressen 0..$f sichtbar, zu denen eben auch dieser Balken gehört. 
Der Energiebedarf sinkt in diesem Modus auf ca. 1/4 dessen, was im 
vollen Displaymodus mit 1:18-Mux benötigt wird. Das Absenken der 
Displayspannung dabei nicht vergessen, sonst sieht man garnix mehr, 
statt ca. $30 sind für 1:9-Mux nur ca. $20 über VLCD_set zu 
konfigurieren, auch muss man über HV_gen 1..2 Stufen der Ladungspumpe 
abschalten (je nach Betriebsspannung), um wirklich auf die genannte 
Energieeinsparung zu kommen.

Naja, alles in allem längst noch nicht so stromsparend, als wären es 
wirklich Icons, aber akzeptabel, weil in diesem Modus außer dem Balken 
ja auch noch 15 normale Zeichen darstellbar bleiben.

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das klingt ja vielversprechend. Laufen die Module auch mit 3,3V oder nur 
mit 5V? Wie ist der Stromverbrauch? Ich suche ein Display für 
dauerhaften Batteriebetrieb 2xAA)?

Gruß,
Bernd

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd O. schrieb:

> Laufen die Module auch mit 3,3V oder nur
> mit 5V?

Bis runter zu 1,5V sind möglich, allerdings nicht empfehlenswert, wenn 
es auf geringen Stromverbrauch ankommt. Je geringer die 
Versorgungsspannung, desto mehr Stufen der eingebauten Ladungspumpe muss 
man benutzen, um die nötige LCD-Spannung zu erreichen und umso höher 
steigt logischerweise der Stromverbrauch.

3.3V passt ziemlich gut, man kommt dann im Icon-Modus und dem von mir 
erwähnten "SparModus" mit 1:9MUX sicher mit einer Stufe aus. Für den 
1:18MUX (volle Zeilenlänge nutzbar) kann es aber bereits zu knapp 
werden, insbesondere bei tiefen Umgebungstemperaturen. Da muss man dann 
die zweite Stufe hinzunehmen.

> Wie ist der Stromverbrauch? Ich suche ein Display für
> dauerhaften Batteriebetrieb 2xAA)?

Wie kommst du bei 2xAA auf 3,3V? Die hast du bestenfalls bei ziemlich 
neuen Batterien. Oder benutzt du einen Aufwärtsregler? Dann solltest du 
das Display nicht daraus speisen, sondern direkt aus der Batterie, sonst 
hast du doppelte Verluste.

Was den Stromverbrauch betrifft, traue ich meinen Messungen nicht mehr 
so ganz, die weichen doch erheblich von dem ab, was das Datenblatt des 
Controllers als typische Werte angibt. Schätze, ich muss die Messungen 
noch einmal systematischer und mit einem besseren Messinstrument 
wiederholen.

Ich hatte bei 5V Vdd, mit nur einer aktiven Stufe der Ladungspumpe (da 
bin ich mir für den 1:18MUX nicht mehr sicher) und  nach Augenschein 
optimierter LCD-Spannung gemessen und folgende Werte erhalten:

1:18MUX          195µA
1:9MUX            62µA
1:2MUX(Iconmode)  42µA

Naja, zumindest die Größenordnung entspricht noch den 
Datenblattangaben...

Wie auch immer, für dauerhaften Batteriebetrieb immer noch ganz schön 
viel, mit AA-Zellen mag es aber angehen.
Außerdem: für das Geld wirst du wohl ziemlich sicher kein besser 
geeignetes Display bekommen. Jedenfalls nicht als Einzelstück und aus 
Deutschland.

Noch ein Hinweis: es handelt sich um ein transmissives Display, das 
wurde in dem Thread noch überhaupt nicht erwähnt. D.h.: eigentlich ist 
es dafür gedacht, mit einer Hintergrundbeleuchtung versehen zu werden. 
Man kann aber einfach weisse Folie hinten drauf kleben, um es als 
reflexives Display zu verwenden.

Besser wäre sicher spezielle Reflexionsfolie, aber wo kriegt man 20 cm² 
davon billig her?

Autor: Magnus M. (magnetus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Besser wäre sicher spezielle Reflexionsfolie, aber wo kriegt man 20 cm²
> davon billig her?

Könnte ein Aluminiumklebeband den Job erfüllen?

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
c-hater schrieb:
> Bernd O. schrieb:
>
>> Wie ist der Stromverbrauch? Ich suche ein Display für
>> dauerhaften Batteriebetrieb 2xAA)?
>
> Wie kommst du bei 2xAA auf 3,3V? Die hast du bestenfalls bei ziemlich
> neuen Batterien. Oder benutzt du einen Aufwärtsregler? Dann solltest du
> das Display nicht daraus speisen, sondern direkt aus der Batterie, sonst
> hast du doppelte Verluste.
Ja - Aufwärtsregler war angedacht um nicht drei Batterien nutzen zu 
müssen, sondern nur zwei. Das passt besser in's Gehäuse - aber 
vielleicht ist es doch besser auf ein anderes Gehäuse auszuweichen und 
drei Zellen ohne Step-Up zu verwenden (ich habe sowieso noch keinen 
günstigen gefunden, der << 1mA bei vernünftigem Wirkungsgrad 
hinbekommt). Es gibt nette ICs von TI und bestimmt auch von anderen 
Herstellern, aber meist in winzigsten SMD Gehäusen und relativ teuer.

Ich habe mir nun mal einen Schwung Displays bestellt und mir das 
Datenblatt näher angeschaut:

Eigentlich darf man dieses Display doch nur im Spannungsbereich von 2,2V 
bis 4V betreiben, da in der Konfiguration alle drei 
Spannungsversorgungen VDD1, VDD2 und VDD3 parallel geschaltet sind und 
auf Pin 2 herausgeführt sind. VDD1 geht zwar von 1,5V bis 5,5V aber für 
die Versorgung der Ladungspumpe "high voltage generator" gilt:

https://www.nxp.com/docs/en/data-sheet/PCF2119X.pdf
Seite 2:
VLCD generator supply voltage:
VDD2 - VSS2 = 2.2 V to 4 V and
VDD3 - VSS2 =2.2 V to 4 V
Seite 55:
VDD1 = VDD2 = VDD3 = 2.2 V (minimum), 2.7 V (typical) and 4.0 V 
(maximum)

Absolute maximum rating für VDD2 und VDD3 ist mit 4,5V angegeben. 
Insofern ist es schon plausibel, dass die Displays bisher die 5V 
überlebt haben, aber ob das dauerhaft und über einen weiten 
Temperaturbereich stabil läuft - wer weiß?

Für den Betrieb mit 3 Mignonzellen müsste doch eigentlich ein 
Linearegler wie der MCP1703 mit 3,3V oder 4V optimal sein. Der geht bis 
runter auf 2,7V - da sind die drei Zellen sowieso völlig leer, hat einen 
Querstrom von ca. 2uA und so gut wie keinen Dropout (<< 10 mV) bei 
diesen kleinen Strömen.

Passt eigentlich der Standard Temperaturkoeffizient von "-0.16 %/K" zum 
Glas? Zum Test müsste man das Ding doch einfach mal bei Raumtemperatur 
auf optimalen Kontrast stellen und dann kühlen und dann prüfen ob der 
Kontrast noch optimal ist und falls nicht einen anderen 
Temperaturkoeffizent probieren - oder?

Gruß
Bernd

Autor: google (Gast)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Eine kleine Vorschau auf das Tian Ma A2C00050374 von Pollin.

Die genaue Pinbelegung folgt im Laufe der nächsten Woche.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
google schrieb:
> Eine kleine Vorschau auf das Tian Ma A2C00050374 von Pollin.
> Die genaue Pinbelegung folgt im Laufe der nächsten Woche.

Cool. Das wäre nett als Aussteuerungsanzeige. Vorausgesetzt man kann 
alle gezeigten Segmente (insbesondere das "CITROEN") auch abschalten.

Autor: google (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die senkrechten Teilstriche sind alle einzeln steuerbar. Die Skala (0-6) 
inklusive der x1000 und der waagerechten Bögen sind ein Segment. Das 
Citröen erscheint zusammen mit dem Segment D der Siebensegmentstelle, 
wenn ich mich richtig erinnere. Auto ist zusammenhängend, Schneeflocke 
ist ein Segment, die linksseitigen Buchstaben sind jeweils einzelne 
Segmente, ebenso das "S" rechts.

Autor: google (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: HT1621B ist perfekt dafür. ;-) Nur mit der LCD-Spannung kämpfe ich 
noch. Stichwort Kontrast

Autor: Mario L. (mlatzig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Das wäre nett als Aussteuerungsanzeige.

google schrieb:
> Die senkrechten Teilstriche sind alle einzeln steuerbar.

Auch wenn es langsam Off-Topic wird:

Eine Aussteuerungsanzeige ist wirklich nett.
Sehe ich das richtig, dass es 4 Backplanes hat?
Man könnte sich auch eine (seltsame) Uhr daraus basteln, indem man die 
Teilstriche in 5er Schritten unterteilt (jeder 5te Strich wird 
angezeigt). Aktuelle Minuten- und Stunden Striche könnten blinken. Aber 
für diese Spielerei würde ich nicht extra dieses LCD bestellen, da ich 
es noch nicht habe. Ein LCD OPTREX FSD-8E41PH mit gefühlten 200 Pins, 
dass Pollin nun nicht mehr im Angebot, liegt auch noch rum.

Interessanter finde ich dagegen das A2C00096100, da es sich anscheinend 
für eine halbwegs stromsparende Batterieanwendungen eignet (wenn auch am 
besten mit 15,2 Zeichen im 1:9 mux, wie c-hater schrieb).

: Bearbeitet durch User
Autor: Bernd O. (bitshifter)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Beim TIAN MA A2C00096100 habe ich das Problem, dass im 1:9 Modus nur 10 
Zeichen nutzbar sind, da ab dem 11. Zeichen links beginnend 
Geisterzeichen erscheinen.

Bei Bild "10.jpg" ist noch alles O.K. (10 Nutzzeichen und keine 
Geisterzeichen).
Bei Bild "11.jpg" erscheint mit dem 11. Zeichen das erste 
Geisterzeichen. Bei Bild "15.jpg" werden alle im 1:0 Modus möglichen 
Character genutzt - aber die anderen in diesem Modus nicht nutzbaren 
Positionen zeigen Geisterzeichen.

Wenn ich VLCD absenke werden die Geisterzeichen zwar schwächer, aber 
bevor sie verschwinden sind die Nutzzeichen schon unbrauchbar blass 
geworden.

Sieht also so aus, als wären im 1:9 Modus tatsächlich nur 10 Positionen 
nutzbar.

Kann jemand meine Beobachtung bestätigen?


Gruß,
Bernd

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ursache ist wohl, dass im 1:9-Betrieb die Spaltentreiber R9-R16 zwar 
nicht angesteuert werden aber auch nicht völlig floatend sind oder die 
Kapazität beim floaten so hoch ist, dass es für diese Geisterbilder 
reicht.

Man kann im 1:9-Betrieb also nur die ersten 10 Stellen und das 
"Aussteuerungssymbol" ohne Geisterbilder nutzen.

Gruß,
Bernd

Autor: Nosnibor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bekomme die Geister auch, allerdings vollständig lesbar und extra 
fett (schwarze Pixel erscheinen eine Zeile tiefer noch einmal).
"All other rows must be left open-circuit" steht im Kleingedruckten, und 
nun wissen wir auch, warum.
Der Hersteller hat wohl nicht damit gerechnet, daß jemand von einem 
zweizeiligen Display zeitweise nur die Hälfte nutzen will, sonst würde 
der Chip im 1:9-Modus an den ungenutzen Zeilenausgängen ein 
entsprechendes Signal ausgeben wie im 1:2-Modus, damit die Pixel ruhig 
bleiben.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd O. schrieb:

> Man kann im 1:9-Betrieb also nur die ersten 10 Stellen und das
> "Aussteuerungssymbol" ohne Geisterbilder nutzen.

Nicht die ersten 10, sondern die mittleren 10 (mechanisch betrachtet, 
nicht nach DDRAM-Adressen).

Alternativ kann man auch 15 Stellen nutzen, indem man das Display so 
einbaut, dass die ersten 5 Stellen schlicht mechanisch verdeckt sind. 
Damit ist dann allerdings auch ein Teil der Icons nicht mehr nutzbar, 
von denen aber wohl nur das Ordnersymbol wirklich ein nennenswerter 
Verlust wäre...

Autor: Marek Lewandowski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mario L. schrieb:

> i2c_write(0x0E);         // Display Ctl (Disp On, Cursor On), Cursor
> nicht sichtbar, warum?

Weil das Display nur 5x7 pixel pro Zeichen hat und somit die 8-te Zeile 
für Cursor fehlt ;-)

(Datenblatt https://www.nxp.com/docs/en/data-sheet/PCF2119X.pdf s34 "The 
cursor is displayed using 5 dots in the 8th line (see Figure 17).")

Autor: Mario L. (mlatzig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marek Lewandowski schrieb:
> Weil das Display nur 5x7 pixel pro Zeichen hat und somit die 8-te Zeile
> für Cursor fehlt ;-)

Achso, danke. Man muss nur wieder genau genug das Datenblatt lesen. Als 
8Bit-Computer(C64) aufgewachsener Mensch, hatte ich intuitiv nur an 
einen Block-Cursor gedacht :-)

Autor: Vincenz D. (dr-inside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen!

Ich versuche mich auch gerade an diesem Display von Pollin, aber
ich bekomme es am Arduino Nano einfach nicht zum laufen ...
Was mache ich falsch?

Beschaltet habe ich es wie im Schaltbild von Mario L. mit Ausnahme
der 2 Pullups, da habe ich 10K statt 4K7 genommen, weil ich nur 10K
griffbereit hatte.

  VSS nach VDD  = 470nF
  VSS nach VLCD = 100nF
  SCL Pullup    = 10K
  SDA Pullup    = 10K


Am Arduino:
  RST  -->  Pin 4
  SDA  -->  Pin A4  (Default-Pin für Data)
  SCL  -->  Pin A5  (Default-Pin für Clock)


Der Code bisher:

#include <Wire.h>

#define PinRST 4

void setup() {

  pinMode(PinRST, OUTPUT);

  digitalWrite(PinRST, HIGH); delay(10);
  digitalWrite(PinRST, LOW);  delay(10);

  Wire.begin();

  Wire.beginTransmission(0x74);
  Wire.write(byte(0x00));
  Wire.write(byte(0x20));
  Wire.write(byte(0x06));
  Wire.write(byte(0x0E));
  Wire.write(byte(0x21));
  Wire.write(byte(0x04));
  Wire.write(byte(0x42));
  Wire.write(byte(0x08));
  Wire.write(byte(0x80));
  Wire.write(byte(0xC0));
  Wire.write(byte(0x20));
  Wire.endTransmission();

  Wire.beginTransmission(0x74);
  Wire.write(byte(0x40));
  for (int i=0; i<40; i++) {
    Wire.write(byte(0x41));   // Send 'A' (0x41)
  }
  Wire.endTransmission();


}


: Bearbeitet durch User
Autor: Mario L. (mlatzig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincenz D. schrieb:
> Wire.beginTransmission(0x74);

Ich arbeite nicht mit Arduino, wollen die aber evtl. nur die 7Bit Device 
Addresse haben? Hast du schon
Wire.beginTransmission(0x3A);

ausprobiert?

Autor: Vincenz D. (dr-inside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mario L. schrieb:
> Vincenz D. schrieb:
>> Wire.beginTransmission(0x74);
>
> Ich arbeite nicht mit Arduino, wollen die aber evtl. nur die 7Bit Device
> Addresse haben? Hast du schon
>
>
> Wire.beginTransmission(0x3A);
> 
>
> ausprobiert?

Ja, das hab ich inzwischen auch schon ausprobiert. Nachdem ich mit 0x74
keinen erfolg hatte, habe ich ein I2C-Scanner aufs Arduino geladen, der
hatte mir dann gemeldet, daß er an Adresse 0x3A ein Device gefunden hat.
Also tut das Display zumindest reagieren. Aber es passiert nach dem Init
und dem senden der "A" nichts.

Autor: W.S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vincenz D. schrieb:
> Der Code bisher:...

... erfüllt mich mit Grausen. Sowas ist wohl Arduino - oder?
Der angehängte Code funktioniert. Er baut auf einem Lowlevel-I2C-Treiber 
auf, der seinerseits plattformabhängig ist.

Allerdings mußt du den eigentliche I2C-Treiber für deinen µC selber 
beisteuern. Ich hatte hier nen LPC1114 benutzt.

W.S.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincenz D. schrieb:

>   VSS nach VDD  = 470nF

Das sollten 100n sein, 470n werden allerdings auch nicht schaden.

>   VSS nach VLCD = 100nF

Das sollten 1000n=1µ sein. 100n sind hier eindeutig zu wenig.

>   Wire.beginTransmission(0x74);
>   Wire.write(byte(0x00));
>   Wire.write(byte(0x20));
>   Wire.write(byte(0x06));
>   Wire.write(byte(0x0E));
>   Wire.write(byte(0x21));
>   Wire.write(byte(0x04));
>   Wire.write(byte(0x42));
>   Wire.write(byte(0x08));
>   Wire.write(byte(0x80));
>   Wire.write(byte(0xC0));
>   Wire.write(byte(0x20));
>   Wire.endTransmission();

Versuch' es mal mit folgenden Werten (in genau dieser Reihenfolge und 
Azahl:

0x21,0xc0,0xb0,0x08,0x40,0x10,0x20

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:

> Versuch' es mal mit folgenden Werten (in genau dieser Reihenfolge und
> Azahl:
>
> 0x21,0xc0,0xb0,0x08,0x40,0x10,0x20

Verdammt, davor gehört noch eine Null. Also, das sollte eigentlich so 
aussehen:

0x00,0x21,0xc0,0xb0,0x08,0x40,0x10,0x20

Autor: Vincenz D. (dr-inside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> ... erfüllt mich mit Grausen. Sowas ist wohl Arduino - oder?

Sorry, ich bin wirklich nicht der C++ Profi, daher ist mein Code noch 
nicht so schön. Ich hab das nur schnell 1 zu 1 umgesetzt zum testen ...

Autor: Vincenz D. (dr-inside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Das sollten 1000n=1µ sein. 100n sind hier eindeutig zu wenig.

Ok, hab gerade kein 1µ rumliegen, muss ich erstmal am Wochenende 
irgendwo einen auslöten, dann kann ich das noch mal testen ...


> Verdammt, davor gehört noch eine Null. Also, das sollte eigentlich so aussehen:
> 0x00,0x21,0xc0,0xb0,0x08,0x40,0x10,0x20

Ok, werde ich ebenfalls testen.

Ich melde mich dann wieder. Erstmal vielen Dank!

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:

> ... erfüllt mich mit Grausen.

Naja, das ist was, was man schreibt, mit dem was man kann, um die Sache 
überhaupt erstmal grundsätzlich dazu zu bewegen, überhaupt irgendetwas 
sichtbares zu tun. Mein ersten Versuche, dieses Display zur Arbeit zu 
bewegen waren zwar in Assembler, aber von der Konstruktion her 
prinzipiell kein bissel anders oder gar besser als der vom TO gezeigte 
Arduino-Code.

> Der angehängte Code funktioniert.

Das mag sein, ja ist sogar sehr wahrscheinlich, aber der Code wird den 
Fähigkeiten des Displays nicht annähernd gerecht und ist auch nicht 
gerade benutzerfreundlich. Die Tatsache, dass er auf einen vorhandenen 
I2C-Layer aufbaut, ist nicht das Problem, das würde jeder 
ernstzunehmende Code natürlich ebenfalls tun (meiner z.B. tut das auch 
und, nicht zu vergessen: auch der Code des TO tut ebenfalls genau das!).

Kritikpunkte an deinem Code:

- Aktiver Reset nicht unterstützt
- Mögliche Display-Modi nicht vernünftig unterstützt (Icons only, 10
  chars+Icons, 20 chars+icons, OFF)
- Keine Konfigurationsmöglichkeit bezüglich Betriebsspannung
- Keine Unterstützung custom chars
- Keine Unterstützung für den bargraph
- Lausige Unterstützung der Icons (keine Abstraktion für Icon-
  Kombinationen, insbesondere nicht für die zwei 7-Segment-Icons, keine
  Unterstützung für blinking icons)

Geht natürlich alles auf Register-Level des Display, sowas sollte aber 
in einem ernstzunehmenden Gerätetreiber für dieses Display enthalten 
sein.

Deiner abstrahiert im Wesentlichen nur die seltsam wirre Adresszuordnung 
der sichtbaren Displaystellen und stellt für einen bestimmten 
Betriebsspannungsbereich eine funktionierende Grundkonfiguration für den 
"20chars+static icons"-mode bereit. Mehr nicht. Ich würde mal sagen: 
Aufgabe zu maximal 50% erfüllt...

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.

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