printf ()- Probleme

Probiers mal mit
sprintf();

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?

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

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.

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.