LCD Display spinnt - Leer oder Sonderzeichen

Mittlerweil bin ich am Verzweifeln.
Wollte eigentlich nur ein LCD an meinen ATmega8-16PU auf Pollin v2-Board anschließen. Das LCD ist ein 2x16 Standarddisplay. Als Anschlussvariante habe ich 4bit ohne Busy gewählt.

Habe zuerst die Pins 7-10 nicht an GND gelegt und das Beispielprogramm hier unter /wissen/ benutzt (natürlich mit angepassten PINs):

Code:

---

$regfile = "m8def.dat"
$crystal = 16000000

Config Lcd = 16 * 2                                        'wir verwenden ein 16 x 2 Zeichen Display
' Im I/O Mode wird jeder Prozessor Pin einzeln angegeben
Config Lcdpin = Pin , Db4 = Portc.2 , Db5 = Portc.3 , Db6 = Portc.4 , Db7 = Portc.5 , E = Portc.1 , Rs = Portc.0

Config Portc = Output

Cls                                                        'loesche das LCD Display
Locate 1 , 1                                                'Cursor auf 1 Zeile, 1 Spalte
Lcd "Hello world."                                          'String auf Display anzeigen

---

Zuerst zeigt das Display brav eine Zeile weiß an (ich nenn es mal Testbild), nach 2 Sekunden wird es farblos und zuckt manchmal. Als ich mal zufällig an die Stromversorgung gekommen bin, war plötzlich Text zu sehen, viele Sonderzeichen und Fragmente von Hello world. Also stimmen die DataPINs und der Kontrast schonmal. Der Text verändert sich aber alle paar Sekunden.
Nach einem END Befehl im Programm zuckt das Display nicht mehr. Dafür geht das mit den Sonderzeichen auch nicht mehr, einfach nur leer ist es, wobei der Kontrast beim Testbild besser ist.

Hab mal ein wenig im Forum gelesen und Try&Error gemacht. Die Spannungsquelle gewechselt und die Spannung verändert bringt nix. Seit ich die PINs 7-10 auf GND gelegt hab, kommt nur noch das Testbild, CLS geht nicht mehr. Diagnose-LEDs zeigen, dass das Programm an sich aber noch läuft. "Config Lcdbus = 4" hab ich auch mal hinzugefügt. Beim Quarz bin ich mir ziemlich sicher, dass es ein 16MHz ist, hab aber 8 auch mal ausprobiert.

Hat jemand noch ne Idee was da faul sein könnte?

Zitat:

---

Als ich mal zufällig an die Stromversorgung gekommen bin, war plötzlich Text zu sehen

---

...da wird wohl der Hase im Pfeffer liegen.

Klingt nach zufälligen Dateneingaben. Prüfe, ob alle anschlüsse koreckt verlötet sind, und es keine Kalten lötstellen gibt. Eventuel, wenn du ein Oszi besitzt, dann miss mal an der Enabled-Leitung, ob du unverältnissmäsige Takte bekommst. Diese lassen das Display nömlich Daten lesen, was bei chaotischer Spannungsbelegung an den Datenleitungen zu chaotischen Ausgaben, und Steuerungen führt.


JimJim
XUN

Die Anschlüsse habe ich visuell überprüft und für gut befunden.
Ein Test am Oszi (gemessen direkt am LCD) zeigt, dass auf allen Pins der Pegel sauber zwischen 0 und 5V springt, auch wenns manchmal sehr schnell geht (µs-Sprünge dürfte das Auge wohl kaum wahrnehmen).
Damit entfällt auch die Möglichkeit, dass ich auf dem Board Anschlüsse per Jumper fehlgeleitet habe (was ich natürlich bereits im Vorfeld überprüft hatte).

Hab da mal ein leicht abgewandeltes Testprogramm geschrieben; es führt regelmäßig CLS+Textausgabe+einen Shift aus, was an sich eigentlich Käse ist, da ja der Puffer jedesmal neu beschrieben wird und der Shift daher nicht funktioniert. Und jetzt das erstaunliche: Je nach Einschaltzeitpunkt des Displays geht nur die (fehlerhafte Textausgabe) oder der Shift bei leerem Display (sieht man am Cursor). Für mich sieht es aus, als würden entweder nur Kommandos ohne Daten oder Daten, aber keine Kommandos verarbeitet. Könnte man jetzt natürlich genaustens mit einem Speicheroszi analysieren, aber sowas hab ich nicht und das sprengt hier den Rahmen.

Ich hoffe halt darauf, dass jemand hier schonmal ein ähnliches Problem gehabt hat und mir nen kleinen Tip geben kann :-)
Z.B. KS statt HD Controller oder sowas...

Seltsam ist, dass wirklich nix mehr geht wenn PINs 7-10 auf Masse liegen...

Ich würde dir jetzt nur noch vorschlagen, den Takt der Datenbertragung runter zu schrauben.

Wenn du diese Taktrate am Controler nicht einstellen kansnt, dann verdrahte das Display einmal mit dem PC, und nutze ein ... z.B. VB Programm, mit dem du das Display ansteuerst. Dann kannst du dort z.B. ein 1Sek. Takt einstellen, udn genau nachvolziehen, ob die SIgnale sauber und mit passnder Flankensteilheit übertragen werden.

Wenn die Enabled-Leitung eine unsaubere Steilheithat, oder sogar Flattert, beim aufsteigen, kan dies zu fehlinformationen führen.
Gleiches Gilt für die Ausführungszeitpunkte. Nicht alle Display haben die selben Zeiten für ein Kommando. Eventuell gibt es damit Probleme. (Zu schnelle Kommandos)


JimJim
XUN

Hi,

der Takt ist egal, muß man nur Bascom mitteilen und der Compiler macht dann den Rest. Ich arbeite gerade an einer Schaltung mit 14,7irgendwas MHz, null Probleme.

Die Datenleitungen D0-D3 haben eigentlich im Controller interne Pull Ups. (Laut Datenblatt) Also einfach frei lassen sollte gehen. Ich mache das Grundsätzlich so und hatte noch nie Probleme.

Das Portc = Output kannst Du Dir sparen.
Bascom macht das mit "Config Lcdpin = ..." selber.

Untersuch nochmal Deine Lötverbindungen gründlich und stell sicher das der Takt von 16MHz auch wirklich im Chip ankommt. (Fuses)

Der Code den Du eingestellt hast sollte tun. (Hinten noch ein End ran)

Das nach END der Spuk ein Ende hat läßt vermuten das irgendetwas sonst noch auf Portc passiert.

Ist das oben Dein einziges Programmteilchen oder ist da noch mehr was auf Portc irgend etwas ausgibt?

Welcher Controller ist eigentlich genau drauf? Wirklich ein 44780 oder ein KS00066? Oder sonst was? Da gibt es feine aber entscheidende Unterschiede.

OK, mein eigenes Projekt ruft und das Weizen im Kühlschrank will auf´m Balkon noch was von der warmen Sonne haben! ;)

Gruß Dnerb

Danke erstmal für die vielen Tipps.

Der Takt von 16 MHz war falsch (kein FUSE gesetzt = interner Taktgeber), das habe ich aber gestern noch selbst rausgefunden und durch $Crystal=1000000 behoben. Leider immer noch das gleiche Resultat.

Config Portc hab ich auch mal weggelassen - keine Änderung
Das gepostete Testprogramm ist wirklich das einzige Programmteilchen!

Der Controller ist mir nicht explizit bekannt, habe das Display von Pollin (BestNr 120422) unter dem Stichwort "Industriestandard-konformer Controller" erworben. Wenn jemand bei kleinen Dotmatrix-Displays von Standard spricht, kann er ja eigentlich nur den HD44780-Controller meinen.

Ich möchte nochmal betonen, dass ohne Spielerein an der Stromversorgung bei definiertem Betriebszustand das Display lediglich vom Testbild auf einen leeren Bildschirm wechselt, wobei die leeren 32 Kästchen im Gegensatz zum Testbild klar erkennbar sind (ca. 20% Resthelligkeit). Sieht für mich nicht nach einem ordentlichen CLS aus.

Löte mal die ganzen Kontakte nach. vieleicht hast du einen nicht sichtbaren Schaden.


JimJim
XUN

Zitat:

---

Zitat von omegazx

Der Controller ist mir nicht explizit bekannt, habe das Display von Pollin (BestNr 120422) unter dem Stichwort "Industriestandard-konformer Controller" erworben. Wenn jemand bei kleinen Dotmatrix-Displays von Standard spricht, kann er ja eigentlich nur den HD44780-Controller meinen.

---

"Industriestandard-konformer Controller" hm :-k meiner Meinung nach gar nicht mal so vielsagend. Muß ich mir mal bei Pollin anschauen.

...

Das Datenblatt bei Pollin gibt nichts her...

Falls sich keine Lösung findet, könnte ich Dir zum Vergleich ein 1x16 schicken für 2€+Porto. (Selbstkosten, mal bei ebay ein paar im komplettangebot ersteigert) Ist halt schwarz auf grau ohne Beleuchtung, aber es tut. ;-)

Das funktioniert 100% mit Bascom. Ich teste es dann auch nochmal bevor ich es versende um sicher zu gehen.

Gruß Dnerb

Das Datenblatt ist echt ohne Informationsgehalt...
Hab recherchiert und *tada* es ist von Tinsharp (100% sicher) und benutzt den Controller SPLC780D-001B-C (aus Sekundärquelle). Da es für den auch ein ordentliches Manual gibt (http://www.lcdproduct.com/Tech/Contr...PLC780D_DS.pdf) und es mit den Bascom-Standardroutinen eh nicht funzt, werde ich dadrin mal selbst ein wenig schmökern.

Ah, sehr schön.

Das PDF schieb ich gleich mal in meinen Ordner mit den PDFs von den anderen Controllern die ich so gesammelt habe. Muß mich echt mal dranmachen und durchschauen wo irgendwelche interessanten unterschiede sind...

Hallo

Das Display hat hat einen HD44780-Controller (oder einen der gleich arbeitet)

Ich habe das selbe Display und hatte anfangs auch Probleme, so wurden z.B:
Falsche Zeichen angezeigt
Nur Weiße Balken angezeigt
Lücken mit komischen Zeichen gefüllt
Bild Zuckte

Ich habe dann dass Programm angepasst und jetzt funkt es, hier mal mein Programm:

Code:

---



$regfile = "m32def.dat"
 $crystal = 16000000

 Config Lcd = 16 * 2                                        'wir verwenden ein 4 x 20 Zeichen Display
 ' Im I/O Mode wird jeder Prozessor Pin einzeln angegeben
 Config Lcdpin = Pin , Db4 = Portb.0 , Db5 = Portb.1 , Db6 = Portb.2 , Db7 = Portb.3 , E = Portb.5 , Rs = Portb.4

 Config Lcdbus = 4


Cls

 Do

 Locate 1 , 1
 Lcd "Sensor1: 125cm"


 Locate 2 , 1
 Lcd "Sensor2: 80 cm"

  Loop

---

Kannst mal testen ob dass so funktioniert.

Zitat:

---

und es mit den Bascom-Standardroutinen eh nicht funzt

---

Tut es sehr wohl


€dit: Hier noch ein Bild davon:
Bild hier  

mfg Luca

Morgen,

hm, könnte es sein das es daran liegt das im Programm von omegazx das "Lcdbus = 4" fehlt?

Darauf habe ich gar nicht geachtet!

Wenn bei den Combiler Settings nämlich 8-Bit eingestellt ist, dann kommt nur Müll am Display raus.

omegazx übernehmen Sie! ;-)

Gruß Dnerb

Hallo

@Dnerb

Zitat:

---

Zitat von omegazx

Config Lcdbus = 4" hab ich auch mal hinzugefügt.

---

Ich habe eben mal das Programm dass omegazx am Anfang gepostet hat bei mir getestet, funkt super. Ich vermute dass omegazx einen verkabelungs Fehler gemacht hat.

mfg Luca

Nun ja, es ist ja nichts auszuschließen... :-)
Also die Verkabelung sieht folgendermaßen aus:

1 GND
2 +5V
3 GND
4 PB4
5 GND
6 PB5
7 open
8 open
9 open
10 open
11 PB0
12 PB1
13 PB2
14 PB3
15 +5V
16 GND

Die Kabel sind jeweils 40cm lang, paarweise verdrillt und nicht abgeschirmt. Hab mal von PortC auf PortB gewechselt, keine Änderung. Der gepostete Code geht genausowenig. (oben ist die geänderte Belegung schon zu sehen)

Ich werde die Tage mal auf ein kurzes Flachbandkabel wechseln und in dem Zuge die Kontakte neu löten.

Das Poti an PIN3 hab ich nach sehr gutem Kontrast des Testbildes bei Kontrastspannung 0V entfernt und auf GND gelegt. Sollte da noch ein Widerstand rein?

Zitat:

---

Zitat von Dnerb

Die Datenleitungen D0-D3 haben eigentlich im Controller interne Pull Ups. (Laut Datenblatt) Also einfach frei lassen sollte gehen. Ich mache das Grundsätzlich so und hatte noch nie Probleme.

---

ich schließe an diese extra GND an, damit das signal da definiert ist. Wenn da high anliegen würde könnte man doch gar nicht den Befehl für 4bit mode senden, oder?

Hallo

1.Port 15 unbedingt mind. 5 Ohm Widerstand zwischenschalten sonst stirbt Hintergrundbeleuchtung schnell!

2. Port 7-10 an GND anschließen, ist besser.

3. Du weißt dass die Pinbelegung die du hier gepostet hast nicht mit der in deinem Programm überein stimmt?


Sonst ist alles in Ordnung, kann dir auch nicht helfen, mein Tipp, Löte das ganze auf eine Lochrasterplatine und verkable es dort. Ich habe dann ein 10Pol Flachbandkabel genommen um das Display mit dem Controller zu verbinden, so kann man es immer wieder schnell ab und an stecken.

Ich würde auf das Poti nicht verzichten, denn Temperaturunterschiede können den Kontrast verändern.


Hier noch ein Bild meiner Platine:

Bild hier  

mfg Luca

Servus!

Auch wenn das Thema nun schon über ein Jahr alt ist, wollte ich mal fragen ob
omegazx das Display ordentlich zum laufen bekommen hat.

Ich habe das Display bei mir an einem ATMega 16 in Betrieb genommen.
Initialisierung klappt auch soweit, nur fängt das Display nach etwa 1-2 Tagen an zu spinnen. Es zeigt entweder nur kryptische Zeichen, 16 weiße Balken in der 1. Reihe (was auf keine Initialisierung hinweisen dürfte) oder garnichts an.

Das Problem habe ich hier schon beschrieben (bevor ich diesen Thread gefunden habe): https://www.roboternetz.de/phpBB2/ze...750&highlight=

Evtl. weiß jemand ja Rat...

Gruß, Sven

Nein, omegazx hat das Display nicht zum Laufen gebracht :(
Nach ein paar weiteren Versuchen ging der Schreibvorgang auf dem Microcontroller nicht mehr (Problem ist ja bekannt bei Atmega) und so hab ich dann auch kein zweites Display für weitere Tests besorgt.