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..?
Was genau verstehst du nicht? Steht doch alles genau beschrieben -> http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Die_Nutzung_von_printf
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.
@alle verschiedene Meinungen gibt es immer.. Ich finde es jetzt besser verständlich. PEACE :-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.