LCD Assembler

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.

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

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.

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.

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.)

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.

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.