Version imprimable
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
Non. TX est une broche conditionnée par le protocole RS-232, donc encodée, donc non pilotable directement.Citation:
Envoyé par RTN14
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 :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.
- 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.
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
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.
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!
C'est pour ça que l'on a inventé les hubs USB... :mouarf:Citation:
Envoyé par RTN14
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...Citation:
Envoyé par RTN14
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 ?).
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!Citation:
Envoyé par Mac LAK
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 ...)Citation:
Envoyé par Mac LAK
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à ! ;)Citation:
Envoyé par RTN14
Que veux-tu dire exactement par là? Certains PIC ne pourraient pas changer de signal de sortie aussi vite?Citation:
Envoyé par Mac LAK
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.Citation:
Envoyé par RTN14
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.
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.
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.