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:
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.
1
$ avr-gcc --version
2
avr-gcc (GCC) 4.3.4
1
$ gcc --version
2
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.)
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
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!
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.
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.
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.
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
;)
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 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. ;-)
