On nous demande parfois s'il est possible d'utiliser nos modules sans intégrer notre librairie de programmation. En effet, elle peut au premier abord paraître inutilement complexe lorsqu'on ne cherche qu'à commuter un relais ou lire une température. Alors la réponse est oui... mais non. Il existe des manières de réduire l'empreinte mémoire de notre librairie, mais pas au point de tout ramener à quelques échanges de paquets USB forgés à la main. Voyons cela en détail.
Utilisation standard de la librairie
Comme décrit dans notre tutoriel décrivant l'utilisation des modules Yoctopuce, la librairie de programmation n'est pas structurée pour offrir une classe spécifique par produit Yoctopuce, mais une classe par fonctionnalité. Au premier abord, cela peut paraître plus compliqué, mais ça a le grand avantage de permettre à une application de fonctionner sans aucun changement avec différents modules similaires.
Dans les différents exemples fournis avec nos librairie de programmation, nous incluons la plupart du temps la librairie en entier, par simplicité. Elle inclut donc les classes permettant de piloter tous les modules Yoctopuce, même si l'exemple ne les utilise pas. Cela vous permet si nécessaire de partir d'un exemple existant pour un capteur, et de rajouter du code pour piloter un relai par exemple.
Si vous désirez réduire les dépendances inutiles, vous pouvez supprimer tous les fichiers concernant les types de fonctions que vous n'utilisez pas. Pour la plupart des langages, ils sont très faciles à reconnaître: le nom du fichier est yocto_ suivi du type de fonction. Le seul autre fichier obligatoire s'appelle yocto_api. Donc si votre application n'utilise que les fonctions LightSensor et Relay, il vous suffit de garder les fichiers yocto_api, yocto_lightsensor et yocto_relay. Voilà qui devrait réduire considérablement le nombre de fichiers dans votre projet.
Utilisation sans l'interface à haut niveau
Si vous ne pouvez ou ne voulez pas utiliser notre interface objet qui permet d'interagir facilement avec toutes les fonctionnalités des modules Yoctopuce, il est possible de descendre d'un niveau d'abstraction en travaillant directement avec notre librairie C. C'est ce que nous vous avons décrit dans un précédent article. Vous trouverez aussi des informations utiles à ce sujet dans les manuels des modules, dans le chapitre intitulé Utilisation avec des langages non supportés.
L'utilisation directe de cette interface "yapi" en C nécessite de très bonnes connaissances de programmation C. Pour utiliser cette interface en C, vous pouvez référencer dans votre projet soit notre librairie précompilée, soit intégrer directement les fichiers sources .c et .h que vous trouverez dans le sous-répertoire yapi de la librairie C++.
Peut-on faire rétrécir la librairie "yapi" ?
Si vous souhaitez quelque chose d'encore plus petit, vous vous demandez peut-être pourquoi nous avons eu besoin d'une quinzaine de fichiers .c pour coder quelques échanges de paquets USB. N'y a-t-il pas une version encore plus courte ?
La réponse est non: nous n'en avons pas. Notre librairie a été conçue pour pouvoir être compilée sur de nombreuses plateformes, et nous avons donc dû faire quelques abstractions pour supporter les différences entre les systèmes d'exploitation. Vous vous direz peut-être que les threads ne sont pas nécessaires à votre application, mais notre expérience est qu'ils sont nécessaires pour un fonctionnement USB robuste lorsqu'on travaille sans driver, en particulier pour gérer correctement le plug-and-play. Par ailleurs, cette librairie en C peut communiquer avec les modules Yoctopuce aussi bien à travers le réseau que par USB. Même si vous n'avez pas besoin de cette fonctionnalité, il ne sera pas aisé de la retirer car elle est finement intégrée pour être entièrement transparente à l'utilisateur.
Peut-on forger directement des paquets USB ?
On nous a même demandé le format de nos paquets USB pour refaire un pilote plus simple que le notre. Alors, oui ou non ?
Nous n'avons rien à cacher: le format des paquets se trouve dans les fichiers ydef.h et l'essentiel du code qui compose les paquets se trouve dans ystream.c. Mais avant de vous y lancer, soyez conscients que le protocole à bas niveau entre les modules et la librairie n'est pas garanti de rester inchangé. Il a déjà évolué à plusieurs reprises durant les dix dernières années pour ajouter de nouvelles fonctionnalités. Nous maintenons la compatibilité des firmwares et des librairies pour que ces changements soient entièrement transparents à nos utilisateurs, mais si vous faites votre propre implémentation de la couche USB, vous le faites à vos risques et périls.
N'espérez pas trouver l'équivalent d'un port série où l'on pourrait envoyer les commandes et recevoir les mesures. Une telle architecture n'aurait pas permis une gestion propre d'événements asynchrones au milieu des communications synchrones. C'est pourquoi nous avons opté pour un protocole HID plus sophistiqué. Par ailleurs, l'utilisation des paquets HID nous limitant à une trame de 64 bytes par milliseconde, nous ne pouvons ni séparer chaque information différente dans une trame différente, ce qui serait inefficace, ni limiter les messages à une trame, ce qui serait trop contraignant lorsqu'il y a beaucoup d'informations à transférer. Les informations sont donc encodées en streams qui sont multiplexés dans les trames USB, et qui ne sont donc pas si triviales à retrouver sans implémenter la logique complète des streams. Par conséquent, ne comptez pas retrouver les informations à des emplacements fixes dans les paquets USB.
Conclusion
Nous n'avons pas encore rencontré de scénario qui justifie réellement une autre implémentation de l'interface à bas niveau que celle fournie dans notre librairie C. Ceci dit, si vous pensez vraiment avoir une bonne raison de nous le demander, vous pouvez toujours contacter le support Yoctopuce pour voir si nous pouvons faire quelque chose pour vous...