LCD_Ansteuerung_Initialisierung_4-Bit-Modus

Hallo,
nach Kauf eines 44780-er-Standard-LCD-Displays ergaben sich folgende "Glühbirn-im-Kopf-angeh"-Aha-Effekte:
Unbekannte Hardware:
Pinbelegung herausfinden. (z. B. waren Beleuchtungs-Pins nicht herausgeführt verdrahtet, das Poti zur Kontrast-Einstellung zwingend notwendig.)
Die Software-Beispiele im Net, von deren es doch eine Menge gibt, teils Bascom, leider sehr wenige in Assembler, die der hier verwendete ATMega8515 (STK500-er Board) auch versteht, sind nicht eins zu eins auch einsetzbar.
(...wäre auch zu schön...)

Dann der 4-Bit-Modus, über den in zahllosen Threads immer wieder dieselben Probs aufzutauchen scheinen:

Also:
Denkproblem numero eins:
Wenn ich ein Display initialisieren soll mit einer Bitfolge, die eine Parallelbusbreite von mindestens 8-Bit hat, dafür aber nur die vier obersten Strippen anschließe, wie soll man dann dreimal hintereinander Hex03 senden?


OK.
Denkproblem numero zwei:
Die RS- bzw. Enable- Impuls- Bitzuordnung auf dem(n) Port(s) erfolgt einmal per sbi dann wiederum per sbr Befehl.
In der Syntaxblibliothek (AVR-Studio4 - Help Menue Assemblerbefehle) findet man dazu,
daß einmal von Null aus gezählt wird, dann einmal von 1 aus
also kann z. B. eine .EQU RS=1 Anweisung in dem Definitionsheader eines selbsterstellten Progs nie richtig funktionieren. (dasselbe gälte auch für den Enable-Impuls, wenn der z. B. auf Bit Null gesetzt wurde.)


Dann gibt es ein weiteres Denkproblem:
Die RS-Setzung erfolgt einmal nach Null einmal nach Eins.
Das ist wohl abhängig davon, welcher Maskierungsbefehl vorher verwendet wurde:
Einmal wird mit andi gearbeitet, dann wieder mit ori.
Also, Bei Andi wird nach geraumer Zeit alles mehr oder weniger Null, bei Ori mehr oder weniger High, (kleiner Exkurs am Rande).
Dabei setzen die sbr bzw sbi Befehle, wenn ich die Syntaxbibliothek richtig verstanden habe einmal ein andi bzw. ori voraus, bzw. führen diese Operation intern selber aus.


Und jetzt kommt's:
Wenn ich im Vier-Bit-Modus arbeiten möchte muß ich ja die Vierergruppen (Nibbles) vertauschen.
OK.
Jetzt ist im "unteren" Nibble der RS- und der Enable-Impuls maskiert.
Wie soll man da noch nach jedem Nibble, den Enable-Impuls aktivieren, was ja auch oft vergessen wird, ohne wieder die Maske hier neu definieren zu müssen.
Die Timingbedinung kommt so niemals zustande, da der Enableimpuls ein "Transition-State"-Impuls ist, das heißt, er ist flankenorientiert. Dabei hat die steigede, wie auch fallende Flanke eine Bedeutung.
Einfach einen Hex-Wert-eingeben und alles mit einem Rutsch übergeben, geht nicht. Die Daten müssen vor dem Enable-Impuls stabil anliegen.



So, für heute erst einmal Schluß, werde weiter berichten.
Also
Cursor blinkt schon mal, mir HexC0 bekomme ich auch zwei Zeilen hin.

Nur, die Routinen laufen immer rund.

Und jede Menge Stack-Overflow- Fehlermeldungen.

Bis dann,
bleibe dran.

Gruß von Oskar.

Danke Dirk,
die Initialisierung mit dreimal Hex 03 soll ja das DDRAM für die AsciII-Charakters initialisieren, wie ich gelesen habe. Ob das überall wirklich nötig ist?
Offensichtlich.

Der Anschluß ist :
STK500 PortD
Bit 0 = Ena
Bit 1 = RS
Bit 4...7 Daten
RW auf Masse gelötet.
Und natürlich entsprechend an das LCD-Display.

Ich würde auch die Direktzugriffe auf die Ports für die ENA- und RS- Impulsgenerierung favorisieren (sbi... cbi). Vorher die Nibble-Tauschaktion durchführen.
(OK, ich brauche direkt hinter jedem Nibble einen Enableimpuls.)

Hier der zugrudeliegende Code von Andreas((c)andreas-s@web.de ) mit freundlicher Genehmigung.
lcd_data:
mov temp2, temp1 ; "Sicherungskopie" für
; die Übertragung des 2.Nibbles
swap temp1 ; Vertauschen
andi temp1, 0b00001111 ; oberes Nibble auf Null setzen
sbr temp1, 1<<4 ; entspricht 0b00010000 (Anm.1); (geändert auf obigen Ausgang und Wert beginnend bei 0 bzw. 1 je nach "sbi" oder "sbr" für Port 1 ; nochmal genaue Syntax nachgucken.... Anm. Oskar01)
out PORTD, temp1 ; ausgeben
rcall lcd_enable ; Enable-Routine aufrufen
; 2. Nibble, kein swap da es schon
; an der richtigen stelle ist
andi temp2, 0b00001111 ; obere Hälfte auf Null setzen
sbr temp2, 1<<4 ; entspricht 0b00010000
out PORTD, temp2 ; ausgeben
rcall lcd_enable ; Enable-Routine aufrufen
rcall delay50us ; Delay-Routine aufrufen
ret ; zurück zum Hauptprogramm

; sendet einen Befehl an das LCD
lcd_command: ; wie lcd_data, nur RS=0 (hier....." muß geguckt werden ob mit diesem Befehl auch das Bit auf Null, nicht versehentlich auf eins gesetzt wird..... Anm. Oskar01)
mov temp2, temp1
swap temp1
andi temp1, 0b00001111
out PORTD, temp1
rcall lcd_enable
andi temp2, 0b00001111
out PORTD, temp2
rcall lcd_enable
rcall delay50us
ret



Das Rotieren in der Initialisierung liegt daran, daß halt alle Routinen in ein File reingeschrieben wurden....zunächst ohne Hauptprogramm, aber mit der Einrichtung von Stack (LDI high (ramend), low(ramend)) etc.
So gibt es hier rcall Befehle für den Aufruf z.B. der Zeitschleifen (Impulsgenerierung), die alle mit ret abgeschlossen werden, so beginnt die Initialisierung immer von Neuem.
OK, das läßt sich ja leicht abändern.
Werde weiter berichten.
Gruß von Oskar01

Hallo,
habe ein wenig experimentiert, das Ergebnis im Word-Doc einkopiert.
Das Display zeigt mir auch manchmal den eingegebenen Charakter an, aber es kommen immer noch schwarze Balken und bei jedem Power-Off und -On des STK500-er mit dem so programmierten File, springt die Anzeige einen Schritt weiter nach rechts. Nehme an, das Display ist nun doch defekt, da ich am Anfang versehentlich mal die Anschlüsse von Plus und Minus vertauscht hatte, dabei eines der Chips sehr heiß geworden ist. Habe aber schon ein neues anderes Display, das muß ich noch ausprobieren.
Noch wichtig: Es wird eine separate 5V-Spannungsquelle für das Diaplay verwendet, nicht etwa die vom Port des STK500.

OK. Künstlerpech - soll vorkommen.

Was am Prog auffällt, ist, daß der "gordische Knoten" in der Vertauschung der Nibbles schon am Bus lag. Das vorliegende, aus dem Net kopierte ASM-File ging davon aus, daß die Low-Nibbles als 4-Bit-Modus verwendet werden, nicht die 4 oberen Datenleitungen des Displays, so kann es ja auch nicht funktionieren.
Habe das Prog nun umgeschrieben.
Auch müssen zwingend die anderen Setup-Einstellungen rein. Die variieren teilweise erheblich.
Leider ist bei etlichen Displays in der "Gebrauchsanweisung" nur vom 8-Bit-Modus die Rede und als Beispiel angegeben.

Bleibe dran....viel Spaß noch......

Euer Oskar01

Bugfixes

Hallo Dirk,
ok. Hatte das Programm in Word formatiert, dann zur Kontrolle nochmals im AVR-Studio aus Word2000 direkt in das ASM-Editorfenster geladen und angetestet, es hing direkt in der Einschaltverzoegerung, da das Label beim Tabulatorsetzen in Word irgendwie verrutscht war.
Jetzt ist mir auch, wie Du schon richtig bemerktest, aufgefallen, daß der sbr-Befehl (bzw. sbi-Befehl) natürlich stets auf das aktuelle Register gesetzt werden mußte. Er löscht sich nämlich auch wieder weg, ohne cbr (cbi) zu verwenden.
Anbei das gefixte File, das ich gerade hochladen wollte, Du warst aber schneller, alle Achtung!!!

Trotzdem frohe Pfingsten noch!!

Es grüßt, Oskar01

P.S.: Daß das "alte" Display wohl doch defekt ist, merke ich schon daran, daß sich nur bei abgezogenem Stecker zum STK500 PortB der Programmer ohne "failed" funktioniert. Also,
die Ports beim ATIMega8515 sind ja alle schon defaultmäßig definiert, Port A (Analog-Digitalwandler) Port B (serielle Schnittstelle etc.) Port C und D zusammen 16 Bit Port.
Auch hatte sich die Clockfrequenz des AVR-Studios aus unerfindlichen Gründen auf 14,4 Kilohertz statt die sonst üblichen 3,9.... MHz verstellt, worauf hin immer "ISP" Frequenz nicht 1/4 der Taktfrequenz-Meldung kam.
OK. Konnte manuell einfach abändern und mit "write" übernehmen. Dann ging Entering programming mode wieder fehlerfrei. Vielleicht ist das auch die Lösung der anderweitig hier im Forum beschriebenen Probs.


Leider funktioniert dier Initialisierung des "neuen" zweizeiligen, 16stelligen LCD auch nicht, weder im 8-Bit- noch im 4-Bit-Modus, obwohl ich genau die Initialisierungssequenz, die auf dem Datenblatt (PDF-File) von KS0066U-Controller angegeben ist als Flowchart, genommen habe.
Jetzt kommt noch nicht einmal mehr schwarze Balken, nur noch per Kontrastpoti einstellbare Kästchenhelligkeit, bzw. -schwärze.

Kennt jemand das ANAG VISION AV1621-er Display (KS0066 kompatibler Controller) (Conrad Bestellnummer 181645) und könnte hier weiterhelfen, wie man es korrekt initialisiert?


Noch etwas.
Beim Umprogrammieren auf vollen PortB (8-Bit) und RS- sowie Enable-Signal auf PortD, D1 und D0, fiel mir per Zufall noch beim Simulationsdurchlauf vorher auf, daß die Zeitschleifen nur gehen, wenn der Wert bei beiden Schleifen (ich meine im Prog das Label Verzoegerung_gross) auf $01 setze, setze ich den Wert der inneren Schleife auf $02, bleibt der Simulator dort hängen. Die Zeitschleifen sind ja ziemlich lang, würden im Simulationsdurchlauf wohl pro Mal eine halbe Stunde in Anspruch nehmen, setze ich die Auto-Step-Geschwindigkeit des Debuggers einmal voraus, deswegen habe ich sie automatisch immer abgeändert vor jedem Simulationstest und die "echten" Werte ausgeremt. Hinterher vor der Programmierung des ATMega8515 natürlich die richtigen Werte eingesetzt.


Jetzt habe ich auch noch in einem anderen Progrämmchen festgestellt, daß der ATMega an den Ports (LEDs) ganz was anderes anzeigt, als im Simulationsprogramm vorher ausprobiert.
Ich maskiere z.B. mit DDRB auf 4 Bit.
Im Simulator zeigt er mir die rotierenden Leuchtdioden in Vierergruppen.
Beim Test am Board wird tatsächlich, so wie es gewollt war, die 4 Bit ausgeblendet, es rotiert nur jeweils eine Leuchtdiode.
Hier habe ich noch ein bißchen rumgespielt, vor allem mit den Zeitschleifen. Scheint so, als ob die Lables Schleife1 und Schleife2 im LCDProg verdreht gelabelt sind.

OK.
Trotzdem kein Erfolg bei der Initialisierung der LCD.
Jetzt guck ich mir noch im Oszilloskop an, ob die Impulse auch tatsächlich da ankommen, wo sie hinsollen und wie sie aussehen.
Vielleicht gibt das ja Aufschluß darüber, was hier total nicht stimmt.
Leider keine Zeit heute mehr.
Werde weiter berichten.


Gruß von Oskar01

Teilerfolg...und vielleicht mehr

Hallo,
nun, im Net fand ich noch einen Post, bei dem jemand das Enable-Bit nicht berücksichtigt hatte. (Mikrocontroller-Net-Forum). Das Prog wurde hier nun zugrundegelegt und ist als erster Schritt zur erfolgreichen Initialisierung doch recht gut.
Da ich schon vermutete, daß Portzuordnungen nach Umlöten auf 8-Bit und softwaremäßig halt die Zeitschleifen zur Impulsdauerdefinition ziemlich "wurmstichig" zu sein schienen (Simulator blieb ja dort immer hängen), hier nun der Clou:
Es wird der cpi- und brlt-Befehl verwendet, sowie die Probleme mit den ret-Befehlen (Stack-Overflow-Meldungen im Simulationsprogramm) dadurch vermieden, daß vor jedem Recall-Verzögerungs-Label-Aufruf der Ladewert für den Zeitschleifenanfang angegeben werden muß.
Da ich keine Lust hatte, eine Unterscheidung zwischen kurzer und längerer Impulsdauer zu programmieren, habe ich die "kurze" Verzögerung einfach mehrfach hintereinandergesetzt.
OK. Ist ziemlich primitiv. Klappt aber:
Die Strings sind im KS0066U-kompatiblen Displaycontroller total anders.
Es entfällt der "Dreier-Satz" dreimal 03 Hex bzw. 30 Hex am Anfang vollständig, und man kann direkt "medias in res" gehen.
OK. Es fehlt noch die eigentliche Darstellung eines oder mehrerer Characters. Reicht aber auch so schon, um überhaupt was zu sehen. Vor allem ist es egal, ob ich nun das Displaynetzteil zuerst einschalte oder das vom STK500, die ja beide, wie gesagt "autonome" 5Volt Spannungsversorgung bekamen, um nicht eventuell die STK500- Powersupply/Onboard-Stabis zu "schießen".
Wichtig ist dabei noch, daß softwaremäßig die Pull-up-Widerstände an der MPU aktiviert werden.
So, dies als kleiner Erfahrungsbericht.
Jetzt macht es auch wieder mehr Spaß.....

Bis demnächst,

beste Grüße von Oskar01

P.S.: Wenn ich das KS0066U- Datenblatt richtig verstanden habe, ist der Vierbit-Modus nur mit eingeschränkten Features möglich, einige Änderungen werden von vorne herein nicht übernommen.
Darüber werde ich evtl. weiter berichten.

OK.
Es funktioniert. Habe in die "Schleife" jetzt noch T E X T _ geprogt.
(Entire Shift ist auf off) Also, zunächst Spannung an Display=> schwach Kästchen sichtbar, in oberer Zeile etwas stärker, dann Spannung an STK500
=> erst läuft etwa 10 Zeilen ein Kästchen mit blinkendem Cursor voran, Tempo 0,2 Sekunden pro Spalte, dann kommt der T E X T _ und das Display wird vollgeschrieben, erst obere Zeile, dann untere.
Drücke ich Reset am ATMega, bzw. schalte das STK500-Board aus,dann dauert es etwa 10 Sekunden, dann erscheinen stark kontrastierte Balken auf beiden Zeilen. Lasse ich Resettaster los, ist der Text plötzlich wieder da.
Habe ich zuerst den ATMega eingeschaltet, schalte dann erst die Anzeigeeinheit an, kommt entweder nichts, bzw. der Text, wenn die Ausschaltpause nicht länger als etwa 5 Sekunden war.
Und am Ende des Ausschaltvorganges erscheint so eine Art "Scannermuster", senkrechte Streifen wie mit "Europäischen Artikelcode" vergleichbar.

OK. Jetzt kommen die marginalen Feinheiten dran.

Werde gelegentlich weiter berichten.

Und weiter gehts...

Hallo,
ok.
Kleines Video vom Test downloadbar unter

http://www.kbra01.de/AV1621_B.MPG

Und noch einiges:

Bei Anklemmen des Uraltoszilloskops (echtes Zweistrahlgerät) konnte ich feststellen, daß die STK500-Taktfrequenz im Test so etwa 1 Zehntel der gewünschten Taktfrequenz ist. Das Mini- Video zeigt diesen Modus. (Alles im Schneckentempo.)

Dann wurde ein HCU 4-MHz-Billigst-Quarz eingesteckt und Jumper auf OSCSEL entsprechend gesetzt, siehe da, die Impulse kommen sauber - auf 4-MHZ- Takt bezogen - rüber. Siehe auch angehängtes Bildchen. Hätte eigentlich hier mehr Probs erwartet. Der ATMega8515 könnte also so nun extern eingesetzt werden ohne das EVA Board. Bingo.

Das wäre nun auch die Lösung für die komischen Werte in den Zeitschleifen bei der Simulation.
Irgendwie dachte ich zunächst, da spinnt die Zeitablenkung am Oszilloskop, aber gleich mehrere Potenzen niedriger, das kann doch wohl nicht wahr sein. Und so ungeübt im Umgang mit dem Philips PM 3231 bin ich ja wohl doch nicht.
OK. Das Gerät war jetzt fast 5 Jahre nicht in Betrieb und fristete ein Kellerdasein.
Das nur am Rande.

Jetzt kommts aber dicke:

OK. Ich höre schon die Bedenken, wieso ich bei der Videodemonstration nicht nun doch zumindest auch die Hintergrundbeleuchtung des Displays etwas höher eingestellt hätte.

Nun gut, habe auch Jumper richtig gelötet, auch der 150 Ohm Widerstand drin,
Doch- welch Überraschung, dort wo normalerweise die Beleuchtung sitzt, pfeift der Wind durch die Ritzen- guschsch emol=> Ist garnicht eingebaut das LED-Hintergrundbeleuchtungsmodul. Also, da haben sie mich aber richtig veräppelt.

So, schönen Feiertag noch....

Jetz kommen auch endlich die Vierbit-Ansteuerungs-Versuche als nächstes an die Reihe.
Darüber demnächst mehr.

Bestens Euer Oskar01

P.S.: Kleine, aber wichtige Korrektur in der Legende des Oszillogramms unten (Bild Impulse)
Die Nullinie Kanal 2 soll natürlich den High-Pegel repräsentieren, nicht 0 Volt.
Getriggert wurde übrigens mit Kanal 2 in "kalibrierter" Stellung der Zeitablenkung, negative Flankentriggerung. Den Anfang habe ich etwas in den sichtbaren Bereich reingezogen mit x-Shift, steht sonst außerhalb des sichbaren Bereiches. Man sieht dann den "Blip", den RS-Impuls zwischen cbi und sbi Befehl des nächsten einzulesenden Charakters. Auch sieht man in Kanal 1 noch schwach "Null"-Pegel durchrutschen. Das liegt daran, daß der Enable-Impuls ja Versatz hat je nach Charakter bzw. Befehlsfolge der dargestellten Endlosschleife, getriggert wird ja nicht auf Kanal 1, sonst verschwände dieses "Artefakt".

Und noch etwas zur getrennten Spannungsversorgung:
Ich konnte feststellen, daß die Leuchtdiode des Netzteils für das Display nach dessen Netztrennung trotzdem weiterleuchtet. Wie dieses?
Ganz einfach! Die Pull-up-Widerstände sind ja mit Vdd common verbunden, liegt nun "High"-Pegel an den Portausgängen des noch laufenden STK500-Boards mit dem ATMega8515, so fließt hier auch Strom "revers" in die Display-Spannungsversorgung. Eigentlich ein Unding, denn an irgendwelchen Eingängen sollte niemals eine Spannung höher als deren System-Vdd anliegen. Ebenso leuchtet die Power-LED am STK-Board ganz schwach im umgekehrten Falle.
Für den Testfall lasse ich es mal so gelten, in der Praxis wären solche "Unmöglichkeiten" durch den Einsatz von Optokopplern zu vermeiden. Für ausgedehntere fliegende Verdrahtungen würde ich auf jeden Fall eine galvanische Trennung vorsehen, vor allem dann, wenn für Steuerungs- und "Effektoren"-Spannungs/Stromversorgung ein und dasselbe Netzteil oder ein Akku verwendet wird, sonst kommt es bestimmt öfters zu unkontrollierten Betriebszuständen durch nicht rückwirkungsfreie Speisung.



Bei den Netzteilen kommt es unter Umständen zur Beschädigung der Serienregler-Powertransistoren, vor allem bei sog. Low-Drop-Reglern mit PNP-Transistoren, da diese eine Revers-Spannung nicht immer verkraften.
Für den oben beschriebenen Fall, daß Spannung am Ausgang (kurzzeitig) höher als die Spannung des (bereits entladenen) Ladeelkos am Eingang ist, sollte eine Schutzdiode zusätzlich vorgesehen werden, die im Normalfall in Sperrichtung betrieben wird, das Reglerverhalten also nicht beeinflußt. Im "Störungsfalle-Reversspannung" wird die Spannung auf Diodenflußspannung, ca. Minus 0,7 Volt sicher begrenzt, so daß die meistens in Darlingtonschaltung (2 x 0,7 Volt) arbeitenden Endtransistoren nicht beschädigt werden können. Der 10-Ohm-Widerstand kann auch entfallen, Diode direkt zwischen Ein- und Ausgang geklemmt werden. Des weiteren kann auch der Adjust-Eingang mit einer für im Bildchen gezeichneten Anwendungsfall aber nun wirklich nicht unbedingt nötigen Schutzdiode parallel zu R1 protectet werden, wie hier eingezeichnet. Das macht man aber deswegen gerne, weil der LM317-Regler im Gegensatz zu den 78XX-Festspannungsreglern seine Referenz/Regelspannungselektronik direkt auf den Pluspol am Ausgang bezieht, dafür keinen Extra-Pin - auf 0 Volt (Masse) zu beschalten- herausgeführt hat. Mit dieser Diode wird auch der Eingang des Operationsverstärkers geschützt (besonders für den Fall, daß man bis unter URef (1,25 Volt) auf Null Volt runterregeln will und dazu noch eine negative Hilfsspannung braucht). Übrigens hat der LM317 fast schon Eigenschaften eines Low-Drop-Reglers ohne deren Nachteile, ihm wird deswegen auch gerne den 78XX-Festspannungsreglern gegenüber der Vorzug gegeben.

Das STK500-EVA-Board arbeitet wohl deswegen auch mit diesem LM317 in der Powersupply-Section.

Siehe Bildchen LM317_Schutz.

Das nur ein kleiner off-topic Abstecher am Rande.

Verbesserungen

Hallo,
hier das geänderte Programm für den 8-Bit-Modus.
Zeitschleifen wurden (hoffentlich) etwas genauer berechnet
(Kommentare).
Daß ich tatsächlich auch in den zeitkritischeren "Entry Mode" komme, sah ich daran, daß, wenn dieser auf "entire display shift" gesetzt wurde, die Anzeige anfängt zu flimmeren, und der Cursor ständig zwischen Anfang Zeile 1 und Zeile 2 hin und herspringt.

Auch wurde die "Schleife" für die Textausgabe als "Programmende" beibehalten, später soll da der Sprung ins noch folgende Hauptprogramm erfolgen.
Wieso immer wieder kurzzeitig das RS-Bit low gesetzt wird, hat den Grund, daß ich hernach auch im "Hauptprogramm" noch gezielt einzelne Stellen des Display ansprechen möchte, dazu wieder in den Command- Mode springen muß, ohne völlig neu initialisieren zu müssen. Wollte mal sehen, ob die Timing-Bedingung für das Setzen und Löschen dieses Register-Select-Bits irgendwelche negativen Auswirkungen auf den jetzigen Programmablauf hätte.
Momentan sieht es so aus, daß der Cursor 5 Stellen springt und ein schwarzer Balken sichtbar wird, wird nicht der Sprung in die Schleife der Textausgabe beibehalten, also die Anzeige "hält" die eingegebenen Daten dann nicht, weil ja ganz am Ende wieder der Command-Mode aufgerufen wird. Eine Verkopplung scheint da intern vorzuliegen, das kriege ich aber bestimmt in den folgenden weiteren Experimenten sicher noch genauer heraus.
Die verschiedenen Displays scheinen da auch stärkere Exemplarstreuungen aufzuweisen. Was mir noch auffiel, ist, daß die Taktfrequenz nur in etwa die Hälfte betragen zu scheint, wie bei anderen Displays üblich. Also 270 Kilohertz anstelle von ca. 500 Kilohertz.


Auch Vierbit-Modus als "Baustelle" noch einkopiert.
Die ersten Strings müßten noch angepaßt werden im Sinne des Programmabschnittes "Datenübernahme",
Unten noch die entsprechende Doku des Herstellers.

Und noch eine kleine Verbesseung. Jetzt wir der Text erst dann dargestellt, wenn am STK500-Board die Taste "1" gedrückt wird. Die Initialisierungsroutine wird erst wieder nach Reset am Board ausgeführt und vom Display mit Sprung auf Anfangsposition und blinkendem Cursor quittiert. Wird erneut Taste eins gedrückt, erscheint wieder der Text.

Übrigens scheint sich im angehängten Datenblatt für den 4-Bit-Initialisierungsmodus eines KS0066U-basierten Displays ein kleiner aber fataler Druckfehler zwischen Display Clear und Entry Mode Set eingeschlichen zu haben. Es muß wohl richtiger heißen: Mindestwartezeit 1,53 Millisekunden statt 1,53 Mikrosekunden.

Gruß
Oskar01
P.S.: Und nun endlich das Prog für den Initialisierungstest im Vierbit-Modus.
Im Test fiel auf, daß, wenn wie hier zunächst noch die vier unteren Datenleitungen zum Display Kontakt mit dem MC-Port haben, am Anfang falsche Buchstaben kommen z. B. UB oder so. Diese Leitungen sollten auf definierten Pegel gesetzt werden, entweder dauernd High oder Low mit Hilfe von Abschlußwiderständen. Deswegen, weil es bei direkter Masse- bzw. +5V-Verbindung unter Umständen zur Zerstörung des Displays kommen kann, vor allem, wenn, wie oben schon erwähnt, die Eingänge bei abgeschalteter Spannungsversorgung am Display aber noch eingeschalteter Spannungsversorgung am STK500-Board untereinander eine Potenzialdifferenz haben könnten. Das verkraften diese keinesfalls.

Erst bei Betätigen des Resettasters kommen dann die richtigen Buchstaben.

Nachtrag vom 29. Juni 2008:
Das Programm wurde so geändert, daß die Enable/RS-Impulse nun "dupliziert" sowohl auf PORTD als auch PORTB liegen. Also, daran erkennt man, daß tatsächlich nur die oberen 4 Bits des Ausgabeports die Daten auf das Display transferieren. Ich wollte ja nicht herumlöten wieder. Die unteren 4 Bit werden tatsächlich wie "Don't-Care-Bits" ignoriert, hier liegen dann die Impulse Enable und RS. Nur am Anfang gib's damit Probleme, bevor man vom Acht-Bit-Modus in den Vier-Bit-Modus wechselt. Hier müssen diese Impulse rausgeremt bleiben. (Oder man muß löten.) Programmstart auch ohne Resettasterbetätigung.
Und jetzt wird klar, warum die unteren Bus-Bits des Displays im Vier-Bit-Modus zwingend auf "low" gelegt werden müssen, anders als oben von mir mal behauptet wurde, daß es nur auf einen definierten Pegel "high" oder "low" ankäme.
Es ist egal, ob logisch "null" durch Portausgänge oder Festverdrahtung erfolgt. Der String für den Übergang vom Acht- in den Vierbit-Modus besitzt ja 4 "Nullen" auf den unteren vier Bits. Das erleichtert die Sache erheblich.

Bastelversuchsergebnisse

Hallo,
hier noch die neuesten Bastelversuchsergebnisse als Hobby-Assembler-Prorgammiererlein:

Habe das 4-Bit-Initialisierungsprogramm aktualisiert.
Aufgabenstellung:
Sowohl nach Power-on "automatisches" Initialisieren, als auch nach manuellem Reset. Dann noch Function Set bzw. Shift-Funktionen manuell per Tastendruck abrufbar machen.
Wollte auch mal die sbi- und cbi- Befehle weglassen - soweit wie möglich - und alternativ mit ori den RS-Impuls maskieren, scheint ja zu funktionieren.

Auffällig ist noch, daß nach manuellem Reset sich das Display in den einzeiligen Modus verstellt, wenn nicht der Entry Mode Set etc. zweimal hintereinander gesendet wird, das ist also kein Fehler im Prog., sondern so gewollt.
Würde jetzt gerne weiter lernen, wie man das Ganze professioneller mit Interrupts realisieren könnte, da wage ich mich noch nicht ran. Zumindest ist ein zaghafter Versuch in Form eines .org 0x000 schon ansatzweise drin, wenn auch völlig überflüssig noch.

(Es bleibt nur noch das Problem der - ich sage mal vorlaut - "vorlaufenden Trabantenimpulse" zu lösen.
Also,
eine "Salve" von Enableimpulsen (nach Zeitschleifenmuster) brachte nichts, dann kommen mathematische Characters z. b. Pi und so.
Also, habe herumexperimentiert, der Text kommt immer hinterhergeklappert, nachdem der Kursor durch das ganze Display flitzte, habe noch nicht gezielt einen Charakter genau an die Cursoradresse plazieren können. Alle möglichen Timings ausprobiert, auch mit fast 500-ms-Verzögerungen oder anderen Taktfrequenzen bis hin zu Kilohertzen.
Kann auch sein, daß die interne Schiebetakterzeugung zur Ansteuerung der einzelnen Kolumnen nicht richtig funktioniert. Trotzdem läßt sich das Display dann noch zur Fließtext-Darstellung nach Terminalart verwenden. Möglich wäre auch, daß irgendwie die Einstellung so ist, daß der Controller des Displays im kaskadierbarem Modus für mehrere hintereinandergeschaltete Anzeigemodule läuft, wäre denkbar, ist laut Datenblatt nämlich durchaus vorgesehen.)

;********************************************************************
;* Initialisierungstest fuer LCD-Anzeige *
;* mit KS0066U-(ST7066)-kompatiblem Controllerchip *
;* 4-Bit-Modus *
;* Daten-/Steuerbits auf PORTB, Bit D4 bis D7 *
;* Enableimpuls auf PORTD, Bit D0; (bzw. PORTB, hier ausgeremt) *
;* RS auf PORTD, Bit D1; (bzw. PORTB, hier ausgeremt) *
;* R/WQuer auf Masse fest verdrahtet *
;* nach Power-On => blinkender Cursor obere Zeile links *
;* nach Druecken auf Resettaste =>blinkender Cusor obere Zeile links*
;* Tasten auf PORTA: *
;* Taste1 gedrueckt => Ausgabe "TEXT*" *
;* Taste2 gedrueckt => Ausgabe aller verfuegbaren Zeichen $00-$FF *
;* auch Kano-Zeichensatz, koreanisch, japanisch nacheinander *
;* Taste3 kurz gedrueckt und dann Taste 1 betaetigt=>Ausgabe "*TXET"*
;* spiegelverkehrt,bzw. bei Taste2 Liste in umgekehrter Reihenfolge *
;* Taste3 laenger gedrueckt => Ausgabe "@/321" von rechts nach links*
;* voriger Text wird von unten rechts ueberschrieben *
;* Taste4 => Cursor Position 1 und Reset Shift-Einstellung *
;* erst Resettaste gedrueckt, dann Taste3 => alternativer Text wird *
;* von unten rechts nach oben links spiegelverkehrt geschrieben *
;* *
;* CPU Takt 4 MHz (Rev.4-190708)*
;**********************************************************

Die verschiedenen Initialisierungsbeispiele noch ausprobiert, die mir zugänglich waren,
dazu ist zu sagen, daß einige die Original-Hardware-Power-On-Self-Reset-Initialisierung bloß wiederholen, und natürlich mit Display Off enden, damit das Display ausschalten, wobei dann natürlich nichts mehr zu sehen ist. Dann ist beim empfohlenen Datenblatt des Controllers ST7066 der Vierbit-Modus so dargestellt, daß der String für 4-Bit völlig fehlt, teilweise die Bit-Reihenfolge verdreht ist. Dann noch Originaldatenblatt-Beispiel, damit reagiert das Display überhaupt nicht. Also, es bleibt erst mal dabei. Das Problem mit den vorlaufenden Zeilen sollte angeblich mit dem Extra-String für Shift gelöst werden, nur, darauf reagiert das Display ebenfalls überhaupt nicht. Dann sollte in regelmäßigen Abständen auch der Register-Select kurz getoggelt werden, ist hier eingebaut, hat aber auch keine von mir zu bemerkenden Auswirkungen auf den Init, könnten also IMHO auch weggelassen werden.
Lediglich das oben erwähnte Umspringen in den einzeiligen Modus konnte mit dem Einfügen der dreimal 03Hex abgefangen werden.

Man lernt nie aus,
in diesem Sinne
schönen (kommenden) Sonntag noch
Oskar01

Trick 17

Hallo,
nach Anmailen des Supports des Displayherstellers ergibt sich die lapidare Feststellung, daß das Display wahrscheinlich defekt ist und umgetauscht werden sollte. OK, das sind wohl Produktionstoleranzen und Exemplarstreuungen.
Trotzdem geht es weiter im Text:

In Kombination zum Thread
http://www.avr-praxis.de/forum/showthread.php?t=144

noch ein kleines Trick-Programm,
das auch funktioniert und die "Macken" des Displays übertölpelt durch "Mehrfachsenden" ein und desselben Strings.
Neuerung:
Kombination Vier-Bit-Modus, der Z-Pointer, der die Texteingabenprogrammierung ganz erheblich erleichtet, diverse Tastenfunktionen und Wunsch-Reset-Initialisierung per Knopfdruck.
Viel Spaß!!

Ein schönes Rest-Wochenende noch...

Euer Oskar01

Neues Display 16x2

Hallo,
es wurmte mich derart, daß das Anag-Vision-Display erst bei mehreren Schleifendurchläufen etwas an Text von sich gab und das Problem mit dem vorlaufenden Cursor hatte, daß ich mich schließlich dazu durchrang, mir nochmals ein derartiges Display anderswo zu besorgen.
Fazit:
Das genauso aussehende Display, sogar mit Hintergrundbeleuchtung hat diese beschriebenen "Macken" nicht und läuft wunschgemäß.
Es heißt - ohne Reklame zu machen - Display Tech 162F arbeitet nun wiederum mit einem anderen Controller, nämlich KS0070B.

Ferner habe ich das Ding direkt im Vierbitmodus zum Laufen bekommen.
Die LCD-Routinen der oben angegebenen ausprobierten Initialisierungs-Proggis sind eins zu eins kompatibel. Jetzt hieß es nur noch, löten und in den Proggis die Portzuweisungen zu aktualisieren..
Tatsächlich Port B , Bit B0 RS, Bit B1, Enable, Daten auf Bit B4 bis B7 ....und noch die Versorgungsspannung direkt vom STK-Board abgegriffen, null Problemo.
Zur Verfeinerung bekam die V0-Display-Segment-Vorspannung noch einen 22 Mikrofarad-Kondensator verpaßt, die Versorgungsspannung wurde auf der Extra-Platine nochmals mit ebenfalls 22 Mikrofarad /16 Volt und parallel dazu einem 22 Nanofarad-Blockkondensator entkoppelt.

Dann hat diese endlose Geschichte doch noch ein gutes Ende genommen.......-))

Gruß von Oskar01

P.S.:
Das Kontrast-Einstell-Poti bekam noch einen 5,6 Kilooohm Reihenwiderstand Richtung +5 Volt.
Die Kontrastspannung ist sehr niedrig, fast Null Volt, das nur nebenbei.
Übrigens, die "don't care"-Eingänge - besser gesagt Ports- am LCD, also Bit 0 bis Bit 3 wurden nicht direkt auf Masse gelötet, sondern bekamen jeder Pin für sich noch einen 2,7 Kiloohm Widerstand gegen Masse. Damit mir diese Ports nicht bei einer eventuellen "Busy-Flag"-Abfrage in evtl. Testprogrammen die dann auf Ausgang geschaltetet sind, direkt satt kurzgeschlossen sind. Evtl. fatale Folgen dann.

Prog Warning message

Hallo,
also, bei dem "Groschengrab2" Proggi kommen beim Assemblieren 2 "warnings". Die beziehen sich auf "misalignmend ....padding zero byte". Dabei sind insgesamt nach Adam Riese drei Arrays drin, komischerweise aber nur 2 Misalignment-Meldungen. Mal hinter das Komma ein Leerzeichen, dann die Terminal-Null. Dann das Leerzeichen weggenommen, dann mal Integer-Format, dann mal Hex-Format. Komisch-. Könnte eine Spezialität des Assemblers sein, zu deutsch "Macke"? Oder habe ich da was übersehen?
Nichts desto trotz läßt sich das Prog assemblieren und flashen, läuft sogar einwandfrei, (muß jetzt sogar das Display Clear mitprogrammieren, da das neue Display jetzt die Daten auch "hält").

Wer hat eine Idee, oder kann jemand mal das Proggi bei sich assemblieren, ob dann diese Meldungen auch kommen? Dann wüßte ich, das es evtl. eine Spezialität des Assemblers sein könnte, zu deutsch "Macke"(?).



Danke schon mal für Eure Hilfe.


Gruß von Oskar01

leider keine Ahnung von Bascom

Hallo @R...
habe leider von Bascom keinerlei Ahnung.....

Markus???


Gruß
Oskar01