Forum de la communauté SFML
Aide => Réseau => Discussion démarrée par: Siviuze le Avril 18, 2012, 05:55:33 pm
-
Salut à tous et à toutes !
J'utilise actuellement dans un petit projet sf::Packet pour balader des données entre un PC et une carte ARM (encore et toujours ;D).
J'ai constaté (après un long arrachage de cheveux) que l'utilisation de données d'une taille impair emmêle l'extraction.
Exemple :
sf::Packet pac;
pac <<< u8 << u16 << u16 << u16 << u16; // erreur extraction
pac << u8 << u8 << u16 << u16 << u16 << u16; // OK
pac << u16 << u16 << u16 << u16 << u16; // OK
Ce problème semble du à l'alignement mémoire de l'ARM9 qui se comporte différemment suivant l'accès à un pointeur pair ou impair pour des données ayant une taille supérieure à 1.
Je me demandais donc s'il s'agit d'un "problème" connue (si on peut parler de problème) ?
Pour l'instant, j'ai résolu le problème de 2 façons : soit en n'envoyant que des données de taille paire, soit en 'patchant' l'extraction de sf::Packet
Packet& Packet::operator >>(Uint16& data)
{
if (checkSize(sizeof(data)))
{
data = ntohs((Uint16)(m_data[m_readPos]) + (Uint16)(m_data[m_readPos+1] << 8)
//data = ntohs(*reinterpret_cast<const Uint16*>(&m_data[m_readPos]));
m_readPos += sizeof(data);
}
return *this;
}
Cela ajoute un léger overhead (une mesure rapide me donne 0.01% de charge en plus côté ARM9). Je me demande s'il existe une manière plus adapté de résoudre ce souci ?
-
C'est dur à dire.
Il se passait quoi exactement quand ça foirait ? De quelle manière est-ce que ça choucroutait l'extraction ?
-
admettons que j'ai:
u8 a = 3;
u16 b = 0x1234;
le contenu du paquet donne : 0x3 0x34 0x12
A lextraction :
u8 a = 3
u16 b = 0x3403 -> il a associé le u8 avec le u16 (car avec le pointeur impair, il a compris que je demandais le LSB...)
-
Ok je vois le truc, il ne sait pas lire de données non-alignées. Il faudrait que je trouve de la bonne doc à ce sujet.
-
Bon en attendant je vais rester sur le workaround par extraction (CAD je récupere chaque octet et je recré 'a la main' la donnée). Si je trouve une solution plus agréable je te tiendrai au courant ;)
-
En fait je ne pense pas qu'il y en ait d'autre. A part regrouper de ton côté tous les membres à sérialiser dans une structure, de façon à ce qu'ils soient automatiquement correctement alignés.
Faire l'extraction octet par octet serait faisable dans SFML (en prenant en compte l'endianness), mais ce serait du boulot pour gérer une architecture qui est finalement assez atypique (j'ai essayé au boulot sur notre carte ARM, j'ai même pas ce problème).
-
Il semblerait que ce problème ai été résolu avec les nouveaux processeur ARM (cortex A/M/R). Je vais bientot faire une MAJ du robot avec un processeur de ce type, du coup si le problème se règle de lui même, tant mieux ;D