Cette année 2015 fut très riche et très excitante au sujet des pilotes graphiques libres. Grosse nouveauté, Mesa 3D 11 a été annoncée le 12 septembre 2015, avec une prise en charge d’OpenGL 4.2, après une très longue stagnation en version 3.3.

Cette dépêche fait donc la part belle aux récentes nouveautés de Mesa 3D, mais s’attarde aussi sur les actualités des puces graphiques embarquées, et se permet quelques incursions du côté de certains pilotes propriétaires dans leur collaboration avec les projets libres ou leurs initiatives qui profitent à tous.

Pour finir, nous nous permettrons d’annoncer quelques actualités à venir ayant pris racine en 2015.

Merci à tous les contributeurs de cette rétrospective !

À l’occasion de la sortie du Raspberry Pi 4, un ordinateur à carte unique (Single Board Computer — SBC), il nous a semblé important de faire un point sur les cartes Raspberry qui se sont démocratisées à partir de 2010, et qui ont aujourd’hui des capacités suffisantes pour traiter l’ensemble des tâches courantes d’un ordinateur de bureau.

Les cartes fonctionnant directement à partir de bibliothèques C/C++ de type Arduino, ou celles fonctionnant via un interpréteur dans un langage particulier (MicroPython), ne seront pas traitées en profondeur dans cette dépêche.

L'augmentation continue de la puissance de calcul, des fonctionnalités présentes et des empreintes mémoires (RAM, FLASH, ROM...) des processeurs 32 bits tend à créer une classe de processeurs hybrides :

• ils sont suffisamment puissants pour exécuter des tâches complexes (réseau, affichage...) ;
• ils sont trop petits pour faire fonctionner de façon raisonnable les systèmes d'exploitation Open Source classiques (GNU/Linux, Android, *BSD...).

Les architectures Cortex-M3 et Cortex-M4 d'ARM rentrent clairement dans cette catégorie.

Même si il existe un portage de uClinux sur STM32 (ici et là), il est indispensable de posséder une mémoire externe de plusieurs dizaines de mégaoctets (mémoire interne de l'ordre de centaines de Kio).

Dans cette optique nous avons décidé de publier le code source de Lepton/Tauon sous licence MPL/EPL (au moment de cette rédaction il s'agit de la MPL 1.1).

Lepton/Tauon est un système d'exploitation temps réel (RTOS, pour Real Time Operating System) qui tente de respecter au maximum le standard POSIX (« POSIX compliant ») tout en gardant à l'esprit les contraintes :

• d'empreinte mémoire ;
• de fiabilité ;
• de simplicité ;
• de portabilité.

Le micrologiciel (firmware) généré se présente sous la forme d'un ELF contenant :

• le noyau ;
• les pilotes de périphériques ;
• les bibliothèques ;
• les pseudo-binaires systèmes et utilisateurs.

OpenEnergyMonitor est un projet visant à développer des outils open-source de suivi énergétique pour nous aider à appréhender notre utilisation de l'énergie, nos systèmes énergétiques, et le défi de l'énergie soutenable.

OpenEnergyMonitor is a project to develop open-source energy monitoring tools to help us relate to our use of energy, our energy systems and the challenge of sustainable energy.

Les applications typiques sont le suivi des consommations énergétiques d'un bâtiment ou de la production d'un système solaire (panneaux photovoltaïques, ballon d'eau chaude sanitaire). Il n'y a pas encore, sinon marginalement, de pilotage automatique du bâtiment et des systèmes.

Les principaux mainteneurs, Glyn Hudson et Trystan Lea, y travaillent à temps plein depuis le labo OpenEnergyMonitor, dans les montagnes de Snowdonia, au Pays de Galle. Le projet inclut aussi les contributions significatives d'une quinzaine de participants. Les codes source du logiciel et les spécifications du matériel sont sous GPL.

Eh bien voilà, très (trop) longtemps après le premier épisode, me revoilà pour reprendre avec vous la série sur l'écriture d'un système d'exploitation pour un microcontrôleur STM32F103. Pour rappel, mon système d'exploitation MOS est écrit dans un but d'apprentissage. Il vise à être simple à appréhender et à permettre à chacun de découvrir les entrailles d'un OS. Cela implique deux conséquences :

• je réinvente la roue puisque je réécris tout de zéro
• il y aura sûrement des bugs, n'essayez pas de le mettre en production (!)

Voilà, tout ceci étant dit, on va pouvoir attaquer les choses sérieuses. Dans cet épisode, nous allons organiser notre projet et configurer nos outils. Bonne lecture !

Alors que la dernière dépêche annonçant une version de Buildroot publiée sur LinuxFr.org date d'il y a 3 ans, Buildroot a continué a publier tous les trois mois une version stable. À l'occasion de la sortie de la version 2014.02 de Buildroot, cette dépêche propose un petit retour sur les récentes avancées du projet.

Pour ceux qui ne connaissent pas le projet, Buildroot est un outil qui simplifie et automatise le processus de création d'un système Linux embarqué. À partir d'une configuration, Buildroot est en mesure de générer une chaîne de compilation croisée, un système de fichiers racine avec diverses applications et bibliothèques, une image de noyau Linux et un ou plusieurs bootloaders. Buildroot supporte plus de 1000 applications ou bibliothèques, pour lesquelles leur cross-compilation se résume à cocher une option dans l'interface de configuration.

À noter que le projet Buildroot participera au Google Summer of Code 2014, et recherche donc des étudiants souhaitant travailler sur le projet tout en étant payé pendant l'été.

Voir la suite de la dépêche pour plus de détails.

Yocto est un projet collaboratif, soutenu par la Linux Foundation, qui fournit des modèles, outils et méthodes pour vous aider à créer des systèmes embarqués.

Le projet Yocto est divisé en plusieurs sous‐parties. Nous allons nous intéresser dans cet article au générateur d’appliances. Ce dernier effectue en toute simplicité la génération de votre propre système embarqué à l’intérieur d’une machine virtuelle de type vmdk.

Yocto est issu du projet Poky (un système de contruction — build — qui s’appuie lui‐même sur OpenEmbedded) dont il est le digne successeur.