www.mikrocontroller.net

Forum: Compiler & IDEs Frage zu Pointern - AVR vs x86_64


Autor: CC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: CC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gross ist denn dein Dataspace?

Autor: CC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CC schrieb:

> Wenn ja, dann 4 KByte laut Datenblatt.

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

Autor: CC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: CC (Gast)
Datum:

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

(habe avr-mem.sh gefunden)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, wenn du kein malloc verwendest, dann ist RAM kein Thema.

Autor: CC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: g457 (Gast)
Datum:

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

Autor: CC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
;)

Autor: CC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(Vergessen: vorher war es -Os)

Autor: CC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: CC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! :)

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.