Bonjour à tous,
 
Nouveau sur ce site, je cherche des renseignements par rapport à la peogrammation en langage C.
 
Je dois envoyer des trames à un afficheur qui doivent obligatoirement lui arriver en format hexadécimal. Et il doit impérativement y avoir un espace entre chaque octet. Voici un exemple (envoi du message HELLO):
 
24 57 52 4C 3E 2A 00 41 01 00 00 00 00 00 00 68 61 00 4D 41 49 4E 00 00 00 00 20 00 0C 24 0A 02 08 06 EF F1 01 F1 F2 01 F2 48 45 4C 4C 4F EF 56 F7 FE F4
 
 
Comment dois je déclarer mes données ?  
 
Je connais peu le langage C et je suis parti d'un exemple existant d'un programme déjà en focntion dans l'entreprise où je travaille (je le déclarais sous forme d'un char[] mais cela ne fonctionne pas)

Renseigne toi sur (s)printf avec %X (et modifie le titre du sujet, le C++ c'est pas identique au C!)

Ok, merci. Je vais regarder ça

Il faudrait définir ce que tu appelles "envoyer des trames à un afficheur". En fonction de ce dont on parle, "qui doivent obligatoirement lui arriver en format hexadécimal" peut n'avoir aucun sens.
 
En général quand on envoie des données à un périphérique (ton afficheur dans ce cas), on transmet des octets qui ont une signification bien particulière pour ce périphérique.
L'hexadécimal n'est qu'une façon d'afficher ces données pour qu'elles soient lisibles par un humain.
 

Bonjour. En fait l'afficheur doit le recevoir tel qu'écrit dans l'exemple que j'ai affiché, cad: 2 chiffres hexa (1 octet) puis un espace puis 2 chiffres hexa, etc....

J'ai de gros doutes.
 
Tu as la datasheet de cet afficheur?
Comment es-tu interfacé avec?
Tu programmes sur PC? Microcontrôleur?

Je  suis d'accord avec h3bus, vu d'ici, cela sent la mauvaise interprétation : pour envoyer un texte à un afficheur, peu de chance de lui envoyer, sous forme de texte, les codes hexa des caractères à afficher ... Ce serait marcher sur la tête !

Je n'ai pas fait de C depuis pas mal d'années mais la solution ne serait pas un truc comme une boucle sur    
 
printf("%02X", data);
 
où data est chacun de tes bytes à afficher ?
 
Mais effectivement, ça parait assez bizarre d'envoyer de l'héxa codé en ASCII avec des blancs à un afficheur.  
C'est plus une représentation pour les humains ou les fichiers de configuration en texte.

Exact.
 

C'est pas faux non plus, en même temps qui sait quelle interface bizarre cet afficheur peut avoir... Faut plus d'infos pour en être sûr.

Merci Pour toutes vos indications. Je vais tester.
Effectivement c'est assez bizarre mais l'afficheur fonctionne réellement comme cela. Cela m'a été indiqué par le fournisseur et j'ai pu le constater avec un logiciel qui m'indique ce que j'envoie sur le port COM. Il faut abbsolument qu'il soit en hexa (ils m'ont fournit un petit logiciel où l'on tape son texte et/ou on peut tester les trames en hexa).
 
Avec mon premier essai, mes octets en hexa étaient convertit en ASCII et ça ne fonctionnait pas.

Il est prise de tête, je vous l'accorde

En tous les cas, la conversion hexadécimale n'est qu'une petite partie du programme. Il faudrait savoir à quoi sert chaque octet, et pour cela il faut la datasheet/handbook/user manual ou tout autre documentation technique.

Oui. Après le détail de la trame, je le connais. donc ça ça va

En fait je crois que les gens ont juste très envie que tu partages la référence/specs de ton mystérieux afficheur .

Je veux bien mais question bête: Comment fait-on pour joindre un fichier ici (je ne trouve pas l'icône joindre/ajouter un fichier) :-)

Il n'y en n'a pas. Il faut l'uploader quelque part (si il n'est pas déjà sur le net) et copier coller le lien.

 
Exactement, je n'aurais pas mieux dit !    
Ce n'est pas qu'on soit curieux, hein ...
Mais cela titille notre envie d'en savoir un peu plus  !    

Voici les manuels, exemples et protocols:
 
https://wetransfer.com/downloads/71 [...] 622/d90c0d  
 

Pour moi il faut bien envoyer des octets, pas leur représentation hexadécimale en ASCII.
 
Après les docs sont vraiment mal écrites... voir pas français du tout!

Effectivement, il faut que la trame envoyé soit lu tel quel par l'afficheur (si j'envoie EF par exemple, il doit lire EF).
 
Mon souci actuel est que je n'arrive pas, pour le moment, à trouver une fonction qui me le permette (par exemple si j'écris 24(hexa) quand je lis ce qui est envoyé via le port COM, il envoie 36).
 
J'ai essayé la fonction %x  
avec (%x,mavariable)
 
dans ma variable, je charge la valeur 36 (24 en Hexa)
 
Sur le traceur je vois bien dans la partie qui correpond à la trame de départ que j'ai écrit 24. Par contre la valeur envoyé est toujours 36.
 
I am lost

Le "traceur" affiche la valeur en décimal (24h = 36d), donc tout va bien.

Pour débuger la liaison RS432 je te conseille un logiciel capable d'afficher en Hexadécimal, par exemple l'excellent Terminal https://sites.google.com/site/terminalbpp/

Je ne comprend plus rien, on envoie de l'hexa en ASCII ou du binaire affiché en hexa au final ?

Au final sur le port COM, ce qui doit être envoyé est de l'hexa:
 
24 57 52 4C 3E 2A 00 41 01 00 00 00 00 00 00 68 61 00 4D 41 49 4E 00 00 00 00 20 00 0C 24 0A 02 08 06 EF F1 01 F1 F2 01 F2 48 45 4C 4C 4F EF 56 F7 FE F4  
 
Si ça se trouve, dans le programme en C, je dois peut-être envoyé la trame sous une autre forme que le port COM la convertisse correctement (je suis un novice dans ce domaine)

Quand je lis la doc, c'est bien du "binaire", mais évidemment la doc utilise des représentations hexa partout.
 
Mais la doc en français est horrible.
 
Rien que le début:

Tu t'emmêles les pinceaux.
 
Sur le port COM tu doit envoyer des octets. Chaque octet est codé sur 8 bits et on utilise souvent l'hexadécimal pour représenter un octet car c'est pratique.
 
Mais "ce qui doit être envoyé est de l'hexa" cela ne signifie rien. Ce qui doit être envoyé ce sont des octets dont la documentation te donne une représentation en hexadécimal.
 
Quand la documentation te parle d'envoyer 24 57 52 4C, tu doit envoyer 4 octets: 24h puis 57h puis 52h puis 4Ch
Ce qui est équivalent à envoyer 36 puis 87 puis 82 puis 76, en décimal.
 
C'est la même chose, sauf que la première fois j'utilise l'hexadécimal et la deuxième le décimal. Ce n'est qu'une représentation, un convention d'écriture, mais les données binaires envoyées sur le lien COM sont les mêmes.

Oui, je commence à m'emmeler je crois .
 
Là le fournisseur, qui ne sait pas m'envoyer d'exemple en langage C, m'a envoyé un logiciel qui permet d'envoyer du texte (pas un logiciel programmable mais juste une application). Avec le traceur du port  COM je peux voir ce qui est est envoyé:
 

Voici ce qui est relevé (j'ai mis seulement les 5 premiers octets pour plus de lisibilité):
 
24 57 4C 3E     (ce qui est envoyé par le port COM)    
$WRL> (envoyé par leur logiciel vers le port COM)

Là encore, je ne peux qu'être d'accord avec h3bus (et cela correspond à ce que l'on pressentait dès le départ).
 
Au final, cela aurait même tendance à simplifier la chose, pour peu que l'afficheur attende directement les codes ascii, on envoie le contenu de la chaîne C (avec ou sans le zéro terminal, c'est à voir) et c'est marre.
 
(Note : je n'arrive pas à télécharger le document depuis le boulot Un mot clé pour trouver la datasheet en anglais directement ?)

La encore c'est la même chose, d'abord représenté en hexadécimal, puis en ASCII.
 
Regarde ici: http://www.table-ascii.com
 
Tu verra que 24h c'est $
57h c'est W
Etc...

Là je viens de faire l'essai. Dans mon programme en C, j'ai envoyé la trame $WRL>  et le port COM a bien écrit:
 
24 57 52 4C 3E       (j'avais oublié le 52 dans mon message précédent)
 
Je dois donc convertir chaque octet de ma trame avec son équivalent  ASCII avant de l'envoyer.
 
Je vais faire l'essai demain et je vous tiens au courant. Merci pour vos orientation
 
PS: la doc n'est pas téléchargeable sur Internet, le fournisseur me l'avait fournit directement.

Sinon en C tu peux écrire:
"\x24\x57\x52" etc

et le compilateur va faire la conversion pour toi.

Bonjour.
 
En informatique "classique" je cois, mais je suis pas certain, vu que "classique" ça dépend... On passe jamais que du binaire.
 
Après tout c'est une question de dimension.
 
un mot de dimensions 4 pour passer de l'hexa ou un petit entier signé, c'est toujours un mot de 4 dimensions, ou quatre bits, mais là encore il peut y en avoir une ceratine quantité.
 
Juste pour re- cadrer.

 
 
 
A chaque trame on compile...

Un tableau :
 
   Avec un element dans chaque case.
   Ces elements sont construit ainsi :
        un caractère de la table ascii.
        le code decimal (non obligatoire)
        le code Hexadécimal.
 
Faut initialiser le tableau avec la table ascii.
 
et tu fait une fonction char to hexa qui prend un caractère et qui retourne le code exa ou ou l'inverse mutuel.

Désolé, c'est du grand n'importe quoi.

Si j'ai une chaîne de caractères en C j'ai déjà les codes ASCII des caractères utilisés en mémoire! (chaîne de caractère en C = tableau avec les codes ASCII et un zéro final très important) Et si je veux convertir des nombres entre le décimal et l'héxa inutile de faire des tableaux (sauf peut-être pour des raisons de vitesse mais dans ce cas présent c'est certainement pas un problème), il y a des fonctions toutes faites pour ça.

edit: Après avoir vu ton (localghost) premier message sur ce sujet je plussoie h3bus et sa formulation: garde tes idées stupides, c'est incompréhensible et ne fait qu'embrouiller les gens.

Si tu pouvais éviter de l'embrouiller encore plus avec des idées stupides, merci.

Edit: @localghost

Vous êtes deux ronchons "embrouillés" alors !
 
Je prend note ça interresse tout le monde je pense.

Désolé, d'habitude tes élucubrations me font marrer mais venir poser ta pêche sur le topic d'un mec qui risque de patauger un bon bout de temps si il ne prend pas le problème du bon côté, ouai ça me rends "ronchon"

 
Donc ça n'a rien à voir avec moi.
 
Donc tu me laisse tranquille.
 
 
Ok ?