RMK-Aaldisplay 40x2

[berferd]

Ich versuche grade das von RMK an mehrere Leute hier viewtopic.php?f=17&t=16998 veraalte (Danke nochmal an der Stelle! ) Display in Betrieb zu nehmen.
Noch läufts nicht, ich dachte ich teile hier mal meinen Stand der Dinge, vielleicht hat ja jemand noch Tips oder Ideen.

Rausgefunden hab ich:
Das Display ist ein Powertip PC 2004LRS-ASO-H. Dem Datenblatt zufolge http://www.farnell.com/datasheets/50586.pdf ist das:
20x4-Textdisplay mit LED-backlight Gelb-Grün, Font 5x8 Pixel.
Displaytyp STN-positive, grau, transflektiv, erweiterer Temperaturbereich, Vorzugsrichtung Blickwinkel 6 Uhr - recht brauchbar!
Font Englisch/Japanisch, IC von Samsung
Die LED-Hintergrundbeleuchtung genehmigt sich 4.2V, 210mA .. und ist dann noch relativ duster. Eventuell würde ich das auf stromsparendere LEDs umbauen, wenn es dann mal läuft.
Display ist aber recht gut ablesbar, ordentlicher Kontrast, ich mag das Ding ansonsten.
Aber es braucht eine negative Kontrastvorspannung. So ab -1,5V erscheinen die ersten Schemen, bei -3V sind die schwarzen Blöcke (un-initialisiertes Display) sehr gut sichtbar.
Der Driver-IC ist wohl (s.o.) von Samsung.. (SO = Samsung, English/Japanese Font).. und damit dann IC KS0066U?

Im KS0066U-Datenblatt ist eine Sequenz für 4bit-Init empfohlen, die habe ich mal gesendet - trotz reichlichem Einhalten der Timing-Bedingungen (50 ms Powerup-Delay z.B.) tut sich aber nichts, das Display bleibt uninitialisiert (schwarze Blöcke in Zeile 1 und 3).

Habe es auf Verdacht auch mal mit der Init-Sequenz für den ST7066U versucht, sowie mit den Fleury-Lib-Defaults KS007 und HD44780 - ebenfalls nix.

Als nächstes werde ich mal direkt an den Displaypins einen Logic Analyzer dranklemmen, ob da auch wirklich alles ankommt - man muss ja auf alles gefasst sein (ansteuernder uC mit defekten Pins, Kabelbrüche, Wackelkontakte).

[sysconsol]

[...] - trotz reichlichem Einhalten der Timing-Bedingungen[...]

Viele Programmschnippsel verlassen sich darauf, dass das Timing vom Display stimmt.
Das Display hat aber ein Busy-Flag. Das wird meistens ignoriert.
Es ist bei mir nicht nur einmal der Fall gewesen, dass das Nutzen des Busy-Flag den Fehler behoben hat.

Was die Kontrastspannung angeht: Das LCD-Modul kann man möglicherweise so umbauen, dass keine negative Spannung nötig ist.
Siehe verlinktes Datenblatt Seite 18.

[berferd]

Der Umbau von Seite 18 aus dem Datenblatt geht leider nur mit den Displays, die keine Negative Kontrastspannung brauchen. Der Umbau ersetzt einfach nur das externe Poti (Spannungsteiler) bzw. die externe Kontrastspannung durch einen internen Widerstand wählbarer Größe nach GND.

Das mit dem Busy-Flag-Pollen ist aber ein guter Vorschlag, der Code den ich aktuell verwende macht das nämlich (wie schon von Dir vermutet) mit Timings - wenn ich auch die Timings seeeehr großzügig gewählt hab gegenüber den Angaben im Datenblatt.

[Bastelbruder]

Ich bin ziemlich sicher daß sich die negative Spannung aus dem Datengeblubber gleichrichten läßt. Da wird doch kein ganzes Kraftwerk benötigt.

[berferd]

Negative Spannung würd ich dann später mit einem wackelnden uC-Pin, zwei Schottky-Dioden und zwei kleinen Kondensatoren erzeugen.

Wie es aussieht bleibt das Display irgendwo beim Init hängen, mein uC kommt übers "warten aufs Busy-Flag" nicht weg,
Mit uC und ständigem Umprogrammieren ist das reichlich dämlich. Besorge mir mal ein i2c-nach-LCD-Interface, dann bin ich mit i2c und Bus Pirate etwas flexibler.

[Alexander470815]

Also ich würde mich damit nicht zu lange aufhalten.
Bei dem Neupreis von so einem Display ist es wirklich die Mühe nicht Wert.

[j.o.e]

Ich würde es mal an einene Arduino ran klöppeln und dann eins der Beispielprogramme ("Hello Worlds"") versuchen.

KS0066U ist aus'm Kopf kompatipel zum HD44780. Falls nicht, findest du mit Sicheheit eine angepasste Arduino-Lib.

Ich hab mir ein Testkabel gebastelt: Lange Stiftleiste, Stück Lochraster mit fest angelöteten Leitungen.

Ein Gummiring verspannt die Stifteiste in den Löchern des Displays. Die Kontaktgabe reicht zum Testen und ist in wenigen Minuten an Arduino rangetüddelt. Das Testkabel liegt normalerweise in der Kiste mit Displays und wartet drauf, zugelaufene Displays testen zu drürfen. Zur Zeit ist's halt mal wieder fest verbaut - drum auch das schlechte Foto...

[berferd]

Seit wann gehts hier im Forum denn um monetären Nutzen?
Es geht doch m.E. um Frickelei, ums Dazulernen, Vorhandenes sinnvoll (wieder-)verwenden, und natürlich um igoristische Technik. Und ein Stück weit auch um die sportliche Herausforderung, Sachen (wieder) zum Laufen zu bekommen.

Beispielprogramme etc hab ich schon durch (s.o.), damit läufts leider nicht (Fleury-Lib in verschiedenen Ausprägungen, die mit anderen Displays bereits gut funktioniert). Letzter Schritt war, die Libs anhand der Datenblätter der verschiedenen Chipsets, die in Frage kommen, anzupassen. Die Init-Sequenzen (das Umschalten in den 4-bit-Modus) unterscheiden sich da nämlich teils. Es geht mir jetzt darum, den "Code - Compile - Test"-Zyklus zu beschleunigen, denn nach gefühlt 50 Zyklen wird es etwas ermüdend. Da ist man mit "halbmanueller" Ansteuerung via Bus-Pirate deutlich flexibler, weil man in jedem Schritt gucken kann was am Display ankommt und wie das Display reagiert. Das hat sich für SPI- und I2C-Inbetriebnahme bewährt. Habe mir jetzt mal eine Handvoll von diesen i2c-nach-LCD-Parallel-Interfaces bestellt, sowas kann man auch für andere Sachen brauchen.

[MSG]

Evtl hilft das Video, der Typ erklärt ganz gut anhand des Datenblattes die Probleme mit dem Timing

https://www.youtube.com/watch?v=FY3zTUaykVo

[berferd]

Das Video hilft nicht so wirklich - im Video kommt zum Timing praktisch nichts vor, der zeigt ja auch nur das Datenblatt dass ich hier auch liegen habe?

Bin mittlerweile noch auf eine Merkwürdigkeit gestoßen: mein Init im uC kommt (reproduzierbar) nur übers Busy-Flag-Abfragen hinaus, wenn man eine negative Kontrastspannung ans Display anlegt, oder den Kontrasteingang mindestens auf GND zieht. Das finde ich eigenartig, denn eigentlich hat der Init mit dem Display-Kontrast doch nichts zu tun? Und, nein, kein falscher Pin: der Kontrastspannungspin (Pin 3) steuert sichtbar den Kontrast des Displays. Ist das ein Display, das keinen Init zulässt wenn die Kontrastspannung nicht passt?

[sysconsol]

Das scheint mir unlogisch.

Hast du mit dem Oszi mal die Betriebsspannung, die Datensignale und die verschiedenen zugänglichen Signale am Displaycontroller angeschaut?
Nicht dass da irgendwas im Argen liegt. Sonst fällt mir da auch nichts mehr zu ein.

[j.o.e]

Halte dich mal besser sklavisch an das Datenblatt; anbei ein Auszug aus dem der Urmutter HD44780U:

IFC.pdf

(62 KiB) 10-mal heruntergeladen

Quelle: Datenblatt der Firma Hitachi ADE-207-272(Z) '99.9

Du musst drauf achten, dass mit E die Daten rausgetaktet werden, also auch das Busy-Flag.
Im 8-bit Mode ist es einfach: E solange takten bis DB7 auf high geht.
Im 4-bit Mode ist es gleich, allerdings braucht es immer 2 Takte auf E, da D4 und D7 nacheinander auf DB7 rausgetaktet werden.

[berferd]

Die Funktionsweise der Displays und wie man sie ansteuert ist mir soweit schon prinzipiell klar - nur dass das eben so nicht funktioniert hat.

Mittlerweile läuft es aber! Hier ein Bild mit rund 1,5V negativer Kontrastspannung, negative 3V sind fast etwas viel. Die Schrift ist leicht bläulich, bei Tageslicht sieht man das. Nicht ganz so schön abzulesen wie die neueren LCDs, da ist Schwarz richtig schwarz.

Es funktioniert mit der Standard LCD-Lib von Fleury.

Die Probleme waren:

• das Display braucht eine negative Kontrastspannung. Das war aber schnell rausgefunden.
• das Display arbeitet nur, wenn eine Kontrastspannung (auf GND legen reicht) anliegt. Bleibt der Eingang z.B. offen, verschwindet das Busy-Flag nicht. Das scheint eine Eigenart des Displays zu sein.
• mein RS-Pin hat uC-seitig nicht funktioniert, klebte auf High. Dumm, denn der muss für den Init auf 0 sein. Drauf gekommen bin ich durch Beobachtung aller Pins mit dem Logic Analyzer.

Warum wackelte der RS-Pin nicht? Ich habe zum Display-Steuern einen Arduino Nano verwendet, und bei dem sind die Pins "RX" und "TX" an der Stiftleiste nicht, wie man annehmen könnte, einfach PD0 und PD1, sondern sie werden scheinbar (?) zum Programmieren des verbauten Atmega verwendet via FT232 (USB). Genau auf PD1 kam der RS-Pin zu liegen...
Das Rausführen von PD0 und PD1 auf die Stiftleiste des Nano-Boards ist damit eigentlich für die allermeisten Anwendungen Unsinn. Da muss man auch erstmal drauf kommen... denn es ist (wie so oft bei dem Arduino-Kram) schwer, verlässlich zu erfahren, was das Board intern eigentlich wirklich elektrisch, sw-mässig usw genau macht, z.B. wenn man es mit "avrdude -c arduino ..." programmiert. Zur Fairness: im Datenblatt (naja..) einiger Nanos ist allerdings gelistet, dass RX und TX mit dem FT232 verbunden sind - das hatte ich bei der ersten Inbetriebnahme und Evaluation übersehen.

[sysconsol]

Ah ja, dann ist ja alles gut.

Der Arduino pro mini hat auch einen ATmega328, dafür keinen FT232.
Manchmal ist das ganz hilfreich.

[RMK]

wow, gratuliere! ich wollte schon raten "tret das Ding in die Tonne"

[berferd]

Alles gut. Dank Dir fürs Veraalen.

[j.o.e]

Warum wackelte der RS-Pin nicht? Ich habe zum Display-Steuern einen Arduino Nano verwendet, und bei dem sind die Pins "RX" und "TX" an der Stiftleiste nicht, wie man annehmen könnte, einfach PD0 und PD1, sondern sie werden scheinbar (?) zum Programmieren des verbauten Atmega verwendet via FT232 (USB). Genau auf PD1 kam der RS-Pin zu liegen...

Das dürfte bei den meisten Arduinos so sein.

Warum da wohl Pin 1 und 2 des Uno's frei sind?

Hätte ich Dir nur mal die Kabelseite meines "Testadapters" geschickt - oder Dir vorgeschlagen, dass Du mal ein anderes Display ran steckst.
Oder Du hättest einfach mal ein Foto von deinem Aufbau gepostet ...

Freu Dich - der Fehler passiert Dir nimmer

[sysconsol]

Habe mir jetzt mal eine Handvoll von diesen i2c-nach-LCD-Parallel-Interfaces bestellt, sowas kann man auch für andere Sachen brauchen.

Ähhm - wenn ich mir die Bilder deratiger Adapter so ansehe - das haben doch Amateure entwickelt - oder?

Ich schätze, wenn man die Adapter huckepack auf so ein LCD-Modul (ein 16x1 und 16x2 habe ich zur Hand) lötet, werden die Lötstellen der Stiftleisten für SCL und GND einen Schluss mit den Fahnen des Displayrahmens machen.
Oder verschätze ich mich derart?

[berferd]

Die Fahnen kann man recht gut umbiegen. Insofern vielleicht nicht ganz so kritisch.