Messages

1

Réseau / Re : sf::Packet et alignement mémoire

« le: Avril 23, 2012, 01:32:33 pm »

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 

2

Réseau / Re : sf::Packet et alignement mémoire

« le: Avril 19, 2012, 10:31:16 pm »

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 

3

Réseau / Re : sf::Packet et alignement mémoire

« le: Avril 18, 2012, 07:06:52 pm »

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...)

4

Réseau / sf::Packet et alignement mémoire

« 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  ).

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 :

Code: [Sélectionner]

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

Code: [Sélectionner]

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 ?