Examining Data Using Pandas

You don't need to be a data scientist to use Pandas for some basic analysis.

Traditionally, people who program in Python use the data types that come with the language, such as integers, strings, lists, tuples and dictionaries. Sure, you can create objects in Python, but those objects typically are built out of those fundamental data structures.

If you're a data scientist working with Pandas though, most of your time is spent with NumPy. NumPy might feel like a Python data structure, but it acts differently in many ways. That's not just because all of its operations work via vectors, but also because the underlying data is actually a C-style array. This makes NumPy extremely fast and efficient, consuming far less memory for a given array of numbers than traditional Python objects would do.

The thing is, NumPy is designed to be fast, but it's also a bit low level for some people. To get more functionality and a more flexible interface, many people use Pandas, a Python package that provides two basic wrappers around NumPy arrays: one-dimensional Series objects and two-dimensional Data Frame objects.

I often describe Pandas as "Excel within Python", in that you can perform all sorts of calculations as well as sort data, search through it and plot it.

For all of these reasons, it's no surprise that Pandas is a darling of the data science community. But here's the thing: you don't need to be a data scientist to enjoy Pandas. It has a lot of excellent functionality that's good for Python developers who otherwise would spend their time wrestling with lists, tuples and dictionaries.

So in this article, I describe some basic analysis that everyone can do with Pandas, regardless of whether you're a data scientist. If you ever work with CSV files (and you probably do), I definitely recommend thinking about using Pandas to open, read, analyze and even write to them. And although I don't cover it in this article, Pandas handles JSON and Excel very well too.

Creating Data Frames

Although it's possible to create a data frame from scratch using Python data structures or NumPy arrays, it's more common in my experience to do so from a file. Fortunately, Pandas can load data from a variety of file formats.

Before you can do anything with Pandas, you have to load it. In a Jupyter notebook, do:

%pylab inline
import pandas as pd

For example, Python comes with a csv module that knows how to handle files in CSV (comma-separated value) format. But, then you need to iterate over the file and do something with each of those lines/rows. I often find it easier to use Pandas to work with such files. For example, here's a CSV file:


You can turn this into a data frame with:

Last Call for Purism's Librem 5 Dev Kits, Git Protocol Version 2 Released, LXQt Version 0.13.0 Now Available and More

Purism announces last call for its Librem 5 dev kits. If you're interested in the hardware that will be the platform for the Librem 5 privacy-focused phones, place your order by June 1, 2018. The dev kit is $399, and it includes "screen, touchscreen, development mainboard, cabling, power supply and various sensors (free worldwide shipping)".

The Google Open Source Blog recently announced the release of Git protocol version 2. This release brings improvements to server-side reference filtering, easy extensibility for new features and simplified client handling of the http transport. See the full list of changes here.

The LXQt team yesterday announced the release of version 0.13.0 of its Lightweight Qt Desktop Environment. Highlights include "all packages are ready for Qt 5.11, out-of-source builds are now mandatory, libfm-qt is made more self-sufficient" and more.

Red Hat announced this morning its collaboration with Juniper Networks to combine Juniper's Contrail Enterprise Multicloud and Red Hat's OpenShift Container and OpenStack Platforms to "deliver an open-source based, multicloud alternative to proprietary platforms".

The Debian Project announced recently that "regular security support for Debian GNU/Linux 8 (code name "jessie") will be terminated on the 17th of June".

The Khronos Group yesterday announced "its engagement of Au-Zone Technologies to enable the NNEF (Neural Network Exchange Format) standard files to be used with leading machine learning training frameworks". See the Press Release for all the details on the Khronos Group and Au-Zone's development of open-source TensorFlow and Caffe2 Converters for NNEF.

Cookies That Go the Other Way


The web—or at least the one we know today—got off on the wrong hoofs. Specifically, I mean with client-server, a distributed application structure that shouldn't subordinate one party to an other, but ended up doing exactly that, which is why the web today looks like this:

Clients come to servers for the milk of HTML, and get cookies as well.

The original cookie allowed the server to remember the client when it showed up again. Later the cookie would remember other stuff: for example, that the client was a known customer with a shopping cart.

Cookies also came to remember fancier things, such as that a client has agreed to the server's terms of use.

In the last decade, cookies also arrived from third parties, some for site analytics but mostly so clients could be spied on as they went about their business elsewhere on the web. The original purpose was so those clients could be given "relevant" and "interest-based" advertising. What matters is that it was still spying and a breach of personal privacy, no matter how well its perpetrators rationalize it. Simply put, websites and advertisers' interests end at a browser's front door. (Bonus link: The Castle Doctrine.)

Thanks to the EU's General Data Protection Regulation (GDPR), which comes into full force this Friday, that kind of spying is starting to look illegal. (Though loopholes will be found.) Since there is a world of fear about that, 99.x% of GDPR coverage is about how the new regulation affects the sites and services, and what they can do to avoid risking massive fines for doing what many (or most) of them shouldn't have been doing in the first place.

But the problem remains structural. As long as we're just "users" and "consumers," we're stuck as calves.

But we don't have to be. The web's underlying protocol, HTTP, is distributed and collaborative. It doesn't say we need to be subordinate to websites, always consenting to those sites' terms and policies. It doesn't even say we have to be calves to the websites' cows. Consent can go the other way.

And so can cookies. So let's bake some.

VMware Announces OpenStack 5, Tesla Releases Some Source Code, KDE's Plasma 5.13 Beta and More

News briefs for May 21, 2018.

VMware today announced its new OpenStack 5. According to the press release, "VMware Integrated OpenStack 5 will be one of the first commercial OpenStack distributions to comply with the OpenStack Foundation's 2018.02 interoperability guidelines. An active member of the OpenStack community, VMware packages, tests, and supports all major components of the distribution, including the full open source OpenStack code in a multi-cloud architecture."

Tesla has released some of the source code for its in-car tech. Engadget reports that the company "has posted the source code for both the material that builds the Autopilot system image as well as the kernels for the Autopilot boards and the NVIDIA Tegra-based infotainment system used in the Model S and Model X."

KDE's Plasma team released Plasma 5.13 beta late last week: "We have spent the last four months optimising startup and minimising memory usage, yielding faster time-to-desktop, better runtime performance and less memory consumption. Basic features like panel popups were optimised to make sure they run smoothly even on the lowest-end hardware. Our design teams have not rested either, producing beautiful new integrated lock and login screen graphics."

The Linux 4.18 kernel will have the Steam Controller driver that will work without needing the Steam client or other third-party applications. Phoronix reports that "HID subsystem maintainer Jiri Kosina has now queued this Valve Steam Controller driver into his HID-next tree for Linux 4.18. This HID driver will expose the Steam Controller as a virtual mouse, virtual keyboard, and custom HID device(s). In turn this should allow the Steam Controller to work happily with any Linux application."

SoftMaker recently released SoftMaker FreeOffice 2018, the newest version of its free software. SoftMaker says "with FreeOffice 2018 you can not only open, but also save documents in the Microsoft file formats DOCX, XLSX and PPTX. Share files directly with Microsoft Office users, without having to export them first!" Note that although it is free to download and use, FreeOffice is not open source.

WordPress recently announced its latest release, 4.9.6, which is a privacy and maintenance release intended to help users be GDPR-compliant. The WordPress blog notes "We're committed to supporting site owners around the world in their work to comply with this important law. As part of that effort, we've added a number of new privacy features in this release."

Nextcloud 13: How to Get Started and Why You Should

Nextcloud could be the first step toward replacing proprietary services like Dropbox and Skype.

In its simplest form, the Nextcloud server is "just" a personal, free software alternative to services like Dropbox or iCloud. You can set it up so your files are always accessible via the internet, from wherever you are, and share them with your friends. However, Nextcloud can do so much more.

In this article, I first describe what the Nextcloud server is and how to install and set it up on GNU/Linux systems. Then I explain how to configure the optional Nextcloud features, which may be the first steps toward making Nextcloud the shell of a complete replacement for many proprietary platforms existing today, such as Dropbox, Facebook and Skype.

Figure 1. A safe home for all your data that all your devices can reach—that's what Nextcloud wants to be.

Why Nextcloud and Not ownCloud?

Nextcloud, whose version 13 was released in February 2018, was spun off the popular ownCloud project in 2016, out of licensing and other disagreements. See the Resources section for some of the most complete feature-by-feature comparisons between Nextcloud and ownCloud. The most basic capabilities are still almost identical, two years after the fork. Some of the functions described here, however, are easier to integrate in Nextcloud than in its ancestor. In addition, my personal reasons for recommending Nextcloud over ownCloud are the following:

  • Licensing and pricing policies: all the official components of Nextcloud are both free as in freedom and as in free beer. You pay only for support and update services. That's not the case with ownCloud.
  • Long-term roadmap: at the moment, ownCloud seems to be more focused on corporate customers and more relevant for investors, while Nextcloud seems to be more focused on extending "direct" user-to-user communication and cooperation features.

Figure 2. The Original Nextcloud/ownCloud Functions: File and Picture Storage, Dropbox-Style

A Word on Security

Several good reasons to choose Nextcloud as the online home for your own files and data are related to security. I don't cover them in detail in this introductory article, but I want to mention at least some of them.

Nextcloud refuses continuous (that is, malicious) attempts to authenticate from any computer, except those whose IP addresses are included in "brute-force IP whitelists". (Of course, the best possible whitelist you can configure is an empty one.)

Weekend Reading: Backups


Public Service Announcement: please do a backup if you haven't in awhile. This weekend we feature articles varying from scary backup stories to how-to safeguard your data with encrypted backup solutions. 


Scary Backup Stories

by Paul Barry

Backups. We all know the importance of making a backup of our most important systems. Unfortunately, some of us also know that realizing the importance of performing backups often is a lesson learned the hard way. Everyone has their scary backup stories. Here are mine.


Reliable, Inexpensive RAID Backup

by Brian C. Lane

As a topic, backups is one of those subject likely to elicit as many answers as people you ask about it. It is as personal a choice as your desktop configuration or your operating system. So in this article I am not even going to attempt to cover all the options. Instead I describe the methods I use for building a reliable, useful backup system. This solution is not the right answer for everyone, but it works well for my situation.


LVM and Removable IDE Drives Backup System

by Mike Fogarty

When the company I work for, a civil engineering and surveying firm, decided to move all its AutoCad drawings onto a central fileserver, we were presented with a backup situation orders of magnitude larger than anything we had confronted before. We had at that time (now considerably larger) about 120,000 files, totaling 200GB, that were in active change and needed to be backed up at least daily.

My first thoughts were of some sort of tape backup system, but as I began to research them, I was shocked at the prices I encountered. A tape autoloader large enough to contain our filesystem ran about $12,000 and a 40Gig tape was $89. When I first convinced my boss to let me run Linux on our servers, cheap was a big selling point. So, what are the alternatives?


Backup and Update

by Shawn Powers

In this video, editor Shawn Powers shows us how to do a basic backup in Linux. Or as he puts it, a public service announcement to please do a backup if you haven't in awhile!




Allwinner VPU support in mainline Linux status update (week 20)

With DMABUF support tested, it has become possible for Paul to start the work on integrating a GPU-based video output pipeline with Sunxi-Cedrus. Using the GPU should greatly improve performance when it comes to displaying the video frames. As of now, we have been using software untiling, software YUV-to-RGB colorspace conversion and software scaling. We … Continue reading "Allwinner VPU support in mainline Linux status update (week 20)"

Caption This: May Winner

Drawing of an Alexa plugged in to a hamburger

Winner: Is this what my cardiologist means by I need an echo?

—Tom Dison, twitter.com/fretinator

Second Place: USBurger

—Greg Charnock, twitter.com/gregcharnock7

Third Place: "Alexa, where's the beef?"

—Jack, via comment on https://www.linuxjournal.com

Each month, we provide a cartoon in need of a caption—check https://www.linuxjournal.com for the next one. You submit your caption in the comments on the site or via Twitter, we choose three finalists, and readers vote for their favorite. See the June issue for the next winner.

Purism's New Purekey OpenPGP Security Token, Windows 10 Now Includes OpenSSH, Vim 8.1 Released and More

News briefs for May 18, 2018.

Purism, maker of the security-focused Librem laptops, announced yesterday it has partnered with Nitrokey to create Purekey, "Purism's own OpenPGP security token designed to integrate with its hardware and software. Purekey embodies Purism's mission to make security and cryptography accessible where its customers hold the keys to their own security." You can purchase a Purekey by itself or as an add-on with a laptop order. According to Purism's CSO Kyle Rankin, "By keeping your encryption keys on a Purekey instead of on a hard drive, your keys never leave the tamper-proof hardware. This not only makes your keys more secure from attackers, it makes using your keys on multiple devices more convenient."

The latest update of Windows 10 includes OpenSSH. ZDNet reports this has been in the works since 2015 due to user requests. Also, third-party SSH clients like Putty no longer will be necessary to connect to a system with SSH.

Vim 8.1 is now available. The major new feature of this release is that you now can run a terminal in a Vim window, which allows you to do things like run a command (like make) while editing in other windows or "use the new terminal debugger plugin for debugging inside Vim".

0 A.D., the "open-source ancient warfare game", has a new release, Alpha 23. Phoronix reports that this "RTS game in its latest alpha release features a new civilization, new models, improved AI behavior, a mod downloader, new random maps, and other changes to enhance the game-play for this game that's been open-source for nearly a decade."

Valve launched the Steam Link App for Android devices yesterday. The app "allows gamers to experience their Steam library of games on their Android (phone, tablet, and TV) devices while connected to the same 5Ghz network or wired Ethernet as their Steam gaming computer (PC, Linux, Mac)". You can get the app here. (Source: Phoronix.)

Testing pixel formats on the RaspberryPi

As part of our ongoing work with the RaspberryPi Foundation, we’ve been working on a number of display-related topics recently. Besides the work done by my colleague Boris Brezillon on improving the kernel side support for a number of features (such as the GPU performance counters support, memory management improvements, etc.), I’ve been working on … Continue reading "Testing pixel formats on the RaspberryPi"

AsteroidOS 1.0 Released, Net Neutrality Update, Qt 3D Studio 2.0 Beta Now Available and More

News briefs for May 17, 2018.

AsteroidOS 1.0 is now available. Released yesterday, the open-source operating system for smartwatches is finally available after four years in the works. As posted on the AsteroidOS website, "AsteroidOS is built on standard Linux technologies including OpenEmbedded, opkg, Wayland, Qt5, systemd, BlueZ, and PulseAudio. This makes it the ideal platform to build any sort of wearable project you can imagine. Do you want to run Docker on your watch? AsteroidOS can do it. Do you want to run Quake on your watch? AsteroidOS can do that too. The sky is really the limit! Our community welcomes anyone interested in playing with a smartwatch project."

Yesterday the Senate voted to reverse the net neutrality repeal. As reported by Ars Technica and elsewhere, if the Congressional Review Act "is approved by the House and signed by President Trump, Internet service providers would have to continue following rules that prohibit blocking, throttling, and paid prioritization." If Congress doesn't act, the net neutrality rules expire on June 11.

Qt 3D Studio 2.0 beta was released yesterday. This release includes a new runtime and viewer application, improved data input, editor improvements and more.

Have a release party for openSUSE Leap 15. See the openSUSE page for how you can help the community spread the word, and see the Launch Party Wiki to sign up and add your party to the map. openSUSE Leap 15 launches May 25, 2018.

Linspire Server 2018 was released this week. Linspire Server is based on Ubuntu Server 16.04 and is intended for small to medium-size businesses and schools. It is fee to download and use under a self-support license.

Generating Good Passwords, Part I

Dave starts a new method for generating secure passwords with the help of 1Password.

A while back I shared a script concept that would let you enter a proposed password for an account and evaluate whether it was very good (well, maybe "secure" would be a better word to describe the set of tests to ensure that the proposed password included uppercase, lowercase, a digit and a punctuation symbol to make it more unguessable).

Since then, however, I've really been trying personally to move beyond mnemonic passwords of any sort to those that look more like gobbledygook. You know what I mean—passwords like fRz3li,4qDP? that turn out to be essentially random and, therefore, impossible to crack using any sort of dictionary attack.

Aiding me with this is the terrific password manager 1Password. You can learn more about it here, but the key feature I'm using is a combination of having it securely store my passwords for hundreds of websites and having a simple and straightforward password generator feature (Figure 1).

Figure 1. 1Password Password Generation System

If I'm working on the command line, however, why pop out to the program to get a good password? Instead, a script can do the same thing, particularly if I again tap into the useful $RANDOM shortcut for generating random numbers.

Generating Secure Passwords

The easiest way to fulfill this task is to have a general-purpose approach to generating a random element from a specific set of possibilities. So, a random uppercase letter might be generated like this:


letter=${uppers:$(( $RANDOM % 26 )):1}

The basic notational convention used here is the super handy Bash shell variable slicing syntax of:


To get the first character only of a variable, for example, you can simply reference it as:


That's easy enough. Instead of a fixed reference number, however, I'm using $(( $RANDOM % 26 )) as a way to generate a value between 0–25 that's different each time.

Add strings that contain all the major character classes you seek and you've got a good start:

punct="()./?;:[{]}|=+-_*&^%$#@!~"  # skip quotes

To get even fancier, there's another notation ${#variable} that returns the number of characters in a variable, so the following shows that there are 24 characters in that particular string:

Surveillance en continu - Garantir la qualité des pièces et la disponibilité des moyens de production - Rodez (12) Le 9 juillet 2018

Placez vos risques sous contrôle : Acquisition et analyse de données, Maintenance prévisionnelle, Surveillance à distance… pour une meilleure productivité

Ce 4 à 7 est organisé par le Cetim, en partenariat avec AD'OCC, Mecanic Vallée et Cap'Tronic. Les nouvelles approches de la maintenance : nouvelles méthodes et approches en surveillance des machines, outils disponibles (analyse vibratoire, courant, thermographie, émission acoustique...), le Big data : quelles applications en surveillance d'équipements, études de cas maintenance prévisionnelle.
Objets mesurants et communicants : technologies innovantes pour le développement de systèmes de mesure intégrables au cœur des équipements mécaniques : l'intégration de capteurs dans les systèmes mécaniques, les nouvelles architectures et briques technologiques, cas d'application : possibilités et limitations.


- Accueil des participants par Patrice Bras, directeur de l'enseignement et de la formation à la CCI Aveyron, Catherine Pommier, direction innovation à AD'OCC, Hervé Danton, délégué à Mecanic Vallée, Didier Viratelle, conseiller technologique à Cap'tronic et Christine Desriac, déléguée régionale au Cetim.

- Les nouvelles approches de la maintenance par Sophie Sieg-Zieba, responsable des actions collectives mesure-mécatronique acoustique et vibrations au Cetim

• Nouvelles méthodes et approches en surveillance des machines
• Outils disponibles (analyse vibratoire, courant, thermographie, émission acoustique...)
• Le Big data : quelles applications en surveillance d'équipements
• Études de cas maintenance prévisionnelle

- Objets mesurants et communicants, par Olivier Duverger : référent capteurs–mécatronique au Cetim technologies innovantes pour le développement de systèmes de mesure intégrables au cœur des équipements mécaniques
• L'intégration de capteurs dans les systèmes mécaniques
• Les nouvelles architectures et briques technologiques
• Cas d'application : possibilités et limitations

- Applications concrètes des nouvelles solutions de maintenance,
par Grégory Brouillet , responsable groupe transformation digitale et sécurité électrique à Robert Bosch France - Usine de Rodez

- Débat et réponses aux questions des participants

- À l'issue de la réunion, un cocktail permettra de poursuivre les discussions

Date et lieu : 9/07/18 de 16h30 à 18h30 - Pôle de formation et d'enseignement de la CCI d'Aveyron, Centre de formation Rodez-Bourran avenue de Bruxuelles, à Rodez (12).
Prix : Gratuit.
Inscription obligatoire Cliquez ICI
Contact : Didier VIRATELLE - 06 83 04 09 78 - viratelle@captronic.fr

L'Open Source pour le développement logiciel et la sécurisation de vos objets connectés - Béziers (34) Le 25 juin 2018

Ce séminaire vous propose un état de l'art sur le sujet et une présentation détaillée des solutions open source existantes pour sécuriser vos objets connectés.

L'IoT et les objets connectés sont aujourd'hui une véritable tendance, les constructeurs à la base de leur conception omettent parfois quelques étapes cruciales en sécurité. Les attaques rencontrées « hier » avec des équipements dits « informatiques » vont, elles aussi, évoluer avec cette tendance, si bien que les développeurs devront opter pour des solutions adaptées à ces nouveaux équipements.
Si la technologie s'installe sur tous les objets, elle nous fournit également les armes pour les protéger (notamment avec le développement de solutions implémentées d'IA). Aujourd'hui plus que jamais, nous devons donc repenser la cybersécurité et adopter des technologies suffisamment modernes pour être à la hauteur des enjeux qu'emmènent cette « IoT revolution ». L'Open Source est considéré comme une véritable opportunité pour les objets connectés. Si les industriels ont traditionnellement tendance à privilégier le secret et les développements internes, la pression économique et concurrentielle les engage à se tourner peu à peu vers des solutions Open Source : l'objectif étant de rester compétitif.


Jean-Paul CRENN : Directeur et fondateur de VUCA Stratégy
Pierre FICHEUX : Directeur technique SMILE ECS
Frédéric MARAVAL : Responsable Systèmes T.R. - ISIT
Laurent MEYER : Directeur et Fondateur de Digit@m


09h45 : Accueil

10h00 : Introduction par les organisateurs & présentation du Guide Cap'Tronic
- " PME : Comment maîtriser la cybersécurité de vos objets et systèmes connectés "

10h15–11h00 (Jean-Paul CRENN) : Quels sont les enjeux stratégiques des Objets Intelligents Connectés ?
- Comment les Objets Intelligents Connectés transforment l'ensemble des modèles économiques, du retail à l'industriel.
- Comment les Objets Intelligents Connectés transforment les entreprises.
- La pyramide de la valeur des Objets Intelligents Connectés, de la Data à l'Analytique des Objets.

11h00–12h00 (Pierre FICHEUX) : solutions libres pour la mise en place des OS des capteurs utilisés dans les solutions IoT sécurisées :
- Yocto (Linux), pour les objets intelligents de type " edge computing "
- Contiki pour les capteurs basiques de type micro-contrôleur
- Prise en compte des contraintes de sécurité : risques et bonnes pratiques

12h00 - 14h00 - Buffet sur place

14h00 - 15h00 (Fréderic MARAVAL) : Cybersécurité et Systèmes embarqués : comment développer un produit Cybersecure

15h00 - 16h00 (Laurent MEYER) : Présentation d'un outil d'accompagnement à la conception d'objets communicants sécurisés.
- Identification des surfaces d'attaques d'un objet communicant.
- Fiches de risques & fiches de solutions.
- Études de cas

16h00 - 16h15 : Conclusion de la journée – Questions/Réponses


Personnes concernées : Concepteurs de systèmes embarqués et d'objets connectés, responsable qualité et chef de projet, etc.

Lieu : IUT de BEZIERS - 3 Place du 14 Juillet, 34505 Béziers

Date : Lundi 25 juin 2018 de 10h00 à 16h30 – Accueil des participants à partir de 9h30.

Prix : Gratuit, les frais liés à l'organisation de ce séminaire sont pris en charge par CAP'TRONIC et l'IUT de Béziers

Contact : José Rèbejac - 06 79 49 72 23 - rebejac@captronic.fr – Richard Salvetat - 06 86 40 94 52 - salvetat@captronic.fr

Inscription gratuite mais obligatoire

Séminaires 2.4GHz LoRa - Gardanne (13) Le 13 juin 2018

Ce séminaire a pour objectif de présenter de manière simple et didactique les principes de base de la technologie Lora, ses évolutions récentes, et surtout comment intégrer cette technologie efficacement dans vos produits avec des exemples d'applications. Les aspects matériels seront également abordés.

Inscription en ligne


9h-9h30 Accueil

9h30-9h45 Présentation EMSE et Semtech

9h45-10h15 Présentation des principes de base de la transmission RF et de la modulation

10h15-10h30 Pause café

10h30-11h Architecture et détails techniques de la famille SX128x

11h-11h30 Mise en œuvre et démo

11h30-12h Principales applications visées

12h-12h30 Témoignage d'un industriel . Questions/Réponses

12h30 Fin du séminaire

Lieu :

Ecole Supérieure des Mines
880 avenue de Mimet

Contact : Alain BRITON - CAP'TRONIC - 06 30 46 78 99
Contact inscription : Dorothée WALLART - CAP'TRONIC - 04 38 78 37 36

Séminaire gratuit - Inscription obligatoire

Comment concevoir un système embarqué - St Etienne (42) Le 1er juin 2018

Nous vous convions à participer à notre « Matinée Business » à St-Etienne.
Pour cette première édition, quatre experts se relaieront pour répondre à la
problématique : « comment concevoir un système embarqué ? »
Enfin, vous aurez la possibilité de présenter votre activité.

Inscription en ligne


8h30 : Accueil

9h00 : Intervention CIOSE

9h20 : Intervention SUDELEC

9h40 : Intervention CAP'TRONIC

10h00 : Intervention MINALOGIC

10h45 : Pitch des participants

12h00 : Collation et échanges


Lieu :

20 rue Professeur Benoît Lauras

Contact : Claude VITTORIA - CAP'TRONIC - 06 82 58 30 13
Contact inscription : Dorothée WALLART - CAP'TRONIC - 04 38 78 37 36

Séminaire gratuit - Inscription obligatoire

Allwinner VPU support in mainline Linux status update (week 19)

This week has seen considerably less advancement than the ones before it due to bank holidays in France. Nevertheless, we managed to prepare and send V3 of the Sunxi-Cedrus Linux kernel driver on Monday. While this new version contains several incremental improvements, a number of tasks (described in the series’ cover letter) have yet to … Continue reading "Allwinner VPU support in mainline Linux status update (week 19)"

Mise en œuvre du protocole Modbus (RTU) sur WaRP7 via Qt5

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).

Au sommaire de l’article

1. Introduction

1.1 Un peu d’histoire, présentation du protocole Modbus

1.2 La trame

1.2.1 L’identifiant esclave (Slave ID)

1.2.2 Le code fonction (Function Code)

1.2.3 Le contenu de la trame

2. Mise en place de l’environnement

2.1 Construction de notre distribution « WaRP7 »

2.2 Mise en route : bref rappel

2.3 SDK Qt5

2.3.1 Génération

2.3.2 Installation

2.3.3 Intégration à l’IDE Qt creator

3. Mise en situation : création du prototype Modbus

3.1 Présentation du projet

3.2 EEPROM Click

3.2.1 Présentation

3.2.2 Intégration à notre Image Kernel

3.2.3 Device tree

3.3 Relay Click

3.3.1 Présentation

3.3.2 Device tree

3.4 Flame Click

3.4.1 Présentation

3.4.2 Device tree

3.5 RS232 Click

3.5.1 Présentation

3.5.2 Device tree

3.6 Intégration & Tests

3.6.1 Fichier dts « imx7s-warp-modbus.dts »

3.6.2 Étape de compilation…

3.6.3 Mise à jour des fichiers sur cible

3.6.4 Tests rapides en espace utilisateur

4. Mise en situation : applicatif Qt

4.1 Préparation de l’environnement

4.2 Intégration Qt : modules Clicks

4.2.1 EEPROM Click

4.2.2 FLAME click

4.2.3 RELAY Click

4.3 Intégration Qt : Modbus RTU

5. Mise en situation : rendu final



Pierre-Jean Texier & Jean Chabrerie

 > Lire l’intégralité de cet article sur notre plateforme de lecture en ligne Connect  

Retrouvez cet article (et bien d’autres) dans GNU/Linux Magazine n°208, disponible sur la boutique et sur Connect !

Allwinner VPU support in mainline Linux status update (week 18)

This week, Paul continued working on DMABUF support and succeeded at exporting a buffer allocated by the Sunxi-Cedrus driver on the v4l2 side and importing it on the drm side via DMABUF. Although DMABUF support is still a work in progress in cedrus-frame-test and beyond the current level of support we have with GStreamer, the … Continue reading "Allwinner VPU support in mainline Linux status update (week 18)"

Robotique et Capteurs - Montpellier (34) Le 13 juin 2018

L'objectif de cette rencontre sera de favoriser les rencontres, entre des acteurs industriels et de services, des académiques de la robotique et des développeurs capteurs, dans la perspective de faire émerger des collaborations business et de R&D.
Nous proposerons une revue d'ensemble de cette thématique et ses perspectives, puis des industrielles viendront présenter leurs solutions, leurs produits et leurs expertises.
Nous vous inviterons par la suite à échanger directement avec les intervenants et les personnes présentes à travers les SpeedMeeting (manifestez nous votre intérêt lors de votre inscription).

Journée thématique organisée par le pôle OPTITEC en collaboration avec le cluster Robotics Place, Cap'tronic, le LIRMM et l'IES.

• 9h30 : Accueil/Café
• 10h00 : Introduction : Optitec/ Robotics Place/ Cap'tronic
• 10h15 : Conférence introductive – LIRMM / IES
• 10h45 : Talks (détails page 2)
• 11h30 : Pause
• 11h45 : Talks (détails page 3)
• 13h00 : Cocktail déjeunatoire
• 14h00 – 16h00 : SpeedMeeting


10H15 - CONFERENCE INTRODUCTIVE : Perception et commande multimodales des robots dans le cadre de la robotique collaborative

LIRMM | Philippe FRAISSE, Directeur du GDR Robotique
IES | Philippe COMBETTE, Professeur des Universités

La robotique collaborative est en train de connaître un essor important dans le domaine industriel en libérant les robots de leurs isolements contraints par des mesures de sécurité pour les opérateurs humain. Les lignes d'assemblages étaient jusqu'à présent constituées de zones où les opérateurs humains intervenaient et des zones robotisées où l'opérateur ne pouvaient pénétrer sans interrompre la chaine d'assemblage. Depuis une dizaine d'année l'interaction physique humain robot (pHRI : physical Human-Robot Interaction) suscite un regain d'intérêt auprès de la communauté de recherche internationale.

Pour augmenter les capacités d'interaction des robots, les capteurs et les mécanismes de traitement de cette information sont essentiels dans la boucle de perception commande.

Après un bref, aperçu de l'état de l'art des robots collaboratifs, nous présenterons les récents développements réalisés au LIRMM sur la commande multimodale utilisant un nombre important de capteurs (vision, tactile, force, capacitif) ainsi que les méthodes de traitements (optilisation, apprentissage) permettant d'enrichir l'interaction avec les opérateurs humains.

10H45 - Safety & Interaction solutions for Collaborative Robots

FOGALE ROBOTICS | Didier ROZIERE, Capacitive Department Manager

A l'heure où la robotique collaborative intéresse de plus en plus d'industriels, la société Fogale Nanotech propose une nouvelle technologie pour recouvrir les robots industriels d'une peau intelligente capable de détecter l'approche d'une main ou d'un objet.

De quoi apporter des solutions de coopération sûres, naturelles et faciles entre l'humain et le robot et de sécuriser les bras robotisés industriels des grandes marques.

11H00 - Association d'un robot poly articulé, d'un hexapode et d'un laser tracker pour le positionnement de haute précision

SYMETRIE | Olivier LAPIERRE, Gérant de la société

Dans le cadre de ses travaux de recherche, la société SYMETRIE présentera les résultats de la mise en oeuvre d'une solution innovante permettant de réaliser des positionnements à 6 degrés de libertés sur des grands mouvements avec une justesse de 10 μm et une résolution de déplacement de 1 μm.
Ses performances habituellement non atteignables par un robot poly articulé industriel sont obtenues en associant un hexapode de haute précision ainsi qu'un système de mesure de type laser tracker.

11H15 - Imagerie multispectrale par filtre de Bayer customisé

SILIOS | Stéphane TISSERAND, Founder & CEO

L'imagerie multispectrale intéresse de plus en plus de secteurs d'application : environnement, agriculture, médical, spatial, défense… Que ce soit pour des applications embarquées (sur drones par exemple) ou pour des applications sur postes fixes, les caméras multispectrales se doivent d'être robustes, petites, légères et à bas coût.
SILIOS Technologies à mis au point sa technologie de filtres multispectraux pixelisés COLOR SHADES® pour équiper tout type de capteurs CMOS monochromes du commerce et ainsi proposer des caméras multispectrales extrêmement compactes.

11H45 - ROSA la plateforme de robotique chirurgicale

Zimmer Biomet Robotics ou comment les nouvelles technologies améliorent le geste chirurgical ?

C'est dans ce sens que la plateforme robotique ROSA a été conçue, pour les chirurgies du crâne et de la colonne vertébrale. Ses performances en termes de précision, de sécurité ou d'ergonomie sont directement liées aux capteurs qui la compose.

12H00 - Guidage visuel de bras de chargement offshore

CYBERNETIX | Nicolas MARCASSUS, Responsable technique de l'équipe robotique

Pour robotiser des bras de chargement de GNL, Cybernétix développe une solution robuste de guidage visuel basée sur des cibles de type ARUCO.
Le système sera déployable en zone ATEX sur plate-forme pétrolière pour un fonctionnement 24/7

12H15 - Les plateformes ROV


OiS est architecte et fabricant de solutions robotiques modulaires sous-marines pour l'exploration, l'exploitation, et la mesure dans les eaux peu profondes et les fonds marins.
OiS propose une gamme de plateformes ROV et un catalogue de modules innovants. Plateformes ROV qui sont en définitive des porteurs pour des capteurs spécifiques, permettant aux clients de réaliser les mesures suivant leur besoin.

12H30 - Outils de vision 3D pour l'Industrie 4.0

TECNALIA | Valérie AUFFRAY, Directrice France

De nouveaux systèmes de vision utilisant des technologies avancées de perception 3D sont maintenant disponibles. Les capteurs sont capables d'extraire un nombre important d'information de l'environnement, en 3D et d'une manière précise et rapide.
Exemples sur des applications de détection de défauts, de localisation et d'inspection et d'évitement d'obstacles.


Lieu : Université de Montpellier (Amphithéâtre Jean-Jacques Moreau, Campus Saint Priest, Bâtiment 2)

Date : mercredi 13 juin 2018 de 9h30 à 17h00

• Adhérent Cap'tronic : Gratuit
*Contactez par email José REBEJAC - rebejac@captronic.fr - pour obtenir votre code interne Cap'tronic.

• Adhérent Optitec/Robotics : 30€ HT
• Non Adhérent : 60€ HT
• Doctorant : 15€ HT


La conception IPC intégrée - Nantes (44) Le 7 juin 2018

Si les normes IPC concernant l'assemblage des cartes électroniques sont maintenant devenues familières aux entreprises françaises qui en ont bien compris l'utilité par rapport à la fiabilisation de leurs produits en phase fabrication, l'application de l'extension de ces normes dès la conception, c'est-à-dire plus en amont, est presque totalement inexistante en France. L'objectif de ces normes est de quantifier et minimiser les risques dès la conception en analysant les défaillances possibles d'une carte, ces défaillances pouvant aller jusqu'aux problématiques d'approvisionnement ou de sous-traitance.

Cette journée vous est proposée par CAP'TRONIC en partenariat avec WE NETWORK


- Sylvain LE ROUX - JETWARE, instructeur CID/CID+, spécialisé depuis 1985, en conception et construction de cartes rigides et flexibles, HDI et HF/RF
- Antony FRICOU - TRONICO-ALCEN, Responsable pôle CAO certifié CID
- Nicolas LELOU - ATLANTEC TECHNOLOGIES, Ingénieur NPI certifié CID


  • Codification internationale des IPC série 2220 et 7351
    Introduction aux recommandations IPC de conception, avec leurs codes d'identification des niveaux (A,B,C) de la complexité de réalisation et type (1/2/3/4/5) de produits suivant l'application (HDI, Flex, PCB, PCBA …), leurs consignes de contrôle (class 1/2/3) ou modes (1/2/3) de documentation, permettant dès la conception, de prendre en compte le rendement industriel de production d'une carte électronique.
  • Règles de placement/routage IPC 2220 : CID + DFX = DFManufacturing + DFAssembly + DFTest + DFReliability
    Définition précise des empreintes des boîtiers et de l'encombrement des composants, en tenant compte de la complexité de routage CAO et d'assemblage qui en découlent, afin d'établir une stratégie de test (AOI, CIT, AXI), maîtriser les brasures et assurer la fiabilité du produit. Identification des motifs de cuivre (trous métallisés, pistes et pastilles) et des isolements (selon les tensions utilisées), permettant de réussir l'interconnexion des composants en respectant les capacités de fabrication (DFM) des sous-traitants susceptibles de réaliser le PCB.
  • Fonctions du PCBA IPC 2251 : Conception IPC Intégrée, CID+ avec matériaux et consignes de réalisation
    Traitement et mise en œuvre des consignes fonctionnelles du PCB, Electriques (RLC, CEM, PDS, HF, RF), Thermiques (CTE, MOT, W/mK, °K/W), Mécaniques (module de flexion, forme du PCB, choc, vibrations), Environnementales (reprise d'humidité, T°) et Vieillissement (CAF, MTBF). Chaque carte répond à des consignes techniques qui lui sont propres, qui font l'objet d'investigations de la part d'un ingénieur hardware, de préférence IPC/CID+, qui a développé une architecture industrielle dédiée, dont il doit assurer la reproduction à l'identique sur une durée définie, en utilisant plusieurs sources de fabrication.
  • Sélection des matériaux et empilage des PCB : IPC 4412 Verre E / 4562 Cuivre / 4101 Composite
    Identification des matériaux de base (tissus de verre E, cuivre, type de résines, charges) utilisés pour les laminés cuivrés et les pré-pregs FR4 IPC 4101 identifiables en performances, pour supporter les températures des cycles d'assemblage et de réparation avec/sans plomb. Constructions symétriques de PCB multicouches, tenant compte du comportement des matériaux utilisés pendant les étapes de fabrication.
  • Documentation du PCB : IPC 2610
    Dossier de définition ‘'international'' des caractéristiques de la carte Description du Master drawing d'une carte électronique en modes (1, 2 ou 3), de préférence mis en oeuvre par un opérateur CID (IPC Certified Interconect Designer), et qui permet de lancer un RFQ (Request For Quote), sans fournir de données Gerber, pour un chiffrage suffisamment précis des fabricants de PCB, afin de compléter le chiffrage de la BOM du PCBA.
  • Fabrication de PCB multicouche IPC 6012 : Efficience des opérations et rendement de production…
    Description synthétique et accessible des différentes étapes de fabrication des PCB multicouche, permettant d'identifier et de comprendre : la manipulation des fichiers Gerber, la diversité des opérations, la fiabilité des procédés tout au long de l'année, et les contrôle IPC 2 ou 3. Justification des délais de réalisation pertinents, dépendants des capacités du fabricant et du type d'interconnexion ou de la technologie mise en œuvre sur une carte électronique pour assurer un bon rendement.


Personnes concernées : Responsables de projets, Ingénieurs, Techniciens en charge de la conception, de la fabrication, des achats ou de la qualité… impliqués dans la réussite d'un projet hardware, qui souhaitent assurer le développement et l'industrialisation de cartes électroniques robustes et compétitives.

Date et lieu :
Jeudi 7 juin 2018 de 9h15 à 17h00

Prix : Les frais liés à l'organisation de ce séminaire sont pris en charge par CAP'TRONIC.

Contact : Jean-Philippe ENEAU - eneau@captronic.fr

Inscription gratuite mais obligatoire

La mise en conformité des produits en atmosphère explosible : Méthodologie, approches, maitrise et pratique de la certification ATEX pour les systèmes électroniques - Aix En Provence (13) Le 13 juin 2018

Ce séminaire a pour but de présenter la réglementation ATEX pour les équipements utilisés en atmosphère explosive. Il traitera des étapes de la démarche ATEX, avec notamment la présentation des directives applicables et des principaux modes de protection.
L'objectif est de bien appréhender la conception - fabrication d'un matériel ATEX dès les premières étapes du développement du projet afin de les optimiser et d'éviter toutes mauvaises surprises.
Le séminaire sera clôturé par des échanges avec l'intervenant afin d'apporter des réponses aux questions les plus concrètes.

Inscription en ligne

Intervenant :Mme Carine VIGNOLLES – Présidente Société AËXOR – Expert Atex
• Membre de la commission de standardisation AFNOR SA66A
• Membre de la commission TC 31/SC 31J/MT 60079-10-2 et 60079-10-1


► Accueil 08h45

► Partie générale ATEX – durée : 2h – Règlementation et référentiel ATEX
Directive 1999/92/CE, textes et grands principes de la règlementation ATEX
Risque d'explosion
Classification en zones et catégories
Concepts des modes de protection
Documentation DRPCE associée
Synthèse et échanges sur sollicitation

► Partie pratique – durée : 2h - Présentation des principaux modes de protections ATEX (GAZ et POUSSIERES) à mettre en oeuvre sur les équipements pour éviter les sources d'inflammation active selon la directive 2014/34/UE
Mode de protection électrique
Mode de protection mécanique
Environnement gaz et poussières

► Partie applicative – durée : 1h - Exemples de matériels électroniques certifiés - autres applications

► Conclusion / débriefing, questions débat – durée : 1h

Date et Lieu :

Le mercredi 13 juin 2018 de 9h00 à 16h45

Aix-Arbois – Forum Auditorium du Technopôle de l'Arbois
Rue Louis Philibert
Aix-en-Provence (13)
Plan d'accès

Contact : Alain BRITON - CAP'TRONIC - 06 30 46 78 99
Contact inscription : Dorothée WALLART - CAP'TRONIC - 04 38 78 37 36

Séminaire gratuit - Inscription obligatoire

Hackable n°24 est chez votre marchand de journaux

Dans ce nouveau numéro, daté mai/juin, nous nous pencherons à nouveau sur le domaine de la domotique et en particulier sur le contrôle de votre éclairage d’intérieur.

Le point de départ de cette mini-aventure se résume par l’acquisition de prises télécommandées semblant être un peu plus évoluées que celles qu’on trouve dans les magasins de bricolage. En effet, plutôt que de permettre simplement le choix des canaux via un sélecteur mécanique, ces prises sont programmables et associables à n’importe laquelle des télécommandes compatible. Il est ainsi possible de contrôler plusieurs prises avec un bouton d’une télécommande, mais également de commander une prise via plusieurs boutons de plusieurs télécommandes. Bref, on peut faire tout ce qui nous plaît sans être limité !

Il est donc possible de gérer des « scénarios » d’ambiance très facilement mais ça, c’était avant qu’on y ajoute notre grain de sel : remplacer une télécommande par un ESP8266 pour un pilotage en Wifi (via un module radio ou tout simplement en vampirisant l’émetteur de l’une des télécommandes), automatiser le basculement d’un mode d’ambiance à un autre, fournir une interface web pour commander les prises et même intégrer une extension dans Chrome/Chromium pour commander l’éclairage directement depuis la barre d’outils du navigateur.

Mais ceci n’est que l’article vedette de ce 24ème numéro. Dans les 96 pages vous trouverez, comme toujours, différents sujets abordés, allant cette fois de l’automatisation d’équipement de labo (générateur de fréquences et oscilloscope) au hack d’une puce sonore d’un Commodore 64 pour créer un lecteur de musique rétro (chiptunes) en passant par la programmation avancée des ESP32, un décryptage des normes vidéos analogiques ou encore la suite de nos expérimentations autour du processeur Z80…

Au sommaire de ce numéro 24 :

  • Equipement
    • p.04 : Automatisez vos mesures en utilisant l’USB
  • Ardu’n’co
    • p.18 : ESP32 : développez vos croquis Arduino sans l’IDE Arduino
  • Repère & Science
    • p.30 : Signaux vidéos analogiques : comment vous y retrouver ?
  • En couverture
    • p.40 : La télécommande Arduino, le retour version ESP8266 !
  • Embarqué & Informatique
    • p.64 : Robotique et électrons : mesurer une tension avec le Rpi
  • Retro Tech (Nouvelle rubrique)
    • p.72 : Pilotez le mythique MOS SID avec un Arduino pour jouer vos chiptunes
  • Démontage, Hacks & Récup
    • p.88 : Et si on faisait communiquer notre Z80 ?


Sécurisation des systèmes électroniques - Orléans (45) Le 20 juin 2018

La Sécurisation des systèmes électroniques est un des problèmes majeurs à résoudre dans les années à venir, aussi bien pour la sécurité des sites de production que pour les produits électroniques destinés au grand public.

CAP'TRONIC s'associe au CRESITT et au Pôle S2E2 et vous invite à un séminaire gratuit et ouvert à tous sur la sécurisation des systèmes électroniques.

Cette thématique s'inscrit donc dans plusieurs domaines :

> L'Internet des objets : la conception de nouveaux objets pour un grand nombre d'utilisateurs doit prendre en compte la sécurité le plus tôt possible dans la chaîne de conception, sous peine de devoir recommencer une partie de l'étude si le produit ne respecte pas les règles de sécurité demandées par des clients de plus en plus exigeants et soucieux du respect de leur vie privée.

> La conception de systèmes électroniques pour des applications professionnelles spécifiques : là encore la sécurité doit être prise en compte dès la phase d'architecture du système et les normes de sécurité auxquelles doivent répondre le produit doivent être examiner pour savoir comment les intégrer au système.

> L'Usine du futur : car les différents systèmes utilisés pour interconnecter les machines et améliorer la production sont autant de points sensibles à protéger.

L'objectif de ce séminaire est de présenter un panorama des règles de bonnes pratiques, des méthodes et des techniques qui peuvent être intégrés dans le processus de développement. Des entreprises et des laboratoires témoigneront de leur expérience dans le développement de produits ou de logiciels sécurisés.

Programme de la journée :

13H30 : Accueil

14H00 : Introduction « Panorama des enjeux et règles de bonnes pratiques », par Samuel Rouxel & Elisabeth Patouillard, CRT CRESITT (45)

14H30 : « Conception de logiciel sécurisé », par Emmanuel Poitier, ENMAN (41)

14H55 : « Secure element pour stocker les clés de cryptage », par David Balland, LEDGER (18)

15H20 : Pause café / Échanges / Stands

16H05 : « Systèmes sécurisés et biométrie », par Hervé Mongin, GL-Industrie (45)

16H30 : « Présentation des laboratoires régionaux / Sécurisation des données remontées par des capteurs à l'aide de la blockchain », par Jérémy Briffaut, INSA Bourges – LIFO/SDS (18)

17H00 : Nouvelles techniques de cryptographie, CEA-TECH (91)

17H30 : Échanges / Stands / Pot de clôture

Informations pratiques


1 avenue du Champ de Mars
Orléans, 45074 France

Inscription en ligne

Découvrez la préface du hors-série spécial Vision assistée par ordinateur !

L’automobile est un secteur qui est en pleine évolution voire révolution et qui intègre de plus en plus de fonctions d’assistance jusqu’à ce que les voitures soient elles même en passe de devenir complètement autonomes. Nombre des fonctions employées utilisent la vision par ordinateur : caméra de recul, détection de dépassement de ligne, etc. Mais le secteur automobile n’est pas le seul domaine d’application où la vision artificielle est employée. Il ne passe pas un jour où nous ne voyons pas une annonce marketing autour des smartphones promouvant telle ou telle soi-disant fonction innovante comme la reconnaissance faciale, la lecture d’émotions ou alors la transformation de votre visage en avatar.

Certes, l’évolution technologique de ces dernières années permet aujourd’hui nombre d’applications qui étaient il y a peu réservées à des expériences de laboratoire. La réalité virtuelle et la réalité augmentée en sont deux beaux exemples. Cependant, le traitement d’images et de flux vidéos sur lequel sont basées ces fonctions est encore considéré comme réservé à une élite aux compétences mathématiques pointues ou à des utilisateurs expérimentés de logiciels spécifiques tels que Photoshop. Les logiciels libres ont participé au changement de mentalité et continuent à faire bouger les lignes avec par exemple The GIMP, Krita, Blender, etc. qui n’ont rien à envier aux logiciels propriétaires. Pour preuve, nombre d’entre eux sont de plus en plus utilisés par les grosses productions hollywoodiennes comme Pixar, Dreamworks ou autres qui ont elles-mêmes contribué au développement de logiciels libres avec OpenSubdiv [1].

Dans ce guide, vous allez découvrir OpenCV qui est un ensemble de librairies sous licence BSD dédiées à la vision par ordinateur et par conséquent au traitement d’images et de flux vidéos. Ces librairies intègrent également des fonctions de deep learning qui ne seront pas abordées dans ce guide. Pour ceux qui souhaitent découvrir cet autre sujet, je vous invite à lire le hors-série numéro 94 sur le machine learning [2]. De plus, pour utiliser OpenCV, il n’est pas nécessaire d’être un expert en mathématiques, bien qu’il soit évident que des connaissances de base soient un avantage comme vous le constaterez en parcourant les différents sujets que nous allons aborder.

Ce guide est construit autour de quatre thèmes progressifs :

– « Débutez » : dans ce premier chapitre, vous allez découvrir et apprendre à mettre en place les fonctions principales et essentielles à tout traitement d’images et de flux vidéos avec OpenCV, telles que le filtrage, la détection de contours, les différents espaces colorimétriques, etc.

– « Reconnaissez » : dans cette partie, vous mettrez en application les bases apprises précédemment afin de reconnaître les expressions sur un visage.

– « Détectez » : vous allez dans cette partie apprendre à regarder une photo sous un autre angle c’est-à-dire utiliser les différentes nuances de gris pour construire un relief et ainsi dénombrer des motifs présents dans la photo : ici les fleurs d’un bouquet ou les bonbons d’une coupelle d’anniversaire. Vous verrez également comment créer un détecteur personnalisé d’objets.

– « Allez plus loin » : pour finir, plusieurs exemples d’utilisation d’actualité telles que la réalité augmentée, la mise en place de vision stéréoscopique basée sur deux Raspberry Pi et le contrôle d’application par le regard.

Pour toute nouvelle application ou idée que vous souhaitez mettre en œuvre, ne vous arrêtez pas à la perception du monde telle que vous l’avez avec vos yeux, mais posez-vous la question de ce que vous recherchez réellement : détecter un mouvement, une couleur, une variation, un objet spécifique…?

Bonne lecture.

Laurent Delmas

[1] OpenSubdiv : https://github.com/PixarAnimationStudios/OpenSubdiv

[2] Collectif, « Machine learning », GNU/Linux Magazine HS n°94, janvier-février 2018 :

Retrouvez GNU/Linux Magazine Hors-série n°96 :

L’édito de GNU/Linux Magazine n°215 !

Deux jours !

Deux jours, c’est le temps qu’il m’a fallu pour récupérer un smartphone opérationnel ! Pourquoi mon smartphone ne fonctionnait-il plus ? C’est toute une histoire qui se déroule donc sur deux jours…

Jour 1

Disposant d’un smartphone pouvant être qualifié par certains d’« assez ancien », en l’occurrence un Galaxy Note 3 de 4 ans, et désirant installer une application récente, je décidai de changer de système. En effet, le Galaxy Note 3 était sous Android 4.4.2, ayant déjà un effectué un changement de version il y a quelque temps, car Samsung n’assure plus la maintenance des Galaxy Note 3 depuis quelques années. L’application que je souhaitais installer nécessitait au minimum Android 5.0 et je décidai donc de passer sous Lineage OS et d’en profiter pour écrire un article pour Linux Pratique. L’intérêt était de montrer que l’on pouvait redonner une seconde jeunesse à son smartphone tout en restant sous Linux pour l’installation d’une ROM. Les smartphones Samsung nécessitent l’utilisation d’Odin sous Windows, mais sous Linux nous avons un équivalent open source : Heimdall. Ce dernier est présent dans les dépôts des grandes distributions et c’est seulement au bout d’une demi-journée que l’on se rend compte qu’il s’agit de la version 1.4.1, que celle-ci est boguée et qu’il faut la 1.4.2… qui doit être compilée manuellement. Bien entendu, la compilation ne fonctionne pas du premier coup et il faut compiler deux bibliothèques pour disposer des dernières versions et parvenir, enfin, à compiler Heimdall. Après avoir effectué toutes les sauvegardes d’usage, on peut donc installer le Custom Recovery open source TWRP pour Team Win Recovery Project (ajout d’une interface graphique au programme natif d’Android de récupération – recovery – le rendant plus simple à utiliser). Voilà qui s’annonce plutôt bien. Toutes ces opérations ayant pris une bonne journée, nous pouvons aller nous coucher sereinement.

Jour 2

Après avoir téléchargé la dernière version de Lineage OS adaptée à mon smartphone ainsi que les applications Google sur opengapps.org, je me lance : transfert via adb, installation puis reboot. Et là, ça marche ! Je commence donc la configuration jusqu’à ce que le système m’annonce que la carte SIM n’est pas détectée ?!?! J’ai donc au final un smartphone parfaitement fonctionnel : les mails, Internet, les applications, le GPS fonctionnent… par contre, je ne peux ni téléphoner ni envoyer de SMS. Plutôt gênant pour un téléphone ! Après diverses recherches et tests, ce qui devait arriver arriva : smartphone bloqué. Ne parvenant à rien avec Heimdall, la mort dans l’âme je passe sur Odin (oui, sous Windows) et j’arrive à débloquer le téléphone. Des heures de recherche et de tests de différentes ROM après, je récupère enfin mon smartphone sous Android 7.1 grâce à Resurrection Remix.


Il est possible de prolonger la vie de son smartphone, mais le coût en temps est assez élevé et, en tout cas pour Samsung, les outils disponibles sous Linux ne sont malheureusement pas assez développés. Il est également dommage que les constructeurs ne suivent pas plus longtemps leurs smartphones, mais c’est peut-être à nous, clients, d’arrêter de changer de téléphone tous les ans pour qu’ils comprennent ce que nous attendons. Enfin, peut-être que le Project Treble de Google visant à séparer le système Android des couches bas niveau spécifiques à chaque modèle de smartphone permettra des mises à jour plus aisées…

En attendant de voir si ce petit miracle devient réalité, vous pouvez profiter de votre magazine qui, lui, n’a pas besoin de mise à jour (pour le moment…:-)).

Tristan Colombo

Retrouvez GNU/Linux Magazine n°215 :

Allwinner VPU support in mainline Linux status update (week 17)

This week started off with numerous reviews received on the patchset introducing the Sunxi-Cedrus VPU driver. Lots of constructive comments, questions and improvements were discussed, which will help improve the driver for the next iteration of the series. Changes to other drivers will also have to be implemented, in particular to the SRAM controller found … Continue reading "Allwinner VPU support in mainline Linux status update (week 17)"

Implémentation d’un driver GPIO dans XVisor


Nous avons découvert l’hyperviseur Xvisor dans un article précédent sur le blog : Xvisor – première mise en oeuvre. Nous y avons vu comment mettre en œuvre Xvisor sur une Raspberry Pi, et dans une machine virtuelle.

Pour comprendre cet article, le lecteur doit avoir déjà manipulé Xvisor ou au moins l’article précédent mentionné ci-dessus.

Xvisor est disponible sur de nombreuses plates-formes (Raspberry pi, i.MX, …). Cependant, il ne dispose pas de tous les drivers pour ces cibles. Or il est plus agréable de tester nos manipulations concrètement en jouant avec des entrées / sorties par exemple.

Nous proposons donc d’étudier le fonctionnement des drivers / émulateurs sous Xvisor puis de développer un driver GPIO pour Xvisor sur une plateforme Raspberry Pi 3.

Cet article est organisé de la façon suivante :

  • Architecture de Xvisor: Nous rappelons l’architecture de Xvisor; les modules, le device tree, les drivers;
  • Environnement de développement: Nous posons un environnement de développement; une Raspberry Pi 3 avec un serveur NFS;
  • Nous continuons avec la conception du driver GPIO pour la Raspberry Pi 3 sous Xvisor;
  • Nous terminons avec des essais.

Architecture de Xvisor

Nous rappelons qu’un hyperviseur émule une architecture matérielle. Ainsi il est possible de faire tourner Linux (qui est alors un invité) sur une carte Saberlite émulée par Xvisor (qui est alors l’hôte) et qui lui-même tourne sur une Raspberry Pi 3. C’est ce que permettent les couples driver / émulateur au sein de Xvisor. Les drivers offrent une interface d’accès au matériel physique pour Xvisor, et les émulateurs (au sein de Xvisor) émulent le comportement d’un périphérique matériel.

Architecture générale

Xvisor émule des périphériques physiques, qui peuvent être différents des périphériques présents sur la carte. Pour cela Xvisor implémente des couples de drivers / émulateurs (comme décrit précédemment, le driver est l’interface vers le matériel physique et l’émulateur est une interface vers un matériel émulé).

Un driver peut servir plusieurs émulateurs, ainsi Xvisor offre un moyen de distribuer les drivers sur les différents émulateurs. Ce point sera décrit dans le prochain article.

Le flot de contrôle descendant vers le matériel est le suivant :

  1. L’invité effectue une demande (lecture ou écriture) vers une interface physique;
  2. Cette demande est captée par un émulateur;
  3. L’émulateur traite la demande et la transforme en une requête vers le driver approprié si besoin;
  4. Le driver traite la demande

Le flot de contrôle ascendant est symétrique, le mécanisme de notification du driver vers l’émulateur est différent, dans notre cas, le driver émet une interruption vers l’émulateur.

Notons qu’un émulateur peut très bien émuler le fonctionnement complet d’un périphérique sans avoir besoin de driver ou, au contraire, solliciter plusieurs drivers. L’objectif est tout de même de construire des émulateurs simples pour maximiser l’efficacité du système complet.

Les drivers et émulateurs de Xvisor sont implémentés comme des modules.

Les modules

Un module définit un ensemble de fonctionnalités. Les modules de Xvisor sont fortement inspirés des modules de Linux. Ils sont chargés au démarrage de Xvisor et peuvent être déchargés durant l’exécution. L’activation ou la désactivation du module se fait lors de la configuration / compilation de Xvisor. Actuellement, tous les modules sont chargés statiquement au démarrage. Il est possible de les charger dynamiquement au moyen de la commande “module load”.

Un module est constitué des éléments suivants :

  • Une structure de données vmm_module. Cette structure est compilée dans la section .modtbl;
  • Une fonction d’initialisation / chargement;
  • Une fonction de déchargement;

La structure vmm_module contient des informations sur le module ainsi qu’un pointeur de fonction permettant d’initialiser le module et un pointeur de fonction permettant de décharger le module.

La variable de type struct vmm_module est définie grâce à la macro VMM_DECLARE_MODULE.


Les paramètres de VMM_DECLARE_MODULE sont également des macros :

  • MODULE_DESC : la description du module
  • MODULE_AUTHOR : l’auteur du module
  • MODULE_LICENSE : la licence du module
  • MODULE_IPRIORITY : la priorité du module
  • MODULE_INIT : un pointeur de fonction vers la fonction d’initialisation du module
  • MODULE_EXIT : un pointeur de fonction vers la fonction de déchargement du module

Voici un exemple simple de création de module.

Choisissons de créer un module module_test qui affiche "Hello World" lors de l’initialisation de Xvisor. Nous le positionnons dans :


Le contenu du fichier module_test.c est :

#include <vmm_stdio.h>
#include <vmm_modules.h>
#include <vmm_devemu.h>

#define MODULE_DESC "Test module"
#define MODULE_AUTHOR "Je"
#define MODULE_INIT module_test_init
#define MODULE_EXIT module_test_exit

static int __init module_test_init(void) {
 vmm_printf("%s: Hello World\n", __func__);
 return 0;

static void __exit module_test_exit(void) {
 vmm_printf("%s: Bye World\n", __func__);


Il nous faut ensuite déclarer le module dans son environnement.

Le répertoire drivers/gpio contient les modules et la configuration :

├── gpio-mmio.c
├── gpio-mxc.c
├── gpiolib-legacy.c
├── gpiolib-of.c
├── gpiolib.c
├── gpiolib.h
├── module-test.c
├── objects.mk
└── openconf.cfg

Nous nous intéressons à notre fichier module_test.c mais aussi aux fichiers objects.mk et openconf.cfg.

Nous choisissons de créer un module statique (built-in), il sera donc chargé au démarrage de Xvisor sans possibilité de le décharger.

Il est possible créer des modules dynamiques, pour cela il faut ajouter le support des modules dynamiques dans la configuration de Xvisor. Il sera alors possible de charger le module avec la commande module load. Notons que nous n’avons pas encore testé cette fonctionnalité.

Ajoutons le module à objects.mk :

drivers-objs-$(CONFIG_MODULE_TEST)+= gpio/module-test.o

Ajoutons nos règles à openconf.cfg :

         def_bool y
         default y

Nous pouvons dès lors tester le module en générant Xvisor pour le modèle de ARMv8 par exemple. Vous trouverez le détail dans l’article précédent.

Lors de l’initialisation de Xvisor, et donc de l’initialisation du module, le message module_test_init: Hello World est affiché dans la console.

On peut consulter la liste des modules disponibles en utilisant la commande module sous l’invite de commande Xvisor.

Sous la console Xvisor :

XVisor# module help
   module help
   module list
   module info 
   module unload

XVisor# module list
 Num   Name                        Author               License     Type 
 15    sp804                       Anup Patel           GPL         built-in 
 16    sp805                       Anup Patel           GPL         built-in 
 17    module_test                 Je                   GPL         built-in 
 18    bcm2835_mailbox             Anup Patel           GPL         built-in 
 19    mailbox                     Anup Patel           GPL         built-in 

Cette commande permet, entre autre, de lister les modules (module list) et de vérifier qu’un module est bien chargé.

Xvisor utilise actuellement deux types de modules : les drivers et les émulateurs. Ces deux types de modules déclarent une structure similaire à vmm_module et des fonctions pour enregistrer et supprimer ces structures. Le système de chargement de modules ne peut  différencier les différents types de modules. Seul l’implémentation du module le permet. En effet, les émulateurs et les drivers sont tous les deux implémentés sous forme de module générique.

Lorsque Xvisor charge un module, il va lire la section .modtbl du fichier objet. Il va pouvoir ainsi charger la structure présentée dans cette section, puis appeler la fonction d’initialisation pointée par MODULE_INIT. Cette dernière sert à préparer le module pour qu’il soit prêt à être utilisé.

L’intégration d’un module dans Xvisor est présenté plus loin dans l’article.

L’objet d’un driver est d’offrir une interface vers le périphérique afférent. Ainsi, le driver doit accéder aux ressources physiques du périphérique; configurer le contenu de ses registres, contrôler son comportement. Étant donné la multiplicité des périphériques et leurs multiples configurations, la communauté Linux a développé depuis quelques années un concept appelé Device Tree.

Le Device Tree

Le Device Tree est la configuration du logiciel vers les ressources matérielles de la cible (registres des périphériques, mémoire, fréquences, interruptions, exceptions, etc.), il est chargé par le noyau au démarrage.

Prenons le cas de notre driver GPIO. Celui-ci va interagir avec des ressources de la cible matérielle. Les caractéristiques de la cible sont décrites dans un Device Tree, et le module implémentant le driver viendra piocher les ressources dont il a besoin dans ce Device Tree, telles que les adresses des registres, la constitution des registres bit par bit, la configuration des périphériques (vitesses d’horloge, forme des signaux, codage, etc.). Par ailleurs les émulateurs sont accompagnés d’un Device Tree car les drivers des invités doivent également avoir le moyen de connaître les caractéristiques de la cible émulée. Il y a donc deux niveaux de Device Tree, l’un entre la cible matérielle et Xvisor, l’autre entre Xvisor et les invités.

Le Device Tree est une structure de données arborescente sous forme de nœuds et propriétés. Une propriété est un couple clé-valeur. Un nœud peut contenir des propriétés, d’autres nœuds ou les deux.

Par exemple (copié de cette page) :

/ {
    node1 {
        a-string-property = "A string";
        a-string-list-property = "first string", "second string";
        // L'écriture hexadécimale est implicite pour les tableaux de bytes.
        // Il n'est pas nécessaire d'utiliser le préfixe 0x
        a-byte-data-property = [01 23 34 56];
        child-node1 {
            second-child-property = <1>;
            a-string-property = "Hello, world";
        child-node2 {
    node2 {
        a-cell-property = <1 2 3 4>; /* Chaque nombre est un uint32 */
        child-node1 {


Les drivers et émulateurs

Les drivers et émulateurs sont des modules, par exemple la fonction d’initialisation du driver GPIO est la suivante :

static int __init bcm2835_pinctrl_init(void)
return vmm_devdrv_register_driver(&bcm2835_pinctrl_driver);

vmm_devdrv_register_driver est une fonction définie par Xvisor qui permet d’enregistrer le driver grâce à une structure de donnée similaire à celle définissant un module.

static struct platform_driver bcm2835_pinctrl_driver = {
.probe  = bcm2835_pinctrl_probe,
.remove = bcm2835_pinctrl_remove,
.driver = {
.name           = MODULE_NAME,
.owner          = THIS_MODULE,
.of_match_table = bcm2835_pinctrl_match,

Le membre probe de la structure est un pointeur de fonction vers la fonction de sondage du périphérique. Cette fonction initialise le driver et l’installe si il peut être installé. Un driver ne peut être installé que si la propriété compatible du device tree (figure 7) est incluse dans of_match_table et que le driver n’est pas déjà présent.

Les émulateurs font appel à une fonction d’enregistrement similaire qui enregistre une structure de donnée définie pour les émulateurs.

Par exemple, la fonction d’initialisation de l’émulateur gpio_forward est la suivante :

static int __init gpio_forward_emulator_init(void)
return vmm_devemu_register_emulator(&gpio_forward_emulator);

gpio_forward_emulator :

static struct vmm_emulator gpio_forward_emulator = {
.name        = "gpio-forward",
.match_table = gpio_forward_emuid_table,
.probe       = gpio_forward_emulator_probe,
.reset       = gpio_forward_emulator_reset,
.sync        = gpio_forward_emulator_sync,
.remove      = gpio_forward_emulator_remove,

Le membre match_table sert au même but que of_match_table pour la structure platform_driver.


Le driver GPIO

Sous Xvisor, les drivers et émulateurs sont des modules, le lien entre ces modules est concrétisé dans le Device Tree.

La fonction d’initialisation du driver GPIO est la suivante :

static int __init bcm2835_pinctrl_init(void)
return vmm_devdrv_register_driver(&bcm2835_pinctrl_driver);

vmm_devdrv_register_driver est une fonction définie par Xvisor qui permet d’enregistrer le driver grâce à une structure de donnée similaire à celle définissant un module :

static struct platform_driver bcm2835_pinctrl_driver = {
.probe  = bcm2835_pinctrl_probe,
.remove = bcm2835_pinctrl_remove,
.driver = {
.name           = MODULE_NAME,
.owner          = THIS_MODULE,
.of_match_table = bcm2835_pinctrl_match,

Le membre probe de la structure est un pointeur de fonction vers la fonction de sondage du périphérique. Cette fonction initialise le driver et l’installe si il peut être installé. Un driver ne peut être installé que si la propriété compatible du Device Tree (figure 7) est incluse dans of_match_table et que le driver n’est pas déjà présent.

Les émulateurs font appel à une fonction d’enregistrement similaire qui enregistre une structure de donnée définie pour les émulateurs.

Par exemple, la fonction d’initialisation de l’émulateur gpio_forward est la suivante :

static int __init gpio_forward_emulator_init(void)
return vmm_devemu_register_emulator(&gpio_forward_emulator);

gpio_forward_emulator :

static struct vmm_emulator gpio_forward_emulator = {
.name        = "gpio-forward",
.match_table = gpio_forward_emuid_table,
.probe       = gpio_forward_emulator_probe,
.reset       = gpio_forward_emulator_reset,
.sync        = gpio_forward_emulator_sync,
.remove      = gpio_forward_emulator_remove,

Le membre match_table sert au même but que of_match_table pour la structure platform_driver.

Enfin, une partie du Device Tree liant les deux modules est :

gpio0 {
manifest_type = "virtual";
guest_physical_addr = <0x10013000>;
gpio-slave {
device_type = "gpio-slave";
out_gpio = <1 2 3>;

Les drivers et les émulateurs sont chargés s’il y a un nœud correspondant au périphérique (physique ou simulé) dans le Device Tree de la carte ou de l’invité. La correspondance entre le driver (ou l’émulateur) et le nœud du Device Tree est fait grâce à la propriété compatible.

Les drivers et les émulateurs ont, dans les structures de données les représentants, un attribut match_table ou of_match_table représentant la table de correspondance. Cet attribut sert à être comparé à la propriété compatible du nœud du Device Tree. Le driver ou l’émulateur n’est chargé que si la propriété est présente dans la table de correspondance. Nous précisons l’utilisation de ces attributs plus loin dans l’article.


Conception du driver GPIO

Nous avons choisi de partir d’un driver existant sous Linux et fonctionnant déjà sur Raspberry PI 3.

Préparation de Xvisor

Pour pouvoir manipuler le driver, il faut tout d’abord l’intégrer à la chaîne de compilation de Xvisor.
Dans le dossier drivers/gpio de Xvisor, il y a deux fichiers : object.mk et openconf.cfg.

openconf.cfg définit les variables de compilation. Ces variables servent à déterminer les fichiers à compiler ou sont utilisés par le pré-processeur C pour activer ou désactiver des parties de code.

object.mk déclare les variables requises pour ajouter un fichier au code à compiler.

Pour que le driver soit compilé dans Xvisor, il faut activer les variables requises pour sa compilation. Il faut ajouter ces variables dans le fichier defconfig (dans arch/<architecture>/config) utilisé (par exemple bcm2835_v8_defconfig pour la Raspberry Pi 3).

Le fichier openconf.cfg pour le driver GPIO pour la Raspberry Pi 3 est le suivant :

bool "BCM2835 pinctrl driver"
Say Y here to enable the BCM2835 pinctrl driver

Ce fichier définit une variable CONFIG_PINCTRL_BCM2835 qui requiert, pour être activée, d’avoir activé CONFIG_PINCTRL et CONFIG_GPIOLIB. De plus, lorsque cette variable est activée, les variables CONFIG_OF_GPIO, CONFIG_GPIO_GENERIC, CONFIG_GPIOLIB_IRQCHIP, CONFIG_PINMUX et CONFIG_PINCONF sont activées.

Le fichier object.mk, pour le même driver est le suivant:

drivers-objs-\$(CONFIG_PINCTRL_BCM2835)+= pinctrl/bcm/pinctrl-bcm2835.o

Ce fichier indique à la chaîne de compilation que pour ajouter le fichier objet du driver, il faut que la variable CONFIG_PINCTRL_BCM2835 soit activée.

Pour compiler le driver GPIO pour Raspberry Pi 3 il faut donc rajouter les variables CONFIG_PINCTRL_BCM2835, CONFIG_PINCTRL et CONFIG_GPIOLIB dans bcm2835_v8_defconfig. On peut aussi
utiliser make menuconfig qui fournit une interface graphique pour la configuration de la compilation.

Extrait de bcm2835_v8_defconfig:


Environnement de développement

La Raspberry Pi 3

Préparation de la carte SD

Nous avons déjà vu, dans l’article précédent, comment préparer une carte SD en vue d’accueillir les images générées lors de la construction de Xvisor. La démarche adoptée dans cet article est plus souple, mais nécessite un peu de configuration au préalable. Elle consistera à démarrer la Raspberry Pi 3 avec une version de U-Boot pouvant démarrer sur un réseau avec NFS. Nous rappelons ce que doit contenir une carte SD pour lancer Xvisor sur une Raspberry Pi (1,2,3) :

    • L’image de U-Boot : u-boot.bin sur la partition boot;
    • L’image de Xvisor : uvmm.bin sur la partition data;
    • le fichier DTB qui décrit les paramètres bas-niveau des invités, par exemple : one_guest_virt-v8.dtb (un invité sur une architecture ARMv8) sur la partition data;;
    • L’image de Xvisor contenant les invités : udisk.img sur la partition data;.

Nous commençons par préparer une carte SD prête à recevoir l’image Xvisor. Si vous avez déjà installé une Raspbian ou toute autre distribution permettant de démarrer votre Rapsberry Pi 3, alors ce qui suit n’est pas utile. Dans l’autre cas voici une démarche simple. On récupère une image de Raspbian, puis on la transfère en mode bloc sur la carte SD. Tout est clairement expliqué sur le site de Raspberry: https://www.raspberrypi.org/documentation/installation/installing-images/linux.md La carte est constituée de 2 partitions, une partition de boot au format FAT, et une partition data au format ext4. Ces deux partitions sont référencées de la façon suivante :

    • boot : /media/<user>/boot
    • data : /media/<user>/data

La carte est prête. Notre objectif est d’éviter de copier systématiquement les images sur la partition data de la carte SD, nous allons donc partager notre environnement PC au travers d’une liaison réseau avec la Raspberry Pi. Nous configurons tout d’abord U-Boot.

Création de u-boot.bin

Nous téléchargeons U-Boot puis le compilons:

$ cd $HOME/workspace/xvisor-tree/u-boot
$ wget ftp://ftp.denx.de/pub/u-boot/u-boot-2016.09-rc1.tar.bz2
$ tar xvf u-boot-2016.09-rc1.tar.bz2
$ cd $HOME/workspace/xvisor-tree/u-boot/u-boot-2016.09-rc1
$ make rpi_3_defconfig
$ make all

Nous obtenons un fichier u-boot.bin qu’il faut copier sur la partition boot de la carte sd.

Insérer cette dernière, puis :

$ cp u-boot.bin /media/<user>/boot

Éditer le fichier config.txt se trouvant sur la partition boot de la carte sd et y ajouter les lignes suivantes :


Ces lignes permettent, respectivement, de :

  • activer la console série, option “enable_uart”;
  • modifier le mode de démarrage de la carte sur l’architecture aarch64 (mode 64bits), option “arm_control”;
  • indiquer le nom de l’exécutable à lancer pour le boot de la carte, ici il s’agit de u-boot.bin, option “kernel”.

Il faut démonter le périphérique:

$ umount /dev/<votre media>

Nous avons également construit dans le répertoire tools l’utilitaire mkimage qui nous servira par la suite.

A ce point, nous pouvons d’ores et déjà tester si la carte démarre correctement. Nous utilisons un adaptateur USB-TTL, par exemple https://www.kubii.fr/composants-raspberry-pi/1761-cable-usb-vers-ttl-4-pin-3272496006263.html.

La connexion est simple :

  • pin2 : alimentation câble rouge;
  • pin6 : masse, câble noir;
  • pin8 : TXD, câble blanc;
  • pin 10 : RXD, câble vert.

Pour un exemple, on peut consulter https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/overview.

On connecte le câble USB, puis on démarre minicom :

$ minicom -b 115200 -D /dev/ttyUSB0

Dès la mise sous tension de la carte, u-boot attend quelques secondes puis démarre son autoboot. Pour éviter ceci, il suffit d’appuyer sur une touche avant la fin du compte à rebours. Débrancher et reconnecter le câble usb pour redémarrer la carte.

Si vous voyez l’invite de commande U-Boot, alors la carte est fonctionnelle.

Mise en place du réseau NFS

Nous avons une carte SD, avec U-Boot, prête à démarrer. Nous voulons que U-Boot démarre en téléchargeant les images de Xvisor puis les lance à partir d’un serveur (notre machine de développement).

Nous configurons l’environnement NFS en deux étapes; la machine de développement, puis U-Boot.

Configuration du serveur NFS

Notre machine de développement sera le serveur auprès duquel U-Boot viendra télécharger les images pour démarrer Xvisor.

Nous donnons un exemple dans un environnement Linux Ubuntu.

Nous choisissons un répertoire NFS, /srv/nfs, sur notre machine. Cette dernière possède l’adresse IP (utiliser ip a ou ifconfig pour la récupérer).

Nous choisissons l’adresse IP pour la Raspberry Pi 3.

Pour créer un serveur NFS, il faut installer le paquet nfs-kernel-server (le paquet peut avoir un autre nom sur une autre distribution). Ensuite, on configure le serveur NFS dans le fichier /etc/exports :

<chemin du répertoire racine NFS> *(rw,no_root_squash,no_all_squash,sync)

Dans notre cas, on crée le fichier /etc/exports et on y écrit la ligne suivante :

/srv/nfs *(rw,no_root_squash,no_all_squash,sync)

Ensuite il faut lancer ou relancer le serveur. C’est fait en (re)démarrant le daemon :

$ sudo systemctl enable nfs # Relance le daemon au démarrage
$ sudo systemctl start nfs # Lance le daemon

ou, au cas où le daemon est déjà lancé:

$ sudo systemctl enable nfs # Relance le daemon au démarrage
$ sudo systemctl restart nfs # Relance le daemon

Le serveur est prêt, passons à la configuration côté client.

Configuration de U-Boot

Nous créons un fichier boot.cmd dans lequel on écrit :

setenv ipaddr
setenv serverip
setenv rootdir /srv/nfs
nfs 200000 $rootdir/uvmm.bin # 20 000
nfs 2000000 $rootdir/udisk.img # 2 000 000
nfs 800000 $rootdir/one_guest_virt-v8.dtb # 80 000
bootm 20000 2000000 800000
setenv bootcmd "nfs 200000 $rootdir/uvmm.bin;\
nfs 2000000 $rootdir/udisk.img;\
nfs 800000 $rootdir/one_guest_virt-v8.dtb;\
bootm 20000 2000000 800000"

La commande nfs permet de charger en mémoire un fichier présent dans le répertoire NFS. La syntaxe est nfs <adresse mémoire> <chemin du fichier>.
La commande bootm sert à indiquer où sont positionnés, dans la mémoire, les fichiers nécessaire au démarrage.
La variable prédéfinie bootcmd définie la ou les commandes à exécuter lors du démarrage.

Ensuite il faut compiler le script boot.cmd :

mkimage -C none -A arm64 -T script -d "${dir}/boot.cmd" "${dir}/boot.scr"

avec ${dir} l’emplacement du script.

(avec ${dir} le chemin où est enregistré boot.cmd).

Pour que u-boot puisse utiliser ce script, il faut le placer dans la partition boot de la carte SD.

Une fois ces deux étapes finies, il suffit de copier les fichiers de Xvisor dans le répertoire NFS et de redémarrer la Raspberry PI 3 pour démarrer sur Xvisor, sans avoir à enlever la carte SD.

Conception du driver GPIO


L’architecture des GPIO de Xvisor peut être divisée en trois parties () :

  • l’émulateur
  • la commande Xvisor; cette commande est un shell à disposition. Ce shell nous permet d’interagir directement avec le driver.
  • le driver


Architecture GPIO

La commande gpio de Xvisor communique avec le driver en faisant des appels à gpiolib.

Le driver GPIO est composé de deux parties. gpiolib définit les fonctions de manipulation des GPIO. Ces fonctions sont communes à tous les drivers. Elles font appel aux fonctions définies dans le driver GPIO. Le driver GPIO implémente les fonctions de manipulation pour le composant, par exemple les GPIO de la Raspberry Pi 3.

L’émulateur est composé de l’émulateur GPIO et du framework d’émulation de composants. Le framework d’émulation de composants fourni une interface entre l’émulateur et la gestion des invités. L’émulateur de GPIO communique avec le driver par l’intermédiaire d’interruptions.

Choix du driver de départ

Pour porter un driver il faut tout d’abord choisir sur quel driver s’appuyer. Une solution est d’utiliser le driver Linux pour le composant sur cette plateforme. En effet, Xvisor est fortement inspiré de Linux. Les modifications à apporter au driver seront réduites.

Nous remplaçons le driver “driver/pinctrl/bcm/pinctrl-bcm2835.c” par celui de Raspbian disponible à https://github. om/raspberrypi/linux/blob/rpi-4.9.y/drivers/pin trl/b m/pin trl-b m2835.c


Modification du driver

La première étape du portage d’un driver est l’identification des fonctions et structures de données à modifier.

La mise au point de ces fonctions peut être facilitée en utilisant la macro BUG Xvisor. Xvisor terminera l’exécution de l’invité sur la fonction attachée à la macro.
On peut utiliser vmm_printf pour afficher des informations à cet instant.

Par exemple:

#define NOT_IMPLEMENTED vmm_printf("%s not implemented\n", __func__); \

Le code applicatif suivant:

void foo() {

affichera :

foo not implemented
Bug is in foo() at foo.c:200
Please reset the system

si foo() est implémenté à la ligne 200 de foo.c

Le travail consiste alors à l’adapter à notre besoin, pour cela je vous invite à analyser les commits disponibles sur https://github.com/avpatel/xvisor-next. Ces derniers sont assez explicites, le gros du travail étant de comprendre l’architecture de Xvisor, savoir quel driver remplacer et de quel driver partir.

Les commits intéressants sont les suivants :

  • 4d5633f5a1b848c1f6324fea7343f4086cbef334 : configuration et driver
  • 57db8e2bc8a34ba5b49d09775d69d7f7872dfadd : configuration

Pour cela l’outil graphique gitk est plutôt pratique, sinon on utilise le traditionnel git show.

Device Tree

Pour charger le module dans le noyau, il faut le configurer dans le device tree en y ajoutant le nouveau noeud GPIO.

La configuration d’un device tree est assez complexe.

Dans notre cas, nous avons un noeud gpio0 définissant les lignes de gpio en entrée (gpio_in_irq) et en sortie (gpio_out_irq).

gpio0 {
manifest_type = "virtual";
address_type = "memory";
guest_physical_addr = <0x10013000>;
physical_size = <0x1000>;
device_type = "gpio";
compatible = "primecell,pl061";
gpio_in_invert = <0 0 0 0 0 0 0 0>;
gpio_in_irq = <1400 1401 1402 1403 1404 1405 1406 1407>;
gpio_out_irq = <1408 1409 1410 1411 1412 1413 1414 1415>;
interrupts = <38>;

Le commit correspondant au driver GPIO est le suivant :

  • 74db889124183876ef0af2a6927e272b68da2c2f : s’intéresser au fichier /arch/arm/board/generic/dts/bcm2837/bcm2837.dtsi

On remarquera, dans ce device tree, l’existance du noeud SERIAL0: uart0. Ce noeud implémente un émulateur de base permettant de tester le driver GPIO, il permet d’utiliser la commande gpio de Xvisor, commande permettant de manipulier le GPIO dans le shell.

Nous n’entrons pas plus dans les détails de la configuration du device tree.

Test du driver

La commande gpio de Xvisor nous sert à faire notre test.

Xvisor # gpio help
Usage :
gpio help - Displays the help
gpio list - Displays the GPIOs
gpio set ID {in , out } [1/0] - Set direction and value

Par exemple :

Xvisor # gpio set 1 out 0
Xvisor # gpio set 1 in

Il reste à réaliser un petit montage avec une breadboard, quelques leds et résistances pour visualiser le résultat, et ne pas se tromper de GPIO.

On trouvera plétore de montages sur le net, par exemple https://thepihut.com/blogs/raspberry-pi-tutorials/27968772-turning-on-an-led-with-your-raspberry-pis-gpio-pins

Un montage type est :

Écriture de l’émulateur

Nous avons un driver GPIO disponible qui, pour l’instant, n’est pas utilisable d’un système invité. L’émulateur permet de router et multiplexer les GPIO entre le driver bas-niveau de Xvisor / RPI3 et les drivers des invités.

En réalité, un émulateur est constitué de :

  • un émulateur qui simule le périphérique,
  • un émulateur-esclave qui sert d’intermédiaire entre le driver et l’émulateur.

En ce qui concerne les GPIO, nous avons déjà 2 émulateurs disponibles, mais incomplets:

  • l’émulateur : pl061,
  • l’émulateur-esclave : gpio-forward, de type gpio-slave dans le device tree.

L’émulateur pl061 définit des gpiochip. Un gpiochip contient deux lignes de gpio:

  • une ligne de GPIO en entrée,
  • une ligne de GPIO en sortie.

Dans notre exemple, le noeud de GPIO virtuelle du Device Tree (gpio0) définit une gpiochip possédant les caractéristiques suivantes:

  • Des GPIO en entrée; [1400, 1407],
  • Des GPIO en sortie; [1408, 1415].


On s’intéresse aux commits suivants :

  • cc54ee806a01a4bd665094362f82b772f92f5137 et 4a73bd36b15ac06296203fdc4ed287a35b04d3a8 : gpio-forward; utilisation des descripteurs gpio au lieu des numéros,
  • a4804774b6c45b33c30ec0bb5ef20bab04379d37 : gestion des directions in / out, interruption virtuelle,
  • 155ce095536c33f874a9944c083bf570938ee853 : ajout d’une API pour communiquer entre VCPU normaux (espace utilisateur invité) et VCPU orphelins (espace noyau Xvisor).

Tester le driver dans un invité

Pour tester le driver complet, il suffira de reprendre la procédure décrite dans le premier article et de le tester sur la Raspberry Pi 3. Attention à bien utiliser la dernière version de Xvisor.

Voici quelques exemples de manipulation à réaliser dans notre invité.

[guest0/uart0] /sys/class/gpio $ echo 506 > export
[guest0/uart0] /sys/class/gpio $ echo out > gpio506/direction
[guest0/uart0] /sys/class/gpio $ echo 0 > gpio506/value

On peut visualiser l’état des GPIO sous Xvisor avec gpio list, par exemple :

Xvisor# gpio list
GPIOs 0-53, platform/gpio@3f200000, pinctrl-bcm2835:
gpio-0   (guest0              ) out low     irq_no=1024, flags=0x3
gpio-1   (guest0              ) out low     irq_no=1025, flags=0x3
gpio-2   (guest0              ) in  high     irq_no=1026, flags=0x1
gpio-3   (guest0              ) out low     irq_no=1027, flags=0x3
gpio-4   (guest0              ) in  high     irq_no=1028, flags=0x1

On remarquera l’utilisation de la GPIO 506 dans le test ci-dessus. Linux gère les GPIO par paquets, avec les contrôleurs gpiochip.

Voir pour cela le document suivant https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/gpio/sysfs.txt

GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
  controller implementing GPIOs starting at #42) and have the following read-only attributes:

    "base" ... same as N, the first GPIO managed by this chip
    "label" ... provided for diagnostics (not always unique)
    "ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)

On retiendra que la gpio numéro 2 du contrôleur gpiochip504 est identifiée par le numéro 506, et elle correspondra, dans notre exmple aux gpio 1402 en entrée et 1410 en sortie.


Cet article nous a permis d’entrer dans le coeur de Xvisor et proposer une démarche pour ajouter un driver (toujours avec l’émulateur qui va avec). Nous pourrions aller beaucoup plus loin en testant le driver GPIO distribué avec plusieurs invités en parallèle.

Dans ces cas, comment gérer les interactions possibles entre invités, comment s’assurer de ne pas allouer le même port à plusieurs invités ?

Si vous voulez vous lancer dans l’écriture d’un driver pour Xvisor et en particulier sur RPI3, vous serez très bien accueillis par l’initiateur de projet. Le projet reste vivace, avec l’initiative toute récente d’un meta Yocto pour Xvisor.



Branche de développement : https://github.com/avpatel/xvisor-next


Sensibilisation à la fiabilisation d'un ensemble électronique - Talence (33) Le 20 juin 2018

L'objectif de ce séminaire est de sensibiliser les participants à la fiabilisation des systèmes électroniques, et d'appréhender les tâches à mener pour obtenir un produit fiable en fonction des contraintes appliquées.


Jean-Michel LASSERRE - Responsable Pôle de compétence Fiabilité chez SERMA TECHNOLOGIES.


- Définitions de la fiabilité
- Défaillance abrupte (catalectique) et défaut d'usure
- Exemple de mécanismes de défaillance

Utilisation des mathématiques
- Fonction taux de défaillance l(t)
- Evolution du taux de défaillance dans le temps (courbe en baignoire)
- Utilisation des lois statistiques et leur limitation :
- Exponentielle
- Weibull
- Echantillonnage :
- Ki²

Evaluation de la fiabilité prévisionnelle
- Méthodes théoriques (MIL-HDBK-217, IEC 62380, FIDES)

Notre approche : « La fiabilisation par la technologie »
- Définition du profil de vie du produit
- Analyse de risques (technologies versus profil de vie)
- Composants et technologies
- Design
- Industrialisation

Construction d'une filière d'évaluation ciblée
- Validation des technologies : Composants, brasures etc…
- Essais de robustesse : Le HALT
- Essais de durabilité : Lois d'accélération (Arrhenius, Coffin Manson et Norris Landzberg, Hallberg Peck…)
- Procédés de fabrication

Positionnement du déverminage
- Définition du déverminage
- POS et SOS
- Efficacité du déverminage

Questions / Réponses


Personnes concernées : Responsable technique ou de bureaux d'étude, Ingénieur Chef de Projet, Responsable fiabilité.

Pré requis : Niveau de technicien supérieur expérimenté ou d'ingénieur travaillant sur la qualité ou fiabilité d'un produit soit au niveau de sa fabrication ou de sa sélection.

Lieu : IMS - Bâtiment A31, 351 Cours de la Libération, 33400 TALENCE

Date : mercredi 20 juin 2018 de 9h00 à 17h00 – Accueil des participants à 8h45

Prix : Gratuit - Les frais liés à ce séminaire sont pris en charge par les organisateurs.

Contact : Thierry ROUBEIX – 06 79 49 15 99 – roubeix@captronic.fr

Inscription obligatoire sur notre site

Contrôlez votre éclairage d’intérieur en Wifi !

Le nouveau Hackable vous propose de contrôler votre éclairage d’intérieur en Wifi. Au menu : la création d’ambiances et de scénarios avec vos luminaires, l’interfaçage d’une télécommande avec l’ESP8266 et l’intégration du contrôle de l’éclairage dans un navigateur. Découvrez également dans ce nouveau numéro comment créer un lecteur de chiptunes en pilotant la puce sonore d’un Commodore 64 avec une carte Arduino, mesurer simplement une tension avec votre Pi grâce à Python et un ADC SPI ou encore connecter vos oscilloscopes et générateurs de fonctions Rigol en USB pour automatiser vos mesures… Rendez-vous en kiosque, sur notre boutique et sur notre plateforme de lecture en ligne Connect pour découvrir ce 24ème numéro ! 

Au sommaire


p. 04 Automatisez vos mesures en utilisant l’USB


p. 18 ESP32 : développez vos croquis Arduino sans l’IDE Arduino

Repère & Science

p. 30 Signaux vidéos analogiques : comment vous y retrouver ?

En couverture

p. 40 La télécommande Arduino, le retour version ESP8266 !

Embarqué & Informatique

p. 64 Robotique et électrons : mesurer une tension avec le Rpi

Retro Tech

p. 72 Pilotez le mythique MOS SID avec un Arduino pour jouer vos chiptunes

Démontage, Hacks & Récup

p. 88 Et si on faisait communiquer notre Z80 ?