Ich möchte einen ATmega328, an dem ein graphisches Display "hängt" über die serielle Schnittstelle an einen Linux Rechner anschließen. Der Linux Rechner sendet seine Ausgaben mittels TTYS0 an den AVR. Soweit so einfach und die Ausgaben des Linux - Rechners kommen auch auf dem Display an. Mein "Problem" ist nun, dass ich gerne die ESC-Sequenzen (VT100) auf dem graphischen Display interpretieren möchte. Hat schon einmal jemand eine VT100 Emulation auf einem ATmega geschrieben oder kennt jemand einen Link ? (okay, ich gebs zu: selber schreiben wäre nicht schlecht, aber an sich wollte ich eigentlich an meinem Projekt weiter werkeln und mich nicht an einem Terminal "verkünsteln"). Also, an alle die, die da sagen: schreibs doch selbst ... ich gebs zu ... ich bin dafür zu faul (warum das Rad immer wieder neu erfinden)
Im letzten Jahrhundert habe ich sowas für 8080/8085 Assembler geschrieben ;) Aber jetzt im Ernst .. Nur die Escape Sequenzen zu dekodieren ist ja recht simpel und du musst das ja nicht vollständig implementieren. Aber woher soll jemand deine Grafikroutinen und ihren Aufruf kennen. Was fertig gebackenes, das genau auf dein System passt wird dir keiner liefern können.
Ralph S. schrieb: > (okay, ich gebs zu: selber schreiben wäre nicht schlecht, aber an sich > wollte ich eigentlich an meinem Projekt weiter werkeln und mich nicht an > einem Terminal "verkünsteln"). > Also, an alle die, die da sagen: schreibs doch selbst ... ich gebs zu > ... ich bin dafür zu faul (warum das Rad immer wieder neu erfinden) Im Prinzip schon richtig. Allerdings verwenden die meisten Programme (über geschätzte 95%) einen recht kleinen Subset der Möglichkeiten. Cursor positionieren, eventuell invers schreiben, Display löschen. Recht viel mehr kommt in den meisten Programmen nicht vor. Das geht zum Implementieren relativ rasch, da du im Grunde dich ja nur auf die Erkennung eines Escape konzentrieren musst. Nach dem Escape kommen ein par Zeichen, die in den meisten Fällen mit einem Buchstaben abgeschlossen werden (das Sonderzeichen nach dem Escape verrät dir, wann nicht). Der Buchstabe sagt dir, was du mit dem Teil zwischen Escape und Buchstabe anfangen musst (den du dir zwischengespeichert hast). Kannst du mit dem Buchstaben nichts anfangen, dann gibst du das Zwischengespeicherte einfach im Nachhinein aus und gut ists. Alles in allem eine Sache auf ein paar Stunden, je nachdem wie kompliziert dein restlicher Teil aufgebaut ist. Alles in allem halb so wild http://ascii-table.com/ansi-escape-sequences-vt-100.php
:
Bearbeitet durch User
smile, die "Grafikroutinen" benötge ich ja nicht (außerdem werde ich das Display nur mit buntem Text füttern). Ich wollte mich schlicht um das Parsing der ESC-Sequenzen drücken. Prinzipiell reicht mir ja auch schon ein "normaler" C-Quelltext (egal für welchen Prozessor). Im Moment bin ich ja dran am Programmieren ! Hrmpf (weil mir jetzt dann die Zeit für anderes fehlt)
Ralph S. schrieb: > smile, die "Grafikroutinen" benötge ich ja nicht (außerdem werde ich das > Display nur mit buntem Text füttern). > > Ich wollte mich schlicht um das Parsing der ESC-Sequenzen drücken. > Prinzipiell reicht mir ja auch schon ein "normaler" C-Quelltext (egal > für welchen Prozessor). Ach komm: Nach dem Erhalt eines Escape ein Flag setzen, so dass die nächsten Zeichen nicht direkt ausgegeben werden sondern erst mal in einem Array landen ist jetzt nicht wirklich Raktenetechnik für jemanden der die Grafikfunktionen bereits geschrieben hat. > Im Moment bin ich ja dran am Programmieren ! Hrmpf (weil mir jetzt dann > die Zeit für anderes fehlt) Ich sag jetzt nicht, dass das eine Sache auf ein paar Minuten ist, aber soooo massig viel Zeit geht da auch nicht rein. Der Escape-Zwischenspeicher Mechanismus ist eine Sache für Abends, wenn man schon müde ist und noch eine halbe Stunde investieren kann. Und die halbe Handvoll Escape Sequenzen, die in der Praxis tatsächlich vorkommen sind dann nur noch das Sahnehäubchen. Da dauert es wesentlich länger, sich aus einem vorhandenem Code, dessen Anbindung an die Anzeige vollkommen anders als bei dir ist, sich die relevanten Stellen per Copy&Paste rauszuschneiden und anzupassen. Manchmal erfindet man das Rad neu, weil es schneller geht als erst mal nach einem passenden Rad zu suchen und das dann anzupassen.
:
Bearbeitet durch User
Karl Heinz schrieb: > schon müde ist und noch eine halbe Stunde investieren kann. Und die > halbe Handvoll Escape Sequenzen, die in der Praxis tatsächlich vorkommen > sind dann nur noch das Sahnehäubchen. Wenn nach einem Escape kein '[' kommt, würde ich erst mal sowieso den Escape Behandelteil wieder abschalten. Und von dem, was dann noch an Kommandos übrig bleib, kannst du getrost mindestens 80% aller Kommandos wegen praktischer Irrelevanz erst mal ignorieren. Mein erstes Subset wäre
1 | <ESC>[<l>;<c>H wobei <l> und <c> auch fehlen dürfen und damit als 0 gelten |
2 | <ESC>[<v>K <v> darf auch wieder fehlen |
3 | <ESC>[<v>J <v> darf fehlen |
4 | <ESC>[<v>A |
5 | <ESC>[<v>B |
6 | <ESC>[<v>C |
7 | <ESC>[<v>D |
8 | und eventuell noch ein paar aus <ESC>[<v>m |
das dürfte für die meisten ansteuernden Programme völlig ausreichen. Was dann noch fehlt, ergibt sich dann schon.
:
Bearbeitet durch User
Und nicht vergessen, das das VT100 nicht nur die Escape Sequenzen versteht sondern auch die "normalen" ASCII Steuerzeichen (CR,LF,VT,HT,BS usw). Auch wenn du keine Linien echte Grafik willst brauchst doch die Routinen zum Zeichen löschen oder Cursor verschieben usw.
Hier die Unterlagen http://vt100.net/docs/vt100-ug/ http://www.vt100.net/docs/vt100-tm/
:
Bearbeitet durch User
Ralph S. schrieb: > Hat schon einmal jemand eine VT100 Emulation auf einem ATmega > geschrieben oder kennt jemand einen Link ? Warum sollte das auf einem AVR anders aussehen als auf einem PC?
:
Bearbeitet durch User
Smile, ich habs ja jetzt (fast) schon (fertig) geschrieben .... lach
Ralph S. schrieb: > > Hat schon einmal jemand eine VT100 Emulation auf einem ATmega > geschrieben oder kennt jemand einen Link ? schau doch mal hier: http://www.msarnoff.org/terminalscope/ The Terminalscope is a full, bidirectional serial terminal that uses a PS/2 keyboard for input and displays 54x24-character output on an oscilloscope or XY display. It can be connected to a PC via USB-to-TTL adapter or directly to another microcontroller. Features include: 7-bit ASCII character set plus box-drawing characters Flicker-free 60Hz picture Most ANSI/VT100 escape sequences interpreted Reverse video attribute supported All your favorite ncurses terminal programs (vi, nano, top, links, mc, irssi, etc.) display fine Graphical configuration menu Selectable baud rate (2400-38400), data bits, parity, and stop bits Two configuration profiles (stored in EEPROM) quickly selectable with an external switch
Beim Umschalten auf Grafiksymbole: wo liegen die denn im Zeichensatz? Ich meine bei Unicode ist das 0x2500 bis 0x257f, wo sitzen sie dann in der ASCII-Tabelle?
http://vt100.net/docs/vt100-ug/ Besser http://www.vt100.net/docs/vt100-tm/ek-vt100-tm-002.pdf Tabelle A9 auzf Seite A-12 Generell: zu Zeiten eines VT100 war die Welt noch einfach: es gab nur 7 Bit ASCII und die blieben im wesentlichen auch immer gleich. Höhepunkt in der 7-Bit ASCII Welt war es, ob ein Pfund Zeichen oder ein Paragrafen-Symbol angezeigt wird. Alles mit Codes großer 0x7F war vollkommen vom Hersteller vorgegeben. Es gab da keinen Standard, das machte jeder wie er wollte. Quasi als Ausgleich dafür gab es aber in dieser Zeit noch Unterlagen und Dokumentationen die ihr Geld wert waren und die man zum Gerät einfach so dazu bekam. Da stand dann zwar auch drinnen, dass man einen zum Kauf des Gerätes beglückwünscht, aber im Gegensatz zu heute nicht in 24 Sprachen und sonst nichts mehr, sondern es gab dann noch ein paar Zig Seiten, auf denen alles haarklein beschrieben war.
:
Bearbeitet durch User
Hallo, vielleicht nützen Dir ja die beigefügten Perl-Skripte etwas. Sie enthalten am Ende eine Spezifikation der VT100/VT102 ESC-Sequenzen. Diese Spezifikation kann man als Beschreibung eines nichtdeterministischen endlichen Automaten (NFA) interpretieren. Das Skript macht daraus durch Teilmengenkonstruktion (nach Myhill, siehe z.B. ISBN 978-0321486813) einen äquivalenten deterministischen endlichen Automaten (DFA), den es in Form eines bash-Skripts ausgibt. Du kannst dieses Skript einfach in einen bash pipen und es wird Dir übersetzbaren Code erzeugen. Dabei wird jeder Zustand des DFA in eine Funktion abgebildet, die das nächste Eingangszeichen als Input erhält, gegebenenfalls die entsprechende Grafikroutine aufruft und als return-Wert den Folgezustand des DFA liefert. Ich habe das damals für ein C++ Projekt gebraucht, daher wird C++ Code erzeugt, es sollte aber durch ein paar Änderungen im Perl-Skript ohne Probleme auch C Code (im Prinzip auch jede andere vergleichbare imperative Sprache) möglich sein. Natürlich wirst Du die Grafikroutinen sowie eine geeignete Laufzeitumgebung für den DFA implementieren müssen. (Der DFA selber ist nicht mehr als eine einfache Schleife.) Ich hatte dieses Skript damals geschrieben, da ich mehrere sich teilweise widersprechende Spezifikationen des VT100/VT102 Terminals hatte und ich mir die Möglichkeit einer schnellen und sicheren Anpassung der Emulation an eine geänderte Spezifikation offen halten wollte. Das hat auch sehr gut funktioniert. Die implementierte Simulation sollte dem Original schon sehr nahe kommen. Wenn ich mich richtig erinnere fehlt lediglich die Möglichkeit, die dargestellten Zeichen auf doppelte Breite bzw. Höhe umzustellen. Hinweis: Es gibt einige Steuerzeichen, die vom VT100 übergeordnet zu ESC-Sequenzen ausgewertet werden. Folglich gibt es auch in der Emulation eine Routine, die diese Zeichen auswertet, ohne dass sie an den DFA weitergereicht werden. Daher ist der Zustand 0 des DFA trivial und enthält insbesondere keinen Übergang in den Zustand 1. Dies geschieht eine Ebene höher. Die übergeordnete Routine nimmt auch die mögliche Umschaltung in den VT52-Mode vor, der in einem eigenen DFA implementiert ist. Der DFA des VT52-Modes ist analog implementiert, nur deutlich einfacher. Viel Spaß
Mike schrieb: > Beim Umschalten auf Grafiksymbole: wo liegen die denn im Zeichensatz? > Ich meine bei Unicode ist das 0x2500 bis 0x257f VT100 war lange lange vor Unicode. Soweit ich mich erinnere gab es die 256 1-Byte-Zeichen basierend auf ASCII, aber was die Zeichen der oberen Hälfte betrifft konnte man zwischen mehreren (3?) Zeichensätzen umschalten. Am besten besorgst du dir das VT102-Manual (EK-VT102-UG-003). Andrerseits erhebt sich die Frage, ob und warum du in allen Punkten VT100-kompatibel sein willst, du könntest ja auch den PC-Zeichensatz verwenden mit Umlauten und Block-Grafik, so dumm war der ja nicht. Georg
Karl Heinz schrieb: > Besser > http://www.vt100.net/docs/vt100-tm/ek-vt100-tm-002.pdf > > Tabelle A9 auzf Seite A-12 danke!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.