Liste aller Escape-Sequenzen und Formatierungszeichen

Hallo Leute,

wie man vielleicht am Threadtitel schon erkennen kann, suche ich eine vollständige(!!) Liste aller in C verwendbaren Escape-Sequenzen und Formatierungszeichen. Und das erstmal unabhängig davon ob sie vom AVR-GCC unterstützt werden oder nicht. Ich stelle diese Frage, weil ich schon Konstrukte wie \033[2J in C-Programmen gesehen habe, die in keiner von mir bisher gefundenen Liste auch nur ansatzweise erwähnt werden.


Achja...
außerdem wüsste ich gern, ob es in der C-Standardbibliothek auch eine Funktion gibt mit der ich den Cursor auf eine bestimmte Position setzen kann.


Gruß,
Felix

Du kannst alle Zeichen angeben, und zwar als oktal. \033 ist zB eine 27, die 255 wäre ein \377.

Ob die jeweiligen Sequenzen von einem Display/Terminal oder was auch immer implementiert/interpretiert werden, ist keine Sache des C-Standarts, gleiches gilt für Cursorpositionierungen.

Du kannst dir jedoch prinf-Ähnliche Ausgabefunktionen schreiben, die Cursorpositionierung unterstützen und in gewissem Grad von der Hardware abstrahieren.

Beispielcode wie das aussehen kann findest du im Modul vfd-put in
http://freenet-homepage.de/gjl/pub/ebook/index.html

Bei Fragen, fragen.

Für die Codes, die gcc unterstützt, müsste ich jetzt auch in die Quellen schauen... Es genügt jedoch nicht, daß der Compiler es unterstützt. Ein "Hallo\n" wird wohl in ein "Hallo\n" übersetzt, also besser in die Assembler-Quellen schauen :-)

Naja,
momentan geht es mir eher darum meine LCD-Funktionen (die auch Cursorpositionierung unterstützen) am PC nachzubilden, um eine Menübibliothek die ich gerade schreibe leichter/schneller testen zu können.

So kann ich meine Bibliothek einfach in VisualStudio in einer Win32-Konsolenanwendung wunderschön debuggen, und dann später in meinen AVR-Projekten weiterverwenden.


Daß 033 eine Oktalzahl ist war mir übrigens durchaus bewusst...
aber ein Blick in eine ASCII-Tabelle verrät: es ist das Zeichen "ESC"
und in Kombination mit dem darauffolgenden [2J tut das irgendwas.

Oder mal gurgeln:

http://www.asphelper.de/referenz/ASCIIANSI.asp
http://www.tfh-berlin.de/~kempfer/skript_c/Kap07.html
http://www.ta7.de/txt/dos/dos0018.htm

Spätestens bei ANSi-Sequqnzen zur Farbumsteling oder Beep (CTRL-g) macht dein LCD aber schlapp, oder? *fg*

Danke für die links, damit sollte sich was anfangen lassen...
zumindest sobald ich herausgefunden habe wieso bei VisualStudio das ESC-Zeichen als "←" angezeigt wird wenn ich es mit printf ausgebe. (falls da nix zu sehen sein sollte: es ist ein Pfeil nach links)

Zitat:

---

Spätestens bei ANSi-Sequqnzen zur Farbumsteling oder Beep (CTRL-g) macht dein LCD aber schlapp, oder? *fg*

---

hast du etwa kein Farb-LCD mit eingebautem Lautsprecher? ;)

Nö, das nicht. Aber dafür gibt es ANSI-Sequenzen.

Was ich da geschrieben habe liest sich echt wie aus einer üblen taiwanesischen Bedienungsanleitung :oops:

Damit die Console die ANSI-Sequenzen interpretiert musst man früher glaub irgendwo was drehen in autoexec.bat oder config.sys.

Aber du brauchst doch diese Kommandos garnicht. Nimm dir einfach 4 Textfelder oder eine TextArea und gib die Codes dahin aus. Auf dem µC will man ja auch nicht mühsam erst diese langen Sequenzen decodieren.
Von der GUI bzw TUI-Abhängigkeit parametrisierst du eh durch #ifdef oder Bibliotheken.

Oder du arbeitest direkt aufm µC. Scheint mir enifacher zu sein als erst VisualStudio bauchpinseln zu müssen.

Natürlich könnte ich direkt auf dem µC arbeiten, aber wie soll ich den Code dann debuggen?
Simulieren geht nicht, da ich ja auf das Display zugreife, und einen ICE habe ich nicht.
(und Notlösungen wie z.B. Ausgaben über RS232 sind nicht wirklich effizient)

Außerdem soll meine Menübibliothek möglichst universell einsetzbar sein,
also mit so ziemlich jedem denkbaren LCD funktionieren (egal welche Größe das Display hat).
bzw. einfach mit jedem beliebigen "Ding" auf dem man irgendwie Text ausgeben, und den Cursor positionieren kann.


Daher wollte ich das ja im VisualStudio machen, und da erschien mir ein Konsolenprojekt die einfachste Variante zu sein.
(aber vielleicht ist eine grafische Oberfläche doch besser geeignet, mal sehen)

Da gibt's Beispiele.

https://www.roboternetz.de/wissen/in...teuerung_ANSII

AAAABER Ansii-Sequencen muß das TERMINAL (Emulation) verstehen, der Programmiersprache gehen die am A... vorbei

Ein Escape-Zeichen ohne nix hinten nach kann aber jedenfalls keiner.

Eine funzende terminal-Emulation ist Hyperterm, im ANSII-Mode, natürlich
(VT100 und aufwärts)

Zitat:

---

Zitat von Felix G

[...] aber wie soll ich den Code dann debuggen?

---

Garnicht :-)

Ich hab noch nie nen Debugger gebraucht, zumindest nicht für Software, die ich selber geschrieben habe. Die funktioniert einfach...

Einmal hatte ich wirklich ein Problem und mir dafür extra AVR-Studio gezogen und simuliert und viel Zeit reingehangen und so, aber in vitro bringt das nix und bei Debuggen ist die Echtzeit eh über'n Jordan. Also: hinsetzen, Brain v0.9b bemühen und es geht.

Debuggen ist IMHO eine Technik, die man nicht braucht.

Wenn man sie braucht, dann läuft es meist in Richtung reverse engineering komplexer Software, die nicht von einem selbst geschrieben ist (zB gcc debuggen).

Zitat:

---

die ich selber geschrieben habe. Die funktioniert einfach...

---

Na, ist doch schön, endlich mal wer ohne Komplexe

Zitat:

---

Zitat von SprinterSB

Zitat:

---

Zitat von Felix G

[...] aber wie soll ich den Code dann debuggen?

---

Garnicht :-)

Ich hab noch nie nen Debugger gebraucht, zumindest nicht für Software, die ich selber geschrieben habe. Die funktioniert einfach...

---

Freut mich für dich, daß alle deine Programme immer sofort 100%ig fehlerfrei laufen. Aber ich persönlich bin eben kein Programmiergott, und es kommt manchmal schon vor daß eines meiner Programme einen Fehler enthält der nicht so einfach zu finden ist.

Genau aus diesem Grund möchte ich die Menübibliothek mit Hilfe eines Debuggers schreiben, denn obwohl ich sicherlich auch ohne Debugger irgendwann die evtl. vorhandenen Fehler finden und entfernen könnte, würde es doch deutlich länger dauern. Es ist einfach praktisch, sich den Inhalt jeder beliebigen Variablen zu jedem beliebigen Zeitpunkt ansehen zu können, oder aber Breakpoints zu setzen um schnell und einfach herauszufinden ob ein bestimmter Codeteil überhaupt ausgeführt wird.


Aber hey...
vielleicht solltest du dein Brain v0.9b mal an Microsoft verkaufen
die wären sicher froh, wenn sie fehlerfreie Software schreiben könnten.

Sorry, ich wollte niemanden verärgern. Ist wie gesagt *IMHO*.

@PicNick. Ich bin nicht zu kaufen, nur zu mieten *g*

Zitat:

---

Debuggen ist IMHO eine Technik, die man nicht braucht.

---

<- aha ^^

joar .. was machst dann wenn z.b. Counter-Stände suchen willst ? oder bei nem ADC in nem gewissen Punkt sehn willst was da abgeht ? oder wo z.b. dad Programm hängen bleibt ? wo ms hängen bleiben ...........

Fehler macht man IMMER .. auch wenn dein Programm läuft hast sicher irgendwo Fehler :P

und spätestens wenn auf z.b. nem tiny24 was nachsehen willst was is
dann , was dann .. hast keine Chance ohne Debugger (Hardware), hast halt keine Uart wo was ausgeben kannst ... sobald nen Programm etwas Aufwändiger wird .. kommst nicht aus ohne Debugen .. zudem Spaart man sich ca 40% Zeit ;) was auch nen netter "Pro" punkt ist .. ich möchte mein ICE nichtmehr missen ;)

Gut wenn sagst du machst keine Fehler lebst wohl auch nach dem Motto "its not a Bug its a Feature" ?!?

Ach und ... Compiler machen auch Fehler ;) ...

Zitat:

---

Zitat von bluelight_electronic

Fehler macht man IMMER .. auch wenn dein Programm läuft hast sicher irgendwo Fehler :P

---

Auf kleineren/älteren µc inclusive AVR hat man schon gar nicht die Möglichkeit zu debuggen, wobei ich hier "debug" im eigentlichen Sinn verwenden möchte, also nicht ausgaben über UART, auf Console, via Status-LED etc verstehen will.

Zitat:

---

Zitat von bluelight_electronic

Ach und ... Compiler machen auch Fehler ;)

---

Jo, davon kann ich ein Lied singen. Ich mache ja Compiler-Entwicklung und bekomme momentan meinen A... versohlt *g*. Die Kosten für einen Fehler werden schnell 8- oder 9-stellig (Rückruf, Haftung, etc.)

Der Punkt ist, daß dir ein Debugger einfach nicht hilft, bessere Software zu machen. Ein Debugger kann dir helfen, einen Fehler zu finden, wenn du weisst, daß ein Fehler in der Software drin ist!
Einen Compiler zu debuggen und zu hoffen, evtl auf einen Fehler zu stossen, ist absolut aussichtslos. Du blickst eben nicht mehr was abgeht.

Die übelsten Fehler sind die, wenn der Compiler klaglos durchläuft, 10000 oder 100000 Testprogramme (oder wieviel auch immer) sowohl im Compile-Streß als auch in den von ihm erzeugten Executables korrekt absolviert. Und dann trotzdem nen Fehler hat. Mit einem Debugger den Fehler schnell zu finden bringt dir absolut *nix*, wenn die damit erzeugten Programme in zigtausenden von Steuergeräten laufen und überall unterwegs sind...

Mit welcher Eingabe (zu übersetzender Quelle) würdest du denn anfangen von den 100000 Testfällen...?

Zudem, wenn du einen Denkfehler hast und deshalb etwas nicht geht, machst du beim Debuggen der entsprechenden Sequenz vermutlich den gleichen Fehler und siehst es nicht mal.

Vielleicht deshalb arbeite ich fast immer ohne Debugger (für AVR sowieso). Am schnellsten hat man Fehler gefunden, die man erst garnicht macht...

Für AVR fällt es mir vielleicht deshalb so leicht, weil die Programme immer sehr einfach sind und linear codiert wird (auch mit Interrupts würde ich das als quasi-linear bezeichnen).

Überrascht und erstaunt bin immer wieder, über den Code den man im Forum manchmal zu sehen bekommt, wo man bereits beim ersten Blick sieht, daß es garnicht laufen *kann* und der Autor sich nicht im mindesten überlegt zu haben scheint, was der Code, den er ha hingeschrieben hat, überhaupt macht.