Moin,
in aller Kürze, warum macht kein Terminal Programm einen carriage
return (\r) alleine, sondern immer carriage return line feed (\r\n),
und wie kann man das umgehen?
Eigendlich unnötige Informationen:
AVR, Tiny2313, Atmel Studio 6.0, Terminal Programme: Bray Terminal, AVR
Studio Terminal
BrayTerminal erkennt mir wenigstens noch die Escape-Sequenzen "\b", also
ein Zeichen zurück auf der gleichen Zeile, das Studio Terminal kann
nicht mal das.
Grüsse
Ralf
@ Klaus De lisson
danke, werd ich ausprobieren, obwohl HTerm vor Urzeiten aus meiner Liste
der nutzbaren Tools ausgeschieden ist, warum weiß ich nicht mehr, ist
halt länger als 10 Jahre her.
@ Peter II
Genau, Standarts, "\r" = Carriage Return, "\n" = new line. Sind die
Standarts heute wirklich so "\r" = "\r\n" und "\n" auch "\r\n".
Vielen Dank im übrigen für die geschätzten 300 Seiten Standart
Beschreibung, erwartest Du ganz ehrlich das man das alles ließt, wenn
man "Hello World" auf der Konsole ausgeben möchte???
(In meinem Fall halt "Hello\r World" = "World")
Timebeast schrieb:> Vielen Dank im übrigen für die geschätzten 300 Seiten Standart> Beschreibung, erwartest Du ganz ehrlich das man das alles ließt, wenn> man "Hello World" auf der Konsole ausgeben möchte???
eigentlich schon, denn dann weis man wie man es zu machen hat. Sonst ist
es doch nur ein trial and error und beim nächsten Programm geht es schon
wieder nicht.
Man kann sich auch nur die betreffenden Abschnitte durchlesen.
Bei HTTP ist es auch nicht anders, dort musst du mit \r\n arbeiten,
sonst es es kein HTTP.
So, HTerm bereit, und was soll ich sagen, es geht trotzdem nicht.
Also man kann mit "New Line at" angeben ob bei "CR" (Carriage Return ->
"\r") oder bei "LF" (Line Feed -> "\r") in eine neue Zeile gesprungen
werden soll.
Das klappt auch, sowohl bei CR als auch bei LF. Sprich, beide
Escape-Sequenzen werden richtig erkannt und interprtiert.
ABER, das er macht keinen Carriage Return!
Was nun?
nee nee ,, bezüglich Htmerm.
Das hat nix mit "new line at" zu tun.
Unten im Programm "send on Enter" wäre mein Kandidat.
Allerdings solltest du jetzt mal langsam sagen ob es um welche Richtung
es dir geht. PC->uC oder umgekehrt.
Gruss Klaus
Vorweg, "ABER, das er macht keinen Carriage Return!" sollte natürlich
"ABER, er macht keinen Carriage Return!" heissen.
@Ulrich B.
Danke, erstmal für den Versuch.
"...ob CR oder CR/LF gesendet..." es geht ja nicht um senden, sondern
empfangen, und beim Empfangen kann man leider wieder nur einstellen bei
welcher Escape-Sequenz in eine neue Zeile gesprungen werden soll.
Auch hier ist es wie bei HTerm, sende ich ein "\r" erkennt er dies als
"CR", sprich wenn ich einstelle das er bei "CR" in eine neue Zeile
springen soll, macht er das.
Aber, ein Carriage Return, also zurück springen an den Anfang der Zeile
wird nicht ausgeführt.
@Klaus De lisson
oh mein Gott, stimmt, auf die Idee das man auch verstehen könnte das
mich LineFeeds auf dem uC stören würden bin ich gar nicht gekommen,
sorry!
Es geht natürlich darum, das ich einen String vom uC sende, und auf dem
PC anzeigen lasse.
Jetzt schreibt er mir allerdings jeden Wert (es sind Strings) in eine
neue Zeile und das macht die Sache komplett unleserlich.
Ich hab mir für MC-Anwendungen folgende Konvention angewöhnt:
Der MC sendet immer ein "\r\n" am Ende.
Der MC empfängt eine Zeile, wenn "\r" oder "\n" erkannt wird.
Ein nachfolgendes "\r" oder "\n" allein wird ignoriert.
Hallo Peter,
"Der MC empfängt eine Zeile..." für meinen Fall egal.
"Der MC sendet immer ein "\r\n" am Ende."
Deine Konvention entspricht einem "an Zeile Anfang springen" ("\r")
gefolgt von einer neuen Zeile ("\n").
Überraschung, das brauchst Du gar nicht zu tun. Ein einfaches "\r" oder
"\n" reicht für dieses Verhalten in Terminal Programmen (auf dem PC)
völlig aus.
Mich intressiert eher Deine Konvention, wenn Du auf dem Terminal
Programm immer in die selbe Zeile schreiben willst.
Um immer in dieselbe Zeile zu schreiben würde ich eher eine ANSI-Escape
Sequenz nehmen, z.B. CSI n G Cursor Horizontal Absolute (Moves the
cursor to column n.)
Gruß,
Ulrich
Timebeast schrieb:> @Klaus De lisson> oh mein Gott, stimmt, auf die Idee das man auch verstehen könnte das> mich LineFeeds auf dem uC stören würden bin ich gar nicht gekommen,> sorry!
also mir ist immer noch nicht klar was du eigentlich willst.
Du sendest etwas vom uC an den PC und es stört dich das LF.
Warum sendest du da LF denn dann ?
... oder willst du so ein quasistatisches Terminalbild mit festen
Positionen auf dem PC Schirm ? Dann musst du wohl mit den esc-Sequenzen
a la VT100 arbeiten.
Bisher machst du mir Rätsel.
Gruss Klaus
Timebeast schrieb:> Überraschung, das brauchst Du gar nicht zu tun. Ein einfaches "\r" oder> "\n" reicht für dieses Verhalten in Terminal Programmen (auf dem PC)> völlig aus.
Z.B. Hyperterminal ist da anderer Meinung.
Timebeast schrieb:> Mich intressiert eher Deine Konvention, wenn Du auf dem Terminal> Programm immer in die selbe Zeile schreiben willst.
Wozu sollte ich das tun?
"\b \b" löscht ein Zeichen sichtbar.
@ Jörg Esser
Du benutzt einen Telnet-Client um mit einem Tiny AVR über RS232 zu
kommunizieren. Ich meine, klar, kann man machen. Putty stand im übrigen
wie schon HTerm und ich glaube HyperTerminal (war zu Win98 zeiten halt
Boardwerkzeug) auf der Liste der nicht so tollen Programme für RS232
Kommunikation. Aber nunja, Versuch macht kluch, oder so ;-)
@ Berger
"Beta-Version aus dem Jahr 2006"
...und damit gehört es noch zu den modernsten Programmen dieser Art.
@ Ulrich B.
ANSI-Escape Sequenz, so so, und das wird auch von allen Terminal
Programmen unterstützt? Welchen String soll ich denn mal versuchsweise
an mein Terminal Programm schicken?
Timebeast schrieb:> ANSI-Escape Sequenz, so so, und das wird auch von allen Terminal> Programmen unterstützt? Welchen String soll ich denn mal versuchsweise> an mein Terminal Programm schicken?
Wenn du mit einem Terminal kommunizieren willst dann halte dich an den
Standard. Siehe meinen Link oben.
Ansonsten ist das Mittel der Wahl sich ein eigenes Protokoll zu basteln
und die PC Anwendung selbst zu schreiben.
Und wie ich oben schon schrieb halte ich mich ja an den Standart:
"\r" = Carriage Return
"\n" = new Line
Die Terminal Programme interpretieren den "Standart" allerdings
anscheinend anders in dem sie "\r" als "\r\n" und "\n" auch als "\r\n"
interprtieren.
Nichts für ungut, es geht halt nicht!
Es wäre halt nett gewesen und würde ein Carriage Return auch ein
Carriage Return sein und kein LineFeed/Carriage Return, wäre es auch
einfach gewesen.
Ich dachte ich wäre nicht der erste dem auffällt das es keinen "\r" mehr
gibt.
Sorry für Eure verschwendete Zeit, die Ihr mit meiner "blöden" Frage
verbracht habt, ich dachte das wäre Standart.
Timebeast schrieb:> ANSI-Escape Sequenz, so so, und das wird auch von allen Terminal> Programmen unterstützt?
Die üblichen machen das.
Deswegen: Bray, hterm & Co. sind keine Terminalprogramme.
Terminalprogramme sind Programme, die ein Terminal nachahmen, i.d.R.
DECs VT-100, das so verbreitet war, daß sein Befehlssatz eine ANSI-Norm
wurde.
MoinMoin,
Timebeast schrieb:> Die Terminal Programme interpretieren den "Standart" allerdings> anscheinend anders in dem sie "\r" als "\r\n" und "\n" auch als "\r\n"> interprtieren.
ich würde sogar soweit gehen, das manche Betriebssysteme das Zeilenende
einfach umdefinieren und sich Anwendungsprogramme dem
Betreibssystemstandard anpassen:
Windows --> cr/lf
Unix --> lf
MacOS --> cr
Gleiches Verhalten hat man ja auch, wenn man sich Textdateien, welche
unter dem jeweiligen Betriebssystem erzeugt hat, anschaut.
Wie schon oben geschrieben, entweder man sucht sich die entsprechende
Option des jeweiligen Terminalprogrammes heraus und ändert diese nach
seinen Wünschen ab oder benutzt einen wirklichen Standard, wie z.B.
ANSI-ESC-Sequenzen, wenn man wirklich auf der sicheren Seite sein
möchte.
Grüße Uwe
PS.: was lernen wir eigentlich daraus --> allein nur UNIX zeigt die Welt
"unverblümt" an ;-)
Uwe Berger schrieb:> Wie schon oben geschrieben, entweder man sucht sich die entsprechende> Option des jeweiligen Terminalprogrammes heraus und ändert diese nach> seinen Wünschen ab oder benutzt einen wirklichen Standard, wie z.B.> ANSI-ESC-Sequenzen, wenn man wirklich auf der sicheren Seite sein> möchte.
Genau! So kommt es mir auch vor.
Was der TO genau will hat er ja noch nicht gesagt.
Möchte er ein Terminalfenster wie einen Grafikbildschirm ansteuern und
für Wert 1 (zei2,spa4) angeben soll er VT100 nehmen.
Will er ein einfaches Frontent auf dem PC für Messwerte kann er auf VB
oder sonstwas zurückgreifen und den uC abfragen um die Werte in eine
Maske zu pressen.
Will er kein LF soll er es nicht senden.
Irgendwie merkwürdig diese Fragestellung
Gruss Klaus
na die Fragestellung ist doch inzwischen klar! Er will ein CR senden und
im Terminalprogramm soll der Cursor nur an den Zeilenanfang springen und
kein zusätzliches Line Feed machen.
Gerhard
So mach ich das. Und das Putty nicht gut ist ist mir egal. Es frisst was
Ich ihm gebe. Und wenns das nicht tut bastel ich halt drumherum. Oder
willste dir noch die Arbeit machen ein Terminal Programm zu schreiben?
Timebeast schrieb:> Jetzt schreibt er mir allerdings jeden Wert (es sind Strings) in eine> neue Zeile und das macht die Sache komplett unleserlich.Gerhard schrieb:> na die Fragestellung ist doch inzwischen klar! Er will ein CR senden und> im Terminalprogramm soll der Cursor nur an den Zeilenanfang springen und> kein zusätzliches Line Feed machen.
...nein eben nicht, sonst würde ersteres Zitat nicht so ausfallen! Aus
diesem Satz lese ich (und auch andere), dass der TO auf Basis von \b,
\n, \r, \t usw. eine, in welcher Form auch immer, formatierte Ausgabe
generieren will. Wenn dem so ist, ist er auf dem falschen Weg.
Vielleicht noch ein paar Links zum Thema, die dann passen würden:
http://www.mikrocontroller.net/articles/MCURSES
auf deren Basis ich dann mal einen Full-Screen-Editor (auch für MCs
geeignet) geschrieben habe:
Beitrag "Re: MCURSES - Mini Curses Bibliothek für Mikrocontroller"
Grüße Uwe
Timebeast schrieb:> Und wie ich oben schon schrieb halte ich mich ja an den Standart:> "\r" = Carriage Return> "\n" = new Line> Die Terminal Programme interpretieren den "Standart" allerdings> anscheinend anders in dem sie "\r" als "\r\n" und "\n" auch als "\r\n"> interprtieren.
Welche tun das? Selbst das ganz billige Windows Hyperterminal
interpretiert CR und LF separat und korrekt.
1
"Hello \rWorld" liefert
2
"World "
3
4
"Hello \nWorld" liefert
5
"Hello
6
World"
7
8
"Hello \r\nWorld" liefert
9
"Hello "
10
"World"
Du kannst die meisten Terminalprogramme allerdings so einstellen, dass
ein loses CR automatisch um ein LF ergänzt wird. Beim Windows
Hyperterminal ist das "Beim Empfang Zeilenvorschub an Zeilenende
anhängen".
