Le fabricant Microchip a ajouté à son catalogue les produits à cœur AVR® depuis qu’il a acquis Atmel en 2016. C’est donc sous son égide que se poursuit l’enrichissement des familles de microcontrôleurs AVR®, et bien sûr celui des PIC®. De cet heureux mariage des savoir-faire sont nées les cartes de développement AVR-IoT WA et PIC IoT WA, deux plateformes permettant une liaison Wi-FI sécurisée avec le service web IoT Core d’Amazon.

Débuter dans le traitement et le stockage des données en ligne peut s’avérer compliqué lorsqu’on sait que ces opérations nécessitent d’établir une liaison sécurisée avec un service en ligne sans brûler toutes les réserves d’énergie dès le premier décollage vers le nuage. C’est pour aider les concepteurs à relever ce défi, mais aussi pour réduire la durée du développement, que Microchip a élaboré ces deux cartes peu énergivores. Avant d’étayer comme il se doit ces affirmations, et avant même de passer en revue le matériel et le logiciel des cartes, ouvrons tout simplement leur boîte.

Déballage

C'est difficile à deviner d’après leurs dimensions (fig. 1), mais aucune des deux boîtes ne contient de câble micro-USB. D’abord parce qu’il est probable que vous en ayez déjà un, ensuite parce que cela préserve la planète.

Figure 1. Seule l’étiquette permet de distinguer les deux boîtes.

À ma gauche, donc, la carte AVR IoT WA, référence EV15R70A et microcontrôleur ATmega4808 de la famille AVR en son cœur. À ma droite, la carte PIC IoT WA, référence EV54Y39A et microcontrôleur PIC24FJ128GA705 aux commandes. Au milieu, vous, peut-être hésitant. PIC ou AVR ? Vos préférences en matière de microcontrôleurs orienteront votre choix, mais quel qu’il soit, ce sera un choix gagnant.

Les deux cartes se ressemblent (fig. 2).

Figure 2. Les cartes AVR-IoT WA et PIC-IoT WA côte à côte.

Chacune est dotée à l’avant d’un port micro-USB (fig. 3) servant à relier le système au débogueur ou à alimenter la carte.

Figure 3. Le port micro-USB, le débogueur et le circuit de charge.

Derrière ce connecteur sont placés ledit débogueur et le circuit de charge pour batteries au lithium. Vous l’avez compris, une telle batterie permettra de transformer la carte en dispositif sans fil autonome.

Matériel

Commençons notre tour d’horizon par l’alimentation. Elle comprend un chargeur MCP73871 pour batteries Li-Ion/LiPO, circuit intégré capable de gérer directement les flux de puissance bi-directionnels (sans composant de puissance extérieur), et un régulateur de tension MIC33050 à inductance interne. Cette association de bienfaiteurs offre l’équivalent d’un chargeur de batteries de 4,2 V allié à un convertisseur CC/CC pouvant délivrer 600 mA. Le chargeur est pourvu d’un sélecteur de ligne d’alimentation et fonctionne comme une diode idéale en empêchant le courant de la batterie de retourner au port USB. Notez que sa tension de charge est de 4,2 V, et donc que seules conviennent des batteries de cette tension.

Plus à gauche sont placés un capteur de luminosité et deux CI. Le premier est un capteur de température MCP9808, l’autre un coprocesseur cryptographique ATECC608A. Ce coprocesseur sécurise les communications entre la carte et les services AWS d’Amazon, mais peut également servir à chiffrer des transactions avec d’autres services en nuage.

Élément central des cartes, le microcontrôleur est comme il se doit placé en leur centre. Le PIC24FJ128GA705 offre 128 Ko de mémoire flash ECC et 16 Ko de RAM. Cadencé à 32 MHz, il peut exécuter 16 MIPS. Ajoutons qu’il a sous ses ordres divers périphériques fort utiles et qu’il possède un mode basse consommation. 

L’ATmega4808 de la carte AVR-IoT fait quant à lui partie des membres récents de la famille AVR, d’où ses 48 Ko de mémoire flash et 6 Ko de RAM. Ses périphériques s’apparentent plus à ceux d’une puce XMEGA qu’à ceux d’une AVR classique. Il peut être cadencé à 20 MHz, exécuter 20 MIPS, se mettre en mode basse consommation, et confier des tâches avancées à ses périphériques CIP (Core Independent Peripherals).

Encore plus à gauche se trouve le module Wi-Fi ATWIN1510 (fig. 4).

Figure 4. Le module ATWINC1510.

Il fournit des ports SPI pour l’interfaçage avec un contrôleur hôte, opère dans la bande de fréquences de 2,4 Hz, et prend en charge les protocoles IEEE 802.11 b/g/n. Ce module est toutefois bien plus qu’une carte réseau Wi-Fi. C’est un coprocesseur capable de décharger le microcontrôleur de la lourde tâche du chiffrement des données et du traitement des paquets TCP/IP.

Les embases noires placées en vis-à-vis (fig. 5) sont un connecteur mikroBus pour capteurs ou actionneurs appartenant à la famille des cartes d’extension et des cartes Click de MikroElektronika, p. ex. la carte de détection de mouvement 3D Motion.

Figure 5. Le connecteur mikroBus de la carte AVR-IoT WA.

Il suffit de retirer ces embases pour accéder aux broches mikroBus et à leur fonction. Ces broches sont identifiées sur la sérigraphie des cartes (fig. 6).

Figure 6. Le marquage des broches mikroBus se trouve sur la face cuivre.

Microchip a rédigé avec le plus grand soin des guides d’utilisation pour ses deux cartes. Description détaillée du matériel, schémas de câblage, prise en main rapide, configuration, liens internet, tout y est.

Logiciel préinstallé

Sur les deux cartes sont préinstallés des exemples d’applications permettant de tester le service IoT Core d’Amazon avec un compte Microchip. Notez que ces applications utilisent des identifiants Wi-Fi publics (fournis dans le guide d’utilisation), et que donc les données envoyées à ce compte peuvent également être considérées comme publiques. Cet avertissement posé, voyons comment connecter une carte à un réseau existant. Une fois reliée à un PC, le système d’exploitation détecte la carte comme un périphérique dont le nom de volume est CURIOSITY. Le répertoire racine de ce volume contient un fichier CLICK-ME.HTM. Celui-ci envoie le navigateur vers une page d'explication des étapes de la configuration. Avant cela nous devons mettre à jour le micrologiciel du microcontrôleur (fig. 7).

Figure 7. La page de configuration CLICK-ME.htm.

Négliger cette étape serait prendre le risque de ne pas parvenir à configurer votre connexion Wi-Fi. Remarquons ici que la puce de sécurité embarquée n’est pas mise à jour par le micrologiciel et peut donc contenir des informations d’authentification obsolètes. Si vous ne parvenez pas à connecter votre carte au service IoT Core, il vous faudra mettre à jour tous les composants de la carte (cf. le paragraphe Ce que le manuel ne dit pas (encore)). Pour en revenir à la procédure normale, glissez-déposez dans le lecteur CURIOSITY le fichier .hex téléchargé depuis GitHub. Le nouveau micrologiciel sera flashé et le microcontrôleur redémarrera.

La configuration de la connexion Wi-Fi peut débuter. La page CLICK-ME.HTM vous invite à entrer vos identifiants Wi-Fi dans un formulaire dont la validation crée un fichier WIFI.CFG. Glissez-déposez ce fichier de configuration dans le lecteur CURIOSITY. Une fois la connexion à votre réseau établie, la carte échangera des données avec le service AWS (fig. 8) et affichera les valeurs des capteurs de température et de luminosité.

Figure 8. Arrivée des premières données.

MPLAB® X

Le petit bouton What’s Next? situé sous les graphiques des capteurs va nous conduire à la prochaine étape, à savoir la configuration de MPLAB X (fig. 9).

Figure 9. Sélection de la chaîne de compilation GNU AVR.

Depuis que Microchip et Atmel ont fusionné, cet environnement de développement n’est plus seulement réservé aux PIC mais prend en charge les systèmes AVR et SAM. Peut-être vous fera-t-il regretter l’interface d’Atmel Studio (qui partage avec Visual Studio le même noyau), mais au moins vous libérera-t-il de l’emprise Windows si vous préférez travailler sous Linux ou macOS puisqu’il peut être installé sur ces systèmes d’exploitation (mais uniquement sur des machines d’architecture AMD64). MPLAB X repose sur Netbeans, un EDI à l’origine pour Java mais depuis étendu à bien d’autres langages. J’ai effectué ce banc d’essai sous Windows avec la version 5.45 de MPLAB X, la plus récente lors de la rédaction de cet article. Vous aurez à installer une chaîne de compilation pour les cartes ainsi que les fichiers de prise en charge des différentes architectures.

Pour ces fichiers, le plus simple est de le faire au moment de l’installation ; si votre disque dur offre suffisamment d’espace libre, choisissez toutes les architectures supportées. En fin d’installation, le programme vous invitera à télécharger les compilateurs depuis le site de Microchip. Si vous optez pour le compilateur AVR-GCC (habituellement inclus dans Atmel Studio 7), vous devrez l’ajouter vous-même à MPLAB X (fig. 9) après l’avoir téléchargé. Sélectionnez le chemin vers le dossier où ont été extraits les fichiers du compilateur, et spécifiez bien le dossier bin, sinon la chaîne de compilation AVR8 ne sera pas trouvée. Les projets d’exemple sont compilés par défaut avec les compilateurs de la famille XC, mais l’étape précédente, bien que facultative, est pratique si l’on est habitué à la façon dont AVR-GCC opère.

Carte de développement AVR-IoT WA

L’application AVR-Iot WA écrite par Microchip va maintenant nous initier à l’usage de la carte de même nom. Téléchargez son code depuis le lien GitHub et ouvrez-le dans MPLAB X (fig. 10).

Figure 10. Affichage de la documentation sous MPLAB X.

Vous remarquerez que l’EDI affiche les ressources et les liens relatifs à votre carte si celle-ci est connectée. L’intérêt du code, outre qu’il est le support du tutoriel de Microchip, est de vous éclairer suffisamment sur le fonctionnement de la carte pour l'adapter rapidement à vos besoins particuliers. La figure 11 montre sa structure sous MPLAB X.

Figure 11. Le projet pour la carte AVR ouvert par MPLAB X.

Au moment où j’écris ceci, la dernière étape du tutoriel pour la carte AVR-IoT est en léger décalage avec le code. Si cela n’a pas été corrigé entre-temps, la figure 12 montre les changements à apporter au code pour que la LED verte fonctionne comme un actionneur.

Figure 12. Les changements à apporter au code pour l’étape 3 du tutoriel.

Une fois le code modifié et chargé dans le contrôleur, l’état de la LED se commande avec le bouton toggle de l’interface (fig. 13).

Figure 13. Le bouton toggle pour commander la LED de la carte.

Ce léger couac mis à part, tout fonctionne à merveille. La fin de ce tutoriel ne devrait pas marquer celle de votre apprentissage. Microchip a publié sur GitHub un « Guide de survie du développeur en partance pour le nuage » qui vous aiguillera vers plus de ressources et tutoriels sur l’utilisation des services web d’Amazon.

Carte de développement PIC-IoT WA

Vos premiers pas avec cette carte devraient là encore se faire avec l’application PIC-IoT WA publiée sur GitHub. Le code a la même structure que le code AVR, et le tutoriel suit les mêmes étapes. La différence est finalement surtout matérielle : des périphériques offrant plus de fonctions sur la carte PIC, plus de mémoire flash, et une quantité de RAM elle aussi légèrement supérieure (fig. 14).

Figure 14. Consommation des ressources sur une carte PIC-IoT.

Comparé à AVR, le PIC offre aussi plus de points d’arrêt matériels pour le débogage, permet d’associer plus de watchpoints aux variables, mais affiche un plus grand temps d’exécution par instruction. L’exploration du code vous amènera sans doute à vous interroger sur la brièveté du main.c :

 

#include "mcc_generated_files/application_manager.h"

int main(void)

{

    application_init();

    while (1)

    {

        runScheduler(); 

    }

    return 0;

}

L’initialisation de tous les composants est confiée à application_init(). Cette fonction est définie dans application_manager.c, où sont également définies la plupart des fonctions de haut niveau. La fonction runScheduler() lance et coordonne toutes les tâches imparties. Pour leur exécution proprement dite, elle appelle la fonction timeout_callNextCallback() :  

inline void timeout_callNextCallback(void)

{

    if (executeQueueHead == NULL)

        return;

    bool tempIE = (IEC0bits.T1IE == 1?1:0);

    IEC0bits.T1IE = 0;

    timerStruct_t *callBackTimer = executeQueueHead;

    // Done, remove from list

    executeQueueHead = executeQueueHead->next;

    // Mark the timer as not in use

    callBackTimer->next = NULL;

    if(tempIE)

    {

        IEC0bits.T1IE = 1;

    }

    uint32_t reschedule = callBackTimer->callbackPtr(callBackTimer->payload);

    // Do we have to reschedule it? If yes then add delta to absolute for reschedule

    if(reschedule)

    {

        timeout_create(callBackTimer, reschedule);

    }

}

Le code vérifie si quelque chose est prêt à être exécuté, sinon quitte immédiatement cette fonction (instruction return). Ensuite le code désactive brièvement une interruption (j’explique pourquoi dans un instant) et sélectionne l’élément prêt à être exécuté. L’appel uint32_t reschedule = callBackTimer->callbackPtr(callBackTimer->payload); exécute la fonction, qui renvoie alors la période au bout de laquelle elle devra être rappelée. Si cette durée n’est pas nulle, elle est remise dans une liste des tâches en attente avec la période indiquée. Le compteur/temporisateur (timer) et l’interruption mentionnée constituent l’autre partie permettant au système d’exécuter en permanence les tâches. La fonction timeout_isr est appelée depuis l’interruption à intervalle défini. 

void timeout_isr(void)

    {

        timerStruct_t *next = listHead->next;

        absoluteTimeofLastTimeout = listHead->absoluteTime;

        lastTimerLoad = 0;

 

    if (listHead != &dummy) {

    enqueueCallback(listHead);

}

 

    listHead = next;

 

    startTimerAtHead();

}

Le code parcourt une liste contenant des tâches à exécuter et des tâches factices (dummy dans le code). Une tâche à exécuter est placée dans une liste des tâches à accomplir, puis la tâche suivante est extraite de la liste des tâches en attente, et le timer ajuste en conséquence son intervalle. La liste des tâches à exécuter est alors traitée par la fonction timeout_callNextCallback, tandis que la routine d’interruption prépare et planifie l’exécution des tâches suivantes. Combiné avec la fonction timeout_callNextCallback, le résultat forme un cycle dans lequel les tâches sont traitées et exécutées en temps voulu. S’il ne reste plus de tâche à exécuter, le microcontrôleur peut être mis en veille en attendant d’être réactivé par le timer ou par un autre événement. Bien adapté au cas présent, cette technique astucieuse pourrait être reprise dans un projet pour exécuter des tâches avec une consommation d’énergie réduite.

Sécurité

Le guide de l’utilisateur de la carte AVR-IoT WA explique comment déployer le projet d’exemple sur la carte. De la simple connexion de la carte au PC à la production du code avec MPLAB X, la couverture est complète. Microchip publie régulièrement de nouvelles versions des outils utilisés, mais ces changements ne devraient en rien affecter les explications du guide dès lors qu’ils ne visent qu’à améliorer l’expérience de l’utilisateur et renforcer la stabilité logicielle. Les figures 15, 16 et 17 montrent des étapes réalisées avec les assistants de MPLAB X. Notez que le projet final pourra être compilé avec AVR-GCC.

Figure 15. Sélection d’un projet sous MPLAB X.
Figure 16. Sélection de la cible.
Figure 17. L’outil MPLAB® Code Configurator.

La figure 17 montre en particulier les composants du projet d’exemple, dont CryptoAuthLibrary, WINC15XX et MQTT (Message Queue Telemetry Transport). Ce qui nous amène à la sécurité des deux cartes. Le service AWS IoT Core repose sur le protocole MQTT pour l’échange des données. Sans protocole supplémentaire, ces données transiteraient sous forme de texte brut, susceptibles d’être interceptées et modifiées. Les échanges MQTT sont donc souvent protégés par une couche TLS (Transport Layer Security). Sur les deux cartes, la sécurité matérielle est assurée par le coprocesseur cryptographique ATECC608A, qui décharge ainsi le microcontrôleur de cette tâche. La sécurité du réseau est prise en charge par la puce WINC1510. Elle crypte la communication et peut être assistée par l’ATECC608A pour garantir l’intégrité des données entre la carte et ceux avec qui elle communique. Ces échanges par protocole MQTT ne sont pas cantonnés au service IoT Core. Vous pouvez utiliser un courtier MQTT écrit pour la communication avec un autre service.

Vot' ticket pour l'nuage, m’sieurs-dames ?

Pourquoi s’en priver ? Le prix est bas et le confort logiciel assuré. J’ai insisté sur la qualité de la documentation, car avec les outils de débogage elle facilite grandement le déploiement d’objets connectés. Ces deux cartes offrent d’autres atouts. Ainsi le chargeur de batteries au lithium trouvera-t-il un intérêt pratique bien au-delà de la commodité qu’il apporte sur la paillasse. Le connecteur mikroBus permettra quant à lui de greffer bon nombre d'extensions du matériel. Les deux versions, PIC et AVR, permettent à l’utilisateur de choisir son microcontrôleur de prédilection. Ce qui vous donne aussi l’occasion d'aller voir si l'herbe est plus verte avec d'autres microcontrôleurs que ceux que vous connaissez.

Ajoutons la compatibilité de l’EDI avec les trois principaux systèmes d’exploitation, et nous avons là une solution complète.

Ce que le manuel ne dit pas (encore)

Il est possible que vous ayez reçu une carte préchargée avec un micrologiciel ancien et que les données de la puce ATECC608A soient obsolètes. Dans ce cas vous pourrez connecter la carte à votre réseau Wi-Fi, mais sans parvenir à accéder au service AWS IoT Core. Vous serez privé des tutoriels et resterez pour ainsi dire cloué au sol, loin du nuage. La solution consiste à mettre à jour à la fois le micrologiciel de la carte, la puce ATECC608A et le débogueur embarqué avec l’outil IoT Provisioning Tool pour Windows, Linux et macOS. Dézippez l’archive et lancez l’exécutable en ligne de commande (il existe une explication en vidéo). Sous Windows, la commande est iotprovision-bin.exe -c aws -m sandbox. Le programme mettra en place tout ce qu’il faut sur votre carte, dont les certificats requis. Comme l’explique la vidéo, l’outil permet aussi de configurer une carte pour les services Google plutôt qu’Amazon.