Frage zu Pointern - AVR vs x86_64

[CC (Gast)]

Hallo!

Ich weiß nicht, ob dieses Forum das Richtige ist, aber ich hoffe mal, 
ansonsten bitte verschieben.

Ich habe ein Projekt auf einem Atmega644p, das in mehrere Dateien 
aufgeteilt ist.

xbee.h:

//...
char *xbee_get_raw_packet(uint16_t *len);
//...

xbee.c:

volatile char xb_data[120];
volatile uint16_t  xb_len = 0; //wird zwischendurch gesetzt

//...

char *xbee_get_raw_packet(uint16_t *len)
{
  *len = xb_len;
  printf("--*len=%u ; xb_len=%u--\r\n", *len, xb_len);
  printf("len = %p\r\n", len);
  return (char *)xb_data;
}

//...

Ausgabe:

--*len=2 ; xb_len=2--
len = 0x10e4

main.c:

//...
main()
{
   //...
   while(1)
   {
       //...
       if(...)
       {
           uint16_t len = 3;
           printf("&len = %p\r\n", &len);
           char *data = xbee_get_raw_packet(&len);

           printf("type = %02x, len = %u\r\n", data[0], len);

           uint8_t i;
           for(i = 0; i < len; i++)
               printf("%02X ", data[i]);
           puts("\r\n");
       }
       //...
   }
}

Ausgabe:

...
 &len = 0x10e4
type = 8a, len = 3
...

Ja, ich weiß, printf() ist "böse" auf einem uC, aber es vereinfacht sehr 
vieles ungemein, kann u.U. später noch rausoptimiert werden.

Nun aber zu der Frage:
In einer ISR wird xb_len auf einen Wert gesetzt.

Rufe ich aus der main.c xbee_get_raw_packet(&len); auf, wird len NICHT 
beschrieben, es behält einfach den Wert von vorher.
Ich habe auf meinem Laptop (x86_64) die Funktionen "nachgebaut", da 
funktioniert alles.

Sieht jemand auf Anhieb einen Fehler?

Ich nutze avr-eclipse, daher kein Makefile.

$ avr-gcc --version
avr-gcc (GCC) 4.3.4

$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

Vielen Dank für die Ratschläge, ich vermute, dass es etwas sehr banales 
ist, aber ich schon zu lang drauf geschaut habe :)

(Das gleiche Verhalten tritt auf, auch wenn xbee_get_raw_packet() einen 
uint8_t * erwartet.)

[Karl H. (kbuchegg)]

CC schrieb:


> Sieht jemand auf Anhieb einen Fehler?

No.
Gut, da len ein uint16_t ist, müsst man atomaren Zugriff garantieren, 
aber das dürfte jetzt erst mal nicht der Fehler sein.

probier mal

//...
main()
{
   //...
   while(1)
   {
       //...
       if(...)
       {
           uint16_t len = 3;
           extern volatile uint16_t  xb_len;

           printf("&len = %p\r\n", &len);
           printf("xb_len vor Aufruf = %u\r\n, xb_len);

           char *data = xbee_get_raw_packet(&len);

           printf("type = %02x, len = %u\r\n", data[0], len);

           uint8_t i;
           for(i = 0; i < len; i++)
               printf("%02X ", data[i]);
           puts("\r\n");

Wie sieht dann die Asusgabe aus?

[CC (Gast)]

Danke für die Antwort!
xb_len kann ich lesen, das funktioniert wunderbar. Aber ich habe gerade 
noch einen merkwürdigen anderen Fehler, bei dem mir irgendein Datenmüll 
angezeigt wird, den ich nicht verstehe :(
Also im Terminal kommen seltsame Steuerzeichen o.ä. an.
Mist! jetzt, wo es spannend wird, muss ich leider los :( Ich werde heute 
Abend berichten, was ich rausgefunden habe.
Viele Grüße!

[(prx) A. K. (prx)]

Wie gross ist denn dein Dataspace?

[CC (Gast)]

Dataspace = SRAM?
Wenn ja, dann 4 KByte laut Datenblatt. Ich bin zwar nicht gerade sparsam 
damit umgegangen, aber voll dürfte er dennoch nicht sein. Rekursionen 
o.ä. habe ich auch nicht drin, auch keine tiefen Unterprogrammaufrufe...

Leider komme ich gerade an den µC nicht dran, wollte nicht zurück in die 
Uni.

[(prx) A. K. (prx)]

CC schrieb:

> Wenn ja, dann 4 KByte laut Datenblatt.

Datenblätter lesen kann ich auch. Wieviel davon ist verwendet?

[CC (Gast)]

Hm, doofe Frage - aber wie krieg ich das raus, außer alle Variablen 
zusammenzuzählen? :)
avr-size datei.hex sagt mir bei text und bss "0".
Ich habe ein Array, das vorher 120 Bytes groß war Testweise auf 30 
verkleinert und eins von 48 auf 15 - die Ergebnisse waren die selben.

[CC (Gast)]

AVR Memory Usage:
-----------------
Program:   12712 bytes (.text + .data + .bootloader)
Data:       1006 bytes
 (.data + .bss + .noinit)

(habe avr-mem.sh gefunden)

[(prx) A. K. (prx)]

Ok, wenn du kein malloc verwendest, dann ist RAM kein Thema.

[CC (Gast)]

Das nutze ich nicht. Kann mir das Verhalten auch nicht wirklich 
erklären...
Am Controller dürfte es auch nicht liegen, avrdude testet die Daten ja 
noch einmal.
Auch ein Versuch, den Block in der Abfrage mit cli() und sei() 
einzuschließen brachte nichts.

[g457 (Gast)]

Schau Dir doch mal den zugehörigen Assemblercode an was der da alles 
anstellt.

[CC (Gast)]

Puh, ich hab befürchtet, dass der Tag kommen wird, an dem man sich damit 
beschäftigen muss... Meine Assembler-Kenntnisse gehen leider gegen 0 :(

Ich habe jetzt versucht, es ohne Optimierungen zu übersetzen (-O0) und 
da scheint es zu gehen!?

Wo kann da in meinem Code der Fehler sein? Mir wird das langsam zu hoch 
;)

[CC (Gast)]

(Vergessen: vorher war es -Os)

[CC (Gast)]

So, nun geht es.
In einer ISR, in der ein Zeichen vom XBEE-Modul eingelesen wird, hatte 
ich probehalber noch das Zeichen ausgegeben. Das habe ich gelöscht, nun 
geht es.
Allerdings meine ich, dass ich das dort erst hinzugefügt hatte, nachdem 
die Übergabe des Parameters Probleme bereitet hat.
Kann das dann eventuell doch an dem Compiler liegen?

[CC (Gast)]

Oh, verdammt!
Asche auf mein Haupt!

char str[3];
sprintf("%02X ", c);

KANN auch gar nicht funktionieren. Ich bedanke mich für eure Hilfe und 
entschuldige mich, euch die Zeit geraubt zu haben! :)

[Klaus (Gast)]

CC schrieb:
> Kann das dann eventuell doch an dem Compiler liegen?

CC schrieb:
> Oh, verdammt!
> Asche auf mein Haupt!

Womit sich mein Lieblingsgesetz bezüglich Compilierfehlern mal wieder 
bestätigt hat ;-)

Mach dir nix draus, mir hat das stellen von Fragen hier auch schon 
manchmal geholfen, die Tomaten auf den eigenen Augen zu beseitigen. ;-)