1

Salut,
J'aurais bien besoin d'un port série virtuel sur lequel je pourrais venir brancher un bout de code perso.
Typiquement, je voudrais répondre des octets arbitraires à la place d'un périphérique afin de le simuler aux yeux du programme appelant.
Ça existe ?
Des suggestions ?
Merci d'avance happy

2

(Pour info, Souane m'indique que ça semble exister, mais ne serait pas contre un conseil sur le meilleur logiciel à choisir cheeky — ce genre de chose par exemple : http://www.fabulatech.com/virtual-serial-port-kit.html, mais ça semble payant cry)

3

avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

4

Merci !

5

En complément de mkfifo, le puissant socat permet de transformer un certain nombre de flux en d'autres types (fichiers, pipes, FIFOs, sockets, etc.) et donc potentiellement d'étendre le jeu d'outils logiciels dont tu peux tirer parti pour la simulation de ton device.
Une solution mixte serait d'utiliser un des devices USB flexibles récents, programmables en langage de haut niveau, pour émuler (plus ou moins correctement, suivant les tests que tu cherches à exécuter) le protocole que tu souhaites.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

6

Oh en fait, ce que je veux faire est un peu bidon, je veux juste simuler la réponse (type log) d'un calculateur de voiture : je connais déjà le protocole, c'est juste l'interprétation de certaines portions de chaque trame qui me sont encore inconnus.
Je veux donc envoyer des trames construites manuellement à un autre logiciel pour gagner du temps sur le reverse cheeky

7

Tu serais pas en train de hacker ta voiture, toi ? cheeky

8

Bof, en fait je fais un logiciel de log des paramètres, c'est essentiellement du readonly. Il n'y a guère que la remise à zéro des codes d'erreurs qui soit en écriture.

9

10

Mmmm, bon, en fait com0com s'installe, mais il se trouve que dans le gestionnaire de périphériques de windows c'est listé dans une catégorie à part des COM physiques, et quelle qu'en soit la raison, le programme que je souhaite brancher sur ce port virtuel ne le liste pas ! (apparemment il y a 42 méthodes pour énumérer les ports sous win et ça ne doit pas utiliser la bonne grin)

Du coup j'ai tenté une démarche alternative : j'ai essayé de lui envoyer des trames arbitraires avec un arduino nano (driver FTDI) et un code custom qui, en gros, fait ceci :

void setup()
{
   serial.open(maVitesse)
}


loop()
{
   int sa= Serial.available() ;
   if ( sa >= laTailleMiniDeLaTrameDeCommande ) {
      maTrame= Serial.readMaTrame() ;
      if ( maTrame == laTrameQuiVaBien ) {
         Serial.write(laTrameArbitraireRenvoyéeAuProgramme) ;
      }
   }
}

Quand je teste avec hterm (ie j'envoie ma trame manuellement) l'arduino renvoie effectivement la trame arbitraire.
En revanche le programme que je veux étudier me renvoie des erreurs. Comme je ne suis pas sûr de ce qu'il envoie, j'ai testé avec un programme perso qui se connecte sur le port COM et qui envoie la trame de commande (laTrameQuiVaBien).
Surprise, ça ne fonctionne pas vraiment !?
Déjà, si je ne mets pas une pause >=250ms entre l'ouverture du port COM et l'envoi de la trame, je n'ai apparemment pas de réponse ?! (je m'en suis rendu compte car ça fonctionnait en traçant au débogueur uniquement triso)
Et finalement, en creusant un peu, je me suis rendu compte qu'en envoyant laTrameQuiVaBien, qui fait quatre octets (=laTailleMiniDeLaTrameDeCommande), l'arduino n'en reçoit apparemment que deux !? (du moins c'est ce que me répond Serial.available, même en le laissant tourner un bon moment).

Bref, je ne sais pas si vous avez des idées, mais à ce moment je me suis dit que c'était peut-être des problèmes liés au buffer du driver FTDI ?
Et j'en suis venu à me demander si le plus pratique pour débugguer tout ça ne serait pas de brancher la sortie série de mon convertisseur usb/serie arduino sur l'entrée série de mon arduino nano et de m'en servir pour voir ce qui ressort sur un second port COM physique tripo.
Est-ce que vous confirmez que ça me ferait bien une boucle COM fonctionnelle ?

(sinon à l'occasion je pourrais aussi essayer la version trial de http://www.fabulatech.com/virtual-serial-port-kit-download.html dont je parlais dans ./2... mais 15 jours ça sera peut-être juste)

PS : je suppose que je rate quelque chose d'évident donc n'hésitez pas et merci d'avance si vous avez des conseils cheeky

11

T'embête pas avec l'Arduino, il suffit probablement de changer le nom des ports de com0com pour les mettre sous la forme "comX", avec X < 10 (voire X <= 4 si c'est un vieux soft ou s'il est mal codé) :
Q. Is it possible to change the names CNCA0 and CNCB0 to COM2 and COM3?
A. Yes, it's possible. To change the names:

1. Launch the Setup Command Prompt shortcut.
2. Enter the change commands, for example:

command> change CNCA0 PortName=COM2
command> change CNCB0 PortName=COM3

Q. I need to use com0com ports with an application that doesn't recognize
com0com ports as "real" com ports. It does not see a com0com port even
though I have changed it's name to COMx. Is there a com0com settings that
will make the port appear to be a "real" com port?
A. No, there is not, but you can "deceive" the application this way:

1. With the "Add/Remove Hardware" wizard install new standard serial port.
You don't need a real serial hardware to do it. Select non conflicted
IO/IRQ resources.
2. With the "Device Manager" disable the newly created port (let it be
COM4).
3. Launch the Setup Command Prompt shortcut.
4. Install the pair of ports, were one of them has name COM4, for example:

command> install PortName=COM4 -
Ignore a warning about the COM4 is "in use" (press Continue).
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

12

Je ne me souviens plus du numéro du port COM mais sinon j'avais effectivement mis un nom explicite (mais c'était peut-être COM8, je ne sais plus trop).
Possible qu'il ait juste tenté de les ouvrir pour voir s'ils existent en s'arrêtant à un petit nombre, pas bête cheeky

(mais sinon, pour ma culture, concernant l'arduino et la boucle hw, ça devrait aussi fonctionner, non ?)

13

Pen^2 (./10) :
(apparemment il y a 42 méthodes pour énumérer les ports sous win et ça ne doit pas utiliser la bonne grin)
Pour info : http://stackoverflow.com/questions/1388871/how-do-i-get-a-list-of-available-serial-ports-in-win32

14

Les joies de la rétrocompatibilité tongue

Ouais ça peut marcher la boucle. Ton problème, c'est probablement parce que tu n'as pas les mêmes paramètres de communication (vitesse, nombre de bits de données et de stop, parité) côté Arduino et côté PC.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

15

LOL, quand la meilleure manière d'énumérer les ports est celle avec "Dos" dans le nom. gni
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

16

La vitesse est la même (8192 bauds), mais le reste je n'ai rien configuré côté arduino (côté PC c'est du 8N1).
C'est effectivement une piste, merci cheeky

edit : https://www.arduino.cc/en/Serial/Begin apparemment c'est bien du 8N1 par défaut, mais je jetterai un oeil, merci !

17

8192 bauds c'est pas une vitesse standard, c'est possible que ç'ait été arrondi différemment côté PC et côté Arduino.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

18

Oui, je sais, mais c'est la vitesse utilisée par mon périphérique cry
D'ailleurs quand je branche mon PC sur celui-ci via un adaptateur usb/série arduino ça semble fonctionner sans aucun problème, donc je ne pense pas que ça vienne de là.
En tout cas j'ai des trucs à vérifier et tester, merci !

19

ca peut foutre un gros box le bitrate arbitraire, tous les adaptateurs ne savent pas les gérer du tout... surtout peut être les machins clones ftdi sur les arduicheap...

20

OK merci.
C'est un made in USA, je ne l'ai pas sous les yeux.
edit : c'est marqué gravitech dessus, il a l'air officiel ou bien imité (de mémoire)
https://www.arduino.cc/en/Main/ArduinoBoardNano

Concernant l'adaptateur usb/série que j'utilise avec succès par ailleurs, il s'agit de celui-ci : https://www.arduino.cc/en/Main/USBSerial

21

Bon, pour info, SoftwareSerial ne fonctionne pas à des vitesses arbitraires.
void NewSoftSerial::begin(long speed)
{
  [...]
  for (unsigned i=0; i<sizeof(table)/sizeof(table[0]); ++i)
  {
    long baud = pgm_read_dword(&table[i].baud);
    if (baud == speed)
    {
      [...]
      break;
    }
  }
  [...]
}

22

http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-05_BaudRates.pdf
Cible : 8192 Baud
Diviseur idéal 3000000 / 8192 = 366.2109375
Diviseur le plus proche : 366.25
Baud réel : 3000000 / 366.25 ~= 8191.13
On est largement dans la limite des +-3%, donc soit j'ai pas compris un truc, soit ça devrait passer sans problème.
doom

23

ca passe, donc la véritay est ailleurs.

24

Oué, je soupçonne quand même un peu les réglages du driver (il est question de latence, etc).
Curieux en tout cas.
J'essaierai à nouveau com0com avec un COM<=4 mais tout de même, j'aimerais bien comprendre.

25

Je pense à un truc : le hardware (ATmega168/328) ne peut stocker que 2 ou 3 octets en réception. Si tu veux en gérer davantage, il faut soit utiliser une interruption soit lire régulièrement, et gérer un buffer à la main. Je ne sais pas comment sont faites les libs de l'Arduino, mais si elles ne gèrent pas ça, ça expliquerait pourquoi tu ne reçois que le début de la trame.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

26

Il me semble que la doc de l'arduino parle d'un buffer de 64 octets mais je me suis peut-être trompé grin

En tout cas c'est peut-être lié d'une manière ou d'une autre, merci !

27

Pas côté Arduino, ou du moins pas en hardware. C'est marqué dans la doc smile

(le chip FTDI a des buffers plus gros, mais à moins de gérer le contrôle de flux sur ton Arduino, ça ne t'avancera à rien)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

28

Là ils parlent bien de 64 octets, non ? (Possible que ce soit un buffer logiciel par contre, je n'en sais rien)
https://www.arduino.cc/en/Serial/Available

29

Oui. Ils doivent gérer ça en software dans les libs, alors.

Les caractères que tu reçois sont bons ou pas ? (est-ce que ça correspond aux premiers de la trame ?)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

30

heu y a pas de buffer hard non, si ton soft lit pas les caracteres ils seront perdus...