Publicité
21. Utilisation avec des langages non supportés
Les modules Yoctopuce peuvent être contrôlés depuis la plupart des langages de programmation
courants. De nouveaux langages sont ajoutés régulièrement en fonction de l'intérêt exprimé par les
utilisateurs de produits Yoctopuce. Cependant, certains langages ne sont pas et ne seront jamais
supportés par Yoctopuce, les raisons peuvent être diverses: compilateurs plus disponibles,
environnements inadaptés, etc...
Il existe cependant des méthodes alternatives pour accéder à des modules Yoctopuce depuis un
langage de programmation non supporté.
21.1. Utilisation en ligne de commande
Le moyen le plus simple pour contrôler des modules Yoctopuce depuis un langage non supporté
consiste à utiliser l'API en ligne de commande à travers des appels système. L'API en ligne de
commande se présente en effet sous la forme d'un ensemble de petits exécutables qu'il est facile
d'appeler et dont la sortie est facile à analyser. La plupart des langages de programmation
permettant d'effectuer des appels système, cela permet de résoudre le problème en quelques lignes.
Cependant, si l'API en ligne de commande est la solution la plus facile, ce n'est pas la plus rapide ni
la plus efficace. A chaque appel, l'exécutable devra initialiser sa propre API et faire l'inventaire des
modules USB connectés. Il faut compter environ une seconde par appel.
21.2. Assembly .NET
Un Assembly .NET permet de partager un ensemble de classes précompilées pour offrir un service,
en annonçant des points d'entrées qui peuvent être utilisés par des applications tierces. Dans notre
cas, c'est toute la librairie Yoctopuce qui est disponible dans l'Assembly .NET, de sorte à pouvoir
être utilisée dans n'importe quel environnement qui supporte le chargement dynamique
d'Assembly .NET.
La librairie Yoctopuce sous forme d'Assembly .NET ne contient pas uniquement la librairie
Yoctopuce standard pour C#, car cela n'aurait pas permis une utilisation optimale dans tous les
environnements. En effet, on ne peut pas attendre forcément des applications hôtes d'offrir un
système de threads ou de callbacks, pourtant très utiles pour la gestion du plug-and-play et des
capteurs à taux de rafraîchissements élevé. De même, on ne peut pas attendre des applications
externes un comportement transparent dans le cas où un appel de fonction dans l'Assembly cause
un délai en raison de communication réseau.
Nous y avons donc ajouté une surcouche, appelée librairie .NET Proxy. Cette surcouche offre une
interface très similaire à la librairie standard mais un peu simplifiée, car elle gère en interne tous les
www.yoctopuce.com
157
Publicité
Chapitres
