Envoyé par
sambia39
Les deux équipements utilisent l'USB, ce qui veut dire en termes simples que tous équipements industriels ou autres qui utilisent de l'USB ont de facto un driver/pilote nécessaire pour communiquer et contrôler le matériel; on parle de stack USB, ce qui désigne l'API ou l'ensemble des microprogrammes, modules de noyau, pilotes ou de programmes qui permettent d'établir une communication entre le matériel et l'ordinateur via une liaison USB et de le contrôler. Vous ne pouvez donc pas demander à une application de faire des requêtes en dehors de celles acceptées par un driver, d'autant plus que c'est le driver qui a la capacité de connaitre les GUID; VID ou PID et de contrôler le matériel.
Donc, la fausse bonne idée de rajouter une stack network (qui désigne pile réseau) avec certaines fonctions de l'API du fabricant, sans oublier le choix complémentaire de la nano-ordinateur ou carte à microcontrôleur (Arduino), dans le but d'avoir une seule connexion avec le PC final (sachant que le fabricant propose une application serveur voire même les sources de l'application serveur) pour part la suite faire appel aux bonnes fonctions du driver, c'est une perte de temps. Je me permets donc, d'en douter pour la suite ; sans prendre en compte que si un Raspberry est utilisé, il va falloir sérieusement revoir les choses. Plus clairement, prendre en compte les problématique liée à la sécurité (pensé à la sécurité du système d'exploitation : identifications des points de sensibilité ; définir et appliquer une politique de sécurité efficace : déployer des configurations fortes ; isoler l'exécution des applications ; etc. ça rajoute des couches supplémentaires.) Bref, pour moi, Arduino/Raspberry n'ont pas lieu d'être.
Ceci dits; l'employeur souhaite avoir sa propre interface pour contrôler les deux équipements, et pour ça il y a à disposition non seulement les drivers, mais également un ensemble de codes sources fournis par les fabricants. A partir de là, le travail devient un peu plus souple. Pour comprendre, prenons le cas du système d'exploitation Windows (sans trop rentrer dans les détails) : quand un périphérique USB est connecté ou détecté par le système d'exploitation Windows, ce dernier procède alors à une énumération afin d'obtenir les informations d'identification vendeur et périphériques (les fameux VID et PID) pour trouver le pilote qui gère le périphérique et si ce dernier est connu, alors Windows va interroger sa base du registre. Cas contraire, il demandera s'il existe un pilote pour ce périphérique que vous devez fournir : soit le vôtre, soit celui du constructeur.
Considérant maintenant que le pilote existe et est installé, Windows va donc utiliser le driver "machinbidule.sys" ou autres pour dialoguer avec un programme qui va utiliser l'ensemble des codes source ou API fourni par le fabricant. Et a travers les diverses fonctions de cette API le système d'exploitation Windows va procéder a l'ouverture d'une liaison nommée, en utilisant les GUID (qui est un identifiant unique) respectives des deux périphériques connecter; pour que le programme puisse s'interfacer avec les drivers; d'où la raison de mon premier message : celui de connaître les codes sources de l'API et les sources de votre programme, qui aux finales, on a qu'une petite partie (pour le cas de Phidget Interface Kit 0.0.4 c'est-à-dire le relais quant à USB 231 aucune information), mais surtout évaluer s'il est possible à partir de tous ces éléments d'avoir la possibilité d'écrire un pilote générique idée de départ; capable de communiquer avec les deux équipements. En termes plus techniques, un driver pour périphériques multiples. Cependant, avec l'option d'un pilote générique, cela implique concrètement d'avoir un point d'entrée vers les différents pilotes et là aussi cela est peut envisageable.
Bref, de toute façon, c'est à vous de voir....
