Discussion :

[Invité]

Bonjour.
J'ai réussi par le passé à envoyer des données sur le port parallèle (écriture seulement) d'un ordi de bureau sans driver spécialisé pour piloter un montage électronique (avec des optocoupleurs) : certains pontages simulent la présence d'une imprimante en reproduisant le handshake, et on ouvre un fichier sur le port // qu'on commande par write ; ou alors on utilise inpout32.dll. Cela fonctionne avec un "vrai" port, mais pas avec un adaptateur USB vers parallèle. Deux solutions a priori, mais ...
1) Existe-t-il un adaptateur "monobloc" sans câble (voir plus loin pourquoi ; cela existe, mais pas avec la spécificité que je cherche ici) qui ajoute un "vrai" port LPT, apparaissant dans la liste des périphériques, et pas seulement une fonction d'impression USB ? Une bidouille de la TU Chemnitz fait cela avec un Atmel.
2) Ou bien peut-on ouvrir dans Delphi un fichier texte sur UNE IMPRIMANTE (je déclarerais dans ce cas une générique, et je lui enverrais des données par write) ? Et quelle serait la syntaxe et le nom à utiliser ? Je n'ai vu que de la gestion d'imprimante en mode graphique par "printers" !
Sinon je vais bricoler un coffret d'interface, proche de l'ordi, et relié par des câbles en parallèle au montage ; l'intégration des adaptateurs "électroniques" (j'en ai essayé 2 types) dans le montage lui-même, relié avec un câble USB, semble provoquer des erreurs de transmission (Il y a un étage d'émission HF en jeu dans le montage, à côté du circuit d'interface, et je ne voudrais pas commencer avec des blindages).
Merci d'avance,
Alberich, l'homme qui aime les complications !

[JML19]

Bonsoir

C'est un PC portable ?

[Auteur]

Bonsoir,

tu cherches donc à piloter ton montage avec un autre moyen que ceux tu as évoqué ?
Je suis également passé par les moyens que tu as décris (inpout32, relier certaines voies à la masse avec des résistances).
-> relier certaines voies à la masse par une résistance (pins 10, 11, 12 si mes souvenirs sont bons), ça fonctionne.
-> les adaptateurs USB parallèles : j'ai testé plusieurs modèles, rien ne marche.

Il y a peut-être une solution alternative à ton problème : l'Arduino. Entre ton PC et l'arduino c'est une liaison série classique (USB) puis tu relies 8 sorties de la carte aux 8 entrées de ton système. Le microcontrôleur servira à traduire les informations que tu vas lui donner (un texte) en quelque chose de compréhensible par ta carte en activant 1 ou plusieurs voies.
Seul bémol : si tu souhaites activer 8 voies en même temps tu vas devoir faire une boucle.

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
for (i=0;i<8;i++)
    digitalWrite(pin[i], HIGH);

Mais dans ce cas, les huit voies ne passeront pas à l'état haut en même temps (tu as la même chose quand tu passes à l'état bas), il y a quelques microsecondes d'écart. Il te faut donc un driver de ligne comme le 74LS541 qui te permettront de basculer toutes les voies en même temps moyennant l'utilisation d'une 9ème voie pour l'entrée de commande du composant.

La seule chose que je n'ai pas encore réussi à déterminer convenablement se sont les différences de performances entre le port parallèle et l'arduino.

[chrtophe]

j'ai testé plusieurs modèles, rien ne marche.

Déjà que pour piloter des imprimantes, ça marche pas toujours...

J'ai eu le cas avec des anciennes embosseuses (imprimantes Braille). Du mal à trouver un adaptateur compatible. Les ports // ayant disparus, tu ne peux pas te tourner vers une liaison RS232 ?, peut-être plus de chance avec les adaptateurs USB/RS232.

[Invité]

Merci d'avoir lu mon intervention ...
1) Oui, c'est pour un portable ... d'où l'absence de port //. La machine de bureau que j'utilise pour développer en a encore un.
2) Je ne voudrais pas me mettre à l'Arduino ... Comme dit dans le pire des cas j'éloigne l'interface de l'étage HF (connexion USB la plus courte possible) et je continue en "boucles de courant" (comme dans le bon vieux TTY ou ... le MIDI ! ). La synchronisation des lignes n'est pas critique. Je me suis déjà demandé si ce n'est pas mon câble USB qui serait trop long et qui capterait ( >1,5m, mais ne sont-ils pas tous blindés ? ). Problème, si je rapproche l'émetteur de l'ordinateur, il y a d'autres ennuis : comme le système comprend une commande vocale, j'ai constaté des problèmes à ce niveau (apparemment l'entrée micro n'aime pas la HF non plus ! ).
Je repose la question : peut-on en Delphi ouvrir un fichier texte sur une imprimante (il n'y en aurait qu'une, "bidon", sur le portable et sur la machine de bureau je peux la déclarer par défaut le temps de mes essais) ? Comme cela j'enverrais mes données par write(chr(...)), comme sur le port //.
3) Le problème avec RS232 est que ensuite il me faut encore un convertisseur série-parallèle ... et qu'en sera-t-il de son immunité à la HF ?
Merci d'avance,
Alberich

[chrtophe]

Tu peux essayer d'envoyer des infos sur une "imprimante generic/text only". Je ne sais pas si ton montage envoi un retour au PC (dans ce cas pas sûr que ça marche).

Le problème avec RS232 est que ensuite il me faut encore un convertisseur série-parallèle

Mon idée était plutôt d'utiliser série vers série, sous réserve que ce fut possible (ça pas l'air).

[Auteur]

Tu as aussi des ExpressCard avec un port parallèle. Ca fonctionne plutôt bien.

Pour ta question sur Delphi, je ne peux pas te répondre, je ne connais pas ce langage.

[Invité]

1) Mon portable n'a pas de slot pour Express Card.
2) Mon montage de test se compose d'une prise DB25 avec "les" pontages du handshake, une led avec une résistance de 2,2K entre une sortie et la masse. Il fonctionne très bien avec le port parallèle (j'ai écrit un programme qui allume et éteint la Led). Mais avec mon adaptateur USB (de marque ST Lab), niet ! J'ai eu l'idée de mesurer la tension : elle suit bien, entre une valeur négligeable et +0,4v ! Apparemment le courant fourni est insuffisant pour allumer la Led. Donc, inutilisable, vu que les sorties parallèles doivent piloter directement les optocoupleurs ; cela serait peut-être utilisable en ajoutant des buffers CMos, mais avec quoi les alimenter ? Je veux une isolation galvanique totale donc pas d'alim des leds des optos à partir de l'émetteur, et les ports parallèles, contrairement au port du C64 (!), ne sortent pas de 5v auxiliaire. Ne restent plus que :
- J'ai déjà remplacé le chip d'interface (on ne sait jamais), mais pas encore fait assez de tests ; il est curieux que les problèmes soient apparus au bout de 1 an de fonctionnement normal, et uniquement sur une seule des deux interfaces que j'utilise (et bien sûr en démonstration publique : loi de Murphy). Je pensais en premier à un bête brouillage (la transmission est en 27MHz, et les deux modèles utilisent 2 fréquences distinctes), mais le problème s'est reproduit chez moi avec la même interface, et le système est redevenu stable quand je lui ai renvoyé une donnée à partir de l'ordinateur. Wait and see ... Possible que l'ancien chip plantait aléatoirement, les pannes, cela arrive.
- Raccourcir le câble USB (espérons qu'il n'y aura pas trop de brouillages ... à voir).
- En dernier recours, délocaliser l'interface USB loin de l'émetteur.
Merci encore ...

[Delias]

Bonsoir Alberich

Pourquoi le mot de la fin après à peine une journée?
Dans les puces de conversion USB-Série, il y a des truc sympa, comme la FT245R, qui bien que se faisant passer pour un port série par le PC sort en réalité les données sous forme parallèle (très proche du LPT par ailleurs.)
Il faut tout au plus un timer pour activer le RD# depuis le RXF#.

Faut encore que je cherche un peu demain, j'avais en tête une puce un peu plus ancienne, mais surtout plus simple à l'utilisation.

L'avantage c'est que tu as du 5V pour la logique et les optocoupler.

Bonne nuit

Delias

[Invité]

Merci, mais j'ai essayé il y a déjà 3 ans et demi la version purement parallèle de FTDI (USBMod4, à l'époque de chez SELECTRONIC), entre temps remplacée par un autre module, je trouve qu'au point de vue logiciel et utilitaires le IOWarrior24 (1 port parallèle de 16bits et non 8 seulement) est meilleur (de chez LEXTRONIC). C'est un microcontrôleur Cypress programmé en conséquence. Plusieurs articles sur cette famille avaient été publiés dans la défunte (Snif ! ) revue "Electronique Pratique". Malheureusement, contrairement au FTDI, il n'y a pas d'entrée "Reset" matériel (sinon j'y aurais câblé un bouton poussoir ! ), et on est obligé de réaliser soi-même toute la partie de connexion USB (ce qui se fait d'ailleurs très bien, il faut seulement trouver une résistance à 1%).
Alberich

[Delias]

Bonjour Alberich

Je ne comprends pas ta réponse.
Au passage j'ai vérifié et c'est bien cette puce à la quelle je pensais.
Ton module FTDI USBMod4, utilise la puce FT245B, version précédente de celle que je t'ai proposé.

Tu demandes quelque chose de simple. Cette puce est très simple car dans le cas standard (sans reprogrammation de sa mémoire):
- Elle est identifiée par un PC comme un convertisseur USB->RS232 et est accessible en programmation Delphi par le TComPort. (Driver inclus dans WinXP et plus récent, à téléchargé pour les anciens Windows)
- Côté montage, c'est une sortie //, qui si on ajoute une bascule monostable non redéclanchable (comme le 74221), se comporte comme la sortie d'un port // avec les 8 bits de donnée et le strobe.

C'est pour moi, la seule solution pérenne, car la seule à utiliser des protocoles et drivers standards et disponible de base sur les PCs.
Edit: Je me dis que je dois préciser ce que je définis comme solution pérenne. C'est d'utiliser un convertisseur USB->RS232, après on choisi le convertisseur en fonction de la circuiterie que l'on a derrière. Interface type: RS232, RS232 niveau TTL, SPI, ou //.

Après je ne connais pas ton niveau en électronique, mais il me semble qu'il est plutôt bon, à voir comment tu en parles.
Si ta communication HF respecte la CEM, il n'y a pas de raison que ce module ne fonctionne pas tant que les condensateurs et la ferrite de déparasitage sont montés correctement.

Bonne journée

Delias

[Invité]

1) Je n'ai pas besoin du strobe, les 8 bis latchés en sortie du USBMod4 me suffisaient pour commander directement mes optocoupleurs (8, si on acceptait une petite restriction de fonctions par rapport à la version actuelle avec 10) ...
2) Je me souviens maintenant du problème que j'avais eu : j'étais sur ma machine de bureau en Delphi 6 sous Windows 2000 (actuellement : D7 sous XP). Il fallait créer au départ plusieurs variables dynamiques par "new". Puis au moment d'initialiser l'interface, je testais un éventuel échec de connexion (device not present) et dans ce cas je comptais quitter proprement mon programme en libérant les variables dynamiques. Et bien, IL NE LES TROUVAIT PLUS ! Apparemment l'utilitaire de FTDI avait mis la zizanie sur la pile de gestion des variables dynamiques !
3) De toute manière, en réfléchissant bien, les démonstrations publiques de mon système sont condamnées à terme, et pas pour des raisons électroniques. Il s'agit en fait de maquettes (chars) radiocommandées en commande vocale. Or les commandes (et dictées) vocales ont toutes le même problème, c'est l'existence d'un bruit de fond non constant, malgré l'utilisation d'un micro serre-tête professionnel unidirectionnel à plus de 200€ (!) . Lors de l'avant-dernière exposition, le système fonctionnait bien ... jusqu'au moment où les organisateurs ont mis une sono d'ambiance, et là la reconnaissance avait des ratés ! A tel point qu'à la dernière expo je n'ai même pas déballé le système (je suis modéliste et j'ai d'autres maquettes en commande "conventionnelle"). Donc les futures démonstrations ne pourront bientôt plus se faire que devant des visiteurs à mon domicile, qui est moins bruyant et où c'est MOI qui contrôle le bruit ambiant ; et là j'ai une machine de bureau qui a (encore) un port parallèle sur la carte mère, dont les 8 bits suffisent, et qui en accepte même un second sur carte PCI si ne veux pas risquer de "griller" le premier avec mes bricolages !
Voilà pour le mot de la fin ! Merci encore pour vos réponses ...

[Invité]

Bonjour.
Je suis allé sur le forum de CodeMercs (j'utilise le IOWARRIOR24), suite à une intuition "géniale" (!). Les responsables m'ont confirmé mes soupçons, merci à eux : Le problème était vraisemblablement dû à une STUPIDITE de XP (et de 2000, au passage), à savoir l'activation par défaut des fonctions d'économie d'énergie des ports USB ; il m'a été confirmé que cela pouvait effectivement poser problème. J'ai donc décoché partout ... Seule question, pourquoi le problème ne s'est-il produit qu'au bout d'un an et demi ? Loi de Murphy, ou première fois que la batterie a atteint un niveau de décharge assez bas ? De plus, si ce réglage par défaut PEUT (!) se justifier sur un portable, je ne comprends pas au passage pourquoi elle est mise sur un ordinateur de bureau, surtout après être passé par les réglages d'option d'alimentation ! Merci qui ?