J'ai un soucis avec les fonctions du port série (ou émulation via USB)
de Windev (version 20 mais je pense que c'est pareil avec toutes les
version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps
sans contrôle de flux ni matériel ni logiciel (pas le choix).
Une première commande permet d'avoir la taille exacte du fichier, on
envoie une seconde commande pour initier la demande de transfert.
Un écho à la commande est reçu et après une petite tempo le flux arrive
en lecture.
La fin est détectée avec un timeout et/ou en vérifiant la taille du
fichier et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que
j'utilise depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer
tous les paramètres possibles (buffer, branchement d'un évenement avec
uniquement la lecture ou utilisation d'une boucle sans fin, paramètre
"temporisation"), il manque toujours 200 à 300 octets dans le fichier
(bizarement toujours situés à peu prêt au même endroit sans que j'ai pu
déterminer une raison, vers l'octet 4300.)
- Je peux exclure un problème matériel car si j'utilise un terminal
(hyperterminal, teraterm) tout se passe correctement.
- J'ai déjà testé avec succès une solution alternative en utilisant une
DLL payante facile à utiliser et performante
(http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre
avis :
- Une expérience similaire ? Une solution possible sans un composant
tiers ?
- Une autre référence de DLL ? (une solution opensource sans activeX à
enregistrer serait l'idéal).
Merci
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Le mercredi 11 mars 2015 10:59:30 UTC+1, Romain PETIT a écrit :
Bonjour,
Bonjour,
j'ecrit peut étre un peu tard, pourquoi ne pas utiliser un buffer hardware ( en téléphonie nous utilisons cela pour éviter la perte de données) il y a 2 com 1 in et 1 out cela permet de travailler avec un " fil de l'eau " même en cas de coupure.
Idée interessante mais peu applicable dans mon cas car il faudrait alors fournir le matériel à tous nos clients...
ps pour une telle vitesse un cable blindé et une connectique compléte sont peut étre nécessaire , rts cet cts ainsi que les autres pins doivente étre reliés , le shéma 2x3 et masse risque d'étre léger.
J'utilise un câble USB/RS232 FTDI de 2m (ou 3?), et ca fonctionne correctement (avec les API, pas avec Windev). Je peux avoir une erreur de checksum de temps en temps mais le gain de vitesse en passant de 19200 à 115200 compense largement l'inconvénient de devoir recommencer le téléchargement si cela survient..
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Le mercredi 11 mars 2015 10:59:30 UTC+1, Romain PETIT a écrit :
Bonjour,
Bonjour,
j'ecrit peut étre un peu tard,
pourquoi ne pas utiliser un buffer hardware ( en téléphonie nous utilisons
cela pour éviter la perte de données) il y a 2 com 1 in et 1 out cela
permet de travailler avec un " fil de l'eau " même en cas de coupure.
Idée interessante mais peu applicable dans mon cas car il faudrait
alors fournir le matériel à tous nos clients...
ps pour une telle vitesse un cable blindé et une connectique compléte sont
peut étre nécessaire , rts cet cts ainsi que les autres pins doivente étre
reliés , le shéma 2x3 et masse risque d'étre léger.
J'utilise un câble USB/RS232 FTDI de 2m (ou 3?), et ca fonctionne
correctement (avec les API, pas avec Windev). Je peux avoir une erreur
de checksum de temps en temps mais le gain de vitesse en passant de
19200 à 115200 compense largement l'inconvénient de devoir recommencer
le téléchargement si cela survient..
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Le mercredi 11 mars 2015 10:59:30 UTC+1, Romain PETIT a écrit :
Bonjour,
Bonjour,
j'ecrit peut étre un peu tard, pourquoi ne pas utiliser un buffer hardware ( en téléphonie nous utilisons cela pour éviter la perte de données) il y a 2 com 1 in et 1 out cela permet de travailler avec un " fil de l'eau " même en cas de coupure.
Idée interessante mais peu applicable dans mon cas car il faudrait alors fournir le matériel à tous nos clients...
ps pour une telle vitesse un cable blindé et une connectique compléte sont peut étre nécessaire , rts cet cts ainsi que les autres pins doivente étre reliés , le shéma 2x3 et masse risque d'étre léger.
J'utilise un câble USB/RS232 FTDI de 2m (ou 3?), et ca fonctionne correctement (avec les API, pas avec Windev). Je peux avoir une erreur de checksum de temps en temps mais le gain de vitesse en passant de 19200 à 115200 compense largement l'inconvénient de devoir recommencer le téléchargement si cela survient..
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
