pyserial et "timeout" sur écriture

Le
hg
Bonjour,

Si ouverture de COM (Windows) avec suppor RTS/CTS et personne au bout de
la ligne, pyserial semble bloquer advitam eternam.

une solution ?

merci,

hg
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
hg
Le #603972
MCI, Shadok Gouroudoudou wrote:

Bonsoir !

personne au bout de la ligne ... bloqué
une solution ?


La seule que j'ai trouvée : utiliser un thread. Seul le thread restera
bloqué, et la partie principale du programme continuant à tourner.









--
@-salutations

Michel Claveau


Merci,

Mais que fais-tu si l'utilisateur ne re-connectes pas le matériel? ... le
thread est bloqué et donc le soft ne peut, à ma connaissance, se terminer
correctement.

hg


MCI, Shadok Gouroudoudou
Le #603747
Bonsoir !

personne au bout de la ligne ... bloqué
une solution ?


La seule que j'ai trouvée : utiliser un thread. Seul le thread restera
bloqué, et la partie principale du programme continuant à tourner.









--
@-salutations

Michel Claveau

Méta-MCI
Le #603501
Re !


Un thread, tournant ou bloqué, n'empêchera pas le programme (principal) de
se terminer.
Cela arrêtera le thread.


@+

MCI
hg
Le #609639
Méta-MCI wrote:

Re !


Un thread, tournant ou bloqué, n'empêchera pas le programme (principal) de
se terminer.
Cela arrêtera le thread.


@+

MCI


Je pense que les problèmes que j'ai rencontré étaient liés à des threads
bloqués sur des sockets.

La solution me rend tout de même nerveux: pleins d'effets de bords.

hg

hg
Le #609555
MCI, Shadok Gouroudoudou wrote:

Re !

Pour être franc, j'ai eu pas mal de problèmes, avec PySerial sous
windows. Je ne l'utilise plus.

Dans certains cas, c'était sans importance. Mais, pour d'autres, j'ai
dû opter pour d'autres solutions. J'en ai utilisé deux :
- utiliser le composant MsComm, via PyWin32
- utiliser des convertisseurs RS-232c <--> Ethernet, et on utilise
les sockets TCP/IP pour dialoguer avec les périphériques.

Actuellement, je mise sur la dernière solution, car ça me permet une
grande souplesse (ça passe par WiFi, c'est utilisable depuis n'importe
quel poste du réseau, voire plus loin, via Internet ; etc.)










--
@-salutations

Michel Claveau


Merci,

Hélas pas possible pour moi ... mini-pc (TPE) qui discute avec une
imprimante ticket de base (le client me tuerais si je lui demandais
d'investir)

J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est
déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et
pourrai toujours ajouter de la tempo. si j'en rencontre.

hg

MCI, Shadok Gouroudoudou
Le #609549
Re !

Pour être franc, j'ai eu pas mal de problèmes, avec PySerial sous
windows. Je ne l'utilise plus.

Dans certains cas, c'était sans importance. Mais, pour d'autres, j'ai
dû opter pour d'autres solutions. J'en ai utilisé deux :
- utiliser le composant MsComm, via PyWin32
- utiliser des convertisseurs RS-232c <--> Ethernet, et on utilise
les sockets TCP/IP pour dialoguer avec les périphériques.

Actuellement, je mise sur la dernière solution, car ça me permet une
grande souplesse (ça passe par WiFi, c'est utilisable depuis n'importe
quel poste du réseau, voire plus loin, via Internet ; etc.)










--
@-salutations

Michel Claveau
hg
Le #609455
NicolasP wrote:


J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est
déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et
pourrai toujours ajouter de la tempo. si j'en rencontre.



T'as shunté en hard, avec ton fer à souder ? Parce que si c'est le cas, tu
peux désactiver la gestion de RTS/CTS dans pyserial. C'est plus simple.



;-) oui c'est effectivement plus simple ... et puis avec mon clavier, je me
brûle jamais.


Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?



Oui (pas testé) mais n'aurais-je pas le même problème ?

Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise
dans une appli qui ne transmet que quelques Ko de temps en temps et sans
contrôle de flux.



Avec RTS/CTS ? si oui comment gères-tu un périphérique déconnecté ?

Nicolas



hg


hg
Le #609454
hg wrote:

Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?



Oui (pas testé) mais n'aurais-je pas le même problème ?


en fait surement pas effectivement ... l'UART devrait accepter l'XON de
pydev sans crier ... et puisque aucun XOFF ne reviendra ...


je vais tester merci

hg


NicolasP
Le #607871

J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est
déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et
pourrai toujours ajouter de la tempo. si j'en rencontre.



T'as shunté en hard, avec ton fer à souder ? Parce que si c'est le cas, tu peux désactiver la gestion de RTS/CTS dans pyserial. C'est plus simple.

Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?

Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise dans une appli qui ne transmet que quelques Ko de temps en temps et sans contrôle de flux.

Nicolas

NicolasP
Le #607039

Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?



Oui (pas testé) mais n'aurais-je pas le même problème ?


A priori non.

Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise
dans une appli qui ne transmet que quelques Ko de temps en temps et sans
contrôle de flux.



Avec RTS/CTS ? si oui comment gères-tu un périphérique déconnecté ?



Ben c'est un cas très particulier où c'est l'utilisateur qui gère. C'est une appli qui n'est pas grand public évidemment.

Nicolas


Publicité
Poster une réponse
Anonyme