electro575 a écrit 841 commentaires

Pour Omnidriver, voici ce qui est dit :

If you are developing with Microsoft Visual Studio, you may use any of these interface methods.
However, if you are developing with any other IDE (e.g., Borland C++ Builder), you may only use the C
and COM interfaces. This is because there is no standard for how C++ name mangling is performed, and
the OmniDriver C++ interface was developed using Microsoft Visual Studio. Using the C++ interface
with an IDE other than Visual Studio results in many "undefined symbol" errors.

Peut être qu'on peut passer par du C sous le compilateur C++ de Qt qui est une surcouche de C++.

Si j'utilise le code C, je n'utiliserais pas la notion d'objet dans ce cas la.
Je retournerais juste les deux tableaux de double.
C'est ca aussi que j'appréhende un peu

Je veux bien faire ça mais pour la suite j'aimerais mettre mon code dans un système embarqué. SeaBreeze est apparemment fait pour ça. Et vu que SeaBreeze fonctionne aussi pour créer mon logiciel, je me dis que ça pourrais être bien de m'en servir pour le logiciel et pour le système embarqué.

Il est dispo seulement pour la compilation gcc mais non avec g++ sous QtCreator.

J'ai déjà testé hors QtCreator avec Omnidriver. Ca fonctionne

je suis bloqué pour faire du multithread avec mon logiciel d'ailleurs!

Je voulais dire par la que je suis entrain de développer la communication un thread pour ça et un pour la gestion de l'interface graphique.

tu utilises donc ton propre code pour dialoguer avec l'appareil

Non, j'utilise les fonctions C++ de SeaBreeze pour dialoguer avec l'appareil.

si tu utilises un logiciel fournit par le fournisseur oceanoptics,
tu as aussi le "bug" sur l "USB400", ou bien tu as ces erreurs de données uniquement avec ton logiciel ?

Si j'utilise un logiciel de chez eux on aurait pas ce problème car ils doivent utiliser Omnidriver avec Mcirosoft Visual Basic et Omnidriver n'est compatible uniquement avec le compilateur C++ MSVC. J'utilise SeaBreeze pour développer mon logiciel sous QtCreator.

Je vais tester les manips que tu me dis dès que j'ai du temps pour ça.

Le blacklister ne servirait à rien alors visiblement !

Je l'ai compilé sur une machine 64 bits.

L'erreur, il n'y en a pas. Enfin, je sais juste observer que les valeurs que je récupère ne sont pas les bonnes. Après je n'ai pas regardé plus loins encore à ce niveau la.

En ce moment je suis bloqué pour faire du multithread avec mon logiciel d'ailleurs! Mais ça c'est une autre histoire

il faut revoir le protocole de test.

Qu'entends-tu par protocole de test?

tu compiles le driver

Tu parles de SeaBreeze?

• soit utiliser un programme que tu sais fonctionner sur une autre machine et l'utiliser sur la machine ou tu testes le driver
• soit faire le programme le plus basic possible,

J'ai pas très bien saisi ce que tu voulais dire!

---

Ce que je peux assurer c'est que SeaBreeze fonctionne avec un matériel mais pas avec l'USB4000 de leur gamme sous Linux.

En fait je lance le protocole d'acquisition classique pour récupérer deux tableaux.

Un tableau concernant les nanomètres
Un tableau concernant les intensités
Tous deux de taille 3648 pour le matériel USB4000

Lorsque je fait un printf du tableau de nanomètre, j'obtiens des valeurs incompréhensible! Mon professeur m'a dit que c'était peut être du à une incompatibilité avec le driver USB sous Linux (ou alors vstmod). Je ne sais pas …

Merci pour ta réponse. J'ai pris SeaBreeze sur ce lien la : SeaBreeze

Je n'ai pas pris le temps de regarder le support pour le moment

Merci beaucoup pour tes précisions. Bonne fin de journée à toi !

Je n'avais pas testé le code de la personne pour le premier lien. Il s'avère que son programme peut lister les périphériques USB.

A moi d'adapter le code à mon application.

Le deuxième lien m'a permit de faire tourner le démon usb.

Une personne m'a indiqué cette librairie pour la communication USB multiplatforme :

Libusb

Merci à toi

Merci à toi

Je pensais peut être qu'avec la description suivante, que je puisse utiliser la fonction udev_monitor_filter_add_match_tag(struct udev_monitor *udev_monitor, const char *tag);

TAG : Attach a tag to a device. This is used to filter events for users of libudev's monitor functionality, or to enumerate a group of tagged devices. The implementation can only work efficiently if only a few tags are attached to a device. It is only meant to be used in contexts with specific device filter requirements, and not as a general-purpose flag. Excessive use might result in inefficient event handling.

Par contre, j'aurais dit comme ceci la syntaxe mais je ne suis pas sur :

ATTRS{idVendor}=="", ATTRS{idProduct}=="", SYMLINK+="", TAG:="essai", MODE:=""

Liens :
LibUdev
Syntaxe_rules

Oui j'ai lu cette page mais pas entièrement.

L'outil udevadm est bien utile.

Je connais déjà le subsystem et le devtype de mon appareil grâce à un programme, je cherche plutôt à mettre un TAG ou alors créer un groupe dans le .rules afin de noter plusieurs périphériques particuliers dont j'aimerais noter les caractéristiques dans mon interface.

Pour le TAG j'ai :
udev_monitor_filter_add_match_tag (struct udev_monitor *udev_monitor, const char *tag);

Pour Subsystem et Devtype j'ai :
udev_monitor_filter_add_match_subsystem_devtype (struct udev_monitor *udev_monitor, const char *subsystem, const char *devtype);

Avec d'autres paramètres je ne peux rien faire. Comme ajouter un groupe je ne sais pas si ça va changer Devtype par exemple…

Voila le lien de la libudev : libudev

Avec ce lien, je ne pense pas qu'il existe de bibliothèque Qt permettant la discussion par USB sur toutes les platformes.

Texte du lien

Problème : la lib qui récupère les infos de mon matériel n'est pas compilable en C++

Solution :
-soit faire un programme pour la gestion de l'USB sous Linux
-soit utiliser une bibliothèque QtCreator pour l'USB, peut être QSerialPort pour gérer l'USB pour toute les platforme et appeler ensuite le programme qui va interroger le matériel.

La deuxième solution serait l'idéal.

Ha ben j'ai pas penser directement passer par une lib Qt pour discuter depuis tous les OS en USB mais effectivement …

Je vais me diriger vers cette option multiplatforme.

Un grand merci, je vous ferais un retour dès que ça fonctionne!

Bonne fin de semaine à vous tous

Solution, connaitre le PID sous le processus lancé de l'interface.cpp !

Peut être que j'arriverai à faire quelque chose et encore c'est pas trop sur

Je comprends ce qu'il veut faire sauf pour monusb.sh et la ligne de code suivante :

/bin/stty -F /dev/$1 57600

fichier /etc/udev/rules.d/70-monusb.rules :

    UBSYSTEMS=="usb", KERNEL=="ttyUSB?",
    ATTRS{interface}=="??",MODE="0666", SYMLINK+="monusb", RUN+="/bin/monusb.sh %k"**

fichier /bin/monusb.sh :

    #!/bin/bash

    sleep 1

    /bin/stty -F /dev/$1 57600
    /bin/stty -F /dev/$1 -icanon
    /bin/stty -F /dev/$1 min 1

L'inconvéniant est que sous QtCreator, je sais lancer un processus en parallèle (ou fils) et lire la sortie standard du processus fils avec l'entrée standard du processus père.

Maintenant, je veux bien lancer un script depuis le .rules avec la commande RUN+="…"
Le souci c'est que je ne sais pas comment créer un tube entre le processus lancé depuis le .rules et le processus père (interface.cpp)

Désolé pour l'affichage … c'est du copie colle!

Pour l'USB dumping, je ne connais pas le langage python mais peut être que je vais m'y mettre.

Je viens de le décompresser !

Des astuces pour compiler tout ça ? comment on se sert des fichiers pythons

Après une lecture du site d'ubuntu à propos de Udev et de la syntaxe des fichiers .rules, je pense qu'il suffi de surveiller avec un démon si un fichier se créé au chemin /dev/truc et après lancer les commandes à partir d'un fichier.

Je ne sais pas si surveiller en permanence si un fichier existe peut poser problème, ou s'il se créé !

En te remerciant. Je vais regarder tout ça ce matin