serial.print etc: zurück zum Zeilenanfang? eine Zeile nach oben?

hallo,

ich habe 3 Fragen zu formatierten seriellen Ausgabe:

    • wie kann man mit serial.print etc zurück zum Zeilenanfang oder eine Zeile nach oben?
      CR (ASCII 13) bedeutet ja eigentlich zurück zum Zeilenanfang, allerdings wird mit "\n" auch gleichzeitig ein Zeilnvorschub gemacht (linefeed=LF=ASCII 10) - das möchte ich aber vermeiden.
    • Dann: gibt es einen Befehl für clear-end-of-line (CLREOL) ?
    • Außerdem suche ich eine Möglichkeit, auch in die Zeile oberhalb der aktuellen zu springen und diese neu zu beschreiben - geht das ?

HaWe:
ich habe 3 Fragen zu formatierten seriellen Ausgabe:

    • wie kann man mit serial.print etc zurück zum Zeilenanfang oder eine Zeile nach oben?
      CR (ASCII 13) bedeutet ja eigentlich zurück zum Zeilenanfang, allerdings wird mit "\n" auch gleichzeitig ein Zeilnvorschub gemacht (linefeed=LF=ASCII 10) - das möchte ich aber vermeiden.
    • Dann: gibt es einen Befehl für clear-end-of-line (CLREOL) ?
    • Außerdem suche ich eine Möglichkeit, auch in die Zeile oberhalb der aktuellen zu springen und diese neu zu beschreiben - geht das ?

Das geht alles mit VT100 Steuerzeichen und einem "Terminalprogramm" anstelle des "seriellen Monitor"

http://www-user.tu-chemnitz.de/~heha/hs/terminal/terminal.htm

Terminalprogramme bilden heute das in Software nach, was das VT100-Terminal damals in Hardware gemacht und den Standard für die Steuerzeichen bis heute gesetzt hat.

Terminalprogramme gehören bei Linux-Distributionen immer schon zum Betriebssystem dazu.

Unter Windows früher mal auch ("Hyperterminal"), aber die Zeiten sind vorbei, es gibt aber diverse Terminalprogramme (Payware, Freeware und auch Open Source) für Windows.

Ach ja, VT100 unterstützt nicht nur Cursoraktionen, sondern auch "bunt und in Farbe" auf dem Terminal, wenn auch nur Text in 8 Farben und zwei Helligkeitsstufen und 8 Hintergrundfarben. Ein kleines Programm zur Demonstration von VT100 Terminalcodes hatte ich hier mal gepostet:
http://forum.arduino.cc/index.php?topic=147715.msg1110406#msg1110406
(Funktioniert NUR mit einem Terminalprogramm, aber NICHT mit dem "seriellen Monitor")

danke für die schnelle Antwort!
Schade, dass das Sketch-Terminal so blöd ist, dafür hatte ich es eigtl gesucht :frowning:

ob die Sketch-Programmierer da mal dran arbeiten...?

HaWe:
ob die Sketch-Programmierer da mal dran arbeiten...?

Prognosen sind immer schwierig. Besonders, wenn sie die Zukunft betreffen.
Aber ich vermute mal, dass das eher nicht der Fall sein wird.

Der Serielle Monitor ist ja auch in Java implementiert, um kompatibel zwischen den verschiedenen unterstützten Betriebssystemen zu sein. Und bei 115200 Baud zeigt der serielle Monitor schon jetzt Performanceprobleme, die Performance würde sich ja mindestens um den Faktor 10 verschlechtern, wenn da jetzt noch ein umfangreicher VT100-Interpreter zwischengeschaltet wird. So etwas implementiert man besser in "native Code" passend zum Betriebssystem.

Aber weil der serielle Monitor sowieso nicht von alleine startet, ist es ja eigentlich kein Problem:
Es kostet einen Mausklick, um den seriellen Monitor zu starten.
Es kostet einen Mausklick, um ein alternatives Terminalprogramm zu starten.
So what?

so this: :sunglasses:
er findet automatisch den richtigen seriellen Port, ich kann per Sketch-Window resetten

  • und ... ecco ... isch 'abe gar keine auto, äh: terminaleprogramme - Signore :slight_smile:

Hallo, an Euch alle,
ich bin Newbee, leider habe ich kein Forum gefunden wo meine Frage besser 'reinpaßt. Seit längerer Zeit ärgert mich ein Problem mit "Serial.print und co.":
Ich benutze die Arduinoversion 1.05, mein Programm hat die Größe von 28.186 Byte, also ist noch etwas Platz. Im Programm. Ich benutze ich ca. insgesmt 59 mal die Funktion Serial.print. Bei weiteren benötigten "Serial.print" erzeugt der Compiler Unsinn ohne eine vernünftige Fehlermeldung!
Gibt es eine Möglichkeit das zu beheben?
es grüßt Euch
Lichtfilter

lichtfilter:
Gibt es eine Möglichkeit das zu beheben?

Ausgabe von Textkonstanten mit F-Makro.

Ist es wirklich der Compiler der meckert, oder stürzt das Programm zur Laufzeit ab? Ich tippe auf letzteres

Überprüfe mal wie viel RAM du noch frei hast (mit der Version die noch läuft):

int getFreeRAM() 
{
  extern int __heap_start, *__brkval; 
  int v; 
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
}

Viele Anfänger klatschen das Programm voller String Konstanten bei Serial Ausgaben ohne zu wissen, dass diese alle im RAM landen. Und davon gibt es nicht viel. Kann man aber bei print() einfach umgehen:

Serial.println(F("String im Flash"));

Durch das F() Makro belegt der String nur Flash

<...gigt es eine Möglichkeit das zu beheben...>.
Also, das hätte ich nie erwartet - ich plage mich mit diesem Problem schon mehrere Monate nun stelle ich meine Frage und sofort kommen mehrere Antworten 'great' und vielen Dank ! - Ich gehe Euren Anregungen gleich nach und melde mich wieder.
Lichfilter

...und melde mich wieder.

leider habe ich kein Forum gefunden wo meine Frage besser 'reinpaßt

Kannst dann auch gerne einen "New Topic" ( mit passender Überschrift ) aufmachen.
Auf Deutsch bist du hier schon richtig...

zum Flash habe ich 2 Fragen:
Ist es nicht so, dass Flashs nur begrenzt oft geschrieben werden können (nur wenige 1000 mal oder so )? Ist es dann nicht riskant, den Flash unnötig zu "belasten"? Oder findet hier keine extra Schreibaktion statt?
Und wie ist die Ausführungsgeschwindigkeit auf dem Flash? Ist der nicht viel langsamer als als aus dem RAM, was u.U. gerade bei sehr schnellen serial Ausgaben (115000 baud oder so) ziemlich bremsen kann?

<gibt es eine Möglichkeit>
Hi, da bin ich wieder,
zu nächst zum Vorschlag der RAM-Überprüfung: ich habe den Code-Teil <getFreeRAM()> in mein Programm eingebaut. Es wurde auch anstandslos alles übersetzt in Ermangelung von C++ - Kenntnissen weiß ich nicht wie man das Ergebnis auf den serieellen Monitor ausgeben kann. Vielleicht kann man mir auf die Sprünge helfen (ich verspreche auch C++ zu lernen - eine fantastische Sprache die Arduino offenbar sofort versteht).
Den zweiten Vorschlag vom Moderator <Serial.println(F("String im Flash"));> habe ich sogut wie's mir möglich war überprüft - leider ohne Erfolg. Nach dem rigorosen Einbau des 'Stringoperators F' ? konnte ich noch weniger Serial.print-Funktionen benutzen.
Offenbar mache ich da was falsch.
Zur weiteren Prüfung habe ich einfach ein kleines Programm geschrieben in dem ich 619 mal die Zeile
"Serial.print(" 120mal Space i=");Serial.print(i++); reingeschrieben - die Sketchgröße war dann 30.640 also fast am Anschlag!
Danch wurden alle Zeilen mit dem 'F-Operator' geändert:
"Serial.print(F("120malSpace i="));Serial.print(i++)"
mit dem traurigen Ergebnis, daß bereits nach 159 Zeilen die Sketchgröße mit 29.700 fast am Anschlag war.
Wo liegt der Fehler?
Schließlich möchte ich gerne einen aufmachen aber wie?
Aller Anfang ist schwer. Hoffentlich habe ich Euch nicht zuviel genervt. Später fasse ich mich sicher kürzer.
Gruß an Alle
Lichtfilter

hi,
ich habe das Gefühl, das hat jetzt wirklch nichts mehr mit meinem eigenen Topic zu tun -
mach doch bitte einen eigenen Thread zu deinem eigenen Thema auf und lösch den letzten Beitrag raus! Danke!

HaWe:
zum Flash habe ich 2 Fragen:
Ist es nicht so, dass Flashs nur begrenzt oft geschrieben werden können (nur wenige 1000 mal oder so )? Ist es dann nicht riskant, den Flash unnötig zu "belasten"? Oder findet hier keine extra Schreibaktion statt?

Du verwechselst das vielleicht mit dem EEPROM. Das geht eher kaputt. Da sind nur minimal 100.000 Schreibzyklen garantiert. Flash hält weit mehr aus.

Aber bei beiden gilt es nur das Schreiben begrenzt. Lesen geht unbegrenzt.

Und wie ist die Ausführungsgeschwindigkeit auf dem Flash? Ist der nicht viel langsamer als als aus dem RAM, was u.U. gerade bei sehr schnellen serial Ausgaben (115000 baud oder so) ziemlich bremsen kann?

Im Flash steht ja auch das Programm das ständig gelesen wird.

Daten im Flash zu speichern ist etwas langsamer, da mehr etwas Code generiert werden muss um die Daten aus dem Flash ins RAM zu kopieren. Das liegt daran das die normalen Assembler OpCodes fast alle ins RAM zeigen und es für die Flash-Behandlung nur Laden und Lesen gibt.

Das spielt aber meistens keine große Rolle. Wenn man HTML für Ethernet im Flash speichert, merkt man das es langsamer ist. Aber das ist es meistens Wert, der RAM halt so sehr begrenzt ist. String Konstanten fressen da schnell hunderte von Bytes. Es kommst ständig vor dass deswegen Programme abstürzen.

@lichtfilter

in Ermangelung von C++ - Kenntnissen weiß ich nicht wie man das Ergebnis auf den serieellen Monitor ausgeben kann.

Wirklich? Wie kannst du dann ein 30kB Programm schreiben? Was ist an Serial.println(getFreeRAM()) so kompliziert? Kann man z.B. am Anfang in setup() machen, dann sollte es das erste sein das angezeigt wird.
Gibt das freie RAM in Bytes aus. Wobei ich gelesen habe, dass die Funktion nicht ganz korrekt funktioniert wenn man dynamischen Speicher verwendet.

Wie oben gesagt, verursacht der Gebrauch von PROGMEM/PSTR()/F() systembedingt etwas mehr Code, aber das es so extrem ist war mir nicht bekannt...

Was hast du da überhaupt, dass du so viel Flash verbrauchst? Ein TFT oder LCD mit Font Definition? Das kann man eventuell kürzen, je nachdem was man davon verwendet.

@quote
In der Tat ich habe nun schon ca.45Kb Programm für Motorsteuerung geschrieben, habe aber manchmal wiklich ein Brett vor dem Kopf. Trotzdem habe ich auch dank deiner Hilfe alle meine Probleme gelöst. Der F-Operator hat wirklich viel gebracht. Da meine Fragen hier nicht reiinpassen, werde ich sie wunschgemäß wieder entfernen. Vielen Dank für Deine Hilfe.
Lichtfilter

@HaWe
Habe nun wieder einen klaren Kopf (Brett ist weg!) . Meine eigenlichen Probleme(Problemchen?) sind komplett dank eurer Hilfe gelöst.
Bis auf zwei:
Zum Einen kann ich gemäß deinem Vorschlag meine Fragen trotz Bemühen nicht in diesem Forurum wieder löschen -
zum Aderen weiß ich nicht wie man ein neues Topic aufmacht.
Nochmals Vielen Dank für eure Hilfe!
Lichtfliter

zum Löschen:
über der Linie eines jeden Posts steht ganz links:

                                                       Modify          X    Remove   <<<<<<<<<

Remove ist englisch und bedeutet "entfernen" 8)

zum neuen Topic:
über dem grünen Frame-Balken steht (s. links !)

Pages: [1] 2 3 ... 4  	                          Mark Read           Notify        >>>>  New Topic   <<<<<

new Topic ist auch Englisch (Überraschung!) und bedeutet - du ahnst es schon: "Neues Thema" 8) 8)

ist ntl nur Spaß und ist auch nicht wichtig und alles ok

  • und schön dass es gelöst ist für dich
    :smiley: