Hallo
Ich verwende AVR Studio 4.18 und Win AVR. Weiters besitze ich das
RN-Control 1.4 Mega32 Board von
http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath=64&products_id=10
Habe mir die LCD Dateien von Peter Fleury downgeloadet und eingebunden.
lcd.h
lcd.c
test_lcd.c
Als Nächstes habe ich mein zweizeiliges Display an PORTB angeschlossen
und in der lcd.h für #define LCD_PORT PORTB eingetragen.
Laut der test_lcd.c Datei müsste irgendetwas am LCD-Display angezeigt
werden, tut es aber nicht.
Kann mir jemand sagen, welche Änderungen im Programm noch vorzunehmen
sind.
Danke für eure Hilfe
Thomas schrieb:
> 11 DB4 PD0 am AVR> 12 DB5 PD1 am AVR> 13 DB6 PD2 am AVR> 14 DB7 PD3 am AVR
dann solltest du vielleicht auch in der lcd.h PORTD eintragen...
Thomas schrieb:
> Display funktionierte schon mit dem Tutorial von microcontroler.net
Das ist der entscheidende Hinweis
> 5 RW GND
Das geht nicht.
Die Fleury Lib will RW bedienen. Du MUSST diesen Pin am µC anschliessen
und in die lcd.h eintragen.
Hallo....
ich verwende myavr Workpad Plus Demo und besitze Atmega8 MK1-Board.
Habe mir die LCD Dateien von Peter Fleury downgeloadet und eingebunden.
lcd.h
beim brennen bekomme ich Fehlermeldung:
Datei "globals.h" nicht gefunden...
muss man globals.h selber schreiben oder was gibt es da für
alternative???
Bin für jeden Tip Dankbar
Lieben Gruß TEVA
Hallo.Hab da ein ähnliches Problem. Ich hab keinen Pin mehr für RW frei.
Lässt sich das irgenwie umgehen ? Einfach für RW Port = PORTE beim Mega
8 reinschreiben geht nicht. Da meckert der Compiler. Ich kenn mich da
noch nicht so aus...
Das hast du richtig verstanden.
Allerdings war Peter schlau genug, das auselesen des Busy Flags in einer
einzigen Funktion zu konzentrieren.
Wenn du daher in dieser Funktion das Auslesen ganz einfach durch einen
delay ersetzt, erfolgt kein Lesezugriff mehr und die Lib funktioniert.
(Die 'Vom LCD auslesen' Funktion geht klarerweise auch nicht. Aber das
sollte logisch sein)
Hallo Leute,
Wenn du daher in dieser Funktion das Auslesen ganz einfach durch einen
delay ersetzt, erfolgt kein Lesezugriff mehr und die Lib funktioniert.
Wie genau sieht die Lib dann aus ?
Ich hab´s jetzt herausgefunden. :
in der LCD.C die Codezeilen :
static uint8_t lcd_waitbusy(void)
{
register uint8_t c;
/* wait until busy flag is cleared */
while ( (c=lcd_read(0)) & (1<<LCD_BUSY)) {}
/* the address counter is updated 4us after the busy flag is cleared
*/
delay(2);
/* now read the address counter */
return (lcd_read(0)); // return address counter
}/* lcd_waitbusy */
in :
static uint8_t lcd_waitbusy(void)
{
delay(1000);
return 0;
}
ändern. Dann kommt zwar noch eine Warnung das irgendeine andere Funktion
nicht genutzt wird, aber das Display funktioniert..
Hab gelesen das die Funktion den Befehl /n beeinflusst. Das funktioniert
dann wohl nicht mehr richtig. Für meine Zwecke aber belanglos.
Robert P schrieb:> Ich hab´s jetzt herausgefunden. :> static uint8_t lcd_waitbusy(void)>> {
...
> return (lcd_read(0)); // return address counter>> }/* lcd_waitbusy */
ändern zu
> static uint8_t lcd_waitbusy(void)> {> delay(1000);> return 0;> }> Dann kommt zwar noch eine Warnung das irgendeine andere Funktion> nicht genutzt wird, aber das Display funktioniert..>> Hab gelesen das die Funktion den Befehl /n beeinflusst. Das funktioniert> dann wohl nicht mehr richtig. Für meine Zwecke aber belanglos.
Ganz allgemein funktioniert nach dieser Änderung der automatische
Wechsel auf die nächste Displayzeile - bei einzeiligen Displays der
Sprung zum Anfang der Zeile - beim Erreichen des Zeilenendes nicht mehr.
Ob es das wert ist?
Die Fleury-LCD-Lib ist übrigens an ein paar Stellen subtil kaputt. Das
Timing ist grenzwertig, was bei manchen Displays zu Kauderwelsch führt.
Vor allem, wenn man Strings mit "\n" oder über mehrere Zeilen ausgibt.
Hier ist ein Diff meiner Änderungen:
Robert P schrieb:> static uint8_t lcd_waitbusy(void)> {> delay(1000);> return 0;> }
Was bedeutet die 1000?
Sind das 1000 Jahre oder was?
Besser nimmt man die delay.h, dann kann man Zeiten (µs, ms) angeben.
1000µs sind natürlich viel zu viel, das bremst nur unnötig aus. Die
meisten Funktionen brauchen nur etwa 50µs.
Bei den langsamen Funktionen (Clear, Home) fügt man dann zusätzlich
Delays (2ms) ein. Oder am besten benutzt man sie erst garnicht. Clear
bewirkt nämlich sichbares Flackern.
Peter
Peter Dannegger schrieb:> Robert P schrieb:>> static uint8_t lcd_waitbusy(void)>> {>> delay(1000);>> return 0;>> }>> Was bedeutet die 1000?> Sind das 1000 Jahre oder was?
delay() ist ein Makro in lcd.c, so richtig mit Inline-Assembler. Peter
F. wickelt das ganze Timing mit dieser Funktion ab. Das Argument ist in
µs.
> 1000µs sind natürlich viel zu viel, das bremst nur unnötig aus. Die> meisten Funktionen brauchen nur etwa 50µs.> Bei den langsamen Funktionen (Clear, Home) fügt man dann zusätzlich> Delays (2ms) ein.
Das ist aber nur die zweitbeste Lösung und mit den ganzen Sonderlocken
auch häßlich. Man muß das Timing pessimistisch machen, sonst
funktioniert es u.U. mit Exoten nicht. Dadurch wartet man fast immer
länger als nötig.
Viel besser ist es, wenn man noch ein Pin freimacht für RW. Oder man
nimmt gleich ein LCD mit serieller Schnittstelle.
XL
Axel Schwenke schrieb:> Man muß das Timing pessimistisch machen, sonst> funktioniert es u.U. mit Exoten nicht.
Kann ich nicht bestätigen.
In den Foren sind es nie Timingprobleme.
Die üblichen Probleme sind:
- Programmfehler
- falsche Initialisierung
- falscher Anschluß
- falsche F_CPU Angabe
Ich hatte auch einmal vergessen, den RW-Pin anzuschließen.
Axel Schwenke schrieb:> Viel besser ist es, wenn man noch ein Pin freimacht für RW.
Noch besser ist ein Timerinterrupt, dann muß man nie warten, auch nicht
auf das Busy-Bit.
Meistens sind mir aber die <1% CPU-Last für das LCD mit 50µs Delay total
schnuppe.
Peter
Peter Dannegger schrieb:> Axel Schwenke schrieb:>> Man muß das Timing pessimistisch machen, sonst>> funktioniert es u.U. mit Exoten nicht.>> Kann ich nicht bestätigen.> In den Foren sind es nie Timingprobleme.
Naja, da ist kein Widerspruch. Man macht das Timing ja von vornherein
pessimistisch, weil man keine Timingprobleme kriegen will.
Andererseits habe ich schon beim ersten veröffentlichten Projekt
Rückmeldungen bekommen, daß Displays Mist anzeigen. Am Ende lief es
darauf hinaus, daß Peter F. nur 2µs wartet und dann den Adreßzähler
ausliest. Darüber aber einen Kommentar stehen hat, daß das bis 4µs
dauern kann :(
Oder daß er E-Pulse mit 4 Takten Länge verwendet, was nur bis 8MHz
Controller-Takt in der Spezifikation bleibt.
>> Viel besser ist es, wenn man noch ein Pin freimacht für RW.>> Noch besser ist ein Timerinterrupt, dann muß man nie warten, auch nicht> auf das Busy-Bit.
Ich sehe nicht, wie dir ein Interrupt hier weiterhilft. Wenn du einen
Befehl an das LCD schicken willst, dann muß der vorherige fertig sein.
Darauf mußt du notfalls warten.
Was man korrekterweise macht, ist nicht nach jedem Befehl zu warten,
bis der fertig ist. Sondern vor jedem Befehl zu checken ob der
vorherige fertig ist. Wenn man aus laufendem Code heraus immer mal ein
Zeichen an das LCD schickt, muß man so u.U. niemals warten. Beim
Kopieren eines Buffers auf das LCD bringts natürlich nichts.
Bei einem LCD mit 50µs Ausführungszeit ist das natürlich ziemlich
akademisch. Aber wenn es z.B. ein UART mit 9600Bd ist, will man die
pessimal 1ms nur dann warten, wenn es wirklich nötig ist.
XL
Axel Schwenke schrieb:> Ich sehe nicht, wie dir ein Interrupt hier weiterhilft.
Ganz einfach, der Timerinterrupt (z.B. 1ms) kommt nicht schneller als
50µs und somit muß nicht gewartet werden. Er kann immer das nächste Byte
ausgeben.
Das Main schreibt immer nur in den Displaypuffer und wartet daher auch
nirgends. Das geht sogar extrem schneller als direkt zum LCD.
Der Displaypuffer muß so groß sein, wie die Zeichenanzahl des LCD. Der
RAM-Verbrauch ist also höher als ohne Interrupt.
Beitrag "Formatierte Zahlenausgabe in C"
Peter
Axel Schwenke schrieb:> Am Ende lief es> darauf hinaus, daß Peter F. nur 2µs wartet und dann den Adreßzähler> ausliest. Darüber aber einen Kommentar stehen hat, daß das bis 4µs> dauern kann :(> Oder daß er E-Pulse mit 4 Takten Länge verwendet, was nur bis 8MHz> Controller-Takt in der Spezifikation bleibt.
Ja, was soll man davon halten.
Das absichliche Verletzen der Spezifikation zählt für mich nicht als
Timingfehler, sondern als Programmierfehler.
Peter
Peter Dannegger schrieb:> Axel Schwenke schrieb:>> Ich sehe nicht, wie dir ein Interrupt hier weiterhilft.>> Ganz einfach, der Timerinterrupt (z.B. 1ms) kommt nicht schneller als> 50µs und somit muß nicht gewartet werden.
...
> Das Main schreibt immer nur in den Displaypuffer und wartet daher auch> nirgends. Das geht sogar extrem schneller als direkt zum LCD.
Ach so. Ein FIFO-Buffer zwischen Display und Code. Dann sag das doch.
Der Interrupt muß übrigens keineswegs langsam sein (wenn man das
Busy-Flag auslesen kann). Pseudocode im Interrupt:
Axel Schwenke schrieb:> Ach so. Ein FIFO-Buffer zwischen Display und Code.
Nein, kein FIFO.
Das Main schreibt die Zeichen immer an die Stelle im Puffer, wo es im
LCD angezeigt werden soll. Und der Interrupt fügt die Zeilenwechsel
automatisch ein. Ein 4*20 LCD braucht also 80 Byte Puffer.
Axel Schwenke schrieb:> Der Interrupt muß übrigens keineswegs langsam sein
Dann würde unnötig oft auf das LCD ausgegeben. 1ms scheint mir ein
optimaler Wert zu sein. Schnell genug, damit man auch Zeichen blinken
lassen kann (z.B. bei Eingaben).
Peter
Peter Dannegger schrieb:> kein FIFO.
Schon wieder ein Mißverständnis. Irgendwie hakelt unsere Kommunikation
:)
> Das Main schreibt die Zeichen immer an die Stelle im Puffer, wo es im> LCD angezeigt werden soll. Und der Interrupt fügt die Zeilenwechsel> automatisch ein. Ein 4*20 LCD braucht also 80 Byte Puffer.
Ach so, dann also ein Frame Buffer. Ist das für ein Textmode Display
nicht ein kleines bisschen übertrieben? Zumal du ja auch einen völlig
unveränderten Buffer immer wieder zyklisch in den Frame Buffer des LCD
kopierst...
> Axel Schwenke schrieb:>> Der Interrupt muß übrigens keineswegs langsam sein>> Dann würde unnötig oft auf das LCD ausgegeben.
Klar, wenn man das als Frame Buffer organisiert. Wenn man einfach nur
ein FIFO macht, dann ist das egal. Sobald der leer ist, passiert nichts
mehr.
XL
Axel Schwenke schrieb:> Ach so, dann also ein Frame Buffer. Ist das für ein Textmode Display> nicht ein kleines bisschen übertrieben? Zumal du ja auch einen völlig> unveränderten Buffer immer wieder zyklisch in den Frame Buffer des LCD> kopierst...
Genau darum gehst.
Diesen zyklischen Refresh kannst du mit einem Interrupt machen, der
immer nur 1 Zeichen updated. Kostet dir so gut wie nichts, ist schnell
genug und du bist die Wartezeiten im Ausgabecode sofort los.
Hinzukommt, dass dadurch die LCD-Ausgaben automatisch reentrant werden,
mann kann damit also auch zb in einer anderen ISR auch mal was aufs LCD
malen, ohne befürchten zu müssen, dass da technisch was durcheinander
kommt.
>> Dann würde unnötig oft auf das LCD ausgegeben.
Im Prinzip richtig. In der Praxis bei den üblichen Grössen der Text-LCD
irrelevant. Ist halt einfach eine Sache mehr, die in der meistens
sowieso bereits vorhandenen Timer-ISR für Basisdinge mitgemacht wird.
Axel Schwenke schrieb:> Ach so, dann also ein Frame Buffer. Ist das für ein Textmode Display> nicht ein kleines bisschen übertrieben?
Nein, da man sich die ganze Warterei spart (wenn man das Busy-Flag nicht
benutzt), weil das "warten" immer zwischen zwei Timer Interrupts ist
Das wiederholte schreiben kriegt man mit ein bisschen Zusatzaufwand weg,
allerdings ist das nicht wirklich von Vorteil.
Dann kann man das noch geschickt mit der Tastaturabfrage (-entprellung)
koppeln und so Leitungen sparen....
Von einer Busy-Flag Abfrage im Interrupt halte ich gar nichts, weil man
dann ja den Interrupt auf "unbestimmte" Zeit blockiert.
Bernhard M. schrieb:> Axel Schwenke schrieb:>> Ach so, dann also ein Frame Buffer. Ist das für ein Textmode Display>> nicht ein kleines bisschen übertrieben?>> Nein, da man sich die ganze Warterei spart (wenn man das Busy-Flag nicht> benutzt), weil das "warten" immer zwischen zwei Timer Interrupts ist
Ich hab das ehrlich gesagt noch nie als Problem empfunden (halte aber
auf der anderen Seite nichts vom Pins sparen und schließe meine LCD
immer mit RW an). Falls überhaupt, würde ich einen FIFO implementieren.
> Von einer Busy-Flag Abfrage im Interrupt halte ich gar nichts, weil man> dann ja den Interrupt auf "unbestimmte" Zeit blockiert.
Nur wenn man sich dumm anstellt. Man soll ja nicht im Interrupthandler
warten, bis BUSY wieder weg ist. Man prüft nur einmal ob es gesetzt ist
(und das auch nur, wenn es was auszugeben gibt). Und wenn BUSY gesetzt
ist, gibt man in diesem Interrupt halt nix aus, sondern beendet die ISR.
Der nächste Interrupt kommt bestimmt!
Was ich als Nachteil dieser Frame Buffer Methode ansehe, ist daß man
sich jeglicher Möglichkeiten des Displays beraubt. Oder das zumindest
deutlich verkompliziert, weil man Schreibzugriffe aufs Display nur mit
gesperrtem Interrupt machen kann. Also Scherze wie Blink-Cursor
einschalten (wenn man auf Eingabe wartet) oder benutzerdefinierte
Zeichen ändern (sehr nett: animierte Zeichen). Oder die Möglichkeiten
die sich durch das Verschieben des Display-Framebuffers ergeben.
Versteh mich nicht falsch: ich will die Idee nicht schlechtreden. Sie
löst halt nur kein Problem, das ich je gehabt hätte. Und für das hier
ursprünglich diskutierte "ich hab nicht genug Pins und kann deswegen
BUSY nicht auslesen" ist sie die berühmte Kanone zum Spatzen abschießen.
XL
Axel Schwenke schrieb:> Falls überhaupt, würde ich einen FIFO implementieren.
Das bring garnichts, sondern macht nur zusätzliche Probleme. Was machst
Du, wenn der FIFO voll ist?
Der Displaypuffer überschreibt sich einfach immer mit dem aktuellsten
Text. Der FIFO müßte ihn aber wegschmeißen oder doch wieder warten.
Axel Schwenke schrieb:> Also Scherze wie Blink-Cursor> einschalten (wenn man auf Eingabe wartet)
Gehen damit prima bei 1ms. Es soll ja blinken und nicht nervös flackern.
Axel Schwenke schrieb:> ich will die Idee nicht schlechtreden. Sie> löst halt nur kein Problem, das ich je gehabt hätte.
Ist daher auch eher eine Designstudie von mir. In Spezialfällen kann es
nötig sein, die Mainloop sehr schnell zu durchlaufen, z.B. für
Regelungen. Und dann könnte auch die Ausgabe mit Busy-Test zu langsam
sein.
Für die meisten Anwendungen ist die 50µs Delay LCD schnell genug.
Der Busy-Test kann ja auch nicht erheblich schneller sein. Er wird
vielleicht die Wartezeit auf 60% reduzieren.
Die Maximalzeiten werden etwa den tatsächlichen Zeiten des
LCD-Controllers mit etwas Sicherheitsaufschlag entsprechen.
Peter
Axel Schwenke schrieb:> Was ich als Nachteil dieser Frame Buffer Methode ansehe, ist daß man> sich jeglicher Möglichkeiten des Displays beraubt.> Oder das zumindest> deutlich verkompliziert, weil man Schreibzugriffe aufs Display nur mit> gesperrtem Interrupt machen kann.
Ist jetzt aber auch nicht so das große Problem.
> Also Scherze wie Blink-Cursor> einschalten (wenn man auf Eingabe wartet)
Na ja. Kann aber auch der nächste Interrupt mit machen.
> oder benutzerdefinierte> Zeichen ändern (sehr nett: animierte Zeichen).> Oder die Möglichkeiten> die sich durch das Verschieben des Display-Framebuffers ergeben.
Das wollte ich immer schon mal fragen.
Jetzt abgesehen vom 'Effekt' "komplette Anzeige scrollt herein", den man
mit dem Framebuffer ebenfalls ziemlich banal erzeugen kann, kennt jemand
irgendeinen sinnvollen Einsatz für dieses Feature?
Der größte Nachteil ist für mich: Es kostet Speicher. Was ich dafür
kriege: ich kann immer und überall Ausgaben machen. Ich muss nur darauf
auspassen, dass ich nicht übereinanderschreiben, aber abgesehen davon,
kann ich alles jederzeit überall ausgeben. Und sei es nur eine
Statusmeldung in einer ISR.
Peter Dannegger schrieb:> Axel Schwenke schrieb:>> Falls überhaupt, würde ich einen FIFO implementieren.>> Das bring garnichts, sondern macht nur zusätzliche Probleme. Was machst> Du, wenn der FIFO voll ist?
Warten :)
Man muß die FIFO-Größe schon auf das restliche Programm abstimmen. Aber
klar, aus einer zeitkritischen ISR würde ich trotzdem nicht aufs Display
pinseln.
>> Also Scherze wie Blink-Cursor>> einschalten (wenn man auf Eingabe wartet)>> Gehen damit prima bei 1ms. Es soll ja blinken und nicht nervös flackern.
Aber du mußt dich drum kümmern. Das Display kann das auch ganz
alleine.
> Ist daher auch eher eine Designstudie von mir. In Spezialfällen kann es> nötig sein, die Mainloop sehr schnell zu durchlaufen, z.B. für> Regelungen. Und dann könnte auch die Ausgabe mit Busy-Test zu langsam> sein.
Das Display selber wird ja auch gescannt. Und normalerweise kann man es
deutlich schneller beschreiben als es die Zeichen auch anzeigt. Wenn es
100Hz Refreshrate hat, kann man 10ms/50µs = 200 Zeichen ausgeben. Ein
16x4 Display also gut dreimal überschreiben.
> Für die meisten Anwendungen ist die 50µs Delay LCD schnell genug.> Der Busy-Test kann ja auch nicht erheblich schneller sein. Er wird> vielleicht die Wartezeit auf 60% reduzieren.
Man weiß halt nicht, wie schnell das gerade angeschlossene Display ist.
Der HD44780 verwendet einen externen Widerling in Verbindung mit
integrierten Kapazitäten. Die exakte Frequenz wird also von Exemplar,
Temperatur und Betriebsspannung abhängen. Das Datenblatt sagt +/-30%.
Und explizit verschiedene Widerstände (91K vs. 75K) für verschiedene
Betriebsspannungen (5V vs. 3V). Die Ausführungszeiten dürften also
Nominalwert + 30% + Sicherheitszuschlag sein. Weniger als die Hälfte
wäre also möglich.
Ach und weil ich gerade das Datenblatt sehe: Framerate ist f_clk 400
duty. Mit nominal 270kHz also 84Hz (duty 8/16) oder 61Hz (duty 11).
XL
Karl Heinz Buchegger schrieb:> Axel Schwenke schrieb:>> Also Scherze wie Blink-Cursor>> einschalten (wenn man auf Eingabe wartet)>> Na ja. Kann aber auch der nächste Interrupt mit machen.
Dazu muß man das aber auch vorgesehen haben. Wenn ich PeDa richtig
verstanden habe, ist das ein reiner Character Frame Buffer. Der
Interrupt gibt also nur Zeichen aus und setzt evtl. den Adresszeiger
neu, um auf die nächste Zeile zu kommen.
Wenn man Befehle an das LCD schicken will, kann man die ja nicht einfach
in den Framebuffer pinseln.
>> Möglichkeiten>> die sich durch das Verschieben des Display-Framebuffers ergeben.>> Das wollte ich immer schon mal fragen.> Jetzt abgesehen vom 'Effekt' "komplette Anzeige scrollt herein", den man> mit dem Framebuffer ebenfalls ziemlich banal erzeugen kann, kennt jemand> irgendeinen sinnvollen Einsatz für dieses Feature?
Laufschriften mit minimalem Aufwand. Oder Eingabefelder länger als das
Display. Ist aber in der Tat mehr ein Gimmick als ein hartes Feature.
XL
Axel Schwenke schrieb:> Wenn ich PeDa richtig> verstanden habe, ist das ein reiner Character Frame Buffer.
Ja.
Andere Funktionen benutze ich nicht.
Das Blinken mache ich in Software, d.h. alle 250ms Wechsel zwischen
Zeichen und Blanks ausgeben.
Blinken nur einiger Zeichen (z.B. 4-stellige Zahl eingeben) kann das LCD
ja nicht.
Und Laufschrift mache ich auch in SW.
Wenn ich das richtig erinnere, geht die Laufschriftfunktion des LCD
nicht richtig. Da gibts beim Zeilenumbruch Probleme und am Display-RAM
Ende.
Und Laufschrift in einer Zeile, stehender Text in den anderen, geht
garnicht.
Peter
Axel Schwenke schrieb:> Karl Heinz Buchegger schrieb:>> Axel Schwenke schrieb:>>>> Also Scherze wie Blink-Cursor>>> einschalten (wenn man auf Eingabe wartet)>>>> Na ja. Kann aber auch der nächste Interrupt mit machen.>> Dazu muß man das aber auch vorgesehen haben. Wenn ich PeDa richtig> verstanden habe, ist das ein reiner Character Frame Buffer. Der> Interrupt gibt also nur Zeichen aus und setzt evtl. den Adresszeiger> neu, um auf die nächste Zeile zu kommen.
Sieh das Ganze als 'System' an. Was immer dir notwendig erscheint,
kannst du reinprogrammieren.
>> Das wollte ich immer schon mal fragen.>> Jetzt abgesehen vom 'Effekt' "komplette Anzeige scrollt herein", den man>> mit dem Framebuffer ebenfalls ziemlich banal erzeugen kann, kennt jemand>> irgendeinen sinnvollen Einsatz für dieses Feature?>> Laufschriften mit minimalem Aufwand.
Schon mal gemacht?
So minimal ist der Aufwand nämlich gar nicht.
Zumindest dann nicht, wenn jede beliebige Laufschrift möglich sein soll.
* Links rum, Rechts rum
* Text beliebiger Länge
* 1 feststehende Zeile, 1 laufende Zeile.
> Oder Eingabefelder länger als das> Display.
Ditto.
> Ist aber in der Tat mehr ein Gimmick als ein hartes Feature.
IMHO in Wirklichkeit für Nichts zu gebrauchen.
Mir wärs lieber gewesen, sie hätten dem Controller mehr RAM verpasst und
dafür ein paar Attribute auf Character-Ebene, wie Blinken bzw Invers.
Damit hätte man mehr anfangen können.
