Hi! Ich habe zwei Probleme mit dem WinAVR. Egal wie ich die \r\n in einem über Serielle auszugebenden String verteile, ich lande immer eine Zeile zu tief. Ich habe den Eindruck, dass der WinAVR eigenständig ein \n anhängt, wenn man keines vorgibt. Meine U(S)ART Routinen tun es jedenfalls nicht. Das Problem zeigt sich besonders ärgerlich, wenn man im terminal eine Kommandozeile realisieren möchte und daher eine Schleife programmiert, die den Eingabe-String auswertet und hinterher wieder etwas wie AVR>_ ausgeben soll. Bei mir steht dann der Cursor immer eine Zeile unter dem AVR> aber genau an der Position rechts neben dem >. Ja, ich habe alle Optionen auf der Terminalseite sowohl bei HyperTerm, HTerm als auch diversen anderen Terminals ausprobiert. Wenn ich "AVR>\n\r" setze, lande ich (wie erwartet) eine Zeile tiefer, wenn ich "\r\nAVR>" mache, lande ich eine Zeile zu tief und wenn ich "\rAVR>" mache, dann lande ich auch eine Zeile zu tief aber versetzt. Die zweite Frage geht in Richtung Optimierung. Gibt es eine 'einfache' Übersicht, welche Teile der avrlibc man wann braucht und, wie man ggf. nicht Erwünschtes deaktiviert? Bislang kann ich kein Programm unter 4k erzeugen, obwohl ich schon für das ein oder andere Projekt mit einem AVR kleiner als Mega8 liebäugelen würde. Danke schon mal im Voraus Ulrich
Ulrich P. wrote: > Hi! > > Ich habe zwei Probleme mit dem WinAVR. Egal wie ich die \r\n in einem > über Serielle auszugebenden String verteile, ich lande immer eine Zeile > zu tief. Ich habe den Eindruck, dass der WinAVR eigenständig ein \n > anhängt, wenn man keines vorgibt. Meine U(S)ART Routinen tun es > jedenfalls nicht. WinAvr tut es auch nicht. > Ja, ich habe alle Optionen auf der Terminalseite sowohl bei HyperTerm, > HTerm als auch diversen anderen Terminals ausprobiert. Wenn ich > "AVR>\n\r" setze, lande ich (wie erwartet) eine Zeile tiefer, wenn ich > "\r\nAVR>" mache, lande ich eine Zeile zu tief und wenn ich "\rAVR>" > mache, dann lande ich auch eine Zeile zu tief aber versetzt. Schau dir das alles noch mal durch. \n ist ein Newline. Newline bedeutet, dass der Cursor um eine Zeile nach unten vorgerückt wird \r ist der Carriage Return. Carriage Return bedeutet, dass der Cursor an den Zeilenanfang gesetzt wird. Wenn du also in derselben Zeile bleiben willst, dann ist die 'nur \r Lösung' die richtige. Voraussetzung ist allerdings, dass die Terminalsoftware das ebenso sieht und nicht eigenmächtig zu dem \r noch ein \n ergänzt (das ist aber im Normalfall konfigurierbar). Im Übrigen: Wenn du eine bessere Steuerung des Terminals willst, dann wirst du um die ANSI Escape Sequenzen nicht umhinkommen. So gut wie jedes Terminal versteht sie oder zumindest den sog. VT100 Escape Sequenzen Satz. > > Die zweite Frage geht in Richtung Optimierung. Gibt es eine 'einfache' > Übersicht, welche Teile der avrlibc man wann braucht Je nachdem was du programmierst, wird das eine oder andere oder sogar alles zusammen gebraucht. > und, wie man ggf. > nicht Erwünschtes deaktiviert? Mach dir deswegen keine Sorgen. Der Linker holt sich aus der Library nur die Teile, die auch tatsächlich in deinem Programm vorkommen.
Ulrich P. wrote: > Bislang kann ich kein Programm unter 4k erzeugen, obwohl ich schon > für das ein oder andere Projekt mit einem AVR kleiner als Mega8 > liebäugelen würde. Lass alles weg, was in stdio.h aufgeführt ist. Insbesondere die printf-Varianten sind ausgesprochen teuer. Auch auf dynamische Speicherverwaltung kann und sollte man verzichten.
Hi! Welche Funktion \n und \r haben, ist mir durchaus klar. Deswegen weiß ich ja auch, welche Optionen ich in einem Terminalprogramm setzen muss, damit eben an \r nicht automatisch ein \n angehangen wird. Also noch einmal: [c] while(1) { puts_P(PSTR("\r\nAVR>")); get_command(&cmds, &cmdl); cmdp = cmds; switch(*cmdp++) ... } Die Zeile puts_P(...) gibt das besagte AVR> aus. Die Absicht dahinter ist, dass man bei den ganzen Kommandos und deren Ausgaben mind. 1 \r\n einsparen kann. Die neue Zeile kommt automatisch nach der Abarbeitung. Man sollte erwarten, dass der Cursor nach der obigen Ausgabe hinter dem AVR> steht. Tut er aber nicht, sondern er landet eine Zeile unter und hinter dem >. X-Position stimmt also, aber Y sind wir zu tief. Tja und das dusselige Hyperterminal ist richtig eingestellt, denn das \n ist in dem guten HTERM deutlich zu sehen... Gruß, Ulrich
RTFM. "puts writes the null-terminated string pointed to by s, followed by a newline character, to the standard output stream called stdout" fputs übrigens nicht.
Andreas Kaiser wrote: > RTFM. > > "puts writes the null-terminated string pointed to by s, followed by a > newline character, to the standard output stream called stdout" > > fputs übrigens nicht. Autsch... danke, der Tritt war gerechtfertigt! Gruß, Ulrich
Bitte 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.