Interfaçage de la sonde HCFR

[fma]

Bonsoir,

Ce fil est plus spécialement destiné aux développeurs, mais il peut sans doute intéresser d'autres personnes...

Je suis en train d'essayer d'interfacer la sonde HCFR avec un programme python. Mais j'ai des petits soucis.

En lisant les sources, j'ai trouvé que la commande à envoyer est un simple octet. Ça marche, je relis bien une tartine de valeurs en sortie, mais je ne peux le faire qu'une seule fois ; le deuxième coup, la led verte ne s'éteint pas, et je sors sur un timeout lors de la lecture.

Y a-t-il une astuce particulière, ou bien ai-je une problème au niveau de la programmation USB, que je découvre en même temps ?

Merci de vos lumières.

[Robinet]

Elles sont dispo les sources

[fma]

Ouaip, suffit de les demander aux développeurs (cf paragraphe 'Logiciel')... Mais c'est vrai que ce serait mieux sur un serveur svn

[Robinet]

Ah oui j'avais pas vu (lu)

Je vais embêter Georges G. et je reviens

[Robinet]

En lisant les sources, j'ai trouvé que la commande à envoyer est un simple octet. Ça marche, je relis bien une tartine de valeurs en sortie, mais je ne peux le faire qu'une seule fois ; le deuxième coup, la led verte ne s'éteint pas, et je sors sur un timeout lors de la lecture.

En regardant la classe KiSensor (dérivée de OneDeviceSensor) j'en conclue que la sonde marche comme ça:
- il faut lui envoyer 0x83 pour l'initialiser et 0x82 pour l'arrêter
- l'octet pour lancer une mesure est compris entre 0x00 et 0x7F suivant les paramètres:
cmd[0] = ( m_bMeasureRGB & 0x01 ) + ( ( m_bMeasureWhite & 0x01 ) << 1 ) + ( ( m_nSensorsUsed & 0x03 ) << 2 ) + ( ( m_nInterlaceMode & 0x03 ) << 4 ) + ( ( m_bFastMeasure & 0x01 ) << 6 );

Après pour le détail, ça sera surement plus rapide de demander à Ki que de le faire par reverse enginering

Dans tous les cas la sonde doit renvoyer une chaine de caractère de moins de 256 octets qui se termine par le caractère 13 avant la fin du timeout.

[Ki]

En lisant les sources, j'ai trouvé que la commande à envoyer est un simple octet. Ça marche, je relis bien une tartine de valeurs en sortie, mais je ne peux le faire qu'une seule fois ; le deuxième coup, la led verte ne s'éteint pas, et je sors sur un timeout lors de la lecture.

En regardant la classe KiSensor (dérivée de OneDeviceSensor) j'en conclue que la sonde marche comme ça:
- il faut lui envoyer 0x83 pour l'initialiser et 0x82 pour l'arrêter

Pas tout à fait, ces octets servent uniquement à demander l'extinction de la LED de la sonde HCFR lorsque l'on fait des mesures avec plusieurs sondes en même temps pour que la LED ne perturbe pas la mesure des autres sondes.
Ils ne sont pas du tout indispensables.

- l'octet pour lancer une mesure est compris entre 0x00 et 0x7F suivant les paramètres:
cmd[0] = ( m_bMeasureRGB & 0x01 ) + ( ( m_bMeasureWhite & 0x01 ) << 1 ) + ( ( m_nSensorsUsed & 0x03 ) << 2 ) + ( ( m_nInterlaceMode & 0x03 ) << 4 ) + ( ( m_bFastMeasure & 0x01 ) << 6 );

Après pour le détail, ça sera surement plus rapide de demander à Ki que de le faire par reverse enginering

Dans tous les cas la sonde doit renvoyer une chaine de caractère de moins de 256 octets qui se termine par le caractère 13 avant la fin du timeout.

J'ai déjà donné les détails du dialogue à fma par contre je n'ai pas d'idée sur le fait que la seconde demande ne soit pas prise en compte et je ne crois pas qu'il y ait d'astuce.
C'est normalement géré comme un port série classique (mais c'est Laric qui a implémenté le dialogue dans le code)

[Robinet]

Merci pour les précisions.

Dans le code, le port série est ouvert à l'envoi d'une commande et refermé à la fin de la réponse (ou du timeout).

C'est peut-être ça l'astuce qu'il manque à fma?

[fma]

Oui, c'est exactement ce que je me disais ce matin, en discutant avec un collègue... Je vais tenter ça.

Ki, concernant le dialogue, je n'ai que les sources (tu m'avais envoyé une partie de ceux-ci, au début, puis les complets). Mais ce serait bien d'avoir une doc qui détaille le protocole sous une forme plus claire, avec les codes d'erreurs éventuelles, etc...

[Ki]

Oui, c'est exactement ce que je me disais ce matin, en discutant avec un collègue... Je vais tenter ça.

Ki, concernant le dialogue, je n'ai que les sources (tu m'avais envoyé une partie de ceux-ci, au début, puis les complets). Mais ce serait bien d'avoir une doc qui détaille le protocole sous une forme plus claire, avec les codes d'erreurs éventuelles, etc...

Je t'avais envoyé les différents codes par MP. Il n'y a rien de plus, mais je peux essayer de retrouver si tu ne l'as plus.

[fma]

Ah, t'es sûr ? Je n'ai rien reçu... Si tu peux me les renvoyer, ce serait sympa

[fma]

Oui, c'est exactement ce que je me disais ce matin, en discutant avec un collègue... Je vais tenter ça.

Bon, en fait, entre 2 essais, mon programme se termine. Donc en principe, tous les descripteurs sont fermés. J'ai quand même fait un handle.releaseInterface(), avant de sortir, mais ça ne change rien...

[Robinet]

Tu l'ouvres avec quels paramètres ton handle?

Habituellement je fais comme ça sous windows pour ouvrir un port com:

Code: Tout sélectionner

...
HANDLE com_hdl;
CString COMPort;
COMPort.Format("\\\\.\\COM%u", com_port);
com_hdl = CreateFile(
    COMPort,
    GENERIC_READ | GENERIC_WRITE,
    0,
    NULL,
    OPEN_EXISTING,
    0,
    NULL
    );
...

[fma]

Ah, je le fais en python, sous Linux, via le module pyusb (basé sur libusb)... Faut que je creuse les paramètres d'ouverture, car ceux par défaut ne sont peut-être pas corrects ici.

[Robinet]

Tu devrais plutôt essayer de communiquer avec la sonde en série (device /dev/ttyACM0).
Sous Gtkterm ça marche tout seul par exemple

Je ne connais rien au python mais avec pyserial (http://pyserial.sourceforge.net/) ça a l'air facile

[fma]

Mince, je ne pensais pas que c'était aussi simple ! J'étais parti sur des trucs plus bas niveau... Et, pfft, l'USB, c'est une grosse daube d'un point de vue programmation ! Vivement que les piles IP se démocratisent au niveau de l'embarqué ; on gagnera du temps !

Merci du tuyau, je vais voir si ça fonctionne mieux avec ce driver...