je me pose quelques questions…
Après lecture de la petite doc trouvée concernant le géné, il me semble qu’il doit être « plug-and-play », si le PC le reconnait et dit qu’il est prêt à l’usage, pourquoi initialiser le port comme une liaison RS232 ?
Je me suis plongé ce matin dans un bouquin qui décrit le bus USB. C’est une tranmission par paquets, si j’ai bien compris, c’est le contrôleur USB qui se débrouille pour structurer ces paquets selon l’affectation du port COM ou d’un autre périphérique.
Si le géné est affecté au port COM4, j’essayerais de simplement d’envoyer sur ce port la chaîne ASCII de commande comme on le ferait pour envoyer une ligne à une imprimante, c’est le CR et/ou LF qui doit générer le paquet.
Par contre, je ne suis pas certain qu’on puisse le faire avec hyper-terminal qui nécessite la config style RS232.
Pas besoin de configurer ni de s’occuper de la vitesse…
Mais c’est peut-être trop simple ou simpliste !
Sinon il me semble que QB64 est un compilateur puisque lorsqu’on lance un « RUN », il crée un fichier « .exe », à moins qu’il n’y ait des options.
Ca fonctionne avec hyperterminal avec une commande du genre :
:01,w210,000
Avec l’écran de commande fourni par le constructeur, il faut mettre le « \n » à la fin.
Si je mets la même commande au sein d’un programme qb64 (en mode byte ou non, avec ou sans le \n), pas de réaction du géné.
J’ai besoin d’envoyer une séquence bouclée de commandes au géné d’où la nécessité d’un programme.
J’ai un draft du protocole… traduit googlement du chinois : SERIAL PROTOCOL.pdf (96.8 KB)
J’ai écrit au constructeur chinois (on verra…).
Il s’agit peut être d’un problème de terminateur. Je ne crois pas que le caractère « newline » (\n) soit compris par le basic. Peut être faudrait il travailler en mode BIN, supprimer le \n et rajouter + chr$(13)+chr$(10) à la fin de la chaine.
J’ai bien le turbo Basic, mais j’ai pretté le bouquin a un copain qui a bien sur oublié de me le rendre.
Le programme se monte sur XP et utilise comme éditeur les commandes de traitement de texte de WordStar.
La différence avec GW c’est la rapidité d’ éxecution et la facilité pour programmer car il n’y a pas besoin de numéroter les lignes.
Maintenant je me souviens d’avoir galéré avec ce problème de liaison série. A force de mettre des tempos un peu partout cela avait fini par marcher. Malheureusement je n’ai plus le programme que j’avais fait. C’était il y a plus de 20 ans !
Il n’y a peut être pas que la solution USB>COM, sur les PC de bureau on peut rajouter des cartes PCI qui rajouent un port COM et un port LPT.
alias chr$(13) et chr$(10) : déjà essayés… l’un et l’autre et l’un ou l’autre.
En mode bin et non bin.
Avec l’hyperminal, il faut d’ailleurs cocher « Envoyer les sauts de ligne avec les fins de ligne ».
Ce qui tendrait à prouver qu’il faille les envoyer aussi via le programme.
D’où les essais avec ou sans et avec ou sans le fameux « ; » en fin d’instruction print.
Si ça réagit avec l’hyperterminal, il faut et il suffit (!) qu’un programme envoie la même séquence de caractères…
qb64 : oui, compilé et n°s de ligne non obligatoires.
L’enquête continue : je vais de ce pas dénuder l’autre partie du câble USB…
ça permettra de vérifier si QB64 envoie effectivement des données sur le bon port…
Par contre lire ce qu’il envoie ne me semble pas trop possible à l’oscillo, sauf peut-être s’il s’agit d’un seul caractère, à suivre donc
Faudrait un oscillo à mémoire…
Dans le temps, je faisais ça avec une jonction éclatée (de chez Black Box) et un Datascope (la marque avait servi de nom générique) ! Un fait, un « spy » sur la ligne… Le Datascope affichait les caractères reçus.
En tout cas, qb64 ne génère pas d’erreur à l’exécution de mes différents essais. J’ai déconnecté le câble USB : qb64 génère alors une erreur (« je ne trouve pas le port »), mais ça ne prouve pas que les datas sortent du PC…
Bon, pince à dénuder maintenant !
Sinon, je peux faire un fichier txt des commandes à envoyer et balancer ce fichier au géné via l’hyperterminal…
Ca marche. Mais je ne sais pas reboucler… Ou alors je recopie 1000 fois la même séquence, why not ?
Ca me fera plusieurs wobulations. Avec 24 wobulations par seconde, j’aurai une image « fixe » sur le scope… pendant un petit moment !
Je peux même programmer un spike au début de chaque wobulation pour déclencher le scope.
Ah oui j’oubliais : le but est d’obtenir sur le scope la réponse en fréquence… d’un transfo MF.
Un ami a construit un tel transfo avec le couplage qui se règle mécaniquement par commande d’une tige filetée…
Le but ultime est de vérifier qu’au couplage critique, il y a bien une bosse suivie d’une « épaule », sorte de plateau qui est en fait un point d’inflexion. C’est ce point d’inflexion qui m’intéresse (ça ne sert à rien, alors c’est marrant).
Au fou !
:mrgreen:
Je ne pense pas que l’analyse de ce qui transite sur le port USB avec un oscillo soit la bonne voie, car c’est délicat à interpréter. Les données sont codées en NRZI et il y a le protocole de passage de jeton qui met son grain de sel…
Si en passant par l’Hyperterminal le fonctionnement est correct, c’est fatalement que le problème est du côté du programme basic.
Une autre possibilité si qb64 est rétif serait, puisque la ligne de commande fonctionne sous Hyperterminal, d’essayer de la faire marcher sur Teraterm une autre application de type Terminal/Telnet. Teraterm dispose de macro-commandes (y compris des boucles) qui permettrait peut être d’automatiser la fonction désirée.
Effectivement la trame envoyée semble correcte. Une seule question, pourquoi fermer le port immédiatement ?
HyperTerminal le laisse ouvert, c’est la première différence que je vois. Je verrai bien laisser attendre le programme sur un input$ après après l’écriture.
La doc de qb64 spécifie que
« INPUT mode can use INPUT # or INPUT$. OUTPUT mode can use PRINT # or PRINT #, USING ».
est « not currently supported by qb64 »
Je crois qu’il faudrait programmer aussi près que possible de l’exemple 3 de la doc en utilisant open for random et put # au lieu de print #
Bon, j’ai dû charger des cochonneries car maintenant j’ai des pubs partout (Sale Charger)…
Je m’en occuperai après.
J’ai supprimé la fermeture du port dans mon programme.
Et Aspycom m’indique que le port se ferme à la fin du run.
Sur l’utilitaire « écran » fourni par le constructeur, celui-ci indique qu’il faut terminer la chaîne de commande par « \n ».
Avec Aspycom, on voit bien la chaîne passer mais avec un sans à la place du « \n ».
Et le port ne se ferme pas !
Donc il y a déjà une grosse différence avec cette fermeture de port par le programme.
Je vais voir Aspycom avec l’hyperterminal (Tera Term fonctionne, je verrai pour les macros).
euh, encore une idée probablement en l’air :
en ajoutant chr$(92)+chr$(110) en fin de chaîne
On voit parfois des « » transformés en « / », il n’y a que MSDOS qui utilise les « » et certains logiciels les transforment en « / »
En réalité, pas besoin de ce « \n » qui n’est utilisé que dans l’applicatif « écran » du constructeur du géné.
Dans cet applicatif, il y a, entre autres, la possibilité d’envoyer une ligne de commande au géné et c’est là que le constructeur dit d’ajouter ce « \n ». Avec Aspycom, on voit que ce « \n » est remplacé par un (sans ).
Maintenant, il faut que je trouve comment empêcher que le port ne se ferme avec la fin du programme, même sans l’instruction CLOSE dans ce programme.
Le port doit se fermer automatiquement à la fin du programme.
Avant cette fin, il faudrait que je fasse un « input » (un buffer à vider ?) mais cela génère des erreurs à l’exécution, quelque soit la façon de programmer cet input/get (bin ou non bin)…
Avec Tera Term (JeffM) et une macro hyper simple qui boucle.
Je pense qu’avec qb64, il y a un pb de buffer à vider après toute commande de « write » (c’est ce que disait bruno02). Mais pas moyen, pour l’instant… Bien aussi le Aspycom.
En effet, avec Tera Term, on voit bien que le géné répond par une chaîne de caractères avant de prendre en compte le « write » suivant.
Un grand merci aussi à jmespe, Bricolou85, Transistorix pour les nombreuses idées, les trucs, les pistes. J’ai appris plein de nouvelles choses.
Doctsf (Modèles & Marques)
Annonces
