Guten Tag, ich habe mir einige Quellcode zur Initialisierung von LCDs durchgelesen. Dabei habe ich gesehen das manche vor der Initialisierung (powerupwait) gemäß http://www.mikrocontroller.net/articles/AVR-Tutorial:_LCD: lcd_init: ldi temp3,50 -------------------------------------------------> *)also an dieser Stelle powerupwait: rcall delay5ms dec temp3 brne powerupwait ldi temp1, 0b00000011 ; muss 3mal hintereinander gesendet out PORTD, temp1 ; werden zur Initialisierung rcall lcd_enable ; 1 rcall delay5ms rcall lcd_enable ; 2 rcall delay5ms rcall lcd_enable ; und 3! rcall delay5ms ldi temp1, 0b00000010 ; 4bit-Modus einstellen out PORTD, temp1 rcall lcd_enable rcall delay5ms ldi temp1, 0b00101000 ; 4Bit 2 Zeilen 5x8 rcall lcd_command ldi temp1, 0b00001100 ; Display ein Cursor aus kein Blinken rcall lcd_command ldi temp1, 0b00000100 ; inkrement / kein Scrollen rcall lcd_command ret ---------------------->*) lcd_init: push temp1 in temp1, LCD_DDR ori temp1, (1<<PIN_E) | (1<<PIN_RW) | (1<<PIN_RS) | 0x0F out LCD_DDR, temp1 ldi temp3,6 Ist es nötig diesen Teil noch einzufügen? Ich weiß garnicht, warum dieser nicht in AVR-Tutorial-LCDs gemacht wurde?? merci
BEN schrieb: > Ist es nötig diesen Teil noch einzufügen? Ich weiß garnicht, warum > dieser nicht in AVR-Tutorial-LCDs gemacht wurde?? Ich würde da mal im Dabla nachlesen.
BEN schrieb: > ---------------------->*) > lcd_init: > > push temp1 ; nach dem push muss irgendwo ein pop folgen?! > in temp1, LCD_DDR ;läd augenblicklichen Datenrichtungsregisterwert > ori temp1, (1<<PIN_E) | (1<<PIN_RW) | (1<<PIN_RS) | 0x0F ;das ori setzt die Bits passend für die Ports die Auisgänge sein sollen > out LCD_DDR, temp1 ;das Out schreibt den Wert dann ins Datenrichtungsregister > > ldi temp3,6 > > Ist es nötig diesen Teil noch einzufügen? Ich weiß garnicht, warum > dieser nicht in AVR-Tutorial-LCDs gemacht wurde?? Ja es ist nötig, zumindest diese drei Anweisungen in der Mitte, um die Ausgangsports entsprechend zu konfigurieren. Ich hab da malö Kommentare drangeschrieben.
BEN schrieb: > im Datenblatt des Mikrocontrollers steht nichts von Initialsierung > des > LCDs.... Warum auch? Das gehört ins LCD-Datenblatt.
BEN schrieb: > Ist es nötig diesen Teil noch einzufügen? Hängt wohl sehr vom LCD ab. Manche (--> Datenblatt) brauchen geörige Zeit um nach dem Anlegen von Spannung ins Leben zu kommen. Da ist jeder Controller schneller und kann das LCD schnell mal überfahren.
Das einzige Datenblatt was ich habe bzw. gefunden habe, ist dies hier: https://docs.google.com/viewer?url=http%3A%2F%2Fwww.mikrocontroller.net%2Fattachment%2F67814%2FTC1602A_09.pdf
https://www.google.de/search?q=LCD+TC1602A+pdf&ie=utf-8&oe=utf-8&gws_rd=cr&ei=n43hVY3vA4ifsAGT26nICw
BEN schrieb: > Das einzige Datenblatt was ich habe bzw. gefunden habe Google und so? :-) https://www.adafruit.com/datasheets/TC1602A-01T.pdf Und im Zweifel schaut man mal in das Datenblatt des auf dem LCD verbauten Controllers. Edit, der erste Link war doch noch besser: http://www.pollin.de/shop/downloads/D120422D.PDF
:
Bearbeitet durch User
BEN schrieb: > Ich benutze ein LCD TC1602A-09.. Wenn du partout nicht warten willst dann mach es ohne und probier es aus. Wenn es dann funktioniert ist "alles gut", und wenn es beim nächsten LCD (Bauteilestreuungen) nicht funktioniert dann wunderst du dich und denkst garantiert nicht an die Wartezeit.
BEN schrieb: > Ist es nötig diesen Teil noch einzufügen? Das hängt ganz von deinem Controller und dessen Taktfrequenz ab. Und auch ganz entscheidend von deiner Software. Erledigst Du noch unzählige andere Aufgaben bevor der erste Zugriff, oder die eigentliche Initialisierung des LCD stattfindet, so erübrigt sich ein extra Wartezyklus. Und nicht zuletzt hängt es von der Hardware des LCD ab. Liegen keine Daten vor, kann man den Weg gehen und initialisiert und testet das Display mit einem langen Wartezyklus und erniedrigt diesen bis ein Fehler auftritt. Tritt dieser auch ohne Wartezyklus nicht auf kann man ihn theoretisch einsparen. Ich empfehle auf die untere Schwelle eine Sicherheitsmarge von 25 - 30% Lass dich nicht davon abhalten in Assembler zu programmieren. Zum einen macht das bei Hardwareanbindungen durchaus Sinn. Wir machen das bei Entwicklungen in der Luftfahrt regelhaft so. Zum anderen Lernt man dabei sehr viel und versteht später beim Debuggen kritischer Passagen wo die Fehler liegen. Kollegen die Assembler nur vom Sagen und Hören kennen und immer nur in einer Hochsprache programmiert haben, sind wenn es zu Problemen mit dem Code kommt mit der Fehlersuche und dem Debuggen hoffnungslos überfordert.
:
Bearbeitet durch User
Ist das jetzt erstmal eine theoretische Betrachtung oder hast du dir mit µC und LCD schon was zusammengestöpselt? Fang' im Tutorial noch mal ganz oben an! Ziemlich am Anfang steht: "Die meisten Text-LCDs verwenden den Controller HD44780 oder einen kompatiblen (z. B. KS0070) und haben 14 oder 16 Pins." Das 'HD44780' ist dort als Link ausgeführt. Da kommst du zu einer Zusammenfassung vom Datenblatt. Dort steht beschrieben, wie und warum welche Bits gesendet werden müssen und wie lange der Controller zum verarbeiten braucht. Wenn's dann 'ernst wird' musst du dich entscheiden: 4-Bit-Modus oder 8-Bit-Modus. Jetzt suchst du dir raus, welche Pins als Steuerleitungen verwendet werden sollen. (Wie das angeschlossen wird, steht auch im Tutorial.) Die Datenleitungen sollten möglichst an einem Port hängen. Welcher Port das ist, ist egal. Aber du musst natürlich dann den Code entsprechend anpassen. Ich weiß, das ist nicht die Antwort auf deine Frage. Die lässt sich einfach mit 'Ja' beantworten. Nur warum? Gehe noch mal alles Schritt für Schritt durch und die Frage stellt sich eigentlich gar nicht, wenn man versucht zu verstehen, was da eigentlich passiert.
:
Bearbeitet durch User
Ralf G. schrieb: > "Die meisten Text-LCDs verwenden den Controller HD44780 oder einen > kompatiblen (z. B. KS0070) und haben 14 oder 16 Pins." BEN schrieb: > Ich benutze ein LCD TC1602A-09..
asdf schrieb: > BEN schrieb: >> Ich benutze ein LCD TC1602A-09.. Ja? Achso: Du hast Zweifel, ob die Steuereinheit HD44780-kompatibel ist? Da reicht 'ne kurze Recherche. Hätte ich mit dazuschreiben sollen. (Meine Kurzrecherche hat 'kompatibel' ergeben.)
Ralf G. schrieb: > asdf schrieb: >> BEN schrieb: >>> Ich benutze ein LCD TC1602A-09.. > > Ja? > Achso: Du hast Zweifel, ob die Steuereinheit HD44780-kompatibel ist? Da > reicht 'ne kurze Recherche. Hätte ich mit dazuschreiben sollen. (Meine > Kurzrecherche hat 'kompatibel' ergeben.) Okay, das wusste ich nicht. Dann bitte ich um Verzeihung für meinen Post!
asdf schrieb: > Dann bitte ich um Verzeihung für meinen > Post! Kannst wieder aufstehen! :-) Okay! PS: Ich hab's auch nur mal überflogen. Konnte aber auf die Schnelle keinen Unterschied feststellen.
:
Bearbeitet durch User
Läuft das LCD jetzt eigentlich? Ich habe in meinen alten Quellen für das LCD nachgeschaut, da habe ich immer die folgende Sequenz genutzt:
1 | // Initialisierung starten
|
2 | lcd_putini(0x3); |
3 | _delay_ms(5); |
4 | lcd_putini(0x3); |
5 | _delay_ms(1); |
6 | lcd_putini(0x3); |
7 | _delay_ms(1); |
8 | lcd_putini(0x2); |
9 | |
10 | // Ab jetzt ist das LCD im 4-Bit-Modus und es koennen ganze
|
11 | // Kommandos gesendet werden
|
12 | lcd_putcom(0x0C); |
13 | _delay_ms(5); |
14 | lcd_putcom(0x01); |
15 | _delay_ms(5); |
16 | lcd_putcom(0x06); |
Wobei ich mir nie die Mühe gemacht habe, das irgendwie abzukürzen, weil andere Teile der Hardware ohnehin immer länger zum starten brauchten als das LCD.
@Walter Ehe du dich zu sehr bemühst: BEN schrieb: > ich habe mir einige Quellcode zur Initialisierung von LCDs durchgelesen.
Bitte 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.