Texier Pierre-Jean

Déjà évoqué dans diverses publications [1], le protocole Machine-2-Machine MQTT, se veut être le standard de communication pour les objets connectés (comprendre IoT ici !). En effet, de par sa légèreté et son efficacité, il en fait un protocole très prisé pour la gestion de la télémétrie en environnement embarqué.

Sécuriser le processus de démarrage est la première étape afin de garantir qu’un système Linux embarqué est fiable. Cette technique, appelée Secure Boot, permet de s’assurer que seuls les logiciels authentifiés de manière cryptographique (bootloader, image noyau, etc.) pourront s’exécuter sur la cible, ceci afin de certifier par exemple qu’une mise à jour logicielle est sûre, qu’aucune faille de sécurité ne subsiste ni même qu’il existe une quelconque altération provenant d’une attaque externe malveillante.

Afin de mieux comprendre les enjeux liés à la mise à jour d’un système embarqué connecté (nous parlons bien d’(I)IoT !), nous mettrons en œuvre dans cet article, Mender, une solution OTA permettant la gestion des déploiements sur des systèmes Linux embarqués.

Dans cet article, nous allons développer un driver de périphérique en utilisant à la fois le bus i2c et le sous-système Industrial I/O. Le but final sera la mise en place d'une petite application Qt/QML permettant d'afficher les informations d'un capteur sur écran LCD.

Nous allons découvrir dans cet article comment appréhender le développement sur plateforme i.MX7. Nous développerons un démonstrateur IoT en associant acquisition des données via Cortex M4, communication interprocesseur et consommation des données côté Cortex A7.

Dans le milieu industriel, l'intégration de périphériques séries (RS232) est monnaie courante : moteur pas à pas, système de refroidissement, matériel scientifique... Malheureusement, le constat est à chaque fois accablant. En effet, de façon très récurrente on s’aperçoit que les protocoles de communication diffèrent en fonction du fabricant : protocole ASCII sans CRC pour l'un, protocole avec CRC16 pour l'autre et même CRC32 pour d'autres ! Donc aucune homogénéité. C'est pour cette raison que nous proposons d'étudier le protocole Modbus série dans sa forme la plus simpliste (RTU).

L'important choix de cartes intégrant des capteurs/actionneurs, en fait aujourd'hui, un choix difficile pour l'utilisateur final.C'est pour ces raisons que MikroElektronika a créé un standard : MikroBUS. Il facilite l'interaction entre microcontrôleur ou microprocesseur et les cartes d'extensions, appelées « add-ons », utilisant cette connectique.Cet article se propose d'explorer la partie MikroBUS d'un des tous derniers SBC (Single Board Computer) du marché : la WaRP7 (« WearAble Reference Platform »). On commencera dans un premier temps par une succincte présentation de la WaRP7 et d'une partie « board bring-up » (via Yocto/OE). Puis, viendra la partie MikroBUS qui sera mise en avant à travers un mini projet architecturé autour du Bluetooth Low Energy et du framework Qt5 pour Android tout en y intégrant une carte add-ons, carte qui se base sur le standard MikroBUS.

Bluetooth (Low Energy), Wifi, NFC, sont des mots qui deviennent de plus en plus prépondérants aujourd'hui. En effet, devant l'élan grandissant de l'Internet des objets (IoT), la connectivité sans fil devient un point essentiel pour les plateformes de développement. Après la Raspberry Pi, la Beagle Bone, la C.H.I.P, une petite dernière vient d'arriver sur ce marché.À travers ses connectivités et un encombrement extrêmement réduit, la WaRP7 se veut être une base solide pour le développement « IoT ».Cet article propose d'explorer, après une présentation de la WaRP7 et d'une partie génération d'images (Yocto/OE), la partie Bluetooth de celle-ci, au travers de la « command line » dans un premier temps, puis au travers de Qt5 pour finir.