www.mikrocontroller.net

Forum: Compiler & IDEs printf auf RS232, was genau fehlt


Autor: CAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was genau verstehst du nicht?
Steht doch alles genau beschrieben -> 
http://www.mikrocontroller.net/articles/AVR-GCC-Tu...

Autor: CAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: CAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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, ...)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: CAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@alle

verschiedene Meinungen gibt es immer.. Ich finde es jetzt besser 
verständlich.

PEACE  :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.