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
Angehängte Dateien:
-
IMG_0529.JPG
130 KB
http://www.miniinthebox.com/de/iic-i2c-2-5-blue-screen-lcd-display-modul-fuer-arduino_p1141469.html sowas in der art dann hast du nur noch 2 Leitungen die gestört werden könnten.
...Schaltplan, ...Programm, ...sonstige Nebenbedingung ? ...also also das übliche für die Glaskugel!
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.
Dieter S. schrieb: > allerdings ist die Kabellänge für I2C auch schon recht lang Das kann man so oder so sehen. NXP spricht in seiner AN10658 bei 100 Metern Länge von "long communications cables", wenn es um I2C geht. http://www.nxp.com/documents/application_note/AN10658.pdf
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.
Achso, ich arbeite mit der normalen Arduino IDE, das ist mir momentan genug Programmierung.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.