Hallo allerseits, mein Programm hab ich jetzt fertig geschrieben und ich
fange jetzt mit dem debuggen auf dem STK600/ATMEGA2560 an.
Bei printf fehlt mir ein Stück vom Puzzle - ich had die (erste) Uart
initialisiert,
UDR0='b';
// funktioniert, am PC kommt ein "b" an
printf("b");
// funktioniert nicht.
Ich hab im Tutorial nicht genau verstanden, welche Routine(n)? genau ich
wo einfügen muß, um die Standardausgabe auf die erste UART umzuleiten..?
Ja, ich hab das auch gelesen und mir jetzt aus anderen
Programmbeispielen die Vorgehensweise hier zusammengesucht.
Also ich hätte halt zuerst mal vermutet, daß die Standard-Aus und
Eingabe auf die Uart(für RS232) zeigt, statt ins Nirwana (Oder wohin
zeigt sie standardmäßig). Wenn das "AVR-GCC" heißt, liegt das doch
irgendwie nahe bzw. werden doch sicher > 90% der Fälle, die printf
benutzen, das so umleiten? Dateisystem/Festplatte und Monitor werden
seltenst vorhanden sein.
Dann lese ich also den ersten Absatz und es kommt ein sprintf innerhalb
einer Funktion vor, die wiederum im main aufgerufen wird, plus ein
Hinweis auf eine andere Funktion (uart_puts), wo man nicht erkennt,
wofür die gut sein soll.
Ich will als Anfänger auch nicht im Tutorial 'rumschreiben, aber als
konstruktive Kritik: Ich hätte es schöner gefunden als "Kochrezept":
Willst Du printf benutzen, mußt Du
1) Die Standardausgabe umleiten, das geht mit dieser Zeile ...
2) Eine Funktion schreiben, die ein Zeichen an die UART sendet - und
damit die Standardausgabe diese Funktion auch benutzt muß sie so
heißen...
Das steht zwar da sinngemäß beschrieben, aber wenn man dann zu der Zeile
mit FILE und stream kommt, grübelt man schon erstmal..
Und ich hätte das zweite Beispiel (printf und Ausgabeumleitung) zuerst
genannt.
CAnfänger wrote:
> Also ich hätte halt zuerst mal vermutet, daß die Standard-Aus und> Eingabe auf die Uart(für RS232) zeigt, statt ins Nirwana (Oder wohin> zeigt sie standardmäßig).
Hätt ich nicht vermutet.
Warum Uart, warum nicht LCD?
Die meisten meiner µC-Anwendungen haben zwar ein LCD aber keine UART
Wie ist das mit der Baudrate, welche soll benutzt werden, wer stellt die
ein? Willst du nur senden oder auch empfangen? (Grade in einem anderen
Thread: Der Programmierer will nur senden, weil er den Empfangspin als
normalen Eingang braucht. Nur blöd, dass ihm BASCOM da keine einfache
Möglichkeit bietet, die Uart Komponente auf 'Nur Senden' zu stellen.)
Was ist mit Handshake? Einstellung der Stopbits?
> Dann lese ich also den ersten Absatz und es kommt ein sprintf innerhalb> einer Funktion vor, die wiederum im main aufgerufen wird, plus ein> Hinweis auf eine andere Funktion (uart_puts), wo man nicht erkennt,> wofür die gut sein soll.
DU kannst nicht erkennen, wozu das gut sein soll.
Wenn du das Tutorial von oben durch gemacht hättest und das Kapitel über
Uart studiert hättest, wär dir die Funktion bekannt vorgekommen.
Wenn du über normale C-Basisgrundlagen verfügen würdest, dann würdest du
die Funktion puts aus der Standardlibrary kennen und in weniger als 1
Sekunde auf den Gedanken verfallen, dass uart_puts wohl sowas wie puts
für die Uart sein wird.
> Das steht zwar da sinngemäß beschrieben, aber wenn man dann zu der Zeile> mit FILE und stream kommt, grübelt man schon erstmal..
Das Tutorial ist nicht dafür gedacht, absoluten Neueinsteigern in C die
Grundlagen der Sprache beizubringen (auch wenn es mittlerweile
phasenweise dahin ergänzt wurde). Das Tutorial setzt ein gewisses
C-Basiswissen voraus und geht auf die Besonderheiten bei der
Programmierung von AVRs ein.
Sorry, aber sprintf ist eine Basis-C Funktion, die in jedem Lehrbuch
über C abgehandelt wird (gleich nachdem über Stringverarbeitung
referiert wird).
Wenn der Anspruch des Tutorials dahingehend geändert werden würde,
absoluten Neueinsteigern auch noch die Grundlagen von C beizubringen,
dann wäre es nämlich 15 mal so lang. Und über die Sinnhaftigkeit braucht
man dann auch nicht mehr diskutieren. Es ist sinnlos, hier Dinge in ein
Tutorial zu packen, die dir in einem von 20 verschiedenen Büchern, die
du um die Ecke in der nächsten Buchhandlung kaufen kannst, wesentlich
besser erklärt werden können.
Und zu guter letzt:
printf ist in den meisten µC Anwendungen ganz einfach Overkill. Wenn man
im Speicher genug Platz hat, ist es ok. Aber in den meisten Fällen
benötigt man genau 2 Funktionalitäten: einen String ausgeben; einen int
ausgeben. Dafür reichen 2 Funktionen und die eierlegende Wollmilchsau
printf kann in ihrem Stall bleiben. Ditto für sprintf. Wobei sprintf
noch den Vorteil hat, dass man dieselbe Funktionalität auch für LCD oder
sonstige Ausgaben benutzen kann, wenn man das Prinzip 'erst einen String
generieren, dann entscheiden was mit dem String geschehen soll' erst mal
verstanden hat. In diesem Sinne ist sprintf also die universellere
Lösung.
>Warum Uart, warum nicht LCD?
na weil die UART meist im Chip eingebaut ist, LCD nur beim Butterfly.
Und am häufigsten benutzt wird wohl 9600,8,n,1
>Das Tutorial ist nicht dafür gedacht, absoluten Neueinsteigern in C die
Grundlagen der Sprache beizubringen
Ok, aber ich denke, die Anfänger, die hier ankommen, sind halt neu im
Fach uC und in C, da ist es schon schön, wenn es etwas pragmatischer
aufgearbeitet ist und man schneller ein Erfolgserlebnis hat. Debuggen
mit printf ist häufig so ziemlich das Erste, was man tut, nachdem man
die LED blinken lassen hat..
Ich bin nicht der Meinung, daß man analytisch alles zur UART und zur
Standardausgabe in C durchgekaut haben sollte, nur um sich "Hello world"
am Terminal anzeigen zu lassen. Man kann es auch umgekehrt lernen
(erstmal empirisch, spielend, ...)
CAnfänger wrote:
>>Warum Uart, warum nicht LCD?>> na weil die UART meist im Chip eingebaut ist, LCD nur beim Butterfly.> Und am häufigsten benutzt wird wohl 9600,8,n,1
Du bist noch nicht lange bei den µC, stimmst.
Bei einer UART kann so viel schief gehen, das kannst du dir nicht
vorstellen. Das geht von falsch beschalteten MAX232 bis hin zu falsch
konfektionierten Kabeln oder falschen Einstellungen auf PC Seite. Das
Forum hier ist voll mit Problemen bei der UART Konfiguration.
> Ok, aber ich denke, die Anfänger, die hier ankommen, sind halt neu im> Fach uC und in C, da ist es schon schön, wenn es etwas pragmatischer> aufgearbeitet ist und man schneller ein Erfolgserlebnis hat. Debuggen> mit printf ist häufig so ziemlich das Erste, was man tut, nachdem man> die LED blinken lassen hat..
Wenn du als Anfänger in der µC Szene auf eine funktionierende UART als
Debug-Werkzeug setzt, hast du mit Zitronen gehandelt :-)
CAnfänger wrote:
> Also ich hätte halt zuerst mal vermutet, daß die Standard-Aus und> Eingabe auf die Uart(für RS232) zeigt, statt ins Nirwana (Oder wohin> zeigt sie standardmäßig). Wenn das "AVR-GCC" heißt, liegt das doch> irgendwie nahe bzw. werden doch sicher > 90% der Fälle, die printf> benutzen, das so umleiten? Dateisystem/Festplatte und Monitor werden> seltenst vorhanden sein.
Du kannst dir ein Rumpfprogramm machen, bei dem das so ist. Derzeit ist
die AVR-LIBC so dikumentiert und implementiert, dass stdout nicht per
Voreinstellung auf irgendwas gerichtet ist. Dadurch ist es u.a. auch
möglich die Library klein zu halten. Es wird nicht per Voreinstellung
eine Ausgabefunktion hinzugebunden, die der Anwender später nicht
braucht. Wenn der Anwender eine Funktion z.B. für UART braucht, stellt
er die bereit und klinkt die ein.
> Dann lese ich also den ersten Absatz und es kommt ein sprintf innerhalb> einer Funktion vor, die wiederum im main aufgerufen wird, plus ein> Hinweis auf eine andere Funktion (uart_puts), wo man nicht erkennt,> wofür die gut sein soll.
Ich habe den Text behutsam umgeschrieben und hoffe das Vorgehen wird
klarer.
> Ich will als Anfänger auch nicht im Tutorial 'rumschreiben, aber als> konstruktive Kritik: Ich hätte es schöner gefunden als "Kochrezept":
Lobenswert!
> Willst Du printf benutzen, mußt Du>> 1) Die Standardausgabe umleiten, das geht mit dieser Zeile ...> 2) Eine Funktion schreiben, die ein Zeichen an die UART sendet - und> damit die Standardausgabe diese Funktion auch benutzt muß sie so> heißen...>>> Das steht zwar da sinngemäß beschrieben, aber wenn man dann zu der Zeile> mit FILE und stream kommt, grübelt man schon erstmal..
Ich habe den Text behutsam umgeschrieben und hoffe das Vorgehen wird
klarer. ABER: C sollte dem Leser des AVR-GCC-Tutorials bereits
bekannt sein. Das Konzept der STREAMs ist in C essentiell und sollte den
Leser hier eigentlich nicht überraschen.
> Und ich hätte das zweite Beispiel (printf und Ausgabeumleitung) zuerst> genannt.
Aus den Gründen, die Karl heinz Buchegger schon genannt hat, sehe ich
das anders. OK, man kann das besser strukturieren (s. Tutorial jetzt)
CAnfänger wrote:
> Ich bin nicht der Meinung, daß man analytisch alles zur UART und zur> Standardausgabe in C durchgekaut haben sollte, nur um sich "Hello world"> am Terminal anzeigen zu lassen. Man kann es auch umgekehrt lernen> (erstmal empirisch, spielend, ...)
Das ist sehr schwer, weil es davon abhängt, wie der Leser lernt.
Ein Typ ("Hörsaal, dann Seminar") will zunächst alles Notwendige wissen
und dann am Beispiel nachvollziehen. Es ist allerdings schwer diese
Infos umfassend im Tutorial unterzubringen, weil es oft bedeuten würde,
Datenblätter abzutippen.
Ein anderer Typ ("Bastler") will zuerst das Beispiel, um dann die
Erklärungen dazu und bei Gelegenheit zieht er sich vielleicht die
komplette Beschreibung rein.
Das Tutorial ist ein Mix für diese beiden Extreme. Ich versuche meistens
im Beispiel so viele Kommentare zu geben, damit der Typ II mit dem
Beispiel zurecht kommt und neugierig auf den Rest wird. Das kann den Typ
I nerven.
Du bist eingeladen hier im Forum mitzuarbeiten und Schritt für Schritt
das Tutorial verständlicher zu machen.
