Discussion :

[pfeuh]

Salut,

je suis sur un protocole de transmission série où tout est en bigendian. Pour envoyer un 32 bits je fais donc quelquechose du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
send_ubyte((my_u32 & 0xff000000) >> 24);
send_ubyte((my_u32 & 0x00ff0000) >> 16);
send_ubyte((my_u32 & 0x0000ff00) >> 8);
send_ubyte((my_u32 & 0x000000ff));

Quelquesoit l'endianess de my_u32, les bytes sont toujours placé de la même façon dans la trame. Comme ce protocle va servir à connecter des PC et des cartes à différents petits micros (8051, PIC etc...) et différents compilos, comment puis-je assurer la même indépendance au niveau des float32 (sans passer par des #define)?

A+

Pfeuh

[Invité(e)]

Bonjour,

Plusieurs choix :

+ faire du binaire et envoyer les float comme les entier.

Pour cela, il suffit de transtyper [EDIT]l'adresse (merci diogène) d'un float en entier [/EDIT] : on ne convertit pas la valeur, mais on stocke les bits du float dans un entier pour utiliser les opérateur binaires et de décalage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
/* il faut un type entier de la même taille que le flottant */
/* ASSERT(sizeof(float) == sizeof(int)); */
void send_float(float f) {
    int fake_float;
    fake_float = *(int*)(&f); /*EDIT: merci Melem */
    /* envoyer fake_float*/
    send_ubyte((fake_float & 0xff000000) >> 24);
    send_ubyte((fake_float & 0x00ff0000) >> 16);
    send_ubyte((fake_float & 0x0000ff00) >> 8);
    send_ubyte((fake_float & 0x000000ff));
}

Le problème de cette méthode est qu'on finira toujours par trouver une plateforme sur laquelle cette astuce ne fonctionne pas.
[edit]
Cette astuce fonctionne si

• on a un type entier de la même taille que le type flottant
• la représentation des flottant est la même sur les eux architectures (IEEE745)

[/edit]
+ faire du mode texte :
Mais le problème est qu'il faut revoir le protocole.

+ ne pas utiliser des flottant, mais des fixés : cela revient à utiliser des entier, tout en sachant où placer une virgule après réception.

[Pouet_forever]

C'est dangereux d'envoyer des nombres flottants tels quels ! Si l'hôte de destination n'a pas la même représentation des nombres flottants que la machine source, tu auras des problèmes. Le mieux est encore de convertir ton float en chaîne de caractères, de l'envoyer, et celui qui reçoit la convertit en nombre flottant. De cette manière tu ne devrais pas avoir de problèmes (du moins tu seras sûr que ton nombre arrive entier à l'autre bout).

Si tu tiens à les envoyer tels quels, tu peux tout simplement utiliser un 'union'

[Melem]

Si tu tiens à les envoyer tels quels, tu peux tout simplement utiliser un 'union'

Sûrement pas. Le *(int*)(&f) (mabu aussi voulait sûrement écrire &f) est largement à préférer aux unions. Les unions en C ANSI servent à économiser de la mémoire, pas à faire des réinterprétations de bits. Sinon, utiliser un pointeur de unsigned char qu'on fait pointeur sur le premier octet du float me semble la meilleure solution.

[diogene]

@mabu :

Pour cela, il suffit de transtyper (je ne suis pas sur du mot) un float en entier : on ne convertit pas la valeur, mais on stocke les bits du float dans un entier

Libellé dangereux, puisque le transtypage d'un float en int change la représentation binaire.
Ce n'est heureusement pas ce que fait ton code qui lui transtype bien l'adresse du float en une adresse d'entier.

[pfeuh]

faire du binaire et envoyer les float comme les entier.

Merci, ça me semble être la meilleure solution si un float32 est placé en mémoire comme un entier 32.

C'est dangereux d'envoyer des nombres flottants tels quels ! Si l'hôte de destination n'a pas la même représentation des nombres flottants que la machine source, tu auras des problèmes.

le format des flottants en petit embarqué est toujours float32 IEEE 754, comme le type float sur PC.

Le mieux est encore de convertir ton float en chaîne de caractères, de l'envoyer, et celui qui reçoit la convertit en nombre flottant.

On cherche à avoir les temps de transmission les plus courts, les plus prévisibles et les plus répétables, donc cette solution n'est pas envisageable.

Merci à tous.

Pfeuh