-         

Ergebnis 1 bis 7 von 7

Thema: Störsicherheit von LCDs...?

  1. #1
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987

    Störsicherheit von LCDs...?

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    Moin.

    Bei nem Versuchsaufbau hing ein Grafik-LCD (Pollin-Klassiker 128x64, blau/weiss) per Kabel (waren gut 15-20cm) an nem ATMega32. Funktionierte dort wunderbar.

    Hab dann ne Platine gemacht, auf der ein ATMega2560 (über das RN-Modul) arbeitet; Das Display liegt auf der Platine gleich daneben, die längste Leiterbahn mit Daten zum Display hat ca. 8cm. Und dort geht beim Display eigentlich garnix mehr.
    Von Zeit zu zeit lässt sich schon was vom eigentlichen Inhalt erkennen, jedoch verrutscht und einige Zeilen sind durchgehend weiss.
    Die meiste Zeit ist das Display aber leer.
    In der Software hab ich nur die #defines für die Portbezeichnungen geändert.

    Ich hab dann zuerst die PWM-Leitung für die Hintergrundbeleuchtung als Fehlerquelle vermutet; dort konnte man z.B. bei mittlerer Helligkeit eine "Wellenbewegung" durch ddie PWM erkennen. Hab dann parallel zur Stromversorgung des LCD nen 22µF-Elko und parallel zur Beleuchtung nen 47µF Elko hin und schon war die Bewegung weg; das Display geht aber dort immer noch nicht.

    Der Verdacht einer schlechten Kontaktierung fällt weg, da ich jede einzelne Leitung vom Display-Lötanschluss bis hin zu den Pins vom ATMega nachgemessen hab.
    Ebenso schaltet auch jeder Pin sauber zwischen 0 und 5V, wie er soll.

    Die Frage ist jetzt: Wie empfindlich sind diese LCDs?
    Meinte mal, dass die Leitungen 10cm nicht überschreiten sollten. Nur dann wunderts mich, dass es bei max. 8cm nicht geht, bei 15-20cm aber schon.

    Hab mal die Eagle-Daten (4.16) angehängt, sowie die bisherigen Sources.
    Evtl findet da jemand den Fehler (wobei davon ausgegangen werden kann, dass die Sources fehlerfrei sind; ging ja mit der anderen Hardware auch)

    mfG
    Angehängte Dateien Angehängte Dateien
    #ifndef MfG
    #define MfG

  2. #2
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    66
    Beiträge
    10.969
    Hallo Jaecko!

    Ich bin zwar PIC Benutzer, habe mich aber mit GLCDs ziemlich viel beschäftigt und versuche jetzt dir meine Meinung sagen.

    Diese Displays sind auf Störungen nicht so empfindlich. Du hast aber viele Sachen geändert und somit die Fehlersuche erheblich erschwert. Die Displaykontroller können nur bis zur bestimmter Frequenz richtig funktionieren. Arbeiten die beiden µC mit gleicher Taktfrequenz?

    Ich vermute, dass das Display von dem anderen µC nicht richtig angesteuert wird. Ich würde das Display zuerst mit bisherigem kabel (15-20 cm) an dem ATMega2560 testen.

    Erst wenn das fehlerfrei funktioniert, würde ich evtl. Fehler auf der Platine suchen.

    MfG

  3. #3
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    Beide AVRs laufen mit 16MHz.
    Ich hab auch mal versucht, den Enable-Puls zu verlängern, also nicht diese paar Zyklen wie sie jetzt sind, sondern mal Werte bis hoch zu einigen ms zu verwenden (was bei der anderen Kombination problemlos klappt, aber halt den Bildaufbau halt entsprechend verlangsamt). Nur hier wieder Funkstille.

    Hab an den anderen (vorherigen) AVR auch mal die Steckverbinder drangebaut, wie sie auf der Platine sind, Display dran, Programm (mit angepassten Ports) drauf und da rennts wieder.

    Durchs Nachmessen tut sich beim 2560 bei jedem Pin was.

    Ein Logikanalyzer wär jetzt was feines... im Oktober wär ich wieder an der FH und hätt da wieder Zugang... aber bis dahin dauerts noch.
    Nur:
    - Wenn alle Ports korrekt schalten
    - Keine Ports defekt sind
    - Keine Kurzschlüsse da sind
    - Alle Leiterbahnen unbeschädigt und korrekt verlötet sind
    - Das Progamm selbst korrekt arbeitet
    - Das Display unbeschädigt ist...
    ... dann müssts doch eigentlich gehen.

    Der Schaltplan ist exakt nach dem Aufbau am ATMega32 entstanden; beim Platinen routen kann man eigentlich bis auf vergessene/sich kreuzende Bahnen keinen Fehler machen; und diese Fehlerquellen hab ich schon überprüft und ausgeschlossen.

    Werd mal weitersuchen und testen...
    #ifndef MfG
    #define MfG

  4. #4
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    66
    Beiträge
    10.969
    Es müsste doch gehen, ohne Logikanalyser das Display direkt (ohne Platine) aus dem ATMega2560 anzusteuern.

    MfG

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    also ich hab jetzt mal alle Leiterbahnen fürs Display mit Kabeln ersetzt; diese gehen von den Anschlüssen am ATMega-Modul direkt zum Display... resultat: immer noch tot...
    Gegenprobe: ATMega32 wieder hingefummelt: Geht wieder...

    Langsam kommt die Vermutung auf, dass mit dem Modul was nicht stimmt... Nur wüsste ich nicht, was da nicht stimmen soll, da die Pins ja alle schalten (LED hinhalten, die blinkt, wenn der Displayinhalt aktualisiert werden sollte)
    #ifndef MfG
    #define MfG

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    So... Fehler gefunden... und zwar an ner Stelle wo man's nicht vermutet: Im Display selbst.

    Dort war bei 3 Datenleitungen ein Haarriss (u.a. Enable), so dass die Verbindung vom Lötanschluss zum Controller auf dem Display unterbrochen war. Je nach dem, wie das Display liegt, war dann Kontakt da oder auch nicht; Beim M32 lag das Ding immer etwas auf Zug, d.h. Kontakt war da. Hab die Bahnen jetzt mit etwas Fummelei und Lötsilber geflickt und schon rennts.

    Gefunden wurden die Leitungen, in dem ich einfach ein Stück vom Lötstoplack befreit hab, kurz bevor die Bahnen unter die schwarze Schutzmasse der Controller verschwinden. So waren die dann messbar.

    Und wieder ein Punkt mehr für die Liste "mögliche Fehlerquellen"...
    #ifndef MfG
    #define MfG

  7. #7
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    66
    Beiträge
    10.969
    Es freut mich sehr, dass du den Fehler gefunden hast.

    Mann muss leider immer eine Fehlerquelle neu suchen, weil alle möglichen nicht zu merken sind. Wenn man nach einer "laaanger" Liste suchen würde, kann es passieren, dass es länger dauern würde.

    MfG

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •