sprintf im debug modus

Sprichst du hier von Simulation oder ICD?
Das wird mir nicht so richtig klar.

Gruß Skriptkiddy

Damit [1] kann man einen UART simulieren und auch Ausgaben 
darufschicken. Spielt ohne Problme mit AVRStudio zusammen. CVAVR kenne 
ich nicht. Müsste man mal schauen, ob es damit auch möglich ist.

[1]http://www.helmix.at/hapsim/

Gruß Skriptkiddy

> Mit dem Keil uVision Studio klappt es, aber da habe ich probleme
> beim Import von meinen AVR-Libs.
**verwirrt**

Keil µVision kann Code für 8051, C166 und ARM übersetzen - keinen AVR 
code.

Was meinst du mit "Message Box" ? Das UART oder Printf - Window?

Für die UARTs existiert eine Simulation, darum siehst du da die Zeichen 
und kannst eintippern.

Für ITM printf gibt es ebenfalls eine Simulation, und im Target Mode 
werden die ITM printf Daten (falls im Debugger (ULINK, JLink) 
konfiguriert), auch im printf Window ausgegeben.

Das printf da rauskommt, liegt am retargeting. Entweder fputc() 
überladen, oder auf unterster Ebene (vgl. retarget.c).


VG,
/th.

M.W. klar: nein

Du hast auf einem AVR kein stdout, solange du es dir nicht baust.
sprintf() kannst du natürlich aufrufen, aber das schreibt ja nur
in einen String (char[]).

printf() gibt es auch, aber dazu muß man vorher stdout definieren.
Das wiederum geht damit: 
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html#gab599ddf60819df4cc993c724a83cb1a4

Wo soll ein AVR eine Datei haben?

Nein, das heißt, daß du eine Funktion schreiben musst, die
ein Zeichen ausgibt (wohin auch immer du es haben willst: UART,
LCD, ...) und diese Funktion als Parameter get an fdevopen()
übergibst.
Ab dann kannst du mit printf(), puts(), putchar() etc. auf
die jetzt existierende Standardausgabe schreiben und
alles läuft über deine eigene Funktion, Zeichen für Zeichen.

Wenn du diese eigene Funktion dazu bringst, in eine Datei zu
schreiben, dann landet stdout dort.

Mischa schrieb:
> Geht das auch so einfach mit AVR-Studio?
Nein das geht nicht. Und mit sprintf alleine schon garnicht. Du solltest 
dir mal ein C-Buch zu Gemüte führen. Dann wird vieles hier im Thread 
bereits Erwähnte wesentlich klarer.


Schau mal hier:
AVR-GCC-Tutorial/Der UART

An uart_puts übergibst du dann nach dem Initialisieren des UART die 
Zeichenkette, die mit sprintf erstellt wurde. Und schon sollte die 
in hapsim zu sehen sein. Versuche aber der Einfachheit halber zuerst den 
UART an sich in Betrieb zu nehmen. Am besten in einem eigenen Projekt. 
Wenn du dann Text im hapsim siehst, dann kannst du die Routinen in dein 
jetziges Projekt integrieren.

Wenn du aber blos Variableninhalte sehen willst, dann reicht prinzipiell 
schon ein "watch". Printf-Debugging lohnt sich IMHO erst, wenn du in der 
Schaltung debuggen willst.


Gruß Skriptkiddy

>  - in Keil uVision mit sprintf()

wie?

LOL, da wird ein printf retargeting über den 8051 Monitor gemacht :-)

Der µVision Debugger hat sogar Fenster, mit denen man sich die Werte von 
Variablen ganz bequem ansehen kann, ohne so verrückte Umwege :-)

Ich denke nicht, dass das geht.
Die Frage ist doch: Bietet AVR-Studio eine Schnittstelle an, mit der man 
ins Output Fenster schreiben kann. Wenn ja, könnte man eventuell eine 
put Funktion patchen, so dass sie das tut und dieses mittels fdevopen 
einer Debug-Version unterjubeln.
Das Problem ist, dass das so nicht gehen wird, denn dein Programm 
arbeitet ja in einem simuliertem AVR, der nicht so einfach auf seinen 
Host, eben das AVR-Studio duchgreifen kann.
So eng ist WinAVR dann auch wieder nicht in AVR-Studio integriert. Da 
müsste der Simulator wesentlich mehr über WinAvr und seinen C-Code 
wissen, damit er zb Schreibzugriffe auf eine ganz bestimmte 
Speicherzelle abfängt und als Ausgaben auf sein eigenes Output Fenster 
interpretiert.

Random ... schrieb:
> LOL, da wird ein printf retargeting über den 8051 Monitor gemacht :-)
>
> Der µVision Debugger hat sogar Fenster, mit denen man sich die Werte von
> Variablen ganz bequem ansehen kann, ohne so verrückte Umwege :-)

Oh. So verrückt ist das gar nicht.
Im VC++ Dev Studio ist das genau die Funktionalität die man mit den 
TRACE Makros erreicht, die ich zur Zeit gerade extensiv nutze, um eine 
Geometrieoperation zu debuggen :-)
Entweder man hat sowas, wie eine Ausgabefläche, auf der man einfach 
ausgeben kann, oder es ist Handarbeit mit Papier und BLeistift angesagt 
um sich einen Log der Veränderungen an den Daten zu machen.

Mischa schrieb:
> so: http://et-tutorials.de/1156/c-syntax-getchar-und-prinf/

Da wird printf verwendet. Und das geht auch nur so ohne Weiteres, weil 
sich der Compiler um die stdio kümmert. Printf zielt IMHO beim Keil C51 
ohne eigenes Retargeting auf den UART.

Gruß Skriptkiddy

> Im VC++ Dev Studio ist das genau die Funktionalität die man mit den
> TRACE Makros erreicht,

klar, benutze ich auch sehr oft, meist in Verbindung mit GetTickCount().

Nur - es ist recht mühsam und Codebeeinflussend, ein printf-debugging zu 
machen, mühsamer, als sich das schnell in einem der Fenster anzeigen zu 
lassen, oder sogar im Logic Analyzer zu visualisieren.

Daher "ohne so verrückte Umwege".
Printf-Debugging gehört zu meinen C-Einsteigersünden, als ich noch 
keinen Debugger hatte und einfach nur per MISO/MOSI meinen Code in den 
AVR geballert und am UART printf-gedebugt hab :-)


VG,
/th.

Klaus Wachtler schrieb:
> Nein, das heißt, daß du eine Funktion schreiben musst, die
> ein Zeichen ausgibt (wohin auch immer du es haben willst: UART,
> LCD, ...) und diese Funktion als Parameter get an fdevopen()
> übergibst.

Ich meinte natürlich put (und nicht get).

Random ... schrieb:
> Printf-Debugging gehört zu meinen C-Einsteigersünden, als ich noch
> keinen Debugger hatte und einfach nur per MISO/MOSI meinen Code in den
> AVR geballert und am UART printf-gedebugt hab :-)

ok, dann bin ich auch Einsteiger.
Ich mache das bei Bedarf nach wie vor so, und habe nicht mal
ein schlechtes Gewissen.

Wenn mehrere Sachen gleichzeitig passieren, ist ein Debugger
auch nur bedingt hilfreich und verfälscht oft das Zeitverhalten.