Pollin TIAN MA A2C00096100 LCD Modul

[google (Gast)]

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.

[google (Gast)]

Ich hatte leider ein falsche Datei angehängt.

[Mario L. (mlatzig)]

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.

[google (Gast)]

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.

[Mario L. (mlatzig)]

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?

[google (Gast)]

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.

[Mario L. (mlatzig)]

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".

[google (Gast)]

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 ...

[Mario L. (mlatzig)]

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...

[google (Gast)]

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?

[c-hater (Gast)]

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.

[c-hater (Gast)]

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.

[Bernd O. (bitshifter)]

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

[c-hater (Gast)]

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?

[Magnus M. (magnetus)]

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?

[Bernd O. (bitshifter)]

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

[google (Gast)]

Eine kleine Vorschau auf das Tian Ma A2C00050374 von Pollin.

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

[Axel S. (a-za-z0-9)]

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.

[google (Gast)]

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.

[google (Gast)]

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

[Mario L. (mlatzig)]

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).

[Bernd O. (bitshifter)]

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

[Bernd O. (bitshifter)]

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

[Nosnibor (Gast)]

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.

[c-hater (Gast)]

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...

[Marek Lewandowski (Gast)]

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).")

[Mario L. (mlatzig)]

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 :-)

[Vincenz D. (dr-inside)]

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();


}

[Mario L. (mlatzig)]

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?

[Vincenz D. (dr-inside)]

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.

[W.S. (Gast)]

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.

[c-hater (Gast)]

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

[c-hater (Gast)]

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

[Vincenz D. (dr-inside)]

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 ...

[Vincenz D. (dr-inside)]

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!

[c-hater (Gast)]

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...

[Raphael (Gast)]

Hallo
Ich habe es inzwischen geschafft das das Display etwas anzeigt. Jedoch 
beginnt es mit dem Schreiben der Zeichen irgendwo in der Mitte.
Somit vermute ich dass ich dem Display angeben muss bei welcher Adresse 
es anfangen soll zu schreiben. Leider komme ich aber nicht darauf wie 
ich das mache. Vielleicht kann mir ja jemand einen kleinen Tipp geben.

Schonmal vielen Dank im vorraus

[Andido (Gast)]

Der Thread ist zwar schon recht alt, aber ich habe spät bestellt und 
erst heute meine Bestellung erhalten. Vielleicht ein Fehler?

Auf *bay bieten Asiaten Reflexfolie auch zu günstigen Preisen an:

https://www.ebay.de/itm/5-100cm-Klebeband-Warnklebeband-Reflektorband-Reflektorfolie-Warnung-Reflexfolie/303575077401?hash=item46ae7c1219:g:PCUAAOSwqKNcO9w0

Dafür ist es vermutlich nicht ganz so reflektiv oder wetterbeständig wie 
die Ware aus USA oder BRD. Aber was macht das hier schon?

[Florian R. (zorin)]

ausgrab

Ich habe mir auch mal eins von den Displays (inkl. Controller) von 
Pollin bestellt.
Leider komme ich über das ACK bei einem I2C Write auf 0x3A nicht hinaus.
Insbesondere die Anzeige auf dem Display funktioniert nicht.

Gibt es vielleicht noch Code Snippets oder Tipps und Tricks, die Euch 
geholfen haben ?

Danke

[c-hater (Gast)]

Florian R. schrieb:

> Gibt es vielleicht noch Code Snippets oder Tipps und Tricks, die Euch
> geholfen haben ?

Ja, das Lesen des Datenblatts des Controllers hat mir damals sehr 
geholfen...

[Florian R. (zorin)]

Und schwups, schon funktioniert es...
Das war ein guter Hinweis, da muß ich aber wohl noch etwas Zeit 
investieren.

Auf jeden Fall geht es jetzt, mit den Code-Snippets aus dem Thread bin 
ich schon soweit, das er jetzt Text anzeigt.
Gute Referenz waren die C Libraries von T.S.
Insbesondere der Init String ist wichtig (ok, sollte klar sein)...

Jetzt geht es ans experimentieren, da hält das Display ja noch einiges 
bereit.

Um vielleicht die Lernkurve noch etwas steiler zu machen:
Gerade wäre ich um einen Hinweis für die Umschaltung MUX 1:9, MUX 1:18 
und MUX 1:2 dankbar...

[W.S. (Gast)]

Andido schrieb:
> Auf *bay bieten Asiaten Reflexfolie auch zu günstigen Preisen an

Ach nö, eine kleine Plexi-Scheibe dahinter, Kanten ordentlich geglättet 
und mit einem Streifchen Alufolie beklebt und seitlich eine LED 
eingesetzt, ist mMn viel netter, siehe Bild - und wenn mehr Zeit ist, 
dann auch 2 LED's, das wird gleichmäßiger.

(ganz rechts im Bild ist die Feldstärke-Anzeige)

W.S.

[cimba007 (Gast)]

Falls interesse besteht habe ich die gesammelten Erkenntnisse aus diesem 
Thread einmal versucht in eine Arduino Library zu überführen.

https://github.com/cimba007/PCF2119

[Flensb (Gast)]

Ein freundliches Moin aus Flensburg.

Vielen Dank für die tollen Beiträge zu diesem Display!

Zu dem 0,55 EUR Display passt natürlich gut ein 3 EUR Controller (in 
meinem Fall der ESP8266-01s). In meinem aktuellen Mini-Projekt übernimmt 
der die Funktion des WIFI-Clients und steuert über die fsapi (html) 
meinen neuen hama it900mbt und fragt ihn vor allem ab und stellt Station 
und Interpret/Titel auf dem Display dar (für 30 EUR bringt der it900mbt 
übrigens richtig gute Leistungsmerkmale für meine Audio-Anlage).

Nachdem der ESP-01s schön über OTA läuft, habe ich mit TX und RX den 3. 
und 4. Pin zur Verfügung (z.B. für IR-Control). Um aber für weitere 
Projekt-Ideen den 4. Pin zur Verfügung zu haben ;) , habe ich für den 
Reset den SCL vom I2C mitbenutzt.

Mit [PNP-Transistor C->LCD-Reset + (20k zu GND); E->VCC; B->(20k zu SCL) 
+ (10uF||Entstör-C zu GND)] habe ich einen schönen Power-On-Reset und 
noch die Möglichkeit, das Display vom Programm aus zurückzusetzen. Darf 
man das hier kundtun, oder wird man hier dafür gelyncht?

Für das Senden der Zeichen in richtiger Reihenfolge habe ich mir 
übrigens einen netten 4-zeiler einfallen lassen:

void DispWr(char DAR[]) {

uint8_t i,j;

Wire.beginTransmission(0x3A); // (#74 ist 0x3A<<1 und hier enthalten)

Wire.write(0x80);Wire.write(0x02);Wire.write(0x40);

//**** Aussenden in richtiger Reihenfolge

for (i=0;i<20;i++) {

  Wire.write(DAR[(i+5)%20]);

  j=(i==12)+(i==17)+10*(i==14);

  while (j--) Wire.write(" "); }

// ****

Wire.endTransmission(); }

Der hat den Charme, dass man sich z.B. mit DispWr(&DSt[22]) direkt auf 
die 22. Stelle des nicht-sortierten Nutzstrings setzen kann und 
entsprechend auch leicht Laufschrift etc. realisieren kann.

Und da it900mbt über die FSAPI Texte mit UTF-8- Kodierung aussendet, 
gibt's hier noch die UTF-8-Umkodierung für 96 UTF-8 Zeichen (C2A0..C2BF 
und C380..C3BF) dazu:

// UTF-8 - Bereinigung des Strings DSt

// rückwärts, dann stört es nicht, wenn sich die Länge unterwegs ändert

// Start beim vorletzten Zeichen

for (i=DSt.length()-2;i>-1;i--) {

   if (uint8_t(DSt[i])==0xc2) DSt.remove(i,1);   //  ",1" muss sein

   if (uint8_t(DSt[i])==0xc3) {

        DSt[i+1]=char(uint8_t(DSt[i+1])+0x40);

        DSt.remove(i,1); }} // }if }for

Beste Grüße Flensb