[C++] Lire une trame hexa avec Readfile
Fermé
Lit seulement jusqu'a '00'
-
16 mars 2009 à 14:16
kingkouka Messages postés 1 Date d'inscription jeudi 29 avril 2010 Statut Membre Dernière intervention 29 avril 2010 - 29 avril 2010 à 16:14
kingkouka Messages postés 1 Date d'inscription jeudi 29 avril 2010 Statut Membre Dernière intervention 29 avril 2010 - 29 avril 2010 à 16:14
A voir également:
- [C++] Lire une trame hexa avec Readfile
- Lire le coran en français pdf - Télécharger - Histoire & Religion
- Lire epub - Guide
- Lire fichier bin - Guide
- Editeur hexa - Télécharger - Édition & Programmation
- Lire iso - Guide
10 réponses
Char Snipeur
Messages postés
9696
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
16 mars 2009 à 16:26
16 mars 2009 à 16:26
Salut.
Tu peux créer ta propre fonction readfile qui lit la trame jusqu'à obtenir le FF final.
Une fonction readCom() faisant appel à readFile().
Tu peux créer ta propre fonction readfile qui lit la trame jusqu'à obtenir le FF final.
Une fonction readCom() faisant appel à readFile().
Char Snipeur
Messages postés
9696
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
17 mars 2009 à 08:27
17 mars 2009 à 08:27
Je n'ai jamais fait de programmation de ce genre, mais je pense que ça doit être du même genre que lire une socket ou un fichier, ou un flux standard.
Il doit y avoir un buffer stokant les trame en attente d'être lu.
Je suppose que la fonction ton tu me parle agit un peu comme les autre fonctions de flux, le lisant jusqu'à recontrer la fin ou un autre critère d'arrêt.
Ce que je te dit, c'est de relancer readFile jusqu'à avoir FF.
Genre :
readCom(){
buffer[0]=readFile();
While(dernier caractère du buffer courant != FF)
buffer[i]=readFile();
//recollage des différent buffer
return buffer_recoller;
}
Enfin, c'est du langage "algorithmique", si tu vois ce que je te suggère. Mais ça ne fonctionne peut être pas.
Il doit y avoir un buffer stokant les trame en attente d'être lu.
Je suppose que la fonction ton tu me parle agit un peu comme les autre fonctions de flux, le lisant jusqu'à recontrer la fin ou un autre critère d'arrêt.
Ce que je te dit, c'est de relancer readFile jusqu'à avoir FF.
Genre :
readCom(){
buffer[0]=readFile();
While(dernier caractère du buffer courant != FF)
buffer[i]=readFile();
//recollage des différent buffer
return buffer_recoller;
}
Enfin, c'est du langage "algorithmique", si tu vois ce que je te suggère. Mais ça ne fonctionne peut être pas.
Moi je ne fonctionne pas caractère par caractère.
Dans mon readFile je lui indique qu'il doit lire 11 Octets ( C'est plus simple de cette manière pour la suite de mon code)
Il me le fait bien en temps normal, sauf s'il il rencontre 00, alors la sera la fin de la lecture.
Dans mon readFile je lui indique qu'il doit lire 11 Octets ( C'est plus simple de cette manière pour la suite de mon code)
Il me le fait bien en temps normal, sauf s'il il rencontre 00, alors la sera la fin de la lecture.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
J'ai compris partiellement pourquoi ma chaine se terminait au 00.
Mon buffer est de type char Rx[12].
Char est donc une chaine AZT ( A Zéro Terminal ), de ce fait, la lecture de ma trame se fait bien entièrement mais mon buffer lui s'arretera à se Zéro terminal (principe des chaine AZT:
Ex : Lecture = 12 48 94 75 00 48 97 53 20 15 FF
mais BufferRx = 12 48 94 75 00 <-- (zéro terminal)
Comment puis-je contourné le problème alor que readfile me demande un buffer de type Char ??
Mon buffer est de type char Rx[12].
Char est donc une chaine AZT ( A Zéro Terminal ), de ce fait, la lecture de ma trame se fait bien entièrement mais mon buffer lui s'arretera à se Zéro terminal (principe des chaine AZT:
Ex : Lecture = 12 48 94 75 00 48 97 53 20 15 FF
mais BufferRx = 12 48 94 75 00 <-- (zéro terminal)
Comment puis-je contourné le problème alor que readfile me demande un buffer de type Char ??
kingkouka
Messages postés
1
Date d'inscription
jeudi 29 avril 2010
Statut
Membre
Dernière intervention
29 avril 2010
29 avril 2010 à 16:14
29 avril 2010 à 16:14
je cherche ce genre de code, pour lire sur le port COM des données venant d'un appareil..
peux tu me fournir ton code à l'adresse: kingkouka2006@yahoo.fr
merci
peux tu me fournir ton code à l'adresse: kingkouka2006@yahoo.fr
merci
Char Snipeur
Messages postés
9696
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
17 mars 2009 à 09:40
17 mars 2009 à 09:40
Salut.
Je ne sais pas où tu as été péché ça. char est un type entier comme un autre qui n'es interprété en caractère que par certaines fonction.
Donne ton code source, mais il n'y a pas de raison pour que ça fasse ce que tu dit.
Je ne te dit pas de fonctionner caractère par caratère, mais de relancer le readFile() si tu rencontre 00.
Enfin bon, si tu ne veux pas de conseil, j'arrête là.
Je ne sais pas où tu as été péché ça. char est un type entier comme un autre qui n'es interprété en caractère que par certaines fonction.
Donne ton code source, mais il n'y a pas de raison pour que ça fasse ce que tu dit.
Je ne te dit pas de fonctionner caractère par caratère, mais de relancer le readFile() si tu rencontre 00.
Enfin bon, si tu ne veux pas de conseil, j'arrête là.
J'ai pêché sa dans mes cours! révise tes chaines de caractère.
Je n'ai jamais dit que je ne voulais pas de conseil!
Mais si tu veux t'arreter la je t'en prie, je vais poursuivre ma recherche dans d'autre forum plus compétent.
Je n'ai jamais dit que je ne voulais pas de conseil!
Mais si tu veux t'arreter la je t'en prie, je vais poursuivre ma recherche dans d'autre forum plus compétent.
Char Snipeur
Messages postés
9696
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
17 mars 2009 à 10:12
17 mars 2009 à 10:12
N'accuse pas d'incompétence les gens qui en savent plus que toi (surtout que tu parles encore de "cours").
char* est une AZT comme tu dit à partir du moment où on la considère en temps que telle. Du point de vue informatique, il s'agît d'un type comme un autre, et la terminaison d'une chaîne par 00 n'est qu'une convention qui s'applique lorsque la chaîne de type char est interprété/considérer comme une chaîne de caractère.
Le problème c'est qu'il est possible que readfile() considère qu'il doit lire une chaîne de caractère (je ne connais pas cette fonction, c'est une supposition) il est alors logique qu'il s'arrête en lisant 00 sur le buffer du COM.
Changer le type passé à la fonction ne servira strictement à RIEN.
Le problème, ou un similaire, se produit avec std::cin, ou les fonction gets associés : le buffer n'est lu que jusqu'à un certain niveau et s'arrête si il rencontre une espace ou un saut de ligne, il faut alors relancer la lecture pour avoir le nombre de donnés lues souhaité.
Attention, quand je parle de buffer, je parle d'un espace mémoire qui ne t'es pas directement accessible où sont stocké les valeurs provenant du port COM.
Il est aussi possible que la fonction considère le flux comme un flux de caractère, ça peut dépendre de la façon d'ouvrir le flux.
char* est une AZT comme tu dit à partir du moment où on la considère en temps que telle. Du point de vue informatique, il s'agît d'un type comme un autre, et la terminaison d'une chaîne par 00 n'est qu'une convention qui s'applique lorsque la chaîne de type char est interprété/considérer comme une chaîne de caractère.
Le problème c'est qu'il est possible que readfile() considère qu'il doit lire une chaîne de caractère (je ne connais pas cette fonction, c'est une supposition) il est alors logique qu'il s'arrête en lisant 00 sur le buffer du COM.
Changer le type passé à la fonction ne servira strictement à RIEN.
Le problème, ou un similaire, se produit avec std::cin, ou les fonction gets associés : le buffer n'est lu que jusqu'à un certain niveau et s'arrête si il rencontre une espace ou un saut de ligne, il faut alors relancer la lecture pour avoir le nombre de donnés lues souhaité.
Attention, quand je parle de buffer, je parle d'un espace mémoire qui ne t'es pas directement accessible où sont stocké les valeurs provenant du port COM.
Il est aussi possible que la fonction considère le flux comme un flux de caractère, ça peut dépendre de la façon d'ouvrir le flux.
Oui je parle encore de cours puisque je n'ai pas fini mes études, mais franchement je n'ai pas compris ta réaction! :o
Bref,
Oui j'ai vu quelque part qu'il fallait ouvrir le flux série en mode binaire et non pas en mode caractère.
Mais je ne vois pas comment procéder.
ReadFile() est une fonction de L'API32 pour ouvrir les flux vers les fichiers ( Le port Série sous Win etant considéré comme un fichier)
Mais j'ai bien peur qu'il ne puisse interprêter que le mode caractère.
Pour info, je lit mon port série jusqu'à FF (comme indiqué ci dessus) seul les problèmes viennent quand j'ai un octet à 00.
C'est pour cela que j'ai penser qu'il s'agissait d'une confusion avec le Zero terminal.
Bref,
Oui j'ai vu quelque part qu'il fallait ouvrir le flux série en mode binaire et non pas en mode caractère.
Mais je ne vois pas comment procéder.
ReadFile() est une fonction de L'API32 pour ouvrir les flux vers les fichiers ( Le port Série sous Win etant considéré comme un fichier)
Mais j'ai bien peur qu'il ne puisse interprêter que le mode caractère.
Pour info, je lit mon port série jusqu'à FF (comme indiqué ci dessus) seul les problèmes viennent quand j'ai un octet à 00.
C'est pour cela que j'ai penser qu'il s'agissait d'une confusion avec le Zero terminal.
Moi, j'ai bien compris sa réaction. Il ne fallait pas mettre d'huile sur le feu !
Quand tu as un octet à zéro, t'es-tu assuré que les autres octets n'avaient pas été mis dans le buffer? Comme l'a expliqué Char Snipeur, char* pointeur peut être considéré en tant que chaîne de caractères avec un caractère de terminaison (0), ou bien, et même d'abord, comme un tableau (ou buffer) de 11 caractères. Si ta fonction 'ReadFile' considère un buffer de 11 caractères, il les remplira même s'il y a des zéros et ainsi tu vas pouvoir lire ces 11 caractères, par exemple:
Mais moi, comme Char Snipeur, je ne suis pas très copain-copain avec la MFC; je ne puis d'aider plus.
Quand tu as un octet à zéro, t'es-tu assuré que les autres octets n'avaient pas été mis dans le buffer? Comme l'a expliqué Char Snipeur, char* pointeur peut être considéré en tant que chaîne de caractères avec un caractère de terminaison (0), ou bien, et même d'abord, comme un tableau (ou buffer) de 11 caractères. Si ta fonction 'ReadFile' considère un buffer de 11 caractères, il les remplira même s'il y a des zéros et ainsi tu vas pouvoir lire ces 11 caractères, par exemple:
for (int i=0; i<11; i++)
printf ("%X ", pointeur[i]);Si ta fonction 'ReadFile' s'arrête lorsqu'elle rencontre un '0', alors il faut effectivement la réécrire.
Mais moi, comme Char Snipeur, je ne suis pas très copain-copain avec la MFC; je ne puis d'aider plus.
Char Snipeur
Messages postés
9696
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
17 mars 2009 à 10:52
17 mars 2009 à 10:52
J'ai trouvé ça : https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile?redirectedfrom=MSDN
Moi et l'API windows ça fait deux, je trouve que c'est une belle implémentation de "pourquoi faire simple quand on peut faire compliqué".
Bon, essayons d'avancé sur ton problème.
Pour info, je lit mon port série jusqu'à FF (comme indiqué ci dessus) Comment le sais tu ?
seul les problèmes viennent quand j'ai un octet à 00. Comment sais tu que le reste de la trame n'est pas rempli.
Pour l'ouverture en mode binaire, il faut se reporter à la documentation de la fonction d'ouverture.
Pour y voir plus clair mets le bout de code qui pose problème, histoire d'avoir un truc plus concret.
Moi et l'API windows ça fait deux, je trouve que c'est une belle implémentation de "pourquoi faire simple quand on peut faire compliqué".
Bon, essayons d'avancé sur ton problème.
Pour info, je lit mon port série jusqu'à FF (comme indiqué ci dessus) Comment le sais tu ?
seul les problèmes viennent quand j'ai un octet à 00. Comment sais tu que le reste de la trame n'est pas rempli.
Pour l'ouverture en mode binaire, il faut se reporter à la documentation de la fonction d'ouverture.
Pour y voir plus clair mets le bout de code qui pose problème, histoire d'avoir un truc plus concret.
bonjour,
Concernant ce que tu dis,
La lecture s'arrete lorsque tu recois 00, au lieu de FF,
et bien c'est simple tu n'as qu'a complementer la valeur de l'ctet recu!
puis avant de l'utiliser dans ton traitement, tu le recomplemente!
de mes souvenir en c/c++ l'operateur de complémentation c'est (~ (valeur de l'octet recu) )
Amicalement,
Concernant ce que tu dis,
La lecture s'arrete lorsque tu recois 00, au lieu de FF,
et bien c'est simple tu n'as qu'a complementer la valeur de l'ctet recu!
puis avant de l'utiliser dans ton traitement, tu le recomplemente!
de mes souvenir en c/c++ l'operateur de complémentation c'est (~ (valeur de l'octet recu) )
Amicalement,
4 sept. 2009 à 10:43
Merci.
4 sept. 2009 à 11:57
Merci.