Les articles de Open Silicium N°18

Article mis en avant

Prototypage IoT avec Buildroot

L'IoT (Internet des objets) est probablement le terme technique le plus évoqué depuis quelques mois. De nombreuses start-ups se développent un peu partout dans le monde afin de proposer l'objet connecté qui changera la face du monde (après le smartphone…). La conception d'un tel objet n'est cependant pas si simple, car elle allie matériel et logiciel. La partie logicielle doit prendre en compte la connectivité, mais aussi la fiabilité générale du système. Dans cet article, nous verrons comment mettre en place une maquette d'objet connecté en utilisant une Raspberry Pi A+ et la dernière version de l'outil Buildroot (2016.02). Pour cela, nous aborderons des concepts de configuration avancée de Buildroot.Cet article est issu d'un exemple de projet réalisé avec des étudiants de l'UPMC (Université Pierre et Marie Curie/Jussieu) [18].
Nous voici de retour pour ce numéro printanier d'Open Silicium. Comme vous pouvez le constater sur la couverture, le sujet phare de cette 18ème mouture est l'Internet des objets, plus communément nommé IoT.
Le FOSDEM est la réunion annuelle des développeurs open source européens. Cette année encore nous avons pu passer une journée à Bruxelles et nous transmettons ici au lecteur de notre revue nos impressions tant sur le plan technique qu'émotionnel !
Tous les ingénieurs travaillant sur un nouveau produit électronique se sont posé la question suivante : comment charger le programme dans le produit final de la façon la plus rapide et propre (sans pin visible sur le PCB) ? Plusieurs solutions sont actuellement disponibles, mais imposent de nouvelles pistes et de nouveaux pins sur la carte mère, ce qui ralentit considérablement la vitesse de production tout en augmentant l’encombrement. Le pire c’est qu’on se rend compte qu’on ne va plus jamais s’en servir durant la vie du produit électronique. Dans cet article, je vais vous présenter le cas du fabricant STMicroelectronics qui propose une méthode que je trouve particulièrement simple, rapide et propre (à mon humble avis) pour charger un programme sur une carte : le Device Firmware Upgrade (DFU).
Les outils et les méthodes de débogage pour l'espace applicatif Linux sont plutôt bien connus : de Valgrind à Strace/Ltrace en passant par GDB et toutes ses déclinaisons (DDD, Eclipse, Gdbserver), la documentation et les exemples sont très répandus. En ce qui concerne l'espace noyau, la pratique du débogage est beaucoup plus limitée. Pourtant, certains outils comme Ftrace permettent non seulement d'aider à la mise au point du code kernel, mais également d'analyser finement les comportements des tâches de l'espace utilisateur.
Cet article présente la mise en œuvre de l'extension Temps Réel dur Xenomai sur la carte ZedBoard qui est basée sur la dernière génération de circuits FPGA Zynq de Xilinx. Cet article fait suite à celui consacré à la mise en œuvre de Linux embarqué sur cette carte.
La variété des plateformes matérielles et logicielles pour l'Internet des objets (en anglais : Internet of Things, ou IoT) rend difficile le choix d'une bibliothèque de développement à utiliser. RIOT se présente comme le système d'exploitation « friendly » pour l'IoT en proposant une API uniforme pour une grande diversité de cartes. RIOT est économe en mémoire et en énergie et supporte les protocoles standards de communication pour l'IoT. Voici un tour d'horizon de RIOT et de ses possibles applications.
Cédric Bail est « senior open source developer » au centre de recherche et développement SAMSUNG (OSG pour Open Source Group) dans la Silicon Valley. Connu pour son implication dans le développement de l'outil graphique EFL (Enlightenment Foundation Library), il nous décrit ici son parcours et répond à quelques questions concernant les EFL et ses travaux présents et futurs.
Dans la course aux cartes toujours moins chères, une petite start-up californienne a surpris son monde en mai dernier. En effet, elle a lancé une campagne de financement sur Kickstarter pour une carte à 9 dollars, tournant sous Linux et utilisant un processeur ARM. Six mois après avoir financé avec un large succès cette campagne, les premières cartes commencent à être disponibles. En effet, son faible coût, ses dimensions réduites et sa connectivité en font un choix idéal pour s'essayer à l'IoT.Dans cet article, nous vous proposons de découvrir, après une brève histoire du C.H.I.P. et une présentation de ses caractéristiques techniques, comment mettre en place à partir de zéro un système Linux sur celui-ci à travers le réseau afin de faciliter le développement. Nous finirons par une présentation des overlays pour le Device Tree  qui permettent de décrire les ajouts de composants que nous pourrions faire.
Après avoir linéarisé l'algorithme de décompression 3R (Recursive Range Reduction) [1] et expliqué les paradigmes de programmation et le style de codage [2], intéressons-nous à la réalisation matérielle. La traduction du JavaScript vers le VHDL étant prévue dès le début, le résultat est un circuit numérique très rapide (dès la première synthèse) occupant une place négligeable dans un FPGA.
La libération des FPGA passe bien sûr d'abord par les outils permettant de générer la configuration du composant. Mais elle passe aussi par l'inclusion de FPGA sur des cartes utilisant des systèmes d'exploitation libres comme Linux. Sur des plateformes processeur + FPGA comme on trouve sur les modules d'Armadeus Système ou sur le Zync de Xilinx se pose alors la question de l'écriture d'un pilote pour le design FPGA. L'utilisation du modèle de driver Userspace I/O permet d'exporter les registres et interruptions dans l'espace utilisateur et d'éviter l'écriture fastidieuse d'un driver kernel.