(volatile) String vergleichen

[AVR-Anfänger (Gast)]

Hallo, ich bin gerade dabei mich in AVR-GCC einzuarbeiten (Atmel 
Studio).

Ich bin dabei einen String über UART einzulesen(Volatile Variable) und 
diesen dann zu verarbeiten. Um die verschieden Befehle zu unterscheiden 
nutze ich "strcmp".

Der Compiler bringt mir anschließend folgende Meldung:

"Warnung  11  passing argument 1 of 'strcmp' discards 'volatile' 
qualifier from pointer target type [enabled by default]"

gibt es eine bessere Möglichkeit den String auszuwerten?

[Karl H. (kbuchegg)]

AVR-Anfänger schrieb im Beitrag #4055258:

> gibt es eine bessere Möglichkeit den String auszuwerten?

Nein.
An dieser Stelle ist es höchst wahrscheinlich ok, wenn du das volatile 
wegcastest.

volatile char input[40];

....



    if( strcmp( (char*)input, "Befehl" ) == 0 ) {
      ...

[Frank M. (ukw) (Moderator)]

AVR-Anfänger schrieb im Beitrag #4055258:
> "Warnung  11  passing argument 1 of 'strcmp' discards 'volatile'
> qualifier from pointer target type [enabled by default]"

Der Compiler will dir damit sagen, dass strcmp() nicht berücksichtigt, 
dass der String volatile ist und sich während des Vergleichs ändern 
könnte.

Die Warnung bekommst Du weg, indem Du den String in ein (char *) 
castest, also:

    int x = strcmp ((char *) str, "Hallo");

[AVR-Anfänger (Gast)]

Ja, den Sinn der Meldung habe ich verstanden. Könnte durch das casten 
Probleme auftreten?

Am liebsten wäre mir die Switch Case Anweisung, aber leider fkt diese 
nur mit Integern :/

[Frank M. (ukw) (Moderator)]

AVR-Anfänger schrieb im Beitrag #4055275:
> Ja, den Sinn der Meldung habe ich verstanden. Könnte durch das casten
> Probleme auftreten?

Erstmal nicht. Aber wenn sich der String wirklich während des Vergleichs 
ändern könnte (z.B. wegen ISR), dann ist das suboptimal. Besser wäre es 
dann, den entsprechenden Interrupt vor dem Vergleich ab- und nachher 
wieder einzuschalten.

[Karl H. (kbuchegg)]

AVR-Anfänger schrieb:
> Ja, den Sinn der Meldung habe ich verstanden. Könnte durch das casten
> Probleme auftreten?

Theoretisch: ja
FAQ: Was hat es mit volatile auf sich

Praktisch ist es unwahrscheinlich, weil derartige Programme meist 
umfangreich genug sind, dass der Optimizer nicht zuschlagen wird.


Man kann sich natürlich auch sein eigenes strcmp schreiben, welches das 
volatile in der Argumentliste hat.

uint8_t strvcmp( volatile const char* str1, volatile const char* str2 )
{
  while( *str1++ == *str2++ )
    ;

  return *str1 - *str2;
}

[Karl H. (kbuchegg)]

Frank M. schrieb:
> AVR-Anfänger schrieb:
>> Ja, den Sinn der Meldung habe ich verstanden. Könnte durch das casten
>> Probleme auftreten?
>
> Erstmal nicht. Aber wenn sich der String wirklich während des Vergleichs
> ändern könnte

Dabei gehts bei volatile gar nicht.
FAQ: Was hat es mit volatile auf sich

Das sich der String während der Arbeit mit ihm ändern könnte, ist eine 
davon losgelöste Problematik und wird von volatile nicht abgedeckt oder 
angesprochen.

[Frank M. (ukw) (Moderator)]

Karl Heinz schrieb:
> Man kann sich natürlich auch sein eigenes strcmp schreiben, welches das
> volatile in der Argumentliste hat.

Wahrscheinlich hat er so etwas ähnliches wie einen Ringbuffer, auf den 
er direkt den strcmp() loslassen will. Das halte ich für nicht korrekt. 
Besser wäre es, den String aus dem Ringbuffer zeichenweise zu 
extrahieren und auf das Resultat den strcmp() anzuwenden.

Aber das ist alles Spekulation. Besser wäre es, wenn der TO seinen 
Source (wenigstens auszugsweise) hier vorstellt.

[AVR-Anfänger (Gast)]

hier ein auszug aus meinem Quellcode:

ISR(USART1_RX_vect)
{
  volatile unsigned char nextChar;
  
  // Daten aus dem Puffer lesen
  nextChar = UDR1;
  if( uart_str_complete == 0 ) {      
    if( nextChar != '\n' &&
    nextChar != '\r' &&
    uart_str_count < UART_MAXSTRLEN ) {
      uart_string[uart_str_count] = toupper(nextChar);       uart_str_count++;
    }
    else {
      uart_string[uart_str_count] = '\0';
      uart_str_count = 0;
      uart_str_complete = 1;
    }
  }
  if (uart_str_complete ==1){uart1_auswerten();}
}

void uart1_auswerten(void){
    char tStr_1[10];
    char tStr_2[5];
    char tStr_3[5];
    uint32_t obergrenze =0xFFFF;
    
    char uart_temp[UART_MAXSTRLEN+1];

    //uart_string=toupper(uart_string);
    uart_str_complete = 0;
    strcpy(uart_temp,(char*)uart_string);
    uart_puts(strcat(uart_temp, ":"));

    if (strcmp((char*)uart_string,"RED")==0) //(char*) verhindert compiler warnung
    {
      uart_puts(strcat(itoa(get_color("RED"),string_seriel,10),CR));
    }
    if (strcmp((char*)uart_string,"GREEN")==0)
    {
      uart_puts(strcat(itoa(get_color("GREEN"),string_seriel,10),CR));
    }
    if (strcmp((char*)uart_string,"BLUE")==0)
    {
      uart_puts(strcat(itoa(get_color("BLUE"),string_seriel,10),CR));
    }
}

[Karl H. (kbuchegg)]

AVR-Anfänger schrieb:
> hier ein auszug aus meinem Quellcode:

In dem kommt nur ein einziges volatile vor. Und genau dieses brauchst du 
nicht.

Lies dir das mal durch
FAQ: Was hat es mit volatile auf sich
dann verstehst du auch, welche volatile du brauchst und welche nicht.

[Frank M. (ukw) (Moderator)]

AVR-Anfänger schrieb im Beitrag #4055288:
> hier ein auszug aus meinem Quellcode:
>

> ISR(USART1_RX_vect)
> {
>   ...
>   if (uart_str_complete ==1){uart1_auswerten();}
> }
> 
> void uart1_auswerten(void){
> {
>   ...
>     if (strcmp((char*)uart_string,"RED")==0) //(char*) verhindert 
> compiler warnung
> }
>

Wenn Du uart_string nur in einer Funktion nutzt, die ausschließlich von 
der ISR() aufgerufen wird, ist das volatile komplett überflüssig. Also 
streiche es.

[Karl H. (kbuchegg)]

Wenn du dir hier

    strcpy(uart_temp,(char*)uart_string);

den String sowieso schon umkopiert hast, warum verwendest du dann nicht 
in weiterer Folge überall die Kopie?

[Karl H. (kbuchegg)]

Frank M. schrieb:
> AVR-Anfänger schrieb im Beitrag #4055288:
>> hier ein auszug aus meinem Quellcode:
>>

>> ISR(USART1_RX_vect)
>> {
>>   ...
>>   if (uart_str_complete ==1){uart1_auswerten();}
>> }
>>
>> void uart1_auswerten(void){
>> {
>>   ...
>>     if (strcmp((char*)uart_string,"RED")==0) //(char*) verhindert
>> compiler warnung
>> }
>>

>
> Wenn Du uart_string nur in einer Funktion nutzt, die ausschließlich von
> der ISR() aufgerufen wird, ist das volatile komplett überflüssig. Also
> streiche es.

Einspruch.
Die Auswertung sollte dort überhaupt nicht sein.
Die gehört da so nicht rein. Alles was nicht mehr wirklich trivial ist, 
hat in einer ISR nichts mehr verloren.

[Frank M. (ukw) (Moderator)]

Karl Heinz schrieb:
>> Wenn Du uart_string nur in einer Funktion nutzt, die ausschließlich von
>> der ISR() aufgerufen wird, ist das volatile komplett überflüssig. Also
>> streiche es.
>
> Einspruch.
> Die Auswertung sollte dort überhaupt nicht sein.

Da hast Du natürlich recht. Eine ISR sollte sich schnellstmöglich 
beenden. Ich wollte mit dem obigen Satz nur das Prinzip verdeutlichen 
und die Betonung dabei auf das Wort "ausschließlich" legen. Ich habe von 
"Nutzung" gesprochen und habe keine Wertung über seine Art der Nutzung 
getroffen ;-)

> Die gehört da so nicht rein. Alles was nicht mehr wirklich trivial ist,
> hat in einer ISR nichts mehr verloren.

Korrekt.

[Frank M. (ukw) (Moderator)]

Der Source hat noch ganz andere Schwächen - abgesehen vom
String-Parsen in einer Funktion, die von einer ISR aufgerufen wird:

Ab dem zweiten "if (strcmp ...)" sollte der TO ein "else"
davorschreiben, damit der arme µC nicht weiter jeden möglichen String
checkt, obwohl er ihn längst gefunden hat.

Die uart_puts()-Aufrufe sind ein absolutes NoGo, wenn man sich noch im 
Interrupt befindet.

@TO: Du solltest den String in der ISR lediglich speichern, aber besser 
im Hauptprogramm auswerten. Dann braucht man natürlich wieder einen 
volatile Buffer für den String.

[Karl H. (kbuchegg)]

Frank M. schrieb:

> Ab dem zweiten "if (strcmp ...)" sollte der TO ein "else"
> davorschreiben, damit der arme µC nicht weiter jeden möglichen String
> checkt, obwohl er ihn längst gefunden hat.
>
> Die uart_puts()-Aufrufe sind ein absolutes NoGo, wenn man sich noch im
> Interrupt befindet.

Nicht nur das.
Das ganze Prinzip, zuerst einen einzelnen String zusammen zu setzen, um 
ihn dann in einem Rutsch auszugeben, ist nichts anderes als 
Fleissaufgabe für den µC. Es gibt keinen Grund dafür. Der Empfänger kann 
nicht unterscheiden, ob der String vom Sender in einem Rutsch 
'aufgegeben' wurde, oder ob da mehrere Sende Funktionen beteiligt waren.

* Aufbauend auf uart_puts sollte er sich erst mal eine Funktion 
uart_puti schreiben, damit er in der Verwendung nicht dauernd die itoa 
hat

void uart_puti( int wert )
{
  char txt[8];
  itoa( wert, txt, 10 );
  uart_puts( txt );
}

* dann sollte er die eigentliche Aufgabe aufteilen. Anstatt des Monsters

      uart_puts(strcat(itoa(get_color("RED"),string_seriel,10),CR));

sollte da stehen

      uart_puti( get_color("RED") );
      uart_putc( CR );

und bingo: kein Mensch braucht da noch einen strcat, was erstes Zeit 
spart und zweitens die Gefahr eines Buffer Overruns eliminiert.

Ob get_color wirklich einen String braucht um die Farbe anzugeben, ist 
auch fraglich. Aber sagen wir mal, das stimmt so. Dann so

void uart1_auswerten(void)
{
  char uart_temp[UART_MAXSTRLEN+1];
  int ColorValue;

  strcpy(uart_temp,(char*)uart_string);  // Reihenfolge! zuerst den String in Sicherheit bringen
  uart_str_complete = 0;                 // dann die UART wieder freigeben

  uart_puts( uart_temp );
  uart_puts( " : " );

  ColorValue = get_color( uart_temp );  // soll -1 bei einer unbekannten Farbe liefern!
  if( ColorValue == -1 )
    uart_puts( " Unbekannt" );
  else
    uart_puti( ColorValue );

  uart_putc( CR );
}

Der/Die einzige(n) strcmp, die jetzt noch vorkommen, stecken in 
get_color

[Daniel A. (daniel-a)]

Karl Heinz schrieb:
> uint8_t strvcmp( volatile const char* str1, volatile const char* str2 )
> {
>   while( *str1++ == *str2++ )
>     ;
>
>   return *str1 - *str2;
> }

Perfekt, der rückgabewert kann hier nie 0 sein, und nen Bufferoverflow 
hat man meistens auch noch, Genial!

Besser noch die Nullterminierung prüfen und den letzten Index 
korrigieren, dann stimmts wieder:

while( *str1 && *str1++ == *str2++ );
return str1[-1] - str2[-1];

[Karl H. (kbuchegg)]

Daniel A. schrieb:

> Besser noch die Nullterminierung prüfen und den letzten Index
> korrigieren, dann stimmts wieder:

Danke. Schuldig in allen Punkten.

Man sollte nicht vor dem ersten Kaffee Codeschnipsel aus dem Ärmel 
schütteln.

[Karl H. (kbuchegg)]

Daniel A. schrieb:

> dann stimmts wieder:
>

> while( *str1 && *str1++ == *str2++ );
> return str1[-1] - str2[-1];
>

Auch noch nicht richtig.
Stell dir einfach einen Aufruf

    strcmp( "", "" );

vor, dann ist schnell klar, dass die Indexkorrektur falsch ist.

So rum ists dann auch richtig

  while(*s1 && (*s1==*s2)) {
    s1++;
    s2++;
  }

  return *s1-*s2;
}

[Frank M. (ukw) (Moderator)]

Karl Heinz schrieb:
>

> uint8_t strvcmp( volatile const char* str1, volatile const char* str2 )
> {
>   ....
>   return *str1 - *str2;
> }
>

uint8_t passt auch nicht mit dem Return-Wert zusammen.

Beide Argumente als volatile zu definieren ist auch ziemlich 
kontraproduktiv.

Alles in allem: Streichen :-)

[AVR-Anfänger (Gast)]

Vielen Dank erstmal für die ganzen Hinweise, TOP! ich werde diese in 
meinen Code einbauen und mich bei weiteren Fragen melden :)

[AVR-Anfänger (Gast)]

ich habe jetzt alles umgesetzt und es funktioniert alles.

Ich habe in der uart_puti() Funktion die ITOA Funktion durch die sprintf 
Funktion ersetzt, dadurch kann ich die Zahlenwerte immer im gleichen 
Format mit vorgestellten Nullen ausgeben. Ist das so konform?

[Frank M. (ukw) (Moderator)]

AVR-Anfänger schrieb im Beitrag #4055567:
> ich habe jetzt alles umgesetzt und es funktioniert alles.

Vielleicht postest Du nochmal das Ergebnis? Denn eines sollte man sich 
merken: Programmcode wird eigentlich nie fertig :-)

> Ich habe in der uart_puti() Funktion die ITOA Funktion durch die sprintf
> Funktion ersetzt, dadurch kann ich die Zahlenwerte immer im gleichen
> Format mit vorgestellten Nullen ausgeben. Ist das so konform?

sprintf() benötigt bedeutend Flash-Speicher als itoa(). Wenn Du aber 
genügend davon zur Verfügung hast, ist das vollkommen in Ordnung.

[Karl H. (kbuchegg)]

Frank M. schrieb:

> uint8_t passt auch nicht mit dem Return-Wert zusammen.

Wenn man nicht dieselbe Semantik wie strcmp braucht sondern nur auf 0 
oder nicht-0 geht, dann passt das schon.

> Beide Argumente als volatile zu definieren ist auch ziemlich
> kontraproduktiv.

Ähm. Das volatile war genau der Grund, warum eine eigene Funktion 
vorgschalgen wird. Damit man nicht beim Aufruf von strcmp dauernd das 
volatile wegcasten muss.

[AVR-Anfänger (Gast)]

die ISR:

ISR(USART1_RX_vect)
{
  volatile unsigned char nextChar;
  
  // Daten aus dem Puffer lesen
  nextChar = UDR1;
  if( uart_str_complete == 0 ) {  
    if( nextChar != '\n' &&
    nextChar != '\r' &&
    uart_str_count < UART_MAXSTRLEN ) {
      uart_string[uart_str_count] = toupper(nextChar); 
      uart_str_count++;
    }
    else {
      uart_string[uart_str_count] = '\0';
      uart_str_count = 0;
      uart_str_complete = 1;
    }
  }
}

Die Auswertung:(wie mein Vorgänger schon sagte, noch nicht 100% fertig;)

void uart1_auswerten(void){
    char tStr_1[10];
    char tStr_2[5];
    char tStr_3[5];
    uint32_t obergrenze =0xFFFF;
    
    char uart_temp[UART_MAXSTRLEN+1];

    strcpy(uart_temp,(char*)uart_string);
    uart_str_complete = 0;

    uart_puts(uart_temp,false);
    uart_puts(":",false);
    
    if (strcmp(uart_temp,"RED")==0) //(char*) verhindert compiler warnung
    {
      uart_puti(get_color("RED"),true);
    }
    else if (strcmp(uart_temp,"GREEN")==0)
    {
      uart_puti(get_color("GREEN"),true);
    }
    else if (strcmp(uart_temp,"BLUE")==0)
    {
      uart_puti(get_color("BLUE"),true);
    }
    else if (strcmp(uart_temp,"CLEAR")==0)
    {
      uart_puti(get_color("CLEAR"),true);
    }
    else if (strcmp(uart_temp,"LUX")==0)
    {
      uart_puti(calculateLux(get_color("RED"),get_color("GREEN"),get_color("BLUE")),true);
    }
    else if (strcmp(uart_temp,"RGB")==0)
    {
      uart_puts("RED:",false);
      uart_puti(get_color("RED"),false);
      uart_puts("GREEN:",false);
      uart_puti(get_color("GREEN"),false);
      uart_puts("BLUE:",false);
      uart_puti(get_color("Blue"),true);

    }
    else if (strstr(uart_temp,"INT_LOW")) //Format: INT_LOW:"WERT"
    {  
      strcpy(tStr_1,strtok(uart_temp,":"));
      strcpy(tStr_2,strtok(NULL,";"));

      if (atol(tStr_2) < obergrenze)
      {
            Interrupt_config_TCS34725(true,0x01,(atoi(tStr_2)>>8),((uint8_t)atoi(tStr_2)),0xFF,0xFF);
            Interrupt_clear_TCS34725();  
            uart_puts("OK",true);
      }
      else
      {
        uart_puts("Integer Wertebereich ueberschritten",true);
      }
    }
    else if (strstr(uart_temp,"INT_HIGH"))
    {  
      strcpy(tStr_1,strtok(uart_temp,":"));
      strcpy(tStr_2,strtok(NULL,";"));

      if (atol(tStr_2) < obergrenze)
      {
            Interrupt_config_TCS34725(true,0x01,0x00,0x00,(atoi(tStr_2)>>8),((uint8_t)atoi(tStr_2))); //aufspalten des dec wertes in hex werte!
            Interrupt_clear_TCS34725();  
            uart_puts("OK",true);
      }
      else
      {
        uart_puts("Integer Wertebereich ueberschritten",true);
      }
    }
    else if (strstr(uart_temp,"INT_MITTEL"))  //Format: INT_MITTEL:"WERT_low";"Wert_High"
    {  
      strcpy(tStr_1,strtok(uart_temp,":"));
      strcpy(tStr_2,strtok(NULL,";"));
      strcpy(tStr_3,strtok(NULL,";"));

      if ((atol(tStr_2) < obergrenze) && (atol(tStr_3) < obergrenze))
      {
            Interrupt_config_TCS34725(true,0x01,(atoi(tStr_2)>>8),((uint8_t)atoi(tStr_2)),(atoi(tStr_3)>>8),((uint8_t)atoi(tStr_3)));
            Interrupt_clear_TCS34725();  
            uart_puts("OK",true);
      }
      else
      {
        uart_puts("Integer Wertebereich ueberschritten",true);
      }
    }
}

und noch uart_puts und puti:

void uart_puts (char *s,bool sendCR)
{
  while (*s)
  {  
    uart_putc(*s);
    s++;
  }
  if (sendCR)
  {
    uart_putc('\r');
    uart_putc('\n');    
  }
}

void uart_puti( unsigned int wert ,bool sendCR)
{
  char txt[8];
  char buffer[8];
  sprintf(buffer,"%05d",wert);
  //itoa( wert, txt, 10 );
  uart_puts( buffer ,sendCR);
}

[AVR-Anfänger (Gast)]

Achja, und bitte zerreist mich jetzt nicht wegen dem Zerteilen des 
Strings mit "strtok", ich habe bis jetzt nur das gefunden...

[Karl H. (kbuchegg)]

Hier

      strcpy(tStr_1,strtok(uart_temp,":"));
      strcpy(tStr_2,strtok(NULL,";"));

brauchst du keinen strcpy.

strtok modifiziert dein uart_temp und liefert dir Pointer auf den 
jeweiligen String Anfang.

  char * part1;
  char * part2;

  part1 = strtok( uart_temp,":");
  part2 = strtok( NULL,";");

die kannst du dann ganz normal weiter benutzen.

Ich bin zwar unter den ersten, die normalerweise sagen: überlass das 
Optimieren dem Compiler. Aber wenn du so wie hier

      if ((atol(tStr_2) < obergrenze) && (atol(tStr_3) < obergrenze))
      {
            Interrupt_config_TCS34725(true,0x01,(atoi(tStr_2)>>8),((uint8_t)atoi(tStr_2)),(atoi(tSt ...

atol mehrmals brauchst, lohnt es sich dafür Zwischenvariablen 
abzustellen, in denen du die Ergebnisse der Konvertierung ablegst.
Man muss sein Glück ja auch nicht mutwillig herausfordern.

[Karl H. (kbuchegg)]

Karl Heinz schrieb:
> Hier
>

>       strcpy(tStr_1,strtok(uart_temp,":"));
>       strcpy(tStr_2,strtok(NULL,";"));
>

> brauchst du keinen strcpy.
>
> strtok modifiziert dein uart_temp und liefert dir Pointer auf den
> jeweiligen String Anfang.
>
>

>   char * part1;
>   char * part2;
> 
>   part1 = strtok( uart_temp,":");
>   part2 = strtok( NULL,";");
>

>
> die kannst du dann ganz normal weiter benutzen.

Und du solltest natürlich auch prüfen, ob das alles geklappt hat!
Nicht auf NULL Pointer zu prüfen, ist der Fehler, der für die 
überwiegende Mehrheit aller Fehler verantwortlich ist!

  char * part1;
  char * part2;

  part1 = strtok( uart_temp,":");
  part2 = strtok( NULL,";");

  if( part1 != NULL && part2 != NULL ) {
    ....

  }
  else
    uart_puts( "Syntaxfehler!\r\n" );

Und das mit dem zusätzlichen Argument true/false bei den 
Ausgabefunktionen würde ich mir nochmal überlegen. Das lohnt 
normalerweise nicht.

Das hier

      uart_puts("RED:",false);
      uart_puti(get_color("RED"),false);
      uart_puts("GREEN:",false);
      uart_puti(get_color("GREEN"),false);
      uart_puts("BLUE:",false);
      uart_puti(get_color("Blue"),true);

schreibt sich länger als das hier

      uart_puts("RED:");
      uart_puti(get_color("RED"));
      uart_puts("GREEN:");
      uart_puti(get_color("GREEN"));
      uart_puts("BLUE:");
      uart_puti(get_color("Blue"));
      uart_puts("\r\n");

wenn du dir was gutes tun willst, dann überleg lieber ob es nicht 
vernünftig wäre, ein paar Leerzeichen einzustreuen. Seit du 6 Jahre alt 
bist, hast du dein Gehirn darauf trainiert, dass zwischen Wörtern ein 
Leerraum steht. Du machst das mitlerweile ganz unbewusst und musst keine 
aktive Identifikationsarbeit der einzelnen Wörter beim Lesen mehr 
aufbringen. In diesem Sinne ist zb

[c]
      uart_puts( "RED:" );
      uart_puti( get_color( "RED" ) );
      uart_puts( "GREEN:" );
      uart_puti( get_color( "GREEN" ) );
      uart_puts( "BLUE:" );
      uart_puti( get_color( "Blue" ) );
      uart_puts( "\r\n" );

leichter zu lesen, weil du keine bewusste Gehirnaktivität dafür 
aufbringen musst, in dem Buchstabenwust erst mal die einzelnen Wörter zu 
finden.

So was hier

            Interrupt_config_TCS34725(true,0x01,0x00,0x00,(atoi(tStr_2)>>8),((uint8_t)atoi(tStr_2))); //aufspalten des dec wertes in hex werte!

geht gar nicht. Um wieviel einfacher ist es

            ConfigWert = atoi( tStr_2 );

            Interrupt_config_TCS34725( true,
                                       0x01, 0x00, 0x00,
                                       ConfigWert >> 8, ConfigWert
                                     );

zu lesen, wobei ich mich frage, warum sich die Funktion die Zerlegung in 
die beiden Bytes nicht selbst macht.

[Daniel A. (daniel-a)]

Die strcmp orgien errinnern mich an dasshier:
Beitrag "Re: Arduino Serial ganze wörter abfragen"
Dass könnte relevant sein.

[AVR-Anfänger (Gast)]

so, wurde nun auch umgesetzt:)...

ich bekomme vom Compiler noch die Warnung das die Funktion sprintf 
implicit deklariert wurde, aber woran soll das denn liegen?

[Karl H. (kbuchegg)]

AVR-Anfänger schrieb im Beitrag #4055627:
> so, wurde nun auch umgesetzt:)...
>
> ich bekomme vom Compiler noch die Warnung das die Funktion sprintf
> implicit deklariert wurde, aber woran soll das denn liegen?

stdio.h includieren

[AVR-Anfänger (Gast)]

hmm peinlich.. wieso kann die Funktion dann trotzdem benutzt werden, 
obwohl sie noch nicht eingebunden ist?

[TriHexagon (Gast)]

AVR-Anfänger schrieb im Beitrag #4055640:
> hmm peinlich.. wieso kann die Funktion dann trotzdem benutzt
> werden,
> obwohl sie noch nicht eingebunden ist?

Sie ist eingebunden auch ohne das Inkludieren. Du machst dem Kompiler 
mit dem Inkludieren die Funktion bekannt. Wenn der Kompiler die Funktion 
nicht kennt, geht er davon aus, dass sie doch existiert und gibt eine 
Warnung aus. Das Einbinden übernimmt der Linker.

[Karl H. (kbuchegg)]

AVR-Anfänger schrieb im Beitrag #4055640:
> hmm peinlich.. wieso kann die Funktion dann trotzdem benutzt werden,
> obwohl sie noch nicht eingebunden ist?

Die Funktion existiert ja.
Das einzige was der Compiler nicht weiss, das ist wie die 
Funktionsargumente aussehen. Und daher warnt er dich, dass in diesem 
Fall dann Standardannahmen in Kraft treten. Die können richtig sein oder 
auch nicht. In deinem Fall sind sie richtig. Das muss aber nicht immer 
so sein, und dann hat man seltsame Fehler. Daher die Warnung.

Die Funktion selber steht ja nicht im Header File. Im Header File steht 
ja nur der Funktionsprotoyp. Du selbst hast ja in deinem Header File 
auch nichts anderes gemacht: Da steht die Information drinnen, welche 
Funktionen es gibt, wieviele Argumente jede Funktion hat und welche 
Datentypen gelten sowie der Return Datentyp der Funktion. Das reicht, 
damit man beim Aufruf der Funktion prüfen kann, ob alles in Ordnung ist 
und ob eventuelle Konvertierungen gemacht werden müssen.
WEnn du aber keinen Prototypen hast, dann musst du dem Programmierer 
vertrauen, dass er seinen Aufruf korrekt gemacht hat.
Mit der Existenz der Funktion hat das erst mal nichts zu tun. Zu diesem 
Zeitpunkt in der Übersetzung geht es nur um die Prüfung, ob der Aufruf 
der Funktion technisch korrekt ist und ob Konvertierungen notwendig 
sind.