Discussion :

[pfeuh]

Bonjour,

Bossant dans l'embarqué, j'ai développé un driver COM 9 bits multidrop pour capteurs (protocole archi utilisé dans l'industrie) avec son pendant sur PC en python. En gros, la com est en 8 bits avec un 9ème bit à 1 (Mark) pour chaque premier octet de la trame envoyée par le maitre. Cet octet est le numéro de canal, chaque esclave se réveille et va voir si c'est lui qui est concerné. Tous les autres octets en émission ont leur 9ème bit à 0 (Space). S'il est concerné, il reçoit la trame, execute la commande et répond. S'il n'est pas concerné, il se rendort immédiatement.

Côté PC, c'est simple dans le principe, mais Bill nous met des bâtons dans les roues. le PC (qui sert de maitre) doit envoyer un 9ème bit à 1 pour le premier octet (pour les autres, même principe mais raisonnement inverse). Il doit donc calculer la parité et en fonction du résultat configurer le port série en parité paire ou impaire de façon à ce que le 9ème bit soit un 1 (Mark). C'est cette commutation dans le mode de travail qui prend un temps fou (valeurs généralement constatées, de 50 à 100msec et malheureusement parfois beaucoup plus...) et fait chuter la vitesse à 10 octets secondes, sans parler de ce qui est beaucoup plus grave, la gestion du time out dans les microcontrôleurs embarqués.

L'idée, ce serait donc de courcuircuiter la couche de Bill pour écrire directement dans les registres de l'UART. Quelqu'un aurait une piste? En tout cas, merci d'avoir lu jusqu'ici!

A+

pfeuh

[jacklafrip]

Il me semble que depuis Windows 98, c'est totalement impossible...
Désolé pour toi...

PS : j'ai déjà écris justement pour des liaisons PC-micro, et j'ai toujours pu discuter à 19200...

[pfeuh]

Il me semble que depuis Windows 98, c'est totalement impossible...
Désolé pour toi...

PS : j'ai déjà écris justement pour des liaisons PC-micro, et j'ai toujours pu discuter à 19200...

Oui, moi aussi, mais avec des données 8 bits il n'y a jamais de problème, même en passant via une com USB... Comme je l'ai dit plus haut, c'est en changeant le mode de parité (puisque les Mark-Space ne sont pas gérés par windows) en cours de route que les problèmes apparaissent.

A+

Pfeuh

[Emmanuel Delahaye]

Bonjour,

Bossant dans l'embarqué, j'ai développé un driver COM 9 bits multidrop pour capteurs (protocole archi utilisé dans l'industrie) avec son pendant sur PC en python. En gros, la com est en 8 bits avec un 9ème bit à 1 (Mark) pour chaque premier octet de la trame envoyée par le maitre. Cet octet est le numéro de canal, chaque esclave se réveille et va voir si c'est lui qui est concerné. Tous les autres octets en émission ont leur 9ème bit à 0 (Space). S'il est concerné, il reçoit la trame, execute la commande et répond. S'il n'est pas concerné, il se rendort immédiatement.

Côté PC, c'est simple dans le principe, mais Bill nous met des bâtons dans les roues. le PC (qui sert de maitre) doit envoyer un 9ème bit à 1 pour le premier octet (pour les autres, même principe mais raisonnement inverse). Il doit donc calculer la parité et en fonction du résultat configurer le port série en parité paire ou impaire de façon à ce que le 9ème bit soit un 1 (Mark). C'est cette commutation dans le mode de travail qui prend un temps fou (valeurs généralement constatées, de 50 à 100msec et malheureusement parfois beaucoup plus...) et fait chuter la vitesse à 10 octets secondes, sans parler de ce qui est beaucoup plus grave, la gestion du time out dans les microcontrôleurs embarqués.

L'idée, ce serait donc de courcuircuiter la couche de Bill pour écrire directement dans les registres de l'UART. Quelqu'un aurait une piste? En tout cas, merci d'avoir lu jusqu'ici!

La seule solution industrielle est d'installer un autre driver de com qui gère le Mark-space. Ca doit exister dans le commerce, sinon, il faut le faire soi même

Penser à désactiver le driver par défaut.

[pfeuh]

La seule solution industrielle est d'installer un autre driver de com qui gère le Mark-space. Ca doit exister dans le commerce, sinon, il faut le faire soi même

Penser à désactiver le driver par défaut.

Salut Emmanuel,

Justement, sauf erreur de ma part, ça n'existe pas tout prêt dans le commerce, mon intention est bien d'en écrire un. Et c'est là que je cherche des pistes, du genre comment arriver à écrire dans la zone d'entrées-sorties comme on le faisait il y a 20 ans, tout en désactivant les drivers installés par défaut. Je pense que le système de "Plug & Play" verrouille toute la zone i/o, non?

A+

Pfeuh

[Emmanuel Delahaye]

Justement, sauf erreur de ma part, ça n'existe pas tout prêt dans le commerce, mon intention est bien d'en écrire un. Et c'est là que je cherche des pistes, du genre comment arriver à écrire dans la zone d'entrées-sorties comme on le faisait il y a 20 ans, tout en désactivant les drivers installés par défaut. Je pense que le système de "Plug & Play" verrouille toute la zone i/o, non?

Ecrire un driver Windows, c'est un métier !

Ca commence par l'acquisition du DDK (je crois que c'est gratuit) sur le site de développement de Microsoft (MSDN). Tu y trouveras tout les renseignements nécessaires à l'écriture d'un driver.

Pour de l'aide, le mieux est de s'adresser au bon forum :

http://www.developpez.net/forums/forumdisplay.php?f=16

Au fait, tu es obligé de faire ça sous Windows ? Sous Linux, ça devrait être beaucoup plus simple, et si ça se trouve, ça fonctionne déjà comme il faut. Si ton application est écrite en GTK+, il est très simple de la faire tourner sous Linux...

[pfeuh]

Merci de ta réponse. Je vais me débrouiller avec ça. Oui, je suis obligé de le faire sous Windows... Les clients en général ne sont toujours pas prêts à monter une machine Linux pour faire tourner un programme. Je n'ai d'ailleurs absolument aucun doute sur le fait que ça tournerait beaucoup plus facilement sous Linux.

A+

Pfeuh