Discussion :

[MeWaa]

Bonsoir,

Alors voila je desire transmettre par la liaison serie un tableau de uint32 dans lequel se trouve des datas, un numero de sequence ainsi qu'un checksum.
Mon probleme est que le driver que je dois utiliser ne peut prendre en argument qu'un pointeur de chaine.
Auriez vous une idée pour la conversion ?


Merci d'avance

[Mac LAK]

Mon probleme est que le driver que je dois utiliser ne peut prendre en argument qu'un pointeur de chaine.

Ce serait étonnant. Ce n'est pas parce qu'une fonction d'émission (surtout réseau !!!) possède un paramètre "char*" pour son buffer qu'elle ne prends que des chaînes ASCII... Loin de là, même. Encore moins s'il y a, en plus, un paramètre contenant la longueur du buffer à envoyer.

Au prix d'un cast sauvage, tu devrais pouvoir envoyer n'importe quel buffer binaire sur ta liaison série.

[MeWaa]

C'est ce que j'avais fait au debut mais une erreur ce produisait lorsque j'observais la trame sur un terminal.
Mon pattern (0xA5A5A5A5) etait bien envoyé mais lorsque que la trame arrivait au numero de sequence elle devenait corrompue. Apres plusieurs teste je me suis rendu compte que l'envoie successif de deux octets nul rendait la suite de la trame fausse.
Je ne sais pas si cela intervient sur chaque liaison série RS485 ou si cela est un problème au niveau hard.

[Mac LAK]

Je ne sais pas si cela intervient sur chaque liaison série RS485 ou si cela est un problème au niveau hard.

Normalement, il n'y a aucune raison que plusieurs octets nuls émis aient un comportement étrange : c'est une valeur tout à fait légitime, qui n'est pas un Break ou autre truc plus ou moins obscur.

Tu utilises quelle librairie pour ta communication ? Sur quel OS/CPU ?

[MeWaa]

J'ai realisé une fonction de reception au lieu d'utiliser Gtkterm (hyperterm).
Les trames recues sont bonnes donc le probleme venait du terminal ce qui est assez surprenant.

Pour infos : Hote : Pc Linux (fedora)
Cible : carte embarqué tournant sous un OS TR Integrity

[MeWaa]

Mais bon maintenant un nouveau probleme est apparue.

J'envoie deux trames de 128bits et j'en reçoie une seule de 256.
Y a t il un moyen de recevoire deux trame de 128 ou dois je separer manuellement les trames ?

[Mac LAK]

J'ai realisé une fonction de reception au lieu d'utiliser Gtkterm (hyperterm).
Les trames recues sont bonnes donc le probleme venait du terminal ce qui est assez surprenant.

Heu, non, en fait, ça ne l'est pas du tout : un terminal, par contre, est conçu pour afficher du texte et non pas du binaire... Donc, un double caractère nul, pour lui, c'est une chaîne C "normale" plus une chaîne C "vide".

Si tu veux tester de l'envoi binaire avec un terminal "texte", il vaut mieux jouer avec les caractères accentués et les commandes de terminal, par exemple la chaîne suivante :

Code :

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

"Test d'e\bémission de bZZZZ\b\b\b\binaire avec des cà\baractères affichables\r\n"

Si tout va bien, ton terminal devrait afficher la chaîne suivante, et faire passer le curseur à la ligne suivante :

Code :

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

Test d'émission de binaire avec des caractères affichables

J'envoie deux trames de 128bits et j'en reçoie une seule de 256.
Y a t il un moyen de recevoire deux trame de 128 ou dois je separer manuellement les trames ?

C'est de la liaison série, et non pas des paquets UDP : c'est émis "tel quel" sur le médium, sans marqueurs spécifiques.
C'est à toi de séparer (temporellement) tes trames et/ou d'avoir une manière de les séparer depuis un flux binaire (longueur, marqueur de fin de trame, taille connue à l'avance, signaux modem, break, etc.).
N'oublie pas que le médium est très lent par rapport à ton PC, donc le poil de délai que tu mets entre les deux trames dans ton code est très certainement invisible à 100% côté médium : il est probable que lorsque tu reviens du second envoi, le premier ne soit toujours pas fini et soit encore dans les buffers du driver/UART...