Le Relais 2 x 5 V … dans l'IoT ou l'art de piloter en BLE les périphériques de la WaRP7

Le présent article s'inscrit dans la continuité des manipulations ayant permis la rédaction d'un article précédent paru dans le n°20 d'Open Silicium [1], les auteurs renverront vers celui-ci les lecteurs qui désirent avoir de plus amples connaissances sur la diversité que propose la cible utilisé dans ce numéro de Linux Magazine. Dans le premier article, il était question de découvrir la WaRP7 et ses capteurs au travers une application « IoT » minimaliste (récupération d'une température, la pression atmosphérique ainsi qu'une valeur représentant le rythme cardiaque), ceci en utilisant la connectivité Bluetooth et le frameworkQt5, le tout basé sur une distribution Yocto/OE mis à disposition par les auteurs.

Que le lecteur ne pouvant pas se procurer le premier article soit rassuré, on se permettra tout de même ici de faire des rappels (ouf !) quant aux éléments essentiels (présentation de la cible, génération et installation de l'image sur notre cible, une partie Bluetooth, puis quelques mots sur le SDK Yocto/Qt5).

1. Introduction

1.1 La cible : « WaRP7 », petit rappel

La plateforme cible [2] est composée de 2 cartes :

- Une carte « fille », qui est construite autour d'un System on Chip NXP i.MX7 Solo[3] (avec un coeur Cortex A7 + un coeur Cortex M4). De plus, cette carte embarquera la gestion de la connectivité (Wifi/BLE) ;

- Une carte « mère », qui contiendra l'ensemble des capteurs (Gyroscope, Altimètre, etc.), ainsi que l'extension MikroBUS (qui nous intéresse particulièrement dans cet article).

 

 

1.2 Construction de notre distribution « IoT »

La génération de la distribution pour notre cible, repose sur l'utilisation du BSP (Board Support Package) NXP articulé autour du projet Yocto [4] et de deux couches supplémentaires (nous ne ferons pas ici, de détails quant à l'utilisation de Yocto/OE, le lecteur pourra en outre, se référer aux différents articles parus dans les précédents numéros d'open silicium).

La première étape consiste donc à récupérer l'ensemble des sources contenues dans le BSP. Pour ce faire, NXP utilise l'utilitaire repo (outil Python développé par Google [5]), ceci afin de permettre une meilleure gestion des référentiels Git compris dans celui-ci :

Comme prévu, après récupération de notre base logicielle, nous pouvons maintenant télécharger les deux couches supplémentaires essentielles à la bonne construction de notre image.

Téléchargeons dans un premier temps la couche distribution mis à disposition par les auteurs [6], pour rappel, cette couche spécifique est intimement liée à l'article (ceci afin de ne pas se perdre dans le framework qu'est Yocto/OE) :

Dans un second temps, récupérons la couche permettant d'intégrer l'environnement Qt5 à notre distribution :

Nous voilà maintenant en possession de l'ensemble des sources. L'étape d'après consiste en la création de l'environnement, on retrouve ci-après les différentes étapes :

- création du dossier de construction warp7-build/,

- appel du script oe-init-build-env,

- mise à jour de la variable MACHINE,

- puis un prompt concernant la licence FSL EULA (à accepter).

La commande suivante s'occupera donc de nous placer dans un environnement de travail spécifique à notre plateforme de développement :

Il reste maintenant à définir les chemins vers les couches précédemment téléchargées, pour ce faire, modifions le fichier conf/bblayers.conf pour y rajouter les deux lignes suivantes :

Dernière étape avant de pouvoir lancer la construction de l'image, il nous faut spécifier la distribution utilisée (dans notre cas une distribution spécifique à l'article dérivé de la distribution poky) dans conf/local.conf, en mettant à jour la variable DISTRO :

Lançons maintenant la construction de notre image par le biais de la commande bitbake :

Après cette longue étape qu'est la construction, l'utilisateur pourra retrouver très facilement l'ensemble des fichiers utiles au bon démarrage de la plateforme (Bootloader, Kernel, RootFileSystem) dans tmp/deploy/images/imx7s-warp.

1.3 Premier Flash, premier Boot, …

Rappelons qu'afin de mettre à jour le système avec l'ensemble des binaires compilés, les étapes se déroulent comme suit :

- Connexion en liaison série (via un émulateur de terminal comme microcom), puis arrêt de l'auto-boot au niveau du bootloader (u-boot) :

- Montage de la partition eMMC côté bootloader :

- Décompression et opération de copie coté système hôte sur le device spécifique :

Une fois la copie terminée, l'utilisateur pourra redémarrer la carte pour voir apparaître la séquence de démarrage :

1.4 Activation de l'interface Bluetooth

Rappelons ici, comment attacher, initialiser et activer notre interface Bluetooth, afin que celle-ci soit accessible par les autres périphériques compatibles :

1.5 SDK Qt5

1.5.1 Génération

Nous avons évoqué lors de l'article précédent la notion de SDK et chaîne de compilation croisée (mais pas que). Ceci afin de pouvoir générer du code Qt5 sur notre cible. La commande ci-dessous permettra la génération d'un SDK générique et compatible Qt5 :

Une fois la génération terminée, le script d'installation du SDK se trouvera dans tmp/deploy/sdk.

1.5.2 Installation

Elle se fera tout simplement en exécutant le script suivant où il conviendra de spécifier le chemin d'installation (/opt/iot/sdk dans cet exemple) :

1.5.3 Intégration à l'IDE Qt creator

Afin de se voir l'environnement de compilation croisée, intégré à notre IDE préféré, il nous faudra :

- Dans Outils > Options > Compiler et Exécuter

-Puis dans la sectionCompilateurs > Ajouter , choisir« GCC »

- On donnera un nom à notre GCC spécifique (par exemple WaRP7_GLMF200),

- Puis nous spécifierons le chemin du compilateur : /opt/iot/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc

- Dans Versions de Qt, Qt est normalement automatiquement détecté. Sinon le lecteur devra ajouter le chemin vers qmake : /opt/iot/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake

- Dans Kits, il ne reste plus qu'à choisir les éléments précédemment mis en place (Compilateur et version), il sera aussi recommandé de spécifier le mkspecs « linux-oe-g++ » :

2. MikroBUS

Dans cette partie nous aborderons, dans un premier temps, le standard MikroBUS, nous présenterons autant les aspects matériels que les aspects logiciels que propose celui-ci. Nous ferons ensuite un bref tour d'horizon sur les modules que propose MikroElektronika.

2.1 Le standard : introduction

Le standard MikroBUS définit les connectiques des cartesprincipales (on parle souvent de carte mère)ainsi que celles des cartes additionnelles (add-on) utilisées pour l'interfaçage du microcontrôleur ou du microprocesseur avec les circuits et modules complémentaires. De plus, ilspécifie la disposition physique du brochage, les broches de communication et lesbroches d'alimentation utilisées.

On remarque, bien évidemment, que l'objectif de mikroBUS est de jouer sur laflexibilité matérielle, permettant ainsi un interfaçage plus facileavec un grand nombre de cartes complètes, qui plus est, standardisées (plus de 200 modèles commercialisés par MikroElektronika tout de même !), chacune avec un simple capteur (humidistance), un module radio(RFID), un écran (OLED), une connectique (RS232), ou tout autre module électronique[7].

2.2 Le standard : Description du connecteur MikroBUS

Le connecteur MikroBUS est composé de 16 broches (2x8). L'ensemble de celles-ci est toujours positionné de la même manière comme le montre la figure 2.

 

 

On retrouvera sur chaque module :

- Des broches par type de bus de communication : SPI, UART, I2C.

- 4 broches complémentaires : PWM (ou MLI en français), interruption matérielle (INT), entrée analogique (AN) et reset (RST).

- Puis un couple pour les alimentations :

- 3,3V / GND

- 5V / GND

2.3 Quelques Examples :

Il est bien évidemment compliqué de présenter ici l'ensemble des modules proposés par la firme MikroElektronika. Afin de donner au lecteur un bref aperçu des cartes disponibles, les auteurs auront choisi d'en exposer 2 au travers de cet article :

2.3.1 La « Relay Click Board » :

 

 

Cette carte embarque deux relais de puissance (G6D1AASI-5DC de référence Omron). Le pilotage vers la carte principale (dans notre cas la WaRP7) s'effectue via les broches suivantes du connecteur MikroBUS :

- Broche PWM pour le Relais 1 (RL1),

- Broche CS pour le Relais 2 (RL2).

De notre point de vue, ce ne sera ni plus ni moins que l'activation (état haut ou état bas) d'une broche GPIO (ouverture ou fermeture du relais).

2.3.2 La « custom » :

 

 

Comme remarqué précédemment, il est possible de réaliser sa propre carte autour du standard MikroBUS. Dans cet exemple, le module est composé d'un gpio expander (microchip mcp23s08) pilotable au travers d'une interface SPI (mais aussi via le bus i2c). Cette option permet d'étendre les capacités de la carte principale quand celle-ci arrive à ses limites (ou si aucune GPIO physique n'est présente sur la carte mère).

3. Jouons un peu avec la « relay click board »

Viens maintenant le temps de jouer un peu avec notre module MikroBUS, celui-ci permettant d'étendre les capacités de notre WaRP7, nous mettant ainsi des relais à disposition (ceci afin de commander par exemple une lampe, ou tout autre objet ...). Dans ce chapitre nous verrons comment les piloter de façon simpliste en accédant aux GPIO depuis l'espace utilisateur. Nous aborderons ensuite le sujet du device tree et l'accès à la configuration des GPIO depuis celui-ci.

3.1 Plug !

Insérons notre module relais et constatons qu'il est très facile d'intégration entre notre plateforme cible et les modules MikroBUS (WaRP7 <-> Relay Click Board), ceci grâce à la standardisation :

 

 

3.2 And Play !

Sous GNU/Linux, l'accès aux GPIO [8] s'effectue dans /sys/class/gpio/gpioN où N représente le numéro de la GPIO (à condition que le driver associé soit présent → GPIO_SYSFS).

Nous savons par le biais de la schématique (disponible en [2]), que le relais 1 et sur la broche CPU « GPIO7_IO8 », qui, en espace utilisateur devient gpio200.

La première étape consistera à exporter cette GPIO pour la rendre accessible depuis le système de fichier virtuel /sys, la commande si après créera donc un point d'accès gpio200 :

L'interface étant disponible, il nous faut la paramétrer en tant que broche de sortie :

Une fois configurée, il nous est possible de la piloter, ceci en agissant simplement sur la tension de sortie de la broche, via la commande suivante :

La broche de sortie passée à l'état haut, il nous est facile de constater le résultat sur la carte relais (led REL1), comme nous le montre la figure 6 :

 

 

Nous ferons de même pour le relais numéro 2 (RL2 sur la « relay click ») qui lui est sur « GPIO4_IO23 » :

 

 

3.2 Intégration au device-tree : « gpio-exporter & pin-muxing »

L'inconvénient des étapes (export/direction) précédentes réside dans le fait qu'il nous est obligatoire de les réexécuter à chaque démarrage de la WaRP7, car non statique au sein de la configuration matérielle. Il serait donc intéressant d'avoir une entrée statique. Nous irons un peu plus loin que la simple configuration des GPIO.

En effet, il serait aussi plaisant de pouvoir associer un nom à nos GPIO lors de la configuration de celles-ci, pour ce faire, nous intégrerons le travail de Martin FUZZEY[9] (qu'on ne manquera pas de remercier pour le travail effectué), qui a en effet développé un driver Kernel permettant d'avoir au sein de l'espace utilisateur, un lien nom/numérode GPIO. L'avantage de cette solution est que finalement, l'utilisateur ne se soucie plus du numéro de la GPIO, de ce fait, la configuration est beaucoup plus portable et maintenable.

3.2.1 Device tree : une petite introduction

L’arbre de périphériques (device tree ou encore DT) est une structure de données permettant de décrire le matériel d’un système, dérivée du format utilisé par Open Firmware pour encapsuler les informations de plateforme et les transmettre au noyau, qui utilise alors les données du DT pour trouver et enregistrer les périphériques du système.

La structure de données elle-même est un arbre de nœuds nommés et de propriétés. Chaque nœud contient des propriétés de simples paires « nom-valeur » et des nœuds fils. Afin d’être interprétée correctement par le noyau, l’arborescence doit suivre une structure prédéfinie. Une « liaison » (en anglais, binding) est une description de la façon dont un périphérique est décrit dans le DT. Un grand nombre de périphériques disposent de liaisons bien établies et documentées.

3.2.2 Anatomie de notre fichier dts « imx7s-warp-relay.dts »

Afin de ne pas surcharger le fichier dts (device tree source) principal (imx7s-warp.dts), les auteurs auront choisi de créer un fichier dts spécifique à l'intégration du module « relay click », en voici sa constitution :

Essayons de détailler celui-ci :

- #include "imx7s-warp.dts" fera référence au fichier principal la WaRP7 (définition de la carte), qui lui-même inclus la définition du SoC (System on Chip) i.MX7 (imx7d.dtsi).

- Au niveau du contenu du fichier :

- La création d'un nœud (node) avec son label associé, que l'on appellera gpio-exporter :

- Le mot clé compatible est une propriété qui permettra de faire le lien avec la partie driver (respectant la règle du plateform driver comme présenté par Pierre Ficheux en [10]). Ceci via la structure of_device_id qui sera utilisée avec le tableau gpio_exporter_dt_ids[]. Le lecteur curieux pourra jeter un coup d'oeil au code source dans tmp/work/imx7s_warp-poky-linux-gnueabi/linux-fslc-imx/4.1-1.0.x+gitAUTOINC+9d3f7f9343-r0/git/drivers/gpio/gpio-exporter.c :

 - La propriété pinctrl-0 permet de donner la liste des broches qui seront soumises à une définition spécifique de leur état, ceci grâce au sous-système pinctrl qui permet de gérer le multiplexage des broches. Dans notre cas, la configuration s'effectuera dans le nœud fils pinctrl_gpioexporter_relay :

 - Il convient ensuite de créer un nœud fils (child node), le nom de celui-ci représentera le nom exposé au sein de l'espace utilisateur, nous garderons la même syntaxe que la carte « relay click », à savoir RL1 pour le pilotage du relais 1 :

Il nous faudra aussi renseigner les propriétés à notre nœud fils :

- gpios : Référence vers la GPIO à exporter (binding standard défini dans les sources du Noyau Linux : Documentation/devicetree/bindings/gpio/gpio.txt). En plus du phandle (nœud vers le contrôleur associé), nous retrouverons le numéro de GPIO, 8 pour notre application. Puis le second argument signifie que celle-ci est active sur un niveau haut (GPIO_ACTIVE_HIGH).

- output : pour spécifier que l'on désire la positionner en sortie,

- initial-state : où on fixera sont état initial (état bas dans notre cas)

 Il en sera de même pour le relais numéro deux, où seul le nom du sous-nœud et de la GPIO associé seront donc à modifier pour le piloter :

Nous en resterons là quant à la présentation du fichier device tree, le lecteur pourra se référer au très bon article écrit par Thomas Petazzoni paru dans le n°17 d'Open Silicium [11].

3.3 Activation du driver Kernel

La partie device tree étant faite, il nous reste à activer le support du driver gpio-exporter au sein de notre image Kernel (zImage). Pour ce faire, nous passerons une fois de plus par l'environnement Yocto/OE, en invoquant la commande suivante :

Puis dans Devices Drivers > GPIO Support il nous faudra activer l'option comme le montre la figure 8.

 

 

Nous pourrons dès à présent relancer une phase de compilation pour générer le fichier zImage et notre nouveau fichier dtb (transformation en un fichier binaire du fichier dts), qui sera donc imx7s-warp-relay.dtb :

3.4 Intégration

Nous allons, dans cette sous-partie, mettre à jour le fichier zImage ainsi que le fichier imx7s-warp-relay.dtb sur notre cible. Pour ce faire, il sera question, ici aussi, de monter la partition eMMC en mode mass storage via u-boot. Nous finirons naturellement cette sous-partie par une phase de test sur cible.

3.4.1 zImage et .dtb

Pour la copie de la zImage :

Pour la copie du fichier dtb spécifique à la gestion du relais :

Plaçons-nous maintenant côté cible et spécifions à notre chargeur d'amorçage (u-boot dans notre cas) que nous souhaitons utiliser le nouveau fichier dtb fraichement généré (imx7s-warp-relay.dtb) intégrant la partie gpio-exporter pour la gestion de nos relais, mais nous souhaitons, dans une moindre mesure, que celui-ci soit pris en compte par défaut, ceci afin d'éviter l'obligation d'une connexion série à chaque démarrage de la cible, il nous suffit donc de faire :

Ceci surcharge la variable fdt_file, variable qui contient la référence vers le fichier dtb à utiliser (de base, imx7s-warp.dtb dans les sources de u-boot). Sauvegardons maintenant notre environnement :

Il nous est maintenant possible de démarrer notre cible via l'exécution de la commande bootcmd (qui contient une suite de commandes à exécuter au démarrage) :

3.4.2 Test en espace utilisateur

Afin de simplifier (encore plus) l'accès aux GPIO (via gpio-exporter), les auteurs auront préféré mettre en place la notion de lien symbolique afin de se créer un point d'accès dans /dev/mikrobus/*. En temps normal l'accès aux GPIO s'effectue dans /sys/devices/platform/gpio-exporter//out_RL*. Cette technique nous donnera donc le résultat suivant sur notre plateforme :

Tout comme en section précédente, nous pouvons de façon très simple, et ceci sans connaître le numéro de la GPIO, piloter nos relais (plutôt pas mal non ?) :

4. Mise en situation …

Nous clôturerons cet article sur un mini-projet (par simple habitude des auteurs) permettant ainsi au lecteur de mettre en pratique les notions évoquées tout au long de l'article. Celui-ci nous permettra d'aborder quelques nouvelles techniques, comme par exemple l'introduction au QML.

4.1 Présentation du projet

Nous nous servirons du travail effectué durant cette première partie de l' article, qui de ce fait, nous servira de base pour notre application « connectée ». Nous proposons ici de faire une évolution du serveur BLE du précédent article.

L'idée sera donc de créer :

- une application « serveur BLE », permettant le pilotage de notre carte « relay click », application qui sera sur la WaRP7.

- un client associé, qui, lui, sera sous forme d'application Android et qui enverra les données au serveur BLE (commande des relais).

La figure 9 (ci-après) illustre l'architecture globale que l'on se propose de mettre en œuvre durant cette dernière partie de l'article :

 

 

4.2 Le Serveur

Interaction avec nos GPIO

La première étape consistera à créer une fonction nous permettant d’écrire sur les GPIO. Il suffit d’utiliser la classe QFile[12] qui permet la gestion de fichiers (et oui, sous Linux tout est fichier) :

Ceci étant fait, il ne reste plus qu’à ouvrir (via l'appel open()) le fichier (avec la permission d'écriture !), écrire la valeur souhaitée (0 ou 1) puis le refermer via l'appel close() :

Dans le cas présent, « data » est de type QByteArray (simple tableau d’octets) contenant la valeur à envoyer sur notre GPIO. Nous verrons plus tard comment cette dernière est envoyée.

Et la partie BLE ?

Dans cet exemple, nous avons décidé de ne pas utiliser les services[13]/caractéristiques[14] standards proposés par le protocole Bluetooth, et de ce fait, nous avonscréé les nôtres pour les besoins de cet article, c’est bien plus ludique quand même !

La figure 10 indique comment nous allons architecturer nos données.

 

 

Il faut donc d’abord avoir nos propresUUID(Service + Caractéristiques) :

Que nous allons ensuite « caster » en QBluetoothUuid :

Les présentations étant faites, nous pouvons rentrer dans le vif du sujet, la création du serveur. Et bien, pour ce faire, rien de plus simple avec l'API proposé par Qt :

Nous déclarons dans un premier temps un « advertiser » qui définit la configuration de base de notre serveur, ceci grâce à la classe suivante :

Configurons son mode, son nom (GLMF_200_BLE) et nous y ajoutons un nouveau service (serviceRelay dans notre exemple) :

Nous créons ensuite les caractéristiques voulues (charRelay1). Le descripteur va définir la gamme de fonctionnalités de la caractéristique associée.

Puis nous les associons au service préalablement configuré. Nous définissons son type comme « Primaire » car il donne accès aux fonctionnalités standard des services :

La dernière étape arrive. Il ne reste plus qu’à créer le contrôleur, qui est, entre autres, le point d’entrée des périphériques Bluetooth. On ajoute alors le service relais à celui-ci et on démarre le serveur. Ainsi on rend la connexion possible :

Il ne reste donc plus qu’à implémenter la fonction qui traite la réception d’une donnée afin de savoir à quel relais elle s’applique et dans quel état nous devons le mettre. Il suffit assez simplement de lire l'UUID de la caractéristique reçue et de commuter celui concerné en fonction :

Le travail est fini et le serveur est ainsi prêt à fonctionner. Si le lecteur veut s’y tenter, il pourra d'ores et déjà compiler l'application pour la déployer sur la cible (bitbake ServiceRelay).Pour de plus amples informations sur la gestion des paquets/déploiement, les auteurs renverront le lecteur sur un excellent article de Pierre Ficheux[15]).

4.3 « Dans la peau du client »

Création de notre environnement

Le serveur est fonctionnel, donc prêt à être piloté. Il ne manque plus qu’à lui associer un client. L’idée ici est de proposer une application Android avec le framework Qt en QML.

 

Avant de pouvoir démarrer le projet, il faut mettre en place notre environnement. Pour cela, il est suggéré ici, de suivre le tutoriel Qt pour Android qui est très bien documenté (http://doc.qt.io/qt-5/android-support.html), qui consiste en l'installation de la chaîne de compilation Qt pour Android ainsi que le NDK et le SDK fournis par Google. Il faudra bien entendu installer Java !

Afin de ne pas sacrifier de nombreuses pages, les auteurs renverront le lecteur sur le GitHub en ce qui concerne l'ensemble des sources à télécharger. A la suite de cela, nous pouvons alors ouvrir Qt Creator et :

- Dans Tool > Options > Android, il faudra ici remplir correctement les arborescences (JDK, NDK et SDK) comme le montre la figure 11.

 

 

- Puis dans Tool > Options > Build & Run > Kits, il faudra créer le Kit associé (voir figure 12).

 

 

Un premier projet 

En premier lieu, créons notre premier projet QML (Qt Quick Application) tout en sélectionnant le Kit Android pour le futur déploiement (smartphone).

Une application QML se scinde toujours en deux parties :

- une partie C++

- une partie script QML.

Il existe donc plusieurs outils pour communiquer entre les deux couches que nous expliciterons au cours de cette partie.

La partie C++ 

Dans cette partie, nous décrirons le client Bluetooth Low Energy. Et surtout, comment envoyer une donnée au serveur.

Dans un souci de simplicité, nous avons retiré les méthodes de découverte des périphériques présents. Partons du postulat que nous connaissons déjà l’adresse (MAC) de notre serveur. Nous chercherons simplement à nous y connecter de façon directe.

Voici donc l’introduction des premières lignes de code. Le type d’adresse peut être soit « Public » soit « Random ». Le premier définit un mode de fonctionnement standard avec une adresse « statique » et le second définit un mode dans lequel l’adressage peut évoluer, c’est une sécurité dont nous n’avons pas besoin pour la suite :

La connexion n’est pas instantanée, mais une fois faite, on lance alors la découverte des services associés au périphérique :

Puis, à la réception des services, il est possible de lancer la découverte des caractéristiques associées au service via la fonction « discoverDetails() » :

Et enfin, à la réception des caractéristiques, on conserve la valeur contenue dans celles-ciet on met à jour l’interface en fonction. Les caractéristiques se reconnaîtront grâce à leurs UUID:

Le plus dur est fait et, afin d'envoyer une nouvelle valeur au serveur en vue de changer l’état d’un des deux relais, il suffira d’utiliser la fonction suivante :

A partir de là, il ne reste plus qu’à créer notre interface !

La partie QML 

Lorsque l’on crée un fichier QML, on peut soit le modifier sous la forme d’un script, soit via le designer QML de Qt. Il existe donc deux types de fichiers qml :

-  Fichier.ui.qml qui pourra être édité via l’éditeur et/ou par script,

-  Fichier.qml qui pourra être modifié uniquement par script

Généralement, les fichiers.ui.qml sont associés à un fichier.qml afin de créer les connexions vers le  C++. Dans l’exemple, nous avons créé deux fichiers .qml (associés chacun à un fichier.ui.qml) :

- main.qml : qui consiste en un simple bouton permettant d’enclencher la connexion directement avec le serveur dont l’adresse est celle spécifiée dans le code principal.

- Relay.qml : permet de piloter les deux relais.

Pour que le QML puisse communiquer avec notre classe, il faut pour ce faire, passer celle-ci en paramètre. Nous pouvons alors charger la page main.qml :

Au chargement de l’application, nous aurons donc la page main.qml qui s’affichera constituée d’un simple bouton. Pour gérer l’évènement du clique, il suffit d’utiliser le script suivant :

Afin que la fonction start soit appelée, il est nécessaire qu’elle soit invocable[16] depuis le C++ :

L’objet pageLoader permet de charger une nouvelle page QML et est défini par :

La page Relay.qml est alors chargée. Elle est composée de deux switchs qui permettront de piloter les deux relais. De la même manière, le changement d’état des switchs se gère de la façon suivante :

L’application est bientôt terminée. Nous avons vu comment inséreret appeler une fonction depuis le QML vers le C++. Il ne reste plus qu’à expliquer comment mettre à jour la parité QML avec le C++. Pour réaliser le lien, Qt propose l’utilisation des Q_PROPERTY[17] qui seront liées à des signaux de mise à jour. Par exemple, si nous voulons mettre à jour l’état d’un relais nous définirons la Q_PROPERTY suivante :

Et côté QML, la connexion au signal se fait de la manière suivante :

4.4 Le rendu final 

Pour avoir un aperçu du projet réalisé, voici ci-après le fruit du travail réalisé durant cet article. La première étape consiste au lancement de l'application (.apk disponible ici : https://github.com/bdx-iot/RelayGUI/blob/master/GLMF_200_GUI_BLE.apk)

 

 

L'étape suivante nous indique de nous connecter à notre périphérique (figure 14) :

 

 

Une fois connectés, nous avons la satisfaction de pouvoir interagir avec nos relais, lire la température du capteur Altimètre (MPL3115), mais surtout, de pouvoir jouer avec une simple ampoule comme le montre notre environnement sur la figure 15.

 

 

Agissons maintenant sur le relais 1 (figure 16) :

 

 

Puis activons le 2ème relais (figure 17) :

 

 

Rappelons une fois de plus que le lecteur pourra retrouver l'ensemble des sources sur le référentiel git suivant : https://github.com/bdx-iot. Se trouvera sur celui-ci :

- La couche « meta-iot » mise à disposition par les auteurs, comprenant :

- La recette dérivée du Kernel (gestion du fichier dts et fichier defconfig),

- La recette permettant la gestion des liens symboliques :https://github.com/bdx-iot/meta-iot/tree/master/recipes-iot/clicks-board-init

- La recette du « serveur BLE » et son script init associé (pour un démarrage automatique de l'application) : https://github.com/bdx-iot/meta-iot/tree/master/recipes-iot/service-relay

- Ainsi que d'autres recettes.

- Les sources de l'application serveur : https://github.com/bdx-iot/ServiceRelay

- Les sources de l'application client : https://github.com/bdx-iot/RelayGUI

Conclusion 

Dans cet article, nous avons découvert le standard MikroBUS et nous avons ainsi pu le mettre en application sur notre plateforme cible. De par l'intégration, nous avons d'autre part, découvert des notions comme le device tree ou encore le langage QML.

Finalement, nous avons mis en pratique l'ensemble des notions pour créer un véritable objet connecté (jusqu'à la création de la partie client pour la gestion de celui-ci), le tout basé sur du Bluetooth Low Energy. Ceci n'étant qu'une introduction au vu du potentiel, le lecteur pourra s'inspirer et imaginer d'autres applications (domotique) via les modules Mikrobus de MikroElektronika.

En parlant de domotique, n'oublions pas que cette plateforme dispose d'une interface caméra, autre périphérique qu'il serait intéressant de mettre en œuvre afin de créer un environnement connecté pour la surveillance de nos enfants (vidéo/température/gestion de la veilleuse), ceci en ne négligeant pas l'aspect low energy de notre objet bien entendu.

Références et Liens

[1] Article « A la découverte de la WaRP7 » par Pierre-Jean TEXIER et Jean CHABRERIE, Open Silicium n°20

[2] Site d'Element14 : https://www.element14.com/community/docs/DOC-79058/l/warp7-the-next-generation-iot-and-wearable-development-platform

[3] Page NXP présentant l'architecture du i.MX7 : http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx-7-processors/i.mx-7solo-processors-heterogeneous-processing-with-arm-cortex-a7-and-cortex-m4-cores:i.MX7S

[4] Documentatio du projet Yocto (version 2.1 : krogoth) : http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html

[5] Documentation relative à l'outil repo : https://source.android.com/source/using-repo.html

[6] Couche distribution des auteurs : https://github.com/bdx-iot/meta-iot

[7] Ensemble des cartes « click » par MikroElektronika : http://www.mikroe.com/click/ 

[8] Documentation dans les sources du Noyau Linux sur l'utilisation des GPIO en espace utilisateur : https://www.kernel.org/doc/Documentation/gpio/sysfs.txt

[9] Driver gpio-exporter : https://patchwork.kernel.org/patch/6207321/

[10] Article « Périphériques découvrables, découverts ou à découvrir » par Pierre FICHEUX, Open Silicium n°20

[11] Article « Introduction au « device Tree »sur ARM » par Thomas PETAZZONI, Open Silicium n°17

[12] Documentation de la classe Qfile : http://doc.qt.io/qt-5/qfile.htmlhttp://doc.qt.io/qt-5/qfile.html

[13] Spécifications des services bluetooth : https://www.bluetooth.com/specifications/gatt/services

[14] Spécifications des caractéristiques bluetooth : https://www.bluetooth.com/specifications/gatt/characteristics

[15] Article « IoT sous Yocto, un cas d'utilisation » par Pierre FICHEUX, Open Silicium n°20

[16] Explication de la macro Q_INVOKABLE : http://doc.qt.io/qt-5/qobject.html#Q_INVOKABLE

[17] Explication de la macro Q_PROPERTY : http://doc.qt.io/qt-5/qobject.html#Q_PROPERTY