Debian 4.7.2 AVR-GCC sscanf Problem

[Kai L. (klaute)]

Hallo,

ich verwende auf meinem Debian-System (64bit) den avr-gcc um meine 
Software für meine Mikrocontroller zu kompilieren.

In meiner Software ist ein TTY per USB implementiert in dem ich 
Benutzereingaben an die MCU senden kann.

Die empfangenen Daten werden per sscanf verarbeitet.

Mit dem aktuellen Atmel Studio und der dazugehörigen AVR GCC Toolchain 
funktioniert dies.

Mit dem standard Paket in Debian gibt es folgendes Problem.

Beispiel 1 (Pseudocode):

char* in_str = "0x02";
unsigned int in = 0;
sscanf(in_str, "0x%02x", &in);

Liefert den korrekt geparsten Wert in der Variablen: in=2.

Beispiel 2 (Pseudocode):

char* in_str = "0x02 0x14";
unsigned int in1 = 0;
unsigned int in2 = 0;
sscanf(in_str, "0x%02x 0x%02x", &in1, &in2);

Liefert keinen Wert wenn die Software auf dem Debian-System kompiliert 
wurde: in1=0 in2=0.

Es ist auf meinem Linux-System die folgende Software installiert:
AVR-GCC: 4.7.2
Lib AVR: 1.8.0
AVR binutils: 2.20.1

Hat hier jemand eine Idee wo das Problem beim Debian 4.7.2 AVR-GCC sein 
könnte?

Meine Linker-Optionen:
-Wl,-u,vfscanf -lscanf_flt -Wl,-u,vfscanf -lscanf_min (abgetippt, kann 
Tippfehler enthalten)

Danke!

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

%x ist für unsigned int, nicht für unsigned char.

GCC weiss das übrigens und warnt. Also hast du entweder Warnungen 
ignoriert, oder dein Pseudocode ist zu viel Pseudo.

[Kai L. (klaute)]

Richtig, es war zu viel Pseudo.

Ich habe es oben korrigiert...

Danke für den Hinweis!

[A. H. (ah8)]

Ist das Problem nun gelöst?

Wenn nicht würde ich es erst einmal mit

sscanf(in_str, "0x%2x 0x%2x", &in1, &in2);

probieren, denn die Null macht an der Stelle meiner Meinung nach keinen 
Sinn. Wenn das nicht hilft:

char* in_str = "02 0x14";
sscanf(in_str, "%2x 0x%02x", &in1, &in2);

Auch ein Blick auf Rückgabewert und Fehlercode könnte nicht schaden.

[Jörg W. (dl8dtl) (Moderator)]

Kai Lauterbach schrieb:
> -Wl,-u,vfscanf -lscanf_flt -Wl,-u,vfscanf -lscanf_min

Das ist übrigens nicht sinnvoll.  Entweder willst du die voll
aufgeblähte Gleitkomma-Version aus libscanf_flt.a haben oder die
minimale aus libscanf_min.a, aber nicht beide (bekommst du ohnehin
nicht, die Gleitkommaversion würde in dieser Konstellation „gewinnen“).

Vermutlich brauchst du beide Varianten aber gar nicht, sondern die
Standarversion würde dir völlig genügen.

[Kai L. (klaute)]

Ich habe alle Eingaben auf

0x%2x

 umgestellt, jedes fälschliche

unsigned char

 zu

unsigned int

 gewandelt und die Linker-Flags vom

scanf_flt

 befreit.

Nun funktioniert es einwandfrei!

Vielen Dank für die schnelle und kompetente Hilfe!!!

Kai

[A. H. (ah8)]

Hast Du das auch mal nacheinader getan damit mir wissen, woran es lag? 
(Mit Rückgabewert und Fehlernummer?) Ich tippe ja auf das unsigned 
char, damit bin ich dem Fehler am nächsten gekommen.

[Jörg W. (dl8dtl) (Moderator)]

A. H. schrieb:
> Ich tippe ja auf das unsigned char, damit bin ich dem Fehler am
> nächsten gekommen.

Glaub' ich nicht, denn die Datentypen, in die er wandeln lassen wollte
(so das Abgebildete der Realitiät entspricht), waren allesamt unsinged
int.  Die chars hat er oben nur für die Strings benutzt.

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

Jörg Wunsch schrieb:
> Glaub' ich nicht, denn die Datentypen, in die er wandeln lassen wollte
> (so das Abgebildete der Realitiät entspricht), waren allesamt unsinged
> int.  Die chars hat er oben nur für die Strings benutzt.

In der ursprünglichen Version des Startbeitrags waren das "unsigned 
char" Variablen. Erst auf meinen Hinweis hin hat er den Beitrag 
geändert.

PS: Nützlich zu wissen, dass euch Mods die Versionshistorie eines 
Beitrags zumindest nicht offen ins Auge sticht. ;-)

[Jörg W. (dl8dtl) (Moderator)]

A. K. schrieb:
> In der ursprünglichen Version des Startbeitrags waren das "unsigned
> char" Variablen.

OK.  "unsigned char" und scanf() ist natürlich immer ein "don't do 
this".