|
| Iniciado por dakota99, 24,jul. 2019 15:57 - 4 respuestas |
| |
| | | |
|
| |
Miembro registrado
34 mensajes |
|
| Publicado el 24,julio 2019 - 15:57 |
Bonjour,
Je souhaiterais lire les données arrivant sur le port série. Le pc sur lequel est installé Windev est connecté à un Arduino qui envoie une chaîne de caractères « TEST123456789 » toutes les 2 secondes.
Si les données sont lues avec un logiciel tel que Putty ou Hterm, pas de problème la chaîne « TEST123456789 » est récupérée correctement :
<\n>TEST1234567890<\r>
<\n>TEST1234567890<\r>
<\n>TEST1234567890<\r>
Par contre dans Windev, la chaîne est tronquée de manière tout à fait aléatoire. Quelques exemples des chaînes telles qu'elles sont affichées dans le trace :
---
TEST1234567890<\r><\n>
---
TEST1234
---
567890<\r><\n>TEST1234567890<\r>
---
<\n>TEST123
---
4567890<\r><\n>TEST1234567890<\r>
---
<\n>TEST123
---
4567890<\r><\n>TEST1234567890
---
<\r><\n>TEST12
---
34567890<\r><\n>TEST123456
Les paramètres dans Putty sont les suivants :
COM30 vitesse 9600 bauds, Data Bits 8, Stop bits 1, Parity None, Flow control : XON/XOFF
Pcm1=30
ECm1 = sOuvre(PCm1, 2000, 2000,sTimeoutDéfaut,Vrai)
SI ECm1 = Vrai ALORS
sFixeParamètre(PCm1,9600, 0, 8, 0)
sEvénement(PCm1, sEveCaractèreReçu, "LectureCm1")
FIN
Procedure LectureCm1()
u est un entier = sDansFileEntrée(PCm1)
m = sLit(Pcm1, u)
Trace(m)
Trace("---")
Quelqu'un aurait-il une suggestion pour lire correctement ces données venant de l'Arduino ?
Merci pour votre temps. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
948 mensajes |
|
| Publicado el 24,julio 2019 - 16:18 |
Bonjour
vu votre code c'est tout à fait normal ! Quand l'événement "sEveCaractèreReçu" se déclenche vous n'affichez avec l'instruction Trace que les "derniers" octets lu d'où cette "impression" de coupure.
Utilisez une variable Globale BufferRx dans laquelle vous ajoutez les caractères reçu BufferRx += sDansFileEntrée(PCm1)
puis vous analysez BufferRx : es que j'ai \n si oui es que j'ai \r si oui prendre les données entre pour les afficher et supprimer ce bloc de BufferRx
note
\n => caract(0x0a) et \r => caract(0x0d)
--
L'urgent est fait, l'impossible est en cours. Pour les miracles, prévoir un délai.
Quand un utilisateur vous a aidé, n'oubliez pas de le remercier... |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
34 mensajes |
|
| Publicado el 24,julio 2019 - 20:47 |
Bonjour Philippe,
Merci pour votre réponse.
Effectivement je peux lire un caractère à la fois et l'ajouter à un buffer.
Mais quand c'est possible, je préfère faire simple.
J'ai déjà communiqué avec d'autres appareils en série et il suffisait de faire un sLit(Pcm1,sDansFileEntrée(PCm1)) pour récupérer l'entièreté du buffer.
Dans ce cas je ne comprends pas pourquoi une chaîne si courte est à chaque fois amputée. Selon mon point de vue, cela n'est pas normal.
Mais encore merci pour votre commentaire. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
948 mensajes |
|
| Publicado el 25,julio 2019 - 15:12 |
Bonjour
1° j'ai fait une grosse erreur, ce n 'est pas BufferRx += sDansFileEntrée(PCm1) qu'il faut faire mais BufferRx += sLit(PCm1, sDansFileEntrée(PCm1)
2° votre chaine n'est pas amputée c'est juste l'instruction Trace qui fait cet effet
mettez un champ de saisie multi-ligne SAI_BUF et alimentez le avec SAI_BUF += sLit(PCm1, sDansFileEntrée(PCm1)
Si votre pc est une bête de course et qu'il ne fait rien d'autre qui lui prend du temps alors il exécutera la procédure avant que la trame ne soit complètement envoyée. Par exemple une trame de 16 octets à 9600, 1 start, none parity, 8 data bits, 1 stop met 0.0175s à être envoyée (58 Hertz)
--
L'urgent est fait, l'impossible est en cours. Pour les miracles, prévoir un délai.
Quand un utilisateur vous a aidé, n'oubliez pas de le remercier... |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
34 mensajes |
|
| Publicado el 29,julio 2019 - 22:27 |
Bonjour Philippe,
Effectivement SAI_BUF += sLit(PCm1, sDansFileEntrée(PCm1) fonctionne.
Merci pour votre intervention. |
| |
| |
| | | |
|
| | | | |
| | |
|