James Gray, 26/07/2017 | Source: Linux Journal
Susan Sons, 25/07/2017 | Source: Linux Journal
Incidents happen. Vulnerabilities happen. The quality of your response can make the difference between a bad day and a disaster. What happens after the response can make the difference between endless firefighting and becoming stronger with every battle. A quality postmortem analysis is free ammunition. more>>
redaction, 25/07/2017 | Source: Linux Magazine
L’important choix de cartes intégrant des capteurs/actionneurs, en fait aujourd’hui, un choix difficile pour l’utilisateur final. C’est pour ces raisons que MikroElektronika a créé un standard : MikroBUS. Il facilite l’interaction entre microcontrôleur ou microprocesseur et les cartes d’extensions, appelées « add-ons », utilisant cette connectique. Cet article se propose d’explorer la partie MikroBUS d’un des tous derniers SBC (Single Board Computer) du marché : la WaRP7 (« WearAble Reference Platform »). On commencera dans un premier temps par une succincte présentation de la WaRP7 et d’une partie « board bring-up » (via Yocto/OE). Puis, viendra la partie MikroBUS qui sera mise en avant à travers un mini projet architecturé autour du Bluetooth Low Energy et du framework Qt5 pour Android tout en y intégrant une carte add-ons, carte qui se base sur le standard MikroBUS.
Le présent article s’inscrit dans la continuité des manipulations ayant permis la rédaction d’un article précédent paru dans le n°20 d’Open Silicium [1], les auteurs renverront vers celui-ci les lecteurs qui désirent avoir de plus amples connaissances sur la diversité que propose la cible utilisé dans ce numéro de Linux Magazine. Dans le premier article, il était question de découvrir la WaRP7 et ses capteurs au travers une application « IoT » minimaliste (récupération d’une température, la pression atmosphérique ainsi qu’une valeur représentant le rythme cardiaque), ceci en utilisant la connectivité Bluetooth et le framework Qt5, le tout basé sur une distribution Yocto/OE mis à disposition par les auteurs.
Que le lecteur ne pouvant pas se procurer le premier article soit rassuré, on se permettra tout de même ici de faire des rappels (ouf !) quant aux éléments essentiels (présentation de la cible, génération et installation de l’image sur notre cible, une partie Bluetooth, puis quelques mots sur le SDK Yocto/Qt5).
La plateforme cible [2] est composée de 2 cartes :
Fig. 1: Non, la WaRP7 n’est pas timide
La génération de la distribution pour notre cible, repose sur l’utilisation du BSP (Board Support Package) NXP articulé autour du projet Yocto [4] et de deux couches supplémentaires (nous ne ferons pas ici, de détails quant à l’utilisation de Yocto/OE, le lecteur pourra en outre, se référer aux différents articles parus dans les précédents numéros d’open silicium).
La première étape consiste donc à récupérer l’ensemble des sources contenues dans le BSP. Pour ce faire, NXP utilise l’utilitaire repo (outil Python développé par Google [5]), ceci afin de permettre une meilleure gestion des référentiels Git compris dans celui-ci :
$ mkdir ~/bin
$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo
$ PATH=${PATH}:~/bin
$ mkdir warp7_glmf200
$ cd warp7_glmf200
$ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b krogoth
$ repo sync
Comme prévu, après récupération de notre base logicielle, nous pouvons maintenant télécharger les deux couches supplémentaires essentielles à la bonne construction de notre image.
Téléchargeons dans un premier temps la couche distribution mis à disposition par les auteurs [6], pour rappel, cette couche spécifique est intimement liée à l’article (ceci afin de ne pas se perdre dans le framework qu’est Yocto/OE) :
$ cd sources/ $ git clone https://github.com/bdx-iot/meta-iot.git
Dans un second temps, récupérons la couche permettant d’intégrer l’environnement Qt5 à notre distribution :
$ cd sources/ $ git clone https://github.com/meta-qt5/meta-qt5.git
Nous voilà maintenant en possession de l’ensemble des sources. L’étape d’après consiste en la création de l’environnement, on retrouve ci-après les différentes étapes :
La commande suivante s’occupera donc de nous placer dans un environnement de travail spécifique à notre plateforme de développement :
$ MACHINE=imx7s-warp source setup-environment warp7-build/
Il reste maintenant à définir les chemins vers les couches précédemment téléchargées, pour ce faire, modifions le fichier conf/bblayers.conf pour y rajouter les deux lignes suivantes :
${BSPDIR}/sources/meta-iot \
${BSPDIR}/sources/meta-qt5 \
Dernière étape avant de pouvoir lancer la construction de l’image, il nous faut spécifier la distribution utilisée (dans notre cas une distribution spécifique à l’article dérivé de la distribution poky) dans conf/local.conf, en mettant à jour la variable DISTRO :
DISTRO ?= 'iot'
Lançons maintenant la construction de notre image par le biais de la commande bitbake :
$ bitbake iot-qt-image
Après cette longue étape qu’est la construction, l’utilisateur pourra retrouver très facilement l’ensemble des fichiers utiles au bon démarrage de la plateforme (Bootloader, Kernel, RootFileSystem) dans tmp/deploy/images/imx7s-warp.
Rappelons qu’afin de mettre à jour le système avec l’ensemble des binaires compilés, les étapes se déroulent comme suit :
$ microcom --speed 115200 --port /dev/ttyUSB0 ... U-Boot 2016.07+fslc+ge6b4241 (Sep 14 2016 - 11:21:52 +0200) CPU: Freescale i.MX7S rev1.2 at 792MHz ... Hit any key to stop autoboot: 0
=> ums 0 mmc 0
$ cd tmp/deploy/images/imx7s-warp $ gunzip qt-image-imx7s-warp-20161118195314.rootfs.sdcard.gz $ sudo dd if=qt-image-imx7s-warp-20161118195314.rootfs.sdcard of=/dev/sdX (où X représente le device)
Une fois la copie terminée, l’utilisateur pourra redémarrer la carte pour voir apparaître la séquence de démarrage :
Starting kernel ... Booting Linux on physical CPU 0x0 Linux version 4.1.32-fslc+g9d3f7f9 (pjtexier@bdxiot) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT ... IOT powered by Yocto/OE (Welcome to Bordeaux) 2.1.1 iot /dev/ttymxc0 iot login: root Password: iot ___ ___ _____ |_ _/ _ \_ _| | | | | || | | | |_| || | |___\___/ |_| root@iot:~#
Rappelons ici, comment attacher, initialiser et activer notre interface Bluetooth, afin que celle-ci soit accessible par les autres périphériques compatibles :
root@iot:~# hciattach ttymxc2 bcm43xx 3000000 flow -t 20 root@iot:~# hciconfig hci0 up root@iot:~# hciconfig hci0 name 'Hello GLMF200' // Nom de l'interface visible depuis n'importe quel périphérique bluetooth root@iot:~# hciconfig hci0 piscan
Nous avons évoqué lors de l’article précédent la notion de SDK et chaîne de compilation croisée (mais pas que). Ceci afin de pouvoir générer du code Qt5 sur notre cible. La commande ci-dessous permettra la génération d’un SDK générique et compatible Qt5 :
$ bitbake meta-toolchain-qt5
Une fois la génération terminée, le script d’installation du SDK se trouvera dans tmp/deploy/sdk.
Elle se fera tout simplement en exécutant le script suivant où il conviendra de spécifier le chemin d’installation (/opt/iot/sdk dans cet exemple) :
$ cd tmp/deploy/sdk $./iot-glibc-x86_64-meta-toolchain-qt5-cortexa7hf-neon-toolchain-2.1.1.sh IOT powered by Yocto/OE (Welcome to Bordeaux) SDK installer version 2.1.1 ========================================================================= Enter target directory for SDK (default: /opt/iot/2.1.1): /opt/iot/sdk
Afin de se voir l’environnement de compilation croisée, intégré à notre IDE préféré, il nous faudra :
Dans cette partie nous aborderons, dans un premier temps, le standard MikroBUS, nous présenterons autant les aspects matériels que les aspects logiciels que propose celui-ci. Nous ferons ensuite un bref tour d’horizon sur les modules que propose MikroElektronika.
Le standard MikroBUS définit les connectiques des cartes principales (on parle souvent de carte mère) ainsi que celles des cartes additionnelles (add-on) utilisées pour l’interfaçage du microcontrôleur ou du microprocesseur avec les circuits et modules complémentaires. De plus, il spécifie la disposition physique du brochage, les broches de communication et les broches d’alimentation utilisées.
On remarque, bien évidemment, que l‘objectif de mikroBUS est de jouer sur la flexibilité matérielle, permettant ainsi un interfaçage plus facile avec un grand nombre de cartes complètes, qui plus est, standardisées (plus de 200 modèles commercialisés par MikroElektronika tout de même !), chacune avec un simple capteur (humidistance), un module radio (RFID), un écran (OLED), une connectique (RS232), ou tout autre module électronique[7].
Remarque
A noter que mikroBUS est un standard ouvert et donc n’importe qui peut prétendre implémenter mikroBUS dans sa conception matérielle, à condition bien sûr de respecter les conditions de MikroElektronika.
Le connecteur MikroBUS est composé de 16 broches (2×8). L’ensemble de celles-ci est toujours positionné de la même manière comme le montre la figure 2.
Fig. 2: pinout du standard MikroBUS
On retrouvera sur chaque module :
Il est bien évidemment compliqué de présenter ici l’ensemble des modules proposés par la firme MikroElektronika. Afin de donner au lecteur un bref aperçu des cartes disponibles, les auteurs auront choisi d’en exposer 2 au travers de cet article :
Fig. 3: La Relay Click sous les projecteurs
Cette carte embarque deux relais de puissance (G6D1AASI-5DC de référence Omron). Le pilotage vers la carte principale (dans notre cas la WaRP7) s’effectue via les broches suivantes du connecteur MikroBUS :
De notre point de vue, ce ne sera ni plus ni moins que l’activation (état haut ou état bas) d’une broche GPIO (ouverture ou fermeture du relais).
Fig. 4: L’inconnu au bataillon
Comme remarqué précédemment, il est possible de réaliser sa propre carte autour du standard MikroBUS. Dans cet exemple, le module est composé d’un gpio expander (microchip mcp23s08) pilotable au travers d’une interface SPI (mais aussi via le bus i2c). Cette option permet d’étendre les capacités de la carte principale quand celle-ci arrive à ses limites (ou si aucune GPIO physique n’est présente sur la carte mère).
Viens maintenant le temps de jouer un peu avec notre module MikroBUS, celui-ci permettant d’étendre les capacités de notre WaRP7, nous mettant ainsi des relais à disposition (ceci afin de commander par exemple une lampe, ou tout autre objet …). Dans ce chapitre nous verrons comment les piloter de façon simpliste en accédant aux GPIO depuis l’espace utilisateur. Nous aborderons ensuite le sujet du device tree et l’accès à la configuration des GPIO depuis celui-ci.
Insérons notre module relais et constatons qu’il est très facile d’intégration entre notre plateforme cible et les modules MikroBUS (WaRP7 <-> Relay Click Board), ceci grâce à la standardisation :
Fig. 5 : La WaRP7 en position !
Sous GNU/Linux, l’accès aux GPIO [8] s’effectue dans /sys/class/gpio/gpioN où N représente le numéro de la GPIO (à condition que le driver associé soit présent → GPIO_SYSFS).
Nous savons par le biais de la schématique (disponible en [2]), que le relais 1 et sur la broche CPU « GPIO7_IO8 », qui, en espace utilisateur devient gpio200.
Comment calculer le numéro de gpio utilisé en mode userspace ?
Le calcul est sous la forme : ((port_GPIO – 1)*32) + n°gpio.
Exemple pour le relais 1 : ((7-1)*32) + 8 = 200
La première étape consistera à exporter cette GPIO pour la rendre accessible depuis le système de fichier virtuel /sys, la commande si après créera donc un point d’accès gpio200 :
root@iot:~# echo 200 > /sys/class/gpio/export
L’interface étant disponible, il nous faut la paramétrer en tant que broche de sortie :
root@iot:~# echo out > /sys/class/gpio/gpio200/direction
Une fois configurée, il nous est possible de la piloter, ceci en agissant simplement sur la tension de sortie de la broche, via la commande suivante :
root@iot:~# echo 1 > /sys/class/gpio/gpio200/value
La broche de sortie passée à l’état haut, il nous est facile de constater le résultat sur la carte relais (led REL1), comme nous le montre la figure 6 :
Fig. 6: Relais 1 en fonctionnement
Nous ferons de même pour le relais numéro 2 (RL2 sur la « relay click ») qui lui est sur « GPIO4_IO23 » :
root@iot:~# echo 119 > /sys/class/gpio/export root@iot:~# echo out > /sys/class/gpio/gpio119/direction root@iot:~# echo 1 > /sys/class/gpio/gpio119/value
Fig. 7 : Relais 2 en fonctionnement
L’inconvénient des étapes (export/direction) précédentes réside dans le fait qu’il nous est obligatoire de les réexécuter à chaque démarrage de la WaRP7, car non statique au sein de la configuration matérielle. Il serait donc intéressant d’avoir une entrée statique. Nous irons un peu plus loin que la simple configuration des GPIO.
En effet, il serait aussi plaisant de pouvoir associer un nom à nos GPIO lors de la configuration de celles-ci, pour ce faire, nous intégrerons le travail de Martin FUZZEY[9] (qu’on ne manquera pas de remercier pour le travail effectué), qui a en effet développé un driver Kernel permettant d’avoir au sein de l’espace utilisateur, un lien nom/numéro de GPIO. L’avantage de cette solution est que finalement, l’utilisateur ne se soucie plus du numéro de la GPIO, de ce fait, la configuration est beaucoup plus portable et maintenable.
L’arbre de périphériques (device tree ou encore DT) est une structure de données permettant de décrire le matériel d’un système, dérivée du format utilisé par Open Firmware pour encapsuler les informations de plateforme et les transmettre au noyau, qui utilise alors les données du DT pour trouver et enregistrer les périphériques du système.
La structure de données elle-même est un arbre de nœuds nommés et de propriétés. Chaque nœud contient des propriétés de simples paires « nom-valeur » et des nœuds fils. Afin d’être interprétée correctement par le noyau, l’arborescence doit suivre une structure prédéfinie. Une « liaison » (en anglais, binding) est une description de la façon dont un périphérique est décrit dans le DT. Un grand nombre de périphériques disposent de liaisons bien établies et documentées.
Afin de ne pas surcharger le fichier dts (device tree source) principal (imx7s-warp.dts), les auteurs auront choisi de créer un fichier dts spécifique à l’intégration du module « relay click », en voici sa constitution :
#include "imx7s-warp.dts"
/ {
gpio_exporter: gpio-exporter {
compatible = "linux,gpio-exporter";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpioexporter_relay>;
out_RL1 {
gpios = <&gpio7 8 GPIO_ACTIVE_HIGH>;
output;
initial-state = <0>;
};
out_RL2 {
gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
output;
initial-state = <0>;
};
};
};
&iomuxc {
pinctrl-names = "default";
imx7s-warp {
pinctrl_gpioexporter_relay: gpioexportergrp {
fsl,pins = <
MX7D_PAD_ENET1_RGMII_TD2__GPIO7_IO8 0x14
MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x14
>;
};
};
};Essayons de détailler celui-ci :
gpio_exporter: gpio-exporter {
compatible = "linux,gpio-exporter";
static const struct of_device_id gpio_exporter_dt_ids[] = {
{ .compatible = "linux,gpio-exporter", },
} ;
pinctrl-0 = <&pinctrl_gpioexporter_relay>;
out_RL1 {
gpios = <&gpio7 8 GPIO_ACTIVE_HIGH>;
output;
initial-state = <0>;
};Il nous faudra aussi renseigner les propriétés à notre nœud fils :
Il en sera de même pour le relais numéro deux, où seul le nom du sous-nœud et de la GPIO associé seront donc à modifier pour le piloter :
out_RL2 {
gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
output;
initial-state = <0>;
};
};Nous en resterons là quant à la présentation du fichier device tree, le lecteur pourra se référer au très bon article écrit par Thomas Petazzoni paru dans le n°17 d’Open Silicium [11].
Pierre-Jean TEXIER
[Ingénieur Linux Embarqué, Intervenant Linux Embarqué à ESTEI Bordeaux ,
Co-auteur de l’ouvrage « Yocto For Raspberry-pi »]
Jean CHABRERIE
[Ingénieur Systèmes Embarqués, Qt Enthousiaste]
La seconde partie de cet article sera publiée prochainement sur le blog, restez connectés 
Retrouvez cet article (et bien d’autres) dans GNU/Linux Magazine n°200, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !
James Gray, 24/07/2017 | Source: Linux Journal
The quick pitch for Rogue Wave Software's Zend Studio, recently updated to version 13.6, is "the PHP IDE for smarter development". Zend Studio 13.6, says Rogue Wave, offers 3X faster performance in indexing, validation and searching of PHP code, and it allows users to code faster, debug more easily and leverage the massive performance gains in PHP 7. more>>
Todd A. Jacobs, 20/07/2017 | Source: Linux Journal
In a previous article, "Provisioning Docker with Puppet", in the December 2016 issue, I covered one of the ways you can install the Docker service onto a new system with Puppet. By contrast, this article focuses on how to manage Docker images and containers with Puppet. more>>
redaction, 20/07/2017 | Source: Linux Magazine
Dans la course aux fonctionnalités, nous ne cessons de casser ce qui marche pour mettre à jour les nouvelles fonctionnalités. Pourquoi donc casser ce bel exemple OpenLayers2 pour le remplacer par OpenLayers3 ? La déformation excessive des cartes aux latitudes élevées est un défaut bien connu de la projection de Mercator utilisée par défaut par tous les environnements cartographiques de la toile (projection de code 900913 – l’écriture leet de Google – puisque la norme choisie n’a pas été validée par l’instance qu’est l’EPSG). Étant conscients des déficiences de la projection de Mercator, nous voudrions pouvoir sélectionner un mode de projection localement tangent à la région considérée – à savoir Universal Transverse Mercator (UTM). Et nous en arrivons à l’excuse pour passer de OpenLayers 2 à 3 : la version actuelle d’OpenLayers ne permet pas la projection au vol des images, et impose donc une sortie déformée, particulièrement gênante lorsque nous nous éloignons de l’équateur.
Nous reprenons donc toutes nos investigations, mais cette fois dans le contexte d’OpenLayers 3, avec la nécessité pour chaque nouvelle couche de préciser le mode de projection d’entrée (toutes nos données sont stockées en coordonnées sphériques, donc WGS84 de code EPSG:4326. OpenLayers ne connaît pas tous les modes de projection de sortie : nous devons les définir selon nos besoins (voir figure 5).
Fig. 5: Gauche : le passage à une projection locale WGS84/UTM33N résout la déformation observée auparavant dans OpenLayers 2 et son Google Mercator. Cependant, cette projection n’a pas prétention de s’étendre à tout le globe, et réduire le grossissement met en évidence la déformation sur les régions adjacentes, ici le nord Canada et la Sibérie (droite). Cet exemple est disponible sur jmfriedt.sequanux.org/reproj.html.
Heureusement, proj4 se charge de cette opération pour nous, et http://spatialreference.org/ref/epsg/wgs-84-utm-zone-33n/ nous informe de la façon de définir WGS84/UTM33N (la bande qui couvre la Norvège – nous aurions choisi UTM31N pour la France). Ainsi, le mode de projection qui va nous intéresser se définit par :
proj4.defs('EPSG:32633','+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +towgs84=0,0,0 +no_defs');Et nous pouvons faire appel aux outils de conversion de la forme :
var osmLayer = new ol.layer.Tile({ source: new ol.source.OSM() });
var map = new ol.Map({
controls: ol.control.defaults().extend([new ol.control.ScaleLine()]),
target: 'map',
view: new ol.View({projection: 'EPSG:32633',center: ol.proj.fromLonLat([10, 79], 'EPSG:32633'),zoom: 9})
});
var dm_wms2013 = new ol.layer.Tile({
preload: Infinity,
visible: true,
source: new ol.source.TileWMS(({
url: 'http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi',
params: {'LAYERS': '2013_0830utm33n', 'TILED': true, 'VERSION': '1.3.0',
'FORMAT': 'image/png8', 'WIDTH': 256, 'HEIGHT': 256, 'CRS': 'EPSG:4326'},
serverType: 'geoserver'
}))
});
...
map.addLayer(osmLayer);
map.addLayer(dm_wms2013);Ici la projection de la carte respecte la norme EPSG (WGS84/UTM33N s’appelle EPSG:32633) que nous avons défini par proj4 auparavant, tandis que les données en entrée (ici issues de la fonction WM(T)S du serveur) sont au format WGS84 en coordonnées sphériques (aussi nommée EPSG:4326).
Une dernière question que nous pouvons nous poser, dans le contexte d’un travail collaboratif où chaque utilisateur est susceptible d’ajouter ses propres couches, tient en la capacité à automatiser la génération d’une page Web contenant toutes les couches fournies par un serveur QGis. Cela signifie donc récupérer la description XML des capacités du serveur, découper cette description pour extraire le nom des couches disponibles, et finalement générer automatique le script JavaScript affichant toutes ces couches. De telles fonctionnalités sont fournies (paquet php-xml dans la distribution Debian) par simplexml. Ainsi, un premier script qui se contente de lister toutes les couches disponibles en recherchant d’abord les fonctionnalités WMS du serveur, puis en étudiant [5] la liste des propriétés (FeatureTypeList) et finalement les propriétés de chacun de ces objets (FeatureType) pour en extraire le nom (FeatureTypeList->FeatureType->Name) ressemble à :
<html><head><title>XML depuis PHP</title></head><body>
<?php
if (extension_loaded(’simplexml’)) {
echo "extension installed:<hr>";
$mypix = simplexml_load_file(urlencode(
’http://127.0.0.1/cgi-bin/project/landsat/qgis_mapserv.fcgi? SERVICE=WFS&VERSION=1.0.0&REQUEST=GetCapabilities’));
foreach ($mypix->FeatureTypeList as $pixinfo):
foreach ($pixinfo->FeatureType as $nam):
if ($nam->Name!=’’) echo $nam->Name,"<br>";
endforeach;
endforeach;
}
else echo "missing extension<br>";
?>
</body></html>Ayant compris ce mécanisme, il devient simple de générer les champs décrivant chaque couche WMS affichée, en lui attribuant le même nom de couche que celui utilisé dans QGis. Le résultat est :
<html><head><title>Toutes les couches WMS depuis openlayers</title>
<script src="http://openlayers.org/api/OpenLayers.js"></script>
</head>
<body>
<div style="width:100%;height:100%" id="map"></div>
<script defer="defer" type="text/javascript">
var map=new OpenLayers.Map(’map’);
ls=new OpenLayers.Control.LayerSwitcher({’div’:OpenLayers.Util.getElement(’layerswitcher’)});
map.addControl(ls);
ls.maximizeControl();
var wms=new OpenLayers.Layer.WMS("Basic map",
"http://vmap0.tiles.osgeo.org/wms/vmap0",{layers: ’basic’} );
<?php
$k=1;
if (extension_loaded(’simplexml’)) {
$mypix = simplexml_load_file(urlencode(
’http://127.0.0.1/cgi-bin/project/landsat/qgis_mapserv.fcgi?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetCapabilities’));
foreach ($mypix->FeatureTypeList as $pixinfo):
foreach ($pixinfo->FeatureType as $nam):
if ($nam->Name!=’’)
{echo "var dm_",$k,"=new OpenLayers.Layer.WMS(\"",$nam->Name,"\",";
echo "\"http://127.0.0.1/cgi-bin/project/landsat/qgis_mapserv.fcgi\",";
echo "{layers: \"",$nam->Name,"\",";
echo "transparent:\"true\", format:\"image/png\"},{isBaseLayer: false});\n";
$k++;
}
endforeach;
endforeach;
echo "map.addLayer(wms);\n";
echo "map.setCenter(new OpenLayers.LonLat(12,79),9);\n";
for ($x=1;$x<$k;$x++) {echo "map.addLayer(dm_$x);\n";}
} else echo "missing extension<br>";
?>
</script></body></html>Ce qui donne la figure 6. Il serait d’une part très fastidieux d’ajouter à la main toutes les couches de ce projet, mais surtout dans cet exemple l’affichage s’adapte automatiquement aux nouvelles couches ajoutées par les divers contributeurs au projet.
Fig. 6: Ajout automatique de toutes les couches fournies par un serveur WMS sur dans un contexte d’OpenLayers2. Le script d’exemple /opt/qgis-server/plugins/HelloServer qui affiche le logo de QGis a été volontairement laissé en place pour distinguer le serveur en production (qgis.sequanux.org) du serveur de tests (127.0.0.1).
Nous avions présenté le flux de traitement permettant de générer une série d’images orthorectifiées et de modèles numériques d’élévation associés avec le souci de comparer ces jeux de données entre eux, mais sans prétention de les positionner dans un référentiel absolu partagé par convention entre plusieurs utilisateurs. Il s’avère [6] que la solution de simplement translater un jeu de données par rapport à l’autre ne suffit plus lorsque la zone considérée s’étend sur plusieurs hectares. Nous avons observé que dans ce cas, le positionnement par GPS (mono-fréquence, telle que fournie sur microdrone DJI Phantom3 Professional) n’est exact qu’à une dizaine de mètres, alors que nous visons un positionnement au décimètre près pour des comparaisons de vols successifs. Il s’avère que vouloir corriger les défauts d’échelle et de position du modèle numérique d’élévation en lui appliquant les corrections permettant de superposer les images orthorectifiées est une approche peu judicieuse, et qu’il vaut mieux insérer dans le flot de traitement l’étape d’exploitation des points de contrôle au sol pour corriger les défauts du modèle de caméra et de leur position (http://forum-micmac.forumprod.com/campari-residuals-differ-from-the-point-cloud-t881.html). Pour notre part, les points de contrôle au sol (GCP) sont acquis a posteriori dans Google Earth – les coordonnées sphériques fournies avec 6 décimales sont précises à 11 cm à l’équateur : 7 points aisément reconnaissables dans les jeux de données sont d’une part identifiée dans Google Earth (bandes de parking, barrière, coin à la base de bâtiments) avec des coordonnées converties de coordonnées sphériques (WGS84) vers un référentiel projeté localement tangent à la Terre (WGS84/UTM31N), et d’autre part leur position (en pixel) identifiée sur les images acquises par drone. Ce couple de fichiers (coordonnées dans l’espace v.s coordonnées sur les photographies) alimente l’outil Campari de Micmac. Après traitement dans ces conditions, nous observons une exactitude de position par rapport aux couches vectorielles de Openstreetmaps mais surtout par rapport à une image aérienne de l’IGN (BD ORTHO, convertie de Lambert93 à WGS84/UTM31N puisque nous avons vu que OpenLayers 2 ne sait pas le faire à la volée) meilleure qu’une vingtaine de centimètres – erreur attribuable à notre manque d’assiduité à pointer les points de contrôle. Ce jeu de données est disponible sur http://qgis.sequanux.org/cgi-bin/project/femto/qgis_mapserv.fcgi.
Fig. 7: Résultat de l’insertion de trois images orthorectifiées, en comparaison de données de référence que sont les images aériennes de la BD ORTHO de l’IGN et les données vectorielles de Opensteetmaps. En haut à gauche : deux images orthorectifiées acquises à 30 minutes d’intervalle positionnées au moyen de 7 GCPs. En haut à droite : le même jeu de données, positionné uniquement par les positions GPS du drone au moment de la prise de vue. Le trait rouge, indiquant la différence de position, est long de 9,8 m. En bas à gauche : superposition d’une image produite par drone (moitié gauche) avec une image IGN (moitié droite). En bas à droite : comparaison de deux orthophotos produites à un mois d’intervalle.
Nous avons proposé un environnement de travail permettant de disséminer des informations géoréférencées soit vers des utilisateurs de logiciels dédiés de gestion de systèmes d’informations géographiques (SIG) ou vers les API Web associées (OpenLayers). Est-ce que ce mode de dissémination est réellement utilisé en pratique ? L’institut polaire norvégien (NPI) propose ses informations dans ce format tel que décrit sur http://geodata.npolar.no/#basemap-services. Ainsi, sous QGis, configurer l’onglet WM(T)S vers http://geodata.npolar.no/arcgis/rest/services/Basisdata/NP_Ortofoto_Svalbard_WMTS_25833/MapServer/WMTS? donne accès aux informations bitmap que sont les photographies aériennes de très haute résolution (jusquà 16 cm/pixel !) tandis que l’url http://geodata.npolar.no/arcgis/services/CryoClim/glaciers/MapServer/WmsServer? dans l’onglet WFS donne accès aux informations vectorielles que sont les limites des glaciers extraites des images satellitaires SPOT.
Le lecteur est encouragé à reproduire ces expériences sur ses propres zones d’intérêt. Compte tenu de la résolution médiocre de Landsat, le résultat est peu convaincant pour la vallée de Chamonix, mais les glaciers groenlandais (Illulisat près de la baie de Disco) ou la banquise antarctique sont parfaitement appropriés à cette démonstration, voir la mer d’Aral sur http://www.nasa.gov/mission_pages/landsat/news/40th-top10-aralsea.html (un peu pénible à assembler car de superficie supérieure à ce que le site de l’USGS permet d’analyser) ou la mer morte sur http://earthobservatory.nasa.gov/IOTD/view.php?id=77592 et pour laquelle l’extension des bassins d’exploitation du sel est particulièrement visible. Le lecteur saura-t-il calculer la surface ainsi affectée ? Indice : tracer un polygone avec l’outil New Shapefile puis dans la table des attributs, créer un nouveau champ pour chaque polygone avec la variable $area.
Une autre voie d’étude qui semble intéressante dans le cadre de la diffusion sur le Web de données géoréférencées est qgis2web, greffon de QGis actuellement inexploitable sous Debian testing/sid compte tenu d’une dépendance cassée. Finalement, étant donné que toutes les informations pertinentes à une utilisation en surface sont disponibles sur OpenStreetMaps, ne serait-il pas temps de commencer à considérer la cartographie des services sous terrains (eau, gaz, électricité), qui même s’ils sont propriété de leurs exploitants respectifs, sont devenus des services nécessaires au quotidien d’un habitant d’Europe occidentale actuel : chaque kilomètre de route contient plusieurs dizaines de kilomètres de services sous terrains [7] qui ne demandent qu’à être cartographiés à l’occasion des ouvertures de routes.
Jean-Michel FRIEDT
[Institut FEMTO-ST, dpt. Temps-fréquence, Besançon]
Émile Carry
[Institut FEMTO-ST, dpt. Temps-fréquence, Besançon]
[1] PIERROT-DESEILLIGNY M. et FRIEDT J.-M, « La photogrammétrie pour tous : MicMac pour la reconstruction 3D de scènes géoréférencées à partir de photographies numériques », tutorial à FOSS4G-fr 2016, décrit sur jmfriedt.free.fr/foss4g_2016
[2] FRIEDT J.-M. Friedt, TOLLE F., et BERNARD É., « Utilisation de Micmac pour la génération de modèle numérique d’élévation par traitement d’images acquises par microdrone », GNU/Linux Magazine France 191, pp.48–57 (Mars 2016)
[3] ERLE S., GIBSON R., et WALSCH J., « Building the geospatial web », dans « Mapping Hacks – Tips & Tools for Electronic Cartography », O’Reilly (2005)
[4] GIBSON R. et ERLE S., « Google Maps Hacks – Tips & Tools for Geographic Searching and Remixing », O’Reilly (2006)
[5] Les divers champs se déduisent de l’analyse de la sortie de wget -O – « http://127.0.0.1/cgi-bin/mon_projet/qgis_mapserv.fcgi?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetCapabilities »
[6] LISEIN J., PINEUX N., PIERROT-DESEILLIGNY, DEGRÉ A., et LEJEUNE P., « Détection de l’érosion dans un bassin versant agricole par comparaison d’images multidates acquises par drone », Colloque Drones et moyens légers aéroportés d’observation, 26/06/2014 (Montpellier), disponible sur http://orbi.ulg.ac.be/handle/2268/171616
[7] Chaque kilomètre de route à Hong-Kong recouvre 47 km de services enterrés, http://www.uti.hk/media/attachments/2nd_ICUMAS_full_paper.pdf ou http://www.scmp.com/news/hong-kong/article/1647088/small-army-utility-specialists-keeps-hongkongers-safe-pipes-cables, ou en d’autres termes il existe 47 câbles, tuyaux, fibres optiques et autres modes de transmission de fluides et d’informations sous chaque route.
J.-P Culas (CM-Drones, Besançon) a effectué les vols au-dessus du parking de FEMTO-ST. Les membres du forum Micmac (http://forum-micmac.forumprod.com/) ont une fois de plus partagé leurs connaissances pour corriger les défaillances dans les traitements que nous proposions initialement.
Retrouvez cet article (et bien d’autres) dans GNU/Linux Magazine n°200, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !
Shawn Powers, 19/07/2017 | Source: Linux Journal
Although they might not be so good for credit cards or floppy disks, magnets are one of those things that always have fascinated me. For the past few years, I've wanted to get a set of the round Zen Magnets to play with—they're sort of like an extra science-y version of LEGOs. Unfortunately, before I was able to purchase any, the US government banned their sale! more>>
Dave Taylor, 18/07/2017 | Source: Linux Journal
In this article, I'm going to tackle a children's game that's extraordinarily complicated, with many variations, and the programming task is going to be quite tricky. Just kidding! Rock Paper Scissors (or RPS, as it's known) is pretty darn easy to simulate because there aren't really many variants or possible outcomes. more>>
Bérénice Allain, 18/07/2017 | Source: Jessica France
L'ANSM, le SNITEM et le G-MED se réuniront le 12 octobre à la CCI de Nantes pour vous présenter les nouvelles exigences et les modalités de mise en œuvre de cette nouvelle réglementation.
8h30-9h : accueil des participants
9h : Introduction par les organisateurs
9H00 – 12h45 :
12h45 : Clôture et mot des organisateurs
L'accès à cette matinée est gratuit et l'inscription obligatoire.
Lieu :
CCI Nantes St-Nazaire - Centre des Salorges, Nantes
16 Quai Ernest Renaud
44100 Nantes
Une retransmission sera proposée à Rennes, précisions à venir.
Organisateurs
Partenaires
Bérénice Allain, 18/07/2017 | Source: Jessica France
Le 23 novembre à Tours, de 9h à 16h00, CAP'TRONIC s'associe au Pôle S2E2 et vous invite à la quatrième édition des "Innovations du Grand Ouest" sur la thématique des composants et fonctions électroniques intégrables.
A cette occasion, venez rencontrer, sur le site de STMicroélectronics Tours une dizaine d'entreprises leaders sur leur marché et découvrir les dernières solutions technologiques sur la thématique des composants et fonctions électroniques intégrables au service de l'autonomie énergétique, de la connectivité et du stockage d'énergie pour des applications stationnaires ou embarquées.
Intervenants & thématiques traitées
Pour les intervenants de cette nouvelle édition, participer aux "Innovations du Grand Ouest", c'est :
Promouvoir vos produits et services innovants
Rencontrer de nouveaux clients, distributeurs et fournisseurs
montrer votre capacité d'innovation
Faire émerger de nouvelles idées
Bénéficier d'une visibilité unique sur la thématique du stockage de l'énergie
Cibles de l'événement :
Electroniciens,
Intégrateurs de solutions,
Industriels,
Utilisateurs potentiels...
Contacts :
Nicolas POUSSET, Responsable technique & pilote des IGO - 02 47 42 49 83
Frédéric CABAS, Marketing & communication - 02 47 42 49 82
redaction, 18/07/2017 | Source: Linux Magazine
Les données géoréférencées, générées par l’auteur ou distribuées par les agences telles que l’ESA (sentinels.copernicus.eu) ou l’USGS (earthexplorer.usgs.gov), sont disséminées au travers d’un service accessible par le Web selon les formats WFS ou WMTS. Ces données sont alors exploitables au travers de logiciels spécialisés tels que QGis, ou de l’API OpenLayers pour être intégrées dans des pages Web.
Tout possesseur de téléphone portable devient en mesure aujourd’hui de produire de la donnée géoréférencée, qu’il s’agisse de photographies numériques ou de traces de parcours pour les données brutes, ou des données issues d’informations géoréférencées acquises. Nous avons par exemple présenté au FOSS4G-fr [1] et dans ces pages [2] la génération de modèles de bâtiments par les photographies géoréférencées prises par téléphone, et leur intégration dans QGis sur fond de carte OpenStreetMaps (OSM).
Obtenir de telles données est bien, mais les partager avec une communauté d’utilisateurs, c’est mieux. Le mode de transmission le plus pratique pour les volumes de données dont il est question est évidemment internet, ne serait-ce que pour centraliser les données partagées en vue de garantir leur cohérence si plusieurs utilisateurs les manipulent.
Trois protocoles de dissémination ont été mis en place à cet effet [3][4] : WM(T)S, WFS et WCS. Le premier dissémine des images représentant les données traitées, avec une résolution adaptée à l’échelle de la carte de l’utilisateur. Ne fournissant qu’une image des informations transmises, il n’est plus possible pour l’utilisateur de s’approprier ou retraiter lui-même des informations. Les deux autres protocoles disséminent les données brutes, vectorielles ou matricielles. Nous nous proposons d’aborder séquentiellement trois problèmes : un serveur de données pour disséminer les informations qui auront été traitées dans QGis (qgis-server) ; la récupération des informations sur un logiciel dédié tel que Qgis pour le traitement des informations ; et finalement la récupération des données dans un client Web pour affichage comme couche OpenLayers. Afin de ne pas faire durer le suspens plus longtemps, le lecteur est encouragé à consulter qgis.sequanux.org/jmfwms.html et jmfriedt.sequanux.org/reproj.html pour se faire une idée du résultat recherché.
Le contexte de notre étude porte sur le retrait de glaciers à front marin en milieu arctique. Les images des satellites Landsat sont acquises depuis les années 1970 et mises à disposition par l’USGS, par exemple sur http://landsatlook.usgs.gov/viewer.html. Elles sont plus ou moins bien géoréférencées (une petite correction est parfois nécessaire, surtout pour les plus anciennes), mais surtout souffrent d’une résolution médiocre (de l’ordre de 30 m/pixel) compte tenu des standards actuels. Plus de 40 ans d’histoire d’images satellites en font néanmoins une source irremplaçable pour appréhender l’évolution des régions qui vont nous intéresser. Notre travail initial sous QGis a été d’importer toutes ces images, les reprojeter dans un référentiel localement plan (WGS84/UTM33N, le référentiel projeté approprié pour le nord de la Norvège tel que nous en informe http://spatialreference.org/ref/epsg/wgs-84-utm-zone-33n/), s’assurer par quelques points de référence que les images sont convenablement positionnées, et dans le cas contraire les repositionner au moyen de 4 ou 5 points de référence sur le pourtour de la région considérée (presqu’île de Brøgger, Svalbard). Ces informations matricielles sont alors utilisées pour tracer manuellement (création d’un shapefile comprenant des lignes) les fronts marins des glaciers, créant ainsi un jeu de données vectorielles. Par ailleurs, un trajet en avion a été enregistré au moyen du récepteur GPS d’un téléphone portable (logiciel OSMTracker sous Android) et nous désirons insérer la séquence de points au format GPX dans nos cartes. Sous QGis, l’opération est triviale (Vector > GPS Tools > Load GPX File) mais pourrons-nous exporter cette information par le Web et l’inclure dans les pages affichées par un navigateur ? Nous verrons que la réponse n’est pas aussi triviale qu’il pourrait paraître.
Fig. 1 :Projet QGis que nous désirons partager au travers d’internet, avec toutes les images sans nuages acquises par Landsat de la presqu’île de Brøgger au Svalbard, et la mesure de position des fronts, illustrant le recul de 4 km en 40 ans du Kongsbreen.
QGis a tout prévu pour nous : un projet QGis s’exporte dans un format accessible par le Web au travers de qgis-server. Le principal exercice va donc porter sur l’installation de cet outil, puisqu’exporter le projet se résume à Project > Projet Properties et activer WMS, WFS et WCS en cochant toutes les couches (Select All) dans les deux derniers cas.
L’installation de qgis-server ne présente aucune difficulté et est décrite parfaitement sur http://docs.qgis.org/testing/en/docs/user_manual/working_with_ogc/ogc_server_support.html. On notera cependant que bien que le service WM(T)S fonctionne convenablement avec des versions plus anciennes de qgis-server, l’export des couches vectorielles (formats WFS et WCS) ne semble pas opérationnel pour les versions précédent 2.12. Nous expérimenterons donc avec une version au moins supérieure à 2.14 de QGis et de son serveur qgis-server. Sous Debian GNU/Linux, cela signifie éviter Wheezy mais travailler dans la version stable à la date de cette rédaction.
À l’issue de l’installation du serveur comme service d’Apache2 (nécessitant le support FCGI fourni par libapache2-mod-fcgid), le bon fonctionnement du service est validé (dans le cas d’une installation locale) par :
$ wget -O - "http://127.0.0.1/cgi-bin/qgis_mapserv.fcgi?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetCapabilities"
La réponse doit être du type :
<Service> <Name>WMS</Name> <!-- Human-readable title for pick lists --> <Title>QGIS mapserver</Title> <!-- Narrative description providing additional information --> <Abstract>A WMS service with QGIS mapserver</Abstract> ...
Le service étant fonctionnel, divers projets QGis (fichier .qgs) sont placés, avec toutes les données associées aux diverses couches du projet, dans des sous-répertoires de /usr/lib/cgi-bin, en complétant avec une copie du serveur Fast-CGI (qgis_mapserv.fcgi).
Attention !
Les liens symboliques entre /usr/lib/cgi-bin et, par exemple, un répertoire utilisateur, ne sont autorisés qu’en modifiant la configuration par défaut de Apache2 sous Debian dans /etc/apache2/conf-available/serve-cgi-bin.conf en remplaçant le + par un – de l’option SymLinksIfOwnerMatch.
Si le projet QGis autorise l’export des couches au format WM(T)S ou WFS, nous validons la capacité à rapatrier ces couches (dans notre cas le projet et ses fichiers se trouvent dans /usr/lib/cgi-bin/project/landsat de qgis.sequanux.org) par :
$ wget -O - "http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi?SERVICE=WFS&VERSION=1.0.0&\ REQUEST=GetCapabilities"
La réponse est la liste des couches accessibles sous la forme :
<WFS_Capabilities xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ... <Service> <Name>WFS</Name> ... <FeatureType> <Name>fronts5</Name> <Title>fronts5</Title> <Abstract></Abstract> <SRS>EPSG:4326</SRS> <Operations> <Query/> </Operations> <LatLongBoundingBox maxx="12.2424" minx="12.103" maxy="79.0268" miny="78.9989"/> </FeatureType> ...
Nous voyons donc que la projection dans laquelle les coordonnées des points formant la couche (ici vectorielle) est renseignée (EPSG:4326 signifie WGS84 en coordonnées sphériques tel que nous l’indique le CRS sous QGis), et l’extension de la couche (autour de 12°E et 79°N).
Ces points sont récupérés – au format GML – par une requête WFS de la forme :
$ wget -O - "http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi?SERVICE=WFS&VERSION=1.0.0&\ REQUEST=GetFeature&typename=fronts5&featureid=fronts5.toto"
La réponse est :
<gml:LineString srsName="EPSG:4326"> <gml:coordinates cs="," ts=" ">12.11525618,79.02193675 12.1224397,79.02118041 12.11728195, 79.01669523 12.11808149,79.0123295 12.12970628,79.00850923 12.14676275,79.00549989 12.16023071,79.00480137 12.16426326,79.00331772 12.16469826,79.00161054 12.17939472,78.99997196 12.18340417,79.00381158 12.20189733, 79.00556583 12.21455655,79.00542793 12.2268052,79.00560265 12.2366082,79.00626179 12.24175315,79.00561112 </gml:coordinates>
Nous avons ici les diverses coordonnées qui forment la ligne d’une des couches vectorielles de notre projet QGis, accessible au travers d’une requête HTML. Ces données sont donc accessibles par la communauté, il reste à en faire un bon usage avec les divers outils à notre disposition. Nous présentons quelques exemples ci-dessous.
Le premier environnement le plus simple pour accéder à ces données est QGis lui même. Dans la barre des icônes de gauche de QGis, les trois icônes en forme de globe proposent l’accès respectivement aux données au format WM(T)S, WCS et WFS. Dans tous les cas, il nous faut renseigner l’url du serveur, par exemple http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi. Lors de la connexion, la liste des couches accessibles est proposée, et cliquer sur une couche suivi de Add donne accès au jeu de données. La seule subtilité dans cette application tient à ne pas utiliser un serveur trop ancien (avant 2.12) sous peine de voir la liste des couches s’afficher, mais une liste vide de points être retournée par les requêtes WFS. WM(T)S semble avoir toujours bien fonctionné (voir figure 2).
Fig. 2: Obtention de couches WM(T)S – images au format bitmap des données (“fronts4”) – et WFS – informations vectorielles (“fronts3”), depuis QGis. Noter le logo de QGis qui est un effet de bord du serveur de test installé par le site web décrivant l’installation de QGis. Effacer /opt/qgis-server/plugins/HelloServer ou tout au moins /opt/qgis-server/plugins/HelloServer/icons/icon.png pour s’affranchir de cet effet.
La portée de notre serveur se retreint encore à un public relativement averti puisque utilisateur de QGis. Nombreuses sont les cartes sur le Web qui ne sont pas destinées à un auditoire de géographes mais simplement pour illustrer un concept à des utilisateurs probablement spécialistes dans d’autres domaines. Afin d’insérer des cartes et les couches générées sous QGis, l’environnement de développement en JavaScript OpenLayers semble idéal puisque fournissant la capacité à charger des couches dans tous les formats qui nous intéressent – WM(T)S, WFS ou GPX pour les traces GPS. Nous avons initialement été sensibilisés à OpenLayers comme environnement de développement pour accéder aux couches fournies par l’IGN au travers de Géoportail. Nous allons dans un premier temps nous intéresser à la version stable d’OpenLayers (version 2) qui semble mature, mais verrons que la nouvelle mouture (version 3) offre des fonctionnalités précieuses qui justifient la migration vers l’environnement en cours de développement.
Une carte OpenLayers est formée d’un appel aux bibliothèques JavaScript (<script>…</script>), la création d’une carte remplie d’un fond par défaut – nous choisissons le fond vectoriel OpenStreeMaps (OSM) – et recouvert de diverses couches additionnelles que nous fournirons depuis qgis-server.
Dans son expression la plus simple, une page OpenLayers ressemble à :
<html>
<head>
<title>Essai de lecture de WMS depuis openlayers</title>
<script src="http://openlayers.org/api/OpenLayers.js"></script>
</head>
<body>
<div style="width:100%;height:100%" id="map"></div>
<script defer="defer" type="text/javascript">
var map=new OpenLayers.Map(’map’);
var wms=new OpenLayers.Layer.WMS("Basic map","http://vmap0.tiles.osgeo.org/wms/vmap0",{layers: ’basic’} );
map.addLayer(wms);
map.setCenter(new OpenLayers.LonLat(12,79),9);
</script>
</body>
</html>Et tant que nous n’insérons que des couches WMS – donc des images (puisque les données, même vectorielles, sont transmises sous forme d’images avec une résolution adaptée au facteur de grossissement), tout se passe bien. Nous pouvons ainsi ajouter une image Landsat accessible sous forme WMS, voir même un des fronts de glacier :
<html>
<head>
<title>Essai de lecture de WMS depuis openlayers</title>
<script src="http://openlayers.org/api/OpenLayers.js"></script>
</head>
<body>
<div style="width:100%;height:100%" id="map"></div>
<script defer="defer" type="text/javascript">
var map=new OpenLayers.Map(’map’);
var wms=new OpenLayers.Layer.WMS("Basic map","http://vmap0.tiles.osgeo.org/wms/vmap0",{layers: ’basic’} );
var dm_wms2013=new OpenLayers.Layer.WMS(
"Landsat image 2013",
"http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi",
{layers: "2013_0830utm33n", transparent:"true", format:"image/png" },
{isBaseLayer: false}
);
var fronts1=new OpenLayers.Layer.WMS(
"Glacier fronts1",
"http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi",
{layers: "fronts4", transparent:"true", format:"image/png"},
{isBaseLayer: false}
);
map.addLayer(wms);
map.setCenter(new OpenLayers.LonLat(12,79),9);
map.addLayer(dm_wms2013);
map.addLayer(fronts1);
</script>
</body>
</html>Le lecteur est encouragé à compléter cet exemple en ajoutant un front additionnel, par exemple la couche nommée fronts5, et observer la conséquence d’échanger l’ordre d’affichage des couches. Ces exemples sont fortement inspirés des excellents tutoriaux fournis par http://demo.3liz.com/wfst/wfs.html.
Pour WFS, le problème se corse : le principe de Same Origin impose que le serveur de données soit sur le même site que le serveur Web. Ceci est valable pour toute donnée vectorielle. Afin d’illustrer ce problème, nous proposons trois sources de données : un même fichier GPX stocké sur jmfriedt.sequanux.org, jmfriedt.free.fr, puis qgis.sequanux.org. Le serveur qgis-serveur fournissant les couches WFS est exécuté comme service Apache2 sur qgis.sequanux.org, tandis que la page Web qui fait appel à ce service peut être placée sur chacun de ces trois serveurs. La figure 3 illustre les interdictions d’accès rencontrées, tel qu’indiqué par Firebug : le fichier GPX stocké sur jmfriedt.sequanux.org peut être lu par la page http://jmfriedt.sequanux.org/jmfwfs.html mais est rejeté par la même page stockée sur http://jmfriedt.free.fr/jmfwfs.html. Cette dernière n’a accès qu’au même fichier GPX placé dans le répertoire du serveur jmfriedt.free.fr.
Fig. 3: Trois illustrations du problème de Same Origin pour se convaincre de la source du problème.
Les exemples de la figure 3 sont obtenus, après la définition de la carte, par l’appel aux couches vectorielles aux formats GPX ou WFS, de la forme :
var lgpxfree = new OpenLayers.Layer.Vector("GPX track free", {
strategies: [new OpenLayers.Strategy.Fixed()],
protocol: new OpenLayers.Protocol.HTTP({
url: "http://jmfriedt.free.fr/May_6,_2016_11;20;10_2016-05-06_11-20-10.gpx",
format: new OpenLayers.Format.GPX()
}),
style: {strokeColor: "red", strokeWidth: 5, strokeOpacity: 0.8}
});
var lgpxsqnx = new OpenLayers.Layer.Vector("GPX track sqnx", {
strategies: [new OpenLayers.Strategy.Fixed()],
protocol: new OpenLayers.Protocol.HTTP({
url: "http://jmfriedt.sequanux.org/May_6,_2016_11;20;10_2016-05-06_11-20-10.gpx",
format: new OpenLayers.Format.GPX()
}),
style: {strokeColor: "green", strokeWidth: 5, strokeOpacity: 0.8}
});
var fronts=new OpenLayers.Layer.Vector("Test WFS", { // WFS
strategies: [new OpenLayers.Strategy.BBOX()],
protocol: new OpenLayers.Protocol.WFS({
url : "http://qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi",
featureType : "fronts5",
}),
});
map.addLayer(wms); map.setCenter(new OpenLayers.LonLat(12,79),9);
map.addLayer(fronts);
map.addLayer(lgpxsqnx);
map.addLayer(lgpxfree);Ce code fait appel au même fichier GPX stocké sur deux serveurs (afin de valider que seule la couche située sur le même serveur que la page Web appelante est acceptable), et la couche nommée fronts5 fournie au format WFS par qgis.sequanux.org/cgi-bin/project/landsat/qgis_mapserv.fcgi.
Fig. 4: En local (127.0.0.1), tout se passe bien, les données et le serveur sont au même endroit. L’intérêt en terme de diffusion reste limité : placer toutes ses données sur le même site que le serveur résout les problèmes de Same Origin (l’exemple de droite est accessible sur qgis.sequanux.org/jmfwms.html).
Ayant dépassé tous les écueils de configuration, nous avons finalement la satisfaction de voir toutes les couches s’afficher sur la même carte, en ajoutant l’onglet de commandes qui permet d’activer ou désactiver chaque couche afin d’aisément comparer la position des fronts des glaciers et leur évolution dans le temps :
var map=new OpenLayers.Map('map');
ls=new OpenLayers.Control.LayerSwitcher({'div':OpenLayers.Util.getElement('layerswitcher')});
map.addControl(ls);
ls.maximizeControl();Il n’aura cependant pas échappé au lecteur que nos images satellites semblent fortement déformées (comparer les figures 1 et 4). Il s’agit ici de la conséquence de la projection de Mercator, qui tend à considérablement grossir l’axe des abscisses lorsque la zone considérée s’éloigne de l’équateur. Quoiqu’acceptable jusqu’à des latitudes de ±60°, l’effet devient vraiment significatif au-delà et carrément désagréable par 79°N. C’est pourquoi les projections locales, tentant de trouver un plan localement tangent à la sphère représentant le globe terrestre, ne prétendent pas à s’appliquer à l’ensemble de la Terre mais uniquement à un petit segment de longitude. Malheureusement, OpenLayers 2 ne supporte pas la reprojection à la volée des données bitmap, nous sommes coincés avec la projection imposée depuis Google Maps qui continue à déformer les pôles. Nous allons remédier à ce problème en passant sous OpenLayers 3 et retrouver ainsi les belles cartes de Qgis.
Jean-Michel FRIEDT
[Institut FEMTO-ST, dpt. Temps-fréquence, Besançon]
Émile Carry
[Institut FEMTO-ST, dpt. Temps-fréquence, Besançon]
La seconde partie de cet article sera publiée prochainement sur le blog, restez connectés
Retrouvez cet article (et bien d’autres) dans GNU/Linux Magazine n°200, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !
James Gray, 17/07/2017 | Source: Linux Journal
Mobile advertising campaigns today are often hampered by broken, non-viewable ads with a poor UX experience. An important open-source initiative aimed at solving this problem and making the web better for all is the AMP Project, which enables the creation of websites and ads that are consistently fast, beautiful and high-performing across devices and distribution platforms. more>>
Margaux Sancy, 17/07/2017 | Source: Jessica France
Créateur d'objets électroniques connectés ou non, venez comprendre les contraintes liées à l'industrialisation et à la conception.
Cette formation sera centrée sur la conception et l'industrialisation des produits électroniques et vous permettra de comprendre clairement les enjeux qui y sont liés afin d'appliquer les bonnes pratiques.
Partie sur le Cycle de vie
développement produit
la faisabilité technico-économique
Partie Conception
la méthodologie de travail, le phasage des étapes, les bonnes pratiques
(et les mauvaises à éviter), les process techniques/technologiques selon les différents métiers (mécanique, électronique, tests, logiciel)
les points à considérer (banc de test, assemblage,...), le design "To cost", les aspects normatifs, le design du boîtier
Partie Industrialisation
les process de fabrication, les étapes nécessaires pour garantir la qualité (câblage, tests, bancs de test etc.)
la méthodologie de travail, le phasage des étapes, les bonnes pratiques
(et les mauvaises à éviter) associés à la conception produit
les maquettes, prototypes, les essais associés, la préparation et réalisation des préséries et séries, les aspects SAV et qualité
Lundi 6 novembre : 8h30-18h00
CYCLE DE VIE D'UN NOUVEAU PRODUIT
Cycle de vie d'un projet (phasage, délais etc.)
L'Innovation
Définition du besoin Client Exemples
FAISABILITÉ TECHNICO-ECONOMIQUE
Synoptique, méthodologie, outils de faisabilité
Faisabilité technico-économique (état de l'art, risques etc.)
Cahier des charges technico-fonctionnel (réponse au CDC Client,
compétences requises)
Preuve de concept (validation par démonstrateur, Fab Labs)
Sourcing prestataires/partenaires (R&D, industrialisation)
Qualification et choix prestataires/partenaires (considérations qualitatives)
Proposition technico-économique R&D/industrialisation (métriques)
Budget R&D/industrialisation/outillages
Prix de revient produit
Planning R&D/industrialisation/outillages
ROI (retour sur investissements)
GO - NO GO
Exemples
L'INDUSTRIALISATION MÉTIER ET SON PROCESS
(mécanique/plasturgie) : Process d'industrialisation mécanique/plasturgie (conception/réalisation outillage, directives, paramètres, tests, retouches, validations, coûts, délais)
Mardi 7 novembre : 8h30-18h00
L'INDUSTRIALISATION MÉTIER ET SON PROCESS
(électronique, assemblage, tests) :
Process d'industrialisation des cartes électroniques
(appros, conception/réalisation outillage, directives, paramètres, tests, retouches, validations, coûts, délais) Process d'Industrialisation assemblage/tests (conception/réalisation outillage, directives, paramètres, tests, validations, coûts, délais)
CONCEPTION
(démarrer la conception vers les prototypes) :
Ingénierie simultanée (bien du 1er coup, penser process dès la conception)
Contrats de prestation R&D/Industrialisation
Synoptique, Méthodologie, Outils de conception
Conception générale multi-métiers (mécanique/plasturgie,
électronique, logiciel embarqué et applicatif, tests)
Design To cost (conception à coût objectif - prix de revient cible)
Les choix (technologiques, composants, assemblage, tests)
Les directives de conception par métiers
Design To manufacturing (contraintes de fabrication)
Design To test (contraintes de test)
Les contraintes normatives, certification
Conception détaillée par métiers (mécanique/plasturgie, électronique,
logiciel embarqué) : les outils, méthodologie, documents, ...
Maquettes (run 1 hardware/mécanique, code source)
Evaluation technique (mesures, fonctions, essais , CEM, ...)
Exemples
L'INDUSTRIALISATION D'UN PRODUIT ELECTRONIQUE
(intégrer les process/technos dès la conception) :
Ingénierie simultanée (bien du 1er coup, penser process dès la conception) Choix technologiques et Conception
Méthodologie
Prototypes (run 2 hardware/mécanique, logiciel embarqué, assemblage,
intégration, mises au point, tests)
Qualification/certifications (validations techniques/normatives par
rapport au CDC)
Lancement présérie industrielle (validation process, outillages, prix de
revient) Lancement fabrication série (stratégie industrielle et logistique)
Le SAV (REX,…)
LES ÉTAPES NÉCESSAIRES POUR GARANTIR LA QUALITÉ
Projet d'ensemble, analyse fonctionnelle
Choix et directives technologiques
Choix et validation prestataires
Validations de phases avec les prestataires
Validation de prototypes
validation de process en Présérie
Lieu de l'événement :
Maison de la Salle
78A Rue de Sèvres
75007 Paris
Participation aux frais
Prix préférentiel pour les adhérents CAP'TRONIC : 700 € HT par personne pour les 2 jours Pour les grandes entreprises et les PME qui ne souhaitent pas adhérer : 900 € HT par personne pour les 2 jours
Si vous êtes une PME non adhérente :
Vous pouvez adhérer à l'association JESSICA France. Pour cela contacter Florence CAGNARD
Modalités d'adhésion
Remarque : Jessica France est titulaire d'un numéro d'agrément de formation continue. La prise en charge de cette formation est donc possible par les Organismes Paritaires Collecteurs Agréés (OPCA) mais attention, l'étude de votre dossier peut prendre plusieurs semaines, renseignez-vous dès maintenant et inscrivez-vous au plus tôt.
Places limitées à 10 personnes
Contact :
Christophe Bricout - 09 52 73 77 88
bricout@captronic.fr
crédit image Designed by Freepik
Aline Hof, 17/07/2017 | Source: Linux Magazine
La téléphonie mobile connaît un essor absolument incroyable. Qui aurait parié en 2005, au moment du rachat d’une startup du nom d’Android, que 10 ans après il serait possible d’avoir dans sa poche un smartphone à 6 processeurs ? Les smartphones actuels ont nettement dépassé le concept même de la téléphonie, la partie téléphonie n’est qu’un composant parmi d’autres, l’utilisation de nombreux capteurs a radicalement changé les développements logiciels. Pourquoi ce changement ? Tout d’abord, la simplification des API a permis à de nombreux développeurs d’intégrer des capteurs dans leur application alors qu’il n’y a encore pas si longtemps il fallait avoir des bagages en électronique pour mettre en œuvre de tels logiciels. Sous Android, les couches d’abstraction logicielle ont permis de s’affranchir de nombreuses difficultés de portage, ainsi une application fonctionne aussi bien sur une tablette que sur un smartphone. Avec ce principe, Google a fait table rase et a redistribué les cartes. Ce sérieux dépoussiérage a révélé de nouveaux concepts dans le domaine du logiciel embarqué lié à la téléphonie avec l’utilisation de nombreux capteurs : accéléromètre, gyromètre, GPS, capteur de luminosité, de pression, de proximité, NFC… D’autres concepts sont alors apparus avec les capteurs composites, mélange d’informatique et d’électronique. Nous sommes dans la virtualisation des capteurs électroniques. Le résultat est époustouflant ! De nouvelles gammes de logiciels sont alors à portée de main, et le développeur peut encore exercer son imagination pour intégrer ces techniques dans des applications d’une diversité incroyable !
Dans ce numéro, qui sera une version « avancée » du hors-série n°82 « Créez votre première application Android » (nous vous conseillons de vous référer à ce hors-série si vous n’avez jamais installé le SDK Android ou utilisé Android Studio), nous allons découvrir avec des exemples concrets et didactiques la mise en œuvre de ces capteurs au travers d’une application de géocaching qui utilise les capteurs suivants : accéléromètre, gyromètre, magnétomètre, NFC, GPS, et capteur composite. Nous aborderons également la communication Bluetooth et SMS pour réaliser des communications en P2P et longues distances. Dans cette phase de développement, nous passerons en revue les concepts essentiels afin que vous puissiez intégrer facilement les capteurs de la plateforme dans vos propres applications, même celles déjà existantes. L’intérêt des capteurs, c’est qu’ils donnent « vie » aux applications, car ils sont en quelque sorte le liant entre le monde physique et le monde du virtuel et de l’impalpable que sont les logiciels. Les cas d’utilisation sont vastes, le challenge reste alors de trouver l’idée originale qui fera de votre application un véritable best-seller ! Si vous avez une idée sur ce sujet depuis longue date, ce hors-série vous propose maintenant de passer à l’action…
En parlant de best-seller, pourquoi ne pas tester la popularité de votre application tout en rémunérant vos heures de développement ? Dans une seconde étape de ce hors-série, nous allons découvrir les différentes étapes de monétisation de votre application sur le store Google Play. Les stores de téléphonie mobile proposent aujourd’hui aux développeurs des opportunités invraisemblables de diffusion logicielle au niveau international en à peine quelques clics (ou presque…). Bien sûr, cette étape doit faire l’objet d’une attention particulière comme l’internationalisation de l’application, l’optimisation des codes, la protection de votre application, autant de sujets qui vont assurer le succès de la diffusion. Les stores ont imposé une grande compétition et, pour s’en apercevoir, il suffit de consulter notamment Google Play pour un type d’application : le choix est pléthorique. N’hésitez pas à devenir un compétiteur international ! C’est parfois juste l’originalité de vos développements qui fera la différence et qui vous rendra riche ! Mais avant de passer par la case « cash », découvrons ensemble les capteurs de votre smartphone…
Pour Adèle.
Frédéric Camps
aline, 14/07/2017 | Source: Editions Diamond
Nous serons fermés pour congés annuels du 14 juillet au 7 août. Les commandes de magazines effectuées depuis notre site seront traitées à notre retour, mais il sera bien évidemment toujours possible de vous abonner/réabonner à vos magazines favoris durant cette période.
Nous vous souhaitons à tous un très bel été :-)
aline, 14/07/2017 | Source: Editions Diamond
Le tout nouveau hors-série du magazine est consacré à la ligne de commandes. Sous la forme de mémos puis de recettes, vous apprendrez l’essentiel pour exploiter le shell et tirer le meilleur de votre système ! La partie introductive de ce guide spécial reviendra sur les principes de fonctionnement du terminal afin de pouvoir prendre en main celui-ci. Vous découvrirez ensuite les bases indispensables pour maîtriser le shell et créer vos premiers scripts et pourrez finalement passer à la pratique grâce aux 15 recettes incluses dans ce numéro ! Ce hors-série vous attend dès demain chez votre marchand de journaux, mais aussi sur notre boutique et notre plateforme de lecture en ligne Connect.
Introduction
p.08 Qu’est-ce qu’un « Shell » ?
Mémo
p.20 Mémo 1 : Le système de fichiers
p.36 Mémo 2 : Le mécanisme d’interprétation du shell
p.52 Mémo 3 : Le traitement de flux de données
Recettes
p.76 Mieux connaître son système
p.80 Inspectez les journaux système
p.85 Créer un service système
p.89 Planifier ses tâches
p.92 Lancer des opérations en tâches de fond
p.94 Exécuter un programme interactif à distance
p.97 Sécuriser son serveur en appliquant des règles firewall
p.102 Détecter les éventuelles menaces présentes dans vos fichiers téléchargés
p.106 Monter des fichiers ISO et créer des espaces de fichiers sur RAM
p.109 Gérer ses environnements de travail
p.112 Synchroniser deux répertoires
p.115 Écouter de la musique depuis son terminal
p.117 Renommer ses photos grâce aux métadonnées
p.120 Convertir ses images par lots
p.123 Générer des galeries d’images avec mise à jour automatique
Aline Hof, 14/07/2017 | Source: Linux Magazine
Ce nouveau guide de GNU/Linux Magazine vous propose de découvrir pas à pas comment créer, publier et monétiser votre application Android. À travers ses quatre parties, vous prendrez connaissance des étapes à suivre pour créer votre projet – ici, c’est un projet complet de développement d’une application de géocaching qui vous servira d’exemple -, apprendrez à manipuler les capteurs/périphériques de votre smartphone, à utiliser le Bluetooth et les SMS pour communiquer… Enfin, la dernière étape vous fournira les clés nécessaires pour publier et monétiser votre application sur le store Google Play. Ce nouveau hors-série vous attend en kiosque dès demain, mais aussi sur notre boutique en ligne ainsi que sur notre plateforme de lecture en ligne Connect !
1. PROGRAMMEZ les étapes à suivre pour créer un projet structuré
p. 08 Écrivez votre premier script « Shell »
2. MANIPULEZ les capteurs/périphériques de votre smartphone : accéléromètre, magnétomètre, NFC, GPS, etc.
p. 16 Découvrez les capteurs de votre smartphone
p. 24 Comment intégrer des capteurs dans une application ?
p. 40 Utilisez des tags NFC
p. 52 Localisez les caches à l’aide de leurs coordonnées GPS et stockez l’information
3. COMMUNIQUEZ en Bluetooth et par SMS pour partager des caches et les afficher sur des cartes Google Maps
p. 64 Communiquez en Bluetooth
p. 80 Envoyez des SMS et utilisez l’API Google Maps pour afficher des cartes
4. PUBLIEZ & MONÉTISEZ votre application sur Google Play, rendez-la payante et/ou insérez-y de la publicité
p. 92 Préparez votre application pour le store
p. 106 Internationnalisez votre application et touchez le plus de monde possible
p. 110 Diffusez votre application sur Google Play
p. 118 Gagnez de l’argent ! Beaucoup d’argent… ?
aline, 14/07/2017 | Source: Editions Diamond
Ce nouveau guide de GNU/Linux Magazine vous propose de découvrir pas à pas comment créer, publier et monétiser votre application Android. À travers ses quatre parties, vous prendrez connaissance des étapes à suivre pour créer votre projet – ici, c’est un projet complet de développement d’une application de géocaching qui vous servira d’exemple -, apprendrez à manipuler les capteurs/périphériques de votre smartphone, à utiliser le Bluetooth et les SMS pour communiquer… Enfin, la dernière étape vous fournira les clés nécessaires pour publier et monétiser votre application sur le store Google Play. Ce nouveau hors-série vous attend en kiosque dès demain, mais aussi sur notre boutique en ligne ainsi que sur notre plateforme de lecture en ligne Connect !
1. PROGRAMMEZ les étapes à suivre pour créer un projet structuré
p. 08 Écrivez votre premier script « Shell »
2. MANIPULEZ les capteurs/périphériques de votre smartphone : accéléromètre, magnétomètre, NFC, GPS, etc.
p. 16 Découvrez les capteurs de votre smartphone
p. 24 Comment intégrer des capteurs dans une application ?
p. 40 Utilisez des tags NFC
p. 52 Localisez les caches à l’aide de leurs coordonnées GPS et stockez l’information
3. COMMUNIQUEZ en Bluetooth et par SMS pour partager des caches et les afficher sur des cartes Google Maps
p. 64 Communiquez en Bluetooth
p. 80 Envoyez des SMS et utilisez l’API Google Maps pour afficher des cartes
4. PUBLIEZ & MONÉTISEZ votre application sur Google Play, rendez-la payante et/ou insérez-y de la publicité
p. 92 Préparez votre application pour le store
p. 106 Internationnalisez votre application et touchez le plus de monde possible
p. 110 Diffusez votre application sur Google Play
p. 118 Gagnez de l’argent ! Beaucoup d’argent… ?
Shawn Powers, 13/07/2017 | Source: Linux Journal
Last weekend my work phone suddenly stopped working. Not the phone itself, but rather all service stopped. I first noticed (of course) due to an inability to load any web pages. Then I tried calling someone and realized my phone was disconnected. In fact, when someone tried to call me, it said the line was no longer in service. more>>
Sébastien Salas, 13/07/2017 | Source: Jessica France
L'électronique flexible et imprimée est une technologie de rupture : des fonctions plus ou moins complexes (imprimées ou hybrides) réalisées avec des matériaux organiques (carbone, hydrogène) ou inorganiques sur des substrats flexibles ou rigides (verre, papier) en utilisant des encres conductrices déposées par des techniques d'impression traditionnelles (déroulé ou feuille à feuille) sur de grandes surfaces. Le rapport coût/performance de cette nouvelle technologie la rend très attractive.
Les nombreuses applications envisagées (avec de nouvelles fonctions qui ne peuvent être réalisées qu'en électronique imprimée) en font un champ de recherche majeur. Finesse, légèreté, solidité, flexibilité, conformabilité font que cette technologie s'intègre facilement aux systèmes existants.
Les applications sont multiples : aéronautique, automobile, industrie, bâtiment, médical, textile, emballage…
En partenariat avec l'association AFELIM, le pôle Aerospace Valley et Cap'tronic vous propose une rencontre autour de l'électronique imprimée au sein de la plateforme Elorprinttec afin de découvrir cette filière et les multiples applications possibles pour vos produits.
Objectif : Faire un tour d'horizon des différents maillons de la chaîne : innovations, formulations, impressions, afin d'identifier les applications possibles.
13h30 Accueil des participants
14h00 Accueil CAPTRONIC et pôle Aerospace Valley (AESE)
Présentation AFELIM, association française de l'électronique imprimée par Anne-Lise MARECHAL, Délégué Général
L'électronique imprimée sur substrat souple : une opportunité pour l'innovation par le CEA Tech
Les encres techniques, caractéristiques, mises en œuvre et domaines applicatifs
par Rémi Vie, Business Development, Chemical Engineer, VFP Ink Technologies
La partie impression dans le process de l'électronique imprimée par Nicolas BERNARDIN, Business Development - CERADROP MGI
Le rôle des capteurs en électronique organique et imprimée par Carlo GUARESCHI, Business Development - ISORG
La plateforme ELORPRINTTEC : les moyens, les axes de recherche et les applications
Témoignage de la société I2S
Date et lieu : Jeudi 20 septembre 2017 de 14h00 à 17h40 – Bordeaux
Prix : Gratuit, les frais de cette journée sont pris en charge par Cap'tronic
Contact : roubeix@captronic.fr au 05 57 02 09 62
Sébastien Salas, 13/07/2017 | Source: Jessica France
La Plastronique est une discipline émergeante qui ouvre une nouvelle dimension à l'industrie électronique, apportant de l'intelligence aux pièces de packaging ou structure.
Les technologies, dans ce domaine, combinent des supports solides (e.g. thermoplastique) ou flexibles avec des circuits électroniques sur une seule pièce “électronique – plastique”.
La présence de pistes conductrices et potentiellement de composants électroniques directement sur un support ou un packaging “electronique-plastique” peut éliminer le besoin de carte électronique complémentaire, d'interconnexions ou éventuellement de câbles, résultant ainsi en des dispositifs plus petits, plus légers et plus intelligents.
Cet évènement, organisé par Aerospace Valley en partenariat avec Captronic, l'Ecole d'Ingénieurs Icam, la Société S2P (Smart plastic products) et le Centre Technique Industriel de la Plasturgie et des Composites - IPC, a pour objectif de proposer des technologies innovantes utilisables dès aujourd'hui dans les dispositifs embarqués et les objets connectés…
Introduction par le pôle Aerospace Valley (AESE) et l'ICAM
Plastronique : De la théorie à la pratique, principes & état de l'art des technologies
Keynote : MINT, Chaire d'Excellence Industrielle pour la Plastronique
Techniques / technologies pour « smart packaging/structure »
LDS « Laser Direct Structuring »
conception, fabrication, assemblage et report composants électr.)
IML « In Mold Labelling »
Composites intelligents : un levier essentiel pour relever les challenges à venir
Impression jet d'encre pour structure composite intelligente
Technologie additive sur plastique et composite
Applications, orientations et échanges sur les besoins industriels
L'inscription est gratuite, mais obligatoire avant le 06 Septembre 2017.
Merci de vous inscrire en cliquant sur le lien ici
Date et lieu : Mercredi 20 septembre 2017 de 8h30 à 17h30 – ICAM Toulouse 75 Avenue de Grande Bretagne
Contact : Sébastien SALAS, salas@captronic.fr
James Gray, 12/07/2017 | Source: Linux Journal
The contemporary data center is typified by an ever-increasing amount of traffic occurring between servers, observes Applied Expert Systems, Inc. (AES), sagely. Fulfilling the logical need to facilitate improved server-to-server communications, AES created CleverView for TCP/IP on Linux, now at v2.7. CleverView provides IT staff access to current and more>>
Maxime Chevallier, 12/07/2017 | Source: Linux Embedded
La gestion de l’énergie sur un système informatique est l’une des préoccupations principales de ces dernières années. Tous les domaines de l’informatique sont concernés, allant des systèmes embarqués très basse consommation jusqu’aux fermes de serveurs en passant par les PC de bureau et les ordinateurs portables.
Lorsque l’on cherche à gérer l’énergie depuis la couche logicielle, tout devient affaire de compromis. Chaque action entreprise pour économiser de l’énergie va avoir des répercussions sur les performances du système. A l’inverse, optimiser les performances, ou imposer des contraintes de latence va souvent se faire au détriment de la consommation énergétique.
Les systèmes nécessitant du temps-réel sous Linux vont devoir tenir compte de leurs paramètres de power-management pour éviter de mauvaises surprises liées aux endormissements intempestifs de leur périphériques.
Cet article abordera les différents frameworks et sous-systèmes proposés par le noyau Linux pour piloter la consommation énergétique d’un système, du côté noyau et espace utilisateur, en mettant le doigt sur les problématiques associées à chaque sous-système.
Beaucoup de constructeurs de matériels implémentent des modes avancés de power-management dans leurs produits. Les frameworks du noyau ont pour rôle de mettre à disposition des mécanismes permettant à la fois de supporter au mieux ces modes, mais aussi de proposer une interface générique à l’utilisateur et aux développeurs de drivers.
Étant donné la proximité avec le matériel, les frameworks de power-management sont pour la plupart légers, avec une interface très simple, laissant beaucoup de liberté au développeurs de drivers pour implémenter les mécanismes spécifiques à chaque matériel.
Par ailleurs, les sous-systèmes liés au power-management restent au maximum transparents pour l’utilisateur. En ce qui concerne le power-management dynamique, l’espace utilisateur va simplement pouvoir donner les “grandes lignes” de la politique de power-management, en indiquant au noyau de privilégier soit les performances et faibles latences, soit l’économie d’énergie.
Nous constaterons cependant que plus les techniques mises en place pour le power-management sont agressives, plus l’utilisateur devra intervenir pour les utiliser. Ainsi, les entrées en modes d’endormissement ne se font que sur ordre de l’espace utilisateur.
Le power-management dynamique regroupe toutes les techniques permettant de contrôler la consommation énergétique pendant que le système est actif et que les processus en espace utilisateur tournent. Il s’agit d’être transparent pour l’espace utilisateur tout en lui laissant la possibilité de spécifier ses contraintes.
Le power-management dynamique est une partie du sous-système de power-management de Linux, appelé le ‘PM core’. Le PM core s’interface avec le reste des sous-systèmes et drivers par l’intermédiaire de callbacks, appelées par le core PM, et de fonctions dites “helper” implémentées par le core PM et appelées par les drivers et sous-systèmes.
Les callbacks sont le plus souvent stockées dans le sous-systèmes au sein d’une structure dédiée, souvent appelée `pm_ops`. Toutes les mentions aux `pm_ops` dans la suite de cet article feront référence aux callbacks de power-management.
On retrouve principalement ces `pm_ops` dans les drivers de périphériques, lorsque ceux-ci permettent d’économiser de l’énergie par rapport à leur fonctionnement nominal. On les retrouve aussi dans les drivers de bus, ou encore dans les pilotes génériques implémentant des protocoles et systèmes de fichiers. De cette manière, la plupart des composants du noyau peuvent être informés des différentes mesures de power-management appliquées et réagir en conséquence.
Le framework runtime_pm est la partie du PM core dédiée au power-management dynamique.
Ce framework permet à différents sous-systèmes et drivers du noyau de définir un ensemble de callbacks, préfixées par ‘runtime_’, qui seront appelées par le noyau lorsque nécessaire.
Lorsque le périphérique n’est plus utilisé par aucun composant du système, celui-ci peut alors être mis dans un mode dit “suspended”, dans lequel il est garanti que le driver ne sera pas utilisé avant la sortie de ce mode (callback runtime_resume).
La détection de l’utilisation d’un périphérique se fait par comptage de références, ainsi que par la gestion de la hiérarchie.
L’interface étant relativement simple, nous pouvons nous attarder sur les 3 principales callbacks proposées par le framework :
/** * Cette callback est appelée lorsque le sous-système PM décide que le * périphérique n'est plus activement utilisé. Si cet appel retourne avec * succès, le périphérique ne doit plus interagir avec le système tant que la * callback runtime_resume n'a pas été appelée. */ int runtime_suspend(struct device *dev) /** * Cette callback est appelée lorsque le système veut accéder à ce périphérique * alors qu'il est 'suspended'. Le périphérique doit retourner dans un état * fonctionnel après cet appel. */ int runtime_resume(struct device *dev) /** * Cette callback est appelée lorsque le périphérique n'est plus utilisé, en se * basant sur le compteur d'utilisations du périphérique, ainsi que sur le nombre * d'enfants actifs. L'action effectuée par cette callback est entièrement définie * par le driver, dans la plupart des cas il s'agit d'un appel à runtime_suspend. */ int runtime_idle(struct device *dev)
Certains drivers enregistrent également des timers d’autosuspend, qui vont déclencher l’appel de la callback ‘runtime_suspend’ si aucune activité n’est détectée sur ce périphérique avant l’expiration du timer.
Un domaine de power management (PM domain) représente un ensemble de sous-systèmes alimentés par les mêmes tensions et horloges. Ainsi, lorsque tous les périphériques liés à un domaine sont inutilisés, il peut être intéressant de changer les fréquences et tensions afin d’économiser davantage d’énergie.
Ce genre de “cluster” de sous-systèmes se retrouve surtout sur les SoC, où ils peuvent être assez complexes, avec des relations de parent-enfant. Le framework PM Core inclut la gestion des domaines et des sous-domaines, et tient compte des informations remontées par le framework QoS.
Dans la plupart des cas, les domaines sont décrits directement dans le device-tree grâce à un binding prévu à cet effet.
Les domaines sont gérés par le noyau grâce à un sous-système dédié dans le PM core, qui va suivre l’état des différents périphériques liés à ce domaine et potentiellement couper l’alimentation des horloges du domaine lorsque tous les périphériques sont “suspended”.
L’un des composants les plus gourmands d’un système est paradoxalement celui qui passe la plus grande partie de son temps à ne rien faire : le CPU. Le CPU est particulier, car il est très souvent sollicité pour de courtes périodes. Il est rare de trouver un système sur lequel le CPU est en permanence sollicité 100% du temps. Plusieurs fois par seconde, il va devoir être pleinement opérationnel pour exécuter les programmes qui ont besoin de tourner, puis se rendormir dans un état de sommeil léger, dit “Idle”, caractérisé par un arrêt de l’exécution des instructions, une plus faible consommation, mais aussi une latence de sortie plus ou moins grande avant de revenir à un état fonctionnel.
Les CPUs modernes possèdent plusieurs modes idle, quelques-uns pour les cœurs ARM, jusqu’à une dizaine pour certains x86. Chaque mode est caractérisé par 3 attributs :
Un mode est souvent appelé “C-state”, en référence au nom de ces états dans la norme ACPI. Le mode nominal du CPU lorsqu’il est pleinement opérationnel est l’état C0. Les états vont alors en s’incrémentant, chaque état éteignant davantage de composants internes du CPU, pour de plus grandes économies d’énergie mais une plus grande latence de réveil.
Pour exemple, voici la liste des C-states supportés par Linux pour un Intel i5-5300U, avec leurs latences de réveil respectives :
Sur plateformes ARM, on ne retrouve en général qu’un ou deux C-states. Par défaut, ARM propose l’état WFI (Wait For Interrupt), qui va mettre le CPU en état low-power et couper certaines horloges jusqu’à la prochaine interruption, comme expliqué sur ce document édité par ARM. Certains SoCs ARM implémentent d’autres états supplémentaires, comme les exynos de Samsung.
L’outil `powertop` permet de consulter les C-states supportés par chaque cœur, package et socket de votre CPU. Vous pourrez y trouver le pourcentage de temps passé dans chaque état.
Il est possible de consulter les C-states de votre CPU supportés par votre système en parcourant l’interface sysfs du framework cpuidle :
# Chaque répertoire dans /sys/devices/system/cpu/cpuX/cpuidle/ correspond à un # C-state supporté pour ce CPU. :~$ ls /sys/devices/system/cpu/cpu0/cpuidle/ state0 state1 state2 state3 state4 state5 state6 state7 state8 # Dans chaque répertoire, les informations suivantes peuvent être trouvées : ls /sys/devices/system/cpu/cpu0/cpuidle/state0/ desc disable latency name power residency time usage
Parmi les attributs relatifs à un C-state, on retrouve :
Le concept de “governor” se retrouve dans plusieurs sous-systèmes du noyau. Il s’agit d’un composant logiciel modulaire qui implémente un algorithme devant faire un choix entre plusieurs états, implémentés dans des drivers d’états. Le fait d’utiliser un composant modulaire permet de changer de governor à la volée, ce qui est utile pour le cas de cpuidle, car le governor implémente l’algorithme qui se charge de choisir le C-state dans lequel entrer.
Lorsque le scheduler n’a plus de tâche à exécuter sur un CPU, il va demander au framework cpuidle de mettre le CPU en état d’endormissement. Cpuidle va alors demander au governor actuel de choisir l’état cible en appelant la callback `select()`. La callback `enter()` de l’état choisi est ensuite appelée, mais rien ne garantit que c’est réellement cet état qui sera appliqué. En effet, le CPU lui-même peut avoir accès à d’autres heuristiques implémentées matériellement et choisir un autre état.
Afin de choisir pertinemment un C-state, il est important d’avoir une estimation fiable du temps durant lequel le CPU va rester idle. Il est assez simple d’estimer le temps avant le prochain timer tick (les évènements de scheduling), il est en revanche beaucoup plus difficile d’estimer quand arriveront des interruptions externes.
C’est pourquoi après que le CPU ait effectué son temps en idle, le framework cpuidle va appeler la callback `reflect()` du governor avec en paramètre le temps réel passé endormi, afin que le governor puisse ajuster ses heuristiques et tenir compte des conditions actuelles du système, par exemple en détectant que beaucoup d’interruptions sont actuellement levées.
Nous avons vu que le sous-système cpuidle contrôle l’état du CPU lorsqu’il ne fait rien. Il existe également le sous-système cpufreq qui contrôle l’état du CPU lorsqu’il exécute quelque chose. En particulier, il convient de régler la bonne fréquence (frequency scaling) et d’adapter dynamiquement la tension d’alimentation (dynamic voltage) afin que le CPU puisse effectuer toutes ses tâches, tout en réduisant l’énergie consommée.
Cela peut aussi s’appliquer à d’autres périphériques, tels que la RAM, le GPU et de manière générale, tout ce qui est piloté par des tensions et fréquences que l’on peut contrôler depuis l’OS.
Les Operating Performance Points (OPP) sont des tuples [fréquence,tension] permettant de représenter les différents paramètres acceptés par les périphériques.
En effet, la fréquence d’une horloge ne se contrôle pas de manière continue et changer la fréquence de fonctionnement implique le plus souvent de changer la tension d’alimentation du composant.
Les OPP permettent une représentation générique de ces points au sein du noyau, peuvent être ajoutés/retirés dynamiquement et consultés par les drivers qui vont les utiliser. On trouve notamment des liaisons dans le device-tree permettant de donner une correspondance entre les points génériques du noyau et les OPP spécifique au processeur ( voir la documentation du noyau )
CPU Freq met en œuvre le DVFS pour le contrôle du CPU, en se basant sur une listed’OPP spécifique au CPU.
Certains CPU vont directement implémenter matériellement le changement d’OPP (on parle alors de P-states, selon la norme ACPI). Dans ce cas, l’OS peut simplement définir les bornes supérieures et inférieures des fréquences pouvant être utilisées par le CPU. On parle alors de ‘policy’.
Le choix de l’OPP se fait en utilsant des governors, de manière similaire à cpuidle.
Linux propose plusieurs governors, plus ou moins intelligents :
L’outil `powertop` vous permet aussi de voir à quelles fréquences vos périphériques fonctionnent et de visualiser le pourcentage d’utilisation des différents OPP :
Les techniques de PM dynamiques peuvent influer directement des composants critiques du système tels que le CPU, les fréquences de certains bus, ou encore les périphériques d’entrée/sortie. Cela peut introduire des latences inacceptables pour l’utilisateur final, mais aussi pour certains périphériques.
L’espace utilisateur, mais aussi certains drivers peuvent exprimer des contraintes de latences, de débit, ou encore interdire à certains sous-systèmes d’entrer en mode lowpower grâce au framework Quality of Service (QoS).
Les classes QoS sont des paramètres globaux, pouvant être contrôlés par les drivers ainsi que par l’espace utilisateur. Ces paramètres sont pris en compte par les drivers et les frameworks liés au PM.
Parmi ces classes, on trouve :
Plusieurs sources peuvent spécifier une valeur minimale pour chaque classe. Le framework QoS va s’occuper de calculer une valeur agrégée pour chaque paramètre qui sera la valeur cible globale. Ces valeurs ont une grande importance pour le power management, car elles vont permettre de limiter l’agressivité de l’économie d’énergie.
En plus des classes, le framework QoS permet d’attacher des attributs de QoS à chaque composant. Actuellement, trois attributs sont proposés :
La gestion de la consommation électrique impacte aussi l’emission de chaleur par le système. Il peut être nécessaire de limiter volontairement les performances afin de satisfaire aux contraintes de température, notamment sur un système qui refroidit passivement.
Le sous-système ‘thermal’ permet de gérer différents profils thermiques, qui s’activent lorsque certaines conditions de température sont rencontrées.
Chaque profil peut définir une méthode de refroidissement à utiliser lorsque la température cible est atteinte. Il peut s’agir d’activer un ventilateur, ou bien d’utiliser cpufreq pour limiter la fréquence de fonctionnement du système.
Vous pouvez consulter les différents profils thermiques avec l’interface sysfs :
:~$ find /sys/class/thermal/ /sys/class/thermal/ /sys/class/thermal/cooling_device0 /sys/class/thermal/cooling_device1 /sys/class/thermal/cooling_device2 /sys/class/thermal/cooling_device3 /sys/class/thermal/thermal_zone0 /sys/class/thermal/thermal_zone1
Un ‘cooling_device’ représente une instance d’un périphérique permettant d’influer sur la température du CPU. Par exemple, cette instance peut contrôler un OPP pour cpufreq, ou encore une vitesse de rotation pour un ventilateur.
Une ‘thermal_zone’ représente un driver de capteur de température. Chacun de ces drivers peut définir différents seuils de température. Lorsqu’un de ces derniers est atteint, une action associée dans les ‘cooling_devices’ peut être exécutée.
Les modes d’endormissement sont des techniques plus agressives de power management, car les processus en espace utilisateur ne sont plus exécutés pendant ces périodes. Un processus en espace utilisateur peut prendre la décision de faire rentrer tout le système dans un mode d’endormissement, le noyau n’as pas la possibilité de deviner quand le système va être endormi.
L’espace utilisateur doit alors configurer la source de réveil, pour indiquer quel(s) évènement(s) extérieur(s) sort l’appareil de son mode d’endormissement. Les sources de réveil sont principalement des interruptions matérielles. Cela peut être un évènement de type ‘timer’, l’appui sur une touche d’un clavier ou sur le bouton power, cela étant limité par les possibilités de chaque périphérique. En effet, chaque driver gérant un périphérique peut fournir une source de réveil, généralement en spécifiant que cette source correspond à une interruption qu’il prend en charge. Lorsque c’est le cas, on peut activer/désactiver la source de réveil depuis le sysfs en écrivant dans le fichier ‘wakeup’.
find /sys/devices -name "wakeup"
La description des fichiers du sysfs gérant le réveil se trouve dans la documentation du noyau :
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-power
Pour demander au système de s’endormir, l’utilisateur doit écrire le mode dans lequel il souhaite entrer dans le fichier ‘/sys/power/state’. L’appel à ‘write’ sera alors bloquant jusqu’au réveil du système, excepté pour le mode ‘disk’.
La liste des états supportés peut être consultée en lisant ce même fichier. Les différents modes sont décrits dans la documentation du noyau.
echo freeze > /sys/power/state
Le mode ‘freeze’ est le mode d’endormissement le plus simple, dans le sens où il est purement logiciel et ne fait presque pas appel aux capacités matérielles de mise en lowpower. Il s’agit simplement de geler tous les processus en espace utilisateur, permettant ainsi au CPU de rester en mode idle la plupart du temps (il reste tout de même certains process actifs dans le noyau). Étant donné que cet état est très peu dépendant du matériel, il est toujours supporté.
echo mem > /sys/power/state
Le mode ‘mem’, aussi appelé ‘Suspend to RAM’ est le mode d’endormissement le plus profond disponible ne nécessitant pas un redémarrage du système au réveil. Ici, les processus espace utilisateur et noyau sont gelés, les CPU non-boot sont coupés, les périphériques sont mis en état lowpower. La RAM est mise dans un mode de basse consommation (self-refresh) durant lequel les données en RAM sont gardées. Les gains en terme de consommation apportés par ce mode dépendent du matériel et des sources de réveil activées, mais ces gains peuvent être conséquents. Ce mode est d’autant plus intéressant que le temps de réveil reste relativement court, de l’ordre de la seconde. Le support de ce mode est cependant très dépendant de la plateforme matérielle et le débogage d’un driver supportant mal ce mode peut être compliqué.
echo disk > /sys/power/state
Le mode ‘disk’, parfois appelé “hibernation” est un peu différent, dans le sens où la RAM sera complètement éteinte. Il s’agit de faire l’équivalent d’un suspend-to-ram, puis de copier le contenu de la RAM sur un espace mémoire persistant, tel qu’un disque dur. On peut ainsi couper l’alimentation de beaucoup plus de composants, voire de l’intégralité du système.
La sortie de ce mode est cependant plus longue, car elle implique de repasser par la procédure de boot classique puis de recharger la RAM précédemment enregistrée, mais reste plus rapide qu’un boot from-scratch puisque l’initialisation des processus en espace utilisateur est déjà effectuée.
Lorsque le système est endormi, il faut bien entendu pouvoir le réveiller. Les différentes sources de réveil disponibles vont dépendre de l’état d’endormissement dans lequel le système est entré. Si le système est en suspend-to-disk, les sources de réveil sont en général très restreintes car la plupart des périphériques seront éteints. Dans tous les cas, les sources de réveil disponibles sont déterminées par le matériel ainsi que certains firmwares bas niveau (le BIOS par exemple).
Le choix des sources de réveil se fait encore une fois au travers du sysfs, grâce à l’interface ‘power’ des drivers et devices.
Le fichier ‘wakeup’ peut prendre deux valeurs : ‘enabled’ ou ‘disabled’, permettant d’activer ou de désactiver un réveil du système par ce périphérique. Si ce fichier n’est pas présent, c’est tout simplement que le périphérique n’a pas la capacité matérielle de réveiller le système (ou bien que ce n’est pas implémenté).
Le fichier ‘wakeup_count’ va reporter le nombre de fois que l’interruption liée à ce périphérique a réveillé le système. Attention, il est possible que les évènements de réveil ne soient comptés qu’au niveau du driver du bus et non pas de votre périphérique. Dans l’exemple suivant, un contrôleur USB sur le bus PCI réveille le système. L’évènement de réveil est alors rapporté au niveau du pilote PCI et non du périphérique USB.
# Exemple : Réveil par évènement USB sur la souris de mon laptop (Dell Latitude E5550) # Le controleur USB est situé sur le bus PCI, c'est donc le driver PCI qui reportera l'interruption # de wakeup. Je sais par avance que ma souris USB est branchée sur ce port de mon controleur USB. # (Test simple : Si je débranche ma souris, /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/ disparaît du sysfs) # Consultation du nombre de réveil du système causés par ce périphérique :/sys/devices/pci0000:00/0000:00:14.0# cat power/wakeup_count 0 # Nous allons configurer directement le controleur USB, qui va alors configurer tous ses parents. :/sys/devices/pci0000:00/0000:00:14.0# cd usb1/1-2/power # Par défaut, le réveil est désactivé pour ce périphérique :/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/power# cat wakeup disabled # On active le réveil :/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/power# echo enabled > wakeup # On s'endort en mode freeze :/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/power# echo freeze > /sys/power/state # On appuie sur le bouton de la souris, qui cause alors le réveil du système. Lorsque 'wakeup' est # à 'disabled', rien ne se passe, il faut alors appuyer sur le bouton 'power' pour causer un réveil. # Allons consulter le compteur de réveil du driver PCI :/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/power# cd ../../.. # On constate que le réveil a bien été généré par ce périphérique :/sys/devices/pci0000:00/0000:00:14.0# cat power/wakeup_count 1
Il est possible de consulter l’ensemble des sources de réveil activées sur le système et de voir lesquelles ont causé des réveils dans le debugfs, si celui-ci est activé et monté, en consultant le fichier ‘/sys/kernel/debug/wakeup_sources’
Nous avons pu voir un aperçu des techniques de power-management dans le noyau. Il faut tout de même tenir compte que l’implémentation de ces différents frameworks dépendra du matériel et des drivers disponibles. Ainsi les fonctionnalités et l’API de la gestion de l’énergie dépendent fortement de la version de Linux utilisée.
Les préoccupations énergétiques sont tout de même de plus en plus prises au sérieux par les développeurs. Auparavant considérés comme sources de bugs et instabilités, les composants de gestion de l’énergie ont vu de grosses refactorisations, évolutions et formalisations au cours des dernières années. On s’approche aujourd’hui d’un energy-aware scheduler fonctionnel et la gestion du DVFS se généralise à tous les composants du système.
Les matériels évoluent, nous ne sommes plus aujourd’hui à l’ère de la course au gigahertz, désormais chaque milliwatt économisé devient un argument commercial supplémentaire pour les fabriquants. Le noyau Linux et sa communauté de développeurs suit le rythme et va continuer de proposer de plus en plus de techniques avancées pour permettre aux utilisateurs et développeurs de contrôler au mieux la consommation de leurs systèmes.
Kyle Rankin, 11/07/2017 | Source: Linux Journal
This is the first in a series of articles on system administrator fundamentals. These days, DevOps has made even the job title "system administrator" seem a bit archaic, much like the "systems analyst" title it replaced. more>>
Shawn Powers, 10/07/2017 | Source: Linux Journal
I don't very often play games. I know that seems odd, because I do often write about gaming. Honestly though, I very rarely actually take the time to play video games. Recently, however, there has been an exception to that rule. more>>
Thomas Petazzoni, 10/07/2017 | Source: Free Electrons
Linus Torvalds has released the 4.12 Linux kernel a week ago, in what is the second biggest kernel release ever by number of commits. As usual, LWN had a very nice coverage of the major new features and improvements: first part, second part and third part.
LWN has also published statistics about the Linux 4.12 development cycles, showing:
Our most important contributions to this kernel release have been:
arch/arm/mach-at91 as well as pinctrl and irqchip driversatmel-spi driver to support the SAMA5D2 backup mode.
sun8i-codec audio driver that she contributed a few releases ago.devfreq support to dynamically change the frequency of the GPU on the Allwinner A33 SoC.mvpp2 network driver, finally adding support for the PPv2.2 version of this Ethernet controller. This allowed to enable network support on the Marvell Armada 7K/8K SoCs.mv_xor_v2 dmaengine driver, used for the XOR engines on the Marvell Armada 7K/8K SoCs.pci-mvebu and pcie-aardvark PCI host controller drivers, which allowed to remove a no-longer used MSI kernel API.fsmc_nand driver, which is used for the NAND controller driver on this platform, removing lots of unused codeIn addition, several Free Electrons engineers are also maintainers of various kernel subsystems. During this release cycle, they reviewed and merged a number of patches from kernel contributors:
The details of all our contributions for this release:
James Gray, 07/07/2017 | Source: Linux Journal
One of the smallest System on a Module (SOM) solutions currently available in the market—measuring a mere 51mm x 26mm—is Mistral Solutions' 820 Nano SOM. The company predicts that its new 820 Nano SOM solution is "destined to be a preferred SoM in the industry". more>>
Bérénice Allain, 07/07/2017 | Source: Jessica France
L'émergence des nouvelles technologies du "numérique" représente un atout mais également une menace pour les sites industriels et les exemples d'utilisations malveillantes se multiplient : cyberattaques contre les systèmes de supervision (SCADA) en charge de l'automatisation des procédés (augmentation de 82% en 2016), prise de contrôle à distance des robots (pas toujours pourvus de protections informatiques), survols illégaux par des drones (sécurité, espionnage, respect de la propriété intellectuelle),... La cyber sécurité sous toutes ses formes apparaît par conséquent comme un facteur indispensable au développement de l'usine 4.0 aux yeux de nombreux industriels français et étrangers.
Programme détaillé prochainement
Contacts :
François GUERIN
Frédéric GUINAND
Bérénice Allain, 07/07/2017 | Source: Jessica France
Suite au succès de la dernière édition -56 stands, 700 visiteurs, 5 tables rondes, patronage d'Axelle LEMAIRE- , l'ESEO et ses partenaires ont le plaisir de vous informer que le prochain Colloque IOT se tiendra le mercredi 25 octobre 2017 dans le cadre de la CONNECTED WEEK d'Angers et du World Electronics Forum.
Doc Searls, 06/07/2017 | Source: Linux Journal
Linux has long since proven it's possible for one operating system to work for everyone—also that there's an approach to development that opens and frees code so everyone can use it, improve it and assure its freedoms spread to everyone doing the same. more>>
