Discussion :

[ChPr]

Bonjour à toutes et à tous,

J'ai acheté une station météo qui envoie ses données à un PC via une liaison USB.

Mais il semble que le protocole utilisé ne soit pas basé sur le modèle UART (liaison série COM X que l'on peut gérer avec une bibliothèque type "Synaser").

Existe-t-il des bibliothèques pour Lazarus gérant ces liaisons USB ?

Cordialement.

Pierre.

[bb84000]

Bonjour,

Allez voir libusb.

bb

Lien corrigé (23/09/2023).

[ChPr]

Merci, je vais aller voir ça ce W.E.

Cordialement.

Pierre.

[JP CASSOU]

Bonjour,

Allez voir libusb.

bb

Lien mort - Utiliser https://github.com/libusb/libusb

[bb84000]

Bonjour,

J'ai corrigé le lien dans mon message. Il manquait un "i" à la fin. Le revoici en clair :

https://github.com/libusb/hidapi

API des fonctions de communications les plus courantes avec un périphérique USB (utilise libusb)

bb

Note: Je ne peux corriger le lien dans les réponses. Si un modérateur s'en sent le courage, merci d'avance...

[ChPr]

Merci pour ce lien.

Pour autant, si cette libraire est multiplateforme, elle n'est pas multilangage et donc je ne sais/peux pas l'utiliser avec Lazarus.

Cordialement.

Pierre.

[Jipété]

Salut,

Pour autant, si cette libraire est multiplateforme, elle n'est pas multilangage et donc je ne sais/peux pas l'utiliser avec Lazarus.

Je ne comprends pas cette remarque : si je fais une recherche dans Synaptic (gestionnaire de librairies, programmes, etc.) sur libhidapi-dev tel qu'indiqué dans le readme.md (tout en bas, avant-dernière entrée), j'y trouve :

Code :

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

This package contains the files needed to compile and link programs which use HIDAPI.

Et tu vois bien qu'il n'y a pas de restrictions.

Ensuite, une petite recherche sur le web ("libhidapi pascal") te donnera la suite :
https://github.com/prof7bit/HIDAPI.pas
https://forum.lazarus.freepascal.org...?topic=44283.0
etc.

[Jipété]

J'ai retrouvé ça :

Par ailleurs, j'avais trouvé de mon côté le lien vers " LongDirtyAnimAlf / FPC-USB-HID ". Là encore, sous Ubuntu, la démo se compile et s'exécute,

Pourquoi n'as-tu pas continué avec ce projet ?
Bon, OK, sous Windows ça ne veut pas, mais chaque chose en son temps, hein.

[Jipété]

Bonjour,

si je récupère l'archive "source code (zip)" ici https://github.com/libusb/hidapi/rel.../hidapi-0.14.0 et que je l'ouvre avec un visualiseur de zips, je trouve dedans un dossier libusb, alors j'y vais voir et je n'y trouve que des Makefile pour Linux et similaires, et rien pour Windows...

si je récupère l'autre archive "hidapi-win.zip", on y trouve des fichiers hidapi.tout_ce_que_tu_veux mais pas de hidapi-libusb.

On dirait que -libusb ne concerne PAS windows.
Maintenant, pourquoi est-ce que c'est dans le fichier sans autre explication, pas la moindre idée...

Mais regarde bien la page que je t'indique : on y trouve

Released hidapi-win.zip includes pre-compiled:

hidapi.dll
hidapi.lib

For x86 and x64 Windows platforms.
And header file(s) for it.

Tiens, va donc fouiller là : https://libusb.info/hidapi/index.html

[ChPr]

Bonsoir,

Ayant chargé cette application, je l'ai un peu modifiée pour la rendre visuelle (utilisation d'un TMemo à la place des Writeln).
J'ai modifié l'unité hidapi.pas pour accepter la dll : hidapi.dll :

Code :

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

1
2
3
4
5
6
{$IFDEF UNIX}
  LIBHIDAPI = 'hidapi-libusb';
{$ENDIF}
{$IFDEF WINDOWS}
  LIBHIDAPI = 'hidapi';
{$ENDIF}

Ça compile et s'exécute aussi bien sous Windows qu'Ubuntu. Pour autant les résultats sont différents :

Sous Ubuntu, j'obtiens de ligne compréhensible, mais je tombe sur "'could not open device'" dans la procédure "OpenAndReadDemo", pourquoi ?

Sous Windows 10, les lignes dans le TMemo sont remplies de caractères bizarres. J'ai été obligé de "commenter" les lignes 97 à 102 de l'unité "Fntr.pas" car la fonction Num:= Device.Read(Buffer, SizeOf(Buffer)); ne répondait pas ; le programme ne se poursuivait pas, pourquoi ?

Donc, en l’état, je suis un peu (voire beaucoup) bloqué.

Si vous avez quelques temps pour voir ce qui se passe ...

Cordialement.

Pierre.HIDAPI.zip

[Jipété]

J'ai récupéré ton zip et l'ai extrait dans un dossier.
J'y ai trouvé des .res, reliquats de compils échouées, pas important.

Plus costaud, j'ai ouvert le README et là je suis resté sur le Q : personne n'a vu les lignes 4 et 6 ?
Je les remets :

## only Linux (or other *ixes)

This does not (yet) work on Windows, it assumes sizeof(wchar_t) == 4 and this is not true on Windows.

Cette partie va être tendue...

Allez, je regarde la linux.

[Jipété]

Si c'est là-dedans que ça coince

Code :

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

1
2
3
4
5
6
7
8
9
10
function THidDevice.Open(VID: Word; PID: Word; Serial: UnicodeString): PHidDevice;
var
  WS: TCWCharArray;
begin
  WS := UnicodeStringToTCWCharNullterminated(Serial);
  if Length(WS) > 1 then
    Result := hid_open(VID, PID, @WS[0])
  else
    Result := hid_open(VID, PID, nil);
end;

je n'ai pas trop d'idée, d'autant plus que pour faire une compil il nous faut rajouter des choses :

Code :

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

sudo apt-get install libudev-dev libusb-1.0-0-dev libfox-1.6-dev

.

Alors au pif, maintenant que chez toi ça compile, est-ce que les différents essais précédents n'auraient pas mis la pagaille dans la pile USB ? Auquel cas un reboot pourrait régler le souci.
Sous Linux.
Et il faudrait aller voir dans la source LIBHIDAPI (elle est dispo ?) ce que fait la proc hid_open.

Sous Windows, je ne vois pas trop, je n'ai plus de Windows (sauf en machines virtuelles, qui risquent d'embrouiller les choses).

[ChPr]

...

En effet, l'auteur dit ne pas avoir pu tester sous Windows. Il semble que ce soit dû à ces différents tableaux de caractères, chaînes, ... à gérer.

Sous Ubuntu, je ne pense pas que le problème vienne de la pile USB car j'ai sans arrêt fait des aller/retour entre Windows et Ubuntu donc, reboot à chaque fois.

Ce que j'aimerais comprendre est :

Code :

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

  UCS4Char            = type 0..$10ffff;

afin de pouvoir donner une valeur à WS dans la fonction : THidDevice.Open

Cordialement.

Pierre.

[Jipété]

Sous Ubuntu, je ne pense pas que le problème vienne de la pile USB car j'ai sans arrêt fait des aller/retour entre Windows et Ubuntu donc, reboot à chaque fois.

OK.

Ce que j'aimerais comprendre est :

Code :

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

  UCS4Char            = type 0..$10ffff;

afin de pouvoir donner une valeur à WS dans la fonction : THidDevice.Open

Vu comment la fonction est écrite, on pourrait penser qu'elle peut supporter le passage d'une valeur vide, mais peut-être qu'elle n'aime pas ton '' et qu'il faudrait lui passer nil ou '0' ou que sais-je d'autre ?

Sinon, encore de la lecture : https://github.com/libusb/hidapi

HIDAPI has four back-ends:
Windows (using hid.dll)
Linux/hidraw (using the Kernel's hidraw driver)
libusb (using libusb-1.0 - Linux/BSD/other UNIX-like systems)
macOS (using IOHidManager)

On Linux, either the hidraw or the libusb back-end can be used. There are tradeoffs, and the functionality supported is slightly different. Both are built by default. It is up to the application linking to hidapi to choose the backend at link time by linking to either libhidapi-libusb or libhidapi-hidraw.

Note that you will need to install an udev rule file with your application for unprivileged users to be able to access HID devices with hidapi. Refer to the 69-hid.rules file in the udev directory for an example.

Linux/hidraw (linux/hid.c):
This back-end uses the hidraw interface in the Linux kernel, and supports both USB and Bluetooth HID devices. It requires kernel version at least 2.6.39 to build. In addition, it will only communicate with devices which have hidraw nodes associated with them. Keyboards, mice, and some other devices which are blacklisted from having hidraw nodes will not work. Fortunately, for nearly all the uses of hidraw, this is not a problem.

Linux/FreeBSD/libusb (libusb/hid.c):
This back-end uses libusb-1.0 to communicate directly to a USB device. This back-end will of course not work with Bluetooth devices.

Et en plus, c'est un peu le bronx avec les forks... Lecture (jusqu'en bas) : https://github.com/signal11/hidapi/issues/373 (tout en bas j'ai vu passer pas mal de posts avec un problème similaire au tien, enfin, lu à la va-vite).

Et un post intéressant à lire et utiliser pour tester sa config et ses périph's: https://unix.stackexchange.com/quest...-an-hid-device

HS : pourquoi ne pas demander au vendeur de ta station météo ce qu'elle attend et ce qu'elle peut fournir, et comment ?

[ChPr]

...Vu comment la fonction est écrite, on pourrait penser qu'elle peut supporter le passage d'une valeur vide, mais peut-être qu'elle n'aime pas ton '' et qu'il faudrait lui passer nil ou '0' ou que sais-je d'autre ?
...

Le "ton '' " n'est pas "mon '' " . C'est ce qui est écrit par défaut. et apparemment, ce terme est facultatif. Que je mette quoi que ce soit à la place ne donne rien.

... HS : pourquoi ne pas demander au vendeur de ta station météo ce qu'elle attend et ce qu'elle peut fournir, et comment ?

Dans ce marché des stations météorologiques, beaucoup de stations se ressemblent et sont vendues par différents fournisseurs. Je ne pense pas qu'il soit aisé de trouver les infos que tu me demandes. Pour autant, j'ai deux applications : "EasyWeather" et "Cumulus" qui s'interfacent avec ma station et qui en affichent toutes les données. Chacune de ces applications utilise des " *USB*.dll " que je n'arrive pas à trouver sur la toile. Même si je les trouvais, je ne pense pas que ça résolve le problème.

Par ailleurs, j'ai trouvé tout un tas d'informations sur le protocole d'échange de cette (ces ?) stations donnant des adresses et des formats de données. Ça pourra me servir si un jour j'arrive (??) à me connecter à cette station.

J'ai aussi récupéré les sources d'un logiciel "CumulusMX" pouvant s'interconnecter à cette station et bien d'autres. Pour autant, il y a une petite centaine de fichier en C++ dont mes connaissances dans ce langage ne me permettent pas d'en tirer une substantifique moelle !

Je n'abandonne pas l'idée de ma faire ma propre application (j'en avais faite une pour une station "La Crosse Technologie", mais elle dialoguait via un port série), mais pour l'instant, je ne sais pas quel bout de la pelote tirer ...

Cordialement.

Pierre.

[Jipété]

Bonjour,

Chacune de ces applications utilise des " *USB*.dll " que je n'arrive pas à trouver sur la toile. Même si je les trouvais, je ne pense pas que ça résolve le problème.

Cherche-les dans ta machine.
Ensuite, il me semble qu'il doit exister des outils pour examiner l'intérieur d'un fichier dll (qui remontera le nom des fonctions accessibles par exemple), j'en avais écrit un très basique en Delphi, en son temps, Mais pas sûr que ça soit bien utile, sauf si l'outil est capable de dire ce que la fonction attend comme paramètre(s) et type de.
Ça permettrait d'être sûr qu'on lui envoie les bonnes données.
Commercer par là https://www.nirsoft.net/.

Et sinon, une question vraiment très bête mais sait-on jamais ? Lors des tests, la station est-elle bien détectée et reconnue par l'OS, genre lsusb avec les options qui vont bien et les autres outils dont le nom m'échappe ?
Vérifier aussi le retour de dmesg | tail -10 (ou + ou -, c'est selon le nbre de lignes), pour être sûr de chez sûr ! À utiliser après connexion physique puis après lancement du prog, pour voir ce qui revient par ce canal.

Ensuite, quand tout cela sera parfait, mettre un point d'arrêt sur le end de la procedure Open, exécuter et à l'arrêt, examiner la pile d'appel pour voir par où ça passe, avec le menu Voir / Fenêtres de débogage / Pile d'appel.

Et tu nous dis...

[bb84000]

Bonjour,

Je n'ai pas testé hidapi sous LInux. Sous Windows (64) voici mon code :

Hidapi_bb.zip

Le programme recherche non pas une souris Logitech, comme indiqué dans le commentaire, mais un tensiomètre Omron... qu'il ne va pas trouver puisqu'il n'est pas connecté.

bb

[ChPr]

...Je n'ai pas testé hidapi sous LInux. Sous Windows (64) ...

Merci pour ce code qui m'a permis de revenir en arrière et de constater que je faisais une grosse erreur quand je disais que je n'obtenais pas de connexion sans serialNumber. En mettant '' comme valeur pour le serialNumber, il y a bien connexion (sous Windows et sous Ubuntu en mode sudo) sur ma station météo (VID = $1941 et PID = $8021). Le problème se trouve donc un peu plus loin sur le code suivant :

Code :

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

      Num := Device.Read(Buffer, SizeOf(Buffer));

Quand le programme passe sur cette instruction, il ne se passe rien et il reste bloqué sur cette ligne.

Une idée de ce qui se passe ?

Par ailleurs, les retours d'information dans un TMemo concernant les chaînes de caractères sont illisibles.



avec des messages comme celui-ci :

Code :

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

fntr.pas(90,67) Warning: Implicit string type conversion with potential data loss from "UnicodeString" to "AnsiString"

Y a-t-il une fonction qui permette de ne pas avoir de perte d'information ?

Cordialement.

Pierre.

[jurassic pork]

Hello,
houla attention le format des données de ce périphérique n'est pas en chaîne mais du binaire. Il faut regarder la structure des blocs de données dans le driver python par exemple dont voici une partie :

Code python :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
########### Read data
        # Get the first 32 Bytes of the fixed
        fixed_block = read_block(dev, 0)
 
        # Check that we have good data
        if (fixed_block[0] != 0x55):
            raise ValueError('Bad data returned')
 
        # Bytes 31 and 32 when combined create an unsigned short int
        # that tells us where to find the weather data we want
        curpos = struct.unpack('H', fixed_block[30:32])[0]
        current_block = read_block(dev, curpos)
 
        # Indoor information
        indoor_humidity = current_block[1]
        tlsb = current_block[2]
        tmsb = current_block[3] & 0x7f
        tsign = current_block[3] >> 7
        indoor_temperature = (tmsb * 256 + tlsb) * 0.1
        # Check if temperature is less than zero
        if tsign:
            indoor_temperature *= -1
 
        # Outdoor information
        outdoor_humidity = current_block[4]
        tlsb = current_block[5]
        tmsb = current_block[6] & 0x7f
        tsign = current_block[6] >> 7
        outdoor_temperature = (tmsb * 256 + tlsb) * 0.1
        # Check if temperature is less than zero
        if tsign:
            outdoor_temperature *= -1
 
        # Bytes 8 and 9 when combined create an unsigned short int
        # that we multiply by 0.1 to find the absolute pressure
        abs_pressure = struct.unpack('H', current_block[7:9])[0]*0.1
 
        wind = current_block[9]
        gust = current_block[10]
        wind_extra = current_block[11]
        wind_dir = current_block[12]

un bloc fixe de 32 octets avec au début normalement 55 (en hexa) et à la fin de ce bloc l'endroit où se trouve les données.

Ami calmant, J.P