|
Anzeige
|
printf ()- Probleme
Gast
#636388
irgendwie steh ich gerade auf dem Schlauch :-)
Ich habe einen String im RAM und möchte den so ausgeben:
printf ("Test: %s ",page_buffer);
Im RAM steht es schon richtig als ASCII-Zeichen mit ner 0 hintendran,
kommt aber nur Müll raus (serielle Schnittstelle selbst funktioniert,
printf %d o.ä. funktioniert.
Probiers mal mit sprintf();
Gast
#636461
zeigt page_buffer denn auch auf den Anfang des Strings? Wie ist page_buffer definiert? Würd mich mal interessieren, wie Du stdout() umdefiniert hast...
Gast
#636499
unsigned char page_buffer[64]; Ist für einen I2C-EEPROM, der seitenweise geschrieben/gelesen wird. So, nach dem Lesen steht in page_buffer [0] "T" [1] "e" [2] "s" [3] "t" [4] 0x00 Im Rest irgendwas Und ich möchte den String über die serielle Schnittstelle senden, das sollte also "Test" erscheinen. stdout habe ich gar nicht angefasst. Irgendwie hatte ich erwartet, dass mit %s das ganze als String interpretiert wird und bis zum Null-Zeichen ausgegeben wird? crazy horse wrote: > Irgendwie hatte ich erwartet, dass mit %s das ganze als String > interpretiert wird und bis zum Null-Zeichen ausgegeben wird? Das wird es auch. Der Fehler muss in den Code Teilen stecken, die du nicht gezeigt hast. crazy horse wrote: > Irgendwie hatte ich erwartet, dass mit %s das ganze als String > interpretiert wird und bis zum Null-Zeichen ausgegeben wird? So sollte es auch sein. Was für ein Compiler und was für ein Prozessor ist das denn?
Gast
#636526
Muss EOF zwindend 0x00 sein? EOF sollte in der Library definiert sein...
Gast
#636536
Tja, welche Code-Schnipsel sollten das sein?? Mehr ist das nicht. Soll auf M16C/Renesas-Compiler laufen. Habe es jetzt gerade mal auf einem AVR probiert, da klappt es wie es soll und gedacht. Hm, das spricht ja dann für einen Compilerfehler?? Kann ich mir kaum vorstellen, werde gleich mal Glyn kontaktieren. Noch mal: printf gibt einen String an die Standard-Ausgabe (stdout) aus (Marvin hat ja schon dezent darauf hingewiesen). Wenn die nicht korrekt eingestellt ist, dann landen die Daten im Nirvana. Ein Compilerfehler ist tatsächlich kaum vorstellbar. Das hätten vermutlich andere längst gemerkt. crazy horse wrote:
> Tja, welche Code-Schnipsel sollten das sein??
Das weis ich nicht.
Ich kann, im Gegensatz zu dir, dein Programm nicht sehen
Gast
#636572
printf funktioniert ja ansonsten, auch auf dem M16. Zahlenausgaben sind
gar kein Problem, insofern bringt das mit stdout nicht wirklich was.
unsigned char page_buffer[64];
i2c_init();
for (loop=0;loop<64;loop++) page_buffer[loop]=loop; //Testdaten
read_i2c_page (0);
printf ("Das ist ein Test"); //funktioniert auf beiden Systemen
printf ("\nPage0: %s", page_buffer); //funktioniert beim AVR, beim M16
nicht
while (1)
{
};
wenn ich mir mit putchar die Bytes aus page_buffer einzeln ausgeben
lasse, funktioniert es auch auf dem M16. Insofern bleibt mit im Moment
nur der Glaube an einen Compilerfehler. Ich werde weiter berichten.
Vielleicht kennt die von Deinem Compiler verwendete printf-Variante den
Formatspezifizierer %s nicht?
Mal folgendes ausprobiert?
printf("Hallo %s!\n", "Egon");
Geht das?
crazy horse wrote: > printf funktioniert ja ansonsten, auch auf dem M16. Zahlenausgaben sind > gar kein Problem, insofern bringt das mit stdout nicht wirklich was. > > unsigned char page_buffer[64]; > i2c_init(); > for (loop=0;loop<64;loop++) page_buffer[loop]=loop; //Testdaten Hä? Du schreibst Daten von 0x00 bis 0x3F. Erstens sind da Non-ASCII-Zeichen bei (ich meine auch XON/XOFF für Software-Handshake von Terminals), und zweitens ist das ERSTE Zeichen eine 0x00! Was soll printf() da ausgeben? > read_i2c_page (0); > printf ("Das ist ein Test"); //funktioniert auf beiden Systemen > > printf ("\nPage0: %s", page_buffer); //funktioniert beim AVR, beim M16 > nicht Das ist Zufall, der Code ist in beiden Fällen Müll. Auf dem AVR wirst Du irgendeinen anderen Pointer haben. > while (1) > { > }; > > wenn ich mir mit putchar die Bytes aus page_buffer einzeln ausgeben > lasse, funktioniert es auch auf dem M16. Insofern bleibt mit im Moment > nur der Glaube an einen Compilerfehler. Ich werde weiter berichten. Meistens liegt der Fehler in dem selbstgeschriebenen Zeugs, Compiler und Librarys werden i.d.R. von mehr als einer Person benutzt... ;) T. Cfkat wrote: > ..., und zweitens ist das ERSTE Zeichen eine 0x00! Was soll > printf() da ausgeben? Nichts (einen leeren String), wenn es so arbeitet, wie es der C-Standard festlegt.
Gast
#636617
Ich habe da erst mal nur Testdaten reingeschrieben, damit ich im Debugger schneller finde, wo die stehen und bis wohin sie überschrieben werden. Ausgeben will ich, was ich mit read_i2c_page (0); lese. Und nach dem i2c-lesen stehen auch die richtigen Werte im Buffer. So richtig glaube ich ja selbst nicht an einen Compilerfehler, im Moment scheint es aber so. Jörg Wunsch wrote: > T. Cfkat wrote: > >> ..., und zweitens ist das ERSTE Zeichen eine 0x00! Was soll >> printf() da ausgeben? > > Nichts (einen leeren String), wenn es so arbeitet, wie es der > C-Standard festlegt. Das war eine rhetorische Frage... ;) @crazy horse Gib die einzelnen char mal mit for (loop=0;loop<64;loop++) printf("%x ",page_buffer[loop]); aus, dann siehst Du, was da tatsächlich drin steht... crazy horse wrote: > Und nach dem i2c-lesen stehen auch die richtigen Werte im Buffer. > So richtig glaube ich ja selbst nicht an einen Compilerfehler, im Moment > scheint es aber so. Das lässt sich mit einem Testprogramm ganz leicht abklären (danach werden dich die Compiler-Hersteller sowieso fragen und wenn du keines hast, dann wird an dem Fehler nicht gearbeitet) #include ... int main() { char test[] = "Hallo Welt"; // tu was immer du tun musst um die Ausgabe von // printf auf die Serielle umzuleiten printf( "Test: %s\n", test ); } Was liefert das? Wenn das funktioniert, dann liegt der Fehler in deinem Programm begraben. Funktioniert das schon nicht, dann kannst du dich getrost an den Compiler Hersteller wenden, denn dann hat er tatsächlich einen Bock geschossen. Antwort schreiben |
Anzeige
|
