Discussion :

[RTN14]

Bonjour,

Je ne suis pas très doué en C++ et je cherche à savoir s'il est possible d'accéder directement à la broche Tx d'un port UART ou COM sans protocole. Je dois en effet envoyer des signaux sur cette broche sans start/stop-bits et à la cadence que je souhaite. J'ai déjà vu que c'était possible via une DLL particulière, mais la particularité de mon travail est qu'il doit tourner sur Windows CE. Existe-t'il une fonction (comme WriteFile) pour faire cela?

Merci

PS: j'utilise les MFC

[RTN14]

Remarque, le but est de jouer avec une LED IR

Bon, j'ai creusé un peu plus.
J'ai trouvé ceci, d'où ma question: devrais-je travailler en asynchrone?
Ici, si je comprends bien, il se sert de WriteFile pour jouer uniquement sur CTS et RTS. Est-ce que cette fonction me permettrait de "jouer" sur Tx?

[Mac LAK]

Est-ce que cette fonction me permettrait de "jouer" sur Tx?

Non. TX est une broche conditionnée par le protocole RS-232, donc encodée, donc non pilotable directement.
Les broches usuellement utilisées pour ça sont effectivement CTS/RTS.

Après, peut-être que ton UART possède une fonction pour passer toutes les broches en mode TTL, mais en général, ce n'est jamais le cas. Cf. la datasheet de l'UART en question pour le savoir.

Sinon, il te faut connaître l'encodage physique sur les fils (usuellement, c'est un [ame=http://fr.wikipedia.org/wiki/Codage_NRZ]codage NRZ[/ame] pour la RS-232), et faire la manip suivante :

• Configurer le port pour n'utiliser aucun bit de parité, 8 bits de données et aucun contrôle de flux.
• Régler la vitesse de transmission à un débit adéquat, usuellement le plus vite possible.
• Mettre un seul bit de stop.
• Lancer un thread qui va maintenir une émission constante de 0 ou de 1 (suivant l'état désiré) sur la liaison.
• Lorsque tu voudras changer l'état de la broche TX, il te faudra modifier le pattern émis (en général un octet) : c'est pour que ce soit le plus rapide possible qu'il faut émettre à la vitesse maximale.
• Dans tous les cas, les bits de start/stop vont te mettre la zone dans ta transmission. Ce n'est pas (trop) gênant pour allumer/éteindre une LED, mais c'est critique pour quelque chose qui compterait les fronts montants / descendants.

Bref, à ta place, j'utiliserais plutôt CTS/RTS quand même... Ou le port parallèle si tu en as un, qui est très très nettement plus adapté à ce genre d'exercice.

[RTN14]

Merci pour ta réponse.
Malheureusement le port UART ne possède que Rx/Tx/GND et il n'y a pas de parrallèle. Et comme je dois déjà utiliser un PIC sur la carte externe, je vais finalement "simplifier" en me servant du PIC pour commander la LED et prendre un PIC avec un UART.
Merci

[Mac LAK]

Sinon, tu as aussi la solution de passer par un boitier USB<->RS-232C (le C indique en général explicitement qu'il y a les broches de contrôle), qui sera vu par ton WinCE exactement comme un port COM habituel.

Autre solution, si tu as la possibilité de faire un montage électronique : utiliser le niveau du TX (comme je te l'ai indiqué précédemment) mais l'expédier sur un filtre hardware (genre monostable redéclenchable) afin de "lisser" le niveau, et donc d'effacer les bits de start/stop de tes trames. Il te suffit de régler la durée du filtre et la vitesse du bus de façon à avoir un délai de réaction adéquat pour ta led. En ce cas, tu auras en sortie du filtre, à la durée du filtre près, un niveau logique librement définissable.

A toi de voir derrière quels sont tes besoins réels, le prix que tu es prêt à mettre dedans (ou le budget alloué), etc.

[RTN14]

Il n'y a qu'un seul port usb de prévu sur le terminal et donc il doit pouvoir rester libre pour le client.
Lisser les bits starts et stop peut être intéressant, mais étant donné que les signaux sont sur plusieur octets, cela va créer des "trous" dans les trames et j'ai donc de forte chance que le récepteur (non modifiable car TV) prennent des bits en trop, correspondant au temps desstart et stop bits

Mais merci tout de même pour tes coneils, ça pourra peut-être me servir une autre fois!

[Mac LAK]

Il n'y a qu'un seul port usb de prévu sur le terminal et donc il doit pouvoir rester libre pour le client.

C'est pour ça que l'on a inventé les hubs USB...

Lisser les bits starts et stop peut être intéressant, mais étant donné que les signaux sont sur plusieur octets, cela va créer des "trous" dans les trames et j'ai donc de forte chance que le récepteur (non modifiable car TV) prennent des bits en trop, correspondant au temps desstart et stop bits

Tout dépend de la durée de ton filtre, de la vitesse de ta RS-232, et enfin de la vitesse désirée sur la modulation de la led IR...
Il est certain que si tu dois piloter la led à une vitesse élevée par rapport à l'UART (ex : 100.000 bauds), c'est très mal barré. Si (cas plus probable) tu es à un équivalent de 200 / 300 bauds en IR, c'est très très largement faisable.
Mais pour poursuivre cette piste, il faudrait les vitesses requises pour l'IR, l'encodage (sûrement un Manchester ou équivalent), et le niveau de tolérance accepté par ton protocole IR (équivalent d'une clock quelque part ? Uniquement sur détection de fronts ?).

[RTN14]

C'est pour ça que l'on a inventé les hubs USB...

Sauf que le port est tout pourri, il respecte même pas la norme 1.0 (mauvais plus and play,...), il est mal placé,... On l'aime pas!

Tout dépend de la durée de ton filtre, de la vitesse de ta RS-232, et enfin de la vitesse désirée sur la modulation de la led IR...
Il est certain que si tu dois piloter la led à une vitesse élevée par rapport à l'UART (ex : 100.000 bauds), c'est très mal barré. Si (cas plus probable) tu es à un équivalent de 200 / 300 bauds en IR, c'est très très largement faisable.
Mais pour poursuivre cette piste, il faudrait les vitesses requises pour l'IR, l'encodage (sûrement un Manchester ou équivalent), et le niveau de tolérance accepté par ton protocole IR (équivalent d'une clock quelque part ? Uniquement sur détection de fronts ?).

Je dois pouvoir travailler entre 36 et 40kHz, sinon faut un oscillateur. Mais le terminal (ou winCE), ne suit pas à cette fréquence donc... Comme la fréquence varie suivant le protocole, j'utiliserait un pic comme oscillo, donc quitte a prendre un PIC, autant qu'il fasse tout. En plus, ça facilitte grandement le travail finalement et la carte n'est pas tellement plus complexe (si l'USART de ce * de terminal fonctionne correctement ...)

[Mac LAK]

Je dois pouvoir travailler entre 36 et 40kHz, sinon faut un oscillateur.

Vu les fréquences, tu vas effectivement devoir passer par un contrôleur dédié à cette fonction... Et, dans ce cas, un PIC adapté n'est pas un mauvais choix. Vérifie quand même bien qu'il est capable de gérer un GPIO / SPI à ces fréquences-là !

[RTN14]

Vu les fréquences, tu vas effectivement devoir passer par un contrôleur dédié à cette fonction... Et, dans ce cas, un PIC adapté n'est pas un mauvais choix. Vérifie quand même bien qu'il est capable de gérer un GPIO / SPI à ces fréquences-là !

Que veux-tu dire exactement par là? Certains PIC ne pourraient pas changer de signal de sortie aussi vite?

[Mac LAK]

Que veux-tu dire exactement par là? Certains PIC ne pourraient pas changer de signal de sortie aussi vite?

Ben oui : si tu commandes ton GPIO directement à 40 kHz, il faut donc pouvoir faire 80.000 changements d'état de la ligne par seconde, tout en lisant les données sources depuis l'UART (afin de savoir quoi émettre), et en respectant les timings requis. Il te faut donc une interruption correctement programmée (80.000 ticks/seconde) pour le GPIO, et une autre IT pour l'UART.
Sur un PIC "lent", cela pourrait devenir problématique de tout gérer en même temps...

Tu seras moins gêné si, au lieu d'un GPIO "brut de fonderie", tu émets les données vers un contrôleur SPI ou autre contrôleur série générant exactement le signal désiré (ça devrait même être faisable avec du PWM, en bidouillant un peu). Dans ce cas, tu peux prendre un PIC plus petit, car son seul "vrai" boulot sera de transférer les données de l'UART RS-232 vers le contrôleur série connecté à la led IR, quasiment sans mise en forme des données.

[RTN14]

Hum, je vois.
Mais je ne compte pas envoyer/recevoir des données pendant que j'émais sur la LED. Le Pic va recevoir une suite de bytes via l'UART (EUSART vu le PIC que je pense utiliser) et une fois qu'il a tout les bytes, il va éméttre sur la LED avant d'attendre une nouvelle transmission.

[Mac LAK]

Si ce n'est pas temps réel et que ce ne sont pas des trames énormes (ce qui poserait un problème de RAM bien entendu), cela devrait aller : normalement, il ne faut pas plus de 4 ou 5 cycles CPU pour changer l'état d'un GPIO, ce qui veut donc dire qu'à partir de 1 MHz de fréquence processeur, le PIC doit pouvoir assurer une telle fréquence sur le GPIO.