4-Bit LCD Initialisierung KS0066

[stmiko]

Hallo zusammen,

ich versuche nun schon seit einiger Zeit ein 16x4 LC-Display mit dem genannten Controller zu initialisieren. Leider hatte ich noch keinen Erfolg und bin auf euer Forum gestoßen und hoffe, dass ihr mir vielleicht helfen könnt.
Ich habe die Initialisierungsschritte laut dem Datenblatt programmiert:

void init_lcd(void)
{

	LCD_DDR = 0xff;
	

	LCD_PORT |= (1<<EN); //Enable-Eingang setzen

	_delay_ms(80);

	
	
	LCD_PORT |=  (1<<DB5);	//
	_delay_us(1);
	LCD_PORT &= ~(1<<DB5);
	_delay_us(1);
	LCD_PORT |=  (1<<DB5);
	LCD_PORT |= (1<<DB6) |(1<<DB7); //Einschalten von Display im 2 Zeilenmodus


	_delay_us(150);


	LCD_PORT &= ~((1<<DB5) | (1<<DB6) |(1<<DB7));
	_delay_ms(1);
	LCD_PORT |= (1<<DB6) | (1<<DB7);


	_delay_us(150);


	LCD_PORT &= ~((1<<DB6) |(1<<DB7));
	_delay_ms(1);
	LCD_PORT |= (1<<DB4);

	
	_delay_ms(5);


	LCD_PORT &= ~(1<<DB4);
	LCD_PORT |=(1<<DB4) |(1<<DB5) |(1<<DB6);

	_delay_ms(5);

	
	
	}

Die verschieden Bezeichner wurden im Vorfeld definiert... Nun frage ich mich, ob an dieser Art und Weise der Programmierung der Fehler zu suchen ist, oder die "Ablaufkette" an sich fehlerhaft ist.
Einige Assemblerbeispiele sind im Forum zu finden, bloß möchte das Projekt in C verwirklichen.

 

[Oskar01]

Hallo @stmiko,

zum Laufen bekommst Du das 16x4 auf jeden Fall.
Zur Not eben über die Assemblerprogrammierung.
Wenn das ASM-LCD-Programm läuft, kann dann ja "forward engieert" werden in C.

Es müßten aber ein paar grundsätzliche Fragen im Vorfeld abgeklärt werden.
Als da wären:

Wieviele Controller?
Interessant wäre das tatsächliche LCD-Pinout
Nehme mal an 2 : einen für Zeile 1 und 3, einen für Zeile 2 und 4 (oder laut Display-Datenblatt entsprechend)

Die Timing-Bedingungen:
Mir scheinen die Pausen von 150 ySec zwischen den Befehlen (mit oder ohne Busy-Flag-Abfrage - ist in der Praxis eigentlich "wurst") doch arg kurz.


Die korrekte Programmierung des Enableimpulses.
(Wenn Du 2 Controller hast, brauchst Du auch 2 Enable-Impulse.)

Setzen der Steuersignale RS , R/W, und eben Ena im Programmverlauf.

Die Zuweisung dieser ganzen "Steuersignale" auf die Portbits - Definitionssache- muß aber im Programm strengstens beachtet werden.

Die ASM-Beispiele verwenden bestimme Ports, die dann auch im ASM-Prog
am Anfang irgendwo deklariert wurden (oder auch noch zusätzlich als Kommentar eingefügt sind).

Am besten erst einmal ein kleines Flußdiagramm zeichnen,
dann geht es an die einzelnen Befehlsfolgen in der Initialisierung.
Diese Kontroller sind bis auf wenige Ausnahmen HD44780-kompatibel. Auch der KS0066U. Die Initialisierungsbefehle sind ausnahmslos dieselben.
Der Teufel steckt im Detail , hier besonders im unterschiedlichen Timing.

Gruß
von Oskar01

 

[stmiko]

Hallo Oscar,

laut Datenblatt ist das ein Controller, der intern 2 Zeilen in 4 sichtbare aufteilt. Man gibt dann laut Datenblatt die Anfangsadresse der entsprechenden Zeile ein, um auf diese etwas darzustellen.

Ich habe das "Datenblattheft" unter folgenden Link im Netz gefunden.
In dem Heft ist die 4-Bit Initialisierung auch beschrieben.
http://www.mmajunke.de/LCD_Module.pdf

Für mich stellt sich nun die Frage, wie das Enablesignal richtig verwendet wird.

 

[Oskar01]

zuerst mal initialisieren

Hallo @stmiko,
wie gesagt, erst einmal die "Grundinitialisierung" in den Griff bekommen.
Damit wir uns nicht im Detail verlieren.
(Die Zeit, die man hier an "Studium" investiert, lohnt sich bestimmt - ca. 1 Stunde - )

Tipp:

http://www.avr-praxis.de/forum/showthread.php?t=232


Danke

Gruß von Oskar01

 

[Oskar01]

Habe Datenblatt angeschaut

Hallo @stmiko...,
hatte leider die Woche über nicht viel Zeit, trotzdem mal ganz kurz das Datenblatt überflogen.
Fazit: Die Sache ist wohl einfacher, als zunächst angenommen.
Frage:
Wie gehen wir jetzt am sinnvollsten vor?

Würde vorschlagen, zunächst einmal nur einen Test zu starten, um überhaupt erst einmal das LCDisplay zum "Leben" zu erwecken.

Irgendwelche später geplanten Anwendungsfälle also zunächst außer Acht lassen.

Punkt eins:
Ohne irgendwelche Bus-Verschaltung zunächst einmal an den LCD-Versorgungsspannungsanschlüssen die angegebene Spannung anlegen (Vcc +5Volt , Vss Masse, Ground)
Jetzt passiert normalerweise noch garnichts.

Punkt zwei:
Ein Potentiometer vom ca. 10 Kiloohm mit dem einen Ende über Vorwiderstand ca. 4,7 Kiloohm an LCD-Versorgungspannung Vcc (+ 5 Volt), anderes Ende an Vss (Masse, Ground).
Schleifer des Poti an Vee, Kontrastspannungsanschluß.
LCD einschalten. Jetzt am Poti drehen.
Es wird nun brennend erwartet, daß sich je nach Einstellung schon schwache Pixel in Balkenform zumindest auf einer Zeile zeigen.
Ist dem nicht so, brauchen wir erst garnicht weiterzumachen, dann wäre, da dieses im
Datenblatt angegebene LCD keine negative Kontrastvorspannung benötigt, der Test beendet.
(Mit dem Resultat => umtauschen, da "DOA" dead on arrival => schon beim Kauf defekt. )

Ist der erste Test aber positiv verlaufen,
festlegen, welche MCUnit nun zum Testen verwendet werden soll.

Wird mit dem STK500-EVA-Board gearbeitet, könnte entweder der dort schon mitgelieferte ATMega8515 oder ein ATiny2313 verwendet werden.

Hier nun einen Port für den LCD-Bus D0 bis D7 und zunächst mal einen anderen Port für die Steuersignale RS, RWQuer, Enable reservieren.
Dann im ASM-Programm auch die entsprechenden Portdefinitionen vornehmen.

Nur mal ein Beispiel:
PortB für D0 bis D7, das Flachbandkabel liefert auch Vcc und Vss vom Board aus für das LCD.
(zehnadriges Flachbandkabel).

PortD Bit 0 für Enable (standardmäßige MCU-Portbelegung, hier für U(S)ART etc. mal ignorieren), Bit 1 für RS, Bit 2 für RWQuer.

RWQuer würde ich nicht am MCU-Port verlöten, dieser Anschluß kommt direkt am LCD zunächst mal auf logisch "low", sprich Masse (GND), taucht aber im Programm irgendwo
mal wieder auf (für spätere Versuche).

Das zugehörige ASM-Proggi ist als Anhang beigefügt.
Der Rest ist kommentiert und selbsterklärend.

Ach, noch etwas, nimm die Fuses-Einstellung so vor, daß ohne externes Quarz zunächst mit der STK500-Board-Taktfrequenz von 3,686 MHz gearbeitet wird.

Jetzt laß mir noch etwas Zeit, ich passe das Proggi noch an.
Habs im Simulator getestet, sieht gut aus.
(excessive stack overflow, stop simu ---ja,ja, hab ja den Simulator zunächst noch auf ATTiny 2313 laufen gehabt, der hat ja keine hohen Stapelspeicher, der String muß dann rausgeremt werden, ist auch so kommentiert.)

Bis dann

Gruß Oskar01

P.S.:Wenn das läuft, kann der 4-Bit-Modus in Angriff genommen werden.
Dazu müssen nur die Ports dementsprechend umdefiniert werden, die Strings im "Set" angepaßt, ebenso die Label "datenuebernahme" und "kommando" ein bißchen anders gestaltet werden. Ein wenig Lötkolbentätigkeit ist nicht so tragisch, oder? Vakuumpumpe und Entlötlitze bereit? Es braucht dann nur der Flachbandkabelverbinder etwas modifiziert werden. Oder möchtest Du gleich .... dann nochmals auf den besagten "Baustellen"-Link gehen.

http://www.avr-praxis.de/forum/showthread.php?t=232

* Menüeintrag [11]
Direkt "copy and paste" in das
Studio4-Editorfenster und "built".

Für ATTiny2313 ist sogar schon für ganz "Bequeme" das Intel-Hex-File drin -
* Menüeintrag [12].
Habs probehalber up- and downgeloadet.
Da die Endung *.hex meistens mit Editor verknüpft, wird es oft direkt im *.txt-Format gespeichert.
Dann eben so vorgehen:
Nach dem "Ziel- speichern-unter"-Maus-Rechtsklick im Editor öffnen, Datei "speichern unter" "alle Dateien" und den vollständigen Dateinamen mit Endung *.hex eingeben und speichern.
Dieses Hex-File dann in der (Studio4-)Programmiermaske auswählen ....und....flashen.
Siehe da, es funktioniert ( mit Umweg über FTP-Server in Amerika) - bei mir jedenfalls.

Dann dürfte ja nichts mehr schiefgehen.

(Habe auch mal bei bewußt "falschem" Pinout (-bereits für Vierbitmodus verdrahtet-) mal das
Achtbit-Programm unten geflasht. Nur so aus Jux und Dollerei. Auch hier ist dann festzustellen, daß der vorher mit dem anderen vorigen Programm geladene Text auf dem Display wieder erscheint, dann nach Betätigen der Resettaste auf Zeile 1 schwarze Balken.
Also, die Initialisierung ist hier "zumindest teilweise" auch bei völlig fehlerhaftem Pinout ansatzweise ausgeführt worden. Es ist müßig, hier dann noch weiter zu forschen, was da passiert im Einzelnen. Klar, die zufällig auf den Ports stehenden Pegel werden dann so übernommen. Der momentane Achtbitmodus-Portinhalt wird dann auch den Steuersignalen zugeordnet, die völlig unkoordiniert auftreten. Richtiges Enable-Toggeln fehlt aber.)

 

[Oskar01]

weiterführende Literatur

Hallo @stmiko...,
und nun zur in der Fragestellung dieses Threads anzusprechenden C-Programmierung.
Man findet im "schlauen" Buch, das ich mir extra für das Verständnisproblemlösungsansinnen des Analog-Digital-Wandlers zugelegt habe, auf Seite 472 ff dazu folgendes:
Zitat:

"...Die C-Programme für die LCD-Initialisierung entsprechen den Assemblerprogrammen...."

"...Ohne Forward Referenzen ist darauf zu achten, daß nur auf Funktionen zugegriffen wird, die bereits vorher definiert wurden..." Zitat Ende.
Prof. Dipl-Ing Günter Schmitt, ISBN 978-3-486-58790-6 Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie
Programmierung in Assembler und C (die andere Ausgabe ....in Assembler und BASCOM)


noch Fragen, Euer Ehren?
Nein danke, Herr Franke...bitte, Frau Witte.

Mehr geht nicht, sonst bekomme ich mit an Sicherheit grenzender Wahrscheinlichkeit noch Urheberrechtsprobleme.


In diesem Sinne,
einen schönen Sonntag noch....
Euer Oskar01

(Tipp: Zwei Tage nach Bestellung bei amazon.de hatte ich das Buch, mit Expresszustellung Kostenpunkt ca. 40,- €.
Noch etwas:
Dieses Buch hat neben zahlloser Positivrezension auch gehörige negative Beurteilungen erhalten. Diese Beurteilungen zielten aber lediglich auf die ersten Auflagen ab. Tipp:
Da im Netz erhebliche Preisunterschiede bei verschiedenen Auflagen zu verzeichnen sind, unbedingt darauf achten, daß man die aktuelle Ausgabe bestellt. Die chaotisch anmutende "Unaufgeräumtheit" der ersten Auflagen wurde massiv bei den Folgeauflagen verbessert.
Allerdings gilt es auch da zu beachten, daß bei den Neuauflagen bestimmte Teile nun bei "zu gründlich" durchgeführter Revision komplett entfallen sind.
Die bei der letzten (4.) Auflage herausgefallenen Assemblerprogrammierbeispiele wurden mir allerdings dann doch noch freundlicherweise auf Anfrage beim Verlag als Links gemailt.

Hier wurde im Forum schon mal moniert, daß Portzuweisungen syntaxmäßig nicht stimmen.
Zum Beispiel PD4 oder so, statt P4, siehe auch hier....(Jetzt weiß ich wohl auch, woher dieser "Unsinn" stammt.-So etwas steht zum Beispiel in diesem "schlauen" Buch auf Seite 211, im Forumsthread wurde wohl Assembler mit C verwechselt.))