Yocto-maxidisplay-g : manuel d'utilisation

Yocto-MaxiDisplay-G : Manuel d'utilisation

1. Introduction
1.1 Prérequis
1.2 Accessoires optionnels
2. Présentation
2.1 Les éléments communs
2.2 Les éléments spécifiques
3. Principes de fonctionnement
3.1 Processeur et mémoire embarqués
3.2 Orientation
3.3 Système de couche
3.4 Routines graphiques
3.5 Affichage de texte
3.6 Format des fichiers de fontes
3.7 Séquences et animations
3.8 Optimisations
4. Le système de fichiers embarqué
4.1 Utilisation
4.2 Limitations
5. Premiers pas
5.1 Localisation
5.2 Test du module
5.3 Configuration
6. Montage et connectique
6.1 Fixation
6.2 Contraintes d'alimentation par USB
7. Programmation, concepts généraux
7.1 Paradigme de programmation
7.2 Le module Yocto-MaxiDisplay
7.3 Interface de contrôle du module
7.4 Interface de la fonction Display
7.5 Interface de la fonction AnButton
7.6 Interface de la fonction Files
7.7 Quelle interface: Native, DLL ou Service?
7.8 Programmation, par où commencer?
8. Utilisation du Yocto-MaxiDisplay en ligne de commande
8.1 Installation
8.2 Utilisation: description générale
8.3 Contrôle de la fonction Display
8.4 Contrôle de la partie module
8.5 Limitations
9. Utilisation du Yocto-MaxiDisplay en Javascript
9.1 Préparation
9.2 Contrôle de la fonction Display
9.3 Contrôle de la partie module
9.4 Gestion des erreurs
10. Utilisation du Yocto-MaxiDisplay en PHP
10.1 Préparation
10.2 Contrôle de la fonction Display
10.3 Contrôle de la partie module
10.4 API par callback HTTP et filtres NAT
10.5 Gestion des erreurs
11. Utilisation du Yocto-MaxiDisplay en C++
11.1 Contrôle de la fonction Display
11.2 Contrôle de la partie module
11.3 Gestion des erreurs
11.4 Intégration de la librairie Yoctopuce en C++
12. Utilisation du Yocto-MaxiDisplay en Objective-C
12.1 Contrôle de la fonction Display
12.2 Contrôle de la partie module
12.3 Gestion des erreurs
13. Utilisation du Yocto-MaxiDisplay en VisualBasic .NET
13.1 Installation
13.2 Utilisation l'API yoctopuce dans un projet Visual Basic
13.3 Contrôle de la fonction Display
13.4 Contrôle de la partie module
13.5 Gestion des erreurs
14. Utilisation du Yocto-MaxiDisplay en C#
14.1 Installation
14.2 Utilisation l'API yoctopuce dans un projet Visual C#
14.3 Contrôle de la fonction Display
14.4 Contrôle de la partie module
14.5 Gestion des erreurs
15. Utilisation du Yocto-MaxiDisplay en Delphi
15.1 Préparation
15.2 Contrôle de la fonction Display
15.3 Contrôle de la partie module
15.4 Gestion des erreurs
16. Utilisation du Yocto-MaxiDisplay en Python
16.1 Fichiers sources
16.2 Librairie dynamique
16.3 Contrôle de la fonction Display
16.4 Contrôle de la partie module
16.5 Gestion des erreurs
17. Utilisation du Yocto-MaxiDisplay en Java
17.1 Préparation
17.2 Contrôle de la fonction Display
17.3 Contrôle de la partie module
17.4 Gestion des erreurs
18. Utilisation du Yocto-MaxiDisplay avec Android
18.1 Accès Natif et Virtual Hub.
18.2 Préparation
18.3 Compatibilité
18.4 Activer le port USB sous Android
18.5 Contrôle de la fonction Display
18.6 Contrôle de la partie module
18.7 Gestion des erreurs
19. Programmation avancée
19.1 Programmation par événements
20. Utilisation avec des langages non supportés
20.1 Ligne de commande
20.2 Virtual Hub et HTTP GET
20.3 Utilisation des librairies dynamiques
20.4 Port de la librairie haut niveau
21. Référence de l'API de haut niveau
21.1 Fonctions générales
21.2 Interface de contrôle du module
21.3 Interface de la fonction Display
21.4 Interface des objets DisplayLayer
21.5 Interface de la fonction AnButton
21.6 Interface de la fonction Files
22. Problèmes courants
22.1 Linux et USB
22.2 Plateformes ARM: HF et EL
23. Caractéristiques
24. Index

1. Introduction

Le module Yocto-MaxiDisplay est un module de 66x58mm qui permet de piloter un écran OLED monochrome de 128 x 64px ainsi que 6 canaux qui permettant de mesurer l'état d'interrupteurs, boutons poussoir, ou encore de potentiomètres. Cet écran vous permettra d'afficher facilement quelques informations très lisibles depuis une machine qui n'est normalement pas munie d'un moniteur.


Le module Yocto-MaxiDisplay

Yoctopuce vous remercie d'avoir fait l'acquisition de ce Yocto-MaxiDisplay et espère sincèrement qu'il vous donnera entière satisfaction. Les ingénieurs Yoctopuce se sont donnés beaucoup de mal pour que votre Yocto-MaxiDisplay soit facile à installer n'importe où et soit facile à piloter depuis un maximum de langages de programmation. Néanmoins, si ce module venait à vous décevoir n'hésitez pas à contacter le support Yoctopuce1.

Par design, tous les modules Yoctopuce se pilotent de la même façon, c'est pourquoi les documentations des modules de la gamme sont très semblables. Si vous avez déjà épluché la documentation d'un autre module Yoctopuce, vous pouvez directement sauter à la description des fonctions du module.

1.1. Prérequis

Pour pouvoir profiter pleinement de votre module Yocto-MaxiDisplay, vous devriez disposer des éléments suivants.

Un ordinateur

Les modules de Yoctopuce sont destinés à être pilotés par un ordinateur (ou éventuellement un microprocesseur embarqué). Vous écrirez vous-même le programme qui pilotera le module selon vos besoin, à l'aide des informations fournies dans ce manuel.

Yoctopuce fourni les librairies logicielles permettant de piloter ses modules pour les systèmes d'exploitation suivants: Windows, Mac OS X, Linux et Android. Les modules Yoctopuce ne nécessitent pas l'installation de driver (ou pilote) spécifiques, car ils utilisent le driver HID2 fourni en standard dans tous les systèmes d'exploitation.

Les versions de Windows actuellement supportées sont Windows XP, Windows 2003, Windows Vista et Windows 7. Les versions 32 bit et 64 bit sont supportées. Yoctopuce teste régulièrement le bon fonctionnement des modules sur Windows XP et Windows 7.

Les versions de Mac OS X actuellement supportées sont Mac OS X 10.6 (Snow Leopard), 10.7 (Lion) et 10.8 (Mountain Lion). Yoctopuce teste régulièrement le bon fonctionnement des modules sur Mac OS X 10.6 et 10.7.

Les versions de Linux supportées sont les kernels 2.6 et 3.0. D'autre versions du kernel et même d'autres variantes d'Unix sont très susceptibles d'être utilisées sans problème, puisque le support de Linux est fait via l'API standard de la libusb, disponible aussi pour FreeBSD par exemple. Yoctopuce teste régulièrement le bon fonctionnement des modules sur un kernel Linux 2.6.

Les versions de Android actuellement supportées sont 3.1 et suivantes. De plus, il est nécessaire que la tablette ou le téléphone supporte le mode USB Host. Yoctopuce teste régulièrement le bon fonctionnement des modules avec Android 4.0 sur un Nexus 7 et un Samsung Galaxy S3 avec la librairie Java pour Android.

Un cable USB de type A-micro B

Il existe trois tailles de connecteurs USB, la taille "normale" que vous utilisez probablement pour brancher votre imprimante, la taille mini encore très courante et enfin la taille micro, souvent utilisée pour raccorder les téléphones portables, pour autant qu'ils n'arborent pas une pomme. Les modules de Yoctopuce sont tous équipés d'une connectique au format micro-USB.


Les connecteurs USB 2 les plus courants: A, B, Mini B, Micro A, Micro B. 3

Pour connecter votre module Yocto-MaxiDisplay à un ordinateur, vous avez besoin d'un cable USB de type A-micro B. Vous trouverez ce cable en vente à des prix très variables selon les sources, sous la dénomination USB A to micro B Data cable. Prenez garde à ne pas acheter par mégarde un simple câble de charge, qui ne fournirait que le courant mais sans les fils de données. Le bon câble est disponible sur le shop de Yoctopuce.


Vous devez raccorder votre module Yocto-MaxiDisplay à l'aide d'un cable USB de type A - micro B

Si vous branchez un hub USB entre l'ordinateur et le module Yocto-MaxiDisplay, prenez garde à ne pas dépasser les limites de courant imposées par USB, sous peine de faire face des comportements instables non prévisibles. Vous trouverez plus de détail à ce sujet dans le chapitre concernant le montage et la connectique.

1.2. Accessoires optionnels

Les accessoires ci-dessous ne sont pas nécessaires à l'utilisation du module Yocto-MaxiDisplay, mais pourraient vous être utiles selon l'utilisation que vous en faites. Il s'agit en général de produits courants que vous pouvez vous procurer chez vos fournisseurs habituels de matériel de bricolage. Pour vous éviter des recherches, ces produits sont en général aussi disponibles sur le shop de Yoctopuce.

Vis et entretoises

Pour fixer le module Yocto-MaxiDisplay à un support, vous pouvez placer des petites vis de 3mm avec une tête de 8mm au maximum dans les trous prévus ad-hoc. Il est conseillé de les visser dans des entretoises filetées, que vous pourrez fixer sur le support. Vous trouverez plus de détail à ce sujet dans le chapitre concernant le montage et la connectique.

Micro-hub USB

Si vous désirez placer plusieurs modules Yoctopuce dans un espace très restreint, vous pouvez les connecter ensemble à l'aide d'un micro-hub USB. Yoctopuce fabrique des hubs particulièrement petits précisément destinés à cet usage, dont la taille peut être réduite à 20mm par 36mm, et qui se montent en soudant directement les modules au hub via des connecteurs droits ou des câbles nappe. Pour plus de détail, consulter la fiche produit du micro-hub USB.

YoctoHub-Ethernet et YoctoHub-Wireless

Vous pouvez ajouter une connectivité réseau à votre Yocto-MaxiDisplay grâce aux hubs YoctoHub-Ethernet et YoctoHub-Wireless. Le premier offre une connectivité Ethernet, le second offre une connectivité Wifi. Chacun de ces hubs peut piloter jusqu'à trois modules Yoctopuce et se comporte exactement comme un ordinateur normal qui ferait tourner un VirtualHub.

Boîtier

Votre Yocto-MaxiDisplay a été conçu pour pouvoir être installé tel quel dans votre projet. Néanmoins, Yoctopuce commercialise des boîtiers spécialement conçus pour les modules Yoctopuce. Le boîtier recommandé pour pour votre Yocto-MaxiDisplay est le modèle YoctoBox-MaxiDisplay. Il a petit pied amovible qui lui permet de tenir debout, il dispose aussi d'aimants intégrés puissants qui lui permettent de tenir sur des surfaces ferromagnétiques. Vous trouverez plus d'informations à propos de ce boîtier sur le site de Yoctopuce4.


Vous pouvez installer votre Yocto-MaxiDisplay dans un boîtier optionnel.

2. Présentation


1:Prise USB micro-B 4:anButtons test 1 à 6
2:Yocto-bouton 5:Entrées anButtons 1 à 6
3:Yocto-led6:Masse commune

2.1. Les éléments communs

Tous les Yocto-modules ont un certain nombre de fonctionnalités en commun.

Le connecteur USB

Les modules de Yoctopuce sont tous équipés d'une connectique au format micro-USB. Les câbles correspondants ne sont pas forcément les plus faciles à trouver, mais ces connecteurs ont l'avantage d'occuper un minimum de place.

Attention le connecteur USB est simplement soudé en surface et peut être arraché si la prise USB venait à faire levier. Si les pistes sont restées en place, le connecteur peut être ressoudé à l'aide d'un bon fer et de flux. Alternativement, vous pouvez souder un fil USB directement dans les trous espacés de 1.27mm prévus à cet effet, prêt du connecteur.

Le Yocto-bouton

Le Yocto-bouton a deux fonctions. Premièrement, il permet d'activer la Yocto-balise (voir la Yocto-led ci-dessous). Deuxièmement, si vous branchez un Yocto-module en maintenant ce bouton appuyé, il vous sera possible de reprogrammer son firmware avec une nouvelle version. Notez qu'il existe une méthode plus simple pour mettre à jour le firmware depuis l'interface utilisateur, mais cette méthode-là peut fonctionner même lorsque le firmware chargé sur le module est incomplet ou corrompu.

La Yocto-Led

En temps normal la Yocto-Led sert à indiquer le bon fonctionnement du module: elle émet alors une faible lumière bleue qui varie lentement mimant ainsi une respiration. La Yocto-Led cesse de respirer lorsque le module ne communique plus, par exemple si il est alimenté par un hub sans connexion avec un ordinateur allumé.

Lorsque vous appuyez sur le Yocto-bouton, la Led passe en mode Yocto-balise: elle se met alors à flasher plus vite et beaucoup plus fort, dans le but de permettre une localisation facile d'un module lorsqu'on en a plusieurs identiques. Il est en effet possible de déclencher la Yocto-balise par logiciel, tout comme il est possible de détecter par logiciel une Yocto-balise allumée.

La Yocto-Led a une troisième fonctionnalité moins plaisante: lorsque ce logiciel interne qui contrôle le module rencontre une erreur fatale, elle se met à flasher SOS en morse5. Si cela arrivait débranchez puis rebranchez le module. Si le problème venait à se reproduire vérifiez que le module contient bien la dernière version du firmware, et dans l'affirmative contactez le support Yoctopuce6.

La sonde de courant

Chaque Yocto-module est capable de mesurer sa propre consommation de courant sur le bus USB. La distribution du courant sur un bus USB étant relativement critique, cette fonctionnalité peut être d'un grand secours. La consommation de courant du module est consultable par logiciel uniquement.

Le numéro de série

Chaque Yocto-module a un numéro de série unique attribué en usine, pour les modules Yocto-MaxiDisplay ce numéro commence par YD128X64. Le module peut être piloté par logiciel en utilisant ce numéro de série. Ce numéro de série ne peut pas être changé.

Le nom logique

Le nom logique est similaire au numéro de série, c'est une chaine de caractère sensée être unique qui permet référencer le module par logiciel. Cependant, contrairement au numéro de série, le nom logique peut être modifié à volonté. L'intérêt est de pouvoir fabriquer plusieurs exemplaire du même projet sans avoir à modifier le logiciel de pilotage. Il suffit de programmer les même noms logique dans chaque exemplaire. Attention le comportement d'un projet devient imprévisible s'il contient plusieurs modules avec le même nom logique et que le logiciel de pilotage essaye d'accéder à l'un de ces module à l'aide de son nom logique. A leur sortie d'usine, les modules n'ont pas de nom logique assigné, c'est à vous de le définir.

2.2. Les éléments spécifiques

L'écran

L'écran est un écran OLED fabriqué par WiseChip sous la référence UG-2864ASGGG14. Etant en verre, il est assez fragile, ne laissez pas tomber votre Yocto-MaxiDisplay. Lorsque vous installez votre Yocto-MaxiDisplay veillez à ce que l'écran ne soit soumi à aucune contrainte mécanique. De plus la nappe qui sort de l'écran est particulièrement fragile au niveau de la jonction à l'écran, veillez à ce qu'elle ne soit soumise à aucune contrainte mécanique, lorsque vous manipulez le Yocto-MaxiDisplay, veillez à ne pas appuyer sur la nappe.


N'appuyez pas sur la nappe quand vous manipulez le Yocto-MaxiDisplay

Les entrées 1 à 6

Le module Yocto-MaxiDisplay dispose de 6 entrées pemettant de mesurer l'état de composants résistifs (interrupteurs, boutons poussoir, potentiomètres etc.). Ces entrées sont en masse commune, cela signifie que chaque interrupteur / bouton poussoir / potentiomètre doit être relié à la fois à l'entrée correspondante et à la masse. Vous pouvez utiliser n'importe quelle valeur de potentiomètre entre 1KΩ et 200 KΩ.


Câblage d'un potentiomètre, d'un interrupteur et d'un bouton poussoir, en masse commune.

Vous voudrez probablement souder un connecteur à l'endroit prévu à cet effet. Pour accéder au pads, enlevez les vis situées au dos de votre Yocto-MaxiDisplay, écartez délicatement l'écran et soudez votre connecteur. Replacez l'écran ensuite.

Potentiomètres et calibration

Ce module vous permet d'utiliser une grande plage de valeurs de potentiomètres. Mais pour qu'il soit capable de vous donner des mesures cohérentes pour le modèle que vous utiliserez, vous devrez calibrer les canaux correspondant. Cela peut être fait très simplement grâce l'interface de configuration. Il n'est pas nécessaire de faire une calibration si vous utilisez de simple interrupteurs ou encore des boutons poussoirs.

Les boutons poussoirs de test

Chaque canal dispose d'un petit bouton poussoir qui permet de fermer artificiellement le circuit correspondant. Ce qui vous vous aidera probablement à débugger vos projets.

3. Principes de fonctionnement

3.1. Processeur et mémoire embarqués

Comme tous les modules Yoctopuce, votre Yocto-MaxiDisplay dispose d'un processeur embarqué qui lui permet d'effectuer des opérations relativement complexes en toute transparence. Ainsi, pour tracer une ligne, l'ordinateur hôte n'a qu'a envoyer la commande tracer une ligne au Yocto-MaxiDisplay, et ne plus s'occuper de rien, le reste est géré par le processeur du Yocto-MaxiDisplay. A ce titre le Yocto-MaxiDisplay fonctionne un peu comme un accélérateur graphique où les tâches graphiques sont effectuées par un processeur dédié afin de laisser le processeur principal vaquer à d'autres tâches.

Votre Yocto-MaxiDisplay dispose aussi d'un petit système de fichiers qui vous permettra de stocker quelques graphismes, fontes et autres animations.

3.2. Orientation

Afin de faciliter son installation matérielle, votre Yocto-MaxiDisplay peut fonctionner selon quatre orientations différentes. Il suffit de configurer un paramètre pour indiquer la position du connecteur USB (left, up,right,down) par rapport à l'affichage, et l'écran tournera le contenu pour qu'il apparaisse du bon sens.


Effet des paramètres LEFT, UP, RIGHT et DOWN sur l'orientation de l'affichage.

Ce paramètre est persistant et peut être sauvé dans la mémoire flash du Yocto-MaxiDisplay

.

3.3. Système de couche

Votre Yocto-MaxiDisplay fonctionne selon un principe de couche superposées et indépendantes. Vous pouvez écrire et dessiner indépendamment dans chacune des 5 couches. Cela vous permet de simplifier et d'optimiser votre code d'affichage.


Vous disposez de plusieurs couches d'affichage.

Vous pouvez cacher et rendre visible n'importe quelle couche. Vous pouvez déplacer latéralement ces couches qui sont légèrement plus grandes que la surface affichable (128x128), créant ainsi un effet de scrolling. Vous pouvez mettre à profit ce système de couches pour implémenter un système de double buffering 7.

Chaque couche dispose de son propre contexte graphique: position du curseur, police courante, couleur courante etc... cela signifie que vous devrez régler ces paramètres pour chacune des couches avec les lesquelles vous travaillerez. Mais cela signifie aussi que plusieurs processus différents peuvent interagir avec votre Yocto-MaxiDisplay sans risquer de problèmes de concurrence: il suffit qu'ils écrivent dans des couches différentes.

Les primitives permettant de manipuler directement les couches sont:

3.4. Routines graphiques

Votre Yocto-MaxiDisplay dispose des routines graphiques de base: lignes, rectangles, cercles, disques, affichage de texte etc. Toutes ces routines supportent le clipping: vous pouvez écrire à cheval sur la bordure d'une couche, la partie située dans la zone gérée sera prise en compte, et la partie située en dehors sera ignorée.

Pour effectuer des opérations plus complexes, ou simplement si vous le préférez, il est aussi possible d'utiliser la librairie graphique de votre choix pour dessiner sur un bitmap en mémoire dans l'ordinateur pilotant le Yocto-MaxiDisplay, et d'afficher ensuite ce bitmap d'un coup directement sur la couche graphique de votre choix. Cette opération est suffisamment rapide pour fabriquer des animations graphiques arbitraires en temps réel.

Les primitives graphiques de base sont:

Couleurs

L'écran du Yocto-MaxiDisplay est purement monochrome. Vous ne pouvez donc pas afficher de niveaux de gris, ni bénéficier d'anti-aliasing. Vous pouvez dessiner en trois "couleurs": la couleur d'affichage de l'écran (que nous appellerons "blanc" dans cette documentation, même si il s'agit de bleu clair par exemple), en noir ou en transparent (gomme). Lorsque vous écrivez en transparent, les couches inférieures deviennent visibles. Notez que la couche 0 n'a pas de transparence. Écrire en transparent sur cette couche revient à écrire en noir. Cela a son importance lorsque vous intervertissez le contenu de deux couches.

Les primitives permettant de changer de couleur de dessin sont:

3.5. Affichage de texte

Vous pouvez afficher n'importe quel texte à une position arbitraire de l'écran. Le Yocto-MaxiDisplay dispose de quelques polices de caractères embarquées, mais vous pouvez créer les vôtres relativement facilement. Il n'est pas possible de connaître à l'avance la taille d'un texte, mais pour compenser de nombreux mode d'alignement de texte vous sont proposés. Vous pouvez aligner du texte à gauche à droite, centre, en fonction du point décimal, de la base line etc.


Les différentes possibilités d'alignement

Les primitives de base permettant d'afficher un texte sont:

Les polices de caractères préchargées sur le module sont:

Mode console

Il existe une autre méthode pour afficher du texte sur votre Yocto-MaxiDisplay: le mode console. La console est une zone rectangulaire dont la position est paramétrable. Les textes affichés dans cette console sont affichés à la manière d'un terminal, les retours à la ligne et le défilement sont gérés automatiquement. Chaque couche a une console intégrée. La taille par défaut de la console de chaque couche est initialisée à la taille de l'écran.

Les primitives permettant de gérer la console sont:

Internationalisation et caractères régionaux

Les fonctions affichant du texte supportent les caractères internationaux (lettres accentuées, alphabets spéciaux) pour les langues qui remplissent les caractéristiques suivantes:

Pour les jeux de caractères nécessitant plus de 8 bits (par exemple les polices chinoises) et les langages s'écrivant de droite à gauche, la seule solution consiste à construire une image bitmap dans l'ordinateur hôte à l'aide des fonctions du système, et de l'afficher avec la primitive drawBitmap.

Pour tous les autres langages, il suffit d'utiliser la même page de localisation pour la police de caractères et dans le programme pour que les caractères accentués s'affichent correctement. Les polices de caractères préchargées sur les modules correspondent à la locale iso-8859-1 (aussi appelée iso-latin-1 ou Windows-1252) permettant l'affichage des pays de l'ouest de l'Europe, mais vous pouvez facilement générer des polices équivalentes utilisant la locale de votre ordinateur à l'aide du petit utilitaire fourni dans la librairie Delphi, dans le répertoire Examples\Display-font-generator.

En pratique, pour les langages qui supportent intrinsèquement un encodage Unicode (16bit, UTF8 ou autre) comme Python, C#, VB ou Java, vous configurez dans l'API la page de localisation qui doit être utilisée pour ramener les chaînes de caractères à 8 bits. La valeur par défaut est iso-8859-1, puisque c'est celle qui correspond aux polices préchargées dans le module.

Pour les autres langages comme Delphi, C++ où PHP où c'est la page de localisation du fichier source qui détermine implicitement l'interprétation des chaînes de caractères immédiates, et où les conversions sont sous le contrôle direct du programmeur, vous n'avez qu'à vous assurer de passer à l'API de chaînes compatibles avec la police de caractères que vous utilisez sur votre écran. L'erreur la plus fréquence consiste à utiliser un format UTF-8 sans s'en rendre compte (parce que c'est le format utilisé par de nombreux éditeurs modernes) et d'omettre de convertir la chaîne en iso-8859-* avant de la passer en argument à la fonction drawText ou consoleOut. Si vous voyez s'afficher deux lettres bizarres à la place de chaque caractère accentué, c'est que vous êtes dans ce cas de figure.

3.6. Format des fichiers de fontes

Votre Yocto-MaxiDisplay contient quelques fontes intégrées, mais il a été conçu pour que vous puissiez créer vos propres fontes aussi facilement que possible. Un fichier de fonte pour votre Yocto-MaxiDisplay est essentiellement un gros bitmap où tous les caractères sont dessinés dans l'ordre de leur code ASCII, les un derrière les autres. En plus du bitmap, ces fichiers incluent un header contenant quelques informations annexe ainsi qu'une liste des positions de la dernière colonne de chaque caractère. Le format est le suivant:

offsettype    Taille (bytes)signification
0x00U16 2 Signature ("YF" 0x4659, little endian )
0x02U8 1 Version = 1
0x03U8 1 Bits par pixel =1
0x04U16 2 W la largeur du bitmap, little endian,
(doit être un multiple de 16)
0x06U8 1 H la hauteur du bitmap
0x07U8 1 Premier caractère défini
0x08U8 1 Dernier caractère défini
0x09U8 1 Base line (en partant du bas)
0x0AU16[] 2*N coordonnées de la dernière colonne de
chaque caractère (little endian)
0x0A +2*NU8[]H* W / 16Données du bitmap

Exemple pratique

Imaginons que l'on souhaite définir une fonte minuscule 3x5 pixels pour les chiffres 0 à 9, le bitmap correspondrait à ceci.


Exemple de bitmap pour une fonte

Le fichier de fonte contiendra alors les données suivantes:

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 59 46 01 01 30 00 06 01 30 39 03 00 05 00 09 00 00000010 0D 00 11 00 15 00 19 00 1D 00 21 00 25 00 EB BA 00000020 3B BB B8 00 A8 8A 22 0A A8 00 AB BA BB 8B B8 00 00000030 AA 0B 8A 8A 88 00 EB B8 BB 8B B8 00 00 00 00 00 00000040 00 00

Notez que la largeur du bitmap doit être un multiple de 16 pixels, et que la hauteur ne peut pas être plus grande que 255 pixels. Par ailleurs l'espacement entre deux caractères est encodé directement dans l'image. Vous n'êtes pas obligé de laisser un espace vide sous les caractères si vous ne comptez pas utiliser votre fonte en mode console.

Vous trouverez dans la librairie Delphi un petit utilitaire Windows8 vous permettant de générer des fichiers de fontes à partir des fontes système.

3.7. Séquences et animations

Il est possible de pré-programmer des animations pour ensuite les rejouer en tâche de fond. Pour cela il suffit d'appeler la méthode newSequence de l'objet Display, puis de faire appel aux méthodes graphiques disponibles, il est possible s'insérer des temps d'attente avec pauseSequence. Une fois l'enregistrement de éléments de la séquence terminé, appeler saveSequece. La séquence sera alors sauvée dans le file system du Yocto-MaxiDisplay. Elle pourra être rejouée à volonté grâce à playSequence. Il est possible de créer des boucles en appelant playSequence à l'intérieur d'une séquence.

Vous trouverez dans les librairies un exemple de code9 illustrant le fonctionnement des séquences. Dès que cet exemple sera exécuté, l'écran se mettra à jouer la séquence indéfiniment.

Attention, les séquences modifient les paramètres (point courant, couleur courante etc..) des couches avec lesquelles elles travaillent. Si vous utilisez une séquence comme une animation en tache de fond veillez à ne pas travailler avec les mêmes couches que celles utilisées par votre séquence.

Séquence de démarrage

A l'allumage votre Yocto-MaxiDisplay joue la séquence yocto.seq qui est préchargée dans le module, mais vous pouvez configurer votre module pour qu'il exécute une séquence animée de votre choix.

3.8. Optimisations

Le Yocto-MaxiDisplay a beau disposer de son propre processeur et proposer de nombreuses routines graphiques, il reste néanmoins un système relativement lent comparé à un système d'affichage classique. Cette lenteur est essentiellement due au protocole HID utilisé pour que le Yocto-MaxiDisplay puisse être piloté sans drivers. Le taux de transfert entre l'écran et l'ordinateur est limité à 64Ko par seconde. Chaque requête prends environ 3 ms. Il existe cependant des techniques pour optimiser l'affichage.

Écriture dans les couche cachées

Les actions à effectuer sur couches visibles sont envoyées immédiatement à l'écran afin d'être exécutée au plus vite, en revanche les actions à effectuer sur les couches cachées sont bufferisées, permettant ainsi d'envoyer plusieurs commandes d'un coup. Il est donc beaucoup plus efficace d'écrire dans une couche cachée et de la rendre visible après coup, ce qui rend le double buffering très intéressant.

Double buffering

La technique appelée double buffering permet d'afficher des animations sans que les artefacts lié à la construction des graphismes ne soient visibles. Elle consiste à travailler sur deux couches, une visible et une seconde cachée. Les images sont construites dans la couche invisible et à la fin de chaque construction, le contenu des deux couches est permuté. Vous trouverez dans les librairies un exemple10 utilisant cette technique pour animer un flocon de Von Koch.

Utilisation de bitmap

A partir d'une certaine complexité graphique, il sera plus probablement plus efficace de calculer un bitmap directement sur la machine hôte et de l'envoyer à l'écran. Pour cela il suffit d'utiliser la fonction drawBitmap. Les données d'un bitmap sont encodées dans un tableau de bytes, lignes par lignes en partant du coin supérieur gauche. Dans chaque byte, le bit de point le plus fort représente le pixel le plus à gauche. Vous trouverez dans les librairies un exemple11 calculant un ensemble de Mandelbrot basé sur ce principe.

Voici le code en C permettant de dessiner un pixel aux coordonnées (x,y) dans un tableau de bytes représentant un bitmap de w x h

void putpixel(unsigned char *data, int x, int y) { int bytesPerLine = (w + 7) >> 3; data[ (x >> 3) + (y * bytesPerLine) ] |= 128 >> (x & 7); }

4. Le système de fichiers embarqué

Votre Yocto-MaxiDisplay dispose d'un petit système de fichiers embarqué, qui permet de stocker des fichiers personnalisés utilisables par le Yocto-MaxiDisplay. Le système de fichier se manipule grâce à la libraire yocto_files.

4.1. Utilisation

Utilisation interactive avec le virtual hub

Le Virtual Hub fourni une interface sommaire pour manipuler le contenu du système de fichiers: cliquez simplement le bouton configuration correspondant à votre module dans l'interface du Virtual Hub, puis sur le bouton manage files. Les fichiers présents sont listés, et vous pouvez les visualiser, les effacer ou en ajouter (téléchargement).

En raison de sa petite taille, le système de fichiers ne possède pas de notion explicite de répertoire. Vous pouvez toutefois utiliser la barre oblique "/" à l'intérieur des noms de fichiers pour les classer comme si ils étaient dans des répertoires.

Utilisation programmée

Le système de fichiers s'utilise avec la librairie yocto_files. Les fonctions de bases sont disponibles:

Un programme utilisant le système de fichier bien conçu devrait toujours commencer par s'assurer que les fichiers nécessaires à son fonctionnement sont présents sur le module, et si nécessaire les charger sur le module. Cela permet de gérer de manière transparente les mises à jour logicielles et le déploiement de l'application sur des nouveaux modules. Pour faciliter la détection des versions de fichiers présents sur le module, la méthode get_list retourne pour chaque fichier une signature sur 32 bit appelée CRC (Cyclic Redundancy Check), qui identifie de manière fiable le contenu du fichier. Ainsi, si le CRC du fichier correspond, il y a moins d'une chance sur 4 milliards que son contenu ne soit pas le bon. Vous pouvez même calculer dans votre programme par avance le CRC du contenu que vous désirez, et ainsi le vérifier sans avoir à transférer le fichier. La fonction CRC utilisée par le système de fichier Yoctopuce est la même que celle d'Ethernet, Gzip, PNG, etc. Sa valeur caractéristique pour la chaîne de neuf caractères "123456789" est 0xCBF43926.

Utilisation par HTTP

Les fichiers que vous avez chargés sur sur votre Yocto-MaxiDisplay sont accessibles par HTTP, à la racine du module (au même niveau que l'API REST). Cela permet de charger par exemple des pages d'interface HTML et Javascript personnalisées. Vous ne pouvez toutefois pas remplacer le contenu d'un fichier préchargé sur le module, mais seulement en ajouter des nouveaux.

4.2. Limitations

Le filesystem embarqué sur votre Yocto-MaxiDisplay a quelques limitations techniques:

5. Premiers pas

Arrivé à ce chapitre votre Yocto-MaxiDisplay devrait être branché à votre ordinateur, qui devrait l'avoir reconnu. Il est temps de le faire fonctionner.

Rendez-vous sur le site de Yoctopuce et téléchargez le programme Virtual Hub12, Il est disponible pour Windows, Linux et Mac OS X. En temps normal le programme Virtual Hub sert de couche d'abstraction pour les langages qui ne peuvent pas accéder aux couches matérielles de votre ordinateur. Mais il offre aussi une interface sommaire pour configurer vos modules et tester les fonctions de base, on accède à cette interface à l'aide d'un simple browser web 13. Lancez le Virtual Hub en ligne de commande, ouvrez votre browser préféré et tapez l'adresse http://127.0.0.1:4444. Vous devriez voir apparaître la liste des modules Yoctopuce raccordés à votre ordinateur.


Liste des modules telle qu'elle apparaît dans votre browser.

5.1. Localisation

Il est alors possible de localiser physiquement chacun des modules affichés en cliquant sur le bouton beacon, cela a pour effet de mettre la Yocto-Led du module correspondant en mode "balise", elle se met alors à clignoter ce qui permet de la localiser facilement. Cela a aussi pour effet d'afficher une petite pastille bleue à l'écran. Vous obtiendrez le même comportement en appuyant sur le Yocto-bouton d'un module.

5.2. Test du module

La première chose à vérifier est le bon fonctionnement de votre module: cliquez sur le numéro de série correspondant à votre module, et une fenêtre résumant les propriétés de votre Yocto-MaxiDisplay.


Propriétés du module Yocto-MaxiDisplay.

Cette fenêtre vous permet entre autres d'afficher un texte arbitraire sur l'écran et de contrôler l'état des entrées anButtons.

5.3. Configuration

Si, dans la liste de modules, vous cliquez sur le bouton configure correspondant à votre module, la fenêtre de configuration apparaît.


Configuration du module Yocto-MaxiDisplay.

Firmware

Le firmware du module peut être facilement être mis à jour à l'aide de l'interface. Pour ce faire, vous devez au préalable disposer du firmware adéquat sur votre disque local. Les firmwares destinés aux modules Yoctopuce se présentent sous la forme de fichiers .byn et peuvent être téléchargés depuis le site web de Yoctopuce.

Pour mettre à jour un firmware, cliquez simplement sur le bouton upgrade de la fenêtre de configuration et suivez les instructions. Si pour une raison ou une autre, la mise à jour venait à échouer, débranchez puis rebranchez le module. Recommencer la procédure devrait résoudre alors le problème. Si le module a été débranché alors qu'il était en cours de reprogrammation, il ne fonctionnera probablement plus ne sera plus listé dans l'interface. Mais il sera toujours possible de le reprogrammer correctement en utilisant le programme Virtual Hub14 en ligne de commande 15.

Nom logique du module

Le nom logique est un nom choisi par vous, qui vous permettra d'accéder à votre module, de la même matière qu'un nom de fichier vous permet d'accéder à son contenu. Un nom logique doit faire au maximum 19 caractères, les caractères autorisés sont les caractères A..Z a..z 0..9 _ et -. Si vous donnez le même nom logique à deux modules raccordés au même ordinateur, et que vous tentez d'accéder à l'un des modules à l'aide de ce nom logique, le comportement est indéterminé: vous n'avez aucun moyen de savoir lequel des deux va répondre.

Luminosité

Ce paramètre vous permet d'agir sur l'intensité maximale des leds présentes sur le module. Ce qui vous permet, si nécessaire, de le rendre plus un peu discret tout en limitant sa consommation. Notez que ce paramètre agit sur toutes les leds de signalisation du module, y compris la Yocto-Led. Si vous branchez un module et que rien ne s'allume, cela veut peut être dire que sa luminosité a été réglée à zéro.

Nom logique des fonctions

Chaque module Yoctopuce a un numéro de série, et un nom logique. De manière analogue, chaque fonction présente sur chaque module Yoctopuce a un nom matériel et un nom logique, ce dernier pouvant être librement choisi par l'utilisateur. Utiliser des noms logiques pour les fonctions permet une plus grande flexibilité au niveau de la programmation des modules

Les fonctions fournies par le module Yocto-MaxiDisplay sont display qui correspond l'écran, anButton1 à anButton6 pour gérer les entrée potentiomètre et files qui correspond au file system.

6. Montage et connectique

Ce chapitre fournit des explications importantes pour utiliser votre module Yocto-MaxiDisplay en situation réelle. Prenez soin de le lire avant d'aller trop loin dans votre projet si vous voulez éviter les mauvaises surprises.

6.1. Fixation

Pendant la mise au point de votre projet vous pouvez vous contenter de laisser le module se promener au bout de son câble. Veillez simplement à ce qu'il ne soit pas en contact avec quoi que soit de conducteur (comme vos outils). Une fois votre projet pratiquement terminé il faudra penser à faire en sorte que vos modules ne puissent pas se promener à l'intérieur.


Exemples de montage sur un support.

Le module Yocto-MaxiDisplay dispose de trous de montage 3mm. Vous pouvez utiliser ces trous pour y passer des vis. Le diamètre de la tête de ces vis ne devra pas dépasser 8mm, sous peine d'endommager les circuits du module. Veillez à que la surface inférieure du module ne soit pas en contact avec le support. La méthode recommandée consiste à utiliser des entretoises, mais il en existe d'autres. Rien ne vous empêche de le fixer au pistolet à colle; ça ne sera très joli mais ça tiendra.

Si vous comptez visser votre module directement contre une paroi conductrice, un chassis métallique par exemple, intercalez une couche isolante entre les deux. Sinon vous aller à coup sûr provoquer un court-circuit: il y a des pads à nu sous votre module. Du simple ruban adhésif d'emballage devrait faire l'affaire.

6.2. Contraintes d'alimentation par USB

Bien que USB signifie Universal Serial BUS, les périphériques USB ne sont pas organisés physiquement en bus mais en arbre, avec des connections point-à-point. Cela a des conséquences en termes de distribution électrique: en simplifiant, chaque port USB doit alimenter électriquement tous les périphériques qui lui sont directement ou indirectement connectés. Et USB impose des limites.

En théorie, un port USB fournit 100mA, et peut lui fournir (à sa guise) jusqu'à 500mA si le périphérique les réclame explicitement. Dans le cas d'un hub non-alimenté, il a droit à 100mA pour lui-même et doit permettre à chacun de ses 4 ports d'utiliser 100mA au maximum. C'est tout, et c'est pas beaucoup. Cela veut dire en particulier qu'en théorie, brancher deux hub USB non-alimentés en cascade ne marche pas. Pour cascader des hubs USB, il faut utiliser des hubs USB alimentés, qui offriront 500mA sur chaque port.

En pratique, USB n'aurait pas eu le succès qu'il a si il était si contraignant. Il se trouve que par économie, les fabricants de hubs omettent presque toujours d'implémenter la limitation de courant sur les ports: ils se contentent de connecter l'alimentation de tous les ports directement à l'ordinateur, tout en se déclarant comme hub alimenté même lorsqu'ils ne le sont pas (afin de désactiver tous les contrôles de consommation dans le système d'exploitation). C'est assez malpropre, mais dans la mesure ou les ports des ordinateurs sont eux en général protégés par une limitation de courant matérielle vers 2000mA, ça ne marche pas trop mal, et cela fait rarement des dégâts.

Ce que vous devez en retenir: si vous branchez des modules Yoctopuce via un ou des hubs non alimentés, vous n'aurez aucun garde-fou et dépendrez entièrement du soin qu'aura mis le fabricant de votre ordinateur pour fournir un maximum de courant sur les ports USB et signaler les excès avant qu'ils ne conduisent à des pannes ou des dégâts matériels. Si les modules sont sous-alimentés, ils pourraient avoir un comportement bizarre et produire des pannes ou des bugs peu reproductibles. Si vous voulez éviter tout risque, ne cascadez pas les hubs non-alimentés, et ne branchez pas de périphérique consommant plus de 100mA derrière un hub non-alimenté.

Pour vous faciliter le contrôle et la planification de la consommation totale de votre projet, tous les modules Yoctopuce sont équipés d'une sonde de courant qui indique (à 5mA près) la consommation du module sur le bus USB.

7. Programmation, concepts généraux

L'API Yoctopuce a été pensée pour être à la fois simple à utiliser, et suffisamment générique pour que les concepts utilisés soient valables pour tous les modules de la gamme Yoctopuce et ce dans tous les langages de programmation disponibles. Ainsi, une fois que vous aurez compris comment piloter votre Yocto-MaxiDisplay dans votre langage de programmation favori, il est très probable qu'apprendre à utiliser un autre module, même dans un autre langage, ne vous prendra qu'un minimum de temps.

7.1. Paradigme de programmation

L'API Yoctopuce est une API orientée objet. Mais dans un souci de simplicité, seules les bases de la programmation objet ont été utilisées. Même si la programmation objet ne vous est pas familière, il est peu probable que cela vous soit un obstacle à l'utilisation des produits Yoctopuce. Notez que vous n'aurez jamais à allouer ou désallouer un objet lié à l'API Yoctopuce: cela est géré automatiquement.

Il existe une classe par type de fonctionnalité Yoctopuce. Le nom de ces classes commence toujours par un Y suivi du nom de la fonctionnalité, par exemple YTemperature, YRelay, YPressure, etc.. Il existe aussi une classe YModule, dédiée à la gestion des modules en temps que tels, et enfin il existe la classe statique YAPI, qui supervise le fonctionnement global de l'API et gère les communications à bas niveau.


Structure de l'API Yoctopuce.

Dans l'API Yoctopuce, la priorité a été mise sur la facilité d'accès aux fonctionnalités des modules en offrant la possibilité de faire abstraction des modules qui les implémentent. Ainsi, il est parfaitement possible de travailler avec un ensemble de fonctionnalités sans jamais savoir exactement quel module les héberge au niveau matériel. Cela permet de considérablement simplifier la programmation de projets comprenant un nombre important de modules.

Du point de vue programmation, votre Yocto-MaxiDisplay se présente sous la forme d'un module hébergeant un certain nombre de fonctionnalités. Dans l'API , ces fonctionnalités se présentent sous la forme d'objets qui peuvent être retrouvés de manière indépendante, et ce de plusieurs manières.

Accès aux fonctionnalités d'un module

Accès par nom logique

Chacune des fonctionnalités peut se voir assigner un nom logique arbitraire et persistant: il restera stocké dans la mémoire flash du module, même si ce dernier est débranché. Un objet correspondant à une fonctionnalité Xxx munie d'un nom logique pourra ensuite être retrouvée directement à l'aide de ce nom logique et de la méthode YXxx.FindXxx. Notez cependant qu'un nom logique doit être unique parmi tous les modules connectés.

Accès par énumération

Vous pouvez énumérer toutes les fonctionnalités d'un même type sur l'ensemble des modules connectés à l'aide des fonctions classiques d'énumération FirstXxx et nextXxxx disponibles dans chacune des classes YXxx.

Accès par nom hardware

Chaque fonctionnalité d'un module dispose d'un nom hardware, assigné en usine qui ne peut être modifié. Les fonctionnalités d'un module peuvent aussi être retrouvées directement à l'aide de ce nom hardware et de la fonction YXxx.FindXxx de la classe correspondante.

Différence entre Find et First

Les méthodes YXxx.FindXxxx et YXxx.FirstXxxx ne fonctionnent pas exactement de la même manière. Si aucun module n'est disponible YXxx.FirstXxxx renvoie une valeur nulle. En revanche, même si aucun module ne correspond, YXxx.FindXxxx renverra objet valide, qui ne sera pas "online" mais qui pourra le devenir, si le module correspondant est connecté plus tard.

Manipulation des fonctionnalités

Une fois l'objet correspondant à une fonctionnalité retrouvé, ses méthodes sont disponibles de manière tout à fait classique. Notez que la plupart de ces sous-fonctions nécessitent que le module hébergeant la fonctionnalité soit branché pour pouvoir être manipulées. Ce qui n'est en général jamais garanti, puisqu'un module USB peut être débranché après le démarrage du programme de contrôle. La méthode isOnline(), disponible dans chaque classe, vous sera alors d'un grand secours.

Accès aux modules

Bien qu'il soit parfaitement possible de construire un projet en faisant abstraction de la répartition des fonctionnalités sur les différents modules, ces derniers peuvent être facilement retrouvés à l'aide de l'API. En fait, ils se manipulent d'une manière assez semblable aux fonctionnalités. Ils disposent d'un numéro de série affecté en usine qui permet de retrouver l'objet correspondant à l'aide de YModule.Find(). Les modules peuvent aussi se voir affecter un nom logique arbitraire qui permettra de les retrouver ensuite plus facilement. Et enfin la classe YModule comprend les méthodes d'énumération YModule.FirstModule() et nextModule() qui permettent de dresser la liste des modules connectés.

Interaction Function / Module

Du point de vue de l'API, les modules et leurs fonctionnalités sont donc fortement décorrélés à dessein. Mais l'API offre néanmoins la possibilité de passer de l'un à l'autre. Ainsi la méthode get_module(), disponible dans chaque classe de fonctionnalité, permet de retrouver l'objet correspondant au module hébergeant cette fonctionnalité. Inversement, la classe YModule dispose d'un certain nombre de méthodes permettant d'énumérer les fonctionnalités disponibles sur un module.

7.2. Le module Yocto-MaxiDisplay

Le module Yocto-MaxiDisplay est un écran OLED de 128x64 pixels. Il inclut un filesystem permettant de stocker des fichiers (images, polices, séquences) et six instances de la fonction AnButton, correspondant aux six entrées analogiques (lecture de potentiomètre ou de bouton) présentes sur le module.

module : Module

attributtypemodifiable ?
productName  Texte  lecture seule
serialNumber  Texte  lecture seule
logicalName  Texte  modifiable
productId  Entier (hexadécimal)  lecture seule
productRelease  Entier (hexadécimal)  lecture seule
firmwareRelease  Texte  lecture seule
persistentSettings  Type énuméré  modifiable
luminosity  0..100%  modifiable
beacon  On/Off  modifiable
upTime  Temps  lecture seule
usbCurrent  Courant consommé (en mA)  lecture seule
rebootCountdown  Nombre entier  modifiable
usbBandwidth  Type énuméré  modifiable

display : Display
attributtypemodifiable ?
logicalName  Texte  modifiable
advertisedValue  Texte  lecture seule
enabled  Booléen  modifiable
startupSeq  Texte  modifiable
brightness  0..100%  modifiable
orientation  Type énuméré  modifiable
displayWidth  Nombre entier  lecture seule
displayHeight  Nombre entier  lecture seule
displayType  Type énuméré  lecture seule
layerWidth  Nombre entier  lecture seule
layerHeight  Nombre entier  lecture seule
layerCount  Nombre entier  lecture seule
command  Texte  modifiable

files : Files
attributtypemodifiable ?
logicalName  Texte  modifiable
advertisedValue  Texte  lecture seule
filesCount  Nombre entier  lecture seule
freeSpace  Nombre entier  lecture seule

anButton1 : AnButton
anButton2 : AnButton
anButton3 : AnButton
anButton4 : AnButton
anButton5 : AnButton
anButton6 : AnButton
attributtypemodifiable ?
logicalName  Texte  modifiable
advertisedValue  Texte  lecture seule
calibratedValue  Nombre entier  lecture seule
rawValue  Nombre entier  lecture seule
analogCalibration  On/Off  modifiable
calibrationMax  Nombre entier  modifiable
calibrationMin  Nombre entier  modifiable
sensitivity  Nombre entier  modifiable
isPressed  Booléen  lecture seule
lastTimePressed  Temps  lecture seule
lastTimeReleased  Temps  lecture seule
pulseCounter  Nombre entier  modifiable
pulseTimer  Temps  lecture seule

7.3. Interface de contrôle du module

Cette interface est la même pour tous les modules USB de Yoctopuce. Elle permet de contrôler les paramètres généraux du module, et d'énumérer les fonctions fournies par chaque module.

productName

Chaîne de caractères contenant le nom commercial du module, préprogrammé en usine.

serialNumber

Chaine de caractères contenant le numéro de série, unique et préprogrammé en usine. Pour un module Yocto-MaxiDisplay, ce numéro de série commence toujours par YD128X64. Il peut servir comme point de départ pour accéder par programmation à un module particulier.

logicalName

Chaine de caractères contenant le nom logique du module, initialement vide. Cet attribut peut être changé au bon vouloir de l'utilisateur. Une fois initialisé à une valeur non vide, il peut servir de point de départ pour accéder à un module particulier. Si deux modules avec le même nom logique se trouvent sur le même montage, il n'y a pas moyen de déterminer lequel va répondre si l'on tente un accès par ce nom logique. Le nom logique du module est limité à 19 caractères parmi A..Z,a..z,0..9,_ et -.

productId

Identifiant USB du module, préprogrammé à la valeur 48 en usine.

productRelease

Numéro de révision du module hardware, preprogrammed at the factory.

firmwareRelease

Version du logiciel embarqué du module, elle change à chaque fois que le logiciel embarqué est mis à jour.

persistentSettings

Etat des réglages persistants du module: chargés depuis la mémoire non-volatile, modifiés par l'utilisateur ou sauvegardés dans la mémoire non volatile.

luminosity

Intensité lumineuse maximale des leds informatives (comme la Yocto-Led) présentes sur le module. C'est une valeur entière variant entre 0 (leds éteintes) et 100 (leds à l'intensité maximum). La valeur par défaut est 50. Pour changer l'intensité maximale des leds de signalisation du module, ou les éteindre complètement, il suffit donc de modifier cette valeur.

beacon

Etat de la balise de localisation du module.

upTime

Temps écoulé depuis la dernière mise sous tension du module.

usbCurrent

Courant consommé par le module sur le bus USB, en milli-ampères.

rebootCountdown

Compte à rebours pour déclencher un redémarrage spontané du module.

usbBandwidth

Nombre d'interfaces utilisé par USB. L'option DOUBLE permet de doubler le débit USB mais peut saturer un hub USB. N'oubliez pas d'appeler la méthode saveToFlash() et de redémarrer le module pour que le paramètre soit appliqué.

7.4. Interface de la fonction Display

L'interface de contrôle des écrans Yoctopuce est conçue pour afficher facilement des informations et des images. Le module est capable de gérer seul la superposition de plusieurs couches graphiques, qui peuvent être dessinées individuellement, sans affichage immédiat, puis librement positionnées sur l'écran. Il est aussi capable de rejouer des séquences de commandes pré-enregistrées (animations).

logicalName

Chaîne de caractères contenant le nom logique de l'ecran, initialement vide. Cet attribut peut être changé au bon vouloir de l'utilisateur. Un fois initialisé à une valeur non vide, il peut servir de point de départ pour accéder à directement à l'ecran. Si deux écran portent le même nom logique dans un projet, il n'y a pas moyen de déterminer lequel va répondre si l'on tente un accès par ce nom logique. Le nom logique du module est limité à 19 caractères parmi A..Z,a..z,0..9,_ et -.

advertisedValue

Courte chaîne de caractères résumant l'état actuel de l'ecran, et qui sera publiée automatiquement jusqu'au hub parent. Pour un ecran, la valeur publiée est son état (ON ou OFF).

enabled

Etat d'activité de l'écran. L'écran peut être allumé ou éteint à volonté par cet attribut.

startupSeq

Nom de la séquence à jouer à la mise sous tension de l'écran.

brightness

Intensité lumineuse de l'écran. C'est une valeur entière variant entre 0 (écran très sombre) et 100 (écran très lumineux).

orientation

Orientation de l'écran. L'orientation est définie comme le côté de l'écran où se trouve la prise USB lorsque l'écran est droit.

displayWidth

Largeur de l'écran, en pixels.

displayHeight

Hauteur de l'écran, en pixels.

displayType

Type d'écran: monochrome (MONO), niveaux de gris (GRAY) ou couleur (RGB).

layerWidth

Largeur des couches affichables, en pixels.

layerHeight

Hauteur des couches affichables, en pixels.

layerCount

Nombre des couches affichables disponibles.

command

Attribut magique permettant d'envoyer du contenu à l'écran. Si une commande n'est pas interprétée comme attendue, consultez les logs du module.

7.5. Interface de la fonction AnButton

La librairie de programmation Yoctopuce permet aussi bien de mesurer l'état d'un simple bouton que de lire un potentiomètre analogique (résistance variable), comme par exmple bouton rotatif continue, une poignée de commande de gaz ou un joystick. Le module est capable de se calibrer sur les valeurs minimales et maximales du potentiomètre, et de restituer une valeur calibrée variant proportionnellement avec la position du potentiomètre, indépendant de sa résistance totale.

logicalName

Chaîne de caractères contenant le nom logique de l'entrée analogique, initialement vide. Cet attribut peut être changé au bon vouloir de l'utilisateur. Un fois initialisé à une valeur non vide, il peut servir de point de départ pour accéder à directement à l'entrée analogique. Si deux entrées analogiques portent le même nom logique dans un projet, il n'y a pas moyen de déterminer lequel va répondre si l'on tente un accès par ce nom logique. Le nom logique du module est limité à 19 caractères parmi A..Z,a..z,0..9,_ et -.

advertisedValue

Courte chaîne de caractères résumant l'état actuel de l'entrée analogique, et qui sera publiée automatiquement jusqu'au hub parent. Pour une entrée analogique, la valeur publiée est la valeur mesurée recalibrée (a number between 0 and 1000).

calibratedValue

Valeur recalibrée de l'entrée analogique, sous forme d'un entier variant entre 0 et 1000 inclus. Si aucune calibration n'est été faite, la valeur recalibrée est simplement la valeur mesurée ramenée dans l'intervalle 0...1000, sans correction de linéarité.

rawValue

Valeur mesurée de l'entrée analogique telle-quelle, sous forme d'un entier variant entre 0 et 4095. Elle vaut zéro lorsque la résistance à l'entrée est nulle (contact fermé), et tends vers 4095 lorsque la résistance à l'entrée tends vers l'infini (contact ouvert). Attention, cette valeur ne varie pas proportionnellement à la résistance (donc à la position du potentiomètre). Pour obtenir une valeur proportionnelle, lancez une calibration et utilisez la valeur calculée calibratedValue.

analogCalibration

Permet d'enclencher et de déclencher la procédure de calibration automatique de l'entrée analogique. Lorsque la calibration est enclanchée, le module enregistre les valeurs mesurées minimales et maximales dans calibrationMin et calibrationMax. Une fois la calibration terminée (déclenchée), le module peut calculer automatiquement en permanence une valeur recalibrée de la mesure, variant linéairement avec la valeur de résistance mesurée.

calibrationMax

Valeur mesurée maximale observée durant la calibration. Vous pouvez aussi changer cette valeur par logiciel pour imposer une calibration théorique.

calibrationMin

Valeur mesurée minimale observée durant la calibration. Vous pouvez aussi changer cette valeur par logiciel pour imposer une calibration théorique.

sensitivity

Sensibilité de l'entrée analogique pour le déclanchement de callbacks utilisateur. La sensibilité correspond à la différence de valeur nécessaire pour déclancher la propagation d'une nouvelle valeur publiée et l'appel du callback utilisateur correspondant. Une valeur trop petite peut pourrait causer des appels inutiles si l'entrée mesurée n'est pas suffisamment stable.

isPressed

Etat logique de l'entrée, si on la traite comme une entrée binaire (bouton on/off). L'état logique est pressé lorsque l'entrée est fermée, et non pressé lorsque l'entrée est ouverte. Le module implémente un léger lissage et un schmitt trigger qui permettent une mesure logique convenable.

lastTimePressed

Temps absolu de la dernière occurrence de "pression de bouton" a été observée sur l'entrée (transition du contact de ouvert à fermé). La base de temps est la même que l'attribut upTime du module, c'est à dire le temps écoulé depuis la dernière mise sous tension du module.

lastTimeReleased

Temps absolu de la dernière occurrence de "relâchement de bouton" a été observée sur l'entrée (transition du contact de fermé à ouvert). La base de temps est la même que l'attribut upTime du module, c'est à dire le temps écoulé depuis la dernière mise sous tension du module. Si on soustrait à cette valeur le lastTimePressed, on obtien la durée de la dernière pression.

pulseCounter

Compteur d'impulsions, incrémenté à chaque fois que l'état du bouton passe chaque d'état (PRESSED / RELEASED) ce qui signifie que le compteur est incrémenté de deux après chaque impulsion. Ce compteur commence à zéro a chaque redémarage du module.

pulseTimer

Temps écoulé depuis la dernière initilialisation du compteur d'impulsion (millisecondes)

7.6. Interface de la fonction Files

L'interface de stockage de fichiers permet de stocker des fichiers sur certains modules, par exemple pour personnaliser un service web (dans le cas d'un module connecté au réseau) ou pour ajouter un police de caractères (dans le cas d'un module d'affichage).

logicalName

Chaîne de caractères contenant le nom logique du système de fichier, initialement vide. Cet attribut peut être changé au bon vouloir de l'utilisateur. Un fois initialisé à une valeur non vide, il peut servir de point de départ pour accéder à directement à le système de fichier. Si deux système de fichier portent le même nom logique dans un projet, il n'y a pas moyen de déterminer lequel va répondre si l'on tente un accès par ce nom logique. Le nom logique du module est limité à 19 caractères parmi A..Z,a..z,0..9,_ et -.

advertisedValue

Courte chaîne de caractères résumant l'état actuel du système de fichier, et qui sera publiée automatiquement jusqu'au hub parent. Pour un système de fichier, la valeur publiée est le nombre de fichiers présents.

filesCount

Nombre de fichiers présents dans le système de fichier.

freeSpace

Espace disponible dans le système de fichiers pour charger des nouveaux fichiers, en octets.

7.7. Quelle interface: Native, DLL ou Service?

Il y existe plusieurs méthodes pour contrôler un module Yoctopuce depuis un programme.

Contrôle natif

Dans ce cas de figure le programme pilotant votre projet est directement compilé avec une librairie qui offre le contrôle des modules. C'est objectivement la solution la plus simple et la plus élégante pour l'utilisateur final. Il lui suffira de brancher le câble USB et de lancer votre programme pour que tout fonctionne. Malheureusement, cette technique n'est pas toujours disponible ou même possible.


L'application utilise la librairie native pour contrôler le module connecté en local

Contrôle natif par DLL

Ici l'essentiel du code permettant de contrôler les modules se trouve dans une DLL, et le programme est compilé avec une petite librairie permettant de contrôler cette DLL. C'est la manière la plus rapide pour coder le support des modules dans un language particulier. En effet la partie "utile" du code de contrôle se trouve dans la DLL qui est la même pour tous les langages, offrir le support pour un nouveau langage se limite à coder la petite librairie qui contrôle la DLL. Du point de de l'utilisateur final, il y a peu de différence: il faut simplement être sur que la DLL sera installée sur son ordinateur en même temps que le programme principal.


L'application utilise la DLL pour contrôler nativement le module connecté en local

Contrôle par un service

Certain langages ne permettent tout simplement pas d'accéder facilement au niveau matériel de la machine. C'est le cas de Javascript par exemple. Pour gérer ce cas Yoctopuce offre la solution sous la forme d'un petit programme, appelé Hub Virtuel qui lui est capable d'accéder aux modules, et votre application n'a plus qu'à utiliser une librairie qui offrira toutes les fonctions nécessaires au contrôle des modules en passant par l'intermédiaire de ce hub virtuel. L'utilisateur final se verra obligé de lancer le hub virtuel avant de lancer le programme de contrôle du projet proprement dit, à moins qu'il ne décide d'installer le hub sous la forme d'un service/démon, auquel cas le hub virtuel se lancera automatiquement au démarrage de la machine..


L'application se connecte au virtual hub pour connecter le module.

En revanche la méthode de contrôle par un service offre un avantage non négligeable: l'application n'est pas n'obligé de tourner sur la machine où se trouvent les modules: elle peut parfaitement se trouver sur un autre machine qui se connectera au service pour piloter les module. De plus les librairie natives et DLL évoquées plus haut sont aussi capables de se connecter à distance à un ou plusieurs hub virtuels


Lorsqu'on utilise un hub virtuel, l'application de contrôle n'a plus besoin d'être sur la même machine que le module.

Quel que soit langage de programmation choisi et le paradigme de contrôle utilisé; la programmation reste strictement identique. D'un langage à l'autre les fonctions ont exactement le même nom, prennent les mêmes paramètres. Les seules différences sont liées aux contraintes des langages eux-mêmes.

Language Natif  Natif avec .DLL/.so  Hub virtuel 
C++
Objective-C -
Delphi -
Python -
VisualBasic .Net -
C# .Net -
Javascript - -
Node.js - -
PHP - -
Java - -
Java pour Android -
Ligne de commande -

Méthode de support pour les différents langages.

Limitation des librairies Yoctopuce

Les librairies Natives et DLL ont une limitation technique. Sur une même machine, vous ne pouvez pas faire tourner en même temps plusieurs applications qui accèdent nativement aux modules Yoctopuce. Si vous désirez contrôler plusieurs projets depuis la même machine, codez vos applications pour qu'elle accèdent aux modules via un VirtualHub plutôt que nativement. Le changement de mode de fonctionnement est trivial: il suffit de changer un paramètre dans l'appel à yRegisterHub().

7.8. Programmation, par où commencer?

Arrivé à ce point du manuel, vous devriez connaître l'essentiel de la théorie à propos de votre Yocto-MaxiDisplay. Il est temps de passer à la pratique. Il vous faut télécharger la librairie Yoctopuce pour votre language de programmation favori depuis le site web de Yoctopuce16. Puis sautez directement au chapitre correspondant au langage de programmation que vous avez choisi.

Tous les exemples décrits dans ce manuel sont présents dans les librairies de programmation. Dans certains langages, les librairies comprennent aussi quelques applications graphiques complètes avec leur code source.

Une fois que vous maîtriserez la programmation de base de votre module, vous pourrez vous intéresser au chapitre concernant la programmation avancée qui décrit certaines techniques qui vous permettront d'exploiter au mieux votre Yocto-MaxiDisplay.

8. Utilisation du Yocto-MaxiDisplay en ligne de commande

Lorsque vous désirez effectuer une opération ponctuelle sur votre Yocto-MaxiDisplay, comme la lecture d'une valeur, le changement d'un nom logique, etc.. vous pouvez bien sur utiliser le Virtual Hub, mais il existe une méthode encore plus simple, rapide et efficace: l'API en ligne de commande.

L'API en ligne de commande se présente sous la forme d'un ensemble d'exécutables, un par type de fonctionnalité offerte par l'ensemble des produits Yoctopuce. Ces exécutables sont fournis pré-compilés pour toutes les plateformes/OS officiellement supportés par Yoctopuce. Bien entendu, les sources de ces exécutables sont aussi fournies17.

8.1. Installation

Téléchargez l'API en ligne de commande18. Il n'y a pas de programme d'installation à lancer, copiez simplement les exécutables correspondant à votre plateforme/OS dans le répertoire de votre choix. Ajoutez éventuellement ce répertoire à votre variable environnement PATH pour avoir accès aux exécutables depuis n'importe où. C'est tout, il ne vous reste plus qu'à brancher votre Yocto-MaxiDisplay, ouvrir un shell et commencer à travailler en tapant par exemple:

C:\>YDisplay any -layer 0 drawText 64 16 CENTER "Hello world!"

Sous Linux, pour utiliser l'API en ligne de commande, vous devez soit être root, soit définir une règle udev pour votre système. Vous trouverez plus de détails au chapitre Problèmes courants.

8.2. Utilisation: description générale

Tous les exécutables de la l'API en ligne de commande fonctionnent sur le même principe: ils doivent être appelés de la manière suivante:


C:\>Executable [options] [cible] commande [paramètres]

Les [options] gèrent le fonctionnement global des commandes , elles permettent par exemple de piloter des modules à distance à travers le réseau, ou encore elles peuvent forcer les modules à sauver leur configuration après l'exécution de la commande.

La [cible] est le nom du module ou de la fonction auquel la commande va s'appliquer. Certaines commandes très génériques n'ont pas besoin de cible. Vous pouvez aussi utiliser les alias "any" ou "all", ou encore une liste de noms, séparés par des virgules, sans espace.

La commande est la commande que l'on souhaite exécuter. La quasi-totalité des fonctions disponibles dans les API de programmation classiques sont disponibles sous forme de commandes. Vous n'êtes pas obligé des respecter les minuscules/majuscules et les caractères soulignés dans le nom de la commande.

Les [paramètres] sont, assez logiquement, les paramètres dont la commande a besoin.

A tout moment les exécutables de l'API en ligne de commande sont capables de fournir une aide assez détaillée: Utilisez par exemple


C:\>executable /help

pour connaître la liste de commandes disponibles pour un exécutable particulier de l'API en ligne de commande, ou encore:


C:\>executable commande /help

Pour obtenir une description détaillée des paramètres d'une commande.

8.3. Contrôle de la fonction Display

Pour contrôler la fonction Display de votre Yocto-MaxiDisplay, vous avez besoin de l'exécutable YDisplay.

Vous pouvez par exemple lancer:

C:\>YDisplay any -layer 0 drawText 64 16 CENTER "Hello world!"

Cet exemple utilise la cible "any" pour signifier que l'on désire travailler sur la première fonction Display trouvée parmi toutes celles disponibles sur les modules Yoctopuce accessibles au moment de l'exécution. Cela vous évite d'avoir à connaître le nom exact de votre fonction et celui de votre module.

Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté).


C:\>YDisplay YD128X64-123456.display describe

C:\>YDisplay YD128X64-123456.MaFonction describe

C:\>YDisplay MonModule.display describe

C:\>YDisplay MonModule.MaFonction describe

C:\>YDisplay MaFonction describe

Pour travailler sur toutes les fonctions Display à la fois, utilisez la cible "all".


C:\>YDisplay all describe

Pour plus de détails sur les possibilités de l'exécutableYDisplay, utilisez:


C:\>YDisplay /help

8.4. Contrôle de la partie module

Chaque module peut être contrôlé d'une manière similaire à l'aide de l'exécutable YModule. Par exemple, pour obtenir la liste de tous les modules connectés, utilisez:


C:\>YModule inventory

Vous pouvez aussi utiliser la commande suivante pour obtenir une liste encore plus détaillée des modules connectés:


C:\>YModule all describe

Chaque propriété xxx du module peut être obtenue grâce à une commande du type get_xxxx(), et les propriétés qui ne sont pas en lecture seule peuvent être modifiées à l'aide de la commande set_xxx(). Par exemple:


C:\>YModule YD128X64-12346 set_logicalName MonPremierModule

C:\>YModule YD128X64-12346 get_logicalName

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'utiliser la commande set_xxx correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la commande saveToFlash. Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode revertFromFlash. Par exemple:


C:\>YModule YD128X64-12346 set_logicalName MonPremierModule
C:\>YModule YD128X64-12346 saveToFlash

Notez que vous pouvez faire la même chose en seule fois à l'aide de l'option -s


C:\>YModule -s  YD128X64-12346 set_logicalName MonPremierModule

Attention, le nombre de cycles d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit que la sauvegarde des réglages se passera correctement. Cette limite, liée à la technologie employée par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la commande saveToFlash que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette commande depuis l'intérieur d'une boucle.

8.5. Limitations

L'API en ligne de commande est sujette à la même limitation que les autres API: il ne peut y avoir q'une seule application à la fois qui accède aux modules de manière native. Par défaut l'API en ligne de commande fonctionne en natif.

Cette limitation peut aisément être contournée en utilisant un Virtual Hub: il suffit de faire tourner le VirtualHub19 sur la machine concernée et d'utiliser les executables de l'API en ligne de commande avec l'option -r par exemple, si vous utilisez:


C:\>YModule  inventory

Vous obtenez un inventaire des modules connectés par USB, en utilisant un accès natif. Si il y a déjà une autre commande en cours qui accède aux modules en natif, cela ne fonctionnera pas. Mais si vous lancez un virtual hub et que vous lancez votre commande sous la forme:


C:\>YModule -r 127.0.0.1 inventory

cela marchera parce que la commande ne sera plus exécutée nativement, mais à travers le Virtual Hub. Notez que le Virtual Hub compte comme une application native.

9. Utilisation du Yocto-MaxiDisplay en Javascript

Javascript n'est probablement pas le premier langage qui vous serait venu à l'esprit pour contrôler du matériel, mais il présente l'immense avantage d'être très facile à mettre en oeuvre: avec Javascript, il ne vous faudra qu'un éditeur de texte et un browser internet pour réaliser vos premiers essais.

Au moment de l'écriture de ce manuel, la librairie Javascript fonctionne avec n'importe quel browser récent... sauf Opera. Il est probable que qu'Opera finira un jour par fonctionner avec la librairie Yoctopuce20, mais pour l'instant ce n'est pas le cas.

Javascript fait partie de ces langages qui ne vous permettront pas d'accéder directement aux couches matérielles de votre ordinateur. C'est pourquoi vous devrez faire tourner la passerelle de Yoctopuce appelée VirtualHub sur la machine à laquelle sont branchés les modules

9.1. Préparation

Connectez vous sur le site de Yoctopuce et téléchargez les éléments suivants:

Décompressez les fichiers de la librairie dans un répertoire de votre choix, branchez vos modules, lancez le programme VirtualHub,et vous pouvez commencer vos premiers test. Vous n'avez pas besoin d'installer de driver.

9.2. Contrôle de la fonction Display

Il suffit de quelques lignes de code pour piloter un Yocto-MaxiDisplay. Voici le squelette d'un fragment de code JavaScript qui utilise la fonction Display.


<SCRIPT type="text/javascript" src="yocto_api.js">;</SCRIPT>
<SCRIPT type="text/javascript" src="yocto_display.js"></SCRIPT>

// On récupère l'objet représentant le module, à travers le VirtualHub local
yRegisterHub('http://127.0.0.1:4444/');
var display = yFindDisplay("YD128X64-123456.display");

// Pour gérer le hot-plug, on vérifie que le module est là
if(display.isOnline())
{
    // Utiliser display.get_displayLayer(), ...
}

Voyons maintenant en détail ce que font ces quelques lignes.

yocto_api.js et yocto_display.js

Ces deux includes Javascript permettent d'avoir accès aux fonctions permettant de gérer les modules Yoctopuce. yocto_api.js doit toujours être inclus, yocto_display.js est nécessaire pour gérer les modules contenant un ecran, comme le Yocto-MaxiDisplay.

yRegisterHub

La fonction yRegisterHub permet d'indiquer sur quelle machine se trouve les modules Yoctopuce, ou plus exactement la machine sur laquelle tourne le programme VirtualHub. Dans notre cas l'adresse 127.0.0.1:4444 indique la machine locale, en utilisant le port 4444 (le port standard utilisé par Yoctopuce). Vous pouvez parfaitement changer cette adresse, et mettre l'adresse d'une autre machine sur laquelle tournerait un autre VirtualHub.

yFindDisplay

La fonction yFindDisplay, permet de retrouver un ecran en fonction du numéro de série de son module hôte et de son nom de fonction. Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté):


var display = yFindDisplay("YD128X64-123456.display");
var display = yFindDisplay("YD128X64-123456.MaFonction");
var display = yFindDisplay("MonModule.display");
var display = yFindDisplay("MonModule.MaFonction");
var display = yFindDisplay("MaFonction");
</

yFindDisplay renvoie un objet que vous pouvez ensuite utiliser à loisir pour contrôler l'ecran.

isOnline

La méthode isOnline() de l'objet renvoyé par yFindDisplay permet de savoir si le module correspondant est présent et en état de marche.

get_displayLayer

La méthode get_displayLayer() de l'objet renvoyé par YFindDisplay permet récupérer un objet correspondant à une des couches de l'écran. Cet objet implémente toutes les routines graphiques.

Un exemple réel

Ouvrez votre éditeur de texte préféré23, recopiez le code ci-dessous, sauvez-le dans le même répertoire que les fichiers de la librairie, et ouvrez-le avec votre browser favori (sauf Opera). Vous trouverez aussi ce code dans le répertoire Examples/Doc-GettingStarted-Yocto-MaxiDisplay de la librairie Yoctopuce.

Vous reconnaîtrez dans cet exemple l'utilisation des fonctions expliquées ci-dessus, cette fois utilisées avec le décorum nécessaire à en faire un petit programme d'exemple concret.

L'exemple est codé pour être utilisé soit depuis un serveur web, soit en ouvrant directement le fichier localement sur la machine. Notez que cette dernière solution n'est pas possible avec certaines versions de Internet Explorer (en particulier IE 9 de Windows 7), qui refuse d'ouvrir des connections réseau lorsqu'il travaille sur un fichier local. Pour utiliser Internet Explorer, vous devez donc mettre les pages sur un serveur web. Aucun problème par contre avec Chrome, Firefox ou Safari.

Si le Yocto-MaxiDisplay n'est pas branché sur la machine où fonctionne le navigateur internet, remplacez dans l'exemple l'adresse 127.0.0.1 par l'adresse IP de la machine où est branché le Yocto-MaxiDisplay et où vous avez lancé le VirtualHub.

<HTML>
<HEAD>
 <TITLE>Hello World</TITLE>
 <SCRIPT type="text/javascript" src="yocto_api.js"></SCRIPT>
 <SCRIPT type="text/javascript" src="yocto_display.js"></SCRIPT>
 <SCRIPT language='javascript1.5' type='text/JavaScript'>
 <!--

 

 // Setup the API to use the VirtualHub on local machine
 if(yRegisterHub('http://127.0.0.1:4444/') != YAPI_SUCCESS) {
     alert("Cannot contact VirtualHub on 127.0.0.1");
 }

 var disp=null;
 var lastSerial ='';
 var h=0;
 var w=0;
 var l1=null;
 var x,y,vx,vy;

 function run()
 {   var serial = document.getElementById('serial').value;
     if ((disp==null) || (lastSerial != serial))
     { if(serial == '')
       { // Detect any connected module suitable for the demo
         disp = yFirstDisplay();
         if(disp)
           { serial = disp.module().get_serialNumber();
             document.getElementById('serial').value = serial;
           }
       }
       disp = yFindDisplay(serial+".display");
        if(disp.isOnline())  
          document.getElementById('msg').value = '';
             else
         { document.getElementById('msg').value = 'Module not connected';        
           return;
         }  
     
     
      // retreive the display size
      w=disp.get_displayWidth();
      h=disp.get_displayHeight();
           
      // retreive the first layer
      var l0=disp.get_displayLayer(0);
      l1=disp.get_displayLayer(1);

      disp.resetAll();
      l0.clear();

      // display a text in the middle of the screen
      l0.drawText(w / 2, h / 2, Y_ALIGN_CENTER, "Hello world!" );

      // visualize each corner
      l0.moveTo(0,5);l0.lineTo(0,0);l0.lineTo(5,0);
      l0.moveTo(0,h-6);l0.lineTo(0,h-1);l0.lineTo(5,h-1);
      l0.moveTo(w-1,h-6);l0.lineTo(w-1,h-1);l0.lineTo(w-6,h-1);
      l0.moveTo(w-1,5);l0.lineTo(w-1,0);l0.lineTo(w-6,0);

      // draw a circle in the top left corner of layer 1
   
      l1.clear();
      l1.drawCircle(h / 8, h / 8, h / 8);
      x=0; y=0; vx=1; vy=1;
      setTimeout('refresh()',20);
     }
  }

 function refresh()
 {    
    x+=vx;y+=vy;
    if ((x<0) || (x>w-(h / 4)))  vx=-vx;
    if ((y<0) || (y>h-(h / 4)))  vy=-vy;
    l1.setLayerPosition(x,y,0);
    setTimeout('refresh()',10);
 }

 
 -->
 </SCRIPT>
</HEAD>  
<BODY onload='run();'>
 Module to use: <input id='serial'>
 <input id='msg' style='color:red;border:none;' readonly><br>
 
</BODY>
</HTML>
 

9.3. Contrôle de la partie module

Chaque module peut-être contrôlé d'une manière similaire, vous trouverez ci dessous un simple programme d'exemple affichant les principaux paramètres d'un module et permettant d'activer la balise de localisation.

<HTML>
<HEAD>
 <TITLE>Module Control</TITLE>
 <SCRIPT type="text/javascript" src="yocto_api.js"></SCRIPT>
 <SCRIPT language='javascript1.5'  type='text/JavaScript'>
 <!--
 // Use explicit error handling rather than exceptions
 yDisableExceptions();

 // Setup the API to use the VirtualHub on local machine
 if(yRegisterHub('http://127.0.0.1:4444/') != YAPI_SUCCESS) {
     alert("Cannot contact VirtualHub on 127.0.0.1");
 }

 var module;

 function refresh()
 {
     var serial = document.getElementById('serial').value;
     if(serial == '') {
         // Detect any conected module suitable for the demo
         module = yFirstModule().nextModule();
         if(module) {
             serial = module.get_serialNumber();
             document.getElementById('serial').value = serial;
         }
     }

     module = yFindModule(serial);
     if(module.isOnline()) {
         document.getElementById('msg').value = '';
         var html = 'serial: '+module.get_serialNumber()+'<br>';
         html += 'logical name: '+module.get_logicalName()+'<br>';
         html += 'luminosity:'+module.get_luminosity()+'%<br>';
         html += 'beacon:';
         if (module.get_beacon()==Y_BEACON_ON)  
             html+="ON <a href='javascript:beacon(Y_BEACON_OFF)'>switch off</a><br>";
         else  
             html+="OFF <a href='javascript:beacon(Y_BEACON_ON)'>switch on</a><br>";        
         html += 'upTime: '+parseInt(module.get_upTime()/1000)+' sec<br>';
         html += 'USB current: '+module.get_usbCurrent()+' mA<br>';
         html += 'logs:<br><pre>'+module.get_lastLogs()+'</pre><br>';
         document.getElementById('data').innerHTML = html;
     } else {
         document.getElementById('msg').value = 'Module not connected';        
     }
     setTimeout('refresh()',1000);
 }

 function beacon(state)
 {
     module.set_beacon(state);
     refresh();
 }
 -->
 </SCRIPT>
</HEAD>  
<BODY onload='refresh();'>
 Module to use: <input id='serial'>
 <input id='msg' style='color:red;border:none;' readonly><br>
 <span id='data'></span>
</BODY>
</HTML>
 

Chaque propriété xxx du module peut être lue grâce à une méthode du type get_xxxx(), et les propriétés qui se sont pas en lecture seule peuvent être modifiées à l'aide de la méthode set_xxx() Pour plus de détails concernant ces fonctions utilisées, reportez-vous aux chapitre API

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'appeler la fonction set_xxx() correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la méthode saveToFlash(). Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode revertFromFlash(). Ce petit exemple ci-dessous vous permet changer le nom logique d'un module.

<HTML>
<HEAD>
 <TITLE>Change module settings</TITLE>
 <SCRIPT type="text/javascript" src="yocto_api.js"></SCRIPT>
 <SCRIPT language='javascript1.5'  type='text/JavaScript'>
 <!--
 // Use explicit error handling rather than exceptions
 yDisableExceptions();

 // Setup the API to use the VirtualHub on local machine
 if(yRegisterHub('http://127.0.0.1:4444/') != YAPI_SUCCESS) {
     alert("Cannot contact VirtualHub on 127.0.0.1");
 }

 var module;

 function refresh()
 {
     var serial = document.getElementById('serial').value;
     if(serial == '') {
         // Detect any conected module suitable for the demo
         module = yFirstModule().nextModule();
         if(module) {
             serial = module.get_serialNumber();
             document.getElementById('serial').value = serial;
         }
     }

     module = yFindModule(serial);
     if(module.isOnline()) {
         document.getElementById('msg').value = '';
         document.getElementById('curName').value = module.get_logicalName();
     } else {
         document.getElementById('msg').value = 'Module not connected';        
     }
     setTimeout('refresh()',1000);
 }

 function save()
 {
     var newname = document.getElementById('newName').value;
     if (!yCheckLogicalName(newname)) {
         alert('invalid logical name');
         return;
     }
     module.set_logicalName(newname);
     module.saveToFlash();
 }  
 -->
 </SCRIPT>
</HEAD>  
<BODY onload='refresh();'>
 Module to use: <input id='serial'>
 <input id='msg' style='color:red;border:none;' readonly><br>
 Current name: <input id='curName' readonly><br>
 New logical name: <input id='newName'>
 <a href='javascript:save();'>Save</a>
</BODY>
</HTML>
 

Attention, le nombre de cycle d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit de que la sauvegarde des réglages se passera correctement. Cette limite, lié à la technologie employé par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la fonction saveToFlash() que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette fonction depuis l'intérieur d'une boucle.

Énumération des modules

Obtenir la liste des modules connectés se fait à l'aide de la fonction yFirstModule() qui renvoie le premier module trouvé, il suffit ensuite d'appeler la fonction nextModule() de cet objet pour trouver les modules suivants, et ce tant que la réponse n'est pas un NULL. Ci-dessous un petit exemple listant les module connectés

<HTML>
<HEAD>
 <TITLE>Modules inventory</TITLE>
 <SCRIPT type="text/javascript" src="yocto_api.js"></SCRIPT>
 <SCRIPT language='javascript1.5'  type='text/JavaScript'>
 <!--
 // Use explicit error handling rather than exceptions
 yDisableExceptions();

 // Setup the API to use the VirtualHub on local machine
 if(yRegisterHub('http://127.0.0.1:4444/') != YAPI_SUCCESS) {
     alert("Cannot contact VirtualHub on 127.0.0.1");
 }

 function refresh()
 {
     yUpdateDeviceList();

     var htmlcode = '';
     var module = yFirstModule();
     while(module) {
         htmlcode += module.get_serialNumber()
                     +'('+module.get_productName()+")<br>";
         module = module.nextModule();
     }
     document.getElementById('list').innerHTML=htmlcode;
     setTimeout('refresh()',500);
 }
 -->
 </SCRIPT>
</HEAD>  
<BODY onload='refresh();'>
 <H1>Device list</H1>
 <tt><span id='list'></span></tt>
</BODY>
</HTML>
 

9.4. Gestion des erreurs

Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour interpréter les erreurs signalées par la librairie.

La manière la plus simple de contourner le problème est celle que nous avons employé pour les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est en ligne avec la méthode isOnline() et on suppose ensuite qu'il va y rester pendant la fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait, mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas totalement exclure une erreur se produisant après le isOnline(), qui pourrait faire planter le programme. La seule manière de l'éviter est d'implémenter une des deux techniques de gestion des erreurs décrites ci-dessous.

La méthode recommandée par la plupart des langages de programmation pour la gestion des erreurs imprévisibles est l'utilisation d'exceptions. C'est le comportement par défaut de la librairie Yoctopuce. Si une erreur se produit alors qu'on essaie d'accéder à un module, la librairie va lancer une exception. Dans ce cas, de trois choses l'une:

Comme cette dernière situation n'est pas la plus souhaitable, la librairie Yoctopuce offre une autre alternative pour la gestion des erreurs, permettant de faire un programme robuste sans devoir attraper les exceptions à chaque ligne de code. Il suffit d'appeler la fonction yDisableExceptions() pour commuter la librairie dans un mode où les exceptions de chaque fonction sont systématiquement remplacées par des valeurs de retour particulières, qui peuvent être testées par l'appelant lorsque c'est pertinent. Le nom de la valeur de retour en cas d'erreur pour chaque fonction est systématiquement documenté dans la référence de la librairie. Il suit toujours la même logique: une méthode get_state() retournera une valeur Y_STATE_INVALID, une méthode get_currentValue retournera une valeur Y_CURRENTVALUE_INVALID, etc. Dans tous les cas, la valeur retournée sera du type attendu, et ne sera pas un pointeur nul qui risquerait de faire crasher votre programme. Au pire, si vous affichez la valeur sans la tester, elle sera hors du cadre attendu pour la valeur retournée. Dans le cas de fonctions qui ne retournent à priori pas d'information, la valeur de retour sera YAPI_SUCCESS si tout va bien, et un code d'erreur différent en cas d'échec.

Quand vous travaillez sans les exceptions, il est possible d'obtenir un code d'erreur et un message expliquant l'origine de l'erreur en le demandant à l'objet qui a retourné une erreur à l'aide des méthodes errType() et errMessage(). Ce sont les même informations qui auraient été associées à l'exception si elles avaient été actives.

10. Utilisation du Yocto-MaxiDisplay en PHP

PHP est, tout comme Javascript, un langage assez atypique lorsqu'il s'agit de discuter avec du hardware. Néanmoins, utiliser PHP avec des modules Yoctopuce offre l'opportunité de construire très facilement des sites web capables d'interagir avec leur environnement physique, ce qui n'est pas donné à tous les serveurs web. Cette technique trouve une application directe dans la domotique: quelques modules Yoctopuce, un serveur PHP et vous pourrez interagir avec votre maison depuis n'importe ou dans le monde. Pour autant que vous ayez une connexion internet.

PHP fait lui aussi partie de ces langages qui ne vous permettront pas d'accéder directement aux couches matérielles de votre ordinateur. C'est pourquoi vous devrez faire tourner un hub virtuel sur la machine à laquelle sont branchés les modules

Pour démarrer vos essais en PHP, vous allez avoir besoin d'un serveur PHP 5.3 ou plus 24 de préférence en local sur votre machine. Si vous souhaiter utiliser celui qui se trouve chez votre provider internet, c'est possible, mais vous devrez probablement configurer votre routeur ADSL pour qu'il accepte et forwarde les requêtes TCP sur le port 4444.

10.1. Préparation

Connectez vous sur le site de Yoctopuce et téléchargez les éléments suivants:

Décompressez les fichiers de la librairie dans un répertoire de votre choix accessible à votre serveur web, branchez vos modules, lancez le programme VirtualHub, et vous pouvez commencer vos premiers test. Vous n'avez pas besoin d'installer de driver.

10.2. Contrôle de la fonction Display

Il suffit de quelques lignes de code pour piloter un Yocto-MaxiDisplay. Voici le squelette d'un fragment de code PHP qui utilise la fonction Display.


include('yocto_api.php');
include('yocto_display.php');

// On récupère l'objet représentant le module, à travers le VirtualHub local
yRegisterHub('http://127.0.0.1:4444/',$errmsg);
$display = yFindDisplay("YD128X64-123456.display");

// Pour gérer le hot-plug, on vérifie que le module est là
if(display->isOnline())
{
    // Utiliser display->get_displayLayer(), ...
}

Voyons maintenant en détail ce que font ces quelques lignes.

yocto_api.php et yocto_display.php

Ces deux includes PHP permettent d'avoir accès aux fonctions permettant de gérer les modules Yoctopuce. yocto_api.php doit toujours être inclus, yocto_display.php est nécessaire pour gérer les modules contenant un ecran, comme le Yocto-MaxiDisplay.

yRegisterHub

La fonction yRegisterHub permet d'indiquer sur quelle machine se trouve les modules Yoctopuce, ou plus exactemenent sur quelle machine tourne le programme VirtualHub. Dans notre cas l'adresse 127.0.0.1:4444 indique la machine locale, en utilisant le port 4444 (le port standard utilisé par Yoctopuce). Vous pouvez parfaitement changer cette adresse, et mettre l'adresse d'une autre machine sur laquelle tournerait un autre VirtualHub.

yFindDisplay

La fonction yFindDisplay, permet de retrouver un ecran en fonction du numéro de série de son module hôte et de son nom de fonction. Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté):


$display = yFindDisplay("YD128X64-123456.display");
$display = yFindDisplay("YD128X64-123456.MaFonction");
$display = yFindDisplay("MonModule.display");
$display = yFindDisplay("MonModule.MaFonction");
$display = yFindDisplay("MaFonction");

yFindDisplay renvoie un objet que vous pouvez ensuite utiliser à loisir pour contrôler l'ecran.

isOnline

La méthode isOnline() de l'objet renvoyé par yFindDisplay permet de savoir si le module correspondant est présent et en état de marche.

get_displayLayer

La méthode get_displayLayer() de l'objet renvoyé par YFindDisplay permet récupérer un objet correspondant à une des couches de l'écran. Cet objet implémente toutes les routines graphiques.

Un exemple réel

Ouvrez votre éditeur de texte préféré27, recopiez le code ci dessous, sauvez-le dans un répertoire accessible par votre serveur web/PHP avec les fichiers de la librairie, et ouvrez-la page avec votre browser favori. Vous trouverez aussi ce code dans le répertoire Examples/Doc-GettingStarted-Yocto-MaxiDisplay de la librairie Yoctopuce.

Vous reconnaîtrez dans cet exemple l'utilisation des fonctions expliquées ci-dessus, cette fois utilisées avec le décorum nécessaire à en faire un petit programme d'exemple concret.

<HTML>
<HEAD>
 <TITLE>Hello World</TITLE>
</HEAD>  
<BODY>
<FORM method='get'>
<?php
  include('yocto_api.php');
  include('yocto_display.php');

  // Use explicit error handling rather than exceptions
  yDisableExceptions();

  // Setup the API to use the VirtualHub on local machine
  if(yRegisterHub('http://127.0.0.1:4444/',$errmsg) != YAPI_SUCCESS) {
      die("Cannot contact VirtualHub on 127.0.0.1");
  }

  @$serial = $_GET['serial'];
  if ($serial != '') {
      // Check if a specified module is available online
      $disp = yFindDisplay("$serial.display");  
      if (!$disp->isOnline()) {
          die("Module not connected (check serial and USB cable)");
      }
  } else {
      // or use any connected module suitable for the demo
      $disp = yFirstDisplay();
      if(is_null($disp)) {
          die("No module connected (check USB cable)");
      }  
   }
  $serial = $disp->get_module()->get_serialNumber();
  Print("Module to use: <input name='serial' value='$serial'><br>");

  $disp->resetAll();
  // retreive the display size
  $w=$disp->get_displayWidth();
  $h=$disp->get_displayHeight();

  // reteive the first layer
  $l0=$disp->get_displayLayer(0);
  $l0->clear();

  // display a text in the middle of the screen
  $l0->drawText($w / 2, $h / 2, YDisplayLayer::ALIGN_CENTER, "Hello world!" );

  // visualize each corner
  $l0->moveTo(0,5);      $l0->lineTo(0,0);      $l0->lineTo(5,0);
  $l0->moveTo(0,$h-6);   $l0->lineTo(0,$h-1);   $l0->lineTo(5,$h-1);
  $l0->moveTo($w-1,$h-6);$l0->lineTo($w-1,$h-1);$l0->lineTo($w-6,$h-1);
  $l0->moveTo($w-1,5);   $l0->lineTo($w-1,0);   $l0->lineTo($w-6,0);

?>
<br><input type='submit'>
</FORM>
</BODY>
</HTML>
 

10.3. Contrôle de la partie module

Chaque module peut-être contrôlé d'une manière similaire, vous trouverez ci dessous un simple programme d'exemple affichant les principaux paramètres d'un module et permettant d'activer la balise de localisation.

<HTML>
<HEAD>
 <TITLE>Module Control</TITLE>
</HEAD>
<BODY>
<FORM method='get'>
<?php
  include('yocto_api.php');

  // Use explicit error handling rather than exceptions
  yDisableExceptions();

  // Setup the API to use the VirtualHub on local machine
  if(yRegisterHub('http://127.0.0.1:4444/',$errmsg) != YAPI_SUCCESS) {
      die("Cannot contact VirtualHub on 127.0.0.1 : ".$errmsg);
  }

  @$serial = $_GET['serial'];
  if ($serial != '') {
      // Check if a specified module is available online
      $module = yFindModule("$serial");  
      if (!$module->isOnline()) {
          die("Module not connected (check serial and USB cable)");
      }
  } else {
      // or use any connected module suitable for the demo
      $module = yFirstModule();
      if($module) { // skip VirtualHub
          $module = $module->nextModule();
      }
      if(is_null($module)) {
          die("No module connected (check USB cable)");
      } else {
          $serial = $module->get_serialnumber();
      }
  }
  Print("Module to use: <input name='serial' value='$serial'><br>");

  if (isset($_GET['beacon'])) {
      if ($_GET['beacon']=='ON')
          $module->set_beacon(Y_BEACON_ON);
      else  
          $module->set_beacon(Y_BEACON_OFF);
  }          
  printf('serial: %s<br>',$module->get_serialNumber());
  printf('logical name: %s<br>',$module->get_logicalName());
  printf('luminosity: %s<br>',$module->get_luminosity());
  print('beacon: ');
  if($module->get_beacon() == Y_BEACON_ON) {
      printf("<input type='radio' name='beacon' value='ON' checked>ON ");
      printf("<input type='radio' name='beacon' value='OFF'>OFF<br>");
  } else {
      printf("<input type='radio' name='beacon' value='ON'>ON ");
      printf("<input type='radio' name='beacon' value='OFF' checked>OFF<br>");
  }
  printf('upTime: %s sec<br>',intVal($module->get_upTime()/1000));
  printf('USB current: %smA<br>',$module->get_usbCurrent());
  printf('logs:<br><pre>%s</pre>',$module->get_lastLogs());
?>  
<input type='submit' value='refresh'>
</FORM>
</BODY>
</HTML>
 

Chaque propriété xxx du module peut être lue grâce à une méthode du type get_xxxx(), et les propriétés qui se sont pas en lecture seule peuvent être modifiées à l'aide de la méthode set_xxx() Pour plus de détails concernant ces fonctions utilisées, reportez-vous aux chapitre API

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'appeler la fonction set_xxx() correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la méthode saveToFlash(). Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode revertFromFlash(). Ce petit exemple ci-dessous vous permet changer le nom logique d'un module.

<HTML>
<HEAD>
 <TITLE>save settings</TITLE>
<BODY>
<FORM method='get'>
<?php
  include('yocto_api.php');
 
  // Use explicit error handling rather than exceptions
  yDisableExceptions();

  // Setup the API to use the VirtualHub on local machine
  if(yRegisterHub('http://127.0.0.1:4444/',$errmsg) != YAPI_SUCCESS) {
      die("Cannot contact VirtualHub on 127.0.0.1");
  }

  @$serial = $_GET['serial'];
  if ($serial != '') {
      // Check if a specified module is available online
      $module = yFindModule("$serial");  
      if (!$module->isOnline()) {
          die("Module not connected (check serial and USB cable)");
      }
  } else {
      // or use any connected module suitable for the demo
      $module = yFirstModule();
      if($module) { // skip VirtualHub
          $module = $module->nextModule();
      }
      if(is_null($module)) {
          die("No module connected (check USB cable)");
      } else {
          $serial = $module->get_serialnumber();
      }
  }
  Print("Module to use: <input name='serial' value='$serial'><br>");

  if (isset($_GET['newname'])){
      $newname = $_GET['newname'];
      if (!yCheckLogicalName($newname))
          die('Invalid name');
      $module->set_logicalName($newname);
      $module->saveToFlash();
  }
  printf("Current name: %s<br>", $module->get_logicalName());
  print("New name: <input name='newname' value='' maxlength=19><br>");
?>
<input type='submit'>
</FORM>
</BODY>
</HTML>
 

Attention, le nombre de cycle d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit de que la sauvegarde des réglages se passera correctement. Cette limite, lié à la technologie employé par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la fonction saveToFlash() que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette fonction depuis l'intérieur d'une boucle.

Enumération des modules

Obtenir la liste des modules connectés se fait à l'aide de la fonction yFirstModule() qui renvoie le premier module trouvé, il suffit ensuite d'appeler la fonction nextModule() de cet objet pour trouver les modules suivants, et ce tant que la réponse n'est pas un NULL. Ci-dessous un petit exemple listant les module connectés

<HTML>
<HEAD>
 <TITLE>inventory</TITLE>
</HEAD>
<BODY>
<H1>Device list</H1>
<TT>
<?php
    include('yocto_api.php');
    yRegisterHub("http://127.0.0.1:4444/");
    $module   = yFirstModule();
    while (!is_null($module)) {
        printf("%s (%s)<br>", $module->get_serialNumber(),
               $module->get_productName());
        $module=$module->nextModule();
    }
?>
</TT>
</BODY>
</HTML>
 

10.4. API par callback HTTP et filtres NAT

La librairie PHP est capable de fonctionner dans un mode spécial appelé Yocto-API par callback HTTP. Ce mode permet de contrôler des modules Yoctopuce installés derrière un filtre NAT tel qu'un routeur DSL par exemple, et ce sans avoir à un ouvrir un port. L'application typique est le contrôle de modules Yoctopuce situés sur réseau privé depuis un site Web publique.

Le filtre NAT, avantages et inconvénients

Un routeur DSL qui effectue de la traduction d'adresse réseau (NAT) fonctionne un peu comme un petit central téléphonique privé: les postes internes peuvent s'appeler l'un l'autre ainsi que faire des appels vers l'extérieur, mais vu de l'extérieur, il n'existe qu'un numéro de téléphone officiel, attribué au central téléphonique lui-même. Les postes internes ne sont pas atteignables depuis l'extérieur.


Configuration DSL typique, les machines du LAN sont isolées de l'extérieur par le router DSL

Ce qui, transposé en terme de réseau, donne : les appareils connectés sur un réseau domestique peuvent communiquer entre eux en utilisant une adresse IP locale (du genre 192.168.xxx.yyy), et contacter des serveurs sur Internet par leur adresse publique, mais vu de l'extérieur, il n'y a qu'une seule adresse IP officielle, attribuée au routeur DSL exclusivement. Les différents appareils réseau ne sont pas directement atteignables depuis l'extérieur. C'est assez contraignant, mais c'est une protection relativement efficace contre les intrusions.


Les réponses aux requêtes venant des machines du LAN sont routées.


Mais les requêtes venant de l'extérieur sont bloquées.

Voir Internet sans être vu représente un avantage de sécurité énorme. Cependant, cela signifie qu'a priori, on ne peut pas simplement monter son propre serveur Web publique chez soi pour une installation domotique et offrir un accès depuis l'extérieur. Une solution à ce problème, préconisée par de nombreux vendeurs de domotique, consiste à donner une visibilité externe au serveur de domotique lui-même, en ouvrant un port et en ajoutant une règle de routage dans la configuration NAT du routeur DSL. Le problème de cette solution est qu'il expose le serveur de domotique aux attaques externes.

L'API par callback HTTP résoud ce problème sans qu'il soit nécessaire de modifier la configuration du routeur DSL. Le script de contrôle des modules est placé sur un site externe, et c'est le Virtual Hub qui est chargé de l'appeler à intervalle régulier.


L'API par callback HTTP utilise le VirtualHub, et c'est lui qui initie les requêtes.

Configuration

L'API callback se sert donc du Virtual Hub comme passerelle. Toutes les communications sont initiées par le Virtual Hub, ce sont donc des communication sortantes, et par conséquent parfaitement autorisée par le routeur DSL.

Il faut configurer le VirtualHub pour qu'il appelle le script PHP régulièrement. Pour cela il faut:

  1. Lancer un VirtualHub
  2. Accéder à son interface, généralement 127.0.0.1:4444
  3. Cliquer sur le bouton configure de la ligne correspondant au VirtualHub lui-même
  4. Cliquer sur le bouton edit de la section Outgoing callbacks


Cliquer sur le bouton "configure" de la première ligne


Cliquer sur le bouton "edit" de la section Outgoing callbacks.


Et choisir "Yocto-API callback".

Il suffit alors de définir l'URL du script PHP et, si nécessaire, le nom d'utilisateur et le mot de passe pour accéder à cette URL. Les méthodes d'authentification supportées sont basic et digest. La seconde est plus sûre que la première car elle permet de ne pas transférer le mot de passe sur le réseau.

Utilisation

Du point de vue du programmeur, la seule différence se trouve au niveau de l'appel à la fonction yRegisterHub; au lieu d'utiliser une adresse IP, il faut utiliser la chaîne callback (ou http://callback, qui est équivalent).


include("yocto_api.php");
yRegisterHub("callback");

La suite du code reste strictement identique. Sur l'interface du VirtualHub, il y a en bas de la fenêtre de configuration de l'API par callback HTTP un bouton qui permet de tester l'appel au script PHP.

Il est à noter que le script PHP qui contrôle les modules à distance via l'API par callback HTTP ne peut être appelé que par le VirtualHub. En effet, il a besoin des informations postées par le VirtualHub pour fonctionner. Pour coder un site Web qui contrôle des modules Yoctopuce de manière interactive, il faudra créer une interface utilisateur qui stockera dans un fichier ou une base de données les actions à effectuer sur les modules Yoctopuce. Ces actions seront ensuite lues puis exécutés par le script de contrôle.

Problèmes courants

Pour que l'API par callback HTTP fonctionne, l'option de PHP allow_url_fopen doit être activée. Certains hébergeurs de site web ne l'activent pas par défaut. Le problème se manifeste alors avec l'erreur suivante:

error: URL file-access is disabled in the server configuration

Pour activer cette option, il suffit de créer dans le même répertoire que le script PHP de contrôle un fichier .htaccess contenant la ligne suivante:
php_flag "allow_url_fopen" "On"
Selon la politique de sécurité de l'hébergeur, il n'est parfois pas possible d'autoriser cette option à la racine du site web, où même d'installer des scripts PHP recevant des données par un POST HTTP. Dans ce cas il suffit de placer le script PHP dans un sous-répertoire.

Limitations

Cette méthode de fonctionnement qui permet de passer les filtres NAT à moindre frais a malgré tout un prix. Les communications étant initiées par le Virtual Hub à intervalle plus ou moins régulier, le temps de réaction à un événement est nettement plus grand que si les modules Yoctopuce étaient pilotés en direct. Vous pouvez configurer le temps de réaction dans la fenêtre ad-hoc du Virtual Hub, mais il sera nécessairement de quelques secondes dans le meilleur des cas.

Le mode Yocto-API par callback HTTP n'est pour l'instant disponible qu'en PHP et Node.JS.

10.5. Gestion des erreurs

Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour interpréter les erreurs signalées par la librairie.

La manière la plus simple de contourner le problème est celle que nous avons employé pour les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est en ligne avec la méthode isOnline() et on suppose ensuite qu'il va y rester pendant la fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait, mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas totalement exclure une erreur se produisant après le isOnline(), qui pourrait faire planter le programme. La seule manière de l'éviter est d'implémenter une des deux techniques de gestion des erreurs décrites ci-dessous.

La méthode recommandée par la plupart des langages de programmation pour la gestion des erreurs imprévisibles est l'utilisation d'exceptions. C'est le comportement par défaut de la librairie Yoctopuce. Si une erreur se produit alors qu'on essaie d'accéder à un module, la librairie va lancer une exception. Dans ce cas, de trois choses l'une:

Comme cette dernière situation n'est pas la plus souhaitable, la librairie Yoctopuce offre une autre alternative pour la gestion des erreurs, permettant de faire un programme robuste sans devoir attraper les exceptions à chaque ligne de code. Il suffit d'appeler la fonction yDisableExceptions() pour commuter la librairie dans un mode où les exceptions de chaque fonction sont systématiquement remplacées par des valeurs de retour particulières, qui peuvent être testées par l'appelant lorsque c'est pertinent. Le nom de la valeur de retour en cas d'erreur pour chaque fonction est systématiquement documenté dans la référence de la librairie. Il suit toujours la même logique: une méthode get_state() retournera une valeur Y_STATE_INVALID, une méthode get_currentValue retournera une valeur Y_CURRENTVALUE_INVALID, etc. Dans tous les cas, la valeur retournée sera du type attendu, et ne sera pas un pointeur nul qui risquerait de faire crasher votre programme. Au pire, si vous affichez la valeur sans la tester, elle sera hors du cadre attendu pour la valeur retournée. Dans le cas de fonctions qui ne retournent à priori pas d'information, la valeur de retour sera YAPI_SUCCESS si tout va bien, et un code d'erreur différent en cas d'échec.

Quand vous travaillez sans les exceptions, il est possible d'obtenir un code d'erreur et un message expliquant l'origine de l'erreur en le demandant à l'objet qui a retourné une erreur à l'aide des méthodes errType() et errMessage(). Ce sont les même informations qui auraient été associées à l'exception si elles avaient été actives.

11. Utilisation du Yocto-MaxiDisplay en C++

Le C++ n'est pas le langage le plus simple à maîtriser. Pourtant, si on prend soin à se limiter aux fonctionnalités essentielles, c'est un langage tout à fait utilisable pour des petits programmes vite faits, et qui a l'avantage d'être très portable d'un système d'exploitation à l'autre. Sous Windows, tous les exemples et les modèles de projet sont testés avec Microsoft Visual Studio 2010 Express, disponible gratuitement sur le site de Microsoft 28. Sous Mac OS X, tous les exemples et les modèles de projet sont testés avec XCode 4, disponible sur l'App Store. Par ailleurs, aussi bien sous Mac OS X que sous Linux, vous pouvez compiler les exemples en ligne de commande avec GCC en utilisant le GNUmakefile fourni. De même, sous Windows, un Makefile pour permet de compiler les exemples en ligne de commande, et en pleine connaissance des arguments de compilation et link.

Les librairies Yoctopuce29 pour C++ vous sont fournies au format source dans leur intégralité. Une partie de la librairie de bas-niveau est écrite en C pur sucre, mais vous n'aurez à priori pas besoin d'interagir directement avec elle: tout a été fait pour que l'interaction soit le plus simple possible depuis le C++. La librairie vous est fournie bien entendu aussi sous forme binaire, de sorte à pouvoir la linker directement si vous le préférez.

Vous allez rapidement vous rendre compte que l'API C++ defini beaucoup de fonctions qui retournent des objets. Vous ne devez jamais désallouer ces objets vous-même. Ils seront désalloués automatiquement par l'API à la fin de l'application.

Afin des les garder simples, tous les exemples fournis dans cette documentation sont des applications consoles. Il va de soit que que les fonctionnement des librairies est strictement identiques si vous les intégrez dans une application dotée d'une interface graphique. Vous trouverez dans la dernière section de ce chapitre toutes les informations nécessaires à la création d'un projet à neuf linké avec les librairies Yoctopuce.

11.1. Contrôle de la fonction Display

Il suffit de quelques lignes de code pour piloter un Yocto-MaxiDisplay. Voici le squelette d'un fragment de code C++ qui utilise la fonction Display.


#include "yocto_api.h"
#include "yocto_display.h"

[...]
String  errmsg;
YDisplay *display;

// On récupère l'objet représentant le module (ici connecté en local sur USB)
yRegisterHub("usb", errmsg);
display = yFindDisplay("YD128X64-123456.display");

// Pour gérer le hot-plug, on vérifie que le module est là
if(display->isOnline())
{
    // Utiliser display->get_displayLayer(), ...
}

Voyons maintenant en détail ce que font ces quelques lignes.

yocto_api.h et yocto_display.h

Ces deux fichiers inclus permettent d'avoir accès aux fonctions permettant de gérer les modules Yoctopuce. yocto_api.h doit toujours être utilisé, yocto_display.h est nécessaire pour gérer les modules contenant un ecran, comme le Yocto-MaxiDisplay.

yRegisterHub

La fonction yRegisterHub initialise l'API de Yoctopuce en indiquant où les modules doivent être recherchés. Utilisée avec le paramètre "usb", elle permet de travailler avec les modules connectés localement à la machine. Si l'initialisation se passe mal, cette fonction renverra une valeur différente de YAPI_SUCCESS, et retournera via le paramètre errmsg un explication du problème.

yFindDisplay

La fonction yFindDisplay, permet de retrouver un ecran en fonction du numéro de série de son module hôte et de son nom de fonction. Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté):


YDisplay *display = yFindDisplay("YD128X64-123456.display");
YDisplay *display = yFindDisplay("YD128X64-123456.MaFonction");
YDisplay *display = yFindDisplay("MonModule.display");
YDisplay *display = yFindDisplay("MonModule.MaFonction");
YDisplay *display = yFindDisplay("MaFonction");

yFindDisplay renvoie un objet que vous pouvez ensuite utiliser à loisir pour contrôler l'ecran.

isOnline

La méthode isOnline() de l'objet renvoyé par yFindDisplay permet de savoir si le module correspondant est présent et en état de marche.

get_displayLayer

La méthode get_displayLayer() de l'objet renvoyé par YFindDisplay permet récupérer un objet correspondant à une des couches de l'écran. Cet objet implémente toutes les routines graphiques.

Un exemple réel

Lancez votre environnement C++ et ouvrez le projet exemple correspondant, fourni dans le répertoire Examples/Doc-GettingStarted-Yocto-MaxiDisplay de la librairie Yoctopuce. Si vous préférez travailler avec votre éditeur de texte préféré, ouvrez le fichier main.cpp, vous taperez simplement make dans le répertoire de l'exemple pour le compiler.

Vous reconnaîtrez dans cet exemple l'utilisation des fonctions expliquées ci-dessus, cette fois utilisées avec le décorum nécessaire à en faire un petit programme d'exemple concret.

#include "yocto_api.h"
#include "yocto_display.h"
#include <iostream>
#include <stdio.h>
#include <stdlib.h>

using namespace std;

static void usage(void)
{  
  cout << "Wrong command line arguments" << endl;
  cout << "usage: demo <serial_number>" << endl;
  cout << "       demo <logical_name>" << endl;
  cout << "       demo any (use any discovered device)" << endl;
  u64 now = yGetTickCount();    // dirty active wait loop
  while (yGetTickCount()-now<3000);
  exit(1);
}

int main(int argc, const char * argv[])
{
  string         errmsg;
  string         target;
  YDisplay      *disp;
  YDisplayLayer *l0,*l1;
  int w,h,x,y,vx,vy;
 
  if(argc < 2) {
    usage();
  }

  // Setup the API to use local USB devices
  if (yRegisterHub("usb", errmsg) != YAPI_SUCCESS) {
    cerr << "RegisterHub error: " << errmsg << endl;
    usage();
    return 1;
  }

  target     = (string) argv[1];
  if (target == "any") {
    disp =  yFirstDisplay();        
    if (disp==NULL) {
      cout << "No module connected (check USB cable)" << endl;
      usage();
      return 1;
    }
  } else {
    disp =  yFindDisplay(target + ".display");  
  }
   
  if (!disp->isOnline()) {
    cout << "Module is offline (check USB cable)" << endl;
    usage();
    return 1;
  }

  disp->resetAll();
  // retreive the display size
  w=disp->get_displayWidth();
  h=disp->get_displayHeight();

  // reteive the first layer
  l0=disp->get_displayLayer(0);
  l0->clear();

  // display a text in the middle of the screen
  l0->drawText(w / 2, h / 2, YDisplayLayer::ALIGN_CENTER, "Hello world!" );
  // visualize each corner
  l0->moveTo(0,5);l0->lineTo(0,0);l0->lineTo(5,0);
  l0->moveTo(0,h-6);l0->lineTo(0,h-1);l0->lineTo(5,h-1);
  l0->moveTo(w-1,h-6);l0->lineTo(w-1,h-1);l0->lineTo(w-6,h-1);
  l0->moveTo(w-1,5);l0->lineTo(w-1,0);l0->lineTo(w-6,0);

  // draw a circle in the top left corner of layer 1
  l1=disp->get_displayLayer(1);
  l1->clear();
  l1->drawCircle(h / 8, h / 8, h / 8);

  // and animate the layer
  cout << "Use Ctrl-C to stop";
  x=0; y=0; vx=1; vy=1;
  while (true) {
    x+=vx;y+=vy;
    if ((x<0) || (x>w-(h / 4)))  
      vx=-vx;
    if ((y<0) || (y>h-(h / 4)))  
      vy=-vy;
    l1->setLayerPosition(x,y,0);
    YAPI::Sleep(5,errmsg);
  }
  return 0;
}
 

11.2. Contrôle de la partie module

Chaque module peut-être contrôlé d'une manière similaire, vous trouverez ci dessous un simple programme d'exemple affichant les principaux paramètres d'un module et permettant d'activer la balise de localisation.

#include <iostream>
#include <stdlib.h>

#include "yocto_api.h"

using namespace std;

static void usage(const char *exe)
{
    cout << "usage: " << exe << " <serial or logical name> [ON/OFF]" << endl;
    exit(1);
}


int main(int argc, const char * argv[])
{
    string      errmsg;

    // Setup the API to use local USB devices
    if(yRegisterHub("usb", errmsg) != YAPI_SUCCESS) {
        cerr << "RegisterHub error: " << errmsg << endl;
        return 1;
    }

    if(argc < 2)
        usage(argv[0]);

    YModule *module = yFindModule(argv[1]);  // use serial or logical name
 
    if (module->isOnline()) {
        if (argc > 2) {
            if (string(argv[2]) == "ON")
                module->set_beacon(Y_BEACON_ON);
            else  
                module->set_beacon(Y_BEACON_OFF);
        }          
        cout << "serial:       " << module->get_serialNumber() << endl;
        cout << "logical name: " << module->get_logicalName() << endl;
        cout << "luminosity:   " << module->get_luminosity() << endl;
        cout << "beacon:       ";
        if (module->get_beacon()==Y_BEACON_ON)  
           cout << "ON" << endl;
        else  
           cout << "OFF" << endl;
        cout << "upTime:       " << module->get_upTime()/1000 << " sec" << endl;
        cout << "USB current:  " << module->get_usbCurrent() << " mA" << endl;
        cout << "Logs:"<< endl << module->get_lastLogs() << endl;
    } else {
        cout << argv[1] << " not connected (check identification and USB cable)"
             << endl;
    }
    return 0;
}
 

Chaque propriété xxx du module peut être lue grâce à une méthode du type get_xxxx(), et les propriétés qui se sont pas en lecture seule peuvent être modifiées à l'aide de la méthode set_xxx() Pour plus de détails concernant ces fonctions utilisées, reportez-vous aux chapitre API

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'appeler la fonction set_xxx() correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la méthode saveToFlash(). Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode revertFromFlash(). Ce petit exemple ci-dessous vous permet changer le nom logique d'un module.

#include <iostream>
#include <stdlib.h>

#include "yocto_api.h"

using namespace std;

static void usage(const char *exe)
{
    cerr << "usage: " << exe << " <serial> <newLogicalName>" << endl;
    exit(1);
}

int main(int argc, const char * argv[])
{
    string      errmsg;

    // Setup the API to use local USB devices
    if(yRegisterHub("usb", errmsg) != YAPI_SUCCESS) {
        cerr << "RegisterHub error: " << errmsg << endl;
        return 1;
    }

    if(argc < 2)
        usage(argv[0]);

    YModule *module = yFindModule(argv[1]);  // use serial or logical name
 
    if (module->isOnline()) {
        if (argc >= 3){
            string newname =  argv[2];
            if (!yCheckLogicalName(newname)){
                cerr << "Invalid name (" << newname << ")" << endl;
                usage(argv[0]);
            }
            module->set_logicalName(newname);
            module->saveToFlash();
        }
        cout << "Current name: " << module->get_logicalName() << endl;
    } else {
        cout << argv[1] << " not connected (check identification and USB cable)"
             << endl;
    }
    return 0;
}
 

Attention, le nombre de cycles d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit que la sauvegarde des réglages se passera correctement. Cette limite, liée à la technologie employée par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la fonction saveToFlash() que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette fonction depuis l'intérieur d'une boucle.

Enumeration des modules

Obtenir la liste des modules connectés se fait à l'aide de la fonction yFirstModule() qui renvoie le premier module trouvé, il suffit ensuite d'appeler la fonction nextModule() de cet objet pour trouver les modules suivants, et ce tant que la réponse n'est pas un NULL. Ci-dessous un petit exemple listant les module connectés

#include <iostream>

#include "yocto_api.h"

using namespace std;

int main(int argc, const char * argv[])
{
    string      errmsg;

    // Setup the API to use local USB devices
    if(yRegisterHub("usb", errmsg) != YAPI_SUCCESS) {
        cerr << "RegisterHub error: " << errmsg << endl;
        return 1;
    }

    cout << "Device list: " << endl;

    YModule *module = yFirstModule();
    while (module != NULL) {
        cout << module->get_serialNumber() << " ";
        cout << module->get_productName()  << endl;
        module = module->nextModule();
    }
    return 0;
}
 

11.3. Gestion des erreurs

Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour interpréter les erreurs signalées par la librairie.

La manière la plus simple de contourner le problème est celle que nous avons employé pour les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est en ligne avec la méthode isOnline() et on suppose ensuite qu'il va y rester pendant la fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait, mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas totalement exclure une erreur se produisant après le isOnline(), qui pourrait faire planter le programme. La seule manière de l'éviter est d'implémenter une des deux techniques de gestion des erreurs décrites ci-dessous.

La méthode recommandée par la plupart des langages de programmation pour la gestion des erreurs imprévisibles est l'utilisation d'exceptions. C'est le comportement par défaut de la librairie Yoctopuce. Si une erreur se produit alors qu'on essaie d'accéder à un module, la librairie va lancer une exception. Dans ce cas, de trois choses l'une:

Comme cette dernière situation n'est pas la plus souhaitable, la librairie Yoctopuce offre une autre alternative pour la gestion des erreurs, permettant de faire un programme robuste sans devoir attraper les exceptions à chaque ligne de code. Il suffit d'appeler la fonction yDisableExceptions() pour commuter la librairie dans un mode où les exceptions de chaque fonction sont systématiquement remplacées par des valeurs de retour particulières, qui peuvent être testées par l'appelant lorsque c'est pertinent. Le nom de la valeur de retour en cas d'erreur pour chaque fonction est systématiquement documenté dans la référence de la librairie. Il suit toujours la même logique: une méthode get_state() retournera une valeur Y_STATE_INVALID, une méthode get_currentValue retournera une valeur Y_CURRENTVALUE_INVALID, etc. Dans tous les cas, la valeur retournée sera du type attendu, et ne sera pas un pointeur nul qui risquerait de faire crasher votre programme. Au pire, si vous affichez la valeur sans la tester, elle sera hors du cadre attendu pour la valeur retournée. Dans le cas de fonctions qui ne retournent à priori pas d'information, la valeur de retour sera YAPI_SUCCESS si tout va bien, et un code d'erreur différent en cas d'échec.

Quand vous travaillez sans les exceptions, il est possible d'obtenir un code d'erreur et un message expliquant l'origine de l'erreur en le demandant à l'objet qui a retourné une erreur à l'aide des méthodes errType() et errMessage(). Ce sont les même informations qui auraient été associées à l'exception si elles avaient été actives.

11.4. Intégration de la librairie Yoctopuce en C++

Selon vos besoins et vos préférences, vous pouvez être mené à intégrer de différentes manières la librairie à vos projets. Cette section explique comment implémenter les différentes options.

Intégration au format source

L'intégration de toutes les sources de la librairie dans vos projets a plusieurs avantages:

Pour intégrer le code source, le plus simple est d'inclure simplement le répertoire Sources de la librairie Yoctopuce à votre IncludePath, et d'ajouter tous les fichiers de ce répertoire (y compris le sous-répertoire yapi) à votre projet.

Pour que votre projet se construise ensuite correctement, il faudra linker avec votre projet les librairies systèmes requises, à savoir:

Intégration en librairie statique

L'intégration de de la librairie Yoctopuce sous forme de librairie statique est une manière plus simple de construire un petit exécutable utilisant des modules Yoctopuce. Elle permet une compilation rapide du programme en une seule commande. Elle ne requiert pas non plus l'installation d'une librairie dynamique spécifique à Yoctopuce sur le système final, tout est dans l'exécutable.

Pour intégrer la librairie statique Yoctopuce à votre projet, vous devez inclure le répertoire Sources de la librairie Yoctopuce à votre IncludePath, et ajouter le sous-répertoire de Binaries/... correspondant à votre système d'exploitation à votre LibPath.

Ensuite, pour que votre projet se construise ensuite correctement, il faudra linker avec votre projet la librairie Yoctopuce et les librairies systèmes requises:

Attention, sous Linux, si vous voulez compiler en ligne de commande avec GCC, il est en général souhaitable de linker les librairies systèmes en dynamique et non en statique. Pour mélanger sur la même ligne de commande des librairies statiques et dynamiques, il faut passer les arguments suivants:

gcc (...) -Wl,-Bstatic -lyocto-static -Wl,-Bdynamic -lm -lpthread -lusb-1.0 -lstdc++

Intégration en librairie dynamique

L'intégration de la librairie Yoctopuce sous forme de librairie dynamique permet de produire un exécutable plus petit que les deux méthodes précédentes, et de mettre éventuellement à jour cette librairie si un correctif s'avérait nécessaire sans devoir recompiler le code source de l'application. Par contre, c'est un mode d'intégration qui exigera systématiquement de copier la librairie dynamique sur la machine cible ou l'application devra être lancée (yocto.dll sous Windows, libyocto.so.1.0.1 sous Mac OS X et Linux).

Pour intégrer la librairie dynamique Yoctopuce à votre projet, vous devez inclure le répertoire Sources de la librairie Yoctopuce à votre IncludePath, et ajouter le sous-répertoire de Binaries/... correspondant à votre système d'exploitation à votre LibPath.

Ensuite, pour que votre projet se construise ensuite correctement, il faudra linker avec votre projet la librairie dynamique Yoctopuce et les librairies systèmes requises:

Avec GCC, la ligne de commande de compilation est simplement:

gcc (...) -lyocto -lm -lpthread -lusb-1.0 -lstdc++

12. Utilisation du Yocto-MaxiDisplay en Objective-C

Objective-C est le langage de prédilection pour programmer sous Mac OS X, en raison de son intégration avec le générateur d'interfaces Cocoa. Pour pouvoir utiliser la libraire Objective-C vous aurez impérativement besoin de XCode 4.2, qui est disponible gratuitement sous Lion. Si vous êtes encore sous Snow Leopard il vous faudra être enregistré comme développeur auprès d'Apple pour pourvoir télécharger XCode 4.2. La librairie Yoctopuce est compatible ARC. Il vous sera donc possible de coder vos projet soit en utilisant la traditionnelle méthode de retain / release, soit en activant l'Automatic Reference Counting.

Les librairies Yoctopuce30 pour Objective-C vous sont fournies au format source dans leur intégralité. Une partie de la librairie de bas-niveau est écrite en C pur sucre, mais vous n'aurez à priori pas besoin d'interagir directement avec elle: tout a été fait pour que l'interaction soit le plus simple possible depuis Objective-C.

Vous allez rapidement vous rendre compte que l'API Objective-C définit beaucoup de fonctions qui retournent des objets. Vous ne devez jamais désallouer ces objets vous-même. Ils seront désalloués automatiquement par l'API à la fin de l'application.

Afin des les garder simples, tous les exemples fournis dans cette documentation sont des applications consoles. Il va de soit que que les fonctionnement des librairies est strictement identiques si vous les intégrez dans une application dotée d'une interface graphique. Vous trouverez sur le blog de Yoctopuce un exemple détaillé31 avec des séquences vidéo montrant comment intégrer les fichiers de la librairie à vos projets.

12.1. Contrôle de la fonction Display

Lancez Xcode 4.2 et ouvrez le projet exemple correspondant, fourni dans le répertoire Examples/Doc-GettingStarted-Yocto-MaxiDisplay de la librairie Yoctopuce.

#import <Foundation/Foundation.h>
#import "yocto_api.h"
#import "yocto_display.h"



static void usage(void)
{
    NSLog(@"usage: demo <serial_number> ");
    NSLog(@"       demo <logical_name>");
    NSLog(@"       demo any                 (use any discovered device)");
    exit(1);
}



int main(int argc, const char * argv[])
{
    NSError *error;
    YDisplay *disp;
    YDisplayLayer *l0, *l1;
    int h, w, y, x, vx, vy;
    @autoreleasepool {

        // Setup the API to use local USB devices
        if([YAPI RegisterHub:@"usb": &error] != YAPI_SUCCESS) {
            NSLog(@"RegisterHub error: %@", [error localizedDescription]);
            usage();
            return 1;
        }
        if(argc < 2){
            disp = [YDisplay FirstDisplay];
            if(disp == nil){
                NSLog(@"No module connected (check USB cable)");
                usage();
                return 1;
            }
        } else {
            NSString *target = [NSString stringWithUTF8String:argv[1]];
           
            disp = [YDisplay FindDisplay:target];
            if(![disp isOnline]){
                NSLog(@"Module not connected (check identification and USB cable)");
                usage();
                return 1;
            }
        }
        // clear screen (and all layers)
        [disp resetAll];
        // retreive the display size
        w = [disp get_displayWidth];
        h = [disp get_displayHeight];

        // reteive the first layer
        l0 = [disp get_displayLayer:0];

        // display a text in the middle of the screen
        [l0 drawText:w / 2 :h / 2 :Y_ALIGN_CENTER  :@"Hello world!"];

        // visualize each corner
        [l0 moveTo:0 :5]; [l0 lineTo:0 :0]; [l0 lineTo:5 :0];
        [l0 moveTo:0 :h - 6]; [l0 lineTo:0 :h - 1]; [l0 lineTo:5 :h - 1];
        [l0 moveTo:w - 1 :h - 6]; [l0 lineTo:w - 1 :h - 1]; [l0 lineTo:w - 6 :h - 1];
        [l0 moveTo:w - 1 :5]; [l0 lineTo:w - 1  :0]; [l0 lineTo:w - 6 :0];

        // draw a circle in the top left corner of layer 1
        l1 = [disp get_displayLayer:1];
        [l1 clear];
        [l1 drawCircle:h / 8 :h / 8 :h / 8];

        // and animate the layer
        NSLog(@"Use Ctrl-C to stop");
        x = 0; y = 0; vx = 1; vy = 1;
        while (true) {
            x += vx; y += vy;
            if ((x < 0) || (x > w - (h / 4))) vx = -vx;
            if ((y < 0) || (y > h - (h / 4))) vy = -vy;
            [l1 setLayerPosition:x :y :0];
            [YAPI Sleep:5 :&error];
        }
        [YAPI FreeAPI];
    }
   
    return 0;
}
 

Il n'y a que peu de lignes véritablement importantes dans le code précédent. Nous allons les expliquer en détail.

yocto_api.h et yocto_display.h

Ces deux fichiers importés permettent d'avoir accès aux fonctions permettant de gérer les modules Yoctopuce. yocto_api.h doit toujours être utilisé, yocto_display.h est nécessaire pour gérer les modules contenant un ecran, comme le Yocto-MaxiDisplay.

yRegisterHub

La fonction yRegisterHub initialise l'API de Yoctopuce en indiquant où les modules doivent être recherchés. Utilisée avec le paramètre @"usb", elle permet de travailler avec les modules connectés localement à la machine. Si l'initialisation se passe mal, cette fonction renverra une valeur différente de YAPI_SUCCESS, et retournera via le paramètre errmsg un explication du problème.

yFindDisplay

La fonction yFindDisplay, permet de retrouver un ecran en fonction du numéro de série de son module hôte et de son nom de fonction. Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté):


YDisplay *display = yFindDisplay(@"YD128X64-123456.display");
YDisplay *display = yFindDisplay(@"YD128X64-123456.MaFonction");
YDisplay *display = yFindDisplay(@"MonModule.display");
YDisplay *display = yFindDisplay(@"MonModule.MaFonction");
YDisplay *display = yFindDisplay(@"MaFonction");

yFindDisplay renvoie un objet que vous pouvez ensuite utiliser à loisir pour contrôler l'ecran.

isOnline

La méthode isOnline() de l'objet renvoyé par yFindDisplay permet de savoir si le module correspondant est présent et en état de marche.

get_displayLayer

La méthode get_displayLayer() de l'objet renvoyé par YFindDisplay permet récupérer un objet correspondant à une des couches de l'écran. Cet objet implémente toutes les routines graphiques.

12.2. Contrôle de la partie module

Chaque module peut-être contrôlé d'une manière similaire, vous trouverez ci dessous un simple programme d'exemple affichant les principaux paramètres d'un module et permettant d'activer la balise de localisation.

#import <Foundation/Foundation.h>
#import "yocto_api.h"

static void usage(const char *exe)
{
    NSLog(@"usage: %s <serial or logical name> [ON/OFF]\n",exe);
    exit(1);
}


int main (int argc, const char * argv[])
{
    NSError *error;
   
    @autoreleasepool {
        // Setup the API to use local USB devices
        if([YAPI RegisterHub:@"usb": &error] != YAPI_SUCCESS) {
            NSLog(@"RegisterHub error: %@", [error localizedDescription]);
            return 1;
        }
        if(argc < 2)
            usage(argv[0]);
        NSString *serial_or_name =[NSString stringWithUTF8String:argv[1]];
        YModule *module = [YModule FindModule:serial_or_name];  // use serial or logical name
        if ([module isOnline]) {
            if (argc > 2) {
                if (strcmp(argv[2], "ON")==0)
                    [module setBeacon:Y_BEACON_ON];
                else  
                    [module setBeacon:Y_BEACON_OFF];
            }        
            NSLog(@"serial:       %@\n", [module serialNumber]);
            NSLog(@"logical name: %@\n", [module logicalName]);
            NSLog(@"luminosity:   %d\n", [module luminosity]);
            NSLog(@"beacon:       ");
            if ([module beacon] == Y_BEACON_ON)
               NSLog(@"ON\n");
            else  
               NSLog(@"OFF\n");
            NSLog(@"upTime:       %d sec\n", [module upTime]/1000);
            NSLog(@"USB current:  %d mA\n",  [module usbCurrent]);
            NSLog(@"logs:  %@\n",  [module get_lastLogs]);
        } else {
            NSLog(@"%@ not connected (check identification and USB cable)\n",serial_or_name);
        }
    }
    return 0;
}
 

Chaque propriété xxx du module peut être lue grâce à une méthode du type get_xxxx, et les propriétés qui se sont pas en lecture seule peuvent être modifiées à l'aide de la méthode set_xxx: Pour plus de détails concernant ces fonctions utilisées, reportez-vous aux chapitre API

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'appeler la fonction set_xxx: correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la méthode saveToFlash. Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode revertFromFlash. Ce petit exemple ci-dessous vous permet changer le nom logique d'un module.

#import <Foundation/Foundation.h>
#import "yocto_api.h"

static void usage(const char *exe)
{
    NSLog(@"usage: %s <serial> <newLogicalName>\n",exe);
    exit(1);
}


int main (int argc, const char * argv[])
{
    NSError *error;

    @autoreleasepool {
        // Setup the API to use local USB devices
        if(yRegisterHub(@"usb", &error) != YAPI_SUCCESS) {
            NSLog(@"RegisterHub error: %@", [error localizedDescription]);
            return 1;
        }

        if(argc < 2)
            usage(argv[0]);

        NSString *serial_or_name =[NSString stringWithUTF8String:argv[1]];
        YModule *module = yFindModule(serial_or_name);  // use serial or logical name
     
        if (module.isOnline) {
            if (argc >= 3){
                NSString *newname =  [NSString stringWithUTF8String:argv[2]];
                if (!yCheckLogicalName(newname)){
                    NSLog(@"Invalid name (%@)\n", newname);
                    usage(argv[0]);
                }
                module.logicalName = newname;
                [module saveToFlash];
            }
            NSLog(@"Current name: %@\n", module.logicalName);
        } else {
            NSLog(@"%@ not connected (check identification and USB cable)\n",serial_or_name);
        }
    }
    return 0;
}
 

Attention, le nombre de cycles d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit que la sauvegarde des réglages se passera correctement. Cette limite, liée à la technologie employée par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la fonction saveToFlash que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette fonction depuis l'intérieur d'une boucle.

Enumeration des modules

Obtenir la liste des modules connectés se fait à l'aide de la fonction yFirstModule() qui renvoie le premier module trouvé, il suffit ensuite d'appeler la fonction nextModule() de cet objet pour trouver les modules suivants, et ce tant que la réponse n'est pas un NULL. Ci-dessous un petit exemple listant les module connectés

#import <Foundation/Foundation.h>
#import "yocto_api.h"

int main (int argc, const char * argv[])
{
    NSError *error;
   
    @autoreleasepool {
        // Setup the API to use local USB devices
        if(yRegisterHub(@"usb", &error) != YAPI_SUCCESS) {
            NSLog(@"RegisterHub error: %@\n", [error localizedDescription]);
            return 1;
        }

        NSLog(@"Device list:\n");

        YModule *module = yFirstModule();
        while (module != nil) {
            NSLog(@"%@ %@",module.serialNumber, module.productName);
            module = [module nextModule];
        }
    }
    return 0;
}
 

12.3. Gestion des erreurs

Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour interpréter les erreurs signalées par la librairie.

La manière la plus simple de contourner le problème est celle que nous avons employé pour les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est en ligne avec la méthode isOnline() et on suppose ensuite qu'il va y rester pendant la fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait, mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas totalement exclure une erreur se produisant après le isOnline(), qui pourrait faire planter le programme. La seule manière de l'éviter est d'implémenter une des deux techniques de gestion des erreurs décrites ci-dessous.

La méthode recommandée par la plupart des langages de programmation pour la gestion des erreurs imprévisibles est l'utilisation d'exceptions. C'est le comportement par défaut de la librairie Yoctopuce. Si une erreur se produit alors qu'on essaie d'accéder à un module, la librairie va lancer une exception. Dans ce cas, de trois choses l'une:

Comme cette dernière situation n'est pas la plus souhaitable, la librairie Yoctopuce offre une autre alternative pour la gestion des erreurs, permettant de faire un programme robuste sans devoir attraper les exceptions à chaque ligne de code. Il suffit d'appeler la fonction yDisableExceptions() pour commuter la librairie dans un mode où les exceptions de chaque fonction sont systématiquement remplacées par des valeurs de retour particulières, qui peuvent être testées par l'appelant lorsque c'est pertinent. Le nom de la valeur de retour en cas d'erreur pour chaque fonction est systématiquement documenté dans la référence de la librairie. Il suit toujours la même logique: une méthode get_state() retournera une valeur Y_STATE_INVALID, une méthode get_currentValue retournera une valeur Y_CURRENTVALUE_INVALID, etc. Dans tous les cas, la valeur retournée sera du type attendu, et ne sera pas un pointeur nul qui risquerait de faire crasher votre programme. Au pire, si vous affichez la valeur sans la tester, elle sera hors du cadre attendu pour la valeur retournée. Dans le cas de fonctions qui ne retournent à priori pas d'information, la valeur de retour sera YAPI_SUCCESS si tout va bien, et un code d'erreur différent en cas d'échec.

Quand vous travaillez sans les exceptions, il est possible d'obtenir un code d'erreur et un message expliquant l'origine de l'erreur en le demandant à l'objet qui a retourné une erreur à l'aide des méthodes errType() et errMessage(). Ce sont les même informations qui auraient été associées à l'exception si elles avaient été actives.

13. Utilisation du Yocto-MaxiDisplay en VisualBasic .NET

VisualBasic a longtemps été la porte d'entrée privilégiée vers le monde Microsoft. Nous nous devions donc d'offrir notre interface pour ce langage, même si la nouvelle tendance est le C#. Tous les exemples et les modèles de projet sont testés avec Microsoft Visual Basic 2010 Express, disponible gratuitement sur le site de Microsoft 32.

13.1. Installation

Téléchargez la librairie Yoctopuce pour Visual Basic depuis le site web de Yoctopuce33. Il n'y a pas de programme d'installation, copiez simplement de contenu du fichier zip dans le répertoire de votre choix. Vous avez besoin essentiellement du contenu du répertoire Sources. Les autres répertoires contiennent la documentation et quelques programmes d'exemple. Les projets d'exemple sont des projets Visual Basic 2010, si vous utilisez une version antérieure, il est possible que vous ayez à reconstruire la structure de ces projets.

13.2. Utilisation l'API yoctopuce dans un projet Visual Basic

La librairie Yoctopuce pour Visual Basic .NET se présente sous la forme d'une DLL et de fichiers sources en Visual Basic. La DLL n'est pas une DLL .NET mais une DLL classique, écrite en C, qui gère les communications à bas niveau avec les modules34. Les fichiers sources en Visual Basic gèrent la partie haut niveau de l'API. Vous avez donc besoin de cette DLL et des fichiers .vb du répertoire Sources pour créer un projet gérant des modules Yoctopuce.

Configuration d'un projet Visual Basic

Les indications ci-dessous sont fournies pour Visual Studio express 2010, mais la procédure est semblable pour les autres versions.

Commencez par créer votre projet, puis depuis le panneau Explorateur de solutions effectuez un clic droit sur votre projet, et choisissez Ajouter puis Elément existant.

Une fenêtre de sélection de fichiers apparaît: sélectionnez le fichier yocto_api.vb et les fichiers correspondant aux fonctions des modules Yoctopuce que votre projet va gérer. Dans le doute, vous pouvez aussi sélectionner tous les fichiers.

Vous avez alors le choix entre simplement ajouter ces fichiers à votre projet, ou les ajouter en tant que lien (le bouton Ajouter est en fait un menu déroulant). Dans le premier cas, Visual Studio va copier les fichiers choisis dans votre projet, dans le second Visual Studio va simplement garder un lien sur les fichiers originaux. Il est recommandé d'utiliser des liens, une éventuelle mise à jour de la librairie sera ainsi beaucoup plus facile.

Ensuite, ajoutez de la même manière la dll yapi.dll, qui se trouve dans le répertoire Sources/dll35. Puis depuis la fenêtre Explorateur de solutions, effectuez un clic droit sur la DLL, choisissez Propriété et dans le panneau Propriétés, mettez l'option Copier dans le répertoire de sortie à toujours copier. Vous êtes maintenant prêt à utiliser vos modules Yoctopuce depuis votre environnement Visual Studio.

Afin de les garder simples, tous les exemples fournis dans cette documentation sont des applications consoles. Il va de soit que que les fonctionnement des librairies est strictement identiques si vous les intégrez dans une application dotée d'une interface graphique.

13.3. Contrôle de la fonction Display

Il suffit de quelques lignes de code pour piloter un Yocto-MaxiDisplay. Voici le squelette d'un fragment de code VisualBasic .NET qui utilise la fonction Display.


[...]
Dim errmsg As String
Dim display As YDisplay

REM On récupère l'objet représentant le module (ici connecté en local sur USB)
yRegisterHub("usb", errmsg)
display = yFindDisplay("YD128X64-123456.display")

REM Pour gérer le hot-plug, on vérifie que le module est là
If (display.isOnline()) Then
   REM Utiliser display.get_displayLayer(), ...
End If

Voyons maintenant en détail ce que font ces quelques lignes.

yRegisterHub

La fonction yRegisterHub initialise l'API de Yoctopuce en indiquant où les modules doivent être recherchés. Utilisée avec le paramètre "usb", elle permet de travailler avec les modules connectés localement à la machine. Si l'initialisation se passe mal, cette fonction renverra une valeur différente de YAPI_SUCCESS, et retournera via le paramètre errmsg un explication du problème.

yFindDisplay

La fonction yFindDisplay, permet de retrouver un ecran en fonction du numéro de série de son module hôte et de son nom de fonction. Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté):


display = yFindDisplay("YD128X64-123456.display")
display = yFindDisplay("YD128X64-123456.MaFonction")
display = yFindDisplay("MonModule.display")
display = yFindDisplay("MonModule.MaFonction")
display = yFindDisplay("MaFonction")

yFindDisplay renvoie un objet que vous pouvez ensuite utiliser à loisir pour contrôler l'ecran.

isOnline

La méthode isOnline() de l'objet renvoyé par yFindDisplay permet de savoir si le module correspondant est présent et en état de marche.

get_displayLayer

La méthode get_displayLayer() de l'objet renvoyé par YFindDisplay permet récupérer un objet correspondant à une des couches de l'écran. Cet objet implémente toutes les routines graphiques.

Un exemple réel

Lancez Microsoft VisualBasic et ouvrez le projet exemple correspondant, fourni dans le répertoire Examples/Doc-GettingStarted-Yocto-MaxiDisplay de la librairie Yoctopuce.

Vous reconnaîtrez dans cet exemple l'utilisation des fonctions expliquées ci-dessus, cette fois utilisées avec le décorum nécessaire à en faire un petit programme d'exemple concret.

Module Module1

  Private Sub Usage()
    Dim execname = System.AppDomain.CurrentDomain.FriendlyName
    Console.WriteLine("Usage:")
    Console.WriteLine(execname + " <serial_number>")
    Console.WriteLine(execname + " <logical_name> ")
    Console.WriteLine(execname + "  any")
    System.Threading.Thread.Sleep(2500)
    End
  End Sub

    Sub Main()
        Dim argv() As String = System.Environment.GetCommandLineArgs()
        Dim errmsg As String = ""
        Dim target As String
    Dim disp As YDisplay
    Dim l0, l1 As YDisplayLayer
    Dim h, w, y, x, vx, vy As Integer


    If argv.Length <= 1 Then Usage()

    target = argv(1)
   



    REM Setup the API to use local USB devices
        If (yRegisterHub("usb", errmsg) <> YAPI_SUCCESS) Then
            Console.WriteLine("RegisterHub error: " + errmsg)
            End
        End If

        If target = "any" Then
      disp = yFirstDisplay()
      If disp Is Nothing Then
        Console.WriteLine("No module connected (check USB cable) ")
        End
      End If

        Else
      disp = yFindDisplay(target + ".display")

    End If

    If Not (disp.isOnline()) Then
      Console.WriteLine("Module not connected (check identification and USB cable)")
      End
    End If

    REM Display clean up
    disp.resetAll()
    REM retreive the display size
    w = disp.get_displayWidth()
    h = disp.get_displayHeight()

    REM reteive the first layer
    l0 = disp.get_displayLayer(0)

    REM display a text in the middle of the screen
    l0.drawText(CInt(w / 2), CInt(h / 2), Y_ALIGN.CENTER, "Hello world!")
   
    REM visualize each corner
    l0.moveTo(0, 5)
    l0.lineTo(0, 0)
    l0.lineTo(5, 0)
    l0.moveTo(0, h - 6)
    l0.lineTo(0, h - 1)
    l0.lineTo(5, h - 1)
    l0.moveTo(w - 1, h - 6)
    l0.lineTo(w - 1, h - 1)
    l0.lineTo(w - 6, h - 1)
    l0.moveTo(w - 1, 5)
    l0.lineTo(w - 1, 0)
    l0.lineTo(w - 6, 0)

    REM draw a circle in the top left corner of layer 1
    l1 = disp.get_displayLayer(1)
    l1.clear()
    l1.drawCircle(CInt(h / 8), CInt(h / 8), CInt(h / 8))

    REM and animate the layer
    Console.WriteLine("Use Ctrl-C to stop")
    x = 0
    y = 0
    vx = 1
    vy = 1

    While (True)
      x += vx
      y += vy
      If ((x < 0) Or (x > w - (h / 4))) Then vx = -vx
      If ((y < 0) Or (y > h - (h / 4))) Then vy = -vy
      l1.setLayerPosition(x, y, 0)
      YAPI.Sleep(5, errmsg)
    End While

  End Sub

End Module
 

13.4. Contrôle de la partie module

Chaque module peut-être contrôlé d'une manière similaire, vous trouverez ci dessous un simple programme d'exemple affichant les principaux paramètres d'un module et permettant d'activer la balise de localisation.


Imports System.IO
Imports System.Environment

Module Module1

  Sub usage()
    Console.WriteLine("usage: demo <serial or logical name> [ON/OFF]")  
    End
  End Sub

  Sub Main()
    Dim argv() As String = System.Environment.GetCommandLineArgs()
    Dim errmsg As String = ""
    Dim m As ymodule

    If (yRegisterHub("usb", errmsg) <> YAPI_SUCCESS) Then
      Console.WriteLine("RegisterHub error:" + errmsg)
      End
    End If

    If argv.Length < 2 Then usage()

    m = yFindModule(argv(1)) REM use serial or logical name

    If (m.isOnline()) Then
      If argv.Length > 2 Then
        If argv(2) = "ON" Then m.set_beacon(Y_BEACON_ON)
        If argv(2) = "OFF" Then m.set_beacon(Y_BEACON_OFF)
      End If
      Console.WriteLine("serial:       " + m.get_serialNumber())
      Console.WriteLine("logical name: " + m.get_logicalName())
      Console.WriteLine("luminosity:   " + Str(m.get_luminosity()))
      Console.Write("beacon:       ")
      If (m.get_beacon() = Y_BEACON_ON) Then
        Console.WriteLine("ON")
      Else
        Console.WriteLine("OFF")
      End If
      Console.WriteLine("upTime:       " + Str(m.get_upTime() / 1000) + " sec")
      Console.WriteLine("USB current:  " + Str(m.get_usbCurrent()) + " mA")
      Console.WriteLine("Logs:")
      Console.WriteLine(m.get_lastLogs())
    Else
      Console.WriteLine(argv(1) + " not connected (check identification and USB cable)")
    End If



  End Sub

End Module
 

Chaque propriété xxx du module peut être lue grâce à une méthode du type get_xxxx(), et les propriétés qui se sont pas en lecture seule peuvent être modifiées à l'aide de la méthode set_xxx() Pour plus de détails concernant ces fonctions utilisées, reportez-vous aux chapitre API

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'appeler la fonction set_xxx() correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la méthode saveToFlash(). Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode revertFromFlash(). Ce petit exemple ci-dessous vous permet changer le nom logique d'un module.

Module Module1


  Sub usage()

    Console.WriteLine("usage: demo <serial or logical name> <new logical name>")
    End
  End Sub

  Sub Main()
    Dim argv() As String = System.Environment.GetCommandLineArgs()
    Dim errmsg As String = ""
    Dim newname As String
    Dim m As YModule

    If (argv.Length <> 3) Then usage()

    REM Setup the API to use local USB devices
    If yRegisterHub("usb", errmsg) <> YAPI_SUCCESS Then
      Console.WriteLine("RegisterHub error: " + errmsg)
      End
    End If

    m = yFindModule(argv(1)) REM use serial or logical name
    If m.isOnline() Then

      newname = argv(2)
      If (Not yCheckLogicalName(newname)) Then
        Console.WriteLine("Invalid name (" + newname + ")")
        End
      End If
      m.set_logicalName(newname)
      m.saveToFlash() REM do not forget this

      Console.Write("Module: serial= " + m.get_serialNumber)
      Console.Write(" / name= " + m.get_logicalName())
    Else
      Console.Write("not connected (check identification and USB cable")
    End If

  End Sub

End Module
 

Attention, le nombre de cycles d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit que la sauvegarde des réglages se passera correctement. Cette limite, liée à la technologie employée par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la fonction saveToFlash() que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette fonction depuis l'intérieur d'une boucle.

Enumeration des modules

Obtenir la liste des modules connectés se fait à l'aide de la fonction yFirstModule() qui renvoie le premier module trouvé, il suffit ensuite d'appeler la fonction nextModule() de cet objet pour trouver les modules suivants, et ce tant que la réponse n'est pas un Nothing. Ci-dessous un petit exemple listant les module connectés

Module Module1

  Sub Main()
    Dim M As ymodule
    Dim errmsg As String = ""

    REM Setup the API to use local USB devices
    If yRegisterHub("usb", errmsg) <> YAPI_SUCCESS Then
      Console.WriteLine("RegisterHub error: " + errmsg)
      End
    End If

    Console.WriteLine("Device list")
    M = yFirstModule()
    While M IsNot Nothing
      Console.WriteLine(M.get_serialNumber() + " (" + M.get_productName() + ")")
      M = M.nextModule()
    End While

  End Sub

    End Module
 

13.5. Gestion des erreurs

Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour interpréter les erreurs signalées par la librairie.

La manière la plus simple de contourner le problème est celle que nous avons employé pour les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est en ligne avec la méthode isOnline() et on suppose ensuite qu'il va y rester pendant la fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait, mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas totalement exclure une erreur se produisant après le isOnline(), qui pourrait faire planter le programme. La seule manière de l'éviter est d'implémenter une des deux techniques de gestion des erreurs décrites ci-dessous.

La méthode recommandée par la plupart des langages de programmation pour la gestion des erreurs imprévisibles est l'utilisation d'exceptions. C'est le comportement par défaut de la librairie Yoctopuce. Si une erreur se produit alors qu'on essaie d'accéder à un module, la librairie va lancer une exception. Dans ce cas, de trois choses l'une:

Comme cette dernière situation n'est pas la plus souhaitable, la librairie Yoctopuce offre une autre alternative pour la gestion des erreurs, permettant de faire un programme robuste sans devoir attraper les exceptions à chaque ligne de code. Il suffit d'appeler la fonction yDisableExceptions() pour commuter la librairie dans un mode où les exceptions de chaque fonction sont systématiquement remplacées par des valeurs de retour particulières, qui peuvent être testées par l'appelant lorsque c'est pertinent. Le nom de la valeur de retour en cas d'erreur pour chaque fonction est systématiquement documenté dans la référence de la librairie. Il suit toujours la même logique: une méthode get_state() retournera une valeur Y_STATE_INVALID, une méthode get_currentValue retournera une valeur Y_CURRENTVALUE_INVALID, etc. Dans tous les cas, la valeur retournée sera du type attendu, et ne sera pas un pointeur nul qui risquerait de faire crasher votre programme. Au pire, si vous affichez la valeur sans la tester, elle sera hors du cadre attendu pour la valeur retournée. Dans le cas de fonctions qui ne retournent à priori pas d'information, la valeur de retour sera YAPI_SUCCESS si tout va bien, et un code d'erreur différent en cas d'échec.

Quand vous travaillez sans les exceptions, il est possible d'obtenir un code d'erreur et un message expliquant l'origine de l'erreur en le demandant à l'objet qui a retourné une erreur à l'aide des méthodes errType() et errMessage(). Ce sont les même informations qui auraient été associées à l'exception si elles avaient été actives.

14. Utilisation du Yocto-MaxiDisplay en C#

C# (prononcez C-Sharp) est un langage orienté objet promu par Microsoft qui n'est pas sans rappeller Java. Tout comme Visual Basic et Delphi, il permet de créer des applications Windows relativement facilement. Tous les exemples et les modèles de projet sont testés avec Microsoft C# 2010 Express, disponible gratuitement sur le site de Microsoft 36.

14.1. Installation

Téléchargez la librairie Yoctopuce pour Visual C# depuis le site web de Yoctopuce37. Il n'y a pas de programme d'installation, copiez simplement de contenu du fichier zip dans le répertoire de votre choix. Vous avez besoin essentiellement du contenu du répertoire Sources. Les autres répertoires contiennent la documentation et quelques programmes d'exemple. Les projets d'exemple sont des projets Visual C# 2010, si vous utilisez une version antérieure, il est possible que vous ayez à reconstruire la structure de ces projets.

14.2. Utilisation l'API yoctopuce dans un projet Visual C#

La librairie Yoctopuce pour Visual C# .NET se présente sous la forme d'une DLL et de fichiers sources en Visual C#. La DLL n'est pas une DLL .NET mais une DLL classique, écrite en C, qui gère les communications à bas niveau avec les modules38. Les fichiers sources en Visual C# gèrent la partie haut niveau de l'API. Vous avez donc besoin de cette DLL et des fichiers .cs du répertoire Sources pour créer un projet gérant des modules Yoctopuce.

Configuration d'un projet Visual C#

Les indications ci-dessous sont fournies pour Visual Studio express 2010, mais la procédure est semblable pour les autres versions.

Commencez par créer votre projet, puis depuis le panneau Explorateur de solutions effectuez un clic droit sur votre projet, et choisissez Ajouter puis Elément existant.

Une fenêtre de sélection de fichiers apparaît: sélectionnez le fichier yocto_api.cs et les fichiers correspondant aux fonctions des modules Yoctopuce que votre projet va gérer. Dans le doute, vous pouvez aussi sélectionner tous les fichiers.

Vous avez alors le choix entre simplement ajouter ces fichiers à votre projet, ou les ajouter en tant que lien (le bouton Ajouter est en fait un menu déroulant). Dans le premier cas, Visual Studio va copier les fichiers choisis dans votre projet, dans le second Visual Studio va simplement garder un lien sur les fichiers originaux. Il est recommandé d'utiliser des liens, une éventuelle mise à jour de la librairie sera ainsi beaucoup plus facile.

Ensuite, ajoutez de la même manière la dll yapi.dll, qui se trouve dans le répertoire Sources/dll39. Puis depuis la fenêtre Explorateur de solutions, effectuez un clic droit sur la DLL, choisissez Propriété et dans le panneau Propriétés, mettez l'option Copier dans le répertoire de sortie à toujours copier. Vous êtes maintenant prêt à utiliser vos modules Yoctopuce depuis votre environnement Visual Studio.

Afin de les garder simples, tous les exemples fournis dans cette documentation sont des applications consoles. Il va de soit que que les fonctionnement des librairies est strictement identiques si vous les intégrez dans une application dotée d'une interface graphique.

14.3. Contrôle de la fonction Display

Il suffit de quelques lignes de code pour piloter un Yocto-MaxiDisplay. Voici le squelette d'un fragment de code C# qui utilise la fonction Display.


[...]
string errmsg = "";
YDisplay display;

// On récupère l'objet représentant le module (ici connecté en local sur USB)
YAPI.RegisterHub("usb", errmsg);
display = YDisplay.FindDisplay("YD128X64-123456.display");

// Pour gérer le hot-plug, on vérifie que le module est là
if (display.isOnline())
 { // Utiliser display.get_displayLayer(): ...
 }

Voyons maintenant en détail ce que font ces quelques lignes.

YAPI.RegisterHub

La fonction YAPI.RegisterHub initialise l'API de Yoctopuce en indiquant où les modules doivent être recherchés. Utilisée avec le paramètre "usb", elle permet de travailler avec les modules connectés localement à la machine. Si l'initialisation se passe mal, cette fonction renverra une valeur différente de YAPI.SUCCESS, et retournera via le paramètre errmsg une explication du problème.

YDisplay.FindDisplay

La fonction YDisplay.FindDisplay, permet de retrouver un ecran en fonction du numéro de série de son module hôte et de son nom de fonction. Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté):


display = YDisplay.FindDisplay("YD128X64-123456.display");
display = YDisplay.FindDisplay("YD128X64-123456.MaFonction");
display = YDisplay.FindDisplay("MonModule.display");
display = YDisplay.FindDisplay("MonModule.MaFonction");
display = YDisplay.FindDisplay("MaFonction");

YDisplay.FindDisplay renvoie un objet que vous pouvez ensuite utiliser à loisir pour contrôler l'ecran.

isOnline

La méthode YDisplay.isOnline() de l'objet renvoyé par FindDisplay permet de savoir si le module correspondant est présent et en état de marche.

get_displayLayer

La méthode get_displayLayer() de l'objet renvoyé par YDisplay.FindDisplay permet récupérer un objet correspondant à une des couches de l'écran. Cet objet fourni toutes les routines graphiques.

Un exemple réel

Lancez Visual C# et ouvrez le projet exemple correspondant, fourni dans le répertoire Examples/Doc-GettingStarted-Yocto-MaxiDisplay de la librairie Yoctopuce.

Vous reconnaîtrez dans cet exemple l'utilisation des fonctions expliquées ci-dessus, cette fois utilisées avec le décorum nécessaire à en faire un petit programme d'exemple concret.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
  class Program
  {
    static void usage()
    {
      string execname = System.AppDomain.CurrentDomain.FriendlyName;
      Console.WriteLine(execname + " <serial_number> ");
      Console.WriteLine(execname + " <logical_name>");
      Console.WriteLine(execname + "  any ");
      System.Threading.Thread.Sleep(2500);
      Environment.Exit(0);
    }

    static void Main(string[] args)
    {
      string errmsg = "";
      string target;
      YDisplay disp;
      YDisplayLayer l0, l1;
      int h, w, y, x, vx, vy;
      if (args.Length < 1) usage();

      target = args[0].ToUpper();

      // API init
      if (YAPI.RegisterHub("usb", ref errmsg) != YAPI.SUCCESS)
      {
        Console.WriteLine("RegisterHub error: " + errmsg);
        Environment.Exit(0);
      }

      // find the display according to command line parameters
      if (target == "ANY")
      {
        disp = YDisplay.FirstDisplay();
        if (disp == null)
        {
          Console.WriteLine("No module connected (check USB cable) ");
          Environment.Exit(0);
        }
      }
      else disp = YDisplay.FindDisplay(target + ".display");


      if (!disp.isOnline())
      {
        Console.WriteLine("Module not connected (check identification and USB cable) ");
        Environment.Exit(0);
      }

      //clean up
      disp.resetAll();
     
      // retreive the display size
      w = disp.get_displayWidth();
      h = disp.get_displayHeight();

      // reteive the first layer
      l0 = disp.get_displayLayer(0);
   
      // display a text in the middle of the screen
      l0.drawText(w / 2, h / 2, YDisplayLayer.ALIGN.CENTER, "Hello world!");

      // visualize each corner
      l0.moveTo(0, 5); l0.lineTo(0, 0); l0.lineTo(5, 0);
      l0.moveTo(0, h - 6); l0.lineTo(0, h - 1); l0.lineTo(5, h - 1);
      l0.moveTo(w - 1, h - 6); l0.lineTo(w - 1, h - 1); l0.lineTo(w - 6, h - 1);
      l0.moveTo(w - 1, 5); l0.lineTo(w - 1, 0); l0.lineTo(w - 6, 0);

      // draw a circle in the top left corner of layer 1
      l1 = disp.get_displayLayer(1);
      l1.clear();
      l1.drawCircle(h / 8, h / 8, h / 8);

      // and animate the layer
      Console.WriteLine("Use Ctrl-C to stop");
      x = 0; y = 0; vx = 1; vy = 1;
      while (true)
      {
        x += vx; y += vy;
        if ((x < 0) || (x > w - (h / 4))) vx = -vx;
        if ((y < 0) || (y > h - (h / 4))) vy = -vy;
        l1.setLayerPosition(x, y, 0);
        YAPI.Sleep(5, ref errmsg);
      }
    }
  }
}
 

14.4. Contrôle de la partie module

Chaque module peut-être contrôlé d'une manière similaire, vous trouverez ci-dessous un simple programme d'exemple affichant les principaux paramètres d'un module et permettant d'activer la balise de localisation.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;


namespace ConsoleApplication1
{
  class Program
  {
    static void usage()
    { string execname = System.AppDomain.CurrentDomain.FriendlyName;
      Console.WriteLine("Usage:");
      Console.WriteLine(execname+" <serial or logical name> [ON/OFF]");
      System.Threading.Thread.Sleep(2500);
      Environment.Exit(0);
    }

    static void Main(string[] args)
    {
      YModule m;
      string errmsg = "";

      if (YAPI.RegisterHub("usb", ref errmsg) !=  YAPI.SUCCESS)
      {
        Console.WriteLine("RegisterHub error: " + errmsg);
        Environment.Exit(0);
      }

     
      if (args.Length < 1)  usage();

      m = YModule.FindModule(args[0]); // use serial or logical name

      if (m.isOnline())
      {
        if (args.Length >= 2)
        {
          if (args[1].ToUpper() == "ON") { m.set_beacon(YModule.BEACON_ON); }
          if (args[1].ToUpper() == "OFF") { m.set_beacon(YModule.BEACON_OFF); }
        }
     
        Console.WriteLine("serial:       " + m.get_serialNumber());
        Console.WriteLine("logical name: " + m.get_logicalName());
        Console.WriteLine("luminosity:   " + m.get_luminosity().ToString());
        Console.Write("beacon:       ");
        if (m.get_beacon() == YModule.BEACON_ON)
          Console.WriteLine("ON");
        else
          Console.WriteLine("OFF");
        Console.WriteLine("upTime:       " + (m.get_upTime() / 1000 ).ToString()+ " sec");
        Console.WriteLine("USB current:  " + m.get_usbCurrent().ToString() + " mA");
        Console.WriteLine("Logs:\r\n"+ m.get_lastLogs());

      }
    else
      Console.WriteLine(args[0] + " not connected (check identification and USB cable)");
   
   }
  }
}
 

Chaque propriété xxx du module peut être lue grâce à une méthode du type YModule.get_xxxx(), et les propriétés qui se sont pas en lecture seule peuvent être modifiées à l'aide de la méthode YModule.set_xxx() Pour plus de détails concernant ces fonctions utilisées, reportez-vous aux chapitre API

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'appeler la fonction YModule.set_xxx() correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la méthode YModule.saveToFlash(). Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode YModule.revertFromFlash(). Ce petit exemple ci-dessous vous permet changer le nom logique d'un module.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
  class Program
  {
    static void usage()
    { string execname = System.AppDomain.CurrentDomain.FriendlyName;
      Console.WriteLine("Usage:");
      Console.WriteLine("usage: demo <serial or logical name> <new logical name>");
      System.Threading.Thread.Sleep(2500);
      Environment.Exit(0);
    }

    static void Main(string[] args)
    {
      YModule m;
      string errmsg = "";
      string newname;

      if (args.Length != 2) usage();

      if (YAPI.RegisterHub("usb", ref errmsg) !=  YAPI.SUCCESS)
      {
        Console.WriteLine("RegisterHub error: " + errmsg);
        Environment.Exit(0);
      }

      m = YModule.FindModule(args[0]); // use serial or logical name

      if (m.isOnline())
      {
        newname = args[1];
        if (!YAPI.CheckLogicalName(newname))
        {
          Console.WriteLine("Invalid name (" + newname + ")");
          Environment.Exit(0);
        }

        m.set_logicalName(newname);
        m.saveToFlash(); // do not forget this

        Console.Write("Module: serial= " + m.get_serialNumber());
        Console.WriteLine(" / name= " + m.get_logicalName());
      }
      else
        Console.Write("not connected (check identification and USB cable");
    }
  }
}
 

Attention, le nombre de cycles d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit que la sauvegarde des réglages se passera correctement. Cette limite, liée à la technologie employée par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la fonction YModule.saveToFlash() que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette fonction depuis l'intérieur d'une boucle.

Enumeration des modules

Obtenir la liste des modules connectés se fait à l'aide de la fonction YModule.yFirstModule() qui renvoie le premier module trouvé, il suffit ensuite d'appeler la méthode nextModule() de cet objet pour trouver les modules suivants, et ce tant que la réponse n'est pas un null. Ci-dessous un petit exemple listant les module connectés

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
  class Program
  {
    static void Main(string[] args)
    {
      YModule m;
      string errmsg = "";

      if (YAPI.RegisterHub("usb", ref errmsg) !=  YAPI.SUCCESS)
      {
        Console.WriteLine("RegisterHub error: " + errmsg);
        Environment.Exit(0);
      }

      Console.WriteLine("Device list");
      m = YModule.FirstModule();
      while (m!=null)
      { Console.WriteLine(m.get_serialNumber() + " (" + m.get_productName() + ")");
       m = m.nextModule();
      }

    }
  }
}
 

14.5. Gestion des erreurs

Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour interpréter les erreurs signalées par la librairie.

La manière la plus simple de contourner le problème est celle que nous avons employé pour les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est en ligne avec la méthode isOnline() et on suppose ensuite qu'il va y rester pendant la fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait, mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas totalement exclure une erreur se produisant après le isOnline(), qui pourrait faire planter le programme. La seule manière de l'éviter est d'implémenter une des deux techniques de gestion des erreurs décrites ci-dessous.

La méthode recommandée par la plupart des langages de programmation pour la gestion des erreurs imprévisibles est l'utilisation d'exceptions. C'est le comportement par défaut de la librairie Yoctopuce. Si une erreur se produit alors qu'on essaie d'accéder à un module, la librairie va lancer une exception. Dans ce cas, de trois choses l'une:

Comme cette dernière situation n'est pas la plus souhaitable, la librairie Yoctopuce offre une autre alternative pour la gestion des erreurs, permettant de faire un programme robuste sans devoir attraper les exceptions à chaque ligne de code. Il suffit d'appeler la fonction yDisableExceptions() pour commuter la librairie dans un mode où les exceptions de chaque fonction sont systématiquement remplacées par des valeurs de retour particulières, qui peuvent être testées par l'appelant lorsque c'est pertinent. Le nom de la valeur de retour en cas d'erreur pour chaque fonction est systématiquement documenté dans la référence de la librairie. Il suit toujours la même logique: une méthode get_state() retournera une valeur Y_STATE_INVALID, une méthode get_currentValue retournera une valeur Y_CURRENTVALUE_INVALID, etc. Dans tous les cas, la valeur retournée sera du type attendu, et ne sera pas un pointeur nul qui risquerait de faire crasher votre programme. Au pire, si vous affichez la valeur sans la tester, elle sera hors du cadre attendu pour la valeur retournée. Dans le cas de fonctions qui ne retournent à priori pas d'information, la valeur de retour sera YAPI_SUCCESS si tout va bien, et un code d'erreur différent en cas d'échec.

Quand vous travaillez sans les exceptions, il est possible d'obtenir un code d'erreur et un message expliquant l'origine de l'erreur en le demandant à l'objet qui a retourné une erreur à l'aide des méthodes errType() et errMessage(). Ce sont les même informations qui auraient été associées à l'exception si elles avaient été actives.

15. Utilisation du Yocto-MaxiDisplay en Delphi

Delphi est l'héritier de Turbo-Pascal. A l'origine, Delphi était produit par Borland, mais c'est maintenant Embarcadero qui l'édite. Sa force réside dans sa facilité d'utilisation, il permet à quiconque ayant des notions de Pascal de programmer une application Windows en deux temps trois mouvements. Son seul défaut est d'être payant40.

Les librairies pour Delphi sont fournies non pas sous forme de composants VCL, mais directement sous forme de fichiers source. Ces fichiers sont compatibles avec la plupart des version de Delphi 41.

Afin des les garder simples, tous les exemples fournis dans cette documentation sont des applications consoles. Il va de soit que le fonctionnement des librairies est strictement identique avec des applications VCL.

Vous allez rapidement vous rendre compte que l'API Delphi défini beaucoup de fonctions qui retournent des objets. Vous ne devez jamais désallouer ces objets vous-même. Ils seront désalloués automatiquement par l'API à la fin de l'application.

15.1. Préparation

Connectez-vous sur le site de Yoctopuce et téléchargez la la librairie Yoctopuce pour Delphi42. Décompressez le tout dans le répertoire de votre choix, et ajoutez le sous-répertoire sources de l'archive dans la liste des répertoires des librairies de Delphi43.

Par défaut la librairie Yoctopuce pour Delphi utilise une DLL yapi.dll, toutes les applications que vous créerez avec Delphi devront avoir accès à cette DLL. Le plus simple est de faire en sorte qu'elle soit présente dans le même répertoire que l'exécutable de votre application.

15.2. Contrôle de la fonction Display

Lancez votre environnement Delphi, copiez la DLL yapi.dll dans un répertoire et créez une nouvelle application console dans ce même répertoire, et copiez-coller le code ci dessous.

program helloworld;
{$APPTYPE CONSOLE}
uses
  SysUtils,
  yocto_api,
  yocto_display;


Procedure  Usage();
  var
   exe : string;

  begin
    exe:= ExtractFileName(paramstr(0));
    WriteLn(exe+' <serial_number>');
    WriteLn(exe+' <logical_name>');
    WriteLn(exe+' any');
    halt;
  End;

var
  disp      : TYDisplay;
  l0,l1     : TYDisplayLayer;
  errmsg    : string;
  w,h       : integer;
  x,y,vx,vy :integer;


begin


  if (paramcount<1) then usage();

  // Setup the API to use local USB devices
  if yRegisterHub('usb', errmsg)<>YAPI_SUCCESS then
  begin
    Write('RegisterHub error: '+errmsg);
    exit;
  end;

  // first one of the two RBG leds
  if paramstr(1)='any' then
    begin
      disp := yFirstDisplay();
      if disp=nil then
         begin
           writeln('No module connected (check USB cable)');
           halt;
         end
      end
   else
  disp:= YFindDisplay(paramstr(1)+'.display');

  // make sure it is online
  if not(disp.isOnline()) then
      begin
        writeln('No module connected (check USB cable)');
        halt;
      end;

  // display clean up
  disp.resetAll();

  // retreive the display size
  w:=disp.get_displayWidth();
  h:=disp.get_displayHeight();

  // reteive the first layer
  L0:=Disp.get_displaylayer(0);

  // display a text in the middle of the screen
  L0.drawText(w div 2, h div 2, Y_ALIGN_CENTER, 'Hello world!' );
  // visualize eah corner
  L0.moveto(0,5);L0.lineto(0,0);L0.lineto(5,0);
  L0.moveto(0,h-6);L0.lineto(0,H-1);L0.lineto(5,H-1);
  L0.moveto(w-1,h-6);L0.lineto(w-1,H-1);L0.lineto(w-6,H-1);
  L0.moveto(w-1,5);L0.lineto(w-1,0);L0.lineto(w-6,0);

  // draw a circle in the top left corner of layer 1
  L1:=Disp.get_displaylayer(1);
  L1.clear();
  L1.drawCircle(H div 8, H div 8, h div 8);

  // and animate the layer
  Writeln('Use Ctrl-C to stop');
  x:=0; y:=0; vx:=1; vy:=1;
  while (true) do
   begin
    x:=x+vx;y:=y+vy;
    if (x<0) or (x>w-(h div 4)) then vx:=-vx;
    if (y<0) or (y>h-(h div 4)) then vy:=-vy;
    l1.setLayerPosition(x,y,0);
    ysleep(5,errmsg);
   end;

end.
 

Il n'y a que peu de lignes véritablement importantes dans le code précédent. Nous allons les expliquer en détail.

yocto_api et yocto_display

Ces deux unités permettent d'avoir accès aux fonctions permettant de gérer les modules Yoctopuce. yocto_api doit toujours être utilisé, yocto_display est nécessaire pour gérer les modules contenant un ecran, comme le Yocto-MaxiDisplay.

yRegisterHub

La fonction yRegisterHub initialise l'API de Yoctopuce en indiquant où les modules doivent être recherchés. Utilisée avec le paramètre 'usb', elle permet de travailler avec les modules connectés localement à la machine. Si l'initialisation se passe mal, cette fonction renverra une valeur différente de YAPI_SUCCESS, et retournera via le paramètre errmsg un explication du problème.

yFindDisplay

La fonction yFindDisplay, permet de retrouver un ecran en fonction du numéro de série de son module hôte et de son nom de fonction. Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté):


display := yFindDisplay("YD128X64-123456.display");
display := yFindDisplay("YD128X64-123456.MaFonction");
display := yFindDisplay("MonModule.display");
display := yFindDisplay("MonModule.MaFonction");
display := yFindDisplay("MaFonction");

yFindDisplay renvoie un objet que vous pouvez ensuite utiliser à loisir pour contrôler l'ecran.

isOnline

La méthode isOnline() de l'objet renvoyé par yFindDisplay permet de savoir si le module correspondant est présent et en état de marche.

get_displayLayer

La méthode get_displayLayer() de l'objet renvoyé par YFindDisplay permet récupérer un objet correspondant à une des couches de l'écran. Cet objet implémente toutes les routines graphiques.

15.3. Contrôle de la partie module

Chaque module peut-être contrôlé d'une manière similaire, vous trouverez ci dessous un simple programme d'exemple affichant les principaux paramètres d'un module et permettant d'activer la balise de localisation.

program modulecontrol;
{$APPTYPE CONSOLE}
uses
  SysUtils,
  yocto_api;

const
  serial = 'YD128X64-123456'; // use serial number or logical name

procedure refresh(module:Tymodule) ;
  begin
    if (module.isOnline())  then
     begin
       Writeln('');
       Writeln('Serial       : ' + module.get_serialNumber());
       Writeln('Logical name : ' + module.get_logicalName());
       Writeln('Luminosity   : ' + intToStr(module.get_luminosity()));
       Write('Beacon    :');
       if  (module.get_beacon()=Y_BEACON_ON) then Writeln('on')
                                             else Writeln('off');
       Writeln('uptime       : ' + intToStr(module.get_upTime() div 1000)+'s');
       Writeln('USB current  : ' + intToStr(module.get_usbCurrent())+'mA');
       Writeln('Logs         : ');
       Writeln(module.get_lastlogs());
       Writeln('');
       Writeln('r : refresh / b:beacon ON / space : beacon off');
     end
    else Writeln('Module not connected (check identification and USB cable)');
  end;


procedure beacon(module:Tymodule;state:integer);
  begin
    module.set_beacon(state);
    refresh(module);
  end;

var
  module : TYModule;
  c      : char;
  errmsg : string;

begin
  // Setup the API to use local USB devices
  if yRegisterHub('usb', errmsg)<>YAPI_SUCCESS then
  begin
    Write('RegisterHub error: '+errmsg);
    exit;
  end;

  module := yFindModule(serial);
  refresh(module);

  repeat
    read(c);
    case c of
     'r': refresh(module);
     'b': beacon(module,Y_BEACON_ON);
     ' ': beacon(module,Y_BEACON_OFF);
    end;
  until  c = 'x';
end.

Chaque propriété xxx du module peut être lue grâce à une méthode du type get_xxxx(), et les propriétés qui se sont pas en lecture seule peuvent être modifiées à l'aide de la méthode set_xxx() Pour plus de détails concernant ces fonctions utilisées, reportez-vous aux chapitre API

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'appeler la fonction set_xxx() correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la méthode saveToFlash(). Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode revertFromFlash(). Ce petit exemple ci-dessous vous permet changer le nom logique d'un module.

program savesettings;
{$APPTYPE CONSOLE}
uses
  SysUtils,
  yocto_api;

const
  serial = 'YD128X64-123456'; // use serial number or logical name

var
  module  : TYModule;
  errmsg  : string;
  newname : string;
 
begin
  // Setup the API to use local USB devices
  if yRegisterHub('usb', errmsg)<>YAPI_SUCCESS then
  begin
    Write('RegisterHub error: '+errmsg);
    exit;
  end;

  module := yFindModule(serial);
  if (not(module.isOnline)) then
   begin
     writeln('Module not connected (check identification and USB cable)');
     exit;
   end;

  Writeln('Current logical name : '+module.get_logicalName());
  Write('Enter new name : ');
  Readln(newname);
  if (not(yCheckLogicalName(newname))) then
   begin
     Writeln('invalid logical name');
     exit;
   end;
  module.set_logicalName(newname);
  module.saveToFlash();
 
  Writeln('logical name is now : '+module.get_logicalName());
end.
 

Attention, le nombre de cycles d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit que la sauvegarde des réglages se passera correctement. Cette limite, liée à la technologie employée par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la fonction saveToFlash() que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette fonction depuis l'intérieur d'une boucle.

Énumération des modules

Obtenir la liste des modules connectés se fait à l'aide de la fonction yFirstModule() qui renvoie le premier module trouvé, il suffit ensuite d'appeler la fonction nextModule() de cet objet pour trouver les modules suivants, et ce tant que la réponse n'est pas un nil. Ci-dessous un petit exemple listant les module connectés

program inventory;
{$APPTYPE CONSOLE}
uses
  SysUtils,
  yocto_api;

var
  module : TYModule;
  errmsg : string;

begin
  // Setup the API to use local USB devices
  if yRegisterHub('usb', errmsg)<>YAPI_SUCCESS then
  begin
    Write('RegisterHub error: '+errmsg);
    exit;
  end;

  Writeln('Device list');

  module := yFirstModule();
  while module<>nil  do
   begin
     Writeln( module.get_serialNumber()+' ('+module.get_productName()+')');
     module := module.nextModule();
   end;

end.

15.4. Gestion des erreurs

Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour interpréter les erreurs signalées par la librairie.

La manière la plus simple de contourner le problème est celle que nous avons employé pour les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est en ligne avec la méthode isOnline() et on suppose ensuite qu'il va y rester pendant la fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait, mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas totalement exclure une erreur se produisant après le isOnline(), qui pourrait faire planter le programme. La seule manière de l'éviter est d'implémenter une des deux techniques de gestion des erreurs décrites ci-dessous.

La méthode recommandée par la plupart des langages de programmation pour la gestion des erreurs imprévisibles est l'utilisation d'exceptions. C'est le comportement par défaut de la librairie Yoctopuce. Si une erreur se produit alors qu'on essaie d'accéder à un module, la librairie va lancer une exception. Dans ce cas, de trois choses l'une:

Comme cette dernière situation n'est pas la plus souhaitable, la librairie Yoctopuce offre une autre alternative pour la gestion des erreurs, permettant de faire un programme robuste sans devoir attraper les exceptions à chaque ligne de code. Il suffit d'appeler la fonction yDisableExceptions() pour commuter la librairie dans un mode où les exceptions de chaque fonction sont systématiquement remplacées par des valeurs de retour particulières, qui peuvent être testées par l'appelant lorsque c'est pertinent. Le nom de la valeur de retour en cas d'erreur pour chaque fonction est systématiquement documenté dans la référence de la librairie. Il suit toujours la même logique: une méthode get_state() retournera une valeur Y_STATE_INVALID, une méthode get_currentValue retournera une valeur Y_CURRENTVALUE_INVALID, etc. Dans tous les cas, la valeur retournée sera du type attendu, et ne sera pas un pointeur nul qui risquerait de faire crasher votre programme. Au pire, si vous affichez la valeur sans la tester, elle sera hors du cadre attendu pour la valeur retournée. Dans le cas de fonctions qui ne retournent à priori pas d'information, la valeur de retour sera YAPI_SUCCESS si tout va bien, et un code d'erreur différent en cas d'échec.

Quand vous travaillez sans les exceptions, il est possible d'obtenir un code d'erreur et un message expliquant l'origine de l'erreur en le demandant à l'objet qui a retourné une erreur à l'aide des méthodes errType() et errMessage(). Ce sont les même informations qui auraient été associées à l'exception si elles avaient été actives.

16. Utilisation du Yocto-MaxiDisplay en Python

Python est un langage interprété orienté objet développé par Guido van Rossum. Il offre l'avantage d'être gratuit et d'être disponible pour la plupart de plate-formes tant Windows qu'Unix. C'est un language idéal pour écrire des petits scripts sur un coin de table. La librairie Yoctopuce est compatible avec Python 2.6+ et 3+. Elle fonctionne sous Windows, Max OS X et Linux tant Intel qu'ARM. La librairie a été testée avec Python 2.6 et Python 3.2. Les interpréteurs Python sont disponibles sur le site de Python 44.

16.1. Fichiers sources

Les classes de la librairie Yoctopuce45 pour Python que vous utiliserez vous sont fournies au format source. Copiez tout le contenu du répertoire Sources dans le répertoire de votre choix et ajoutez ce répertoire à la variable d'environnement PYTHONPATH. Si vous utilisez un IDE pour programmer en Python, référez-vous à sa documentation afin le configurer de manière à ce qu'il retrouve automatiquement les fichiers sources de l'API.

16.2. Librairie dynamique

Une partie de la librairie de bas-niveau est écrite en C, mais vous n'aurez a priori pas besoin d'interagir directement avec elle: cette partie est fournie sous forme de DLL sous Windows, de fichier .so sous Unix et de fichier .dylib sous Mac OS X. Tout a été fait pour que l'interaction avec cette librairie se fasse aussi simplement que possible depuis Python: les différentes versions de la librairie dynamique correspondant aux différents systèmes d'exploitation et architectures sont stockées dans le répertoire cdll. L'API va charger automatiquement le bon fichier lors de son initialisation. Vous n'aurez donc pas à vous en soucier.

Si un jour vous deviez vouloir recompiler la librairie dynamique, vous trouverez tout son code source dans la librairie Yoctopuce pour le C++.

Afin de les garder simples, tous les exemples fournis dans cette documentation sont des applications consoles. Il va de soit que que le fonctionnement des librairies est strictement identiques si vous les intégrez dans une application dotée d'une interface graphique.

16.3. Contrôle de la fonction Display

Il suffit de quelques lignes de code pour piloter un Yocto-MaxiDisplay. Voici le squelette d'un fragment de code Python qui utilise la fonction Display.


[...]

errmsg=YRefParam()
#On récupère l'objet représentant le module (ici connecté en local sur USB)
YAPI.RegisterHub("usb",errmsg)
display = YDisplay.FindDisplay("YD128X64-123456.display")

#Pour gérer le hot-plug, on vérifie que le module est là
if display.isOnline():
    #Use display.get_displayLayer()
    ...
   
[...]  

Voyons maintenant en détail ce que font ces quelques lignes.

YAPI.RegisterHub

La fonction YAPI.RegisterHub initialise l'API de Yoctopuce en indiquant où les modules doivent être recherchés. Utilisée avec le paramètre "usb", elle permet de travailler avec les modules connectés localement à la machine. Si l'initialisation se passe mal, cette fonction renverra une valeur différente de YAPI.SUCCESS, et retournera via l'objet errmsg une explication du problème.

YDisplay.FindDisplay

La fonction YDisplay.FindDisplay, permet de retrouver un ecran en fonction du numéro de série de son module hôte et de son nom de fonction. Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté):


display = YDisplay.FindDisplay("YD128X64-123456.display")
display = YDisplay.FindDisplay("YD128X64-123456.MaFonction")
display = YDisplay.FindDisplay("MonModule.display")
display = YDisplay.FindDisplay("MonModule.MaFonction")
display = YDisplay.FindDisplay("MaFonction")

YDisplay.FindDisplay renvoie un objet que vous pouvez ensuite utiliser à loisir pour contrôler l'ecran.

isOnline

La méthode YDisplay.isOnline() de l'objet renvoyé par FindDisplay permet de savoir si le module correspondant est présent et en état de marche.

get_displayLayer

La méthode get_displayLayer() de l'objet renvoyé par YDisplay.FindDisplay permet récupérer un objet correspondant à une des couches de l'écran. Cet objet fourni toutes les routines graphiques.

Un exemple réel

Lancez votre interpréteur Python et ouvrez le script correspondant, fourni dans le répertoire Examples/Doc-GettingStarted-Yocto-MaxiDisplay de la librairie Yoctopuce.

Vous reconnaîtrez dans cet exemple l'utilisation des fonctions expliquées ci-dessus, cette fois utilisées avec le décorum nécessaire à en faire un petit programme d'exemple concret.

#!/usr/bin/python
# -*- coding: utf-8 -*-
import os,sys

from yocto_api import *
from yocto_display import *

def usage():
    scriptname = os.path.basename(sys.argv[0])
    print("Usage:")
    print(scriptname+' <serial_number>')
    print(scriptname+' <logical_name>')
    print(scriptname+' any  ')
    sys.exit()

def die(msg):
    sys.exit(msg+' (check USB cable)')

errmsg=YRefParam()

if len(sys.argv)<2 :  usage()

target=sys.argv[1]

# Setup the API to use local USB devices
if YAPI.RegisterHub("usb", errmsg)!= YAPI.SUCCESS:
    sys.exit("init error"+errmsg.value)



if target=='any':
    # retreive any RGB led
    disp = YDisplay.FirstDisplay()
    if disp is None :
        die('No module connected')
else:
    disp= YDisplay.FindDisplay(target + ".display")

if not disp.isOnline():
    die("Module not connected ")

# display clean up
disp.resetAll()

# retreive the display size
w=disp.get_displayWidth()
h=disp.get_displayHeight()

# retreive the first layer
l0=disp.get_displayLayer(0)
l0.clear()

#display a text in the middle of the screen
l0.drawText(w / 2,h / 2, YDisplayLayer.ALIGN.CENTER, "Hello world!" )

# visualize each corner
l0.moveTo(0,5)
l0.lineTo(0,0)
l0.lineTo(5,0)
l0.moveTo(0,h-6)
l0.lineTo(0,h-1)
l0.lineTo(5,h-1)
l0.moveTo(w-1,h-6)
l0.lineTo(w-1,h-1)
l0.lineTo(w-6,h-1)
l0.moveTo(w-1,5)
l0.lineTo(w-1,0)
l0.lineTo(w-6,0)

# draw a circle in the top left corner of layer 1
l1=disp.get_displayLayer(1)
l1.clear()
l1.drawCircle(h / 8, h / 8, h / 8)

# and animate the layer
print("Use Ctrl-C to stop")
x=0
y=0
vx=1
vy=1
while True:
    x+=vx
    y+=vy
    if x<0 or x>w-(h / 4) :  vx=-vx
    if y<0 or y>h-(h / 4)  : vy=-vy
    l1.setLayerPosition(x,y,0)
    YAPI.Sleep(5,errmsg)
 

16.4. Contrôle de la partie module

Chaque module peut-être contrôlé d'une manière similaire, vous trouverez ci-dessous un simple programme d'exemple affichant les principaux paramètres d'un module et permettant d'activer la balise de localisation.

#!/usr/bin/python
# -*- coding: utf-8 -*-
import os,sys
from yocto_api import *


def usage():
    sys.exit("usage: demo <serial or logical name> [ON/OFF]")

errmsg =YRefParam()
if YAPI.RegisterHub("usb", errmsg) !=  YAPI.SUCCESS:
    sys.exit("RegisterHub error: " + str(errmsg))

if len(sys.argv)<2 : usage()

m = YModule.FindModule(sys.argv[1]) ## use serial or logical name

if m.isOnline():
    if len(sys.argv) > 2:
        if sys.argv[2].upper() == "ON" :  m.set_beacon(YModule.BEACON_ON)
        if sys.argv[2].upper() == "OFF" : m.set_beacon(YModule.BEACON_OFF)

    print("serial:       " + m.get_serialNumber())
    print("logical name: " + m.get_logicalName())
    print("luminosity:   " + str(m.get_luminosity()))
    if m.get_beacon() == YModule.BEACON_ON:
        print("beacon:       ON")
    else:
        print("beacon:       OFF")
    print("upTime:       " + str(m.get_upTime()/1000)+" sec")
    print("USB current:  " + str(m.get_usbCurrent())+" mA")
    print("logs:\n" + m.get_lastLogs())    
else:
    print(sys.argv[1] + " not connected (check identification and USB cable)")



 

Chaque propriété xxx du module peut être lue grâce à une méthode du type YModule.get_xxxx(), et les propriétés qui se sont pas en lecture seule peuvent être modifiées à l'aide de la méthode YModule.set_xxx() Pour plus de détails concernant ces fonctions utilisées, reportez-vous aux chapitre API

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'appeler la fonction YModule.set_xxx() correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la méthode YModule.saveToFlash(). Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode YModule.revertFromFlash(). Ce petit exemple ci-dessous vous permet changer le nom logique d'un module.

#!/usr/bin/python
# -*- coding: utf-8 -*-
import os,sys
from yocto_api import *

def usage():
    sys.exit("usage: demo <serial or logical name> <new logical name>")

if len(sys.argv) != 3 :  usage()

errmsg =YRefParam()
if YAPI.RegisterHub("usb", errmsg) !=  YAPI.SUCCESS:
    sys.exit("RegisterHub error: " + str(errmsg))

m = YModule.FindModule(sys.argv[1]) # use serial or logical name

if m.isOnline():
    newname = sys.argv[2]
    if not YAPI.CheckLogicalName(newname):
        sys.exit("Invalid name (" + newname + ")")
    m.set_logicalName(newname)
    m.saveToFlash()  # do not forget this
    print ("Module: serial= " + m.get_serialNumber()+" / name= " + m.get_logicalName())
else:
    sys.exit("not connected (check identification and USB cable")

 

Attention, le nombre de cycles d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit que la sauvegarde des réglages se passera correctement. Cette limite, liée à la technologie employée par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la fonction YModule.saveToFlash() que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette fonction depuis l'intérieur d'une boucle.

Enumeration des modules

Obtenir la liste des modules connectés se fait à l'aide de la fonction YModule.yFirstModule() qui renvoie le premier module trouvé, il suffit ensuite d'appeler la mehode nextModule() de cet objet pour trouver les modules suivants, et ce tant que la réponse n'est pas un null. Ci-dessous un petit exemple listant les module connectés

#!/usr/bin/python
# -*- coding: utf-8 -*-
import os,sys

from yocto_api import *

errmsg=YRefParam()

# Setup the API to use local USB devices
if YAPI.RegisterHub("usb", errmsg)!= YAPI.SUCCESS:
    sys.exit("init error"+str(errmsg))

print('Device list')

module = YModule.FirstModule()
while module is not None:
     print(module.get_serialNumber()+' ('+module.get_productName()+')')
     module = module.nextModule()
 

16.5. Gestion des erreurs

Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour interpréter les erreurs signalées par la librairie.

La manière la plus simple de contourner le problème est celle que nous avons employé pour les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est en ligne avec la méthode isOnline() et on suppose ensuite qu'il va y rester pendant la fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait, mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas totalement exclure une erreur se produisant après le isOnline(), qui pourrait faire planter le programme. La seule manière de l'éviter est d'implémenter une des deux techniques de gestion des erreurs décrites ci-dessous.

La méthode recommandée par la plupart des langages de programmation pour la gestion des erreurs imprévisibles est l'utilisation d'exceptions. C'est le comportement par défaut de la librairie Yoctopuce. Si une erreur se produit alors qu'on essaie d'accéder à un module, la librairie va lancer une exception. Dans ce cas, de trois choses l'une:

Comme cette dernière situation n'est pas la plus souhaitable, la librairie Yoctopuce offre une autre alternative pour la gestion des erreurs, permettant de faire un programme robuste sans devoir attraper les exceptions à chaque ligne de code. Il suffit d'appeler la fonction yDisableExceptions() pour commuter la librairie dans un mode où les exceptions de chaque fonction sont systématiquement remplacées par des valeurs de retour particulières, qui peuvent être testées par l'appelant lorsque c'est pertinent. Le nom de la valeur de retour en cas d'erreur pour chaque fonction est systématiquement documenté dans la référence de la librairie. Il suit toujours la même logique: une méthode get_state() retournera une valeur Y_STATE_INVALID, une méthode get_currentValue retournera une valeur Y_CURRENTVALUE_INVALID, etc. Dans tous les cas, la valeur retournée sera du type attendu, et ne sera pas un pointeur nul qui risquerait de faire crasher votre programme. Au pire, si vous affichez la valeur sans la tester, elle sera hors du cadre attendu pour la valeur retournée. Dans le cas de fonctions qui ne retournent à priori pas d'information, la valeur de retour sera YAPI_SUCCESS si tout va bien, et un code d'erreur différent en cas d'échec.

Quand vous travaillez sans les exceptions, il est possible d'obtenir un code d'erreur et un message expliquant l'origine de l'erreur en le demandant à l'objet qui a retourné une erreur à l'aide des méthodes errType() et errMessage(). Ce sont les même informations qui auraient été associées à l'exception si elles avaient été actives.

17. Utilisation du Yocto-MaxiDisplay en Java

Java est un langage orienté objet développé par Sun Microsystem. Son principal avantage est la portabilité, mais cette portabilité a un coût. Java fait une telle abstraction des couches matérielles qu'il est très difficile d'interagir directement avec elles. C'est pourquoi l'API java standard de Yoctopuce ne fonctionne pas en natif: elle doit passer par l'intermédiaire d'un VirtualHub pour pouvoir communiquer avec les modules Yoctopuce.

17.1. Préparation

Connectez vous sur le site de Yoctopuce et téléchargez les éléments suivants:

La librairie est disponible en fichier sources, mais elle aussi disponible sous la forme d'un fichier jar. Branchez vos modules, Décompressez les fichiers de la librairie dans un répertoire de votre choix. Lancez le programme VirtualHub, et vous pouvez commencer vos premiers test. Vous n'avez pas besoin d'installer de driver.

Afin de les garder simples, tous les exemples fournis dans cette documentation sont des applications consoles. Il va de soit que que le fonctionnement des librairies est strictement identiques si vous les intégrez dans une application dotée d'une interface graphique.

17.2. Contrôle de la fonction Display

Il suffit de quelques lignes de code pour piloter un Yocto-MaxiDisplay. Voici le squelette d'un fragment de code Java qui utilise la fonction Display.


[...]

// On récupère l'objet représentant le module (ici connecté en local sur USB)
YAPI.RegisterHub("127.0.0.1");
display = YDisplay.FindDisplay("YD128X64-123456.display");

//Pour gérer le hot-plug, on vérifie que le module est là
if (display.isOnline())
   { //Use display.get_displayLayer()
     ...  
   }
   
[...]  

Voyons maintenant en détail ce que font ces quelques lignes.

YAPI.RegisterHub

La fonction YAPI.RegisterHub initialise l'API de Yoctopuce en indiquant où les modules doivent être recherchés. Le paramètre est l'adresse du virtual hub capable de voir les modules. Si l'initialisation se passe mal, une exception sera générée.

YDisplay.FindDisplay

La fonction YDisplay.FindDisplay, permet de retrouver un ecran en fonction du numéro de série de son module hôte et de son nom de fonction. Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté):


display = YDisplay.FindDisplay("YD128X64-123456.display")
display = YDisplay.FindDisplay("YD128X64-123456.MaFonction")
display = YDisplay.FindDisplay("MonModule.display")
display = YDisplay.FindDisplay("MonModule.MaFonction")
display = YDisplay.FindDisplay("MaFonction")

YDisplay.FindDisplay renvoie un objet que vous pouvez ensuite utiliser à loisir pour contrôler l'ecran.

isOnline

La méthode YDisplay.isOnline() de l'objet renvoyé par FindDisplay permet de savoir si le module correspondant est présent et en état de marche.

get_displayLayer

La méthode get_displayLayer() de l'objet renvoyé par YDisplay.FindDisplay permet récupérer un objet correspondant à une des couches de l'écran. Cet objet fourni toutes les routines graphiques.

Un exemple réel

Lancez votre environnement java et ouvrez le projet correspondant, fourni dans le répertoire Examples/Doc-GettingStarted-Yocto-MaxiDisplay de la librairie Yoctopuce.

Vous reconnaîtrez dans cet exemple l'utilisation des fonctions expliquées ci-dessus, cette fois utilisées avec le décorum nécessaire à en faire un petit programme d'exemple concret.


import com.yoctopuce.YoctoAPI.*;
import java.util.logging.Level;
import java.util.logging.Logger;

public class Demo {

    private static void disp(YDisplay display, String text, YDisplayLayer.ALIGN al) throws YAPI_Exception
    {
        YDisplayLayer layer0 = display.get_displayLayer(0);
        int l = (int) display.get_displayWidth();
        int h = (int) display.get_displayHeight();
        int mx = l / 2;
        int my = h / 2;
        layer0.clear();
        layer0.moveTo(mx, 0);
        layer0.lineTo(mx, h);
        layer0.moveTo(0, my);
        layer0.lineTo(l, my);
        layer0.drawText(mx, my, al, text);
    }

    public static void main(String[] args)
    {

        YDisplay disp;
        YDisplayLayer l0, l1;
        int h, w, y, x, vx, vy;

        // API init
        try {
            // setup the API to use local VirtualHub
            YAPI.RegisterHub("127.0.0.1");
        } catch (YAPI_Exception ex) {
            System.out.println("Cannot contact VirtualHub on 127.0.0.1 (" + ex.getLocalizedMessage() + ")");
            System.out.println("Ensure that the VirtualHub application is running");
            System.exit(1);
        }

        if (args.length == 0) {
            disp = YDisplay.FirstDisplay();
            if (disp == null) {
                System.out.println("No module connected (check USB cable)");
                System.exit(1);
            }
        } else {
            disp = YDisplay.FindDisplay(args[0] + ".display");
        }

        try {
            //clean up
            disp.resetAll();

            // retreive the display size
            w = disp.get_displayWidth();
            h = disp.get_displayHeight();

            // reteive the first layer
            l0 = disp.get_displayLayer(0);

            // display a text in the middle of the screen
            l0.drawText(w / 2, h / 2, YDisplayLayer.ALIGN.CENTER, "Hello world!");

            // visualize each corner
            l0.moveTo(0, 5);
            l0.lineTo(0, 0);
            l0.lineTo(5, 0);
            l0.moveTo(0, h - 6);
            l0.lineTo(0, h - 1);
            l0.lineTo(5, h - 1);
            l0.moveTo(w - 1, h - 6);
            l0.lineTo(w - 1, h - 1);
            l0.lineTo(w - 6, h - 1);
            l0.moveTo(w - 1, 5);
            l0.lineTo(w - 1, 0);
            l0.lineTo(w - 6, 0);

            // draw a circle in the top left corner of layer 1
            l1 = disp.get_displayLayer(1);
            l1.clear();
            l1.drawCircle(h / 8, h / 8, h / 8);

            // and animate the layer
            System.out.println("Use Ctrl-C to stop");
            x = 0;
            y = 0;
            vx = 1;
            vy = 1;
            while (true) {
                x += vx;
                y += vy;
                if ((x < 0) || (x > w - (h / 4))) {
                    vx = -vx;
                }
                if ((y < 0) || (y > h - (h / 4))) {
                    vy = -vy;
                }
                l1.setLayerPosition(x, y, 0);
                YAPI.Sleep(5);
            }

        } catch (YAPI_Exception ex) {
            System.out.println("Exception durring execution (" + ex.getLocalizedMessage() + ")");
            YAPI.FreeAPI();
            System.exit(1);
        }

    }
}
 

17.3. Contrôle de la partie module

Chaque module peut-être contrôlé d'une manière similaire, vous trouverez ci-dessous un simple programme d'exemple affichant les principaux paramètres d'un module et permettant d'activer la balise de localisation.


import com.yoctopuce.YoctoAPI.*;
import java.util.logging.Level;
import java.util.logging.Logger;

public class Demo {

    public static void main(String[] args)
    {
        try {
            // setup the API to use local VirtualHub
            YAPI.RegisterHub("127.0.0.1");
        } catch (YAPI_Exception ex) {
            System.out.println("Cannot contact VirtualHub on 127.0.0.1 (" + ex.getLocalizedMessage() + ")");
            System.out.println("Ensure that the VirtualHub application is running");
            System.exit(1);
        }
        System.out.println("usage: demo [serial or logical name] [ON/OFF]");

        YModule module;
        if (args.length == 0) {
            module = YModule.FirstModule();
            if (module == null) {
                System.out.println("No module connected (check USB cable)");
                System.exit(1);
            }
        } else {
            module = YModule.FindModule(args[0]);  // use serial or logical name
        }

        try {
            if (args.length > 1) {
                if (args[1].equalsIgnoreCase("ON")) {
                    module.setBeacon(YModule.BEACON_ON);
                } else {
                    module.setBeacon(YModule.BEACON_OFF);
                }
            }
            System.out.println("serial:       " + module.get_serialNumber());
            System.out.println("logical name: " + module.get_logicalName());
            System.out.println("luminosity:   " + module.get_luminosity());
            if (module.get_beacon() == YModule.BEACON_ON) {
                System.out.println("beacon:       ON");
            } else {
                System.out.println("beacon:       OFF");
            }
            System.out.println("upTime:       " + module.get_upTime() / 1000 + " sec");
            System.out.println("USB current:  " + module.get_usbCurrent() + " mA");
            System.out.println("logs:\n" + module.get_lastLogs());
        } catch (YAPI_Exception ex) {
            System.out.println(args[1] + " not connected (check identification and USB cable)");
        }
        YAPI.FreeAPI();
    }
}
 

Chaque propriété xxx du module peut être lue grâce à une méthode du type YModule.get_xxxx(), et les propriétés qui se sont pas en lecture seule peuvent être modifiées à l'aide de la méthode YModule.set_xxx() Pour plus de détails concernant ces fonctions utilisées, reportez-vous aux chapitre API

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'appeler la fonction YModule.set_xxx() correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la méthode YModule.saveToFlash(). Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode YModule.revertFromFlash(). Ce petit exemple ci-dessous vous permet changer le nom logique d'un module.

import com.yoctopuce.YoctoAPI.*;

public class Demo {

    public static void main(String[] args)
    {
        try {
            // setup the API to use local VirtualHub
            YAPI.RegisterHub("127.0.0.1");
        } catch (YAPI_Exception ex) {
            System.out.println("Cannot contact VirtualHub on 127.0.0.1 (" + ex.getLocalizedMessage() + ")");
            System.out.println("Ensure that the VirtualHub application is running");
            System.exit(1);
        }

        if (args.length != 2) {
            System.out.println("usage: demo <serial or logical name> <new logical name>");
            System.exit(1);
        }

        YModule m;
        String newname;

        m = YModule.FindModule(args[0]); // use serial or logical name

        try {
            newname = args[1];
            if (!YAPI.CheckLogicalName(newname))
                {
                    System.out.println("Invalid name (" + newname + ")");
                    System.exit(1);
                }

            m.set_logicalName(newname);
            m.saveToFlash(); // do not forget this

            System.out.println("Module: serial= " + m.get_serialNumber());
            System.out.println(" / name= " + m.get_logicalName());
        } catch (YAPI_Exception ex) {
            System.out.println("Module " + args[0] + "not connected (check identification and USB cable)");
            System.out.println(ex.getMessage());
            System.exit(1);
        }

        YAPI.FreeAPI();
    }
}
 

Attention, le nombre de cycles d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit que la sauvegarde des réglages se passera correctement. Cette limite, liée à la technologie employée par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la fonction YModule.saveToFlash() que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette fonction depuis l'intérieur d'une boucle.

Enumeration des modules

Obtenir la liste des modules connectés se fait à l'aide de la fonction YModule.yFirstModule() qui renvoie le premier module trouvé, il suffit ensuite d'appeler la mehode nextModule() de cet objet pour trouver les modules suivants, et ce tant que la réponse n'est pas un null. Ci-dessous un petit exemple listant les module connectés

import com.yoctopuce.YoctoAPI.*;

public class Demo {

    public static void main(String[] args)
    {
        try {
            // setup the API to use local VirtualHub
            YAPI.RegisterHub("127.0.0.1");
        } catch (YAPI_Exception ex) {
            System.out.println("Cannot contact VirtualHub on 127.0.0.1 (" + ex.getLocalizedMessage() + ")");
            System.out.println("Ensure that the VirtualHub application is running");
            System.exit(1);
        }

        System.out.println("Device list");
        YModule module = YModule.FirstModule();
        while (module != null) {
            try {
                System.out.println(module.get_serialNumber() + " (" + module.get_productName() + ")");
            } catch (YAPI_Exception ex) {
                break;
            }
            module = module.nextModule();
        }

        YAPI.FreeAPI();
    }
}
 

17.4. Gestion des erreurs

Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour interpréter les erreurs signalées par la librairie.

La manière la plus simple de contourner le problème est celle que nous avons employé pour les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est en ligne avec la méthode isOnline() et on suppose ensuite qu'il va y rester pendant la fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait, mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas totalement exclure une erreur se produisant après le isOnline(), qui pourrait faire planter le programme.

Dans l'API java, le traitement d'erreur est implémenté au moyen d'exceptions. Vous devrez donc intercepter et traiter correctement ces exceptions si vous souhaitez avoir un projet fiable qui ne crashera pas des que vous débrancherez un module.

18. Utilisation du Yocto-MaxiDisplay avec Android

A vrai dire, Android n'est pas un langage de programmation, c'est un système d'exploitation développé par Google pour les appareils portables tels que smart phones et tablettes. Mais il se trouve que sous Android tout est programmé avec le même langage de programmation: Java. En revanche les paradigmes de programmation et les possibilités d'accès au hardware sont légèrement différentes par rapport au Java classique, ce qui justifie un chapitre à part sur la programmation Android.

18.1. Accès Natif et Virtual Hub.

Contrairement à l'API Java classique, l'API Java pour Android accède aux modules USB de manière native. En revanche, comme il n'existe pas de VirtualHub tournant sous Android, il n'est pas possible de prendre le contrôle à distance de modules Yoctopuce pilotés par une machine sous Android. Bien sûr, l'API Java pour Android reste parfaitement capable de se connecter à un VirtualHub tournant sur un autre OS.

18.2. Préparation

Connectez-vous sur le site de Yoctopuce et téléchargez la librairie de programmation pour Java pour Android48. La librairie est disponible en fichiers sources, mais elle aussi disponible sous la forme d'un fichier jar. Branchez vos modules, décompressez les fichiers de la librairie dans le répertoire de votre choix. Et configurez votre environnement de programmation Android pour qu'il puisse les trouver.

Afin de les garder simples, tous les exemples fournis dans cette documentation sont des fragments d'application Android. Vous devrez les intégrer dans vos propres applications Android pour les faire fonctionner. En revanche vous pourrez trouver des applications complètes dans les exemples fournis avec la librairie Java pour Android.

18.3. Compatibilité

Dans un monde idéal, il suffirait d'avoir un téléphone sous Android pour pouvoir faire fonctionner des modules Yoctopuce. Malheureusement, la réalité est légèrement différente, un appareil tournant sous Android doit répondre à un certain nombre d'exigences pour pouvoir faire fonctionner des modules USB Yoctopuce en natif.

Android 4.x

Android 4.0 (api 14) et suivants sont officiellement supportés. Théoriquement le support USB host fonctionne depuis Android 3.1. Mais sachez que Yoctopuce ne teste régulièrement l'API Java pour Android qu'à partir de Android 4.

Support USB host

Il faut bien sûr que votre machine dispose non seulement d'un port USB, mais il faut aussi que ce port soit capable de tourner en mode host. En mode host, la machine prend littéralement le contrôle des périphériques qui lui sont raccordés. Les ports USB d'un ordinateur bureau, par exemple, fonctionnent mode host. Le pendant du mode host est le mode device. Les clefs USB par exemple fonctionnent en mode device: elles ne peuvent qu'être contrôlées par un host. Certains ports USB sont capables de fonctionner dans les deux modes, ils s'agit de ports OTG (On The Go). Il se trouve que beaucoup d'appareils portables ne fonctionnent qu'en mode "device": ils sont conçus pour être branchés à chargeur ou un ordinateur de bureau, rien de plus. Il est donc fortement recommandé de lire attentivement les spécifications techniques d'un produit fonctionnant sous Android avant d'espérer le voir fonctionner avec des modules Yoctopuce.

Disposer d'une version correcte d'Android et de ports USB fonctionnant en mode host ne suffit malheureusement pas pour garantir un bon fonctionnement avec des modules Yoctopuce sous Android. En effet certains constructeurs configurent leur image Android afin que les périphériques autres que clavier et mass storage soit ignorés, et cette configuration est difficilement détectable. En l'état actuel des choses, le meilleur moyen de savoir avec certitude si un matériel Android spécifique fonctionne avec les modules Yoctopuce consiste à essayer.

Matériel supporté

La librairie est testée et validée sur les machines suivantes:

Si votre machine Android n'est pas capable de faire fonctionner nativement des modules Yoctopuce, il vous reste tout de même la possibilité de contrôler à distance des modules pilotés par un VirtualHub sur un autre OS ou un YoctoHub49.

18.4. Activer le port USB sous Android

Par défaut Android n’autorise pas une application à accéder aux périphériques connectés au port USB. Pour que votre application puisse interagir avec un module Yoctopuce branché directement sur votre tablette sur un port USB quelques étapes supplémentaires sont nécessaires. Si vous comptez uniquement interagir avec des modules connectés sur une autre machine par IP, vous pouvez ignorer cette section.

Il faut déclarer dans son AndroidManifest.xml l'utilisation de la fonctionnalité "USB Host" en ajoutant le tag <uses-feature android:name="android.hardware.usb.host" /> dans la section manifest.


<manifest ...>
    ...
    <uses-feature android:name="android.hardware.usb.host" />;
    ...
</manifest>

Lors du premier accès à un module Yoctopuce, Android va ouvrir une fenêtre pour informer l'utilisateur que l'application va accéder module connecté. L'utilisateur peut refuser ou autoriser l’accès au périphérique. Si l'utilisateur accepte, l'application pourra accéder au périphérique connecté jusqu'à la prochaine déconnexion du périphérique. Pour que la librairie Yoctopuce puisse gérer correctement ces autorisations, il faut lui fournir un pointeur sur le contexte de l'application en appelant la méthode EnableUSBHost de la classe YAPI avant le premier accès USB. Cette fonction prend en argument un objet de la classe android.content.Context (ou d'une sous-classe). Comme la classe Activity est une sous-classe de Context, le plus simple est de d'appeler YAPI.EnableUSBHost(this); dans la méthode onCreate de votre application. Si l'objet passé en paramètre n'est pas du bon type, une exception YAPI_Exception sera générée.


...
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    try {
                // Pass the application Context to the Yoctopuce Library
        YAPI.EnableUSBHost(this);
        } catch (YAPI_Exception e) {
                Log.e("Yocto",e.getLocalizedMessage());
        }
}
...

Lancement automatique

Il est possible d'enregistrer son application comme application par défaut pour un module USB, dans ce cas des qu'un module sera connecté au système, l'application sera lancée automatiquement. Il faut ajouter <action android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED"/> dans la section <intent-filter> de l'activité principale. La section <activity> doit contenir un pointeur sur un fichier xml qui contient la liste des modules USB qui peuvent lancer l'application.


<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    ...
    <uses-feature android:name="android.hardware.usb.host" />
    ...
    <application ... >
        <activity
            android:name=".MainActivity" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <action android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>

            <meta-data
                android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED"
                android:resource="@xml/device_filter" />
        </activity>
    </application>

</manifest>

Le fichier XML qui contient la liste des modules qui peuvent lancer l'application doit être sauvé dans le répertoire res/xml. Ce fichier contient une liste de vendorId et deviceID USB en décimal. L'exemple suivant lance l'application dès qu'un Yocto-Relay ou un Yocto-PowerRelay est connecté. Vous pouvez trouver le vendorId et deviceId des modules Yoctopuce dans la section caractéristiques de la documentation.


<?xml version="1.0" encoding="utf-8"?>

<resources>
    <usb-device vendor-id="9440" product-id="12" />
    <usb-device vendor-id="9440" product-id="13" />
</resources>

18.5. Contrôle de la fonction Display

Il suffit de quelques lignes de code pour piloter un Yocto-MaxiDisplay. Voici le squelette d'un fragment de code Java qui utilise la fonction Display.


[...]

// On récupère l'objet représentant le module (ici connecté en local sur USB)
YAPI.EnableUSBHost(this);
YAPI.RegisterHub("usb");
display = YDisplay.FindDisplay("YD128X64-123456.display");

//Pour gérer le hot-plug, on vérifie que le module est là
if (display.isOnline())
   { //Use display.get_displayLayer()
     ...
   }

[...]

Voyons maintenant en détail ce que font ces quelques lignes.

YAPI.EnableUSBHost

La fonction YAPI.EnableUSBHost initialise l'API avec le Context de l'application courante. Cette fonction prend en argument un objet de la classe android.content.Context (ou d'une sous-classe). Si vous comptez uniquement vous connecter à d'autres machines par IP vous cette fonction est factultative.

YAPI.RegisterHub

La fonction YAPI.RegisterHub initialise l'API de Yoctopuce en indiquant où les modules doivent être recherchés. Le paramètre est l'adresse du virtual hub capable de voir les modules. Si l'on passe la chaine de caractère "usb", l'API va travailler avec les modules connectés localement à la machine. Si l'initialisation se passe mal, une exception sera générée.

YDisplay.FindDisplay

La fonction YDisplay.FindDisplay permet de retrouver un ecran en fonction du numéro de série de son module hôte et de son nom de fonction. Mais vous pouvez tout aussi bien utiliser des noms logiques que vous auriez préalablement configurés. Imaginons un module Yocto-MaxiDisplay avec le numéros de série YD128X64-123456 que vous auriez appelé "MonModule" et dont vous auriez nommé la fonction display "MaFonction", les cinq appels suivants seront strictement équivalents (pour autant que MaFonction ne soit définie qu'une fois, pour éviter toute ambiguïté):


display = YDisplay.FindDisplay("YD128X64-123456.display")
display = YDisplay.FindDisplay("YD128X64-123456.MaFonction")
display = YDisplay.FindDisplay("MonModule.display")
display = YDisplay.FindDisplay("MonModule.MaFonction")
display = YDisplay.FindDisplay("MaFonction")

YDisplay.FindDisplay renvoie un objet que vous pouvez ensuite utiliser à loisir pour contrôler l'ecran.

isOnline

La méthode YDisplay.isOnline() de l'objet renvoyé par FindDisplay permet de savoir si le module correspondant est présent et en état de marche.

get_displayLayer

La méthode get_displayLayer() de l'objet renvoyé par YDisplay.FindDisplay permet récupérer un objet correspondant à une des couches de l'écran. Cet objet fourni toutes les routines graphiques.

Un exemple réel

Lancez votre environnement java et ouvrez le projet correspondant, fourni dans le répertoire Examples/Doc-Examples de la librairie Yoctopuce.

Vous reconnaîtrez dans cet exemple l'utilisation des fonctions expliquées ci-dessus, cette fois utilisées avec le décorum nécessaire à en faire un petit programme d'exemple concret.

package com.yoctopuce.doc_examples;

import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.widget.AdapterView;
import android.widget.AdapterView.OnItemSelectedListener;
import android.widget.ArrayAdapter;
import android.widget.EditText;
import android.widget.Spinner;

import com.yoctopuce.YoctoAPI.YAPI;
import com.yoctopuce.YoctoAPI.YAPI_Exception;
import com.yoctopuce.YoctoAPI.YDisplay;
import com.yoctopuce.YoctoAPI.YDisplayLayer;

public class GettingStarted_Yocto_MaxiDisplay extends Activity implements OnItemSelectedListener
{

       
    private YDisplay display = null;
    private ArrayAdapter<String> aa;

    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.gettingstarted_yocto_maxidisplay);
        Spinner my_spin = (Spinner) findViewById(R.id.spinner1);
        my_spin.setOnItemSelectedListener(this);
        aa = new ArrayAdapter<String>(this, android.R.layout.simple_spinner_item);
        aa.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item);
        my_spin.setAdapter(aa);
    }

    @Override
    protected void onStart()
    {
        super.onStart();
        aa.clear();
        try {
            YAPI.EnableUSBHost(this);
            YAPI.RegisterHub("usb");
            YDisplay d = YDisplay.FirstDisplay();
            while (d != null) {
                String hwid = d.get_hardwareId();
                aa.add(hwid);
                d = d.nextDisplay();
            }
        } catch (YAPI_Exception e) {
            e.printStackTrace();
        }
        aa.notifyDataSetChanged();
    }

    @Override
    protected void onStop()
    {
        super.onStop();
        YAPI.FreeAPI();
    }

    @Override
    public void onItemSelected(AdapterView<?> parent, View view, int pos, long id)
    {
        String hwid = parent.getItemAtPosition(pos).toString();
        display = YDisplay.FindDisplay(hwid);
        updateDisplay(null);
    }

    @Override
    public void onNothingSelected(AdapterView<?> arg0)
    {
    }

    public void updateDisplay(View view)
    {
        if (display == null)
            return;
       
        EditText message = (EditText) findViewById(R.id.editText1);        
        // clean up
        try {
            display.resetAll();

            // retreive the display size
            int w = display.get_displayWidth();
            int h = display.get_displayHeight();

            // reteive the first layer
            YDisplayLayer l0 = display.get_displayLayer(0);

            // display a text in the middle of the screen
            l0.drawText(w / 2, h / 2, YDisplayLayer.ALIGN.CENTER, message.getText().toString());

            // visualize each corner
            l0.moveTo(0, 5);
            l0.lineTo(0, 0);
            l0.lineTo(5, 0);
            l0.moveTo(0, h - 6);
            l0.lineTo(0, h - 1);
            l0.lineTo(5, h - 1);
            l0.moveTo(w - 1, h - 6);
            l0.lineTo(w - 1, h - 1);
            l0.lineTo(w - 6, h - 1);
            l0.moveTo(w - 1, 5);
            l0.lineTo(w - 1, 0);
            l0.lineTo(w - 6, 0);
        } catch (YAPI_Exception e) {
            e.printStackTrace();
        }

    }

       
}
 

18.6. Contrôle de la partie module

Chaque module peut-être contrôlé d'une manière similaire, vous trouverez ci-dessous un simple programme d'exemple affichant les principaux paramètres d'un module et permettant d'activer la balise de localisation.

package com.yoctopuce.doc_examples;

import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.widget.AdapterView;
import android.widget.AdapterView.OnItemSelectedListener;
import android.widget.ArrayAdapter;
import android.widget.Spinner;
import android.widget.Switch;
import android.widget.TextView;

import com.yoctopuce.YoctoAPI.YAPI;
import com.yoctopuce.YoctoAPI.YAPI_Exception;
import com.yoctopuce.YoctoAPI.YModule;

public class ModuleControl extends Activity implements OnItemSelectedListener
{

    private ArrayAdapter<String> aa;
    private YModule module = null;

    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.modulecontrol);
        Spinner my_spin = (Spinner) findViewById(R.id.spinner1);
        my_spin.setOnItemSelectedListener(this);
        aa = new ArrayAdapter<String>(this, android.R.layout.simple_spinner_item);
        aa.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item);
        my_spin.setAdapter(aa);
    }

    @Override
    protected void onStart()
    {
        super.onStart();

        try {
            aa.clear();
            YAPI.EnableUSBHost(this);
            YAPI.RegisterHub("usb");
            YModule r = YModule.FirstModule();
            while (r != null) {
                String hwid = r.get_hardwareId();
                aa.add(hwid);
                r = r.nextModule();
            }
        } catch (YAPI_Exception e) {
            e.printStackTrace();
        }
        // refresh Spinner with detected relay
        aa.notifyDataSetChanged();
    }

    @Override
    protected void onStop()
    {
        super.onStop();
        YAPI.FreeAPI();
    }

    private void DisplayModuleInfo()
    {
        TextView field;
        if (module == null)
            return;
        try {
            field = (TextView) findViewById(R.id.serialfield);
            field.setText(module.getSerialNumber());
            field = (TextView) findViewById(R.id.logicalnamefield);
            field.setText(module.getLogicalName());
            field = (TextView) findViewById(R.id.luminosityfield);
            field.setText(String.format("%d%%", module.getLuminosity()));
            field = (TextView) findViewById(R.id.uptimefield);
            field.setText(module.getUpTime() / 1000 + " sec");
            field = (TextView) findViewById(R.id.usbcurrentfield);
            field.setText(module.getUsbCurrent() + " mA");
            Switch sw = (Switch) findViewById(R.id.beaconswitch);
            Log.d("switch", "beacon" + module.get_beacon());
            sw.setChecked(module.getBeacon() == YModule.BEACON_ON);
            field = (TextView) findViewById(R.id.logs);
            field.setText(module.get_lastLogs());

        } catch (YAPI_Exception e) {
            e.printStackTrace();
        }
    }

    @Override
    public void onItemSelected(AdapterView<?> parent, View view, int pos, long id)
    {
        String hwid = parent.getItemAtPosition(pos).toString();
        module = YModule.FindModule(hwid);
        DisplayModuleInfo();
    }

    @Override
    public void onNothingSelected(AdapterView<?> arg0)
    {
    }

    public void refreshInfo(View view)
    {
        DisplayModuleInfo();
    }

    public void toggleBeacon(View view)
    {
        if (module == null)
            return;
        boolean on = ((Switch) view).isChecked();

        try {
            if (on) {
                module.setBeacon(YModule.BEACON_ON);
            } else {
                module.setBeacon(YModule.BEACON_OFF);
            }
        } catch (YAPI_Exception e) {
            e.printStackTrace();
        }
    }
}
 

Chaque propriété xxx du module peut être lue grâce à une méthode du type YModule.get_xxxx(), et les propriétés qui se sont pas en lecture seule peuvent être modifiées à l'aide de la méthode YModule.set_xxx() Pour plus de détails concernant ces fonctions utilisées, reportez-vous aux chapitre API

Modifications des réglages du module

Lorsque que vous souhaitez modifier les réglages d'un module, il suffit d'appeler la fonction YModule.set_xxx() correspondante, cependant cette modification n'a lieu que dans la mémoire vive du module: si le module redémarre, les modifications seront perdues. Pour qu'elle soient mémorisées de manière persistante, il est nécessaire de demander au module de sauvegarder sa configuration courante dans sa mémoire non volatile. Pour cela il faut utiliser la méthode YModule.saveToFlash(). Inversement il est possible de forcer le module à oublier ses réglages courants en utilisant la méthode YModule.revertFromFlash(). Ce petit exemple ci-dessous vous permet changer le nom logique d'un module.

package com.yoctopuce.doc_examples;

import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.widget.AdapterView;
import android.widget.AdapterView.OnItemSelectedListener;
import android.widget.ArrayAdapter;
import android.widget.EditText;
import android.widget.Spinner;
import android.widget.TextView;
import android.widget.Toast;

import com.yoctopuce.YoctoAPI.YAPI;
import com.yoctopuce.YoctoAPI.YAPI_Exception;
import com.yoctopuce.YoctoAPI.YModule;

public class SaveSettings extends Activity implements OnItemSelectedListener
{

    private ArrayAdapter<String> aa;
    private YModule module = null;

    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.savesettings);
        Spinner my_spin = (Spinner) findViewById(R.id.spinner1);
        my_spin.setOnItemSelectedListener(this);
        aa = new ArrayAdapter<String>(this, android.R.layout.simple_spinner_item);
        aa.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item);
        my_spin.setAdapter(aa);
    }

    @Override
    protected void onStart()
    {
        super.onStart();

        try {
            aa.clear();
            YAPI.EnableUSBHost(this);
            YAPI.RegisterHub("usb");
            YModule r = YModule.FirstModule();
            while (r != null) {
                String hwid = r.get_hardwareId();
                aa.add(hwid);
                r = r.nextModule();
            }
        } catch (YAPI_Exception e) {
            e.printStackTrace();
        }
        // refresh Spinner with detected relay
        aa.notifyDataSetChanged();
    }

    @Override
    protected void onStop()
    {
        super.onStop();
        YAPI.FreeAPI();
    }

    private void DisplayModuleInfo()
    {
        TextView field;
        if (module == null)
            return;
        try {
            YAPI.UpdateDeviceList();// fixme
            field = (TextView) findViewById(R.id.logicalnamefield);
            field.setText(module.getLogicalName());
        } catch (YAPI_Exception e) {
            e.printStackTrace();
        }
    }

    @Override
    public void onItemSelected(AdapterView<?> parent, View view, int pos, long id)
    {
        String hwid = parent.getItemAtPosition(pos).toString();
        module = YModule.FindModule(hwid);
        DisplayModuleInfo();
    }

    @Override
    public void onNothingSelected(AdapterView<?> arg0)
    {
    }

    public void saveName(View view)
    {
        if (module == null)
            return;

        EditText edit = (EditText) findViewById(R.id.newname);
        String newname = edit.getText().toString();
        try {
            if (!YAPI.CheckLogicalName(newname)) {
                Toast.makeText(getApplicationContext(), "Invalid name (" + newname + ")", Toast.LENGTH_LONG).show();
                return;
            }
            module.set_logicalName(newname);
            module.saveToFlash(); // do not forget this
            edit.setText("");
        } catch (YAPI_Exception ex) {
            ex.printStackTrace();
        }
        DisplayModuleInfo();
    }

}
 

Attention, le nombre de cycles d'écriture de la mémoire non volatile du module est limité. Passé cette limite plus rien ne garantit que la sauvegarde des réglages se passera correctement. Cette limite, liée à la technologie employée par le micro-processeur du module se situe aux alentour de 100000 cycles. Pour résumer vous ne pouvez employer la fonction YModule.saveToFlash() que 100000 fois au cours de la vie du module. Veillez donc à ne pas appeler cette fonction depuis l'intérieur d'une boucle.

Enumeration des modules

Obtenir la liste des modules connectés se fait à l'aide de la fonction YModule.yFirstModule() qui renvoie le premier module trouvé, il suffit ensuite d'appeler la mehode nextModule() de cet objet pour trouver les modules suivants, et ce tant que la réponse n'est pas un null. Ci-dessous un petit exemple listant les module connectés

package com.yoctopuce.doc_examples;

import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.widget.LinearLayout;
import android.widget.TextView;

import com.yoctopuce.YoctoAPI.YAPI;
import com.yoctopuce.YoctoAPI.YAPI_Exception;
import com.yoctopuce.YoctoAPI.YModule;

public class Inventory extends Activity
{

    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.inventory);
    }

    public void refreshInventory(View view)
    {
        LinearLayout layout = (LinearLayout) findViewById(R.id.inventoryList);
        layout.removeAllViews();

        try {
            YAPI.UpdateDeviceList();
            YModule module = YModule.FirstModule();
            while (module != null) {
                String line = module.get_serialNumber() + " (" + module.get_productName() + ")";
                TextView tx = new TextView(this);
                tx.setText(line);
                layout.addView(tx);
                module = module.nextModule();
            }
        } catch (YAPI_Exception e) {
            e.printStackTrace();
        }
    }

    @Override
    protected void onStart()
    {
        super.onStart();
        try {
            YAPI.EnableUSBHost(this);
            YAPI.RegisterHub("usb");
        } catch (YAPI_Exception e) {
            e.printStackTrace();
        }
        refreshInventory(null);
    }

    @Override
    protected void onStop()
    {
        super.onStop();
        YAPI.FreeAPI();
    }

}
 

18.7. Gestion des erreurs

Lorsque vous implémentez un programme qui doit interagir avec des modules USB, vous ne pouvez pas faire abstraction de la gestion des erreurs. Il y aura forcément une occasion où un utilisateur aura débranché le périphérique, soit avant de lancer le programme, soit même en pleine opération. La librairie Yoctopuce est prévue pour vous aider à supporter ce genre de comportements, mais votre code doit néanmoins être fait pour se comporter au mieux pour interpréter les erreurs signalées par la librairie.

La manière la plus simple de contourner le problème est celle que nous avons employé pour les petits exemples précédents de ce chapitre: avant d'accéder à un module, on vérifie qu'il est en ligne avec la méthode isOnline() et on suppose ensuite qu'il va y rester pendant la fraction de seconde nécessaire à exécuter les lignes de code suivantes. Ce n'est pas parfait, mais ça peut suffire dans certains cas. Il faut toutefois être conscient qu'on ne peut pas totalement exclure une erreur se produisant après le isOnline(), qui pourrait faire planter le programme.

Dans l'API java pour Android, le traitement d'erreur est implémenté au moyen d'exceptions. Vous devrez donc intercepter et traiter correctement ces exceptions si vous souhaitez avoir un projet fiable qui ne crashera pas des que vous débrancherez un module.

19. Programmation avancée

Les chapitres précédents vous ont présenté dans chaque language disponible les fonctions de programmation de base utilisables avec votre module Yocto-MaxiDisplay. Ce chapitre présente de façon plus générale une utilisation plus avancée de votre module. Les exemples sont donnés dans le language le plus populaire auprès des clients de Yoctopuce, à savoir C#. Néanmoins, vous trouverez dans les librairies de programmation pour chaque language des exemples complets illustrant les concepts présentés ici.

Afin de rester le plus concis possible, les exemples donnés dans ce chapitre ne font aucune gestion d'erreur. Ne les copiez pas tels-quels dans une application de production.

19.1. Programmation par événements

Les méthodes de gestion des modules Yoctopuce qui vous ont été présentées dans les chapitres précédents sont des fonctions de polling, qui consistent à demander en permanence à l'API si quelque chose a changé. Facile à appréhender, cette technique de programmation est n'est pas la plus efficace ni la plus réactive. C'est pourquoi l'API de programmation Yoctopuce propose aussi un modèle de programmation par événements. Cette technique consiste à demander à l'API de signaler elle-même les changements importants dès qu'ils sont détectés. A chaque fois qu'un paramètre clé change, l'API appelle une fonction de callback que vous avez prédéfinie.

Détecter l'arrivée et le départ des modules

La gestion du hot-plug est importante lorsque l'on travaille avec des modules USB, car tôt ou tard vous serez amené à brancher et débrancher un module après le lancement de votre programme. L'API a été conçue pour gérer l'arrivée et le départ inopinés des modules de manière transparente, mais votre application doit en général en tenir compte si elle veut éviter de prétendre utiliser un module qui a été débranché.

La programmation par événements est particulièrement utile pour détecter les branchements/débranchements de modules. Il est en effet plus simple de se faire signaler les branchements, que de devoir lister en permanence les modules branchés pour en déduire ceux qui sont arrivés et ceux qui sont partis. Pour pouvoir être prévenu dès qu'un module arrive, vous avez besoin de trois morceaux de code.

Le callback

Le callback est la fonction qui sera appelée à chaque fois qu'un nouveau module Yoctopuce sera branché. Elle prend en paramètre le module concerné.


 static void deviceArrival(YModule m)
 {
     Console.WriteLine("Nouveau module  : " + m.get_serialNumber());
 }

L'initialisation

Vous devez ensuite signaler à l'API qu'il faut appeler votre callback quand un nouveau module est branché.


  YAPI.RegisterDeviceArrivalCallback(deviceArrival);

Notez que si des modules sont déjà branchés lorsque le callback est enregistré, le callback sera appelé pour chacun de ces modules déjà branchés.

Déclenchement des callbacks

Un problème classique de la programmation par callbacks est que ces callbacks peuvent être appelés n'importe quand, y compris à des moments où le programme principal n'est pas prêt à les recevoir, ce qui peut avoir des effets de bords indésirables comme des dead-locks et autres conditions de course. C'est pourquoi dans l'API Yoctopuce, les callbacks d'arrivée/départs de modules ne sont appelés que pendant l'exécution de la fonction UpdateDeviceList(). Il vous suffit d'appeler UpdateDeviceList() à intervalle régulier depuis un timer ou un thread spécifique pour controller précisément quand les appels à ces callbacks auront lieu:


// boucle d'attente gérant les callback
while (true)
{  
    // callback d'arrivée / départ de modules
    YAPI.UpdateDeviceList(ref errmsg);
    // attente non active gérant les autres callbacks
    YAPI.Sleep(500, ref errmsg);
}

De manière similaire, il est possible d'avoir un callback quand un module est débranché. Vous trouverez un exemple concret démontrant toutes ces techniques dans la librairie de programmation Yoctopuce de chaque langage. L'exemple se trouve dans le répertoire Examples/Prog-EventBased.

Attention: dans la plupart des langages, les callbacks doivent être des procédures globales, et non pas des méthodes. Si vous souhaitez que le callback appelle une méthode d'un objet, définissez votre callback sous la forme d'une procédure globale qui ensuite appellera votre méthode.

20. 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é.

20.1. 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.

20.2. Virtual Hub et HTTP GET

Le Virtual Hub est disponible pour presque toutes les plateformes actuelles, il sert généralement de passerelle pour permettre l'accès aux modules Yoctopuce depuis des langages qui interdisent l'accès direct aux couches matérielles d'un ordinateur (Javascript, PHP, Java...).

Il se trouve que le Virtual Hub est en fait un petit serveur Web qui est capable de router des requêtes HTTP vers les modules Yoctopuce. Ce qui signifie que si vous pouvez faire une requête HTTP depuis votre langage de programmation, vous pouvez contrôler des modules Yoctopuce, même si ce langage n'est pas officiellement supporté.

Interface REST

A bas niveau, les modules sont pilotés à l'aide d'une API REST. Ainsi pour contrôler un module, il suffit de faire les requêtes HTTP appropriées sur le Virtual Hub. Par défaut le port HTTP du Virtual Hub est 4444.

Un des gros avantages de cette technique est que les tests préliminaires sont très faciles à mettre en œuvre, il suffit d'un Virtual Hub et d'un simple browser Web. Ainsi, si vous copiez l'URL suivante dans votre browser favori, alors que le Virtual Hub est en train de tourner, vous obtiendrez la liste des modules présents.


http://127.0.0.1:4444/api/services/whitePages.txt

Remarquez que le résultat est présenté sous forme texte, mais en demandant whitePages.xml vous auriez obtenu le résultat en XML. De même, whitePages.json aurait permis d'obtenir le résultat en JSON. L'extension html vous permet même d'afficher une interface sommaire vous permettant de changer les valeurs en direct. Toute l'API REST est disponible dans ces différents formats.

Contrôle d'un module par l'interface REST

Chaque module Yoctopuce a sa propre interface REST disponible sous différentes formes. Imaginons un Yocto-MaxiDisplay avec le numéro de de série YD128X64-12345 et le nom logique monModule. l'URL suivante permettra de connaître l'état du module.


http://127.0.0.1:4444/bySerial/YD128X64-12345/api/module.txt

Il est bien entendu possible d'utiliser le nom logique des modules plutôt que leur numéro de série.


http://127.0.0.1:4444/byName/monModule/api/module.txt

Vous pouvez retrouver la valeur d'une des propriétés d'un module, il suffit d'ajouter le nom de la propriété en dessous de module. Par exemple, si vous souhaitez connaître la luminosité des LEDs de signalisation, il vous suffit de faire la requête suivante:


http://127.0.0.1:4444/bySerial/YD128X64-12345/api/module/luminosity

Pour modifier la valeur d'une propriété, il vous suffit de modifier l'attribut correspondant. Ainsi, pour modifier la luminosité il vous suffit de faire la requête suivante:


http://127.0.0.1:4444/bySerial/YD128X64-12345/api/module?luminosity=100

Contrôle des différentes fonctions du module par l'interface REST

Les fonctionnalités des modules se manipulent de la même manière. Pour connaître l'état de la fonction display, il suffit de construire l'URL suivante.


http://127.0.0.1:4444/bySerial/YD128X64-12345/api/display.txt

En revanche, si vous pouvez utiliser le nom logique du module en lieu et place de son numéro de série, vous ne pouvez pas utiliser les noms logiques des fonctions, seuls les noms hardware sont autorisés pour les fonctions.

Vous pouvez retrouver un attribut d'une fonction d'un module d'une manière assez similaire à celle utilisée avec les modules, par exemple:


http://127.0.0.1:4444/bySerial/YD128X64-12345/api/display/logicalName

Assez logiquement, les attributs peuvent être modifiés de la même manière.


http://127.0.0.1:4444/bySerial/YD128X64-12345/api/display?logicalName=maFonction

Vous trouverez la liste des attributs disponibles pour votre Yocto-MaxiDisplay au début du chapitre Programmation, concepts généraux.

Accès aux données enregistrées sur le datalogger par l'interface REST

Cette section s'applique uniquement aux modules dotés d'un enregistreur de donnée.

La version résumée des données enregistrées dans le datalogger peut être obtenue au format JSON à l'aide de l'URL suivante:


http://127.0.0.1:4444/bySerial/YD128X64-12345/dataLogger.json

Le détail de chaque mesure pour un chaque tranche d'enregistrement peut être obtenu en ajoutant à l'URL l'identifiant de la fonction désirée et l'heure de départ de la tranche:


http://127.0.0.1:4444/bySerial/YD128X64-12345/dataLogger.json?id=display&utc=1389801080

20.3. Utilisation des librairies dynamiques

L'API Yoctopuce bas niveau est disponible sous différents formats de librairie dynamiques écrites en C, dont les sources sont disponibles avec l'API C++. Utiliser une de ces librairies bas niveau vous permettra de vous passer du Virtual Hub.

FilenamePlateforme
libyapi.dylibMax OS X
libyapi-amd64.soLinux Intel (64 bits)
libyapi-armel.soLinux ARM EL
libyapi-armhf.soLinux ARM HL
libyapi-i386.soLinux Intel (32 bits)
yapi64.dllWindows (64 bits)
yapi.dllWindows (32 bits)

Ces librairies dynamiques contiennent toutes les fonctionnalités nécessaires pour reconstruire entièrement toute l'API haut niveau dans n'importe quel langage capable d'intégrer ces librairies. Ce chapitre se limite cependant à décrire une utilisation de base des modules.

Contrôle d'un module

Les trois fonctions essentielles de l'API bas niveau sont les suivantes:


int yapiInitAPI(int connection_type, char *errmsg);
int yapiUpdateDeviceList(int forceupdate, char *errmsg);
int yapiHTTPRequest(char *device, char *request, char* buffer,int buffsize,int *fullsize, char *errmsg);

La fonction yapiInitAPI permet d'initialiser l'API et doit être appelée une fois en début du programme. Pour une connection de type USB, le paramètre connection_type doit prendre la valeur 1. errmsg est un pointeur sur un buffer de 255 caractères destiné à récupérer un éventuel message d'erreur. Ce pointeur peut être aussi mis à NULL. La fonction retourne un entier négatif en cas d'erreur, ou zéro dans le cas contraire.

La fonction yapiUpdateDeviceList gère l'inventaire des modules Yoctopuce connectés, elle doit être appelée au moins une fois. Pour pouvoir gérer le hot plug, et détecter d'éventuels nouveaux modules connectés, cette fonction devra être apellée à intervalles réguliers. Le paramètre forceupdate devra être à la valeur 1 pour forcer un scan matériel. Le paramètre errmsg devra pointer sur un buffer de 255 caractères pour récupérer un éventuel message d'erreur. Ce pointeur peut aussi être à null.Cette fonction retourne un entier négatif en cas d'erreur, ou zéro dans le cas contraire.

Enfin, la fonction yapiHTTPRequest permet d'envoyer des requêtes HTTP à l'API REST du module. Le paramètre device devra contenir le numéro de série ou le nom logique du module que vous cherchez à atteindre. Le paramètre request doit contenir la requête HTTP complète (y compris les sauts de ligne terminaux). buffer doit pointer sur un buffer de caractères suffisamment grand pour contenir la réponse. buffsize doit contenir la taille du buffer. fullsize est un pointeur sur un entier qui sera affecté à la taille effective de la réponse. Le paramètre errmsg devra pointer sur un buffer de 255 caractères pour récupérer un éventuel message d'erreur. Ce pointeur peut aussi être à null. Cette fonction retourne un entier négatif en cas d'erreur, ou zéro dans le cas contraire.

Le format des requêtes est le même que celui décrit dans la section Virtual Hub et HTTP GET. Toutes les chaînes de caractères utilisées par l'API sont des chaînes constituées de caractères 8 bits: l'Unicode et l'UTF8 ne sont pas supportés.

Le résultat retourné dans la variable buffer respecte le protocole HTTP, il inclut donc un header HTTP . Ce header se termine par deux lignes vides, c'est-à-dire une séquence de quatre caractères ASCII 13, 10, 13, 10.

Voici un programme d'exemple écrit en pascal qui utilise la DLL yapi.dll pour lire puis changer la luminosité d'un module.


// Dll functions import
function  yapiInitAPI(mode:integer;
                      errmsg : pansichar):integer;cdecl;
                      external 'yapi.dll' name 'yapiInitAPI';
function  yapiUpdateDeviceList(force:integer;errmsg : pansichar):integer;cdecl;
                      external 'yapi.dll' name 'yapiUpdateDeviceList';
function  yapiHTTPRequest(device:pansichar;url:pansichar; buffer:pansichar;
                      buffsize:integer;var fullsize:integer;
                      errmsg : pansichar):integer;cdecl;
                      external 'yapi.dll' name 'yapiHTTPRequest';

var
 errmsgBuffer  : array [0..256] of ansichar;
 dataBuffer    : array [0..1024] of ansichar;
 errmsg,data   : pansichar;
 fullsize,p    : integer;

const
  serial      = 'YD128X64-12345';
  getValue = 'GET /api/module/luminosity HTTP/1.1'#13#10#13#10;
  setValue = 'GET /api/module?luminosity=100 HTTP/1.1'#13#10#13#10;

begin
  errmsg  :=  @errmsgBuffer;
  data    :=  @dataBuffer;
  // API  initialization
  if(yapiInitAPI(1,errmsg)<0) then
   begin
    writeln(errmsg);
    halt;
  end;

  // forces a device inventory
  if( yapiUpdateDeviceList(1,errmsg)<0) then
    begin
     writeln(errmsg);
     halt;
   end;

  // requests the  module luminosity
  if (yapiHTTPRequest(serial,getValue,data,sizeof(dataBuffer),fullsize,errmsg)<0) then
   begin
     writeln(errmsg);
     halt;
   end;

  // searches for the HTTP header end
  p := pos(#13#10#13#10,data);

  // displays the response minus the HTTP header
  writeln(copy(data,p+4,length(data)-p-3));

  // change the luminosity
  if (yapiHTTPRequest(serial,setValue,data,sizeof(dataBuffer),fullsize,errmsg)<0) then
   begin
     writeln(errmsg);
     halt;
   end;

end.

Inventaire des modules

Pour procéder à l'inventaire des modules Yoctopuce, deux fonctions de la librairie dynamique sont nécessaires


 int yapiGetAllDevices(int *buffer,int maxsize,int *neededsize,char *errmsg);
 int yapiGetDeviceInfo(int devdesc,yDeviceSt *infos, char *errmsg);

La fonction yapiGetAllDevices permet d'obtenir la liste des modules connectés sous la forme d'une liste de handles. buffer pointe sur un tableau d'entiers 32 bits qui contiendra les handles retournés. Maxsize est la taille en bytes du buffer. neededsize contiendra au retour la taille nécessaire pour stocker tous les handles. Cela permet d'en déduire le nombre de module connectés, ou si le buffer passé en entrée est trop petit. Le paramètre errmsg devra pointer sur un buffer de 255 caractères pour récupérer un éventuel message d'erreur. Ce pointeur peut aussi être à null. Cette fonction retourne un entier négatif en cas d'erreur, ou zéro dans le cas contraire.

La fonction yapiGetDeviceInfo permet de récupérer les informations relatives à un module à partir de son handle. devdesc est un entier 32bit qui représente le module, et qui a été obtenu grâce à yapiGetAllDevices. infos pointe sur une structure de données dans laquelle sera stocké le résultat. Le format de cette structure est le suivant:

Nom TypeTaille (bytes)Description
vendorid int4ID USB de Yoctopuce
deviceid int4ID USB du module
devrelease int4Version du module
nbinbterfaces int4Nombre d'interfaces USB utilisée par le module
manufacturer char[]20Yoctopuce (null terminé)
productname char[]28Modèle (null terminé)
serial char[]20Numéro de série (null terminé)
logicalname char[]20Nom logique (null terminé)
firmware char[]22Version du firmware (null terminé)
beacon byte1Etat de la balise de localisation (0/1)

Le paramètre errmsg devra pointer sur un buffer de 255 caractères pour récupérer un éventuel message d'erreur.

Voici un programme d'exemple écrit en pascal qui utilise la DLL yapi.dll pour lister les modules connectés.


// device description structure
type yDeviceSt = packed record
   vendorid        : word;
   deviceid        : word;
   devrelease      : word;
   nbinbterfaces   : word;
   manufacturer    : array [0..19] of ansichar;
   productname     : array [0..27] of ansichar;
   serial          : array [0..19] of ansichar;
   logicalname     : array [0..19] of ansichar;
   firmware        : array [0..21] of ansichar;
   beacon          : byte;
 end;

// Dll function import
function  yapiInitAPI(mode:integer;
                      errmsg : pansichar):integer;cdecl;
                      external 'yapi.dll' name 'yapiInitAPI';

function  yapiUpdateDeviceList(force:integer;errmsg : pansichar):integer;cdecl;
                      external 'yapi.dll' name 'yapiUpdateDeviceList';

function  yapiGetAllDevices( buffer:pointer;
                             maxsize:integer;
                             var neededsize:integer;
                             errmsg : pansichar):integer; cdecl;
                             external 'yapi.dll' name 'yapiGetAllDevices';

function  apiGetDeviceInfo(d:integer; var infos:yDeviceSt;
                             errmsg : pansichar):integer;  cdecl;
                             external 'yapi.dll' name 'yapiGetDeviceInfo';


var
 errmsgBuffer  : array [0..256] of ansichar;
 dataBuffer    : array [0..127] of integer;   // max of 128 USB devices
 errmsg,data   : pansichar;
 neededsize,i  : integer;
 devinfos      : yDeviceSt;

begin
  errmsg  :=  @errmsgBuffer;

  // API  initialisation
  if(yapiInitAPI(1,errmsg)<0) then
   begin
    writeln(errmsg);
    halt;
  end;

   // forces a device inventory
  if( yapiUpdateDeviceList(1,errmsg)<0) then
    begin
     writeln(errmsg);
     halt;
   end;

  // loads all device handles into dataBuffer
  if yapiGetAllDevices(@dataBuffer,sizeof(dataBuffer),neededsize,errmsg)<0 then
    begin
     writeln(errmsg);
     halt;
    end;

  // gets device info from each handle
  for i:=0 to  neededsize div sizeof(integer)-1 do
   begin
     if (apiGetDeviceInfo(dataBuffer[i], devinfos, errmsg)<0) then
       begin
         writeln(errmsg);
         halt;
       end;
     writeln(pansichar(@devinfos.serial)+' ('+pansichar(@devinfos.productname)+')');
   end;

end.

20.4. Port de la librairie haut niveau

Toutes les sources de l'API Yoctopuce étant fournies dans leur intégralité, vous pouvez parfaitement entreprendre le port complet de l'API dans le langage de votre choix. Sachez cependant qu'une grande partie du code source de l'API est généré automatiquement.

Ainsi, il n'est pas nécessaire de porter la totalité de l'API, il suffit de porter le fichier yocto_api et un de ceux correspondant à une fonctionnalité, par exemple yocto_relay. Moyennant un peu de travail supplémentaire, Yoctopuce sera alors en mesure de générer tous les autres fichiers. C'est pourquoi il est fortement recommandé de contacter le support Yoctopuce avant d'entreprendre le port de la librairie Yoctopuce dans un autre langage. Un travail collaboratif sera profitable aux deux parties.

21. Référence de l'API de haut niveau

Ce chapitre résume les fonctions de l'API de haut niveau pour commander votre Yocto-MaxiDisplay. La syntaxe et les types précis peuvent varier d'un langage à l'autre mais, sauf avis contraire toutes sont disponibles dans chaque language. Pour une information plus précise sur les types des arguments et des valeurs de retour dans un langage donné, veuillez vous référer au fichier de définition pour ce langage (yocto_api.* ainsi que les autres fichiers yocto_* définissant les interfaces des fonctions).

Dans les langages qui supportent les exceptions, toutes ces fonctions vont par défaut générer des exceptions en cas d'erreur plutôt que de retourner la valeur d'erreur documentée pour chaque fonction, afin de faciliter le déboguage. Il est toutefois possible de désactiver l'utilisation d'exceptions à l'aide de la fonction yDisableExceptions(), si l'on préfère travailler avec des valeurs de retour d'erreur.

Ce chapitre ne reprend pas en détail les concepts de programmation décrits plus tôt, afin d'offrir une référence plus concise. En cas de doute, n'hésitez pas à retourner au chapitre décrivant en détail de chaque attribut configurable.

21.1. Fonctions générales

Ces quelques fonctions générales permettent l'initialisation et la configuration de la librairie Yoctopuce. Dans la plupart des cas, un appel à yRegisterHub() suffira en tout et pour tout. Ensuite, vous pourrez appeler la fonction globale yFind...() ou yFirst...() correspondant à votre module pour pouvoir interagir avec lui.

Pour utiliser les fonctions décrites ici, vous devez inclure:

js
<script type='text/javascript' src='yocto_api.js'></script>
nodejs
var yoctolib = require('yoctolib');
var YAPI = yoctolib.YAPI;
var YModule = yoctolib.YModule;
php
require_once('yocto_api.php');
cpp
#include "yocto_api.h"
m
#import "yocto_api.h"
pas
uses yocto_api;
vb
yocto_api.vb
cs
yocto_api.cs
java
import com.yoctopuce.YoctoAPI.YModule;
py
from yocto_api import *
Fonction globales
yCheckLogicalName(name)

Vérifie si un nom donné est valide comme nom logique pour un module ou une fonction.

yDisableExceptions()

Désactive l'utilisation d'exceptions pour la gestion des erreurs.

yEnableExceptions()

Réactive l'utilisation d'exceptions pour la gestion des erreurs.

yEnableUSBHost(osContext)

Cette fonction est utilisée uniquement sous Android.

yFreeAPI()

Libère la mémoire dynamique utilisée par la librairie Yoctopuce.

yGetAPIVersion()

Retourne la version de la librairie Yoctopuce utilisée.

yGetTickCount()

Retourne la valeur du compteur monotone de temps (en millisecondes).

yHandleEvents(errmsg)

Maintient la communication de la librairie avec les modules Yoctopuce.

yInitAPI(mode, errmsg)

Initialise la librairie de programmation de Yoctopuce explicitement.

yPreregisterHub(url, errmsg)

Alternative plus tolerante à RegisterHub().

yRegisterDeviceArrivalCallback(arrivalCallback)

Enregistre une fonction de callback qui sera appelée à chaque fois qu'un module est branché.

yRegisterDeviceRemovalCallback(removalCallback)

Enregistre une fonction de callback qui sera appelée à chaque fois qu'un module est débranché.

yRegisterHub(url, errmsg)

Configure la librairie Yoctopuce pour utiliser les modules connectés sur une machine donnée.

yRegisterHubDiscoveryCallback(callback)

Enregistre une fonction de callback qui sera appelée à chaque fois qu'un Hub réseau ou un VirtualHub est détecté sur le réseau local.

yRegisterLogFunction(logfun)

Enregistre une fonction de callback qui sera appellée à chaque fois que l'API a quelque chose à dire.

ySelectArchitecture(arch)

Sélectionne manuellement l'architecture de la libraire dynamique à utiliser pour accéder à USB.

ySetDelegate(object)

(Objective-C uniquement) Enregistre un objet délégué qui doit se conformer au procole YDeviceHotPlug.

ySetTimeout(callback, ms_timeout, arguments)

Appelle le callback spécifié après un temps d'attente spécifié.

ySleep(ms_duration, errmsg)

Effectue une pause dans l'exécution du programme pour une durée spécifiée.

yUnregisterHub(url)

Configure la librairie Yoctopuce pour ne plus utiliser les modules connectés sur une machine préalablement enregistrer avec RegisterHub.

yUpdateDeviceList(errmsg)

Force une mise-à-jour de la liste des modules Yoctopuce connectés.

yUpdateDeviceList_async(callback, context)

Force une mise-à-jour de la liste des modules Yoctopuce connectés.

YAPI.CheckLogicalName()
yCheckLogicalName()
yCheckLogicalName()YAPI.CheckLogicalName()yCheckLogicalName()yCheckLogicalName()yCheckLogicalName()yCheckLogicalName()yCheckLogicalName()YAPI.CheckLogicalName()YAPI.CheckLogicalName()YAPI.CheckLogicalName()

Vérifie si un nom donné est valide comme nom logique pour un module ou une fonction.

js
function yCheckLogicalName(name)
nodejs
function CheckLogicalName(name)
php
function yCheckLogicalName($name)
cpp
bool yCheckLogicalName(const string& name)
m
BOOL yCheckLogicalName(NSString * name)
pas
function yCheckLogicalName(name: string): boolean
vb
function yCheckLogicalName(ByVal name As String) As Boolean
cs
bool CheckLogicalName(string name)
java
boolean CheckLogicalName(String name)
py
def CheckLogicalName(name)

Un nom logique valide est formé de 19 caractères au maximum, choisis parmi A..Z, a..z, 0..9, _ et -. Lorsqu'on configure un nom logique avec une chaîne incorrecte, les caractères invalides sont ignorés.

Paramètres :

nameune chaîne de caractères contenant le nom vérifier.

Retourne :

true si le nom est valide, false dans le cas contraire.

YAPI.DisableExceptions()
yDisableExceptions()
yDisableExceptions()YAPI.DisableExceptions()yDisableExceptions()yDisableExceptions()yDisableExceptions()yDisableExceptions()yDisableExceptions()YAPI.DisableExceptions()YAPI.DisableExceptions()

Désactive l'utilisation d'exceptions pour la gestion des erreurs.

js
function yDisableExceptions()
nodejs
function DisableExceptions()
php
function yDisableExceptions()
cpp
void yDisableExceptions()
m
void yDisableExceptions()
pas
procedure yDisableExceptions()
vb
procedure yDisableExceptions()
cs
void DisableExceptions()
py
def DisableExceptions()

Lorsque les exceptions sont désactivées, chaque fonction retourne une valeur d'erreur spécifique selon son type, documentée dans ce manuel de référence.

YAPI.EnableExceptions()
yEnableExceptions()
yEnableExceptions()YAPI.EnableExceptions()yEnableExceptions()yEnableExceptions()yEnableExceptions()yEnableExceptions()yEnableExceptions()YAPI.EnableExceptions()YAPI.EnableExceptions()

Réactive l'utilisation d'exceptions pour la gestion des erreurs.

js
function yEnableExceptions()
nodejs
function EnableExceptions()
php
function yEnableExceptions()
cpp
void yEnableExceptions()
m
void yEnableExceptions()
pas
procedure yEnableExceptions()
vb
procedure yEnableExceptions()
cs
void EnableExceptions()
py
def EnableExceptions()

Attention, lorsque les exceptions sont activées, tout appel à une fonction de la librairie qui échoue déclenche une exception. Dans le cas où celle-ci n'est pas interceptée correctement par le code appelant, soit le debugger se lance, soit le programme de l'utilisateur est immédiatement stoppé (crash).

YAPI.EnableUSBHost()
yEnableUSBHost()
YAPI.EnableUSBHost()

Cette fonction est utilisée uniquement sous Android.

java
synchronized static void EnableUSBHost(Object osContext)

Avant d'appeler yRegisterHub("usb") il faut activer le port USB host du systeme. Cette fonction prend en argument un objet de la classe android.content.Context (ou d'une sous-classe). Il n'est pas nécessaire d'appeler cette fonction pour accéder au modules à travers le réseau.

Paramètres :

En cas d'erreur, déclenche une exception
osContextun objet de classe android.content.Context (ou une sous-classe)

YAPI.FreeAPI()
yFreeAPI()
yFreeAPI()YAPI.FreeAPI()yFreeAPI()yFreeAPI()yFreeAPI()yFreeAPI()yFreeAPI()YAPI.FreeAPI()YAPI.FreeAPI()YAPI.FreeAPI()

Libère la mémoire dynamique utilisée par la librairie Yoctopuce.

js
function yFreeAPI()
nodejs
function FreeAPI()
php
function yFreeAPI()
cpp
void yFreeAPI()
m
void yFreeAPI()
pas
procedure yFreeAPI()
vb
procedure yFreeAPI()
cs
void FreeAPI()
java
synchronized static void FreeAPI()
py
def FreeAPI()

Il n'est en général pas nécessaire d'appeler cette fonction, sauf si vous désirez libérer tous les blocs de mémoire alloués dynamiquement dans le but d'identifier une source de blocs perdus par exemple. Vous ne devez plus appeler aucune fonction de la librairie après avoir appelé yFreeAPI(), sous peine de crash.

YAPI.GetAPIVersion()
yGetAPIVersion()
yGetAPIVersion()YAPI.GetAPIVersion()yGetAPIVersion()yGetAPIVersion()yGetAPIVersion()yGetAPIVersion()yGetAPIVersion()YAPI.GetAPIVersion()YAPI.GetAPIVersion()YAPI.GetAPIVersion()

Retourne la version de la librairie Yoctopuce utilisée.

js
function yGetAPIVersion()
nodejs
function GetAPIVersion()
php
function yGetAPIVersion()
cpp
string yGetAPIVersion()
m
NSString* yGetAPIVersion()
pas
function yGetAPIVersion(): string
vb
function yGetAPIVersion() As String
cs
String GetAPIVersion()
java
String GetAPIVersion()
py
def GetAPIVersion()

La version est retournée sous forme d'une chaîne de caractères au format "Majeure.Mineure.NoBuild", par exemple "1.01.5535". Pour les langages utilisant une DLL externe (par exemple C#, VisualBasic ou Delphi), la chaîne contient en outre la version de la DLL au même format, par exemple "1.01.5535 (1.01.5439)".

Si vous désirez vérifier dans votre code que la version de la librairie est compatible avec celle que vous avez utilisé durant le développement, vérifiez que le numéro majeur soit strictement égal et que le numéro mineur soit égal ou supérieur. Le numéro de build n'est pas significatif par rapport à la compatibilité de la librairie.

Retourne :

une chaîne de caractères décrivant la version de la librairie.

YAPI.GetTickCount()
yGetTickCount()
yGetTickCount()YAPI.GetTickCount()yGetTickCount()yGetTickCount()yGetTickCount()yGetTickCount()yGetTickCount()YAPI.GetTickCount()YAPI.GetTickCount()YAPI.GetTickCount()

Retourne la valeur du compteur monotone de temps (en millisecondes).

js
function yGetTickCount()
nodejs
function GetTickCount()
php
function yGetTickCount()
cpp
u64 yGetTickCount()
m
u64 yGetTickCount()
pas
function yGetTickCount(): u64
vb
function yGetTickCount() As Long
cs
ulong GetTickCount()
java
long GetTickCount()
py
def GetTickCount()

Ce compteur peut être utilisé pour calculer des délais en rapport avec les modules Yoctopuce, dont la base de temps est aussi la milliseconde.

Retourne :

un long entier contenant la valeur du compteur de millisecondes.

YAPI.HandleEvents()
yHandleEvents()
yHandleEvents()YAPI.HandleEvents()yHandleEvents()yHandleEvents()yHandleEvents()yHandleEvents()yHandleEvents()YAPI.HandleEvents()YAPI.HandleEvents()YAPI.HandleEvents()

Maintient la communication de la librairie avec les modules Yoctopuce.

js
function yHandleEvents(errmsg)
nodejs
function HandleEvents(errmsg)
php
function yHandleEvents(&$errmsg)
cpp
YRETCODE yHandleEvents(string& errmsg)
m
YRETCODE yHandleEvents(NSError** errmsg)
pas
function yHandleEvents(var errmsg: string): integer
vb
function yHandleEvents(ByRef errmsg As String) As YRETCODE
cs
YRETCODE HandleEvents(ref string errmsg)
java
int HandleEvents()
py
def HandleEvents(errmsg=None)

Si votre programme inclut des longues boucles d'attente, vous pouvez y inclure un appel à cette fonction pour que la librairie prenne en charge les informations mise en attente par les modules sur les canaux de communication. Ce n'est pas strictement indispensable mais cela peut améliorer la réactivité des la librairie pour les commandes suivantes.

Cette fonction peut signaler une erreur au cas à la communication avec un module Yoctopuce ne se passerait pas comme attendu.

Paramètres :

errmsgune chaîne de caractères passée par référence, dans laquelle sera stocké un éventuel message d'erreur.

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

YAPI.InitAPI()
yInitAPI()
yInitAPI()YAPI.InitAPI()yInitAPI()yInitAPI()yInitAPI()yInitAPI()yInitAPI()YAPI.InitAPI()YAPI.InitAPI()YAPI.InitAPI()

Initialise la librairie de programmation de Yoctopuce explicitement.

js
function yInitAPI(mode, errmsg)
nodejs
function InitAPI(mode, errmsg)
php
function yInitAPI($mode, &$errmsg)
cpp
YRETCODE yInitAPI(int mode, string& errmsg)
m
YRETCODE yInitAPI(int mode, NSError** errmsg)
pas
function yInitAPI(mode: integer, var errmsg: string): integer
vb
function yInitAPI(ByVal mode As Integer, ByRef errmsg As String) As Integer
cs
int InitAPI(int mode, ref string errmsg)
java
synchronized static int InitAPI(int mode)
py
def InitAPI(mode, errmsg=None)

Il n'est pas indispensable d'appeler yInitAPI(), la librairie sera automatiquement initialisée de toute manière au premier appel à yRegisterHub().

Lorsque cette fonctin est utilisée avec comme mode la valeur Y_DETECT_NONE, il faut explicitement appeler yRegisterHub() pour indiquer à la librairie sur quel VirtualHub les modules sont connectés, avant d'essayer d'y accéder.

Paramètres :

modeun entier spécifiant le type de détection automatique de modules à utiliser. Les valeurs possibles sont Y_DETECT_NONE, Y_DETECT_USB, Y_DETECT_NET et Y_DETECT_ALL.
errmsgune chaîne de caractères passée par référence, dans laquelle sera stocké un éventuel message d'erreur.

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

YAPI.PreregisterHub()
yPreregisterHub()
yPreregisterHub()YAPI.PreregisterHub()yPreregisterHub()yPreregisterHub()yPreregisterHub()yPreregisterHub()yPreregisterHub()YAPI.PreregisterHub()YAPI.PreregisterHub()YAPI.PreregisterHub()

Alternative plus tolerante à RegisterHub().

js
function yPreregisterHub(url, errmsg)
nodejs
function PreregisterHub(url, errmsg)
php
function yPreregisterHub($url, &$errmsg)
cpp
YRETCODE yPreregisterHub(const string& url, string& errmsg)
m
YRETCODE yPreregisterHub(NSString * url, NSError** errmsg)
pas
function yPreregisterHub(url: string, var errmsg: string): integer
vb
function yPreregisterHub(ByVal url As String,
  ByRef errmsg As String) As Integer
cs
int PreregisterHub(string url, ref string errmsg)
java
synchronized static int PreregisterHub(String url)
py
def PreregisterHub(url, errmsg=None)

Cette fonction a le même but et la même paramètres que la fonction RegisterHub, mais contrairement à celle-ci PreregisterHub() ne déclanche pas d'erreur si le hub choisi n'est pas joignable au moment de l'appel. Il est ainsi possible d'enregistrer un hub réseau indépendemment de la connectivité, afin de tenter de ne le contacter que lorsqu'on cherche réellement un module.

Paramètres :

urlune chaîne de caractères contenant "usb","callback", ou l'URL racine du VirtualHub à utiliser.
errmsgune chaîne de caractères passée par référence, dans laquelle sera stocké un éventuel message d'erreur.

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

YAPI.RegisterDeviceArrivalCallback()
yRegisterDeviceArrivalCallback()
yRegisterDeviceArrivalCallback()YAPI.RegisterDeviceArrivalCallback()yRegisterDeviceArrivalCallback()yRegisterDeviceArrivalCallback()yRegisterDeviceArrivalCallback()yRegisterDeviceArrivalCallback()yRegisterDeviceArrivalCallback()YAPI.RegisterDeviceArrivalCallback()YAPI.RegisterDeviceArrivalCallback()YAPI.RegisterDeviceArrivalCallback()

Enregistre une fonction de callback qui sera appelée à chaque fois qu'un module est branché.

js
function yRegisterDeviceArrivalCallback(arrivalCallback)
nodejs
function RegisterDeviceArrivalCallback(arrivalCallback)
php
function yRegisterDeviceArrivalCallback($arrivalCallback)
cpp
void yRegisterDeviceArrivalCallback(yDeviceUpdateCallback arrivalCallback)
m
void yRegisterDeviceArrivalCallback(yDeviceUpdateCallback arrivalCallback)
pas
procedure yRegisterDeviceArrivalCallback(arrivalCallback: yDeviceUpdateFunc)
vb
procedure yRegisterDeviceArrivalCallback(ByVal arrivalCallback As yDeviceUpdateFunc)
cs
void RegisterDeviceArrivalCallback(yDeviceUpdateFunc arrivalCallback)
java
synchronized static void RegisterDeviceArrivalCallback(DeviceArrivalCallback arrivalCallback)
py
def RegisterDeviceArrivalCallback(arrivalCallback)

Le callback sera appelé pendant l'éxecution de la fonction yHandleDeviceList, que vous devrez appeler régulièrement.

Paramètres :

pour supprimer un callback déja enregistré.
arrivalCallbackune procédure qui prend un YModule en paramètre, ou null

YAPI.RegisterDeviceRemovalCallback()
yRegisterDeviceRemovalCallback()
yRegisterDeviceRemovalCallback()YAPI.RegisterDeviceRemovalCallback()yRegisterDeviceRemovalCallback()yRegisterDeviceRemovalCallback()yRegisterDeviceRemovalCallback()yRegisterDeviceRemovalCallback()yRegisterDeviceRemovalCallback()YAPI.RegisterDeviceRemovalCallback()YAPI.RegisterDeviceRemovalCallback()YAPI.RegisterDeviceRemovalCallback()

Enregistre une fonction de callback qui sera appelée à chaque fois qu'un module est débranché.

js
function yRegisterDeviceRemovalCallback(removalCallback)
nodejs
function RegisterDeviceRemovalCallback(removalCallback)
php
function yRegisterDeviceRemovalCallback($removalCallback)
cpp
void yRegisterDeviceRemovalCallback(yDeviceUpdateCallback removalCallback)
m
void yRegisterDeviceRemovalCallback(yDeviceUpdateCallback removalCallback)
pas
procedure yRegisterDeviceRemovalCallback(removalCallback: yDeviceUpdateFunc)
vb
procedure yRegisterDeviceRemovalCallback(ByVal removalCallback As yDeviceUpdateFunc)
cs
void RegisterDeviceRemovalCallback(yDeviceUpdateFunc removalCallback)
java
synchronized static void RegisterDeviceRemovalCallback(DeviceRemovalCallback removalCallback)
py
def RegisterDeviceRemovalCallback(removalCallback)

Le callback sera appelé pendant l'éxecution de la fonction yHandleDeviceList, que vous devrez appeler régulièrement.

Paramètres :

pour supprimer un callback déja enregistré.
removalCallbackune procédure qui prend un YModule en paramètre, ou null

YAPI.RegisterHub()
yRegisterHub()
yRegisterHub()YAPI.RegisterHub()yRegisterHub()yRegisterHub()yRegisterHub()yRegisterHub()yRegisterHub()YAPI.RegisterHub()YAPI.RegisterHub()YAPI.RegisterHub()

Configure la librairie Yoctopuce pour utiliser les modules connectés sur une machine donnée.

js
function yRegisterHub(url, errmsg)
nodejs
function RegisterHub(url, errmsg)
php
function yRegisterHub($url, &$errmsg)
cpp
YRETCODE yRegisterHub(const string& url, string& errmsg)
m
YRETCODE yRegisterHub(NSString * url, NSError** errmsg)
pas
function yRegisterHub(url: string, var errmsg: string): integer
vb
function yRegisterHub(ByVal url As String,
  ByRef errmsg As String) As Integer
cs
int RegisterHub(string url, ref string errmsg)
java
synchronized static int RegisterHub(String url)
py
def RegisterHub(url, errmsg=None)

Le premier paramètre détermine le fonctionnement de l'API, il peut prendre les valeurs suivantes:

usb: Si vous utilisez le mot-clé usb, l'API utilise les modules Yoctopuce connectés directement par USB. Certains languages comme PHP, Javascript et Java ne permettent pas un accès direct aux couches matérielles, usb ne marchera donc pas avec ces languages. Dans ce cas, utilisez un VirtualHub ou un YoctoHub réseau (voir ci-dessous).

x.x.x.x ou hostname: L'API utilise les modules connectés à la machine dont l'adresse IP est x.x.x.x, ou dont le nom d'hôte DNS est hostname. Cette machine peut être un ordinateur classique faisant tourner un VirtualHub, ou un YoctoHub avec réseau (YoctoHub-Ethernet / YoctoHub-Wireless). Si vous désirez utiliser le VirtualHub tournant sur votre machine locale, utilisez l'adresse IP 127.0.0.1.

callback Le mot-clé callback permet de faire fonctionnner l'API dans un mode appélé "callback HTTP". C'est un mode spécial permettant, entre autres, de prendre le contrôle de modules Yoctopuce à travers un filtre NAT par l'intermédiaire d'un VirtualHub ou d'un Hub Yoctopuce. Il vous suffit de configuer le hub pour qu'il appelle votre script à intervalle régulier. Ce mode de fonctionnement n'est disponible actuellement qu'en PHP et en Node.JS.

Attention, seule une application peut fonctionner à la fois sur une machine donnée en accès direct à USB, sinon il y aurait un conflit d'accès aux modules. Cela signifie en particulier que vous devez stopper le VirtualHub avant de lancer une application utilisant l'accès direct à USB. Cette limitation peut être contournée en passant par un VirtualHub plutôt que d'utiliser directement USB.

Si vous désirez vous connecter à un Hub, virtuel ou non, sur lequel le controle d'accès a été activé, vous devez donner le paramètre url sous la forme:

http://nom:mot_de_passe@adresse:port

Vous pouvez appeller RegisterHub plusieurs fois pour vous connecter à plusieurs machines différentes.

Paramètres :

urlune chaîne de caractères contenant "usb","callback", ou l'URL racine du VirtualHub à utiliser.
errmsgune chaîne de caractères passée par référence, dans laquelle sera stocké un éventuel message d'erreur.

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

YAPI.RegisterHubDiscoveryCallback()
yRegisterHubDiscoveryCallback()
YAPI.RegisterHubDiscoveryCallback()

Enregistre une fonction de callback qui sera appelée à chaque fois qu'un Hub réseau ou un VirtualHub est détecté sur le réseau local.

java
void RegisterHubDiscoveryCallback(NewHubCallback callback)

Paramètres :

pour supprimer un callback déjà enregistré
callbackune procédure qui prend en paramètre deux chaîne de caractères ou null

YAPI.RegisterLogFunction()
yRegisterLogFunction()
yRegisterLogFunction()yRegisterLogFunction()yRegisterLogFunction()yRegisterLogFunction()YAPI.RegisterLogFunction()YAPI.RegisterLogFunction()YAPI.RegisterLogFunction()

Enregistre une fonction de callback qui sera appellée à chaque fois que l'API a quelque chose à dire.

cpp
void yRegisterLogFunction(yLogFunction logfun)
m
void yRegisterLogFunction(yLogCallback logfun)
pas
procedure yRegisterLogFunction(logfun: yLogFunc)
vb
procedure yRegisterLogFunction(ByVal logfun As yLogFunc)
cs
void RegisterLogFunction(yLogFunc logfun)
java
void RegisterLogFunction(LogCallback logfun)
py
def RegisterLogFunction(logfun)

Utile pour débugger le fonctionnement de l'API.

Paramètres :

ou null pour supprimer un callback déja enregistré.
logfunune procedure qui prend une chaîne de caractère en paramètre,

YAPI.SelectArchitecture()
ySelectArchitecture()
YAPI.SelectArchitecture()

Sélectionne manuellement l'architecture de la libraire dynamique à utiliser pour accéder à USB.

py
def SelectArchitecture(arch)

Par défaut, la libraire Python détecte automatiquement la version de la libraire dynamique à utiliser pour accéder au port USB. Sous Linux ARM il n'est pas possible de détecter de manière fiable si il s'agit d'une installation Soft float (armel) ou Hard float (armhf). Dans ce cas, il est donc recommendé d'appeler SelectArchitecture() avant tout autre appel à la librairie pour forcer l'utilisation d'une architecture spécifiée.

Paramètres :

archune chaîne de caractère spécifiant l'architecture à utiliser. Les valeurs possibles sont "armhf","armel", "i386","x86_64","32bit", "64bit"

Retourne :

rien. En cas d'erreur, déclenche une exception.

YAPI.SetDelegate()
ySetDelegate()
ySetDelegate()

(Objective-C uniquement) Enregistre un objet délégué qui doit se conformer au procole YDeviceHotPlug.

m
void ySetDelegate(id object)

Les methodes yDeviceArrival et yDeviceRemoval seront appelées pendant l'éxecution de la fonction yHandleDeviceList, que vous devrez appeler régulièrement.

Paramètres :

pour supprimer un objet déja enregistré.
objectun objet qui soit se conformer au procol YAPIDelegate, ou nil

YAPI.SetTimeout()
ySetTimeout()
ySetTimeout()YAPI.SetTimeout()

Appelle le callback spécifié après un temps d'attente spécifié.

js
function ySetTimeout(callback, ms_timeout, arguments)
nodejs
function SetTimeout(callback, ms_timeout, arguments)

Cette fonction se comporte plus ou moins comme la fonction Javascript setTimeout, mais durant le temps d'attente, elle va appeler yHandleEvents et yUpdateDeviceList périodiquement pour maintenir l'API à jour avec les modules connectés.

Paramètres :

callbackla fonction à appeler lorsque le temps d'attente est écoulé. Sous Microsoft Internet Explorer, le callback doit être spécifié sous forme d'une string à évaluer.
ms_timeoutun entier correspondant à la durée de l'attente, en millisecondes
argumentsdes arguments supplémentaires peuvent être fournis, pour être passés à la fonction de callback si nécessaire (pas supporté sous Microsoft Internet Explorer).

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

YAPI.Sleep()
ySleep()
ySleep()YAPI.Sleep()ySleep()ySleep()ySleep()ySleep()ySleep()YAPI.Sleep()YAPI.Sleep()YAPI.Sleep()

Effectue une pause dans l'exécution du programme pour une durée spécifiée.

js
function ySleep(ms_duration, errmsg)
nodejs
function Sleep(ms_duration, errmsg)
php
function ySleep($ms_duration, &$errmsg)
cpp
YRETCODE ySleep(unsigned ms_duration, string& errmsg)
m
YRETCODE ySleep(unsigned ms_duration, NSError ** errmsg)
pas
function ySleep(ms_duration: integer, var errmsg: string): integer
vb
function ySleep(ByVal ms_duration As Integer,
  ByRef errmsg As String) As Integer
cs
int Sleep(int ms_duration, ref string errmsg)
java
int Sleep(long ms_duration)
py
def Sleep(ms_duration, errmsg=None)

L'attente est passive, c'est-à-dire qu'elle n'occupe pas significativement le processeur, de sorte à le laisser disponible pour les autres processus fonctionnant sur la machine. Durant l'attente, la librairie va néanmoins continuer à lire périodiquement les informations en provenance des modules Yoctopuce en appelant la fonction yHandleEvents() afin de se maintenir à jour.

Cette fonction peut signaler une erreur au cas à la communication avec un module Yoctopuce ne se passerait pas comme attendu.

Paramètres :

ms_durationun entier correspondant à la durée de la pause, en millisecondes
errmsgune chaîne de caractères passée par référence, dans laquelle sera stocké un éventuel message d'erreur.

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

YAPI.UnregisterHub()
yUnregisterHub()
yUnregisterHub()YAPI.UnregisterHub()yUnregisterHub()yUnregisterHub()yUnregisterHub()yUnregisterHub()yUnregisterHub()YAPI.UnregisterHub()YAPI.UnregisterHub()YAPI.UnregisterHub()

Configure la librairie Yoctopuce pour ne plus utiliser les modules connectés sur une machine préalablement enregistrer avec RegisterHub.

js
function yUnregisterHub(url)
nodejs
function UnregisterHub(url)
php
function yUnregisterHub($url)
cpp
void yUnregisterHub(const string& url)
m
void yUnregisterHub(NSString * url)
pas
procedure yUnregisterHub(url: string)
vb
procedure yUnregisterHub(ByVal url As String)
cs
void UnregisterHub(string url)
java
synchronized static void UnregisterHub(String url)
py
def UnregisterHub(url)

Paramètres :

l'URL racine du VirtualHub à ne plus utiliser.
urlune chaîne de caractères contenant "usb" ou

YAPI.UpdateDeviceList()
yUpdateDeviceList()
yUpdateDeviceList()YAPI.UpdateDeviceList()yUpdateDeviceList()yUpdateDeviceList()yUpdateDeviceList()yUpdateDeviceList()yUpdateDeviceList()YAPI.UpdateDeviceList()YAPI.UpdateDeviceList()YAPI.UpdateDeviceList()

Force une mise-à-jour de la liste des modules Yoctopuce connectés.

js
function yUpdateDeviceList(errmsg)
nodejs
function UpdateDeviceList(errmsg)
php
function yUpdateDeviceList(&$errmsg)
cpp
YRETCODE yUpdateDeviceList(string& errmsg)
m
YRETCODE yUpdateDeviceList(NSError** errmsg)
pas
function yUpdateDeviceList(var errmsg: string): integer
vb
function yUpdateDeviceList(ByRef errmsg As String) As YRETCODE
cs
YRETCODE UpdateDeviceList(ref string errmsg)
java
int UpdateDeviceList()
py
def UpdateDeviceList(errmsg=None)

La librairie va vérifier sur les machines ou ports USB précédemment enregistrés en utilisant la fonction yRegisterHub si un module a été connecté ou déconnecté, et le cas échéant appeler les fonctions de callback définies par l'utilisateur.

Cette fonction peut être appelée aussi souvent que désiré, afin de rendre l'application réactive aux événements de hot-plug.

Paramètres :

errmsgune chaîne de caractères passée par référence, dans laquelle sera stocké un éventuel message d'erreur.

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

YAPI.UpdateDeviceList_async()
yUpdateDeviceList_async()
yUpdateDeviceList_async()YAPI.UpdateDeviceList_async()

Force une mise-à-jour de la liste des modules Yoctopuce connectés.

js
function yUpdateDeviceList_async(callback, context)
nodejs
function UpdateDeviceList_async(callback, context)

La librairie va vérifier sur les machines ou ports USB précédemment enregistrés en utilisant la fonction yRegisterHub si un module a été connecté ou déconnecté, et le cas échéant appeler les fonctions de callback définies par l'utilisateur.

Cette fonction peut être appelée aussi souvent que désiré, afin de rendre l'application réactive aux événements de hot-plug.

Cette version asynchrone n'existe qu'en Javascript. Elle utilise une fonction de callback plutôt qu'une simple valeur de retour, pour éviter de bloquer la VM Javascript de Firefox, qui n'implémente pas le passage de contrôle entre threads durant les appels d'entrée/sortie bloquants.

Paramètres :

callbackfonction de callback qui sera appelée dès que le résultat sera connu. La fonction callback reçoit deux arguments: le contexte fourni par l'appelant et le code de retour (YAPI_SUCCESS si l'opération se déroule sans erreur).
contextcontexte fourni par l'appelant, et qui sera passé tel-quel à la fonction de callback

Retourne :

rien du tout : le résultat sera passé en paramètre à la fonction de callback.

21.2. Interface de contrôle du module

Cette interface est la même pour tous les modules USB de Yoctopuce. Elle permet de contrôler les paramètres généraux du module, et d'énumérer les fonctions fournies par chaque module.

Pour utiliser les fonctions décrites ici, vous devez inclure:

js
<script type='text/javascript' src='yocto_api.js'></script>
nodejs
var yoctolib = require('yoctolib');
var YAPI = yoctolib.YAPI;
var YModule = yoctolib.YModule;
php
require_once('yocto_api.php');
cpp
#include "yocto_api.h"
m
#import "yocto_api.h"
pas
uses yocto_api;
vb
yocto_api.vb
cs
yocto_api.cs
java
import com.yoctopuce.YoctoAPI.YModule;
py
from yocto_api import *
Fonction globales
yFindModule(func)

Permet de retrouver un module d'après son numéro de série ou son nom logique.

yFirstModule()

Commence l'énumération des modules accessibles par la librairie.

Méthodes des objets YModule
module→describe()

Retourne un court texte décrivant le module.

module→download(pathname)

Télécharge le fichier choisi du module et retourne son contenu.

module→functionCount()

Retourne le nombre de fonctions (sans compter l'interface "module") existant sur le module.

module→functionId(functionIndex)

Retourne l'identifiant matériel de la nième fonction du module.

module→functionName(functionIndex)

Retourne le nom logique de la nième fonction du module.

module→functionValue(functionIndex)

Retourne la valeur publiée par la nième fonction du module.

module→get_beacon()

Retourne l'état de la balise de localisation.

module→get_errorMessage()

Retourne le message correspondant à la dernière erreur survenue lors de l'utilisation de l'objet module.

module→get_errorType()

Retourne le code d'erreur correspondant à la dernière erreur survenue lors de l'utilisation de l'objet module.

module→get_firmwareRelease()

Retourne la version du logiciel embarqué du module.

module→get_hardwareId()

Retourne l'identifiant unique du module.

module→get_icon2d()

Retourne l'icône du module.

module→get_lastLogs()

Retourne une chaine de charactère contenant les derniers logs du module.

module→get_logicalName()

Retourne le nom logique du module.

module→get_luminosity()

Retourne la luminosité des leds informatives du module (valeur entre 0 et 100).

module→get_persistentSettings()

Retourne l'état courant des réglages persistents du module.

module→get_productId()

Retourne l'identifiant USB du module, préprogrammé en usine.

module→get_productName()

Retourne le nom commercial du module, préprogrammé en usine.

module→get_productRelease()

Retourne le numéro de version matériel du module, préprogrammé en usine.

module→get_rebootCountdown()

Retourne le nombre de secondes restantes avant un redémarrage du module, ou zéro si aucun redémarrage n'a été agendé.

module→get_serialNumber()

Retourne le numéro de série du module, préprogrammé en usine.

module→get_upTime()

Retourne le numbre de millisecondes écoulées depuis la mise sous tension du module

module→get_usbBandwidth()

Retourne le nombre d'interface USB utilisé par le module.

module→get_usbCurrent()

Retourne le courant consommé par le module sur le bus USB, en milliampères.

module→get_userData()

Retourne le contenu de l'attribut userData, précédemment stocké à l'aide de la méthode set_userData.

module→isOnline()

Vérifie si le module est joignable, sans déclencher d'erreur.

module→isOnline_async(callback, context)

Vérifie si le module est joignable, sans déclencher d'erreur.

module→load(msValidity)

Met en cache les valeurs courantes du module, avec une durée de validité spécifiée.

module→load_async(msValidity, callback, context)

Met en cache les valeurs courantes du module, avec une durée de validité spécifiée.

module→nextModule()

Continue l'énumération des modules commencée à l'aide de yFirstModule().

module→reboot(secBeforeReboot)

Agende un simple redémarrage du module dans un nombre donné de secondes.

module→revertFromFlash()

Recharge les réglages stockés dans le mémoire non volatile du module, comme à la mise sous tension du module.

module→saveToFlash()

Sauve les réglages courants dans la mémoire non volatile du module.

module→set_beacon(newval)

Allume ou éteint la balise de localisation du module.

module→set_logicalName(newval)

Change le nom logique du module.

module→set_luminosity(newval)

Modifie la luminosité des leds informatives du module.

module→set_usbBandwidth(newval)

Modifie le nombre d'interface USB utilisé par le module.

module→set_userData(data)

Enregistre un contexte libre dans l'attribut userData de la fonction, afin de le retrouver plus tard à l'aide de la méthode get_userData.

module→triggerFirmwareUpdate(secBeforeReboot)

Agende un redémarrage du module en mode spécial de reprogrammation du logiciel embarqué.

module→wait_async(callback, context)

Attend que toutes les commandes asynchrones en cours d'exécution sur le module soient terminées, et appelle le callback passé en paramètre.

YModule.FindModule()
yFindModule()
yFindModule()YModule.FindModule()yFindModule()yFindModule()yFindModule()yFindModule()yFindModule()YModule.FindModule()YModule.FindModule()YModule.FindModule()

Permet de retrouver un module d'après son numéro de série ou son nom logique.

js
function yFindModule(func)
nodejs
function FindModule(func)
php
function yFindModule($func)
cpp
YModule* yFindModule(string func)
m
+(YModule*) yFindModule: (NSString*) func
pas
function yFindModule(func: string): TYModule
vb
function yFindModule(ByVal func As String) As YModule
cs
YModule FindModule(string func)
java
YModule FindModule(String func)
py
def FindModule(func)

Cette fonction n'exige pas que le module soit en ligne au moment ou elle est appelée, l'objet retourné sera néanmoins valide. Utiliser la méthode YModule.isOnline() pour tester si le module est utilisable à un moment donné. En cas d'ambiguïté lorsqu'on fait une recherche par nom logique, aucune erreur ne sera notifiée: la première instance trouvée sera renvoyée. La recherche se fait d'abord par nom matériel, puis par nom logique.

Paramètres :

funcune chaîne de caractères contenant soit le numéro de série, soit le nom logique du module désiré

Retourne :

un objet de classe YModule qui permet ensuite de contrôler le module ou d'obtenir de plus amples informations sur le module.

YModule.FirstModule()
yFirstModule()
yFirstModule()YModule.FirstModule()yFirstModule()yFirstModule()yFirstModule()yFirstModule()yFirstModule()YModule.FirstModule()YModule.FirstModule()YModule.FirstModule()

Commence l'énumération des modules accessibles par la librairie.

js
function yFirstModule()
nodejs
function FirstModule()
php
function yFirstModule()
cpp
YModule* yFirstModule()
m
YModule* yFirstModule()
pas
function yFirstModule(): TYModule
vb
function yFirstModule() As YModule
cs
YModule FirstModule()
java
YModule FirstModule()
py
def FirstModule()

Utiliser la fonction YModule.nextModule() pour itérer sur les autres modules.

Retourne :

un pointeur sur un objet YModule, correspondant au premier module accessible en ligne, ou null si aucun module n'a été trouvé.

module→describe()module.describe()module.describe()module→describe()module→describe()[module describe]module.describe()module.describe()module.describe()module.describe()module.describe()

Retourne un court texte décrivant le module.

js
function describe()
nodejs
function describe()
php
function describe()
cpp
string describe()
m
-(NSString*) describe
pas
function describe(): string
vb
function describe() As String
cs
string describe()
java
String describe()
py
def describe()

Ce texte peut contenir soit le nom logique du module, soit son numéro de série.

Retourne :

une chaîne de caractères décrivant le module

module→download()module.download()module.download()module→download()module→download()[module download: ]module.download()module.download()module.download()YModule download

Télécharge le fichier choisi du module et retourne son contenu.

js
function download(pathname)
nodejs
function download(pathname)
php
function download($pathname)
cpp
string download(string pathname)
m
-(NSData*) download: (NSString*) pathname
pas
function download(pathname: string): TByteArray
vb
function download() As Byte
py
def download(pathname)
cmd
YModule target download pathname

Paramètres :

pathnamenom complet du fichier

Retourne :

le contenu du fichier chargé

En cas d'erreur, déclenche une exception ou retourne un contenu vide.

module→functionCount()module.functionCount()module.functionCount()module→functionCount()module→functionCount()[module functionCount]module.functionCount()module.functionCount()module.functionCount()module.functionCount()

Retourne le nombre de fonctions (sans compter l'interface "module") existant sur le module.

js
function functionCount()
nodejs
function functionCount()
php
function functionCount()
cpp
int functionCount()
m
-(int) functionCount
pas
function functionCount(): integer
vb
function functionCount() As Integer
cs
int functionCount()
py
def functionCount()

Retourne :

le nombre de fonctions sur le module

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

module→functionId()module.functionId()module.functionId()module→functionId()module→functionId()[module functionId: ]module.functionId()module.functionId()module.functionId()module.functionId()

Retourne l'identifiant matériel de la nième fonction du module.

js
function functionId(functionIndex)
nodejs
function functionId(functionIndex)
php
function functionId($functionIndex)
cpp
string functionId(int functionIndex)
m
-(NSString*) functionId: (int) functionIndex
pas
function functionId(functionIndex: integer): string
vb
function functionId(ByVal functionIndex As Integer) As String
cs
string functionId(int functionIndex)
py
def functionId(functionIndex)

Paramètres :

functionIndexl'index de la fonction pour laquelle l'information est désirée, en commençant à 0 pour la première fonction.

Retourne :

une chaîne de caractères correspondant à l'identifiant matériel unique de la fonction désirée

En cas d'erreur, déclenche une exception ou retourne un chaîne vide.

module→functionName()module.functionName()module.functionName()module→functionName()module→functionName()[module functionName: ]module.functionName()module.functionName()module.functionName()module.functionName()

Retourne le nom logique de la nième fonction du module.

js
function functionName(functionIndex)
nodejs
function functionName(functionIndex)
php
function functionName($functionIndex)
cpp
string functionName(int functionIndex)
m
-(NSString*) functionName: (int) functionIndex
pas
function functionName(functionIndex: integer): string
vb
function functionName(ByVal functionIndex As Integer) As String
cs
string functionName(int functionIndex)
py
def functionName(functionIndex)

Paramètres :

functionIndexl'index de la fonction pour laquelle l'information est désirée, en commençant à 0 pour la première fonction.

Retourne :

une chaîne de caractères correspondant au nom logique de la fonction désirée

En cas d'erreur, déclenche une exception ou retourne un chaîne vide.

module→functionValue()module.functionValue()module.functionValue()module→functionValue()module→functionValue()[module functionValue: ]module.functionValue()module.functionValue()module.functionValue()module.functionValue()

Retourne la valeur publiée par la nième fonction du module.

js
function functionValue(functionIndex)
nodejs
function functionValue(functionIndex)
php
function functionValue($functionIndex)
cpp
string functionValue(int functionIndex)
m
-(NSString*) functionValue: (int) functionIndex
pas
function functionValue(functionIndex: integer): string
vb
function functionValue(ByVal functionIndex As Integer) As String
cs
string functionValue(int functionIndex)
py
def functionValue(functionIndex)

Paramètres :

functionIndexl'index de la fonction pour laquelle l'information est désirée, en commençant à 0 pour la première fonction.

Retourne :

une chaîne de caractères correspondant à la valeur publiée par la fonction désirée

En cas d'erreur, déclenche une exception ou retourne un chaîne vide.

module→get_beacon()
module→beacon()
module.get_beacon()module.get_beacon()module→get_beacon()module→get_beacon()[module beacon]module.get_beacon()module.get_beacon()module.get_beacon()module.get_beacon()module.get_beacon()YModule get_beacon

Retourne l'état de la balise de localisation.

js
function get_beacon()
nodejs
function get_beacon()
php
function get_beacon()
cpp
Y_BEACON_enum get_beacon()
m
-(Y_BEACON_enum) beacon
pas
function get_beacon(): Integer
vb
function get_beacon() As Integer
cs
int get_beacon()
java
int get_beacon()
py
def get_beacon()
cmd
YModule target get_beacon

Retourne :

soit Y_BEACON_OFF, soit Y_BEACON_ON, selon l'état de la balise de localisation

En cas d'erreur, déclenche une exception ou retourne Y_BEACON_INVALID.

module→get_errorMessage()
module→errorMessage()
module.get_errorMessage()module.get_errorMessage()module→get_errorMessage()module→get_errorMessage()[module errorMessage]module.get_errorMessage()module.get_errorMessage()module.get_errorMessage()module.get_errorMessage()module.get_errorMessage()

Retourne le message correspondant à la dernière erreur survenue lors de l'utilisation de l'objet module.

js
function get_errorMessage()
nodejs
function get_errorMessage()
php
function get_errorMessage()
cpp
string get_errorMessage()
m
-(NSString*) errorMessage
pas
function get_errorMessage(): string
vb
function get_errorMessage() As String
cs
string get_errorMessage()
java
String get_errorMessage()
py
def get_errorMessage()

Cette méthode est principalement utile lorsque la librairie Yoctopuce est utilisée en désactivant la gestion des exceptions.

Retourne :

une chaîne de caractères correspondant au message de la dernière erreur qui s'est produit lors de l'utilisation du module

module→get_errorType()
module→errorType()
module.get_errorType()module.get_errorType()module→get_errorType()module→get_errorType()module.get_errorType()module.get_errorType()module.get_errorType()module.get_errorType()module.get_errorType()

Retourne le code d'erreur correspondant à la dernière erreur survenue lors de l'utilisation de l'objet module.

js
function get_errorType()
nodejs
function get_errorType()
php
function get_errorType()
cpp
YRETCODE get_errorType()
pas
function get_errorType(): YRETCODE
vb
function get_errorType() As YRETCODE
cs
YRETCODE get_errorType()
java
int get_errorType()
py
def get_errorType()

Cette méthode est principalement utile lorsque la librairie Yoctopuce est utilisée en désactivant la gestion des exceptions.

Retourne :

un nombre correspondant au code de la dernière erreur qui s'est produit lors de l'utilisation du module

module→get_firmwareRelease()
module→firmwareRelease()
module.get_firmwareRelease()module.get_firmwareRelease()module→get_firmwareRelease()module→get_firmwareRelease()[module firmwareRelease]module.get_firmwareRelease()module.get_firmwareRelease()module.get_firmwareRelease()module.get_firmwareRelease()module.get_firmwareRelease()YModule get_firmwareRelease

Retourne la version du logiciel embarqué du module.

js
function get_firmwareRelease()
nodejs
function get_firmwareRelease()
php
function get_firmwareRelease()
cpp
string get_firmwareRelease()
m
-(NSString*) firmwareRelease
pas
function get_firmwareRelease(): string
vb
function get_firmwareRelease() As String
cs
string get_firmwareRelease()
java
String get_firmwareRelease()
py
def get_firmwareRelease()
cmd
YModule target get_firmwareRelease

Retourne :

une chaîne de caractères représentant la version du logiciel embarqué du module

En cas d'erreur, déclenche une exception ou retourne Y_FIRMWARERELEASE_INVALID.

module→get_hardwareId()
module→hardwareId()
module.get_hardwareId()module.get_hardwareId()module→get_hardwareId()module→get_hardwareId()[module hardwareId]module.get_hardwareId()module.get_hardwareId()module.get_hardwareId()module.get_hardwareId()

Retourne l'identifiant unique du module.

js
function get_hardwareId()
nodejs
function get_hardwareId()
php
function get_hardwareId()
cpp
string get_hardwareId()
m
-(NSString*) hardwareId
vb
function get_hardwareId() As String
cs
string get_hardwareId()
java
String get_hardwareId()
py
def get_hardwareId()

L'identifiant unique est composé du numéro de série du module suivi de la chaîne ".module".

Retourne :

une chaîne de caractères identifiant la fonction

module→get_icon2d()
module→icon2d()
module.get_icon2d()module.get_icon2d()module→get_icon2d()module→get_icon2d()[module icon2d]module.get_icon2d()module.get_icon2d()module.get_icon2d()YModule get_icon2d

Retourne l'icône du module.

js
function get_icon2d()
nodejs
function get_icon2d()
php
function get_icon2d()
cpp
string get_icon2d()
m
-(NSData*) icon2d
pas
function get_icon2d(): TByteArray
vb
function get_icon2d() As Byte
py
def get_icon2d()
cmd
YModule target get_icon2d

L'icone est au format PNG et a une taille maximale de 1536 octets.

Retourne :

un buffer binaire contenant l'icone, au format png.

module→get_lastLogs()
module→lastLogs()
module.get_lastLogs()module.get_lastLogs()module→get_lastLogs()module→get_lastLogs()[module lastLogs]module.get_lastLogs()module.get_lastLogs()module.get_lastLogs()module.get_lastLogs()module.get_lastLogs()YModule get_lastLogs

Retourne une chaine de charactère contenant les derniers logs du module.

js
function get_lastLogs()
nodejs
function get_lastLogs()
php
function get_lastLogs()
cpp
string get_lastLogs()
m
-(NSString*) lastLogs
pas
function get_lastLogs(): string
vb
function get_lastLogs() As String
cs
string get_lastLogs()
java
String get_lastLogs()
py
def get_lastLogs()
cmd
YModule target get_lastLogs

Cette methode retourne les derniers logs qui sont encore stocké dans le module.

Retourne :

une chaine de charactère contenant les derniers logs du module.

module→get_logicalName()
module→logicalName()
module.get_logicalName()module.get_logicalName()module→get_logicalName()module→get_logicalName()[module logicalName]module.get_logicalName()module.get_logicalName()module.get_logicalName()module.get_logicalName()module.get_logicalName()YModule get_logicalName

Retourne le nom logique du module.

js
function get_logicalName()
nodejs
function get_logicalName()
php
function get_logicalName()
cpp
string get_logicalName()
m
-(NSString*) logicalName
pas
function get_logicalName(): string
vb
function get_logicalName() As String
cs
string get_logicalName()
java
String get_logicalName()
py
def get_logicalName()
cmd
YModule target get_logicalName

Retourne :

une chaîne de caractères représentant le nom logique du module

En cas d'erreur, déclenche une exception ou retourne Y_LOGICALNAME_INVALID.

module→get_luminosity()
module→luminosity()
module.get_luminosity()module.get_luminosity()module→get_luminosity()module→get_luminosity()[module luminosity]module.get_luminosity()module.get_luminosity()module.get_luminosity()module.get_luminosity()module.get_luminosity()YModule get_luminosity

Retourne la luminosité des leds informatives du module (valeur entre 0 et 100).

js
function get_luminosity()
nodejs
function get_luminosity()
php
function get_luminosity()
cpp
int get_luminosity()
m
-(int) luminosity
pas
function get_luminosity(): LongInt
vb
function get_luminosity() As Integer
cs
int get_luminosity()
java
int get_luminosity()
py
def get_luminosity()
cmd
YModule target get_luminosity

Retourne :

un entier représentant la luminosité des leds informatives du module (valeur entre 0 et 100)

En cas d'erreur, déclenche une exception ou retourne Y_LUMINOSITY_INVALID.

module→get_persistentSettings()
module→persistentSettings()
module.get_persistentSettings()module.get_persistentSettings()module→get_persistentSettings()module→get_persistentSettings()[module persistentSettings]module.get_persistentSettings()module.get_persistentSettings()module.get_persistentSettings()module.get_persistentSettings()module.get_persistentSettings()YModule get_persistentSettings

Retourne l'état courant des réglages persistents du module.

js
function get_persistentSettings()
nodejs
function get_persistentSettings()
php
function get_persistentSettings()
cpp
Y_PERSISTENTSETTINGS_enum get_persistentSettings()
m
-(Y_PERSISTENTSETTINGS_enum) persistentSettings
pas
function get_persistentSettings(): Integer
vb
function get_persistentSettings() As Integer
cs
int get_persistentSettings()
java
int get_persistentSettings()
py
def get_persistentSettings()
cmd
YModule target get_persistentSettings

Retourne :

une valeur parmi Y_PERSISTENTSETTINGS_LOADED, Y_PERSISTENTSETTINGS_SAVED et Y_PERSISTENTSETTINGS_MODIFIED représentant l'état courant des réglages persistents du module

En cas d'erreur, déclenche une exception ou retourne Y_PERSISTENTSETTINGS_INVALID.

module→get_productId()
module→productId()
module.get_productId()module.get_productId()module→get_productId()module→get_productId()[module productId]module.get_productId()module.get_productId()module.get_productId()module.get_productId()module.get_productId()YModule get_productId

Retourne l'identifiant USB du module, préprogrammé en usine.

js
function get_productId()
nodejs
function get_productId()
php
function get_productId()
cpp
int get_productId()
m
-(int) productId
pas
function get_productId(): LongInt
vb
function get_productId() As Integer
cs
int get_productId()
java
int get_productId()
py
def get_productId()
cmd
YModule target get_productId

Retourne :

un entier représentant l'identifiant USB du module, préprogrammé en usine

En cas d'erreur, déclenche une exception ou retourne Y_PRODUCTID_INVALID.

module→get_productName()
module→productName()
module.get_productName()module.get_productName()module→get_productName()module→get_productName()[module productName]module.get_productName()module.get_productName()module.get_productName()module.get_productName()module.get_productName()YModule get_productName

Retourne le nom commercial du module, préprogrammé en usine.

js
function get_productName()
nodejs
function get_productName()
php
function get_productName()
cpp
string get_productName()
m
-(NSString*) productName
pas
function get_productName(): string
vb
function get_productName() As String
cs
string get_productName()
java
String get_productName()
py
def get_productName()
cmd
YModule target get_productName

Retourne :

une chaîne de caractères représentant le nom commercial du module, préprogrammé en usine

En cas d'erreur, déclenche une exception ou retourne Y_PRODUCTNAME_INVALID.

module→get_productRelease()
module→productRelease()
module.get_productRelease()module.get_productRelease()module→get_productRelease()module→get_productRelease()[module productRelease]module.get_productRelease()module.get_productRelease()module.get_productRelease()module.get_productRelease()module.get_productRelease()YModule get_productRelease

Retourne le numéro de version matériel du module, préprogrammé en usine.

js
function get_productRelease()
nodejs
function get_productRelease()
php
function get_productRelease()
cpp
int get_productRelease()
m
-(int) productRelease
pas
function get_productRelease(): LongInt
vb
function get_productRelease() As Integer
cs
int get_productRelease()
java
int get_productRelease()
py
def get_productRelease()
cmd
YModule target get_productRelease

Retourne :

un entier représentant le numéro de version matériel du module, préprogrammé en usine

En cas d'erreur, déclenche une exception ou retourne Y_PRODUCTRELEASE_INVALID.

module→get_rebootCountdown()
module→rebootCountdown()
module.get_rebootCountdown()module.get_rebootCountdown()module→get_rebootCountdown()module→get_rebootCountdown()[module rebootCountdown]module.get_rebootCountdown()module.get_rebootCountdown()module.get_rebootCountdown()module.get_rebootCountdown()module.get_rebootCountdown()YModule get_rebootCountdown

Retourne le nombre de secondes restantes avant un redémarrage du module, ou zéro si aucun redémarrage n'a été agendé.

js
function get_rebootCountdown()
nodejs
function get_rebootCountdown()
php
function get_rebootCountdown()
cpp
int get_rebootCountdown()
m
-(int) rebootCountdown
pas
function get_rebootCountdown(): LongInt
vb
function get_rebootCountdown() As Integer
cs
int get_rebootCountdown()
java
int get_rebootCountdown()
py
def get_rebootCountdown()
cmd
YModule target get_rebootCountdown

Retourne :

un entier représentant le nombre de secondes restantes avant un redémarrage du module, ou zéro si aucun redémarrage n'a été agendé

En cas d'erreur, déclenche une exception ou retourne Y_REBOOTCOUNTDOWN_INVALID.

module→get_serialNumber()
module→serialNumber()
module.get_serialNumber()module.get_serialNumber()module→get_serialNumber()module→get_serialNumber()[module serialNumber]module.get_serialNumber()module.get_serialNumber()module.get_serialNumber()module.get_serialNumber()module.get_serialNumber()YModule get_serialNumber

Retourne le numéro de série du module, préprogrammé en usine.

js
function get_serialNumber()
nodejs
function get_serialNumber()
php
function get_serialNumber()
cpp
string get_serialNumber()
m
-(NSString*) serialNumber
pas
function get_serialNumber(): string
vb
function get_serialNumber() As String
cs
string get_serialNumber()
java
String get_serialNumber()
py
def get_serialNumber()
cmd
YModule target get_serialNumber

Retourne :

une chaîne de caractères représentant le numéro de série du module, préprogrammé en usine

En cas d'erreur, déclenche une exception ou retourne Y_SERIALNUMBER_INVALID.

module→get_upTime()
module→upTime()
module.get_upTime()module.get_upTime()module→get_upTime()module→get_upTime()[module upTime]module.get_upTime()module.get_upTime()module.get_upTime()module.get_upTime()module.get_upTime()YModule get_upTime

Retourne le numbre de millisecondes écoulées depuis la mise sous tension du module

js
function get_upTime()
nodejs
function get_upTime()
php
function get_upTime()
cpp
s64 get_upTime()
m
-(s64) upTime
pas
function get_upTime(): int64
vb
function get_upTime() As Long
cs
long get_upTime()
java
long get_upTime()
py
def get_upTime()
cmd
YModule target get_upTime

Retourne :

un entier représentant le numbre de millisecondes écoulées depuis la mise sous tension du module

En cas d'erreur, déclenche une exception ou retourne Y_UPTIME_INVALID.

module→get_usbBandwidth()
module→usbBandwidth()
module.get_usbBandwidth()module.get_usbBandwidth()module→get_usbBandwidth()module→get_usbBandwidth()[module usbBandwidth]module.get_usbBandwidth()module.get_usbBandwidth()module.get_usbBandwidth()module.get_usbBandwidth()module.get_usbBandwidth()YModule get_usbBandwidth

Retourne le nombre d'interface USB utilisé par le module.

js
function get_usbBandwidth()
nodejs
function get_usbBandwidth()
php
function get_usbBandwidth()
cpp
Y_USBBANDWIDTH_enum get_usbBandwidth()
m
-(Y_USBBANDWIDTH_enum) usbBandwidth
pas
function get_usbBandwidth(): Integer
vb
function get_usbBandwidth() As Integer
cs
int get_usbBandwidth()
java
int get_usbBandwidth()
py
def get_usbBandwidth()
cmd
YModule target get_usbBandwidth

Retourne :

soit Y_USBBANDWIDTH_SIMPLE, soit Y_USBBANDWIDTH_DOUBLE, selon le nombre d'interface USB utilisé par le module

En cas d'erreur, déclenche une exception ou retourne Y_USBBANDWIDTH_INVALID.

module→get_usbCurrent()
module→usbCurrent()
module.get_usbCurrent()module.get_usbCurrent()module→get_usbCurrent()module→get_usbCurrent()[module usbCurrent]module.get_usbCurrent()module.get_usbCurrent()module.get_usbCurrent()module.get_usbCurrent()module.get_usbCurrent()YModule get_usbCurrent

Retourne le courant consommé par le module sur le bus USB, en milliampères.

js
function get_usbCurrent()
nodejs
function get_usbCurrent()
php
function get_usbCurrent()
cpp
int get_usbCurrent()
m
-(int) usbCurrent
pas
function get_usbCurrent(): LongInt
vb
function get_usbCurrent() As Integer
cs
int get_usbCurrent()
java
int get_usbCurrent()
py
def get_usbCurrent()
cmd
YModule target get_usbCurrent

Retourne :

un entier représentant le courant consommé par le module sur le bus USB, en milliampères

En cas d'erreur, déclenche une exception ou retourne Y_USBCURRENT_INVALID.

module→get_userData()
module→userData()
module.get_userData()module.get_userData()module→get_userData()module→get_userData()[module userData]module.get_userData()module.get_userData()module.get_userData()module.get_userData()module.get_userData()

Retourne le contenu de l'attribut userData, précédemment stocké à l'aide de la méthode set_userData.

js
function get_userData()
nodejs
function get_userData()
php
function get_userData()
cpp
void * get_userData()
m
-(void*) userData
pas
function get_userData(): Tobject
vb
function get_userData() As Object
cs
object get_userData()
java
Object get_userData()
py
def get_userData()

Cet attribut n'es pas utilisé directement par l'API. Il est à la disposition de l'appelant pour stocker un contexte.

Retourne :

l'objet stocké précédemment par l'appelant.

module→isOnline()module.isOnline()module.isOnline()module→isOnline()module→isOnline()[module isOnline]module.isOnline()module.isOnline()module.isOnline()module.isOnline()module.isOnline()

Vérifie si le module est joignable, sans déclencher d'erreur.

js
function isOnline()
nodejs
function isOnline()
php
function isOnline()
cpp
bool isOnline()
m
-(BOOL) isOnline
pas
function isOnline(): boolean
vb
function isOnline() As Boolean
cs
bool isOnline()
java
boolean isOnline()
py
def isOnline()

Si les valeurs des attributs du module en cache sont valides au moment de l'appel, le module est considéré joignable. Cette fonction ne cause en aucun cas d'exception, quelle que soit l'erreur qui pourrait se produire lors de la vérification de joignabilité.

Retourne :

true si le module est joignable, false sinon

module→isOnline_async()module.isOnline_async()module.isOnline_async()

Vérifie si le module est joignable, sans déclencher d'erreur.

js
function isOnline_async(callback, context)
nodejs
function isOnline_async(callback, context)

Si les valeurs des attributs du module en cache sont valides au moment de l'appel, le module est considéré joignable. Cette fonction ne cause en aucun cas d'exception, quelle que soit l'erreur qui pourrait se produire lors de la vérification de joignabilité.

Cette version asynchrone n'existe qu'en Javascript. Elle utilise une fonction de callback plutôt qu'une simple valeur de retour, pour éviter de bloquer la VM Javascript de Firefox, qui n'implémente pas le passage de contrôle entre threads durant les appels d'entrée/sortie bloquants.

Paramètres :

callbackfonction de callback qui sera appelée dès que le résultat sera connu. La fonction callback reçoit trois arguments: le contexte fourni par l'appelant, l'objet module concerné et le résultat booléen
contextcontexte fourni par l'appelant, et qui sera passé tel-quel à la fonction de callback

Retourne :

rien du tout : le résultat sera passé en paramètre à la fonction de callback.

module→load()module.load()module.load()module→load()module→load()[module load: ]module.load()module.load()module.load()module.load()module.load()

Met en cache les valeurs courantes du module, avec une durée de validité spécifiée.

js
function load(msValidity)
nodejs
function load(msValidity)
php
function load($msValidity)
cpp
YRETCODE load(int msValidity)
m
-(YRETCODE) load: (int) msValidity
pas
function load(msValidity: integer): YRETCODE
vb
function load(ByVal msValidity As Integer) As YRETCODE
cs
YRETCODE load(int msValidity)
java
int load(long msValidity)
py
def load(msValidity)

Par défaut, lorsqu'on accède à un module, tous les attributs des fonctions du module sont automatiquement mises en cache pour la durée standard (5 ms). Cette méthode peut être utilisée pour marquer occasionellement les données cachées comme valides pour une plus longue période, par exemple dans le but de réduire le trafic réseau.

Paramètres :

msValidityun entier correspondant à la durée de validité attribuée aux les paramètres chargés, en millisecondes

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

module→load_async()module.load_async()module.load_async()

Met en cache les valeurs courantes du module, avec une durée de validité spécifiée.

js
function load_async(msValidity, callback, context)
nodejs
function load_async(msValidity, callback, context)

Par défaut, lorsqu'on accède à un module, tous les attributs des fonctions du module sont automatiquement mises en cache pour la durée standard (5 ms). Cette méthode peut être utilisée pour marquer occasionellement les données cachées comme valides pour une plus longue période, par exemple dans le but de réduire le trafic réseau.

Cette version asynchrone n'existe qu'en Javascript. Elle utilise une fonction de callback plutôt qu'une simple valeur de retour, pour éviter de bloquer la VM Javascript de Firefox, qui n'implémente pas le passage de contrôle entre threads durant les appels d'entrée/sortie bloquants.

Paramètres :

msValidityun entier correspondant à la durée de validité attribuée aux les paramètres chargés, en millisecondes
callbackfonction de callback qui sera appelée dès que le résultat sera connu. La fonction callback reçoit trois arguments: le contexte fourni par l'appelant, l'objet module concerné et le code d'erreur (ou YAPI_SUCCESS)
contextcontexte fourni par l'appelant, et qui sera passé tel-quel à la fonction de callback

Retourne :

rien du tout : le résultat sera passé en paramètre à la fonction de callback.

module→nextModule()module.nextModule()module.nextModule()module→nextModule()module→nextModule()[module nextModule]module.nextModule()module.nextModule()module.nextModule()module.nextModule()module.nextModule()

Continue l'énumération des modules commencée à l'aide de yFirstModule().

js
function nextModule()
nodejs
function nextModule()
php
function nextModule()
cpp
YModule * nextModule()
m
-(YModule*) nextModule
pas
function nextModule(): TYModule
vb
function nextModule() As YModule
cs
YModule nextModule()
java
YModule nextModule()
py
def nextModule()

Retourne :

un pointeur sur un objet YModule accessible en ligne, ou null lorsque l'énumération est terminée.

module→reboot()module.reboot()module.reboot()module→reboot()module→reboot()[module reboot: ]module.reboot()module.reboot()module.reboot()module.reboot()module.reboot()YModule reboot

Agende un simple redémarrage du module dans un nombre donné de secondes.

js
function reboot(secBeforeReboot)
nodejs
function reboot(secBeforeReboot)
php
function reboot($secBeforeReboot)
cpp
int reboot(int secBeforeReboot)
m
-(int) reboot: (int) secBeforeReboot
pas
function reboot(secBeforeReboot: LongInt): LongInt
vb
function reboot() As Integer
cs
int reboot(int secBeforeReboot)
java
int reboot(int secBeforeReboot)
py
def reboot(secBeforeReboot)
cmd
YModule target reboot secBeforeReboot

Paramètres :

secBeforeRebootnombre de secondes avant de redémarrer

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

module→revertFromFlash()module.revertFromFlash()module.revertFromFlash()module→revertFromFlash()module→revertFromFlash()[module revertFromFlash]module.revertFromFlash()module.revertFromFlash()module.revertFromFlash()module.revertFromFlash()module.revertFromFlash()YModule revertFromFlash

Recharge les réglages stockés dans le mémoire non volatile du module, comme à la mise sous tension du module.

js
function revertFromFlash()
nodejs
function revertFromFlash()
php
function revertFromFlash()
cpp
int revertFromFlash()
m
-(int) revertFromFlash
pas
function revertFromFlash(): LongInt
vb
function revertFromFlash() As Integer
cs
int revertFromFlash()
java
int revertFromFlash()
py
def revertFromFlash()
cmd
YModule target revertFromFlash

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

module→saveToFlash()module.saveToFlash()module.saveToFlash()module→saveToFlash()module→saveToFlash()[module saveToFlash]module.saveToFlash()module.saveToFlash()module.saveToFlash()module.saveToFlash()module.saveToFlash()YModule saveToFlash

Sauve les réglages courants dans la mémoire non volatile du module.

js
function saveToFlash()
nodejs
function saveToFlash()
php
function saveToFlash()
cpp
int saveToFlash()
m
-(int) saveToFlash
pas
function saveToFlash(): LongInt
vb
function saveToFlash() As Integer
cs
int saveToFlash()
java
int saveToFlash()
py
def saveToFlash()
cmd
YModule target saveToFlash

Attention le nombre total de sauvegardes possibles durant la vie du module est limité (environ 100000 cycles). N'appelez pas cette fonction dans une boucle.

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

module→set_beacon()
module→setBeacon()
module.set_beacon()module.set_beacon()module→set_beacon()module→set_beacon()[module setBeacon: ]module.set_beacon()module.set_beacon()module.set_beacon()module.set_beacon()module.set_beacon()YModule set_beacon

Allume ou éteint la balise de localisation du module.

js
function set_beacon(newval)
nodejs
function set_beacon(newval)
php
function set_beacon($newval)
cpp
int set_beacon(Y_BEACON_enum newval)
m
-(int) setBeacon: (Y_BEACON_enum) newval
pas
function set_beacon(newval: Integer): integer
vb
function set_beacon(ByVal newval As Integer) As Integer
cs
int set_beacon(int newval)
java
int set_beacon(int newval)
py
def set_beacon(newval)
cmd
YModule target set_beacon newval

Paramètres :

newvalsoit Y_BEACON_OFF, soit Y_BEACON_ON

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

module→set_logicalName()
module→setLogicalName()
module.set_logicalName()module.set_logicalName()module→set_logicalName()module→set_logicalName()[module setLogicalName: ]module.set_logicalName()module.set_logicalName()module.set_logicalName()module.set_logicalName()module.set_logicalName()YModule set_logicalName

Change le nom logique du module.

js
function set_logicalName(newval)
nodejs
function set_logicalName(newval)
php
function set_logicalName($newval)
cpp
int set_logicalName(const string& newval)
m
-(int) setLogicalName: (NSString*) newval
pas
function set_logicalName(newval: string): integer
vb
function set_logicalName(ByVal newval As String) As Integer
cs
int set_logicalName(string newval)
java
int set_logicalName(String newval)
py
def set_logicalName(newval)
cmd
YModule target set_logicalName newval

Vous pouvez utiliser yCheckLogicalName() pour vérifier si votre paramètre est valide. N'oubliez pas d'appeler la méthode saveToFlash() du module si le réglage doit être préservé.

Paramètres :

newvalune chaîne de caractères

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

module→set_luminosity()
module→setLuminosity()
module.set_luminosity()module.set_luminosity()module→set_luminosity()module→set_luminosity()[module setLuminosity: ]module.set_luminosity()module.set_luminosity()module.set_luminosity()module.set_luminosity()module.set_luminosity()YModule set_luminosity

Modifie la luminosité des leds informatives du module.

js
function set_luminosity(newval)
nodejs
function set_luminosity(newval)
php
function set_luminosity($newval)
cpp
int set_luminosity(int newval)
m
-(int) setLuminosity: (int) newval
pas
function set_luminosity(newval: LongInt): integer
vb
function set_luminosity(ByVal newval As Integer) As Integer
cs
int set_luminosity(int newval)
java
int set_luminosity(int newval)
py
def set_luminosity(newval)
cmd
YModule target set_luminosity newval

Le paramêtre est une valeur entre 0 et 100. N'oubliez pas d'appeler la méthode saveToFlash() du module si le réglage doit être préservé.

Paramètres :

newvalun entier représentant la luminosité des leds informatives du module

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

module→set_usbBandwidth()
module→setUsbBandwidth()
module.set_usbBandwidth()module.set_usbBandwidth()module→set_usbBandwidth()module→set_usbBandwidth()[module setUsbBandwidth: ]module.set_usbBandwidth()module.set_usbBandwidth()module.set_usbBandwidth()module.set_usbBandwidth()module.set_usbBandwidth()YModule set_usbBandwidth

Modifie le nombre d'interface USB utilisé par le module.

js
function set_usbBandwidth(newval)
nodejs
function set_usbBandwidth(newval)
php
function set_usbBandwidth($newval)
cpp
int set_usbBandwidth(Y_USBBANDWIDTH_enum newval)
m
-(int) setUsbBandwidth: (Y_USBBANDWIDTH_enum) newval
pas
function set_usbBandwidth(newval: Integer): integer
vb
function set_usbBandwidth(ByVal newval As Integer) As Integer
cs
int set_usbBandwidth(int newval)
java
int set_usbBandwidth(int newval)
py
def set_usbBandwidth(newval)
cmd
YModule target set_usbBandwidth newval

Vous devez redémarrer le module après avoir changé ce réglage.

Paramètres :

newvalsoit Y_USBBANDWIDTH_SIMPLE, soit Y_USBBANDWIDTH_DOUBLE, selon le nombre d'interface USB utilisé par le module

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

module→set_userData()
module→setUserData()
module.set_userData()module.set_userData()module→set_userData()module→set_userData()[module setUserData: ]module.set_userData()module.set_userData()module.set_userData()module.set_userData()module.set_userData()

Enregistre un contexte libre dans l'attribut userData de la fonction, afin de le retrouver plus tard à l'aide de la méthode get_userData.

js
function set_userData(data)
nodejs
function set_userData(data)
php
function set_userData($data)
cpp
void set_userData(void* data)
m
-(void) setUserData: (void*) data
pas
procedure set_userData(data: Tobject)
vb
procedure set_userData(ByVal data As Object)
cs
void set_userData(object data)
java
void set_userData(Object data)
py
def set_userData(data)

Cet attribut n'es pas utilisé directement par l'API. Il est à la disposition de l'appelant pour stocker un contexte.

Paramètres :

dataobjet quelconque à mémoriser

module→triggerFirmwareUpdate()module.triggerFirmwareUpdate()module.triggerFirmwareUpdate()module→triggerFirmwareUpdate()module→triggerFirmwareUpdate()[module triggerFirmwareUpdate: ]module.triggerFirmwareUpdate()module.triggerFirmwareUpdate()module.triggerFirmwareUpdate()module.triggerFirmwareUpdate()module.triggerFirmwareUpdate()YModule triggerFirmwareUpdate

Agende un redémarrage du module en mode spécial de reprogrammation du logiciel embarqué.

js
function triggerFirmwareUpdate(secBeforeReboot)
nodejs
function triggerFirmwareUpdate(secBeforeReboot)
php
function triggerFirmwareUpdate($secBeforeReboot)
cpp
int triggerFirmwareUpdate(int secBeforeReboot)
m
-(int) triggerFirmwareUpdate: (int) secBeforeReboot
pas
function triggerFirmwareUpdate(secBeforeReboot: LongInt): LongInt
vb
function triggerFirmwareUpdate() As Integer
cs
int triggerFirmwareUpdate(int secBeforeReboot)
java
int triggerFirmwareUpdate(int secBeforeReboot)
py
def triggerFirmwareUpdate(secBeforeReboot)
cmd
YModule target triggerFirmwareUpdate secBeforeReboot

Paramètres :

secBeforeRebootnombre de secondes avant de redémarrer

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

module→wait_async()module.wait_async()module.wait_async()

Attend que toutes les commandes asynchrones en cours d'exécution sur le module soient terminées, et appelle le callback passé en paramètre.

js
function wait_async(callback, context)
nodejs
function wait_async(callback, context)

La fonction callback peut donc librement utiliser des fonctions synchrones ou asynchrones, sans risquer de bloquer la machine virtuelle Javascript.

Paramètres :

callbackfonction de callback qui sera appelée dès que toutes les commandes en cours d'exécution sur le module seront terminées La fonction callback reçoit deux arguments: le contexte fourni par l'appelant et l'objet fonction concerné.
contextcontexte fourni par l'appelant, et qui sera passé tel-quel à la fonction de callback

Retourne :

rien du tout :

21.3. Interface de la fonction Display

L'interface de contrôle des écrans Yoctopuce est conçue pour afficher facilement des informations et des images. Le module est capable de gérer seul la superposition de plusieurs couches graphiques, qui peuvent être dessinées individuellement, sans affichage immédiat, puis librement positionnées sur l'écran. Il est aussi capable de rejouer des séquences de commandes pré-enregistrées (animations).

Pour utiliser les fonctions décrites ici, vous devez inclure:

js
<script type='text/javascript' src='yocto_display.js'></script>
nodejs
var yoctolib = require('yoctolib');
var YDisplay = yoctolib.YDisplay;
php
require_once('yocto_display.php');
cpp
#include "yocto_display.h"
m
#import "yocto_display.h"
pas
uses yocto_display;
vb
yocto_display.vb
cs
yocto_display.cs
java
import com.yoctopuce.YoctoAPI.YDisplay;
py
from yocto_display import *
Fonction globales
yFindDisplay(func)

Permet de retrouver un ecran d'après un identifiant donné.

yFirstDisplay()

Commence l'énumération des écran accessibles par la librairie.

Méthodes des objets YDisplay
display→copyLayerContent(srcLayerId, dstLayerId)

Copie le contentu d'un couche d'affichage vers une autre couche.

display→describe()

Retourne un court texte décrivant l'ecran au format TYPE(NAME)=SERIAL.FUNCTIONID.

display→fade(brightness, duration)

Change la luminosité de l'écran en douceur, pour produire un effet de fade-in ou fade-out.

display→get_advertisedValue()

Retourne la valeur courante de l'ecran (pas plus de 6 caractères).

display→get_brightness()

Retourne la luminosité des leds informatives du module (valeur entre 0 et 100).

display→get_displayHeight()

Retourne la hauteur de l'écran, en pixels.

display→get_displayLayer(layerId)

Retourne un objet YDisplayLayer utilisable pour dessiner sur la couche d'affichage correspondante.

display→get_displayType()

Retourne le type de l'écran: monochrome, niveaux de gris ou couleur.

display→get_displayWidth()

Retourne la largeur de l'écran, en pixels.

display→get_enabled()

Retourne vrai si le l'ecran est alimenté, faux sinon.

display→get_errorMessage()

Retourne le message correspondant à la dernière erreur survenue lors de l'utilisation de l'ecran.

display→get_errorType()

Retourne le code d'erreur correspondant à la dernière erreur survenue lors de l'utilisation de l'ecran.

display→get_friendlyName()

Retourne un identifiant global de l'ecran au format NOM_MODULE.NOM_FONCTION.

display→get_functionDescriptor()

Retourne un identifiant unique de type YFUN_DESCR correspondant à la fonction.

display→get_functionId()

Retourne l'identifiant matériel de l'ecran, sans référence au module.

display→get_hardwareId()

Retourne l'identifiant matériel unique de l'ecran au format SERIAL.FUNCTIONID.

display→get_layerCount()

Retourne le nombre des couches affichables disponibles.

display→get_layerHeight()

Retourne la hauteur des couches affichables, en pixels.

display→get_layerWidth()

Retourne la largeur des couches affichables, en pixels.

display→get_logicalName()

Retourne le nom logique de l'ecran.

display→get_module()

Retourne l'objet YModule correspondant au module Yoctopuce qui héberge la fonction.

display→get_module_async(callback, context)

Retourne l'objet YModule correspondant au module Yoctopuce qui héberge la fonction.

display→get_orientation()

Retourne l'orientation sélectionnée pour l'écran.

display→get_startupSeq()

Retourne le nom de la séquence à jouer à la mise sous tension de l'écran.

display→get_userData()

Retourne le contenu de l'attribut userData, précédemment stocké à l'aide de la méthode set_userData.

display→isOnline()

Vérifie si le module hébergeant l'ecran est joignable, sans déclencher d'erreur.

display→isOnline_async(callback, context)

Vérifie si le module hébergeant l'ecran est joignable, sans déclencher d'erreur.

display→load(msValidity)

Met en cache les valeurs courantes de l'ecran, avec une durée de validité spécifiée.

display→load_async(msValidity, callback, context)

Met en cache les valeurs courantes de l'ecran, avec une durée de validité spécifiée.

display→newSequence()

Enclanche l'enregistrement de toutes les commandes d'affichage suivantes dans une séquence, qui pourra être rejouée ultérieurement.

display→nextDisplay()

Continue l'énumération des écran commencée à l'aide de yFirstDisplay().

display→pauseSequence(delay_ms)

Attend pour la durée spécifiée (en millisecondes) avant de jouer les commandes suivantes de la séquence active.

display→playSequence(sequenceName)

Joue une séquence d'affichage préalablement enregistrée à l'aide des méthodes newSequence() et saveSequence().

display→registerValueCallback(callback)

Enregistre la fonction de callback qui est appelée à chaque changement de la valeur publiée.

display→resetAll()

Efface le contenu de l'écran et remet toutes les couches à leur état initial.

display→saveSequence(sequenceName)

Termine l'enregistrement d'une séquence et la sauvegarde sur la mémoire interne de l'écran, sous le nom choisi.

display→set_brightness(newval)

Modifie la luminositéde l'écran.

display→set_enabled(newval)

Modifie l'état d'activité de l'écran.

display→set_logicalName(newval)

Modifie le nom logique de l'ecran.

display→set_orientation(newval)

Modifie l'orientation de l'écran.

display→set_startupSeq(newval)

Modifie le nom de la séquence à jouer à la mise sous tension de l'écran.

display→set_userData(data)

Enregistre un contexte libre dans l'attribut userData de la fonction, afin de le retrouver plus tard à l'aide de la méthode get_userData.

display→stopSequence(sequenceName)

Arrête immédiatement la séquence d'affichage actuellement jouée sur l'écran.

display→swapLayerContent(layerIdA, layerIdB)

Permute le contentu de deux couches d'affichage.

display→upload(pathname, content)

Télécharge un contenu arbitraire (par exemple une image GIF) vers le système de fichier de l'écran, au chemin d'accès spécifié.

display→wait_async(callback, context)

Attend que toutes les commandes asynchrones en cours d'exécution sur le module soient terminées, et appelle le callback passé en paramètre.

YDisplay.FindDisplay()
yFindDisplay()
yFindDisplay()YDisplay.FindDisplay()yFindDisplay()yFindDisplay()yFindDisplay()yFindDisplay()yFindDisplay()YDisplay.FindDisplay()YDisplay.FindDisplay()YDisplay.FindDisplay()

Permet de retrouver un ecran d'après un identifiant donné.

js
function yFindDisplay(func)
nodejs
function FindDisplay(func)
php
function yFindDisplay($func)
cpp
YDisplay* yFindDisplay(string func)
m
+(YDisplay*) yFindDisplay: (NSString*) func
pas
function yFindDisplay(func: string): TYDisplay
vb
function yFindDisplay(ByVal func As String) As YDisplay
cs
YDisplay FindDisplay(string func)
java
YDisplay FindDisplay(String func)
py
def FindDisplay(func)

L'identifiant peut être spécifié sous plusieurs formes:

Cette fonction n'exige pas que l'ecran soit en ligne au moment ou elle est appelée, l'objet retourné sera néanmoins valide. Utiliser la méthode YDisplay.isOnline() pour tester si l'ecran est utilisable à un moment donné. En cas d'ambiguïté lorsqu'on fait une recherche par nom logique, aucune erreur ne sera notifiée: la première instance trouvée sera renvoyée. La recherche se fait d'abord par nom matériel, puis par nom logique.

Paramètres :

funcune chaîne de caractères qui référence l'ecran sans ambiguïté

Retourne :

un objet de classe YDisplay qui permet ensuite de contrôler l'ecran.

YDisplay.FirstDisplay()
yFirstDisplay()
yFirstDisplay()YDisplay.FirstDisplay()yFirstDisplay()yFirstDisplay()yFirstDisplay()yFirstDisplay()yFirstDisplay()YDisplay.FirstDisplay()YDisplay.FirstDisplay()YDisplay.FirstDisplay()

Commence l'énumération des écran accessibles par la librairie.

js
function yFirstDisplay()
nodejs
function FirstDisplay()
php
function yFirstDisplay()
cpp
YDisplay* yFirstDisplay()
m
YDisplay* yFirstDisplay()
pas
function yFirstDisplay(): TYDisplay
vb
function yFirstDisplay() As YDisplay
cs
YDisplay FirstDisplay()
java
YDisplay FirstDisplay()
py
def FirstDisplay()

Utiliser la fonction YDisplay.nextDisplay() pour itérer sur les autres écran.

Retourne :

un pointeur sur un objet YDisplay, correspondant à le premier écran accessible en ligne, ou null si il n'y a pas de écran disponibles.

display→copyLayerContent()display.copyLayerContent()display.copyLayerContent()display→copyLayerContent()display→copyLayerContent()[display copyLayerContent: ]display.copyLayerContent()display.copyLayerContent()display.copyLayerContent()display.copyLayerContent()display.copyLayerContent()YDisplay copyLayerContent

Copie le contentu d'un couche d'affichage vers une autre couche.

js
function copyLayerContent(srcLayerId, dstLayerId)
nodejs
function copyLayerContent(srcLayerId, dstLayerId)
php
function copyLayerContent($srcLayerId, $dstLayerId)
cpp
int copyLayerContent(int srcLayerId, int dstLayerId)
m
-(int) copyLayerContent: (int) srcLayerId
  : (int) dstLayerId
pas
function copyLayerContent(srcLayerId: LongInt,
  dstLayerId: LongInt): LongInt
vb
function copyLayerContent() As Integer
cs
int copyLayerContent(int srcLayerId, int dstLayerId)
java
int copyLayerContent(int srcLayerId, int dstLayerId)
py
def copyLayerContent(srcLayerId, dstLayerId)
cmd
YDisplay target copyLayerContent srcLayerId dstLayerId

La couleur et la transparence de tous les pixels de la couche de destination sont changés pour correspondre à la couche source. Cette méthode modifie le contenu affiché, mais n'a aucun effet sur les propriétés de l'objet layer lui-même. Notez que la couche zéro n'a pas de transparence (elle est toujours opaque).

Paramètres :

srcLayerIdl'identifiant de la couche d'origine (un chiffre parmi 0..layerCount-1)
dstLayerIdl'identifiant de la couche de destination (un chiffre parmi 0..layerCount-1)

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→describe()display.describe()display.describe()display→describe()display→describe()[display describe]display.describe()display.describe()display.describe()display.describe()display.describe()

Retourne un court texte décrivant l'ecran au format TYPE(NAME)=SERIAL.FUNCTIONID.

js
function describe()
nodejs
function describe()
php
function describe()
cpp
string describe()
m
-(NSString*) describe
pas
function describe(): string
vb
function describe() As String
cs
string describe()
java
String describe()
py
def describe()

Plus précisément, TYPE correspond au type de fonction, NAME correspond au nom utilsé lors du premier accès a la fonction, SERIAL correspond au numéro de série du module si le module est connecté, ou "unresolved" sinon, et FUNCTIONID correspond à l'identifiant matériel de la fonction si le module est connecté. Par exemple, La methode va retourner Relay(MyCustomName.relay1)=RELAYLO1-123456.relay1 si le module est déjà connecté ou Relay(BadCustomeName.relay1)=unresolved si le module n'est pas déjà connecté. Cette methode ne declenche aucune transaction USB ou TCP et peut donc être utilisé dans un debuggeur.

Retourne :

une chaîne de caractères décrivant l'ecran (ex: Relay(MyCustomName.relay1)=RELAYLO1-123456.relay1)

display→fade()display.fade()display.fade()display→fade()display→fade()[display fade: ]display.fade()display.fade()display.fade()display.fade()display.fade()YDisplay fade

Change la luminosité de l'écran en douceur, pour produire un effet de fade-in ou fade-out.

js
function fade(brightness, duration)
nodejs
function fade(brightness, duration)
php
function fade($brightness, $duration)
cpp
int fade(int brightness, int duration)
m
-(int) fade: (int) brightness : (int) duration
pas
function fade(brightness: LongInt, duration: LongInt): LongInt
vb
function fade() As Integer
cs
int fade(int brightness, int duration)
java
int fade(int brightness, int duration)
py
def fade(brightness, duration)
cmd
YDisplay target fade brightness duration

Paramètres :

brightnessnouvelle valeur de luminosité de l'écran
durationdurée en millisecondes de la transition.

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→get_advertisedValue()
display→advertisedValue()
display.get_advertisedValue()display.get_advertisedValue()display→get_advertisedValue()display→get_advertisedValue()[display advertisedValue]display.get_advertisedValue()display.get_advertisedValue()display.get_advertisedValue()display.get_advertisedValue()display.get_advertisedValue()YDisplay get_advertisedValue

Retourne la valeur courante de l'ecran (pas plus de 6 caractères).

js
function get_advertisedValue()
nodejs
function get_advertisedValue()
php
function get_advertisedValue()
cpp
string get_advertisedValue()
m
-(NSString*) advertisedValue
pas
function get_advertisedValue(): string
vb
function get_advertisedValue() As String
cs
string get_advertisedValue()
java
String get_advertisedValue()
py
def get_advertisedValue()
cmd
YDisplay target get_advertisedValue

Retourne :

une chaîne de caractères représentant la valeur courante de l'ecran (pas plus de 6 caractères). En cas d'erreur, déclenche une exception ou retourne Y_ADVERTISEDVALUE_INVALID.

display→get_brightness()
display→brightness()
display.get_brightness()display.get_brightness()display→get_brightness()display→get_brightness()[display brightness]display.get_brightness()display.get_brightness()display.get_brightness()display.get_brightness()display.get_brightness()YDisplay get_brightness

Retourne la luminosité des leds informatives du module (valeur entre 0 et 100).

js
function get_brightness()
nodejs
function get_brightness()
php
function get_brightness()
cpp
int get_brightness()
m
-(int) brightness
pas
function get_brightness(): LongInt
vb
function get_brightness() As Integer
cs
int get_brightness()
java
int get_brightness()
py
def get_brightness()
cmd
YDisplay target get_brightness

Retourne :

un entier représentant la luminosité des leds informatives du module (valeur entre 0 et 100)

En cas d'erreur, déclenche une exception ou retourne Y_BRIGHTNESS_INVALID.

display→get_displayHeight()
display→displayHeight()
display.get_displayHeight()display.get_displayHeight()display→get_displayHeight()display→get_displayHeight()[display displayHeight]display.get_displayHeight()display.get_displayHeight()display.get_displayHeight()display.get_displayHeight()display.get_displayHeight()YDisplay get_displayHeight

Retourne la hauteur de l'écran, en pixels.

js
function get_displayHeight()
nodejs
function get_displayHeight()
php
function get_displayHeight()
cpp
int get_displayHeight()
m
-(int) displayHeight
pas
function get_displayHeight(): LongInt
vb
function get_displayHeight() As Integer
cs
int get_displayHeight()
java
int get_displayHeight()
py
def get_displayHeight()
cmd
YDisplay target get_displayHeight

Retourne :

un entier représentant la hauteur de l'écran, en pixels

En cas d'erreur, déclenche une exception ou retourne Y_DISPLAYHEIGHT_INVALID.

display→get_displayLayer()
display→displayLayer()
display.get_displayLayer()display.get_displayLayer()display→get_displayLayer()display→get_displayLayer()[display displayLayer: ]display.get_displayLayer()display.get_displayLayer()display.get_displayLayer()

Retourne un objet YDisplayLayer utilisable pour dessiner sur la couche d'affichage correspondante.

js
function get_displayLayer(layerId)
nodejs
function get_displayLayer(layerId)
php
function get_displayLayer($layerId)
cpp
YDisplayLayer* get_displayLayer(unsigned layerId)
m
-(YDisplayLayer*) displayLayer: (unsigned) layerId
vb
function get_displayLayer() As YDisplayLayer
cs
YDisplayLayer get_displayLayer(int layerId)
java
synchronized YDisplayLayer get_displayLayer(int layerId)

Le contenu n'est visible sur l'écran que lorsque la couche est active sur l'écran (et non masquée par une couche supérieure).

Paramètres :

layerIdl'identifiant de la couche d'affichage désirée (un chiffre parmi 0..layerCount-1)

Retourne :

un objet YDisplayLayer

En cas d'erreur, déclenche une exception ou retourne null.

display→get_displayType()
display→displayType()
display.get_displayType()display.get_displayType()display→get_displayType()display→get_displayType()[display displayType]display.get_displayType()display.get_displayType()display.get_displayType()display.get_displayType()display.get_displayType()YDisplay get_displayType

Retourne le type de l'écran: monochrome, niveaux de gris ou couleur.

js
function get_displayType()
nodejs
function get_displayType()
php
function get_displayType()
cpp
Y_DISPLAYTYPE_enum get_displayType()
m
-(Y_DISPLAYTYPE_enum) displayType
pas
function get_displayType(): Integer
vb
function get_displayType() As Integer
cs
int get_displayType()
java
int get_displayType()
py
def get_displayType()
cmd
YDisplay target get_displayType

Retourne :

une valeur parmi Y_DISPLAYTYPE_MONO, Y_DISPLAYTYPE_GRAY et Y_DISPLAYTYPE_RGB représentant le type de l'écran: monochrome, niveaux de gris ou couleur

En cas d'erreur, déclenche une exception ou retourne Y_DISPLAYTYPE_INVALID.

display→get_displayWidth()
display→displayWidth()
display.get_displayWidth()display.get_displayWidth()display→get_displayWidth()display→get_displayWidth()[display displayWidth]display.get_displayWidth()display.get_displayWidth()display.get_displayWidth()display.get_displayWidth()display.get_displayWidth()YDisplay get_displayWidth

Retourne la largeur de l'écran, en pixels.

js
function get_displayWidth()
nodejs
function get_displayWidth()
php
function get_displayWidth()
cpp
int get_displayWidth()
m
-(int) displayWidth
pas
function get_displayWidth(): LongInt
vb
function get_displayWidth() As Integer
cs
int get_displayWidth()
java
int get_displayWidth()
py
def get_displayWidth()
cmd
YDisplay target get_displayWidth

Retourne :

un entier représentant la largeur de l'écran, en pixels

En cas d'erreur, déclenche une exception ou retourne Y_DISPLAYWIDTH_INVALID.

display→get_enabled()
display→enabled()
display.get_enabled()display.get_enabled()display→get_enabled()display→get_enabled()[display enabled]display.get_enabled()display.get_enabled()display.get_enabled()display.get_enabled()display.get_enabled()YDisplay get_enabled

Retourne vrai si le l'ecran est alimenté, faux sinon.

js
function get_enabled()
nodejs
function get_enabled()
php
function get_enabled()
cpp
Y_ENABLED_enum get_enabled()
m
-(Y_ENABLED_enum) enabled
pas
function get_enabled(): Integer
vb
function get_enabled() As Integer
cs
int get_enabled()
java
int get_enabled()
py
def get_enabled()
cmd
YDisplay target get_enabled

Retourne :

soit Y_ENABLED_FALSE, soit Y_ENABLED_TRUE, selon vrai si le l'ecran est alimenté, faux sinon

En cas d'erreur, déclenche une exception ou retourne Y_ENABLED_INVALID.

display→get_errorMessage()
display→errorMessage()
display.get_errorMessage()display.get_errorMessage()display→get_errorMessage()display→get_errorMessage()[display errorMessage]display.get_errorMessage()display.get_errorMessage()display.get_errorMessage()display.get_errorMessage()display.get_errorMessage()

Retourne le message correspondant à la dernière erreur survenue lors de l'utilisation de l'ecran.

js
function get_errorMessage()
nodejs
function get_errorMessage()
php
function get_errorMessage()
cpp
string get_errorMessage()
m
-(NSString*) errorMessage
pas
function get_errorMessage(): string
vb
function get_errorMessage() As String
cs
string get_errorMessage()
java
String get_errorMessage()
py
def get_errorMessage()

Cette méthode est principalement utile lorsque la librairie Yoctopuce est utilisée en désactivant la gestion des exceptions.

Retourne :

une chaîne de caractères correspondant au message de la dernière erreur qui s'est produit lors de l'utilisation de l'ecran.

display→get_errorType()
display→errorType()
display.get_errorType()display.get_errorType()display→get_errorType()display→get_errorType()display.get_errorType()display.get_errorType()display.get_errorType()display.get_errorType()display.get_errorType()

Retourne le code d'erreur correspondant à la dernière erreur survenue lors de l'utilisation de l'ecran.

js
function get_errorType()
nodejs
function get_errorType()
php
function get_errorType()
cpp
YRETCODE get_errorType()
pas
function get_errorType(): YRETCODE
vb
function get_errorType() As YRETCODE
cs
YRETCODE get_errorType()
java
int get_errorType()
py
def get_errorType()

Cette méthode est principalement utile lorsque la librairie Yoctopuce est utilisée en désactivant la gestion des exceptions.

Retourne :

un nombre correspondant au code de la dernière erreur qui s'est produit lors de l'utilisation de l'ecran.

display→get_friendlyName()
display→friendlyName()
display.get_friendlyName()display.get_friendlyName()display→get_friendlyName()display→get_friendlyName()[display friendlyName]display.get_friendlyName()display.get_friendlyName()display.get_friendlyName()

Retourne un identifiant global de l'ecran au format NOM_MODULE.NOM_FONCTION.

js
function get_friendlyName()
nodejs
function get_friendlyName()
php
function get_friendlyName()
cpp
string get_friendlyName()
m
-(NSString*) friendlyName
cs
string get_friendlyName()
java
String get_friendlyName()
py
def get_friendlyName()

Le chaîne retournée utilise soit les noms logiques du module et de l'ecran si ils sont définis, soit respectivement le numéro de série du module et l'identifant matériel de l'ecran (par exemple: MyCustomName.relay1)

Retourne :

une chaîne de caractères identifiant l'ecran en utilisant les noms logiques (ex: MyCustomName.relay1) En cas d'erreur, déclenche une exception ou retourne Y_FRIENDLYNAME_INVALID.

display→get_functionDescriptor()
display→functionDescriptor()
display.get_functionDescriptor()display.get_functionDescriptor()display→get_functionDescriptor()display→get_functionDescriptor()[display functionDescriptor]display.get_functionDescriptor()display.get_functionDescriptor()display.get_functionDescriptor()display.get_functionDescriptor()display.get_functionDescriptor()

Retourne un identifiant unique de type YFUN_DESCR correspondant à la fonction.

js
function get_functionDescriptor()
nodejs
function get_functionDescriptor()
php
function get_functionDescriptor()
cpp
YFUN_DESCR get_functionDescriptor()
m
-(YFUN_DESCR) functionDescriptor
pas
function get_functionDescriptor(): YFUN_DESCR
vb
function get_functionDescriptor() As YFUN_DESCR
cs
YFUN_DESCR get_functionDescriptor()
java
String get_functionDescriptor()
py
def get_functionDescriptor()

Cet identifiant peut être utilisé pour tester si deux instance de YFunction référencent physiquement la même fonction sur le même module.

Retourne :

un identifiant de type YFUN_DESCR. Si la fonction n'a jamais été contactée, la valeur retournée sera Y_FUNCTIONDESCRIPTOR_INVALID

display→get_functionId()
display→functionId()
display.get_functionId()display.get_functionId()display→get_functionId()display→get_functionId()[display functionId]display.get_functionId()display.get_functionId()display.get_functionId()display.get_functionId()

Retourne l'identifiant matériel de l'ecran, sans référence au module.

js
function get_functionId()
nodejs
function get_functionId()
php
function get_functionId()
cpp
string get_functionId()
m
-(NSString*) functionId
vb
function get_functionId() As String
cs
string get_functionId()
java
String get_functionId()
py
def get_functionId()

Par example relay1.

Retourne :

une chaîne de caractères identifiant l'ecran (ex: relay1) En cas d'erreur, déclenche une exception ou retourne Y_FUNCTIONID_INVALID.

display→get_hardwareId()
display→hardwareId()
display.get_hardwareId()display.get_hardwareId()display→get_hardwareId()display→get_hardwareId()[display hardwareId]display.get_hardwareId()display.get_hardwareId()display.get_hardwareId()display.get_hardwareId()

Retourne l'identifiant matériel unique de l'ecran au format SERIAL.FUNCTIONID.

js
function get_hardwareId()
nodejs
function get_hardwareId()
php
function get_hardwareId()
cpp
string get_hardwareId()
m
-(NSString*) hardwareId
vb
function get_hardwareId() As String
cs
string get_hardwareId()
java
String get_hardwareId()
py
def get_hardwareId()

L'identifiant unique est composé du numéro de série du module et de l'identifiant matériel de l'ecran (par example RELAYLO1-123456.relay1).

Retourne :

une chaîne de caractères identifiant l'ecran (ex: RELAYLO1-123456.relay1) En cas d'erreur, déclenche une exception ou retourne Y_HARDWAREID_INVALID.

display→get_layerCount()
display→layerCount()
display.get_layerCount()display.get_layerCount()display→get_layerCount()display→get_layerCount()[display layerCount]display.get_layerCount()display.get_layerCount()display.get_layerCount()display.get_layerCount()display.get_layerCount()YDisplay get_layerCount

Retourne le nombre des couches affichables disponibles.

js
function get_layerCount()
nodejs
function get_layerCount()
php
function get_layerCount()
cpp
int get_layerCount()
m
-(int) layerCount
pas
function get_layerCount(): LongInt
vb
function get_layerCount() As Integer
cs
int get_layerCount()
java
int get_layerCount()
py
def get_layerCount()
cmd
YDisplay target get_layerCount

Retourne :

un entier représentant le nombre des couches affichables disponibles

En cas d'erreur, déclenche une exception ou retourne Y_LAYERCOUNT_INVALID.

display→get_layerHeight()
display→layerHeight()
display.get_layerHeight()display.get_layerHeight()display→get_layerHeight()display→get_layerHeight()[display layerHeight]display.get_layerHeight()display.get_layerHeight()display.get_layerHeight()display.get_layerHeight()display.get_layerHeight()YDisplay get_layerHeight

Retourne la hauteur des couches affichables, en pixels.

js
function get_layerHeight()
nodejs
function get_layerHeight()
php
function get_layerHeight()
cpp
int get_layerHeight()
m
-(int) layerHeight
pas
function get_layerHeight(): LongInt
vb
function get_layerHeight() As Integer
cs
int get_layerHeight()
java
int get_layerHeight()
py
def get_layerHeight()
cmd
YDisplay target get_layerHeight

Retourne :

un entier représentant la hauteur des couches affichables, en pixels

En cas d'erreur, déclenche une exception ou retourne Y_LAYERHEIGHT_INVALID.

display→get_layerWidth()
display→layerWidth()
display.get_layerWidth()display.get_layerWidth()display→get_layerWidth()display→get_layerWidth()[display layerWidth]display.get_layerWidth()display.get_layerWidth()display.get_layerWidth()display.get_layerWidth()display.get_layerWidth()YDisplay get_layerWidth

Retourne la largeur des couches affichables, en pixels.

js
function get_layerWidth()
nodejs
function get_layerWidth()
php
function get_layerWidth()
cpp
int get_layerWidth()
m
-(int) layerWidth
pas
function get_layerWidth(): LongInt
vb
function get_layerWidth() As Integer
cs
int get_layerWidth()
java
int get_layerWidth()
py
def get_layerWidth()
cmd
YDisplay target get_layerWidth

Retourne :

un entier représentant la largeur des couches affichables, en pixels

En cas d'erreur, déclenche une exception ou retourne Y_LAYERWIDTH_INVALID.

display→get_logicalName()
display→logicalName()
display.get_logicalName()display.get_logicalName()display→get_logicalName()display→get_logicalName()[display logicalName]display.get_logicalName()display.get_logicalName()display.get_logicalName()display.get_logicalName()display.get_logicalName()YDisplay get_logicalName

Retourne le nom logique de l'ecran.

js
function get_logicalName()
nodejs
function get_logicalName()
php
function get_logicalName()
cpp
string get_logicalName()
m
-(NSString*) logicalName
pas
function get_logicalName(): string
vb
function get_logicalName() As String
cs
string get_logicalName()
java
String get_logicalName()
py
def get_logicalName()
cmd
YDisplay target get_logicalName

Retourne :

une chaîne de caractères représentant le nom logique de l'ecran. En cas d'erreur, déclenche une exception ou retourne Y_LOGICALNAME_INVALID.

display→get_module()
display→module()
display.get_module()display.get_module()display→get_module()display→get_module()[display module]display.get_module()display.get_module()display.get_module()display.get_module()display.get_module()

Retourne l'objet YModule correspondant au module Yoctopuce qui héberge la fonction.

js
function get_module()
nodejs
function get_module()
php
function get_module()
cpp
YModule * get_module()
m
-(YModule*) module
pas
function get_module(): TYModule
vb
function get_module() As YModule
cs
YModule get_module()
java
YModule get_module()
py
def get_module()

Si la fonction ne peut être trouvée sur aucun module, l'instance de YModule retournée ne sera pas joignable.

Retourne :

une instance de YModule

display→get_module_async()
display→module_async()
display.get_module_async()display.get_module_async()

Retourne l'objet YModule correspondant au module Yoctopuce qui héberge la fonction.

js
function get_module_async(callback, context)
nodejs
function get_module_async(callback, context)

Si la fonction ne peut être trouvée sur aucun module, l'instance de YModule retournée ne sera pas joignable.

Cette version asynchrone n'existe qu'en Javascript. Elle utilise une fonction de callback plutôt qu'une simple valeur de retour, pour éviter de bloquer la VM Javascript de Firefox, qui n'implémente pas le passage de contrôle entre threads durant les appels d'entrée/sortie bloquants.

Paramètres :

callbackfonction de callback qui sera appelée dès que le résultat sera connu. La fonction callback reçoit trois arguments: le contexte fourni par l'appelant, l'objet fonction concerné et l'instance demandée de YModule
contextcontexte fourni par l'appelant, et qui sera passé tel-quel à la fonction de callback

Retourne :

rien du tout : le résultat sera passé en paramètre à la fonction de callback.

display→get_orientation()
display→orientation()
display.get_orientation()display.get_orientation()display→get_orientation()display→get_orientation()[display orientation]display.get_orientation()display.get_orientation()display.get_orientation()display.get_orientation()display.get_orientation()YDisplay get_orientation

Retourne l'orientation sélectionnée pour l'écran.

js
function get_orientation()
nodejs
function get_orientation()
php
function get_orientation()
cpp
Y_ORIENTATION_enum get_orientation()
m
-(Y_ORIENTATION_enum) orientation
pas
function get_orientation(): Integer
vb
function get_orientation() As Integer
cs
int get_orientation()
java
int get_orientation()
py
def get_orientation()
cmd
YDisplay target get_orientation

Retourne :

une valeur parmi Y_ORIENTATION_LEFT, Y_ORIENTATION_UP, Y_ORIENTATION_RIGHT et Y_ORIENTATION_DOWN représentant l'orientation sélectionnée pour l'écran

En cas d'erreur, déclenche une exception ou retourne Y_ORIENTATION_INVALID.

display→get_startupSeq()
display→startupSeq()
display.get_startupSeq()display.get_startupSeq()display→get_startupSeq()display→get_startupSeq()[display startupSeq]display.get_startupSeq()display.get_startupSeq()display.get_startupSeq()display.get_startupSeq()display.get_startupSeq()YDisplay get_startupSeq

Retourne le nom de la séquence à jouer à la mise sous tension de l'écran.

js
function get_startupSeq()
nodejs
function get_startupSeq()
php
function get_startupSeq()
cpp
string get_startupSeq()
m
-(NSString*) startupSeq
pas
function get_startupSeq(): string
vb
function get_startupSeq() As String
cs
string get_startupSeq()
java
String get_startupSeq()
py
def get_startupSeq()
cmd
YDisplay target get_startupSeq

Retourne :

une chaîne de caractères représentant le nom de la séquence à jouer à la mise sous tension de l'écran

En cas d'erreur, déclenche une exception ou retourne Y_STARTUPSEQ_INVALID.

display→get_userData()
display→userData()
display.get_userData()display.get_userData()display→get_userData()display→get_userData()[display userData]display.get_userData()display.get_userData()display.get_userData()display.get_userData()display.get_userData()

Retourne le contenu de l'attribut userData, précédemment stocké à l'aide de la méthode set_userData.

js
function get_userData()
nodejs
function get_userData()
php
function get_userData()
cpp
void * get_userData()
m
-(void*) userData
pas
function get_userData(): Tobject
vb
function get_userData() As Object
cs
object get_userData()
java
Object get_userData()
py
def get_userData()

Cet attribut n'es pas utilisé directement par l'API. Il est à la disposition de l'appelant pour stocker un contexte.

Retourne :

l'objet stocké précédemment par l'appelant.

display→isOnline()display.isOnline()display.isOnline()display→isOnline()display→isOnline()[display isOnline]display.isOnline()display.isOnline()display.isOnline()display.isOnline()display.isOnline()

Vérifie si le module hébergeant l'ecran est joignable, sans déclencher d'erreur.

js
function isOnline()
nodejs
function isOnline()
php
function isOnline()
cpp
bool isOnline()
m
-(BOOL) isOnline
pas
function isOnline(): boolean
vb
function isOnline() As Boolean
cs
bool isOnline()
java
boolean isOnline()
py
def isOnline()

Si les valeurs des attributs en cache de l'ecran sont valides au moment de l'appel, le module est considéré joignable. Cette fonction ne cause en aucun cas d'exception, quelle que soit l'erreur qui pourrait se produire lors de la vérification de joignabilité.

Retourne :

true si l'ecran est joignable, false sinon

display→isOnline_async()display.isOnline_async()display.isOnline_async()

Vérifie si le module hébergeant l'ecran est joignable, sans déclencher d'erreur.

js
function isOnline_async(callback, context)
nodejs
function isOnline_async(callback, context)

Si les valeurs des attributs en cache de l'ecran sont valides au moment de l'appel, le module est considéré joignable. Cette fonction ne cause en aucun cas d'exception, quelle que soit l'erreur qui pourrait se produire lors de la vérification de joignabilité.

Cette version asynchrone n'existe qu'en Javascript. Elle utilise une fonction de callback plutôt qu'une simple valeur de retour, pour éviter de bloquer la machine virtuelle Javascript avec une attente active.

Paramètres :

callbackfonction de callback qui sera appelée dès que le résultat sera connu. La fonction callback reçoit trois arguments: le contexte fourni par l'appelant, l'objet fonction concerné et le résultat booléen
contextcontexte fourni par l'appelant, et qui sera passé tel-quel à la fonction de callback

Retourne :

rien du tout : le résultat sera passé en paramètre à la fonction de callback.

display→load()display.load()display.load()display→load()display→load()[display load: ]display.load()display.load()display.load()display.load()display.load()

Met en cache les valeurs courantes de l'ecran, avec une durée de validité spécifiée.

js
function load(msValidity)
nodejs
function load(msValidity)
php
function load($msValidity)
cpp
YRETCODE load(int msValidity)
m
-(YRETCODE) load: (int) msValidity
pas
function load(msValidity: integer): YRETCODE
vb
function load(ByVal msValidity As Integer) As YRETCODE
cs
YRETCODE load(int msValidity)
java
int load(long msValidity)
py
def load(msValidity)

Par défaut, lorsqu'on accède à un module, tous les attributs des fonctions du module sont automatiquement mises en cache pour la durée standard (5 ms). Cette méthode peut être utilisée pour marquer occasionellement les données cachées comme valides pour une plus longue période, par exemple dans le but de réduire le trafic réseau.

Paramètres :

msValidityun entier correspondant à la durée de validité attribuée aux les paramètres chargés, en millisecondes

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→load_async()display.load_async()display.load_async()

Met en cache les valeurs courantes de l'ecran, avec une durée de validité spécifiée.

js
function load_async(msValidity, callback, context)
nodejs
function load_async(msValidity, callback, context)

Par défaut, lorsqu'on accède à un module, tous les attributs des fonctions du module sont automatiquement mises en cache pour la durée standard (5 ms). Cette méthode peut être utilisée pour marquer occasionellement les données cachées comme valides pour une plus longue période, par exemple dans le but de réduire le trafic réseau.

Cette version asynchrone n'existe qu'en Javascript. Elle utilise une fonction de callback plutôt qu'une simple valeur de retour, pour éviter de bloquer la machine virtuelle Javascript avec une attente active.

Paramètres :

msValidityun entier correspondant à la durée de validité attribuée aux les paramètres chargés, en millisecondes
callbackfonction de callback qui sera appelée dès que le résultat sera connu. La fonction callback reçoit trois arguments: le contexte fourni par l'appelant, l'objet fonction concerné et le code d'erreur (ou YAPI_SUCCESS)
contextcontexte fourni par l'appelant, et qui sera passé tel-quel à la fonction de callback

Retourne :

rien du tout : le résultat sera passé en paramètre à la fonction de callback.

display→newSequence()display.newSequence()display.newSequence()display→newSequence()display→newSequence()[display newSequence]display.newSequence()display.newSequence()display.newSequence()display.newSequence()display.newSequence()YDisplay newSequence

Enclanche l'enregistrement de toutes les commandes d'affichage suivantes dans une séquence, qui pourra être rejouée ultérieurement.

js
function newSequence()
nodejs
function newSequence()
php
function newSequence()
cpp
int newSequence()
m
-(int) newSequence
pas
function newSequence(): LongInt
vb
function newSequence() As Integer
cs
int newSequence()
java
int newSequence()
py
def newSequence()
cmd
YDisplay target newSequence

Le nom de la séquence sera donné au moment de l'appel à saveSequence(), une fois la séquence terminée.

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→nextDisplay()display.nextDisplay()display.nextDisplay()display→nextDisplay()display→nextDisplay()[display nextDisplay]display.nextDisplay()display.nextDisplay()display.nextDisplay()display.nextDisplay()display.nextDisplay()

Continue l'énumération des écran commencée à l'aide de yFirstDisplay().

js
function nextDisplay()
nodejs
function nextDisplay()
php
function nextDisplay()
cpp
YDisplay * nextDisplay()
m
-(YDisplay*) nextDisplay
pas
function nextDisplay(): TYDisplay
vb
function nextDisplay() As YDisplay
cs
YDisplay nextDisplay()
java
YDisplay nextDisplay()
py
def nextDisplay()

Retourne :

un pointeur sur un objet YDisplay accessible en ligne, ou null lorsque l'énumération est terminée.

display→pauseSequence()display.pauseSequence()display.pauseSequence()display→pauseSequence()display→pauseSequence()[display pauseSequence: ]display.pauseSequence()display.pauseSequence()display.pauseSequence()display.pauseSequence()display.pauseSequence()YDisplay pauseSequence

Attend pour la durée spécifiée (en millisecondes) avant de jouer les commandes suivantes de la séquence active.

js
function pauseSequence(delay_ms)
nodejs
function pauseSequence(delay_ms)
php
function pauseSequence($delay_ms)
cpp
int pauseSequence(int delay_ms)
m
-(int) pauseSequence: (int) delay_ms
pas
function pauseSequence(delay_ms: LongInt): LongInt
vb
function pauseSequence() As Integer
cs
int pauseSequence(int delay_ms)
java
int pauseSequence(int delay_ms)
py
def pauseSequence(delay_ms)
cmd
YDisplay target pauseSequence delay_ms

Cette méthode peut être utilisée lors de l'enregistrement d'une séquence d'affichage, pour insérer une attente mesurée lors de l'exécution (mais sans effet immédiat). Cette méthode peut aussi être appelée dynamiquement pendant l'exécution d'une séquence enregistrée, pour suspendre temporairement ou reprendre l'exécution. Pour annuler une attente, appelez simplement la méthode avec une attente de zéro.

Paramètres :

delay_msla durée de l'attente, en millisecondes

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→playSequence()display.playSequence()display.playSequence()display→playSequence()display→playSequence()[display playSequence: ]display.playSequence()display.playSequence()display.playSequence()display.playSequence()display.playSequence()YDisplay playSequence

Joue une séquence d'affichage préalablement enregistrée à l'aide des méthodes newSequence() et saveSequence().

js
function playSequence(sequenceName)
nodejs
function playSequence(sequenceName)
php
function playSequence($sequenceName)
cpp
int playSequence(string sequenceName)
m
-(int) playSequence: (NSString*) sequenceName
pas
function playSequence(sequenceName: string): LongInt
vb
function playSequence() As Integer
cs
int playSequence(string sequenceName)
java
int playSequence(String sequenceName)
py
def playSequence(sequenceName)
cmd
YDisplay target playSequence sequenceName

Paramètres :

sequenceNamele nom de la nouvelle séquence créée

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→registerValueCallback()display.registerValueCallback()display.registerValueCallback()display→registerValueCallback()display→registerValueCallback()[display registerValueCallback: ]display.registerValueCallback()display.registerValueCallback()display.registerValueCallback()display.registerValueCallback()display.registerValueCallback()

Enregistre la fonction de callback qui est appelée à chaque changement de la valeur publiée.

js
function registerValueCallback(callback)
nodejs
function registerValueCallback(callback)
php
function registerValueCallback($callback)
cpp
int registerValueCallback(YDisplayValueCallback callback)
m
-(int) registerValueCallback: (YDisplayValueCallback) callback
pas
function registerValueCallback(callback: TYDisplayValueCallback): LongInt
vb
function registerValueCallback() As Integer
cs
int registerValueCallback(ValueCallback callback)
java
int registerValueCallback(UpdateCallback callback)
py
def registerValueCallback(callback)

Ce callback n'est appelé que durant l'exécution de ySleep ou yHandleEvents. Cela permet à l'appelant de contrôler quand les callback peuvent se produire. Il est important d'appeler l'une de ces deux fonctions périodiquement pour garantir que les callback ne soient pas appelés trop tard. Pour désactiver un callback, il suffit d'appeler cette méthode en lui passant un pointeur nul.

Paramètres :

callbackla fonction de callback à rappeler, ou un pointeur nul. La fonction de callback doit accepter deux arguments: l'object fonction dont la valeur a changé, et la chaîne de caractère décrivant la nouvelle valeur publiée.

display→resetAll()display.resetAll()display.resetAll()display→resetAll()display→resetAll()[display resetAll]display.resetAll()display.resetAll()display.resetAll()display.resetAll()display.resetAll()YDisplay resetAll

Efface le contenu de l'écran et remet toutes les couches à leur état initial.

js
function resetAll()
nodejs
function resetAll()
php
function resetAll()
cpp
int resetAll()
m
-(int) resetAll
pas
function resetAll(): LongInt
vb
function resetAll() As Integer
cs
int resetAll()
java
int resetAll()
py
def resetAll()
cmd
YDisplay target resetAll

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→saveSequence()display.saveSequence()display.saveSequence()display→saveSequence()display→saveSequence()[display saveSequence: ]display.saveSequence()display.saveSequence()display.saveSequence()display.saveSequence()display.saveSequence()YDisplay saveSequence

Termine l'enregistrement d'une séquence et la sauvegarde sur la mémoire interne de l'écran, sous le nom choisi.

js
function saveSequence(sequenceName)
nodejs
function saveSequence(sequenceName)
php
function saveSequence($sequenceName)
cpp
int saveSequence(string sequenceName)
m
-(int) saveSequence: (NSString*) sequenceName
pas
function saveSequence(sequenceName: string): LongInt
vb
function saveSequence() As Integer
cs
int saveSequence(string sequenceName)
java
int saveSequence(String sequenceName)
py
def saveSequence(sequenceName)
cmd
YDisplay target saveSequence sequenceName

La séquence peut être rejouée ultérieurement à l'aide de la méthode playSequence().

Paramètres :

sequenceNamele nom de la nouvelle séquence créée

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→set_brightness()
display→setBrightness()
display.set_brightness()display.set_brightness()display→set_brightness()display→set_brightness()[display setBrightness: ]display.set_brightness()display.set_brightness()display.set_brightness()display.set_brightness()display.set_brightness()YDisplay set_brightness

Modifie la luminositéde l'écran.

js
function set_brightness(newval)
nodejs
function set_brightness(newval)
php
function set_brightness($newval)
cpp
int set_brightness(int newval)
m
-(int) setBrightness: (int) newval
pas
function set_brightness(newval: LongInt): integer
vb
function set_brightness(ByVal newval As Integer) As Integer
cs
int set_brightness(int newval)
java
int set_brightness(int newval)
py
def set_brightness(newval)
cmd
YDisplay target set_brightness newval

Le paramêtre est une valeur entre 0 et 100. N'oubliez pas d'appeler la méthode saveToFlash() du module si le réglage doit être préservé.

Paramètres :

newvalun entier représentant la luminositéde l'écran

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→set_enabled()
display→setEnabled()
display.set_enabled()display.set_enabled()display→set_enabled()display→set_enabled()[display setEnabled: ]display.set_enabled()display.set_enabled()display.set_enabled()display.set_enabled()display.set_enabled()YDisplay set_enabled

Modifie l'état d'activité de l'écran.

js
function set_enabled(newval)
nodejs
function set_enabled(newval)
php
function set_enabled($newval)
cpp
int set_enabled(Y_ENABLED_enum newval)
m
-(int) setEnabled: (Y_ENABLED_enum) newval
pas
function set_enabled(newval: Integer): integer
vb
function set_enabled(ByVal newval As Integer) As Integer
cs
int set_enabled(int newval)
java
int set_enabled(int newval)
py
def set_enabled(newval)
cmd
YDisplay target set_enabled newval

Paramètres :

newvalsoit Y_ENABLED_FALSE, soit Y_ENABLED_TRUE, selon l'état d'activité de l'écran

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→set_logicalName()
display→setLogicalName()
display.set_logicalName()display.set_logicalName()display→set_logicalName()display→set_logicalName()[display setLogicalName: ]display.set_logicalName()display.set_logicalName()display.set_logicalName()display.set_logicalName()display.set_logicalName()YDisplay set_logicalName

Modifie le nom logique de l'ecran.

js
function set_logicalName(newval)
nodejs
function set_logicalName(newval)
php
function set_logicalName($newval)
cpp
int set_logicalName(const string& newval)
m
-(int) setLogicalName: (NSString*) newval
pas
function set_logicalName(newval: string): integer
vb
function set_logicalName(ByVal newval As String) As Integer
cs
int set_logicalName(string newval)
java
int set_logicalName(String newval)
py
def set_logicalName(newval)
cmd
YDisplay target set_logicalName newval

Vous pouvez utiliser yCheckLogicalName() pour vérifier si votre paramètre est valide. N'oubliez pas d'appeler la méthode saveToFlash() du module si le réglage doit être préservé.

Paramètres :

newvalune chaîne de caractères représentant le nom logique de l'ecran.

Retourne :

YAPI_SUCCESS si l'appel se déroule sans erreur. En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→set_orientation()
display→setOrientation()
display.set_orientation()display.set_orientation()display→set_orientation()display→set_orientation()[display setOrientation: ]display.set_orientation()display.set_orientation()display.set_orientation()display.set_orientation()display.set_orientation()YDisplay set_orientation

Modifie l'orientation de l'écran.

js
function set_orientation(newval)
nodejs
function set_orientation(newval)
php
function set_orientation($newval)
cpp
int set_orientation(Y_ORIENTATION_enum newval)
m
-(int) setOrientation: (Y_ORIENTATION_enum) newval
pas
function set_orientation(newval: Integer): integer
vb
function set_orientation(ByVal newval As Integer) As Integer
cs
int set_orientation(int newval)
java
int set_orientation(int newval)
py
def set_orientation(newval)
cmd
YDisplay target set_orientation newval

N'oubliez pas d'appeler la méthode saveToFlash() du module si le réglage doit être préservé.

Paramètres :

newvalune valeur parmi Y_ORIENTATION_LEFT, Y_ORIENTATION_UP, Y_ORIENTATION_RIGHT et Y_ORIENTATION_DOWN représentant l'orientation de l'écran

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→set_startupSeq()
display→setStartupSeq()
display.set_startupSeq()display.set_startupSeq()display→set_startupSeq()display→set_startupSeq()[display setStartupSeq: ]display.set_startupSeq()display.set_startupSeq()display.set_startupSeq()display.set_startupSeq()display.set_startupSeq()YDisplay set_startupSeq

Modifie le nom de la séquence à jouer à la mise sous tension de l'écran.

js
function set_startupSeq(newval)
nodejs
function set_startupSeq(newval)
php
function set_startupSeq($newval)
cpp
int set_startupSeq(const string& newval)
m
-(int) setStartupSeq: (NSString*) newval
pas
function set_startupSeq(newval: string): integer
vb
function set_startupSeq(ByVal newval As String) As Integer
cs
int set_startupSeq(string newval)
java
int set_startupSeq(String newval)
py
def set_startupSeq(newval)
cmd
YDisplay target set_startupSeq newval

N'oubliez pas d'appeler la méthode saveToFlash() du module si le réglage doit être préservé.

Paramètres :

newvalune chaîne de caractères représentant le nom de la séquence à jouer à la mise sous tension de l'écran

Retourne :

YAPI_SUCCESS si l'opération se déroule sans erreur.

En cas d'erreur, déclenche une exception ou retourne un code d'erreur négatif.

display→set_userData()
display→setUserData()
display.set_userData()display.set_userData()display→set_userData()display→set_userData()[display setUserData: ]display.set_userData()display.set_userData()display.set_userData()display.set_userData()display.set_userData()

Enregistre un contexte libre dans l'attribut userData de la fonction, afin de le retrouver plus tard à l'aide de la méthode get_userData.

js
function set_userData(data)
nodejs
function set_userData(data)
php
function set_userData($data)
cpp
void set_userData(void* data)
m
-(void) setUserData: (void*) data
pas
procedure set_userData(data: Tobject)
vb
procedure set_userData(ByVal data As Object)
cs
void set_userData(object data)
java
void set_userData(Object data)
py
def set_userData(data)

Cet attribut n'es pas utilisé directement par l'API. Il est à la disposition de l'appelant pour stocker un contexte.

Paramètres :

dataobjet quelconque à mémoriser

display→stopSequence()display.stopSequence()display.stopSequence()display→stopSequence()display→stopSequence()[display stopSequence]display.stopSequence()display.stopSequence()display.stopSequence()display.stopSequence()display.stopSequence()YDisplay stopSequence

Arrête immédiatement la séquence d'affichage actuellement jouée sur l'écran.

js
function stopSequence()
nodejs
function stopSequence()
php
function stopSequence()
cpp
int stopSequence()
m
-(int) stopSequence
pas
function stopSequence(): LongInt
vb
function stopSequence() As Integer
cs
int stopSequence()
java
int stopSequence()
py
def stopSequence()
cmd
YDisplay target stopSequence

L'affichage est laissé tel quel.

Paramètres :

sequenceNamele nom de la nouvelle séquence créée