C Übergabe mit Zeiger

[M. M. (blackcow)]

Hallo Forum!

Ich bin mal wieder am Verzweifeln mit C. Ich habe ein Problem mit der 
Übergabe by reference. Die Funktion g_printc gibt ein Zeichen auf meinem 
LCD aus. Das auszugebende Zeichen wird per Zeiger von test() übergeben 
(*ichar). Nur leider funktioniert das nicht. Ich habe schon versucht mit 
static test() und volatile... Funktioniert alles nicht und ich weiß 
nicht warum. Könnte da bitte mal jemand drüberschauen? Warscheinlich 
sehe ich den Baum vor lauter Wäldern nicht und es ist ein saudummer 
Fehler.

///define font arrays
  //font0 4x2
  const uint8_t font0[10] PROGMEM = {153, 240, 219, 249, 231, 189, 223, 241, 255, 251};

[...]

void g_printc(uint8_t x, uint8_t y, uint8_t font, char *ichar){
  switch(font){
    case 0: ;
      char test=*ichar;
      uint8_t *charflash=font0+test;
      g_crect(x-1, y-1, x+3, y+5);
      for(uint8_t iy=0; iy<4; ++iy){
        if(*charflash&(1<<iy))
          g_point(x, y+iy);
      }
      for(uint8_t iy=0; iy<4; ++iy){
        if(*charflash&(1<<iy+4))
          g_point(x+1, y+iy);
      }
      g_crect(10, 5, 12, 20);
      for(int i=0; i<8; ++i){
        if(*charflash&(1<<i))
          g_point(10, 6+i);
      }
      break;
    case 1: ;
      break;
    case 2: ;
      break;
  }
  return;
}

[...]

void test(){
  g_frect(0,0,120,30);
  char test=1;
  g_printc(5,5,0,&test);
  lcd_refresh();
  return;
}

[Rufus Τ. F. (rufus)]

Die Übergabe von "test" ist soweit korrekt.

Deine Funktion erwartet einen Pointer (char *ichar), Du übergibst ihr 
beim Aufruf die Adresse von "test" (g_printc(5, 5, 0, &test))

Ist zwar vollkommen unklar, was das soll (Du könntest Deinen einzelnen 
char auch direkt als Wert übergeben), aber korrekt ist es trotzdem.

Woran machst Du fest, daß "das nicht funktioniert"?

Könnte es sein, daß Deine Zugriffe auf Deine Zeichentabelle nicht 
funktionieren, weil Du PROGMEM und normale Speicherzugriffe mischt?

[Dirk B. (dirkb2)]

M. M. schrieb:
> Das auszugebende Zeichen wird per Zeiger von test() übergeben
> (*ichar).
Warum über Zeiger?

> Nur leider funktioniert das nicht.
Doch, das funktioniert.

Das Problem ist nicht der Zeiger von ichar.

[M. M. (blackcow)]

Rufus Τ. F. schrieb:

> Ist zwar vollkommen unklar, was das soll (Du könntest Deinen einzelnen
> char auch direkt als Wert übergeben), aber korrekt ist es trotzdem.

Ich mach eine zweite Funktion printf, die bekommt einen Zeiger auf ein 
String-Array. Die druckt dann die einzelnen Zeichen eben mit dem printc. 
Ich meine das dies effizienter ist als die Variablen zu kopieren.

> Woran machst Du fest, daß "das nicht funktioniert"?

Wenn ich in die Funktion printc nicht den Zeiger verwende, sondern eine 
Variable erstelle, in diesem Fall mit char testvariable=1;, dann wird 
das richtige Zeichen ausgegeben.

> Könnte es sein, daß Deine Zugriffe auf Deine Zeichentabelle nicht
> funktionieren, weil Du PROGMEM und normale Speicherzugriffe mischt?

Wie meinst du das? Ist die Vorgehensweise korrekt:
const uint8_t a PROGMEM = 1;
uint8_t test;
test=a;

[Dirk B. (dirkb2)]

M. M. schrieb:
> Die druckt dann die einzelnen Zeichen eben mit dem printc.
> Ich meine das dies effizienter ist als die Variablen zu kopieren.
Da täuscht du dich.

Ein Zeiger braucht i.A. mehr Speicher als ein Byte.
Und somit müssen mehr Daten kopiert werden als bei der direkten 
Übergabe.

Das Problem ist dann auch nicht ichar sondern charflash.

[M. M. (blackcow)]

M. M. schrieb:
> void g_printc(uint8_t x, uint8_t y, uint8_t font, char *ichar){
>   switch(font){
>     case 0: ;
        char test2=1;
        char *test3=&test2;
>       char test=*test3;
>       uint8_t *charflash=font0+test;
>       g_crect(x-1, y-1, x+3, y+5);
>       for(uint8_t iy=0; iy<4; ++iy){
>         if(*charflash&(1<<iy))
>           g_point(x, y+iy);
>       }
>       [...]

Hier funktioniert es wie gewünscht, damit ihr wisst was ich meine. Liegt 
es vielleicht an dem switch? Ist es ein Bug von AVR Studio?

Dirk B. schrieb:
> Das Problem ist dann auch nicht ichar sondern charflash.

Das wäre dann hiermit wiederlegt, oder sehe ich das falsch?

[Dirk B. (dirkb2)]

So leicht kannst du den Compiler auch nicht verwirren, der macht ein
char test=1;
daraus.

Geht das denn, wenn du ichar nicht als Zeiger definierst?


Du kannst dich mit den Funktionen durchaus an der Standardbibliothek 
orientieren: printf und putc

[Kaj G. (Firma: RUB) (bloody)]

Hat zwar nichts mit dem Problem zu tun, aber:
> case 0: ;
> case 1: ;
> case 2: ;
gibt es einen Grund für die (sinnfreien) Semikola? Die tun zwar nicht 
weh, aber extra Punkte bringen sie auch nicht.

M. M. schrieb:
> Ist es ein Bug von AVR Studio?
Wenn dann wäre es ein Bug im Compiler (und nicht in der IDE), also dem 
GCC, und das ist (wenn auch nicht ganz ausgeschlossen) eher 
unwahrscheinlich.
Such mal hier im Forum nach Bug und GCC. Fast jeder behauptet erstmal, 
das muss ein Bug im Compiler sein,... und praktisch jedes Mal stellt 
sich raus, das es doch kein Bug im GCC ist.

Mit welchen Compiler flags compilierst du denn? Kann es vielleicht sein, 
das der Compiler da was wegoptimiert?

[Dirk B. (dirkb2)]

M. M. schrieb:
> Das wäre dann hiermit wiederlegt, oder sehe ich das falsch?

Da der Wert von test in der Funktion auf 1 festgelegt ist, kann der 
Compiler ganz anders Optimieren.

Er kann *charflash komplett durch 240 ersetzen.

[M. M. (blackcow)]

Ok. Nochmal ganz einfach. Der gleiche Effekt jetzt mit direkter 
Übergabe.

Funktioniert:

void g_printc(uint8_t x, uint8_t y, uint8_t font, char ichar){
        ichar=1
  g_crect(x-1, y-1, x+3, y+5);
  for(uint8_t iy=0; iy<4; ++iy){
    if(*charflash&(1<<iy))
      g_point(x, y+iy);
  }
  for(uint8_t iy=0; iy<4; ++iy){
    if(*charflash&(1<<iy+4))
      g_point(x+1, y+iy);
  }
        return;
}

Funktioniert nicht:

void g_printc(uint8_t x, uint8_t y, uint8_t font, char ichar){
  g_crect(x-1, y-1, x+3, y+5);
  for(uint8_t iy=0; iy<4; ++iy){
    if(*charflash&(1<<iy))
      g_point(x, y+iy);
  }
  for(uint8_t iy=0; iy<4; ++iy){
    if(*charflash&(1<<iy+4))
      g_point(x+1, y+iy);
  }
        return;
}
void test(){
     char test=1;
     g_printc(1,1,0,test);
}

[Dirk B. (dirkb2)]

Dirk B. schrieb:
> Er kann *charflash komplett durch 240 ersetzen.

Dirk B. schrieb:
> Das Problem ist dann auch nicht ichar sondern charflash.

[M. M. (blackcow)]

Kaj G. schrieb:
> Hat zwar nichts mit dem Problem zu tun, aber:
>> case 0: ;
>> case 1: ;
>> case 2: ;
> gibt es einen Grund für die (sinnfreien) Semikola? Die tun zwar nicht
> weh, aber extra Punkte bringen sie auch nicht.

Das dachte ich auch zuerst, aber die sind tatsächlich notwendig. Der 
C-Standard sagt nach einem case: darf keine Variable initialisiert 
werden.

> M. M. schrieb:
>> Ist es ein Bug von AVR Studio?
> Wenn dann wäre es ein Bug im Compiler (und nicht in der IDE), also dem
> GCC, und das ist (wenn auch nicht ganz ausgeschlossen) eher
> unwahrscheinlich.
> Such mal hier im Forum nach Bug und GCC. Fast jeder behauptet erstmal,
> das muss ein Bug im Compiler sein,... und praktisch jedes Mal stellt
> sich raus, das es doch kein Bug im GCC ist.

Ja klar im Compiler. Ich weiß garnicht das AVR-Studio gcc nutzt. Ehrlich 
gesagt kann ich es mir auch nicht vorstellen, aber an was liegt es dann?

> Mit welchen Compiler flags compilierst du denn? Kann es vielleicht sein,
> das der Compiler da was wegoptimiert?

Mit den Standardeinstellungen.

[M. M. (blackcow)]

Dirk B. schrieb:
> Dirk B. schrieb:
>> Er kann *charflash komplett durch 240 ersetzen.
>
> Dirk B. schrieb:
>> Das Problem ist dann auch nicht ichar sondern charflash.

Dann dürfte es doch trotzdem keinen Unterschied geben, die Optimierung 
ist ja in dem Fall in Ordnung.

[Dirk B. (dirkb2)]

DAs habe ich noch vergessen zu zitieren:

Rufus Τ. F. schrieb:
> Könnte es sein, daß Deine Zugriffe auf Deine Zeichentabelle nicht
> funktionieren, weil Du PROGMEM und normale Speicherzugriffe mischt?

[Kaj G. (Firma: RUB) (bloody)]

M. M. schrieb:
> Funktioniert:void g_printc(uint8_t x, uint8_t y, uint8_t font, char
...
> Funktioniert nicht:
Ist ganz schön was du da schreibst, aber in beiden Beispielen wird ichar 
nicht verwendet... aber vielleicht bin ich auch einfach nur blind.

[M. M. (blackcow)]

Kaj G. schrieb:
> M. M. schrieb:
>> Funktioniert:void g_printc(uint8_t x, uint8_t y, uint8_t font, char
> ...
>> Funktioniert nicht:
> Ist ganz schön was du da schreibst, aber in beiden Beispielen wird ichar
> nicht verwendet... aber vielleicht bin ich auch einfach nur blind.

Ahh du hast recht! Also nochmal richtig:

Funktioniert:

void g_printc(uint8_t x, uint8_t y, uint8_t font, char ichar){
  ichar=1;
  uint8_t *charflash=font0+ichar;
  g_crect(x-1, y-1, x+3, y+5);
  for(uint8_t iy=0; iy<4; ++iy){
    if(*charflash&(1<<iy))
      g_point(x, y+iy);
  }
  for(uint8_t iy=0; iy<4; ++iy){
    if(*charflash&(1<<iy+4))
      g_point(x+1, y+iy);
  }
        return;
}
void test(){
     char test=1;
     g_printc(1,1,0,test);
}

Funktioniert nicht:

void g_printc(uint8_t x, uint8_t y, uint8_t font, char ichar){
  uint8_t *charflash=font0+ichar;
  g_crect(x-1, y-1, x+3, y+5);
  for(uint8_t iy=0; iy<4; ++iy){
    if(*charflash&(1<<iy))
      g_point(x, y+iy);
  }
  for(uint8_t iy=0; iy<4; ++iy){
    if(*charflash&(1<<iy+4))
      g_point(x+1, y+iy);
  }
        return;
}
void test(){
     char test=1;
     g_printc(1,1,0,test);
}

[Rufus Τ. F. (rufus)]

M. M. schrieb:
>> gibt es einen Grund für die (sinnfreien) Semikola? Die tun zwar nicht
>> weh, aber extra Punkte bringen sie auch nicht.
>
> Das dachte ich auch zuerst, aber die sind tatsächlich notwendig. Der
> C-Standard sagt nach einem case: darf keine Variable initialisiert
> werden.

Aua. Da hilft auch kein Semikolon. Wenn hier neue Variablen nötig sind, 
beginnt man einen neuen Block - d.h. einen von geschweiften Klammern 
umschlossenen Abschnitt.

Natürlich nur, wenn es tatsächlich nötig ist, hier neue Variablen zu 
deklarieren, sonst sind sie überflüssig.

[M. M. (blackcow)]

Rufus Τ. F. schrieb:
> M. M. schrieb:
>>> gibt es einen Grund für die (sinnfreien) Semikola? Die tun zwar nicht
>>> weh, aber extra Punkte bringen sie auch nicht.
>>
>> Das dachte ich auch zuerst, aber die sind tatsächlich notwendig. Der
>> C-Standard sagt nach einem case: darf keine Variable initialisiert
>> werden.
>
> Aua. Da hilft auch kein Semikolon. Wenn hier neue Variablen nötig sind,
> beginnt man einen neuen Block - d.h. einen von geschweiften Klammern
> umschlossenen Abschnitt.
>
> Natürlich nur, wenn es tatsächlich nötig ist, hier neue Variablen zu
> deklarieren, sonst sind sie überflüssig.

http://stackoverflow.com/questions/92396/why-cant-variables-be-declared-in-a-switch-statement

[Karl H. (kbuchegg)]

M. M. schrieb:

> Ahh du hast recht! Also nochmal richtig:
>
> Funktioniert:
>

> void g_printc(uint8_t x, uint8_t y, uint8_t font, char ichar){
>   ichar=1;
>   uint8_t *charflash=font0+ichar;
>   g_crect(x-1, y-1, x+3, y+5);
>   for(uint8_t iy=0; iy<4; ++iy){
>     if(*charflash&(1<<iy))
>

Nö. Das funktioniert ganz sicher nicht.
Nicht mit

  const uint8_t font0[10] PROGMEM = {153, 240, 219, 249, 231, 189, 223, 241, 255, 251};

In deinem Beispiel wenöglichst du dem Compiler alle Zwischenvariablen 
sowiet wegzuoptimieren, bis er beim eigentlichen Zugriff auf charflash 
noch immer die Information da hat, dass es sich da um einen Zugriff ins 
Flash handelt.

In deinem 'funktioniert nicht' Beispiel kann der Compiler diesen weg 
aber nicht gehen, weil ihm der Wert für ichar nicht bekannt ist.

Wenn du auf Dinge zugreifen willst, die due mittels PROGMEM ins Flash 
legst, dann müssen die Zugriffe anders sein. Du brauchst dazu die 
pgm_read Funktionen

https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Flash_mit_PROGMEM_und_pgm_read

Da liegt dein Problem.

[Karl H. (kbuchegg)]

M. M. schrieb:

> 
http://stackoverflow.com/questions/92396/why-cant-variables-be-declared-in-a-switch-statement


Alles schön und gut. Der übliche Weg besteht trotzdem darin in einem 
case einen Block einzufügen, wenn man in einem case eine Variable 
benötigt

  switch( ... )
  {

    case 'A':
      {
        char j = 5;
        ....
      }
      break;

    case 'B':
      {
        char j = 8;
        ....
      }
      break;

  }

das vermeidet dann Probleme mit dem Scope, zeigt an (und garantiert), 
dass diese Variable nur in diesem case verwendet werden kann und der 
Block ist auch ein Hinweis an zukünftige Programmier-Generationen, dass 
hier in diesem case irgendetwas 'Aussergwöhnliches' passiert.

Das Thema lautet "defensives programmieren".