Gabor Farkas' Practical GIS (Packt Publishing)

Open-source GIS tools are maturing rapidly, and Gábor Farkas' new book Practical GIS is a guide to applying these tools to managing geographic information like a pro at minimal cost. Farkas deploys the popular QGIS application and explains how to use it to generate useful spatial data. more>>

The Current Phase of the Moon

Ladies and gentlemen, we've left Mars. Well, at least I'm done with the Martian lander from my past few articles. I hope you had chance to experiment with it and find out that it's not too easy to land a craft on any planet! more>>

Mastering ATA over Ethernet

At one point in time, when you wanted to attach an external block storage device to a server, you mapped it as a Logical Unit (LU) across a Storage Area Network (SAN). In the early days, you would do this over the Fibre Channel (FC) protocol. More recently, iSCSI (SCSI over IP) has usurped FC in most data centers. more>>

The Family Dashboard

I've written a little about PHP before, because I think it's a great utility language for writing quick things you need to do. Plus, it allows you to use a web browser as your interface, and everyone has a web browser. That makes it very convenient for my family, because I can make simple web interfaces for the various things I normally have to do from the command line. more>>

Retro United Ltd.'s Write!

Even when you're sequestered in a monastery with nothing to do but write, you still need a tool to record your thoughts. more>>

Wibu-Systems CmASIC

Wibu-Systems describes the new generation of its CmASIC module as "the answer to the security-by-design needs of modern embedded computing technology leaders:. CmASIC is a module that Intelligent Device Manufacturers (IDMs) can directly embed into their boards to provide out-of-the box security and entitlement management. more>>

Passeport pour le CES 2018 : comment s'y préparer et pourquoi anticiper l'industrialisation ? - Paris Le 12 juillet 2017

Avec la participation des « Douanes », de l'INPI et en partenariat avec BUSINESS France, CAP'TRONIC vous propose de participer à une demi-journée dédiée au CES 2018. La première partie sera consacrée au retour de l'édition du CES 2017 et de ses points marquants. Et la deuxième partie sera essentiellement concentrée sur l'édition 2018.

Au cours de cet événement, les participants pourront partager avec les start-up présentes à l'édition 2017 du Consumer Electronic Show et échanger en particulier avec les acteurs de l'aide publique afin de préparer au mieux la présentation de leurs produits pour l'édition 2018.

Cette année une attention particulière sera portée aux problématiques liées à l'industrialisation en essayant de répondre à la question suivante : « comment répondre dans les temps et sans décevoir ses futurs clients, investisseurs, … ? ».

Programme :

- 09h00-09h30 : Accueil

- 09h30-09h50 : Le pavillon France au CES 2017 et l'édition 2018 : retour d'expérience
Business France

- 09h50-10h00 : Questions/réponses

- 10h00-10h15 : Comment développer sa stratégie douanière post-CES
Douanes Françaises

- 10h15-10h20 : Questions/réponses

- 10h20-10h30 : Comment préparer la protection industrielle
INPI

- 10h35-10h40 : Questions/réponses

- 10h40-11h00 : Les tendances technologiques vues au CES2017 dans l'IoT
EDF

- 11h00-11h20 : Pause

- 11h20-11h30 : Le Design et l'ergonomie : bonnes pratiques
- 11h30- 12h30 : L'industrialisation d'un IoT : bonnes pratiques

  • Le développement du firmware et son industrialisation (15mn)
  • La compréhension d'un outil productif : descriptions des étapes (15mn)
  • Les bonnes pratiques à appliquer dès la conception pour maitriser les coûts d'industrialisation : exemples et retour d'expérience (15mn)
  • Les aspects cybersécurités : pourquoi et comment les considérer dès la conception (15mn)

- 12h30-13h00 : Partage d'expériences autour de start-Up et PME ayant participées au CES
Modérateur : Business France

- 13h00-13h10 : Conclusions

- 13h10 : Pause déjeunatoire

Lieu de l'événement :

BUSINESS FRANCE
77 bd Saint-Jacques
75998 Paris cedex 14
Transport en commun : RERB/M4/M6 - Station Denfert Rochereau

Contact :

Christophe BRICOUT - 09 52 73 77 88 - bricout@captronic.fr

Inscription gratuite mais obligatoire en remplissant le formulaire ci-dessous

Inscription jusqu'au 2 juillet 2017
Places limitées : 80 personnes

Introducing lavabo, board remote control software

In two previous blog posts, we presented the hardware and software architecture of the automated testing platform we have created to test the Linux kernel on a large number of embedded platforms.

The primary use case for this infrastructure was to participate to the KernelCI.org testing effort, which tests the Linux kernel every day on many hardware platforms.

However, since our embedded boards are now fully controlled by LAVA, we wondered if we could not only use our lab for KernelCI.org, but also provide remote control of our boards to Free Electrons engineers so that they can access development boards from anywhere. lavabo was born from this idea and its goal is to allow full remote control of the boards as it is done in LAVA: interface with the serial port, control the power supply and provide files to the board using TFTP.

The advantages of being able to access the boards remotely are obvious: allowing engineers working from home to work on their hardware platforms, avoid moving the boards out of the lab and back into the lab each time an engineer wants to do a test, etc.

User’s perspective

From a user’s point of view, lavabo is used through the eponymous command lavabo, which allows to:

  • List the boards and their status
    $ lavabo list
  • Reserve a board for lavabo usage, so that it is no longer used for CI jobs
    $ lavabo reserve am335x-boneblack_01
  • Upload a kernel image and Device Tree blob so that it can be accessed by the board through TFTP
    $ lavabo upload zImage am335x-boneblack.dtb
  • Connect to the serial port of the board
    $ lavabo serial am335x-boneblack_01
  • Reset the power of the board
    $ lavabo reset am335x-boneblack_01
  • Power off the board
    $ lavabo power-off am335x-boneblack_01
  • Release the board, so that it can once again be used for CI jobs
    $ lavabo release am335x-boneblack_01

Overall architecture and implementation

The following diagram summarizes the overall architecture of lavabo (components in green) and how it connects with existing components of the LAVA architecture.

lavabo reuses LAVA tools and configuration files

lavabo reuses LAVA tools and configuration files

A client-server software

lavabo follows the classical client-server model: the lavabo client is installed on the machines of users, while the lavabo server is hosted on the same machine as LAVA. The server-side of lavabo is responsible for calling the right tools directly on the server machine and making the right calls to LAVA’s API. It controls the boards and interacts with the LAVA instance to reserve and release a board.

On the server machine, a specific Unix user is configured, through its .ssh/authorized_keys to automatically spawn the lavabo server program when someone connects. The lavabo client and server interact directly using their stdin/stdout, by exchanging JSON dictionaries. This interaction model has been inspired from the Attic backup program. Therefore, the lavabo server is not a background process that runs permanently like traditional daemons.

Handling serial connection

Exchanging JSON over SSH works fine to allow the lavabo client to provide instructions to the lavabo server, but it doesn’t work well to provide access to the serial ports of the boards. However, ser2net is already used by LAVA and provides a local telnet port for each serial port. lavabo simply uses SSH port-forwarding to redirect those telnet ports to local ports on the user’s machine.

Different ways to connect to the serial

Different ways to connect to the serial

Interaction with LAVA

To use a board outside of LAVA, we have to interact with LAVA to tell him the board cannot be used anymore. We therefore had to work with LAVA developers to add endpoints for putting online (release) and for putting offline (reserve) boards and an endpoint to get the current status of a board (busy, idle or offline) in LAVA’s API.

These additions to the LAVA API are used by the lavabo server to make reserve and release boards, so that there is no conflict between the CI related jobs (such as the ones submitted by KernelCI.org) and the direct use of boards for remote development.

Interaction with the boards

Now that we know how the client and the server interact and also how the server communicates with LAVA, we need a way to know which boards are in the lab, on which port the serial connection of a board is exposed and what are the commands to control the board’s power supply. All this configuration has already been given to LAVA, so lavabo server simply reads the LAVA configuration files.

The last requirement is to provide files to the board, such as kernel images, Device Tree blobs, etc. Indeed, from a network point of view, the boards are located in a different subnet not routed directly to the users machines. LAVA already has a directory accessible through TFTP from the boards which is one of the mechanisms used to serve files to boards. Therefore, the easiest and most obvious way is to send files from the client to the server and move the files to this directory, which we implemented using SFTP.

User authentication

Since the serial port cannot be shared among several sessions, it is essential to guarantee a board can only be used by one engineer at a time. In order to identify users, we have one SSH key per user in the .ssh/authorized_keys file on the server, each associated to a call to the lavabo-server program with a different username.

This allows us to identify who is reserving/releasing the boards, and make sure that serial port access, or requests to power off or reset the boards are done by the user having reserved the board.

For TFTP, the lavabo upload command automatically uploads files into a per-user sub-directory of the TFTP server. Therefore, when a file called zImage is uploaded, the board will access it over TFTP by downloading user/zImage.

Availability and installation

As you could guess from our love for FOSS, lavabo is released under the GNU GPLv2 license in a GitHub repository. Extensive documentation is available if you’re interested in installing lavabo. Of course, patches are welcome!

Adding IoT Flare to a Hot Springs and Spa Business

As the folks at Bozeman Hot Springs usher their hot springs and spa into the 21st century with new technology and pools, they are thinking about new ways to delight their customers and stay top of mind. One recurring request, no doubt from the avid skiing community, is the ability to read current pool temperatures online, in the same way ski resorts publish current snow conditions. more>>

Rencontre Cybersécurité & Objets Connectés - Amiens (60) Le 31 mai 2017

Prise de contrôle de véhicules connectés, de réseaux d'objets zombies, piratage d'équipements domotiques, on constate une explosion du nombre d'attaques d'objets connectés, de nature variée. Spectaculaires, ces démonstrations réalisées à distance ou directement sur le composant par de véritables pirates informatiques, montrent à quel point les objets intelligents détournés de leur mission première peuvent devenir dangereux.

Pirater un objet connecté en tant que tel peut ne pas avoir de sens. Par contre, le pirater pour accéder à un réseau se révèle bien plus intéressant. Ces objets sont des cibles de hautes valeurs qui manipulent des données parfois sensibles et dont les capteurs peuvent être détournés. Ils sont souvent peu supervisés et ils proposent peu ou pas de mises à jour ou de moyens de détection des attaques.

Parallèlement pour ceux qui se lancent dans l'internet des objets, il faut aller au plus vite pour inonder le marché et prendre en compte les problématiques de sécurité coûte cher et ralenti le time to market. D'autant qu'il n'est pas facile de sécuriser les objets contraints en puissance de calcul et de batterie.

Les entreprises doivent prendre conscience de la menace pour pouvoir anticiper.

C'est pourquoi l'ARI Picardie organise une matinée d'information :

Cybersécurité & objets connectés

le mercredi 31 Mai de 9h00 à 12h00

ARI Picardie – 41 avenue Paul Claudel à DURY

Avec l'intervention de l'ANSSI (l'Agence nationale de la sécurité des systèmes d'information), qui présentera l'état de la menace en France et la politique de sensibilisation auprès des entreprises pour contourner les attaques. Les centres techniques et industriels se lancent également dans des initiatives en développant des technologies pour y pallier, comme le CITC (centre d'innovation des technologies sans contacts et cluster de l'Internet des objets) qui présentera sa plateforme SCOP de sécurité & Internet des objets, développée avec Thales.

Programme :

- 9h00 : Accueil des participants - Introduction et présentation des organisateurs

- 9h30 : Piratage… pourquoi moi ?
Comment peut-on devenir une victime de cybermalveillance, présentation des typologies de pirates et d'attaques, comment s'en protéger ?
Olivier SIEROCKI – Référent Hauts-de-France de l'Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI)

- 10h15 : La sécurité des objets connectés – facteurs de risques et recommandations
Présentation du CITC (centre d'innovation des technologies sans contact et cluster de l'Internet des objets) et de leur plateforme de sécurité & internet des objets (SCOP) créée avec Thales afin d'analyser les risques et vulnérabilités des systèmes et services liés à l'IOT.
Mohamed-Salah BOUASSIDA – Ingénieur R&S - CITC

- 10h45 : Cas pratique & Témoignage
Témoignage d'une startup du Numérique

- 11h15 : Questions/réponses

- 11h45 : Cocktail déjeunatoire

Pour vous inscrire : cliquez-ici

Contact :

Clara REVEL - ARI Picardie
Tél : 03 22 97 95 63

OpenStack Gets...Easier

Although the promise of OpenStack and private cloud is huge, and still largely in front of us, the one challenge we've heard from people wanting to try it is "It's a bear!" Its reputation, whether or not well-deserved, is one of being a real challenge for even skilled IT people to install and deploy. more>>

L'Open Source pour le développement logiciel des objets connectés : une solution compétitive - Toulouse (31) Le 28 juin 2017

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 commerciales : l'objectif étant de rester compétitif.

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 l'IoT.

L'open source, en soi, ne rend pas un projet plus innovant. Mais c'est son utilisation qui libère les développeurs des tâches de création de logiciels propriétaires : c'est une question d'efficience de développement. Ainsi, les concepteurs et les développeurs focalisent leurs ressources sur le développement du logiciel d'application : c'est cela qui fait la différence sur le marché, offrant davantage de temps et de moyens pour rendre les objets plus simples, plus attractifs et plus performants.

PROGRAMME

09h45 : Accueil
10h00 : Introduction par les organisateurs

10h15 – 11h00 (Jean-Paul CRENN, VUCA Stratégie) : 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'Analytiques des Objets.
• 11h00 – 11h30 (Maître Gérard HAAS) : Quels sont les enjeux juridiques des Objets Intelligents Connectés ?
• Sécurité et protection des données
• Le droit de se déconnecter
• La conclusion de contrats par ou via des objets connectés
• Quelle responsabilité en cas de défaillance de l'objet connecté ?
• Les risques sanitaires

11h30 – 12h00 (Pierre FICHEUX, SMILE) : Panorama des licences Open Source

12h00-12h30 : Table ronde sur les enjeux stratégiques et juridiques de l'IoT

12h30 - 13h30 - Buffet sur place – Démonstrations

13h30 - 14h30 (Pierre FICHEUX, SMILE-ECS) : Yocto, outil libre pour le capteur intelligent ?
• Yocto/OpenEmbedded est le système de "build" le plus célèbre dans le monde de Linux embarqué et selon l'étude "IoT developper survey" (2016), Linux est le système d'exploitation le plus utilisé pour les objets connectés "intelligents" (plus de 70% des cas). Durant la conférence nous décrirons comment construire un capteur basé sur une Raspberry Pi zero en utilisant quelques fonctionnalités avancées de Yocto (ajout de layer 'meta-iot', dérivation, mise à jour par SMART). La conférence sera axée sur une démonstration permettant de visualiser des données transmises par MQTT sur une application mobile Android.

14h30 – 15h (Florent BERANGER, SMILE-XDATA) : Présentation de la plateforme Quickstart IoT
• Plateforme destinée à faciliter le prototypage, valider les modèles de services valoriser les données.

15h00 - 15h45 (Florent BERANGER, SMILE-XDATA) : Explorez toute la valeur de vos données sur la plateforme IoT Open Source.

15h45 - 16h PAUSE

16h00 - 17h00 : Retours d'expérience : NEOCAMPUS, DIGITAM, SMILE…

INFORMATIONS PRATIQUES

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

Lieu : LAAS-CNRS - 7 av du Colonel Roche - TOULOUSE

Date : Mercredi 28 Juin 2017 de 10h00 à 17h00

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

Contact : Richard SALVETAT au 06 86 40 94 52 ou par email : salvetat@captronic.fr
Inscription obligatoire

Teaching Your Computer

As I have written in my last two articles (Machine Learning Everywhere and Preparing Data for Machine Learning), machine learning is influencing our lives in numerous ways. more>>

Make Your Containers Transparent with Puppet's Lumogon

As development and IT shops look for ways to more quickly test and deploy software or scale out their environments, containers have become a go-to solution. With Docker and similar tools, you can spin up dev and production containerized platforms that are fast, lightweight and consistent. more>>

Automatic Slack Notifications

Slack is an incredible communication tool for groups of any size (see my recent piece on it). At the company I work for during the day, Slack has become more widely used than email or instant messaging. It truly has become the hub of company communication. more>>

Drivers DMA dans Linux

I – Introduction

I.1 Pré-requis

Nous partons du fait que le lecteur connaît les bases des drivers linux. Donc il sait créer un « node » sur /dev , /sys et /proc, initialiser un module et le terminer proprement. Il connaît les licences et la gestion des paramètres d’un module.

I.2 Les périphériques matériels

I.2.a Quelques généralités

Quand on est peu impliqué dans le développement d’un produit matériel, il est difficile de concevoir un driver pour un périphérique spécifique, et généralement on débute sur le développement d’un driver pour un périphérique USB.

Ceux-ci sont hélas enfouis sous de nombreuses couches de protocoles car le driver primaire est celui du PHY du chipset USB de notre carte.

Un SoC est composé d’un certain nombre de périphériques comme le chipset USB, mais aussi le bus SPI, le bus I2C, les GPIO, le PHY ethernet, ou encore le DSP audio et vidéo.

Tous ces périphériques ont en commun un mode de fonctionnement par registres et interruptions. En général un registre de FIFO permet de lire les données reçues sur le bus, un autre d’écrire de nouvelles données à émettre et d’autres registres permettent de configurer tout cela pour que la réception et l’émission fonctionnent.

Une première amélioration au fonctionnement des périphériques a été l’ajout des interruptions. Il est en effet possible de configurer (via les précédents registres) le périphérique pour qu’il émette un signal électrique sur un autre périphérique, le « contrôleur d’interruption » (souvent abrégé INTC). Celui-ci manipule aussi des registres pour être configuré et dialoguer avec le CPU. Il est ensuite capable de générer une interruption matérielle, qui est cette fois-ci reconnue par le CPU.

Ces signaux électriques ont le grand intérêt de permettre au CPU de savoir quand de nouvelles valeurs sont utiles dans les registres d’un périphérique. Ainsi il n’est pas nécessaire de les scruter en permanence et donc de consommer de l’énergie et des ressources.

Bien sûr comme dans tout dialogue, il faut parler la même langue, et là nous sommes encore à la chute de Babylone, personne ne (veut) parle la même langue. Alors, comme nous sommes des développeurs, nous travaillons à faire la traduction. Pour nous aider, nous utilisons les dictionnaires que sont le « datasheet » des périphériques.

 

La datasheet du SoC Sitara5718 de chez Ti à la date d’avril 2017: http://www.ti.com/lit/ug/spruhz7e/spruhz7e.pdf

I.2.b La gestion de la mémoire

Le noyau Linux fonctionne avec le support d’une MMU (Memory Management Unit) qui permet de cacher l’utilisation réelle de la mémoire physique derrière une mémoire virtuelle. Ce principe permet d’avoir accès à une zone mémoire virtuelle de grande taille alors que physiquement ce sont des blocs de mémoire, éparses. Pourtant un périphérique ne connaît pas la MMU et il ne peux utiliser que des adresses physiques.

Allocation mémoire

Le noyau Linux permet d’allouer une zone mémoire à l’usage du pilote par l’intermédiaire de la MMU. Ce principe permet d’allouer des zones mémoires de taille importante que le pilote pourra utiliser à son gré pour stocker des informations.

Pour le dialogue entre un périphérique et son pilote, le noyau permet aussi d’allouer une zone mémoire qui sera d’un seul tenant dans l’espace physique de la mémoire. On dit qu’elle est «contiguë». Celle-ci est de plus en plus difficile à allouer au fur et à mesure du fonctionnement du système.

L’exemple suivant présente une première allocation d’une zone mémoire qui est faite par la MMU, et une seconde qui sera contiguë.

array = vmalloc(array_size * sizeof (struct spi_slave_rx_dma_buf));
array[0].buf = kcalloc(array_size , buf_size, GFP_KERNEL);
for (i = 0; i < array_size; ++i) {
    array[i].buf = array[0].buf + i * dma_buf_size;
}

La première peut être éclatée à plusieurs endroits de la mémoire physique, alors que la deuxième sera toujours d’un seul tenant.

 

L’infrastructure « scatterlist »

Lors d’un transfert de données avec un périphérique, il est souvent utile d’avoir plusieurs zones mémoires accessibles à celui-ci pour lui permettre d’en utiliser une alors que son pilote est en train d’en préparer une autre. Sur un contrôleur vidéo, c’est ce que l’on appelle un « double (ou triple) frame buffer ».

L’exemple précédent est une présentation possible de ce qu’on appelle un « Scatter/Gather », une liste de buffers chaînés qui pourront être utilisés un à un par le périphérique et son pilote.

Pour simplifier et uniformiser les interfaces, le noyau Linux propose une infrastructure appelée « scatterlist » qui est définie dans le fichier « include/linux/scatterlist.h ».

struct scatterlist *rx_sg;
unsigned char *buf ;
rx_sg = vmalloc(array_size * sizeof(struct scatterlist));
buf = kcalloc(array_size , buf_size, GFP_DMA);
sg_init_table(rx_sg, array_size);
for (i = 0; i < array_size; i++) {
    sg_set_buf(&rx_sg[i], buf + i * buf_size, buf_size);
}

I.2.c l’accès aux registres

Les registres de périphérique sont des adresses mappées physiquement entre le bus de mémoire du CPU et les périphériques. Il est donc nécessaire de connaître ces adresses pour y lire et modifier des valeurs.

C’est aujourd’hui sous Linux, le DTB (device tree) qui nous indique ces adresses pour chaque périphérique. Il est donc nécessaire lors de l’initialisation de faire une demande de ces valeurs :

mcspi3: spi@480b8000 {
    compatible = "ti,omap4-mcspi";
    reg = <0x480b8000 0x200>;
    interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
    ti,hwmods = "mcspi3";
    dmas = <&sdma_xbar 15>, <&sdma_xbar 16>;
    dma-names = "tx0", "rx0";
    status = "okay";
    ti,spi-num-cs = <1>;
    pinctrl-names = "default";
    pinctrl-0 = <&mcspi3_pins>;
};

DTS pour le bus SPI 3 du Sitara 5718

static const u32 mcspi_base[MCSPI_NB_MOD] = { 0x48098000, 0x4809A000, 0x480B8000, 0x480BA000 };
static int mcspi_probe(struct platform_device *pdev)
{
    struct device_node *node = pdev->dev.of_node;
    u32 node_reg;
...
    match = of_match_device(mcspi_of_match, &pdev->dev);
    of_property_read_u32_index(node, "reg", 0, &node_reg);
    for (i=0; i<MCSPI_NB_MOD; i++) {
        if( mcspi_base[i] == node_reg )
            mcspi->bus_num = i+1;
    }
    of_property_read_u32(node, "ti,spi-num-cs", &num_cs);
    mcspi->num_chipselect = num_cs;
...
}

accès au DTB depuis la détection du device


L’utilisation de la MMU cache l’accès aux adresses physique. Il est donc nécessaire de dire à la MMU que l’on veut avoir accès directement aux adresses des registres du périphérique, ce que nous appelons un « remappage des entrées/sorties ».

static int mcspi_probe(struct platform_device *pdev)
{
    struct resource *res;
...
    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    mcspi->phys = res->start;
    mcspi->base = devm_ioremap_resource(&pdev->dev, res);
    infomsg("MCSPI%i controller's attributes: @phys=0x%08x, @virt=0x%08x\n", mcspi->bus_num, (u32)mcspi->phys, (u32)mcspi->base);
...
}

“remappage” des registres du bus SPI


Une fois cette opération faite, il est facile d’utiliser cette adresse virtuelle pour lire et écrire dans le registre physique du périphérique.

static void mcspi_configure_slave(struct mcspi_ctx *mcspi)
{
    u32 chconf0, modulctrl;
    u32 * p_chconf0 = &(mcspi->base + 0x12C + 0x14 * 0);
    u32 * p_modulctrl = &(mcspi->base + 0x128);
    u32 * p_sysconfig = &(mcspi->base + 0x110);
    u32 * p_sysstatus = &(mcspi->base + 0x114);

    sysconfig = readl(p_sysconfig);
    sysconfig |= MCSPI_SYSCONFIG_SOFTRESET;
    writel(sysconfig, p_sysconfig);
    while (!(MCSPI_SYSSTATUS_RESETDONE & readl(p_sysstatus)))
        ;

    /* System config: no wake-up capability (always running), ignore idle request, maintain all clocks */
    sysconfig &= ~(MCSPI_SYSCONFIG_ENAWAKEUP | MCSPI_SYSCONFIG_SOFTRESET | MCSPI_SYSCONFIG_AUTOIDLE | MCSPI_SYSCONFIG_SIDLEMODE_MASK);
    sysconfig |= (MCSPI_SYSCONFIG_IGNORE_IDLEREQ | MCSPI_SYSCONFIG_ALL_CLOCKS_MAINT);
    writel(sysconfig, &regs->sysconfig);
    chconf0 = readl(p_chconf0);
    /* RAZ fields then configure: Rx-only, 16-bit words, enable turbo mode, enable usage of FIFO in Rx */
    chconf0 &= ~(MCSPI_CHCONF_WL_MASK | MCSPI_CHCONF_TRM_MASK | MCSPI_CHCONF_DPE0 | MCSPI_CHCONF_DPE1 );
    chconf0 |= (MCSPI_CHCONF_TRM_RX_ONLY | MCSPI_CHCONF_SET_WORDLEN(16) | MCSPI_CHCONF_DPE0 | MCSPI_CHCONF_DPE1 | MCSPI_CHCONF_TURBO | MCSPI_CHCONF_FFER | MCSPI_CHCONF_IS);

    writel(chconf0, p_chconf0);
    /* Set slave mode and use PIN34 as Chip Select */
    modulctrl = readl(p_modulctrl);
    modulctrl &= ~MCSPI_MODULCTRL_PIN34;
    modulctrl |= MCSPI_MODULCTRL_MS;
    writel(modulctrl, p_modulctrl);
    /* Additional config: SPIEN active low, SPICLK inactive low, data latch on even SPICLK */
    chconf0 &= ~MCSPI_CHCONF_POL;
    chconf0 |= (MCSPI_CHCONF_EPOL | MCSPI_CHCONF_PHA);
    writel(chconf0, p_chconf0);
}

Lire et écrire sur les registres d’un périphérique SPI du Sitara 5718

I.2.d La gestion des interruptions

Un périphérique est configurable pour générer des interruptions sur certains événements comme l’arrivée de données dans le registre de réception du périphérique.

La définition de l’« IRQ » est faite par le « device tree ». Lors d’une interruption, le CPU ARM appelle un vecteur d’exception qui permet au noyau de se mettre dans un contexte particulier. Dans ce contexte, une fonction du noyau pourra réaliser un traitement court où toute autre interruption sera interdite. En général, cette fonctionnement déclenchera l’exécution d’une « tasklet » (« SofTIRQ ») dans le contexte normal du noyau.

static irqreturn_t omap_dma_irq(int irq, void *irqparam)
{
    return IRQ_HANDLED;
}

static int omap_dma_probe(struct platform_device *pdev)
{
    int irq;
    void *irqparam;
...
    irq = platform_get_irq(pdev, 1);
    if (irq <= 0) {
        dev_info(&pdev->dev, "failed to get L1 IRQ: %d\n", irq);
    } else {
        devm_request_irq(&pdev->dev, irq, omap_dma_irq,
        IRQF_SHARED, "omap-dma-engine", irqparam);
    }
...
}

II – Le DMA, un périphérique pas tout à fait comme les autres

II.1 Présentation

Cette gestion des périphériques par registres et interruption pose le problème des grandes quantités de données à transférer. En effet les FIFO des périphériques sont souvent de taille réduite, et le CPU doit faire des copies entre celles-ci et la mémoire volatile pour envoyer ou recevoir des données. Si on prend un bus SPI à 16 MHz avec une FIFO de 32 octets en réception le CPU devrait remplir la FIFO toutes les 1.625 us, ce qui, on s’en doute bien, est impossible.

Le DMA ou plutôt le contrôleur de « Direct Memory Access » est un composant particulier capable de transférer de grande quantité de données depuis une zone mémoire vers une autre, sans que le CPU ne soit sollicité. Et il peut donc faire le lien entre la FIFO d’un bus classique, comme le SPI, et la mémoire volatile du SoC.

Pour pouvoir être utilisé avec plusieurs périphériques et/ou en full-duplex, le contrôleur de DMA offre un certain nombre de canaux. Chacun d’eux est configurable indépendamment, comme autant de périphériques. Bien sûr, le CPU doit connaître l’avancement de ces transferts et donc le DMA est capable de l’informer directement par l’intermédiaire de registres et d’interruptions comme tous les périphériques.

Un canal DMA doit être vu comme un périphérique quelconque mais qui fonctionne en interne.

II.2 Les fonctionnements

II.2.a Par « burst »

Le canal DMA est configuré pour recevoir ou émettre une certaine quantité de données entre une adresse de la mémoire volatile et les FIFO du périphérique. Une fois le transfert terminé le contrôleur lève une interruption pour avertir le CPU puis attend de nouveaux ordres.

Ce mode de fonctionnement permet le transfert dans les deux sens, selon des données attendues ou envoyées depuis le « userspace ». Il est ainsi possible de faire un transfert dans un sens puis dans l’autre selon les besoins, tout en n’utilisant qu’un seul canal.

II.2.b Par « cycle »

Cette fois-ci, le canal DMA permet d’utiliser un « Scatter/Gather » de manière tournante. Quand le canal DMA a fini de remplir une zone mémoire, il la libère pour que le CPU y ait accès et passe à la suivante pour continuer son transfert.

Il est ainsi possible de ne jamais arrêter le transfert, l’interruption vers le CPU ne bloquant pas le fonctionnement du contrôleur. En revanche, il est impossible d’utiliser le canal dans les 2 sens en même temps.

II.2.c Par FIFO

Ce fonctionnement est juste mentionné pour indiquer que le DMA peut être configuré pour utiliser un canal entre 2 périphériques différents sans utilisation du CPU.

II.2.d Par copie

Et celui-ci est mentionné car il permet de faire des manipulations sur de grandes quantités de données. Il est ainsi possible d’utiliser un canal DMA pour faire le retournement d’une image ou encore l’application d’un filtre sur un flux.

II.3 Le driver DMA

II.3.a La mémoire

L’allocation de la mémoire doit se faire dans une région spécifique. L’allocation par « kmalloc » doit prendre le flag « GFP_DMA » comme argument, ou alors il est possible d’utiliser la fonction « dma_alloc_coherent ».

La différence entre ces deux fonctions est la gestion du cache. On se doute bien que le DMA ne peut pas utiliser la mémoire cache du CPU et donc celui-ci ne doit pas intervenir dans le transfert.

« dma_alloc_coherent » permet de ne pas activer le cache sur la zone mémoire. Alors que l’utilisation de « kmalloc » exige de forcer la copie du cache en mémoire avant de donner l’accès de la mémoire au DMA.

La seconde utilisation peut permettre de gagner du temps lors du transfert de données entre les différents processus mais pas dans le fonctionnement du pilote.

rx_sg = vmalloc(array_size * sizeof(struct scatterlist));
buf = kcalloc(array_size , buf_size, GFP_DMA);
sg_init_table(rx_sg, array_size);
for (i = 0; i < array_size; i++)
{
    sg_set_buf(&rx_sg[i], buf + i * buf_size, buf_size);
}
dma_map_sg(mcspi->dev, rx_sg, array_size,DMA_FROM_DEVICE);
...
dma_sync_sg_for_cpu(mcspi->dev, rx_sg, array_size,DMA_FROM_DEVICE);
copy_to_user(user_data, buf + current_buf * buf_size, buf_size) ;
current_buf++;
current_buf %= array_size;
dma_sync_sg_for_device(mcspi->dev, rx_sg, array_size,DMA_FROM_DEVICE);

II.3.b La partie physique

Chaque contrôleur possède son pilote. Son fonctionnement est distinct des autres et certaines fonctionnalités peuvent être absentes.

Les sources sont localisées dans le répertoire « drivers/dma » du noyau.

Cette partie du driver gère la configuration des registres et la réception des interruptions matérielles venant du contrôleur de DMA.

Le traitement des interruptions étant spécifique à l’utilisation du canal DMA, la fonction d’IRQ est très simple pour diminuer le temps de réponse dans le contexte d’interruption, et laisse le traitement à une « tasklet » (SoftIRQ) qui est instanciée lors de la configuration du canal.

Chaque driver physique doit remplir une structure « struct dma_device » qui définit les actions possibles par le contrôleur. Cette structure propose une douzaine de manières pour faire un transfert DMA, chacune implémentée dans une fonction. Les drivers peuvent implémenter tout ou partie de ces fonctions puis ils décrivent leurs capacités.

struct dma_async_tx_descriptor *(*device_prep_dma_memcpy)(
    struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
    size_t len, unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_dma_xor)(
    struct dma_chan *chan, dma_addr_t dst, dma_addr_t *src,
    unsigned int src_cnt, size_t len, unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_dma_xor_val)(
    struct dma_chan *chan, dma_addr_t *src, unsigned int src_cnt,
    size_t len, enum sum_check_flags *result, unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_dma_pq)(
    struct dma_chan *chan, dma_addr_t *dst, dma_addr_t *src,
    unsigned int src_cnt, const unsigned char *scf,
    size_t len, unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_dma_pq_val)(
    struct dma_chan *chan, dma_addr_t *pq, dma_addr_t *src,
    unsigned int src_cnt, const unsigned char *scf, size_t len,
    enum sum_check_flags *pqres, unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_dma_memset)(
    struct dma_chan *chan, dma_addr_t dest, int value, size_t len,
    unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_dma_memset_sg)(
    struct dma_chan *chan, struct scatterlist *sg,
    unsigned int nents, int value, unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
    struct dma_chan *chan, unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_dma_sg)(
    struct dma_chan *chan,
    struct scatterlist *dst_sg, unsigned int dst_nents,
    struct scatterlist *src_sg, unsigned int src_nents,
    unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
    struct dma_chan *chan, struct scatterlist *sgl,
    unsigned int sg_len, enum dma_transfer_direction direction,
    unsigned long flags, void *context);

struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
    struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
    size_t period_len, enum dma_transfer_direction direction,
    unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_interleaved_dma)(
    struct dma_chan *chan, struct dma_interleaved_template *xt,
    unsigned long flags);

struct dma_async_tx_descriptor *(*device_prep_dma_imm_data)(
    struct dma_chan *chan, dma_addr_t dst, u64 data,
    unsigned long flags);

Sur toutes ces fonctions nous allons nous arrêter plus spécifiquement sur 2 d’entre elles :

  • device_prep_dma_cyclic
  • device_prep_slave_sg

Ces deux fonctions sont implémentées pour le contrôleur DMA des SoC de la famille Sitara et Omap dont le code se trouve dans le fichier « omap_dma.c ». Elles sont surtout utilisées pour faire de la copie de données entre un périphérique et la mémoire volatile.

device_prep_slave_sg

Le terme « sg » qui termine le nom, est l’acronyme de Scatter/Gather. Le principe de ce mode est de fournir une liste de buffers et d’attendre que tous ceux-ci aient été utilisés. Il est donc nécessaire que l’utilisateur du canal redemande un transfert, une fois terminé, depuis le driver du périphérique. Cela peut être depuis les fonctions entrée/sortie de l’interface utilisateur ou depuis une « tasklet » connectée à l’interruption matérielle.

Cette solution permet beaucoup de souplesse mais laisse une grande incertitude sur le moment où le contrôleur DMA sera de nouveau prêt pour continuer le transfert. Or dans le cas de la réception de données sur un bus rapide, il est possible de rater des données.

device_prep_dma_cyclic

Cette fonction va utiliser un seul et unique buffer tournant, une fois rempli, le contrôleur vient réécrire dessus les nouvelles données. Le contrôleur de DMA peut générer une interruption matérielle à plusieurs moments du remplissage de celui-ci et ainsi permettre l’utilisation (lecture ou écriture) des données en invoquant une « tasklet ».

Cette solution permet de ne pas couper le transfert de données, mais il faut tout de même faire attention à la cohérence des données. En effet le contenu de la mémoire volatile peut être affecté par l’utilisation de zones tampons ou de la MMU.

II.3.c L’infrastructure « dmaengine »

Le driver de DMA est rarement utilisé directement depuis le contexte utilisateur, et donc il doit fournir une interface identique quelque soit le contrôleur sous-jacent. C’est ce qu’offre le « dmaengine » qui est décrit dans le fichier « include/linux/dmaengine.h ».

Il permet :

  • de réserver l’utilisation d’un canal sur un contrôleur DMA compatible avec le périphérique utilisé :
struct dma_chan *dma_rx;
dma_cap_mask_t mask;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
dma_cap_set(DMA_CYCLIC, mask);
dma_rx = dma_request_slave_channel_compat(mask, omap_dma_filter_fn, &sig, dev, "mydmarx");

 

  • de configurer la source et/ou la destination des données :
struct dma_slave_config cfg;
unsigned long dummy_flags;
memset(&cfg, 0, sizeof(cfg));
cfg.src_addr = (dma_addr_t)&((struct mcspi_regs *)mcspi->phys)->chx[0].rx;
cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
cfg.src_maxburst = mcspi->fifo_depth >> 1;
dmaengine_slave_config(dma_rx, &cfg);
rx_sg = kcalloc(array_size, sizeof(struct scatterlist), GFP_KERNEL);
sg_init_table(rx_sg, array_size);
...
dma_map_sg(mcspi->dev, rx_sg,dma_buf_array_size, DMA_FROM_DEVICE);
int len = sg_dma_len(&rx_sg[0]) ;
unsigned char *address = sg_dma_address(&rx_sg[0]) ;

 

  • de définir le type de transfert :
struct dma_async_tx_descriptor *trans;
trans = dmaengine_prep_dma_cyclic(dma_rx, sg_dma_address(&rx_sg[0]),
    sg_dma_len(&rx_sg[0]) * dma_buf_array_size, dma_buf_size,
    DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);

ou

trans = dmaengine_prep_slave_sg(dma_rx,
    &rx_sg, dma_buf_array_size,
    DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);

 

  • d’installer une « callback » sur la « tasklet » du DMA :
struct dma_async_tx_descriptor *trans;
...
trans->callback = callback;
trans->callback_param = callback_param;
rx_cookie = dmaengine_submit(trans);

 

  • de mettre l’infrastructure en attente de données sur le périphérique :
dma_async_issue_pending(dma_rx);

III – Conclusion

L’écriture d’un pilote n’est pas simple, l’utilisation du DMA le complexifie encore et l’utilisation du mode cyclique de ce dernier est un challenge de plus. Mais c’est à ce prix qu’il est possible d’optimiser l’utilisation des ressources de nos systèmes.

Le DMA est vraiment un outil puissant, et peu utilisé en fin de compte. Nous avons parlé de transfert entre un périphérique et la mémoire, mais il permet aussi de faire des manipulations de données. Cette capacité est peu utilisée dans Linux et vous laisse l’opportunité de tester le développement de pilote DMA. Le Sitara5718 offre deux contrôleurs DMA, proposant 32 et 64 canaux. Les possibilités sont immenses si vous utilisez votre imagination.

Cet article donne une grande partie des informations pour avancer dans votre projet, mais chaque plate-forme, chaque périphérique a son mode de fonctionnement. Et même si les développeurs de Linux veulent uniformiser les API, il vous faudra sûrement commencer par lire la documentation technique des composants utilisés et composer avec les différentes possibilités. Il est difficile de trouver le bon exemple qui sera le plus proche de votre problème.

La préface du hors-série programmation réseau !

« Et puis c’est arrivé… une porte s’est ouverte sur un monde nouveau… j’envoie un signal, il traverse les lignes téléphoniques (…). »

« The Hacker Manifesto », The Mentor, 1986

Depuis que ces lignes ont été écrites, 31 ans se sont écoulés. Et pourtant elles n’ont jamais autant été d’actualité. Le net ne cesse de grandir, de se développer, d’accoucher de nouvelles technologies et de nouvelles façons de faire communiquer différentes entités entre elles. Le SOAP a laissé la place au REST, les réseaux sociaux se diversifient, chaque jour amène son lot de nouveaux services qui offrent chacun leur API.

Dans cet écosystème foisonnant, nous, développeuses et développeurs Python, sommes plus que chanceux. En effet, la mise en place de communications par échange d’informations passant par des connexions réseaux est au cœur du Python. Que ce soit grâce aux modules fournis par la bibliothèque standard ou les multiples bibliothèques disponibles, tout est fait pour que nous ayons tous les outils pour pouvoir travailler efficacement.

« Nous explorons… (…). Nous recherchons la connaissance… (…). ». Le magazine que vous tenez entre les mains a pour but de vous faire découvrir ou approfondir les différents moyens de mettre en places des communications réseaux avec notre langage préféré :

Que vous vouliez en apprendre plus sur les concepts de base fondamentaux de la communication réseau bas niveau, pour mettre en place des applications ayant à la fois une interface graphique et des communications réseaux, consommer des API web REST diverses ou pour travailler directement sur les paquets réseaux, la première partie de ce hors-série est faite pour vous.

Si vous avez plutôt envie de suivre la mouvance des chats-bots, que ce soit pour se connecter à IRC, Jabber, Slack ou des réseaux sociaux, là aussi, vous allez pouvoir trouver votre bonheur dans les pages qui vous attendent dès que vous aurez fini de lire cette petite préface.

Enfin, si vous voulez mettre en place des serveurs de fichiers ou interagir avec le réel et envoyer des SMS avec l’un de vos Raspberry Pi préférés, alors vous allez adorer la derrière partie de ce hors-série.

Je vais profiter de la poignée de caractères qu’il me reste pour vous souhaiter une bonne lecture et de longues heures d’expérimentation avec Python et les communications réseaux. Faites tout de même attention, ne développez pas le bot de trop, la Singularité n’est pas si loin que ça…

Jean-Michel Armand

Retrouvez GNU/Linux Magazine Hors-série n°90 chez votre marchand de journaux, sur notre boutique ainsi que sur notre plateforme de lecture en ligne Connect

ioSafe Server 5

Until now, says ioSafe, true zero-recovery-point server solutions have been available only to the biggest of companies. However, with the arrival of ioSafe's Server 5, SMEs have access to "the industry's first fire and waterproof server" designed to eliminate data loss and minimize downtime. more>>

L'interopérabilité des systèmes connectés. Impact pour l'écosystème des objets connectés IoT / M2M ! - Talence (33) Le 8 juin 2017

Ce séminaire vous propose un état de l'art sur le sujet, avec en fil rouge l'interopérabilité et les standards industriels et l'impact que cela engendre sur l'IoT / M2M.

Souvent désignés par leurs initiales, le machine to machine (M2M) et l'Internet of Things (IoT) sont deux concepts très proches, souvent source d'innovation dans les services.
Un système IoT/M2M c'est un système complexe : l'objet/le capteur, les réseaux de communication radiofréquence, une passerelle / routeur qui se connecte à Internet sur les systèmes centraux (serveurs cloud) pour offrir du service.

Demain la flexibilité des architectures et des flux de données offrira des interactions entre les objets, au-delà de leurs constructeurs ou des secteurs d'activités, afin d'apporter de nouveaux services plus performants. L'interopérabilité est en marche, les plates-formes de l'Internet des objets (IoT) pour optimiser le « time to market » qui ont vocation à connecter ces appareils hétérogènes et à les faire communiquer entre eux, se multiplient.
Ces technologies de plus en plus complexes nécessitent d'avoir une bonne vision globale des différentes constituantes du système telles que l'architecture logicielle, les protocoles, le cloud, le big data, la sécurité, les réseaux, en plus de l'objet.

Intervenant : Frédéric CAMPS - Ingénieur de recherche CNRS

PROGRAMME

13h30- Accueil

Introduction et statistiques de l'IoT
- Qui sont les acheteurs ? Quels sont les produits les plus vendus ?
- Profil des consommateurs, motivation d'achat, comportement d'utilisation, freins à l'achat
- Segmentation du marché, exemple avec la santé et le transport
- Cyberdépendance : Symptômes physiologiques

Etat de l'art des architectures des systèmes et des protocoles
- Modèle abstrait d'architecture de l'IoT
- Design pattern de développement,
- Application verticale et horizontale,
- Architectures : self, home, city, work, commune
- Protocoles standard de transport réseau (5G/NB-IoT, Wifi Halow, ZigBee, Thread, 6loWPAN, LoRa, Sigfox …)
- Interactions avec les bus de terrain : BacNET, ModBus, KNX, M-Bus
- Protocoles de transport de données : REST, MQTT, CoAP, Websocket, XMPP, AMQP

Interopérabilité des systèmes avec le M2M
- Intérêt des systèmes M2M
- Apport du M2M dans l'IoT (architecture commune)
- Les standards M2M en Europe, USA, Asiatique
- Critère de choix pour une plateforme M2M
- Présentation du standard ETSI, projet Européen FIWARE
- Architecture privée, d'entreprise, urbaine
- Intégration de la sécurité, du big data, des protocoles
- Complexité de l'infrastructure, big data, analyse de données,
- M2M légers pour l'embarqué – OPC UA
- Impact des standards M2M sur l'électronique et le logiciel

Bilan sur les Open plateformes
- Les composants d'une plateforme open source
- Exemple Open plateforme
- Plateforme – hub numérique
- Le hub numérique
- Exemples de plateformes (Amazon, La Poste …),

IoT et abstraction technologique
- Découverte automatique des IoT : vers le « DNS » pour IoT ?
- Exemple avec un projet open source
- Langage standard de description système (ADL)

Libérer le concept de l'IoT avec les Use Case
- Définition d'un Use case – aspect fonctionnel et non fonctionnel
- Banque de Use Case,
- Uses cases génériques,
- Templates génériques,
- Génération et exploitation : Exemple avec un projet open source, exemple sur un smartphone.

Les bonnes pratiques pour le développement d'un IoT

17h30 - Table ronde, Retour d'expérience & témoignage d'une PME

18h00 - Conclusions

INFORMATIONS PRATIQUES

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

Lieu : IMS – Bât A31 - 351 Cours de la Libération - 33405 TALENCE CEDEX

Date : Jeudi 08 Juin 2017 de 13h30 à 18h00

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

Contact : Richard SALVETAT au 06 86 40 94 52 ou par email : salvetat@captronic.fr

Inscription obligatoire

Découvrez notre guide spécial Programmation réseau avec Python !

GNU/Linux Magazine consacre son nouveau hors-série à la programmation réseau en vous apprenant à créer vos applications client/serveur en Python ! Vous démarrerez cette nouvelle aventure en découvrant les modules essentiels à la programmation réseau, puis vous serez accompagné dans la création de plusieurs projets parmi lesquels un client XMPP, un bot IRC, ou encore un robot Slack. La dernière partie de ce guide vous permettra d’aller plus loin en créant un script communiquant par SMS et en analysant un serveur de fichiers. Retrouvez dès à présent ce nouveau numéro en kiosque, mais aussi sur notre boutique ou encore notre plateforme de lecture en ligne Connect

Au sommaire

DÉMARREZ… la programmation réseau en Python avec les modules essentiels

p. 08 Utilisez TCP et UDP en Python

p. 22 Développez une application graphique utilisant le réseau

p. 34 Utilisez des API REST en Python

p. 46 Scapy, le couteau suisse Python pour le réseau

CRÉEZ… vos robots et clients en Python pour interagir avec des services web tels que GitHub, Google Drive, etc.

p. 58 Créez un système de migration des rapports de bug de GitHub à votre GitLab

p. 68 Créez un driver FUSE pour Google Drive

p. 76 Créez un bot IRC

p. 86 Créez un robot Slack

p. 98 Créez un client XMPP

PROGRESSEZ… en créant un script communiquant par SMS et en analysant un serveur de fichiers

p. 108 Envoyez des SMS avec un Raspberry Pi et Python

p. 116 Un exemple concret de serveur HTTP servant des fichiers

Découvrez notre guide spécial Programmation réseau avec Python !

GNU/Linux Magazine consacre son nouveau hors-série à la programmation réseau en vous apprenant à créer vos applications client/serveur en Python ! Vous démarrerez cette nouvelle aventure en découvrant les modules essentiels à la programmation réseau, puis vous serez accompagné dans la création de plusieurs projets parmi lesquels un client XMPP, un bot IRC, ou encore un robot Slack. La dernière partie de ce guide vous permettra d’aller plus loin en créant un script communiquant par SMS et en analysant un serveur de fichiers. Retrouvez dès à présent ce nouveau numéro en kiosque, mais aussi sur notre boutique ou encore notre plateforme de lecture en ligne Connect

Au sommaire

DÉMARREZ… la programmation réseau en Python avec les modules essentiels

p. 08 Utilisez TCP et UDP en Python

p. 22 Développez une application graphique utilisant le réseau

p. 34 Utilisez des API REST en Python

p. 46 Scapy, le couteau suisse Python pour le réseau

CRÉEZ… vos robots et clients en Python pour interagir avec des services web tels que GitHub, Google Drive, etc.

p. 58 Créez un système de migration des rapports de bug de GitHub à votre GitLab

p. 68 Créez un driver FUSE pour Google Drive

p. 76 Créez un bot IRC

p. 86 Créez un robot Slack

p. 98 Créez un client XMPP

PROGRESSEZ… en créant un script communiquant par SMS et en analysant un serveur de fichiers

p. 108 Envoyez des SMS avec un Raspberry Pi et Python

p. 116 Un exemple concret de serveur HTTP servant des fichiers

L'interopérabilité des systèmes connectés. Impact pour l'écosystème des objets connectés IoT / M2M ! - Béziers (34) Le 30 juin 2017

Ce séminaire organisé dans le cadre de la journée TECH DAY, vous propose un état de l'art sur le sujet, avec en fil rouge l'interopérabilité et les standards industriels et l'impact que cela engendre sur l'IoT / M2M. L'ensemble du séminaire sera illustré par des exemples concrets de projets, réalisés par les étudiants du département Réseaux et télécommunications dans le cadre de leur cursus.

Souvent désignés par leurs initiales, le machine to machine (M2M) et l'Internet of Things (IoT) sont deux concepts très proches, souvent source d'innovation dans les services. Un système IoT/M2M est un système complexe : l'objet/le capteur, les réseaux de communication radiofréquence, une passerelle / routeur qui se connecte à Internet sur les systèmes centraux (serveurs cloud) pour offrir du service.
Demain la flexibilité des architectures et des flux de données offrira des interactions entre les objets, au-delà de leurs constructeurs ou des secteurs d'activités, afin d'apporter de nouveaux services plus performants. L'interopérabilité est en marche, les plates-formes de l'Internet des objets qui ont vocation à connecter ces appareils hétérogènes et à les faire communiquer entre eux, se multiplient. Ces technologies de plus en plus complexes nécessitent d'avoir une bonne vision globale des différentes constituantes du système telles que l'architecture logicielle, les protocoles, le cloud, le big data, la sécurité, les réseaux, en plus de l'objet.

Intervenant : Frédéric CAMPS - Ingénieur de recherche CNRS

PROGRAMME

10h00 : Mot des organisateurs

Introduction et statistiques de l'IoT
- Qui sont les acheteurs ? Quels sont les produits les plus vendus ?
- Profil des consommateurs, motivation d'achat, comportement d'utilisation, freins à l'achat
- Segmentation du marché, exemple avec la santé et le transport
- Cyberdépendance : Symptômes physiologiques

Etat de l'art des architectures des systèmes et des protocoles
- Modèle abstrait d'architecture de l'IoT
- Design pattern de développement,
- Application verticale et horizontale,
- Architectures : self, home, city, work, commune
- Protocoles standard de transport réseau (5G/NB-IoT, Wifi Halow, ZigBee, Thread, 6loWPAN, LoRa, Sigfox…)
- Interactions avec les bus de terrain : BacNET, ModBus, KNX, M-Bus
- Protocoles de transport de données : REST, MQTT, CoAP, Websocket, XMPP, AMQP

12h30 – 14h00 : Pause déjeuner

Interopérabilité des systèmes avec le M2M
- Intérêt des systèmes M2M
- Apport du M2M dans l'IoT (architecture commune)
- Les standards M2M en Europe, USA, Asiatique
- Critère de choix pour une plateforme M2M
- Présentation du standard ETSI, projet Européen FIWARE
- Architecture privée, d'entreprise, urbaine
- Intégration de la sécurité, du big data, des protocoles
- Complexité de l'infrastructure, big data, analyse de données,
- M2M légers pour l'embarqué – OPC UA
- Impact des standards M2M sur l'électronique et le logiciel

Bilan sur les Open plateformes
- Les composants d'une plateforme open source
- Exemple Open plateforme
- Plateforme – hub numérique
- Le hub numérique
- Exemples de plateformes (Amazon, La Poste …),

IoT et abstraction technologique
- Découverte automatique des IoT : vers le « DNS » pour IoT ?
- Exemple avec un projet open source
- Langage standard de description système (ADL)

Libérer le concept de l'IoT avec les Use Case
- Définition d'un Use case – aspect fonctionnel et non fonctionnel
- Banque de Use Case,
- Uses cases génériques,
- Templates génériques,
- Génération et exploitation : Exemple avec un projet open source, exemple sur un smartphone.

Les bonnes pratiques pour le développement d'un IoT

17h00 : Conclusion de la journée - Questions/Réponses

INFORMATIONS PRATIQUES

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

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

Date : Vendredi 30 juin 2017 de 10h00 à 17h00 – 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

Internet des Objets : Du concept à la pratique - Toulouse (31) Le 1er juin 2017

CAPTRONIC et ses partenaires, LAAS-CNRS, INSA Toulouse, le Catalyseur et INTEL organisent cette journée à l'attention des étudiants, des industriels et des chercheurs.
La matinée est consacrée à des présentations sur la méthodologie de conception d'un objet connecté, l'état des déploiements des communications d'objets connectés et leurs performances et la tendance de la 5G, le développement durable à Toulouse métropole et la smart city. Des ateliers auront lieu l'après-midi.
Pendant le déjeuner il sera présenté des projets d'étudiants issus du concours sur les 'Objets et services connectés pour la ville du futur : Smart City'

PROGRAMME

9h00-9h15 : Introduction à la journée

9h15-9h55 : Méthodologie de conception électronique d'un objet connecté par Thomas DEMARNE (Consultant R&D chez ALCIOM)

9h55-10h35 : Cellular LPWA communications for the Internet of Things par Nicolas DAMOUR (Senior Manager, Business and Innovation Development chez SIERRA WIRELESS)

10h35-11h05 : Pause

11h05-11h45 : Le développement durable dans la métropole de Toulouse par Axel PAULINO (Chargé de Projets Innovants métropole de Toulouse – Smart City)

11h45-12h25 : Smart ville et observativité du réseau par Tony MARCHAND (Chargé de projet numérique et région à ENEDIS)

12h25-13h00 : pitch des sessions ateliers

13h00-14h30 : Repas et démonstration concours

14h30-16h00 : 2 Sessions de 45 minutes en parallèle

16h00-16h30 : Pause et remise des prix du concours

16h30-18h00 : 2 Sessions de 45 minutes en parallèle

• Premiers pas avec l'intergiciel OM2M et le standard OneM2M pour l'interaction avec un smart bilding par F. AÏSSAOUI, G. GARZONNE et N. SEYDOUX du LAAS-CNRS
• Méthodes et bonnes pratiques organisationnelles pour un développement sécurisé d'un objet connecté par L. MEYER de la société DIGITAM
• Comment manager l'innovation (PME et grands groupes) ? (Mr MARCHAND ENEDIS)
• L'écosystème d'innovation en Occitanie (Mr MARCHAND ENEDIS)

• Découverte du réseau LoRaWAN Objenious et expérimentation (Christophe Fouille, Objenious)

• Comment rendre son code cybersecure (Mr Micael MARTINS, ISIT)

• Projets autour de NeOCampus :
- Introduction à l'architecture neOCampus + Un automate open-source pour connecter les capteurs industriels / tertiaires à neOCampus (François Thiebolt, UPS)
- Relevé de compteurs modbus via une liaison LoRa (Alexandre Fernandes, UPS)
- La mesure de fréquentation par caméra (Alexandre Herrera, UPS)
- Nouveaux capteurs de bruit / luminosité / température / hygrométrie à la Bibliothèque des Sciences (Zhenyu BAI, UPS)
- LuxOCampus, un caliendrier connecté (Louis Dupré Bertoni, UPS)

• La simulation pour l'optimisation d'antenne des objets connectés (Pascal De Resseguier, Nexio). Cet atelier présentera le logiciel CAPITOLE-RF qui est parfaitement adapté pour aider les ingénieurs à optimiser la partie RF de leur produits. Vous réaliserez des simulations sur un cas pratique issu d'un design de référence antenne PCB. Vous pouvez également amener vos fichiers GERBER et étudier votre propre design PCB

INFORMATIONS PRATIQUES

Personnes concernées : Ce séminaire s'adresse aux chefs d'entreprises, chefs de projets, intéressés par les objets connectés.

Date et lieu : 01/06/17 de 9h00 à 17h00 à l'INSA - Amphithéâtre Vinci, 135 avenue de Rangueil à TOULOUSE

Prix : Gratuit.

Contacts : Thierry MONTEIL - monteil@laas.fr, Jérémie GRISOLIA - jeremie.grisolia@insa-toulouse.fr ;
Nicolas DELCEY - nicolas.delcey@univ-tlse3.fr - Didier VIRATELLE - 06 83 04 09 78 - viratelle@captronic.fr

Inscription obligatoire sur ce LIEN

Orchestration with MCollective

I originally got into systems administration because I loved learning about computers, and I figured that was a career that always would offer me something new to learn. Now many years later that prediction has turned out to be true, and it seems like there are new things to learn all the time. more>>

Android Candy: Landing on the Moon, with your Thumbs

I do a lot of system administration with my thumbs. Yes, if I'm home, I grab a laptop or go to my office and type in a real terminal window. Usually, when things go wrong though, I'm at my daughters' volleyball match or shopping with my wife. Thankfully, most tasks can be done remotely via SSH. There are lots of SSH clients for Android, but my favorite is JuiceSSH. more>>

La 5G : nouvelles technologies & nouveaux business models - Grenoble - Minatec (38) Le 9 juin 2017

Annoncée avec des débits 100 fois plus élevés que la 4G, la 5G est présentée comme la prochaine révolution dans le secteur des télécoms. Au-delà des débits, quels seront les grands impacts pour les applications grands publics et surtout professionnelles ?
Alors que les opérateurs annoncent les premiers déploiements pour 2019 en France, cette demi-journée vous présentera la technologie mais également toutes ses potentialités, promesses d'usages et business models associés.

Ce séminaire est organisé par CAP'TRONIC en partenariat avec Minalogic et l'IRT Nanoelec.

MINATEC
3 parvis Louis Néel
38 Grenoble

Programme

  • 13h45 : Accueil à Minatec
  • 14h00 : Présentation et positionnement des différentes technologies de transmission RF pour l'Iot (LoRa, Sigfox, EC-GSM, LTE-M, NB-IoT…) - Pascal Champaney, Always Wireless
  • 14h45 : 5G : nouvelles technologies & nouveaux modèles économiques - Lionel Rudant, CEA Leti, Responsable Marketing Stratégique IoT
    L'internet des objets (Internet of Things IoT) promet de bouleverser les modèles économiques de nos industries et de nos territoires en mettant au cœur de la création de valeur l'exploitation de la donnée.
    Une première génération de solutions IoT a fait la démonstration de ces perspectives avec le déploiement commercial de réseaux IoT et de plateformes Cloud.
    Cependant, les limitations des technologies actuelles ont remis en cause les prédictions initiales de la croissance des marchés de l'IoT. Les données collectées montent et les données de services descendent sur les mêmes canaux de communication ce qui maintient des coûts de connectivité et des consommations en énergie importants, ainsi que des problèmes de sécurité et de confidentialité.
    Déjà, les roadmaps des technologies de l'information et de la communication préparent des évolutions structurantes de l'IoT.
    L'automobile connectée se déploie et constitue une nouvelle plateforme de services au plus près des utilisateurs. Une nouvelle vague de standards de réseaux non opérés libère les déploiements de réseaux de données privées. Enfin, les réseaux cellulaires 5G promettent aux grands opérateurs industriels de concrétiser la révolution de l'IoT.
    La 5G redéfinit l'architecture du réseau pour réduire les coûts de déploiement et de gestion des opérateurs afin de globaliser la couverture des services d'accès à l'internet haut-débit mobile. Elle intègre aussi de nouveaux standards innovants pour le déploiement à très grande échelle de l'IoT ainsi que pour des missions critiques du réseau pour assurer la supervision des futurs déploiements de systèmes autonomes. Les annonces de déploiements pré-commerciaux de réseaux 5G-ready se sont multipliés depuis le World Mobile Congress WMC de 2016 et les premières offres commerciales sont annoncées dès 2018.
  • Autres interventions en cours de confirmation

Ce séminaire est précédé du Comité de Pilotage CAP'TRONIC Sud-Est, si vous souhaitez y assister, merci de vous inscrire en suivant ce lien

Pour toute information, vous pouvez contacter
Claude Vittoria : vittoria@captronic.fr
Dorothée Wallart, Assistante Inter Région SUD-EST : wallart@captronic.fr

Inscription obligatoire en ligne via le formulaire ci-dessous

Comité de Pilotage CAP'TRONIC SUD-EST - Grenoble - Minatec (38) Le 9 juin 2017

Toute l'équipe de CAP'TRONIC Sud-Est a le plaisir de vous convier au prochain Comité Inter Régional de Pilotage qui aura lieu le 9 juin 2017 à partir de 9h30 à :

MINATEC
3 parvis Louis Néel
38 Grenoble

Cette réunion a pour objet de faire le point sur l'activité nationale et régionale de l'Association JESSICA France et du programme CAP'TRONIC qu'elle met en œuvre.

Ce rendez-vous est pour nous un temps fort de la vie de notre Association.
Il est pour vous l'occasion de participer à la vie de JESSICA FRANCE en exprimant vos attentes sur le programme CAP'TRONIC et plus largement sur la coordination des dispositifs d'aides aux PME innovantes. Nous élirons également à cette occasion un nouveau Président de CIRP (Comité Interrégional de Pilotage) qui représentera les adhérents CAP'TRONIC au Conseil d'Administration national de l'association.

C'est pourquoi votre présence en tant que PME adhérentes, partenaires institutionnels et centres de compétences publics et privés revêt une importance toute particulière.

N'hésitez pas à nous contacter si votre société est adhérente et si vous souhaitez vous porter candidat à cette élection.

Programme

  • 9h45 : Accueil à Minatec
  • 10h00 : Après un tour de table, présentation de l'activité JESSICA en Sud Est
  • 10h30 : Les évolutions du programme CAP'TRONIC
  • 10h45 : Présentation des candidats et élection d'un nouveau Président de CIRP
  • 11h15 : Les projets de séminaires, d'ateliers et de formations - échanges avec la salle
  • 11h45 : Articulation du programme CAP'TRONIC avec les autres dispositifs d'innovation : présentation des évolutions du dispositif Easytech, Damien Cohen, Responsable du programme Easytech - Minalogic
  • 12h15 : Les dispositifs d'aide à l'innovation proposés par BpiFrance, Philippe Koch, Délégué Innovation Alpes Bpifrance Auvergne Rhône-Alpes
  • 12h30 : Buffet

L'après-midi sera consacré, pour ceux qui le souhaitent, à un séminaire sur la 5G : > plus d'information.

Pour toute information, vous pouvez contacter :
Jean-Philippe MALICET, Directeur national et Directeur de l'Inter Région SUD-EST : malicet@captronic.fr
Dorothée Wallart, Assistante Inter Région SUD-EST : wallart@captronic.fr

Inscription obligatoire en ligne via le formulaire ci-dessous

GNU/Linux Magazine est partenaire du salon Innorobo !

La nouvelle édition du salon dédié à la transformation robotique se tiendra du mardi 16 au jeudi 18 mai aux Docks de Paris. À travers ces trois journées accueillant l’écosystème robotique international, vous pourrez échanger autour des innovations robotiques et dernières tendances du marché, rencontrer de nombreux exposants (notre stand sera le S20 😉 ), mais aussi découvrir une approche humaine des technologies robotiques. Nous vous donnons rendez-vous lors de cet événement, que vous pourrez découvrir plus en détail sur https://innorobo.com/fr/accueil/, avec GNU/Linux Magazine, mais aussi Hackable. À très vite ! 🙂

CARNAUTO 2017 : Cybersécurité pour la mobilité - Palaiseau (91) Le 13 juin 2017

Programme :

- 17:00 Accueil

- 17:15 Cybersécurité : enjeux industriels et stratégie

- 17:45 Véhicule connecté : confiance et certification

- 18:05 CARNAUTO : une offre de R&D sur toute la chaîne de la valeur

- 18:30 Innovation PME

- 18:45 Financer la R&D

- 19:00 Cocktail de clôture - espace démonstrateurs

Inscription gratuite : cliquez-ici

Lieu de l'événement :

CEA Nano-INNOV
Avenue de la Vauve
91120 Palaiseau
Accès

Contact :

Michel MARCEAU - 01 69 08 24 90

Plus d'information sur www.carnauto.fr

Will Anything Make Linux Obsolete?

Remember blogging? Hell, remember magazine publishing? Shouldn't be hard. You're reading some now.

Both are still around, but they're obsolete—at least relatively. Two cases in point: my blog and Linux Journal. more>>