AVR-Tutorial: LCD - Erweiterung lcd-routines.asm - Bitte um Feedback

... warum "verändert / verbessert" man etwas, wenn man keine Möglichkeit 
hat, seine Änderungen zu testen und veröffentlicht dieses dann auch noch 
ungetestet?

Assembly failed 8 errors 8 warnings

C:\Users\***\Documents\Test_1.asm(40): warning: Use of undefined or 
forward referenced symbol 'PORTD' in .equ/.set

C:\Users\***\Documents\Test_1.asm(50): error: Undefined symbol: PORTB

und so geht das weiter.

Das include file fürs Target in use fehlt auch.
(Target hier ausgetestet der AtMega8515, der gute alte...)
Die Busyabfrage ist vom Prinzip her richtig beim 4-Bit Modus.
Zweimal enable. Keine Ausgaberoutine nach dem zweiten enable.
Aber "Verkapselung" ist besser, wenn man mit I2C bzw. TWI noch arbeiten 
möchte.

ciao
gustav

Johannes F. schrieb:
> Die Datei „lcd-routines.asm“ vom Ende des AVR-Tutorial: LCD habe ich
> (hoffentlich) verbessert

Welche genau, diese 
https://www.mikrocontroller.net/wikifiles/9/96/Lcd-routines.asm ? Die 
enthält zu Beginn auch

1

 ;sendet ein Datenbyte an das LCD

2

lcd_data:

3

4

 ; sendet einen Befehl an das LCD

5

lcd_command:

Die sehe ich bei Dir nicht.

S. Landolt schrieb:
>> ... keine Möglichkeit habe, den Code zu testen ...
> Dann waren Sie voreilig.

Soweit ich das sehe, hat er den code noch nicht (im Tutorial) 
hochgeladen.

Karl B. schrieb:
> (Target hier ausgetestet der AtMega8515, der gute alte...)

Wobei das Tutorial eigentlich für den ATmega8 ist.

Ich sag mal, die Zeiten, sich noch mit Assembler abquälen zu müssen, 
sind schon einige Jahrzehnte vorbei.

Der AVR-Assembler ist obendrein eine Sackgasse, da er keine linkbaren 
Objekte erzeugt. D.h. man kann nicht später Assembler und C zusammen 
linken, sondern nur den Assemblercode komplett wegschmeißen.
Man müßte also schon alles in GNU-Assembler schreiben (ist im AVR-GCC 
enthalten).

Also die Zeiten, wo man ganze „Anwendungen“ in Assembler schreibt sind 
im Prinzip seit es C-Compiler gibt vorbei. Bei zeitkritischen 
Anwendungen sieht das auch heute noch anders aus.

Dabei ist es in der Regel allerdings Usus Assembler mit C zu mischen. 
Bei GCC oder XC8 am besten direkt initial, oder als library projekt 
(GNU) zum späteren Einbinden.  Dann muss man auch nicht seine Register 
retten unter der Voraussetzung dass man seinen Compiler kennt und 
versteht. Es gibt bei GCC z.B. eine Menge Register die beim Verfahren "C 
call’s Assembly" frei benutzt werden können. Es gibt für die 
unterschiedlichsten Platformen und Compiler in der Regel von allen 
Herstellern entsprechende Apnotes zum Thema „mixing c and assembly“

Wenn man den C-Compiler allerdings eines Besseren belehren möchte, dann 
sollte man auch ein guter Assemblerprogramierer sein. Ein guter 
Assemblerprogrammierer ist aber mindestens in der Lage seinen Code 
selbst zu testen. Wer das nicht kann bleibt aber tatsächlich besser bei 
C. LCD Displays sind im übrigen nicht Zeitkritisch. Hier macht es 
höchstens Sinn auf Codegröße zu optimieren. Das sieht allerdings anders 
aus.

Johannes F. schrieb:
> Dass man dann die Delay-Routinen anpassen muss

Da kann der AVR-GCC punkten. Da muß man nur die Konstante F_CPU in Hz 
definieren und alle Delays stimmen.
Dem Macro _delay_us() wird einfach die Zeit in µs als Argument 
übergeben.

Johannes F. schrieb:
> * lcd_data und lcd_command zu lcd_write zusammengefasst

Nun ja, es ist ein Tutorial, also für Anfänger. Als solches sollte der 
Code leicht verständlich sein. Die bisherigen getrennten Routinen für 
Data und Command finde ich da weit besser verständlich als deine Version 
mit den ganzen ifs und elses. Und so viel Flash-Speicher brauchen die 
beiden Routinen nun auch nicht.

Ein ganzes Register nur für das Data/Command Bit zu verschwenden halte 
ich auch für falsch. Register sind in Assembler immer Mangelware. Warum 
kein Flag wie das T-Flag nutzen?

Ich habe nun schon einige Routinen für LCDs in ASM geschrieben und 
benutze immer getrennte Data- und Command-Routinen da ich das 
übersichtlicher und einfacher empfinde. Und das bischen mehr an Flash 
fällt nicht ins Gewicht.

Johannes F. schrieb:
> Karl B. schrieb:
>> Aber "Verkapselung" ist besser, wenn man mit I2C bzw. TWI noch arbeiten
>> möchte.
>
> Das verstehe ich nicht, was meinst du mit Verkapselung?

Tja,
die Frage hatte ich gestern Abend schon insgeheim erwartet.
Dabei hatte ich Dir schon eine Eselsbrücke gebaut. Dachte, Du würdest 
auf den Köder anbeißen.
Offensichtlich sind Dir aber die Probleme bei der I2C LCD-Ansteuerung 
mit den PCFs Expansion Moduls noch nicht über den Weg gelaufen.
Aber ich möchte hier niemanden im Regen stehen lassen:
Wie willst Du die Steuersignale RS, R/Wquer, Enable übertragen, wenn 
keine "Drähte" dafür vorgesehen sind?
Eben.
Mit Verkapselung. Und diese bringt für "normale" Ansteuerung auch 
Denkanstöße, die man zur Ökonomisierung des Codes eventuell verwenden 
könnte.
Man nimmt den Vierbit-Modus und deklariert die 
"Hardware"-Steuersignal-Pins als Bits im 8-Bit-Byte, das auch 
sequenziell über TWI- oder I2C- (oder USI-) Routinen übertragen werden 
kann.
Anbei der kommentierte ausgetestete Codeschnipsel für ein 
SainSmart-4-Zeiler LCD mit dem Expansion Module.

ciao
gustav

Karl B. schrieb:
> Anbei der kommentierte ausgetestete Codeschnipsel für ein
> SainSmart-4-Zeiler LCD mit dem Expansion Module.

Und dann sind wir auch schon bei dem Problem, dass man in asm eben nicht 
vernünftig kapseln und abstrahieren kann. Sinnvoll wäre hier die 
Funktion des LCD-Controllers HD44780 von der Funktion des Interface 
PCF8547 und von der Funktion des Transports I2C zu trennen, wie man das 
etwa in C/C++ kann. Nur so entstehen wiederverwendbare Komponenten.

Wilhelm M. schrieb:
> Nur so entstehen wiederverwendbare Komponenten.

...und leichte Portierbarkeit von einem Target zum anderen.
Vom AtTiny4313 zum ATMega32U2 zum Beispiel bei Programmen, die vom 
Speicherbedarf und sonstigen Design her auf beiden µCs lauffähig wären.
Und auch sind, wenn man die Sache erst nachgearbeitet hat.
Bei C macht das ein halbwegs vernünftiger Compiler schon von sich aus, 
ohne dass man so weit runter auf die Befehlsebene gehen müsste

Generell gesprochen:
Für didaktische Zwecke ist das Beispiel der LCD-Initialisierung im 
Tutorial vielleicht ganz nützlich. Ich sehe da aber eigentlich keinen 
essenziellen Verbesserungsbedarf. Die Idee des TO in allen Ehren, aber 
mich hätte das als Absolut-Einsteiger erst einmal völlig aus der Spur 
gebracht, weil wieder weitere Konstrukte, so was Ähnliches wie Makros 
mit dem if und endif etc. pp. zusätzlich aufgedrückt werden.
Wenn ich schon mit ASM arbeite, dann so, dass die Befehle halbwegs 
nachvollzogen werden können. Sonst wird das sehr schnell ein 
unübersehbarer Wust an Spaghetticode. Ohne geremte Text-Kommentare geht 
es so wie so nicht.

ciao
gustav

Johannes F. schrieb:
> Es gibt schon einige Unschönheiten in dem Quelltext des Tutorials, die
> auch in Diskussion:AVR-Tutorial: LCD bereits vor vielen Jahren von
> anderen angesprochen wurden:

Hi,
gib 'mal den Link an, wo das zugehörige asm-File zu sehen ist.
Sonst reden wir womöglich aneinander vorbei.

Und: Entry Mode ist flexibler, als man denkt.
Siehe Video. Man kann auch dekrementieren. Das ist erst einmal so 
gesehen prinzipiell kein Fehler. Kommt drauf an, was man möchte.

Der Witz ist ja dabei gerade, dass nicht jedesmal explizit eine 
locate-Anweisung ausformuliert werden muss. Das übernimmt dann die im 
Entry Mode Set angestoßene, bereits implementierte Routine.

ciao
gustav

Hi,
auch wenn es schon Gegenstand der Diskussion war:
Nur einige Zeilen aus besagtem Tutorial-File rausgesucht:

in temp3, LCD_PORT
andi  temp3, 0x80
or    temp1, temp3

Überflüssiger Ballast, wenn man, wie in den meisten Fällen, ohne 
Busyflag-Abfrage arbeitet.
Und temp3 kann man sich schenken. Und wieso wird temp1 nicht auch 
gepushed/gepopt?

Ich drehe es um. Zuerst unteres Nibble ausblenden und oberes übergeben, 
da diese Reihenfolge vom LCD Controller so vorgegeben ist. Erst beim 
zweiten Durchgang wird geswappt. Warum Verwirrung stiften, indem man den 
Swap zuerst durchführt und dann wieder das andere Nibbel aus"und"et.
Ist doch anders viel anschaulicher und LCD-logisch nachvollziehbarer, es 
so zu machen, wie im von mir oben aufgezeigten Beispiel.
Im Klartext zum Mitschreiben nochmal:
LCD Controller verlangt zwingend im Vierbit-Modus z u e r s t das obere 
Nibble, dann das untere, und zwar in zwei Schritten, die jeweils mit 
einem Enable-Impuls quittiert werden müssen. Macht man das anders, dann 
sieht das vielleicht wie im Video aus.
Statt "Hallo" sieht man die Ascii Zeichen, wo in der Charactertabelle 
Zehner- und Einerstelle vertauscht sind. (Oder MSB und LSB vertauscht).

Man muss auch nicht die ganze Komplexität der unterschiedlichen Befehle 
zur Schau stellen. Ich fände es gerade für den Absolut-Anfänger besser, 
sich mit einer Handvoll gängiger Instructions zu bescheiden. Denn es 
funktioniert auch so. Gerade die vermeintlich unterschiedlichen 
Bit-Setz-Befehle bzw. Sprünge mit sbrc etc. pp. bieten hier bereits zur 
Genüge durchgekauten Diskussionsstoff.
Es gibt nämlich eine Reihe von "unechten", sondern Atmel AVR 
spezifischen Instructions. Die unter anderem auch auf verschiedenen 
Targets nicht alle zur Verfügung stehen müssen.
Also: Je einfacher, je weniger "Extrawürste", desto schneller wird der 
Anfänger ein Erfolgserlebnis verzeichnen können.

ciao
gustav

Hi,
verstehe die Absicht des TO schon, für unterschiedliche Konfigurationen 
ein
möglichst passendes, allgemeingültiges Programm zu kreieren.
Das findet schon meine Wertschätzung.

Einen etwas anderen Weg einzuschlagen, ist vielleicht auch nicht ganz 
falsch. Also, erst einmal herausfinden, wie die spezifische Pinbelegung, 
Portbelegung etc. ist. Dann das Programm entsprechend anpassen.
Dabei ein Grundgerüst verwenden. Ins Programm eingreifen muss man ja so 
oder so.

Hatte mal sowas gemacht:
Ist aber noch nicht überarbeitet. Ohne Gewähr.
Hompage war mir auf die Dauer zu teuer.
Aber ich möchte es niemandem vorenthalten.
Vieles ist vielleicht zu ausführlich.
Aber die Intention war ja, das LCD zum Laufen zu bringen, wenn
noch keinerlei Kenntnisse damit vorliegen.

Viel Spaß!

ciao
gustav

P.S:
Ziel speichern unter...und im Browser öffnen ...sonst kommt nur der 
Quellcode.

Hi,
gerade mit der Busyflag-Abfrage handelt man sich oft noch Probleme ein.
Weil Cursor undefiniert springt.
Der Fehler liegt meistens darin, dass der Adresscounter erst dann, 
nachdem das Busy-Flag resettet wurde, eine Adresse weitergeht.
Hier helfen noch ein paar "nops".
Also auch hier evtl. ebenso Feinjustierungsbedarf.

Zitat:
"...Note: — indicates no effect.
* After execution of the CGRAM/DDRAM data write or read instruction, the 
RAM address counter is incremented or decremented by 1. The RAM address 
counter is updated after the busy flag turns off. In Figure 10, t ADD is 
the time elapsed after the busy flag turns off until the address
counter is updated..."
/Zitat
Quelle: Hitachi HD44780 manual Seite 25


Apropos Zeitschleifen:
Mit den 16-Bittern fahre ich mittlerweile ganz gut.
Die Werte stehen ganz unten im angehängten asm-File. Natürlich auch 
abhängig von der Taktfrequenz.


ciao
gustav

Johannes F. schrieb:
> gibt es irgendeinen Grund, dort feste
> Wartezeiten einzuhalten?

Hi,
Power on reset macht der Displaycontroller so oder so.
Aber die Bedingung ist, dass die Anstiegszeit der angelegten 
Betriebsspannung (hier 5V) innerhalb einer nicht zu langen Zeitspanne 
stattfindet.
Deswegen sollte kein großer Elko direkt am Display angeschlossen sein.
[Ab etwa 2200 µF funktioniert bei mir im Test der Power-on-Self-Reset 
nicht mehr sauber.]
Daraus folgt, dass innerhalb dieser Self-Reset-Spanne der Controller 
selber seine Befehlsausführung und Zeit, die er dafür braucht, bestimmt.
Das ist mit jener Formulierung nämlich gemeint, dass in der Zeit keine 
Busyflag-Abfrage wirkt, ob man die nun softwaremäßig vorgesehen hat oder 
nicht. Die "Firmware" hat höhere Priorität. Und die angegebenen Waits 
sind eben Vorgabe, an der man sich orientieren sollte.
BTW: Die Unterschiede der sehr ähnlichen Controller KSxxx und so weiter 
beziehen sich im wesentlichen eben auf diese Zeiten.
Dann sollte beachtet werden, dass die praktische Situation so ist,
dass µC und Display meistens von derselben 5V-Spannungsquelle gespeist 
werden.
Der µC ist eher in der Lage Steuerimpulse zu senden, während das Display 
noch nicht bereit ist.
Deswegen will man keine Befehle in der Zeit haben. Auch solche nicht, 
die eine Busyflag-Abfrage machen.

ciao
gustav

Johannes F. schrieb:
> Was mich noch interessieren würde: Ich habe in meiner Version das
> Busy-Flag bereits in der Initialisierungsroutine abgefragt, also
> sämtliche Delays durch Busy-Abfrage ersetzt – auch beim Warten während
> der LCD-Controller-Initialisierung.

Das geht nur dann gut, wenn das LCD immer nur nach einem sauberen 
Power-On initialisiert wird.
Aber z.B. eine Resettaste, Brownout oder ein Watchdog kann das Reset 
auch inmitten eines LCD-Zugriffs auslösen.
Der LCD-Status ist dann unbekannt und kann 3 verschiedene Zustände 
haben:
1. LCD ist im 8-Bit Modus.
2. LCD ist im 4-Bit Modus, 1. Nibble
3. LCD ist im 4-Bit Modus, 2. Nibble

Hi,
Die Abfrage bleibt da hängen, da Busyflag während der Self-Init-Phase 
ständig auf "high" steht.

ciao
gustav

Hi,
soweit mir bekannt ist:
Die R/W Umschaltung Port von Eingang auf Ausgang geht schon nicht in der 
Init Phase mindestens 10 ms siehe Dabla.

ciao
gustav