Hallo,
ich habe ein großes Problem mit meinem HD44780 Display.
Es ist an einem Arduino Uno Rev. 3 angeschlossen. Der Kabelweg zum
Display ist 110 cm lang und kann auch leider nicht verkürzt werden.
Kabeldurchmesser: 0.35 mm².
Das Display soll den Zustand meiner Alarmanlage anzeigen, also finden
nur selten (10 mal pro Tag) Aktualisierungen des Displays statt. Dies
ist auch so im Arduino Sketch implementiert, es wird nur bei
Statusänderungen auf das Display geschrieben.
Leider passiert es häufig, dass bei Aktualisierungen auf dem Display
falsche Zeichen angezeigt werden. Danach bekomme ich bis zum Reset auch
keine vernünftige Ausgabe mehr aufs Display.
In dem Bild seht ihr, was mir das Display dann anzeigt.
Über die 5V Stromversorgung für das Display wird außerdem noch eine
Relaiskarte geschaltet (wird für Signalgeber benötigt).
Was ich schon versucht habe: 100 nF Kondensatoren parallel zur
Stromversorgung von Display und Relaiskarte angeschlossen und 100 Ohm
Widerstand in Reihe zur E-Leitung des Displays. Leider hat es wenig
geholfen.
Ich freue mich auf eure Ideen!
Gruß Björn
Servus,
arbeitest du mit einen i2c bus oder nur mit Gpio´s?
Sonst würde ich beim i2c bus die Baudrate runterschrauben und bei Gpio
Ansteuerung müsset du die Timings (delays) ein wenig anpassen.
Bei 10 Werten pro Tag ist es wohlmachbar.
mfg
Die Leitung zu deinem Display ist def. viel zu lang.
Da kommen haufenweise Störungen rein. Das wirst du durch Kondensatoren
kaum verhindern können.
Die Idee von Benedikt ist genau richtig, allerdings ist die Kabellänge
für I2C auch schon recht lang, nur kann man das, wenn noch Störungen
auftreten, durch weitere IC's (Portextender P82B715) verlängern.
Damit wirst du dein Problem mit den Störungen los.
Hallo,
momentan ist das Display per GPIO angeschlossen. Ich hatte mir schon
gedacht, dass das Kabel dafür zu lang ist, weil die 2. Steuerung (wo das
Displaykabel nur 20 cm hat) einwandfrei funktioniert.
Danke für den Tipp mit I2C, habe mir gestern noch drei Adapter bestellt.
Die Timings kann ich beim Arduino nicht verändern, soweit ich weiß.
Gruß Björn
Björn schrieb:> Die Timings kann ich beim Arduino nicht verändern, soweit ich weiß.
Warum nicht?
Auf deinem Arduino Board werkelt höchstwahrscheinlich ein ganz normaler
Microkontroller von Atmel. Die Dinger kann man programmieren und dann
manchen die genau was man ihnen gesagt hat (wenn die Hardware stabil
läuft).
Björn schrieb:> Die Timings kann ich beim Arduino nicht verändern
Selbstverständlich kannst du das Timing ändern. Du musst dich nur von
den mitgelieferten Software Schablonen lösen und selbst programmieren.
Aber dein Problem ist weniger das Timing, es sind die verschliffenen
Flanken deiner Signale, bedingt durch das viel zu lange Kabel.
Versuch mal in die langen Leitungen Serienwiderstände einzubauen. So
33/47/100Ω (Größenordnung). Das besänftigt die Flanken und ist einfach
auszuprobieren.
Georg G. schrieb:> Selbstverständlich kannst du das Timing ändern. Du musst dich nur von> den mitgelieferten Software Schablonen lösen und selbst programmieren.
So arg muss man es gar nicht treiben. Ein paar NOPs zwischen Setzen der
Datenleitungen und Übernahmeflanke bei der LCD-Ausgabe dürfen schon
reichen, falls es an Signalverschmierungen liegt.
Ein Oszi hilft da Wunder, um das zu beurteilen. Aber Trial&Error führt
vielleicht auch irgendwann zum Ziel.
Servus,
du könntest auf ein weniger capazitives Kabel umsteigen. Schneide ein
Lan Kabel auf (cat5). Hat ja 8 Adern :).
Laut Datenblatt heißt es:
Enable rise/fall timetEr, tEf max 20ns.
mfg
oder erhöhe die Treiberleistung
2,2k bis runter 560 Ohm pullups am Ende des Kabels (LCD) sollte die
kapazitive Umladung wieder schneller machen.
Timing verlängern wie schon vorgeschlagen geht natürlich auch.
Joachim B. schrieb:> oder erhöhe die Treiberleistung>> 2,2k bis runter 560 Ohm pullups am Ende des Kabels (LCD) sollte die> kapazitive Umladung wieder schneller machen.>> Timing verlängern wie schon vorgeschlagen geht natürlich auch.
Servus,
er hat KEIN i2b bus, sondern normale Gpio Ansteuerung.
Aber du hast einerseits recht, man kann die Gpio Ausgänge als open drain
deklarieren und mit Pullups arbeiten.
Aber ich denke das übersteigt das Wissen des TE´s.
mfg
Joachim B. schrieb:> Timing verlängern wie schon vorgeschlagen geht natürlich auch.aSma>> schrieb:> Laut Datenblatt heißt es:> Enable rise/fall timetEr, tEf max 20ns.
Ja, das timing bringt nichts, wenn die Flanke mau ist :(.
Wenn dir die Erfahrung fehlt, solltest du nicht an der Hardware
rumbasteln. Mach es mit I2C, das ist deutlich einfacher und wird bei der
Kabellänge auch ohne Änderungen funktionieren.
Sollte das mit der Länge von 1 Meter nicht funktionieren, kannst du 2
von den Portexpander zwischenschalten. Wie schon geschrieben.
Dieter S. schrieb:> Wenn dir die Erfahrung fehlt, solltest du nicht an der Hardware> rumbasteln.
Und was genau spricht jetzt gegen die Verlängerung des Schreibzyklus für
das Display, damit trotz kapazitiver Belastung bei der Latch-Flanke
stabile Pegel anliegen bzw. der Latch-Puls überhaupt voll zwischen den
Logikpegeln hin- und her schaltet?
Wolfgang schrieb:> Dieter S. schrieb:> Wenn dir die Erfahrung fehlt, solltest du nicht an der Hardware> rumbasteln.>> Und was genau spricht jetzt gegen die Verlängerung des Schreibzyklus für> das Display, damit trotz kapazitiver Belastung bei der Latch-Flanke> stabile Pegel anliegen bzw. der Latch-Puls überhaupt voll zwischen den> Logikpegeln hin- und her schaltet?
Warum interpretierst du mein Post verkehrt?
Ich habe nicht dagegen gesprochen.
Dieter S. schrieb:> Warum interpretierst du mein Post verkehrt?> Ich habe nicht dagegen gesprochen.
Du hast sogar für eine Änderung der Hardware und Verwendung eines ganz
anderen Bus-Systems plädiert, statt erstmal der einfachen Lösung mit dem
gezielten Plazieren von ein paar NOPs eine Chance zu geben ;-)
Wolfgang schrieb:> Dieter S. schrieb:> Warum interpretierst du mein Post verkehrt?> Ich habe nicht dagegen gesprochen.>> Du hast sogar für eine Änderung der Hardware und Verwendung eines ganz> anderen Bus-Systems plädiert, statt erstmal der einfachen Lösung mit dem> gezielten Plazieren von ein paar NOPs eine Chance zu geben ;-)
Dann solltest du bitte mal den kompletten Post lesen. Da steht: Wenn dir
die Erfahrung fehlt...
Und nicht "Du musst..."
Letztendlich überlasse ich die Entscheidung immer dem User.
Wolfgang schrieb:> Dieter S. schrieb:>> Warum interpretierst du mein Post verkehrt?>> Ich habe nicht dagegen gesprochen.>> Du hast sogar für eine Änderung der Hardware und Verwendung eines ganz> anderen Bus-Systems plädiert, statt erstmal der einfachen Lösung mit dem> gezielten Plazieren von ein paar NOPs eine Chance zu geben ;-)
Oder der genauso simplen Platzierung von ein paar Serienwiderständen in
den vermutlich "klingelnden" Leitungen und/oder Abschlußwiderständen am
LCD-Ende der Leitung. Beides bedämpft die durch die Leitungen gebildeten
Schwingkreise. Und es behebt, anders als die NOP's das eigentliche
physikalische Problem.
Hallo,
ich werde erst mal die I2C Verbindung testen, da mir die Kabeleinsparung
sehr gelegen kommt. Momentan habe ich nämlich fast alle Ports des
Arduino belegt.
Einen 100 Ohm Widerstand hatte ich schon in der E-Leitung getestet, aber
es hat nichts bewirkt.
Wenn I2C auch nicht geht, werde ich nochmal auf die Basteleien mit
Widerständen und Software-Anpassungen zurückkommen.
Ich möchte aber am liebsten eine Lösung, bei der man nah am Standard
bleiben kann.
Danke und Gruß
Hallo,
seit dem Umbau auf I2C Verkabelung sind keine Bildfehler mehr
aufgetreten.
Leider ist das Display jetzt nicht mehr so kontrastreich wie vorher,
aber da kann man wohl nichts machen...
Hallo Börn,
hier ist noch eine weitere Anregung.
Wenn ich ein abgesetztes LCD benötige, dann nutze ich ein serielles
Datenprotokoll, wie 600Bit/s - 460800Bit/s,none,8,1 ein.
Evtl. muss ich noch RS232 Pegelkonverter einsetzen oder bei kleineren
Entfernungen reichen auch TTL Pegel mit 0V und +5V aus.
Die Idee und der Befehlssatz stammt aus
"Parallax Serial LCD Product Guide"
https://www.parallax.com/downloads/parallax-serial-lcd-product-guide
Meine Firmware ist mit dem dargestellten Befehlssatz kompatibel und hat
noch eine Erweiterung in Richtung Ausgabe von Morse-Zeichen erhalten.
Durch die Firmware kann man u.a. auch kleine Musikstücke zum Atmel
übertragen und abspielen lassen. Die Tongenerierung erfolgt, wie im
Original auch, über PWM., deshalb auch der "harte" Klang.
Björn C. schrieb:> Hallo,>> seit dem Umbau auf I2C Verkabelung sind keine Bildfehler mehr> aufgetreten.> Leider ist das Display jetzt nicht mehr so kontrastreich wie vorher,> aber da kann man wohl nichts machen...
Der Kontrast ändert sich durch die u.U. veränderte Spannung am LCD.
Das kannst du durch ändern der Potieinstellung anpassen.
Wenn kein Poti vorhanden ist, müssen die Festwiderstände dazu geändert
werden.
Hallo,
es ist ein Poti vorhanden.
Aber auch bei der besten Einstellung ist der Kontrast leider etwas
schlechter als bei direkter Verbindung mit dem Arduino.
Dann hast du noch einen Fehler in deiner Anschaltung. SOOO hochohmig
können die Leitungen nicht sein, das bei den paar mA nennenswerte
Spannungsabfälle entstehen. Poste ein gutes Bild des realen Aufbaus.
Björn C. schrieb:> seit dem Umbau auf I2C Verkabelung sind keine Bildfehler mehr> aufgetreten.> Leider ist das Display jetzt nicht mehr so kontrastreich wie vorher,> aber da kann man wohl nichts machen...
Vermutlich wird nun deine Anzeige mehrmals pro Sekunde gelöscht und neu
beschrieben, was zur Abnahme des Kontrastes führt.
Schau dir mal die Anzeigeroutine an.
Das könnte natürlich sein. Wäre dann ja ein systembedingtes Problem bei
I2C.
Mein Programm habe ich mit/für "Arduino" geschrieben und es sendet nur
ganz selten Aktualisierungen ans Display.
Kann man die Frequenz für die Displayaktualisierung ggf. reduzieren oder
gibt es andere Ideen?
Björn C. schrieb:> Kann man die Frequenz für die Displayaktualisierung ggf. reduzieren oder> gibt es andere Ideen?
schreib die Routinen selber, reserviere dir Platz für deine 2 Zeilen und
Zeichen, char zeile1[] usw.
schreibe in zeile1 und 2 und aktualisiere nur 2-4x pro Sekunde, in einer
ISR ein LCDupdate flag setzen, in der loop nur neu schreiben wenn die
Zeit reif ist.
Statt LCD komplett löschen ist es besser nur die benötigten Zeichen zu
überschreiben notfalls mit <SPACE> 0x20 oder 32
Besteht das Problem auch, wenn das Display direkt am Arduino betrieben
wird, also ohne Kabel dazwischen.
Mir ist so nicht bekannt, dass sich der Kontrast über I2C verändert.
Hast du mal die Spannung am Display gemessen?
Du verwendest doch auch die Hintergrundbeleuchtung.
Eine eigene Frage?
Dieser Thread ist über 10 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
IMG_0529.JPG
(130 KB)
