Planet RaspFR

Bienvenue sur ce planet dédié au Raspberry Pi
mais aussi autres micro-ordinateurs et aux imprimantes 3D de type DIY.

Si vous voulez ajouter votre blog, n'hésitez pas à nous contacter.
Nous vous donnons rendez-vous sur le forum RaspFR

14 juin 2017 : Journée du Libre au FabLab du Chalonnais

Journée du Libre au FABLab du Chalonnais. J’ai pu visiter le FABLab puis participer aux conférences Linux, Logiciel Libre et Raspberry Pi organisées à la maison des associations.

Journée du Libre au FABLab du Chalonnais

Le FABLab du Chalonnais

Le FABLab du Chalonnais est une association Loi de 1901. C’est une plateforme d’innovation basée sur l’échange de savoir entre ses adhérents et les membres du réseau mondial des FABLabs.

Il peut aussi être vu comme une plateforme de prototypage rapide, que les objets soient communicants ou non.

Le FABLab du Chalonnais est gracieusement hébergé dans les ateliers de la cité scolaire Niepce-Balleure au 141 avenue Boucicaut, à Chalon-sur-Saône.

65 adhérents bénéficient des compétences et ressources du FABLab : plusieurs imprimantes 3D, une fraiseuse numérique, matériel électronique et informatique embarquée etc.

Le FABLab est ouvert du mardi au jeudi de 14h à 19h, hors vacances scolaires.

Vous pouvez contacter le fablab si vous êtes intéressé(e) :
XXXXX.chalon@gmail.com  (remplacez les XXXXX par fablab – Anti-spam)

Le FABLAb en images

La visite du FABLab a bien entendu été le prétexte pour prendre quelques photos… comme à mon habitude 🙂

La première imprimane du FABLab a été la 3DRAG (à droite) de chez COMELEC – partenaire de framboise314, au passage 🙂

La seconde, à gauche, a été crée en Saône et Loire, à Lugny… Un produit local !

La troisième imprimante 3D est cette Witbox2, achetée par le FABLab après une souscription, un financement participatif. Ici Roland est en train de changer une pièce de la 3DRAG, abimée mais ré-imprimée sur une autre machine… Pratique !

Un certain nombre d’objets imprimés sont présentés, en particulier des objets en résine et bois.

Même les lunettes de Doc (Retour vers le futur) ont été imprimées, portées ici par Patrice, président de l’association. Contrairement à ce qu’on pourrait penser, on voit vraiment à travers.

Sont exposés également des objets réalisés en découpe laser qui montrent bien l’utilisation qu’il est possible de faire de cette technique.

Une des choses surprenantes présentées par le FABLab du Chalonnais c’est cette plaque sur laquelle on distingue des personnages mais ils sont difficiles de reconnaitre.

En fait cette plaque s’observe devant la lumière et l’épaisseur de matière laisse plus ou moins passer la lumière. On obtient alors une photo tout à fait correcte. A gauche René, trésorier de l’association et à droite le président, Patrice. Pour ma part je n’avais pas encore vu cette application d’une imprimante 3D 😉

Support d’arduino pour rail DIN réalisé à la demande d’un industriel.

Le coin « électronique » est bien fourni en matériel de tests et mesures.

Enfin des revues sont à disposition des adhérents.

La journée du Libre

La journée du libre donnait la possibilité d’assister à 3 conférences, et de tester des matériels/logiciels libres.

Les bases d’une distribution Linux

 

C’est à Thibault MIOSSEC qu’est revenu l’honneur d’ouvrir la série de conférences avec une présentation de Linux et des distributions.

Thibault et Patrice ont répondu aux questions des participants sous le regard attentif de Tux.

Le logiciel Libre

C’est ensuite Eric Gautheron qui est intervenu pour parler du logiciel Libre.

Eric anime le blog Konectik dans lequel il partage ses expériences, en particulier sur Arduino.

Il met à disposition tous ses programmes sur GitHub : EpixFr.

On y trouve PPW, un portail Web réalisé en Php, générant automatiquement un tableau de bord sous forme de tuiles pour l’ensemble des dossiers projets d’une arborescence donnée.

Vous pourrez également découvrir PrintFr. C’est une bibliothèque pour Arduino permettant l’affichage de lettres accentuées lors de l’envoi de données par USB/serial avec des cartes Arduino

 

Au fur et à mesure que la soirée avance, la salle se remplit…

Tux

Patrice a présenté le Tux qui trônait sur le bureau. C’est en fait un boîtier pour une carte Fox. Cette carte a été utilisée dans un projet de ballon photographique, commandé en WiFi… bien avant que le Raspberry Pi n’arrive sur le marché !

Le Raspberry Pi

A l’invitation du FABLab du Chalonnais (nous sommes voisins), j’ai eu le plaisir d’animer une conférence sur le Raspberry Pi.

Après tout, un Raspberry Pi ce n’est pas autre chose que les composants d’un smartphone en « éclaté » ? Non ?

A la fin de la conférence, un tirage au sort a désigné Joseph. Je lui ai donc dédicacé et remis mon livre « Raspberry Pi 3 et Pi Zero« , offert par les Editions ENI.

Piqo

Piqo était présent lors de cette journée, représenté par Nivara.

Nivara est une entreprise située dans la Nièvre (également en Bourgogne ! quand je vous dis qu’on fait du local 😉 ) et spécialisée dans l’intégration de solutions informatiques. Ils proposent des ordinateurs à base de Raspberry Pi, comme Piqo, économes en énergies, compacts et utilisant des logiciels libres.

Présentation de Nivara par Anthony et Christophe (ils sont stagiaires 1ere année BTS Management des Unités Commerciales MUC). Ils ont fait déplacement de Nevers et présenté un stand avec démonstration du matériel Piqo. Merci à eux 🙂

Il faut noter que deux membres du Fablab ont acheté un Piqo One SE !

Steerpod

encore un produit Bourguignon 🙂

Christian habite Gueugnon (eh oui c’est encore la Bourgogne !). Il cherchait un moyen pour parcourir journellement 4 à 5 kilomètres. Il fallait que l’engin soit facile à transporter… Il a passé douze ans à développer le Steerpod.

C’est un monocycle électrique muni d’un système de stabilisation. « Sa roue est dotée de capteurs qui permettent de gérer l’accélération et le freinage. Vous avez envie d’avancer, penchez-vous en avant. Si vous voulez vous arrêter, penchez-vous en arrière, c’est aussi simple que ça », explique Christian.

Christian s’est associé à Mickaël, un ingénieur de la région. Des étudiants de la région (IUT du Creusot, ISAT de Nevers, ESIREM de Dijon, Lycée de Digoin) ont également participé au développement du projet.

Christian avait amené un Steerpod à Chalon-sur-Saône et proposait un test à qui le souhaitait…

Ici c’est Olivier, président du FABLab du Creusot qui teste l’engin. Je vous propose quelques vidéos si vous voulez en savoir plus sur le maniement de Steerpod.

Les caractéristiques

  • Vitesse : 18 km/h
  • Vitesse maximale : 20 km/h
  • Poids : 20 kg
  • Autonomie : 20 km
  • Charge maximale : 100 kg
  • Encombrement : 85cm / 48cm / 20cm
  • Temps de charge à 80% : 2h
  • Temps de charge à 100% : 4h

Steerpod : Les vidéos

 

Conclusion

Une belle réussite à mettre sur le compte du FABLab du Chalonnais. Pour une première, cette journée du libre a attiré de nombreux participants (plus de 40) et des animations venues de toute la région.

Bravo à l’équipe du FABLAb et… à la prochaine 😉

Sources

 

Cet article 14 juin 2017 : Journée du Libre au FabLab du Chalonnais a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Et si vous écriviez un livre sur Python ou sur Arduino ?

Les Editions ENI sont le premier éditeur de livres informatiques en France. Actuellement ils recherchent des auteurs pour des ouvrages sur Python et Arduino.

Le communiqué des Editions ENI

Vous souhaitez partager votre expérience à travers l’écriture d’un livre ? Les Éditions ENI recherchent actuellement des auteurs pour la rédaction d’un ouvrage sur «Python et Raspberry Pi» et également un autre livre sur «Arduino».

N’hésitez pas à contacter Julie Potier par mail : auteurs@eni.fr, si vous souhaitez vous lancer dans l’aventure.

Écrire un livre ?

Même si vous débutez en écriture, lancez vous. J’ai écrit mon premier livre sur le Raspberry Pi avec ENI et j’ai été épaulé par une équipe dynamique et efficace !!

J’ai écrit à l’époque un article qui résume le processus, lisez le. N’hésitez pas à contacter Julie chez ENI ou contactez moi si vous voulez plus d’infos 🙂

Si vous avez envie de transmettre vos connaissances/compétences en Python sur Raspberry Pi ou vos compétences en Arduino, manifestez vous.

J’y suis arrivé, alors…

POURQUOI PAS VOUS ?

 

Cet article Et si vous écriviez un livre sur Python ou sur Arduino ? a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

SmartiPi Touch : un support pour l’écran tactile officiel 7″ du Raspberry Pi

Le Smartipi Touch est un support orientable pour l’écran tactile officiel 7 pouces DU Raspberry pi. Il permet l’intégration d’un Raspberry Pi3, Pi2, B+, A+ sur sa face arrière et d’un écran tactile LCD officiel de 7 pouces.

SmartiPi Touch : un support pour l’écran tactile officiel 7″ du Raspberry Pi

En navigant sur le site Audiophonics, j’ai rencontré ce boîtier orientable pour le Raspberry Pi.

Les possibilités d’utilisation de ce support sont étendues.

Il peut devenir une borne audio stéréo (PicorePlayer) avec un DAC Audiophonics I-Sabre, par exemple.

Il peut devenir un contrôle Multiroom domotique, une station météo ou … tout autre chose selon la distribution que vous choisirez.

Son montage est extrêmement simple et prend moins de 10 minutes.

Le support dispose de 4 trous de fixation compatibles VESA 75mm M4, il s’intégrera sur tout support et notamment sur des bras articulés.

De plus, ce support écran possède un emplacement Lego pour insérer un module caméra V1 et V2 Raspberry Pi officiel.

On peut ainsi concevoir un boîtier élégant avec écran tactile LCD 7 pouces orientable de qualité à prix abordable.

Attention ! Ce support condamne la sortie HDMI du Raspberry Pi

Images de SmartiPi Touch

Caractéristiques

  • Support orientable pour l’écran tactile officiel Raspberry Pi 7 pouces
  • Compatible cartes Hat : Raspberry Pi 3, Pi2, A+, B+
  • Emplacement Lego pour fixer un module caméra V1 et V2
  • Compatible support VESA 75 M4

Contenu du kit

  • les vis nécessaires au montage sont fournies
  • Deux supports attache écran
  • Un boîtier pour caméra (kit lego)
  • Un câble splitter Micro USB femelle de 10cm
  • Une nappe pour relier l’écran et le Rapsberry Pi.
  • Une clé Allen (6pans)

Vous devrez prévoir

  • Un écran tactile LCD 7″ qui n’est pas fourni
  • Le Raspberry Pi n’est pas fourni dans le Kit

Vidéos

Présentation

Montage

Conclusion

Pour moins de 25€ (24,90€ exactement), ce boîtier permet d’intégrer facilement un écran tactile officiel lorsque la nécessité d’avoir une présentation impeccable existe.

Pas cher, très pratique, voilà (à mon avis) un complément intéressant pour ceux d’entre vous qui souhaitez intégrer le RasPi à un environnement domestique sans imposer la présence d’un boîtier insipide…

Sources

 

Cet article SmartiPi Touch : un support pour l’écran tactile officiel 7″ du Raspberry Pi a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

L’Officiel PC Raspberry Pi N°2 : Il n’est pas trop tard

Vous trouverez encore pour quelques semaines le numéro 2 de la revue L’officiel PC Raspberry Pi chez votre marchand de journaux. Début juillet sortira le N°3, toujours aussi riche en article et avec une surprise !

L’officiel PC Raspberry Pi N° 2

Au sommaire

Vous pouvez voir de façon plus détaillée la page gauche et la page droite du sommaire.

Les articles

On commence par le Raspberry Pi Zero. revue de détails et possibilités d’utilisation surtout chez les modélistes du fait de sa taille réduite et de son poids plume.

Suit un article sur la dernière version de Raspbian avec sa nouvelle interface PIXEL.

Vous verrez ensuite comment installer Raspbian sur un disque dur.

et utiliser Real VNC pour vous connecter à distance.

Un article est consacré à la sauvegarde de votre carte SD, un bien précieux sur le Raspberry Pi 😉

Puis vous verrez comment faire causer votre Raspberry Pi.

Vient ensuite un lecteur multimédia, TBOPlayer. Peu utilisé mais bien adapté à la framboise.

Pour les pirates en herbe, comment installer une PirateBox chez vous…

Les plus joueurs réaliseront leur propre borne d’arcade avec RacalBox.

Chuck Norris et ses blagues à 2 balles (2 €) ne sont qu’un prétexte pour mettre en œuvre un afficheur LCD et une imprimante thermique, avec une interface homme-machine réduite à 2 boutons.

Si vous utilisez des servomoteurs, cet article vous expliquera comment un RasPi peut les piloter, même s’il y en a plusieurs à commander.

Dans le Coin des Astuces » vous découvrirez un tas de trucs utiles pour votre Raspberry Pi (il y en a même qui viennent de framboise314 😀

La revue annonçait aussi les rencontres Raspberry Pi de Nevers où j’ai pu rencontrer certains d’entre vous.

Conclusion

Le numéro 3 est pratiquement prêt et il nous promet encore des choses intéressantes… mais chhht venez faire un tour sur framboise314 pour en savoir plus !

Cet article L’Officiel PC Raspberry Pi N°2 : Il n’est pas trop tard a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Linux et Logiciels Libres au FabLab de Chalon-sur-Saône

Le FabLab du Chalonnais est très heureux de vous annoncer sa première conférence autour de Linux et des logiciels libres. J’animerai une conférence sur le Raspberry Pi à partir de 19h. Rendez-vous le mercredi 14 Juin de 17h à 20h30 salle “loi 1901” au sein de la Maison des Associations Espace Jean Zay de Chalon sur Saône.
C’est gratuit et ouvert à toutes et tous. N’hésitez pas à venir nombreux et en parler autour de vous !!!

Après une approche technique des modèles Raspberry Pi 3 et Raspberry Pi Zero, je présenterai des applications de ces nano-ordinateurs dans divers domaines. A l’issue de la conférence, un tirage au sort désignera un participant auquel j’aurai le plaisir de remettre mon dernier livre « RaspberryPi 3 et Pi Zero » offert par les Editions ENI. Je serai également disponible pour discuter avec vous et répondre à vos questions si vous le souhaitez.

http://www.openstreetmap.org/search?query=4%20rue%20Jules%20ferry%20chalon%20sur%20saone#map=18/46.79824/4.86753

La maison des Associations est située 4 rue Jules FERRY à Chalon-sur-Saône

Sources

Cet article Linux et Logiciels Libres au FabLab de Chalon-sur-Saône a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Électronique et Loisirs Magazine N° 139 est sorti

Le numéro 139 de la revue Électronique et Loisirs Magazine est disponible chez votre marchand de journaux et le restera jusqu’en Août 2017. Comme d’habitude vous retrouverez le Raspberry Pi et Arduino dans ce numéro 139 d’ELM. Vous pouvez consulter le sommaire en ligne mais aussi feuilleter une grande partie de la revue avant de décider de l’acheter.

Construisons une tondeuse autonome

Avec l’arrivée des beaux jours, la nature s’éveille avec ses lots d’agréments mais aussi de contraintes lorsqu’il s’agit de tondre la pelouse du jardin. Afin de vous éviter cette tâche fastidieuse, ELM vous propose de fabriquer une tondeuse autonome à l’aide de composants de récupération (c’est le cas des moteurs). Sa particularité réside dans le fait qu’elle est équipée de capteur à ultrasons permettant d’éviter les obstacles, le tout étant géré de manière intelligente par un microcontrôleur qui s’adapte à toutes les formes et tailles de pelouses ou jardins. La tondeuse se déplace de façon aléatoire et non répétitive et coupe l’herbe à une hauteur prédéfinie.

C’est un des exemples que je donne souvent lors de mes conférences : Avant de se lancer dans la construction d’une tondeuse autonome pilotée par GPS, avec retour vidéo, il faut commencer par comprendre comment allumer une LED… Je vous aurai prévenu(e)s.

Amplificateur 4 W pour guitare

Cet amplificateur pour guitare dispose d’un réglage de volume, de tonalité et un système de distorsion « fuzz » intégré activable et désactivable si nécessaire. Complété par un haut-parleur ou une mini enceinte et alimenté par une batterie de 12 V, vous pourrez vous exercer partout, à la maison, chez des amis (ou bientôt à la fête de la musique).

Notification push avec RaspberryPi

Cet article vous propose d’utiliser « Pushetta », qui est un service web permettant d’envoyer des notifications d’événements avec des smartphones sous iOS et Android. Comme l’IoT est un sujet d’actualité, la revue ELM a décidé de vous proposer une application basée sur le Raspberry Pi. C’est la carte d’expérimentation ET1060M pour Raspberry Pi qui est utilisée, afin de simuler des conditions liées à la variation de grandeurs physiques telles que la température, et envoyer des alertes en fonction de seuils prédéfinis.

Whiff, le purificateur d’air pour la maison

Cet appareil émet un flux d’air dont l’intensité est réglable, cependant sa particularité est qu’il n’utilise pas des pales, des hélices ou autres ventilateurs. Mais alors comment fonctionne-t-il ? Tout simplement, il produit un flux d’air ionique qui, en plus de souffler l’air, le purifie. Whiff est un ventilateur et un purificateur d’air, mais sa forme est inhabituelle pour ce type d’appareil.

Transformez votre oscilloscope en analyseur de spectre (II)

Dans cette seconde partie de l’article paru dans le numéro 138, sont abordées la construction et l’utilisation de l’analyseur de spectre. Pour mémoire, il s’agit d’une interface capable de transformer n’importe quel oscilloscope en analyseur de spectre pour des signaux allant jusqu’à 5 MHz.

Imprimante 3D VERTEX – V

Dans les précédents numéros d’Electronique et Loisirs Magazine vous avez appris comment réaliser le montage mécanique de l’imprimante 3DVERTEX. Cet article (et les suivants) abordent l’utilisation de l’imprimante ainsi que les problèmes techniques que vous pourrez rencontrer lors de la mise en service.

Variateur de vitesse pour moteur à courant continu

Ce variateur permet de faire varier la vitesse de rotation de n’importe quel moteur électrique à balais de 12 VDC à 35 VDC, à l’aide d’une poignée de composants électroniques dont le célèbre timer NE555.

Caractéristiques techniques :

  • Tension d’alimentation : de 12 VDC à 35 VDC
  • Tension du moteur : de 12 VDC à 35 VDC
  • Courant moteur : 5 A
  • Puissance maximale du moteur : 200 W
  • Fréquence PWM : 25 kHz
  • Régulation de la vitesse : de 0 à 100 %

Cours Arduino IX

Dans cette neuvième leçon, ELM vous propose d’interfacer Arduino avec un récepteur GPS afin de réaliser vos premières expériences de localisation de satellites. Pour cela, l’article utilise deux cartes d’extension, une dénommée « GPSSHIELD » et l’autre « ET1017M », dont les composants CMS sont déjà soudés. Ainsi il ne vous restera plus qu’à souder quelques composants classiques ainsi que les connecteurs, le tout pour quelques dizaines d’euros.

Cours de programmation sur iPhone – V

Dans cette cinquième leçon, vous allez découvrir comment utiliser la «Navigation Bar» pour gérer la navigation d’un contenu, et apprendre à utiliser les «pickers» qui permettent de sélectionner la date, l’heure ou du contenu comme par exemple une image. L’exemple de mise en œuvre est  un projet pratique basé sur l’utilisation de «TabBar» et de «Navigation Controller».

Conclusion

Les typons de circuit imprimés, les bibliothèques et les scripts sont téléchargeables sur le site de la revue, dans la rubrique… Télécharger.
ELM est une des dernières revues qui nous parle d’électronique et les 8,30€ dépensés pour Électronique et Loisirs Magazine (100 pages) vous ouvrent des portes sur des articles variés, avec la possibilité de feuilleter une partie de la revue en ligne avant de l’acheter !

Si vous ne trouvez pas la revue chez votre marchand de journaux, vous pouvez l’acheter en ligne (PayPal accepté).

Sources

 

Cet article Électronique et Loisirs Magazine N° 139 est sorti a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

[Kernel] Interruptions et tasklets

[Kernel Interruptions et tasklets

Il existe plusieurs mécanismes proposés par le noyau Linux pour programmer un traitement à réaliser lorsqu’un périphérique externe déclenche une interruption pour nous notifier de l’occurrence d’un événement. Gestionnaire monolithique, tasklet, workqueue, threaded interrupt, chaque solution a des avantages et des inconvénients, qu’il est intéressant de connaître pour optimiser l’efficacité de nos traitements.

Gestion des interruptions

Récapitulons rapidement le principe des interruptions sous Linux. Il convient tout d’abord de préciser que du fait de la portabilité du noyau sur un grand nombre d’architectures, les mécanismes très bas-niveau sont totalement abstraits pour ce qui concerne la plupart du code kernel classique (dans un driver par exemple).

Lorsqu’un périphérique externe – disons un contrôleur d’entrées-sorties GPIO par exemple – désire notifier le processeur de l’occurrence d’une situation intéressante (par exemple le changement d’état d’une broche d’entrée), il envoie un signal sur une entrée du contrôleur d’interruption APIC (Advanced Programmable Interrupt Controler). De nos jours celui-ci est intégré directement dans le microprocesseur, mais dans les anciens PC par exemple, il existait sous forme de composant indépendant.

Le contrôleur d’interruption effectue une demande d’interruption IRQ (Interrupt Request) auprès du processeur principal. Ce dernier arrête le traitement en cours, sauvegarde son état (ses registres) dans la pile et interroge le contrôleur d’interruption pour connaître l’événement survenu. L’APIC lui indique la source du signal initial sous forme d’un numéro. Le processeur déroute alors son exécution sur une routine de traitement bas-niveau chargée de prendre en compte l’interruption et de réagir en conséquence.

Une fois cette routine de traitement terminée le processeur reprend le cours de ses opérations précédentes comme si de rien n’était.

fig-01 - Déclenchement d'une interruption

Fig-01 – Déclenchement d’une interruption

On peut voir les différentes interruptions gérées par le noyau Linux dans le pseudo-fichier /proc/interrupts. Par exemple sur un Raspberry Pi 3, on observe les données suivantes.

# cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       
 16:          0          0          0          0  bcm2836-timer   0 Edge      arch_timer
 17:        974        466        348       1505  bcm2836-timer   1 Edge      arch_timer
 23:         18          0          0          0  ARMCTRL-level   1 Edge      3f00b880.mailbox
 24:          2          0          0          0  ARMCTRL-level   2 Edge      VCHIQ doorbell
 39:          1          0          0          0  ARMCTRL-level  41 Edge    
 46:          0          0          0          0  ARMCTRL-level  48 Edge      bcm2708_fb dma
 48:        267          0          0          0  ARMCTRL-level  50 Edge      DMA IRQ
 50:          0          0          0          0  ARMCTRL-level  52 Edge      DMA IRQ
 62:       8865          0          0          0  ARMCTRL-level  64 Edge      dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
 79:          0          0          0          0  ARMCTRL-level  81 Edge      3f200000.gpio:bank0
 80:          0          0          0          0  ARMCTRL-level  82 Edge      3f200000.gpio:bank1
 86:          4          0          0          0  ARMCTRL-level  88 Edge      mmc0
 87:        116          0          0          0  ARMCTRL-level  89 Edge      uart-pl011
 92:        456          0          0          0  ARMCTRL-level  94 Edge      mmc1
FIQ:              usb_fiq
IPI0:          0          0          0          0  CPU wakeup interrupts
IPI1:          0          0          0          0  Timer broadcast interrupts
IPI2:        323        610        369        468  Rescheduling interrupts
IPI3:          2          5          4          4  Function call interrupts
IPI4:          2          2          0          0  Single function call interrupts
IPI5:          0          0          0          0  CPU stop interrupts
IPI6:          1          0          0          0  IRQ work interrupts
IPI7:          0          0          0          0  completion interrupts
Err:          0
#

La première colonne représente le numéro de l’interruption (sauf pour celles du bas de la liste, FIQ et IPIx qui représentent des interruptions internes au processeur). Les quatre colonnes suivantes indiquent le nombre d’occurrence de chaque interruption depuis le boot du système sur chacun des quatre cœurs de processeur. Les valeurs sont faibles ici, le Raspberry Pi 3 vient de démarrer. Les colonnes suivantes affichent le type de contrôleur, un numéro interne à celui-ci, et le driver concerné.

Les fonctions de traitement bas-niveau sont déjà écrites dans le noyau Linux et nous n’avons pas à y toucher. Elles ont pour rôle d’appeler des fonctions de plus haut-niveau que l’on nomme routines de service (Interrupt Service Routine ou ISR), et ce sont ces routines de service que nous pouvons écrire dans nos drivers. Une fonction bas-niveau a également pour rôle de désactiver dans l’APIC l’interruption qui l’a déclenchée avant d’appeler la routine de service et de réactiver l’interruption ensuite. Imaginons le déclenchement d’une hypothétique interruption 100 :

Fig-02 - Handlers bas-niveau et ISR

Fig-02 – Handlers bas-niveau et ISR

Lorsque, dans le reste de cet article je parlerai – avec un léger abus de langage – de gestionnaire (ou de handler) d’interruption, il s’agira toujours d’une routine de service invoquée par une fonction de plus bas-niveau. Autrement dit, les schémas à venir ne représenteront plus les handlers bas-niveau, mais uniquement les routines ISR.

Fig-03 - Handler d'interruption

Fig-03 – Handler d’interruption

Précisons dès à présent qu’une fonction bas-niveau peut appeler successivement plusieurs routines de service en réponse à la même interruption. Par exemple dans le fichier /proc/interrupts ci-dessus, on voit que l’interruption 62 est traitée conjointement par trois routines de service appartenant aux drivers dwc_otg, dwc_otg_pcd, et dwc_otg_hcd appelées successivement. C’est ce qu’on nomme une interruption partagée.

Fig-04 - Interruption partagée

Fig-04 – Interruption partagée

Il est possible, lors de l’écriture d’un driver d’agir de différentes façons sur le traitement des interruptions.
On peut désactiver (on dit généralement “masquer“) ou activer (“démasquer“) le traitement d’une interruption. Si on masque une interruption, et qu’elle se produit effectivement, l’IRQ restera en attente au niveau de l’APIC, jusqu’à ce que le processeur démasque l’interruption. C’est à ce moment seulement qu’il recevra la demande en attente.

Fig-05 - Masquage d'interruption

Fig-05 – Masquage d’interruption

Il faut bien comprendre qu’une seule instance de l’interruption sera délivrée au moment du déblocage, même si elle est survenue à plusieurs reprises pendant la période de masquage.

Fig-06 - Occurrences d'interruption masquée

Fig-06 – Occurrences d’interruption masquée

Sur certains processeurs, il existe des interruptions non-masquables servant à la notification d’événements très urgents.
En outre certaines interruptions peuvent être plus prioritaires que d’autres. Du fait de la portabilité de Linux sur de nombreuses architectures, cette notion n’est pas prise en compte au niveau de l’API proposée aux drivers.

Un peu de pratique

Nous allons commencer quelques expériences avec les interruptions. J’ai choisi comme plate-forme d’illustration pour cet article le Raspberry Pi 3 en raison de sa grande disponibilité. Toutefois les exemples sont adaptables sur d’autres cartes. Durant des sessions de formation je les ai testés sur de nombreux autres systèmes (BeagleBoneBlack, Pandaboard, IGEPv2, i.MX6 Sabrelite, toute la gamme des Raspberry Pi, etc.) en adaptant les numéros de GPIO.

Dans notre premier exemple nous allons installer un petit gestionnaire d’interruption très simple qui inscrira lors de son déclenchement un message dans les traces du noyau. L’intérêt de travailler avec un Raspberry Pi est de pouvoir facilement gérer communications avec l’extérieur grâce aux GPIO, et de déclencher facilement des interruptions avec un simple morceau de fil électrique.

J’ai fait le choix, pour éviter de mettre en œuvre un environnement de cross-compilation qui compliquerait le propos de cet article, de faire toutes les compilations de modules du kernel directement sur le Raspberry Pi. La compilation d’un module prend deux à trois secondes sur un Raspberry Pi 3, ce qui est très raisonnable, même lorsque le nombre d’exemples est assez élevé. L’inconvénient, est que la compilation d’un module nécessite la présence des fichiers d’en-tête, du fichier de configuration et des Makefile du noyau cible. Or, les distributions Raspbian ne fournissent pas cet ensemble. Il existe bien un package linux-headers dans cette distribution mais il ne correspond pas du tout au noyau fourni.

Nous devons donc commencer par recompiler un noyau, opération très simple mais qui prend environ deux heures de compilation sur le Raspberry Pi 3. En partant d’une distribution Raspbian fraîchement installée, voici la suite de commandes à exécuter.

$ sudo apt update
$ sudo apt install -y ncurses-dev  bc
$ git clone https://github.com/raspberrypi/linux --depth 1
$ cd linux/
$ make bcm2709_defconfig
$ make -j 8     # C'est cette étape qui dure environ deux heures...
$ sudo make scripts
$ sudo make modules_install
$ sudo mkdir /boot/old-dtbs
$ sudo mv /boot/*dtb /boot/old-dtbs/
$ sudo make INSTALL_DTBS_PATH=/boot dtbs_install
$ sudo cp /boot/kernel7.img /boot/old-kernel7.img
$ sudo cp arch/arm/boot/zImage /boot/kernel7.img 
$ sudo reboot

Après redémarrage, on vérifie avec :

$ uname -a

que l’on se trouve bien sur notre noyau tout neuf.

Attention, le répertoire qui a servi pour la compilation sera référencé pendant la compilation des modules ultérieurs, et ne doit donc pas être déplacé, ni effacé. À la rigueur, on peut y faire un peu de ménage pour gagner de la place :

$ cd /lib/modules/$(uname -r)/build                                                                                  
$ rm -rf Documentation
$ find . -name '*.[coS]' | xargs rm -f

Ceci efface les fichiers sources C et assembleur ainsi que les fichiers objets. Il est important de conserver les fichiers d’en-tête .h et les fichiers Makefile. On gagne ainsi environ 700 Mo.

Handler d’interruption monolithique

Le cas le plus simple – et le plus courant – est celui du handler monolithique. Lorsque l’interruption se produit, le handler invoqué fait tout le travail attendu puis se termine et le processeur reprend son activité initiale.

Un handler d’interruption s’écrit en respectant un prototype bien défini (il existe d’ailleurs un typedef irq_handler_t pour représenter ce prototype) :

irqreturn_t irq_handler(int irq_num, void *irq_id);

Lorsque le handler est appelé, il recevra automatiquement deux arguments : le numéro de l’interruption qui l’a déclenché (utile lorsque le même handler gère plusieurs interruptions différentes), et un identifiant représenté par un pointeur générique. Nous fournirons cet identifiant lors de l’installation du handler. En général il s’agit d’un pointeur sur une structure de données personnalisées, contenant des informations propres à notre instance de driver.

Ce pointeur joue également un second rôle, notamment dans le cas d’une interruption partagée entre plusieurs périphériques : on fournit le même pointeur lors du retrait du driver afin d’indiquer quel handler doit être désinstallé.

Le handler doit également renvoyer une valeur de type irqreturn_t. Il s’agit d’un type énuméré pouvant prendre les valeurs IRQ_NONE ou IRQ_HANDLED (ainsi que la valeur IRQ_WAKE_THREAD que nous verrons dans le prochain article). En principe le handler doit interroger le matériel qu’il gère afin de savoir si l’interruption lui était bien destinée. Dans l’affirmative il renverra IRQ_HANDLED. Sinon, (il est probable que l’interruption soit partagée entre plusieurs drivers) il renverra IRQ_NONE.

Pour installer et désinstaller le handler, on utilise les routines suivantes :

int  request_irq(unsigned int irq_num, irq_handler_t irq_handler, unsigned long flags, const char *name, void *irq_dev);
void free_irq(unsigned int irq_num, void *irq_dev);

Il existe divers flags pour l’installation d’un handler, on les trouve dans le fichier <linux/interrupt.h>. En voici quelques-uns utilisés régulièrement :

  • IRQF_TRIGGER_RISING : déclenchement sur le front montant d’un signal logique.
  • IRQF_TRIGGER_FALLING : déclenchement sur le front descendant d’un signal logique.
  • IRQF_TRIGGER_HIGH : déclenchement tant qu’un signal logique est au niveau haut.
  • IRQF_TRIGGER_LOW : déclenchement tant qu’un signal logique est au niveau bas.
  • IRQF_SHARED : le handler accepte le partage de l’interruption avec d’autres handlers.
  • IRQF_NO_THREAD : l’interruption ne peut pas être threadée (nous en reparlerons ultérieurement) même avec le patch PREEMPT_RT.

Implémentation

Nous allons programmer un premier module simple, qui installera un handler pour une entrée GPIO. Lorsqu’un front montant se présentera sur cette broche, le handler enverra un message dans les traces du noyau. Le numéro de l’interruption associé à une borne GPIO donnée est obtenu avec la fonction gpio_to_irq().

J’ai choisi arbitrairement la broche 16 (GPIO 23, comme on peut le voir sur ce schéma du connecteur P1 du Raspberry Pi).

Téléchargeons et compilons les exemples de cet article :

$ git clone https://github.com/cpb-/Article-2017-06-06
$ cd Article-2017-06-06
$ make

Voici le listing du premier exemple :

/// \file test-irq-01.c
///
/// \brief Exemples de l'article "[KERNEL] Interruptions et tasklets" (https://www.blaess.fr/christophe/2017/06/05)
///
/// \author Christophe Blaess 2017 (https://www.blaess.fr/christophe)
///
/// \license GPL.

        #include <linux/gpio.h>
        #include <linux/interrupt.h>
        #include <linux/module.h>


        #define IRQ_TEST_GPIO_IN  23


static irqreturn_t irq_test_handler(int irq, void * ident)
{
        printk(KERN_INFO "%s: %s()\n", THIS_MODULE->name, __FUNCTION__);
        return IRQ_HANDLED;
}


static int __init irq_test_init (void)
{
        int err;

        if ((err = gpio_request(IRQ_TEST_GPIO_IN,THIS_MODULE->name)) != 0)
                return err;

        if ((err = gpio_direction_input(IRQ_TEST_GPIO_IN)) != 0) {
                gpio_free(IRQ_TEST_GPIO_IN);
                return err;
        }

        if ((err = request_irq(gpio_to_irq(IRQ_TEST_GPIO_IN), irq_test_handler,
                               IRQF_SHARED | IRQF_TRIGGER_RISING,
                               THIS_MODULE->name, THIS_MODULE->name)) != 0) {
                gpio_free(IRQ_TEST_GPIO_IN);
                return err;
        }

        return 0;
}


static void __exit irq_test_exit (void)
{
        free_irq(gpio_to_irq(IRQ_TEST_GPIO_IN), THIS_MODULE->name);
        gpio_free(IRQ_TEST_GPIO_IN);
}


module_init(irq_test_init);
module_exit(irq_test_exit);


MODULE_DESCRIPTION("Simple monolithic interrupt handler");
MODULE_AUTHOR("Christophe Blaess <Christophe.Blaess@Logilin.fr>");
MODULE_LICENSE("GPL");

Chargeons le module, et vérifions que le handler est bien installé :

$ sudo insmod test-irq-01.ko
$ cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       
   [...]
189:          0          0          0          0  pinctrl-bcm2835  23 Edge      test_irq_01
   [...]

On peut alors faire un contact entre la broche 16 (notre GPIO) et la broche 1 (le +3.3V) avec un petit fil par exemple :

$ cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3       
   [...]
189:         54          0          0          0  pinctrl-bcm2835  23 Edge      test_irq_01
   [...]

Cinquante quatre interruptions ! Et oui, ce n’est pas surprenant, un petit contact sec entre deux fils produit de nombreux rebonds très brefs. Vérifions les traces de notre handler :

$ dmesg
   [...]
[  177.947441] test_irq_01: irq_test_handler()
[  177.947541] test_irq_01: irq_test_handler()
[  177.947615] test_irq_01: irq_test_handler()
[  177.947675] test_irq_01: irq_test_handler()
[  177.947686] test_irq_01: irq_test_handler()
[  177.947696] test_irq_01: irq_test_handler()
[  177.947706] test_irq_01: irq_test_handler()
[  177.947728] test_irq_01: irq_test_handler()
[  177.947738] test_irq_01: irq_test_handler()
[  177.947747] test_irq_01: irq_test_handler()
   [...]
[  178.107233] test_irq_01: irq_test_handler()
[  178.107290] test_irq_01: irq_test_handler()
[  178.107322] test_irq_01: irq_test_handler()
[  178.107357] test_irq_01: irq_test_handler()
[  178.107376] test_irq_01: irq_test_handler()
$ sudo rmmod test_irq_01

Grâce à l’horodatage du printk(), nous voyons que les petits rebonds sont séparés par quelques dizaines de microsecondes seulement.

Différer un traitement

Nous avons parfaitement réussi à installer un handler simple qui se déclenche à chaque occurrence de l’interruption et s’exécute immédiatement et entièrement. Il est important de se souvenir que pendant toute l’exécution d’un handler, l’interruption qui l’a déclenché est masquée (sur tous les cœurs dans le cas d’un processeur multicœur).

Supposons à présent, que nous ayons un travail un peu plus conséquent à réaliser dans le handler, et que nous souhaitions par ailleurs horodater précisément l’occurrence de l’interruption. On pourrait très bien imaginer un transfert de données à effectuer, une vérification de checksum, voire un déchiffrement d’information encodées.

Pour simuler ceci, j’ai simplement ajouté dans le handler une attente active d’une milliseconde avec udelay(), après le printk() qui nous sert d’horodatage :

/// \file test-irq-02.c

   [...]

        #include <linux/delay.h>


        #define IRQ_TEST_GPIO_IN  23


static irqreturn_t irq_test_handler(int irq, void * ident)
{
        printk(KERN_INFO "%s: %s()\n", THIS_MODULE->name, __FUNCTION__);
        udelay(1000);
        return IRQ_HANDLED;
}

   [...]

Après chargement du module je réitère la même expérience en faisant un bref contact entre l’entrée GPIO et le +3.3V. Voici les traces des messages du kernel :

$ cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3       
   [...]
189:         57          0          0          0  pinctrl-bcm2835  23 Edge      test_irq_01
   [...]
$ dmesg
   [...]
[ 1297.485853] test_irq_02: irq_test_handler()
[ 1297.486866] test_irq_02: irq_test_handler()
[ 1297.487876] test_irq_02: irq_test_handler()

Cette fois nous n’avons que trois interruptions prises en compte, toutes séparées d’une milliseconde. Pour simplifier notre propos, je n’en ai représentées que deux sur le schéma suivant, mais le raisonnement est tout aussi valable. Nous savons que des rebonds se produisent et qu’une cinquantaine d’IRQ seront envoyées par l’APIC, toutes les vingt microsecondes environ. Après avoir horodaté son déclenchement, par un printk(), le handler monolithique effectue un travail consommant du temps CPU, une boucle active dans udelay(), pendant une milliseconde.

Fig-07 - Rafales d'interruptions monolithiques

Fig-07 – Rafales d’interruptions monolithiques

Sur le schéma ci-dessus, j’ai numéroté entre parenthèses les occurrences des interruptions. Nous voyons que la première est correctement traitée, avec un retard (on parle généralement de latence) de quelques microsecondes parfaitement justifié. Lorsque la deuxième arrive, l’interruption 189 étant masquée dans l’APIC, elle reste en attente et sera délivrée plusieurs centaines de microsecondes plus tard, une fois que le premier handler sera terminé. Nous avons donc un problème d’horodatage pour cette deuxième occurrence. La situation est pire pour la troisième interruption et les suivantes, puisque le masquage ne conservant qu’une seule occurrence d’IRQ, elles seront tout simplement perdues.

Il est clair que si une interruption périodique se produit toutes les vingt microsecondes dont le handler dure une milliseconde, le système n’est pas viable. Ce qui m’intéresse, c’est le cas où nous avons quelques déclenchements occasionnellement très rapprochés, mais que cela se produit suffisamment rarement pour permettre au système de fonctionner normalement le reste du temps. Et avec un handler monolithique, le résultat n’est pas satisfaisant : seule la première occurrence est correctement traitée, la seconde est mal horodatée, et les suivantes sont perdues !

Top-half et bottom-half

Alf

Une autre approche est possible, qui consiste à distinguer les opérations devant être exécutées immédiatement au déclenchement de l’IRQ, de celles qui peuvent être réalisées une fois que l’interruption aura été démasquée dans l’APIC. Les premières sont regroupées dans la partie supérieure (top half) du traitement, et les secondes dans la partie inférieure (bottom half).

Il existe plusieurs supports pour implémenter top half et bottom half. Dans cet article nous observerons les tasklets, dans le suivant nous verrons les workqueues et les threaded interrupts.

Tasklets

Contrairement à ce que leur nom – particulièrement mal choisi – laisse entendre, les tasklets ne sont pas des petites tâches. Il s’agit simplement d’un mécanisme permettant à un handler d’interruption de programmer l’exécution d’une fonction après avoir démasqué l’IRQ qui l’a déclenché. La fonction qui s’exécute doit être de type :

void tasklet_function(unsigned long arg);

On déclare une tasklet avec :

DECLARE_TASKLET(tasklet_name, tasklet_function, tasklet_arg)

La tasklet ainsi déclarée est implémentée par une structure tasklet_struct. Puis on peut programmer son exécution avec :

void tasklet_schedule(struct tasklet_struct *tasklet_name);

Lorsque le handler invoque tasklet_schedule(), nous avons plusieurs garanties :

  • La fonction de la tasklet sera exécutée (par abus de langage, on dit “la tasklet sera exécutée”) ultérieurement, le plus tôt possible après la fin du handler, sans passer par l’ordonnanceur (contrairement à ce que schedule dans tasklet_schedule() laisse entendre).
  • Si la tasklet est déjà programmée, mais n’a pas encore débuté, une seule instance sera exécutée.
  • Si la tasklet est déjà en cours d’exécution, une seconde instance sera exécutée après la fin de la première, sur le même cœur de CPU que celle-ci.
  • Si la tasklet n’est pas programmée ni en cours d’exécution, elle sera exécutée sur le même cœur de CPU que le handler qui invoque tasklet_schedule().

 

Attention, il est important au retrait du module de s’assurer qu’il n’y a pas de tasklet en cours ou en attente d’exécution (sur un autre cœur). Pour cela il faut appeler :

void tasklet_kill(struct tasklet_struct * tasklet_name);

Voyons comment se déroule le traitement d’une occurrence unique de l’interruption :

Fig-08 - Une interruption, une tasklet

Fig-08 – Une interruption, une tasklet

J’ai abrégé sur le schéma ci-dessus T.H. pour Top Half (le code qui est exécuté directement dans le handler d’interruption), et B.H. pour Bottom Half, le code ultérieurement exécuté dans la tasklet. Pas de surprise, le traitement est identique à celui d’un handler monolithique, avec un temps d’exécution très légèrement plus long (non représenté sur ce schéma) dû au mécanisme de programmation et d’invocation de la tasklet.

Supposons maintenant que deux interruptions très rapprochées se déclenchent. La Bottom Half de la première est interrompue par la Top Half de la seconde, et la deuxième Bottom Half s’exécutera à la suite.

Fig-09 - Deux interruptions, deux tasklets

Fig-09 – Deux interruptions, deux tasklets

L’avantage par rapport au handler monolithique, c’est que la seconde interruption est correctement horodatée. Intéressons-nous maintenant au cas de trois interruptions rapprochées :

Fig-10 - Trois interruptions, deux tasklets

Fig-10 – Trois interruptions, deux tasklets

À nouveau les trois interruptions sont correctement horodatées. Mais cette fois, le troisième tasklet_schedule() n’a pas d’effet car la seconde tasklet n’a pas encore démarré. C’est ce que confirme l’expérience suivante :

/// \file test-irq-03.c

  [...]
        static void irq_test_tasklet_function(unsigned long);

        static DECLARE_TASKLET(irq_test_tasklet, irq_test_tasklet_function, 0);


static irqreturn_t irq_test_handler(int irq, void * ident)
{
        printk(KERN_INFO "%s: %s()\n", THIS_MODULE->name, __FUNCTION__);
        tasklet_schedule(&irq_test_tasklet);
        return IRQ_HANDLED;
}


static void irq_test_tasklet_function(unsigned long unused)
{
        printk(KERN_INFO "%s: %s()\n", THIS_MODULE->,name, __FUNCTION__);
        udelay(1000);   
}
  [...]

Lorsqu’on fait à nouveau un bref contact entre la broche 16 et la broche 1, on observe :

$ dmesg
  [...]
[130129.690714] test_irq_03: irq_test_handler()
[130129.690734] test_irq_03: irq_test_handler()
[130129.690744] test_irq_03: irq_test_handler()
[130129.690776] test_irq_03: irq_test_tasklet_function()
[130129.690826] test_irq_03: irq_test_handler()
[130129.690857] test_irq_03: irq_test_handler()
[130129.690868] test_irq_03: irq_test_handler()
[130129.690877] test_irq_03: irq_test_handler()
[130129.690895] test_irq_03: irq_test_handler()
[130129.691814] test_irq_03: irq_test_tasklet_function()
  [...]

Mais alors, la situation n’est pas meilleure qu’avec un driver monolithique ! Somme nous condamnés à perdre la troisième interruption et les suivantes jusqu’au déclenchement de la tasklet ? Non. La situation n’est pas tout à fait la même. Car dans la Top Half, nous avons brièvement le contrôle, et pouvons par exemple incrémenter un compteur d’interruptions. La Bottom Half bouclera autant de fois qu’il y a d’interruptions reçues, et décrémentera le compteur. Voici un exemple d’implémentation :

/// \file test-irq-04.c
  [...]
        #include <linux/atomic.h>
        #include <linux/delay.h>
        #include <linux/gpio.h>
        #include <linux/interrupt.h>
        #include <linux/module.h>

  [...]
        static atomic_t irq_test_counter = ATOMIC_INIT(0);


static irqreturn_t irq_test_handler(int irq, void * ident)
{
        printk(KERN_INFO "%s: %s()\n", THIS_MODULE->name, __FUNCTION__);
        atomic_inc(&irq_test_counter);
        tasklet_schedule(&irq_test_tasklet);
        return IRQ_HANDLED;
}


static void irq_test_tasklet_function(unsigned long unused)
{
        printk(KERN_INFO "%s: %s()\n", THIS_MODULE->name, __FUNCTION__);
        do {
                printk(KERN_INFO "%s:%s() loop\n", THIS_MODULE->name, __FUNCTION__);
                udelay(1000);
        } while (atomic_dec_return(&irq_test_counter) > 0);
}
  [...]

Heureuse surprise, dès mon premier test, j’ai eu trois interruptions rapprochées et le résultat est concluant :

  [...]
[171984.092518] test_irq_04: irq_test_handler()
[171984.092569] test_irq_04: irq_test_handler()
[171984.092581] test_irq_04: irq_test_handler()
[171984.092595] test_irq_04: irq_test_tasklet_function()
[171984.092606] test_irq_04:irq_test_tasklet_function() loop
[171984.093617] test_irq_04:irq_test_tasklet_function() loop
[171984.094627] test_irq_04:irq_test_tasklet_function() loop
  [...]

Tasklet et contexte d’appel-système

Nous avons vu que, programmée depuis un contexte d’interruption, une tasklet est exécutée immédiatement sans repasser par l’ordonnanceur. Ceci est facile à vérifier, en modifiant légèrement le code de la tasklet ainsi :

/// \file test-irq-05.c

  [..]
static irqreturn_t irq_test_handler(int irq, void * ident)
{
        tasklet_schedule(&irq_test_tasklet);
        return IRQ_HANDLED;
}


static void irq_test_tasklet_function(unsigned long unused)
{
        printk(KERN_INFO "%s: current pid=%d comm=%s\n", THIS_MODULE->name, current->pid, current->comm);
}

Cette tasklet affiche le PID et le nom du processus current (celui actuellement ordonnancé sur le cœur de CPU où elle s’exécute). Nous voyons bien qu’il n’y a pas de tâche spécifique. Suivant les itérations différents processus où threads kernel sont actifs :

[198874.401602] test_irq_05: current pid=0 comm=swapper/0
  [...]
[198874.402142] test_irq_05: current pid=463 comm=rs:main Q:Reg
  [...]
[198874.402669] test_irq_05: current pid=90 comm=jbd2/mmcblk0p2-
  [...]
[198874.415554] test_irq_05: current pid=0 comm=swapper/0
  [...]
[198874.421986] test_irq_05: current pid=3 comm=ksoftirqd/0
  [...]
[198874.422530] test_irq_05: current pid=462 comm=in:imklog
  [...]
[198874.423017] test_irq_05: current pid=463 comm=rs:main Q:Reg
  [...]
[198874.423882] test_irq_05: current pid=0 comm=swapper/0
  [...]

Rien ne nous empêche néanmoins de programmer une tasklet depuis un contexte d’appel-système. Voici par exemple un module qui implémente un mini-driver proposant un unique appel-système write() qui ne fait qu’appeler notre tasklet :

/// \file test-irq-06.c
  [...]
        #include <linux/delay.h>
        #include <linux/interrupt.h>
        #include <linux/miscdevice.h>
        #include <linux/module.h>
        #include <linux/sched.h>

        static void irq_test_tasklet_function(unsigned long);

        static DECLARE_TASKLET(irq_test_tasklet, irq_test_tasklet_function, 0);


static void irq_test_tasklet_function(unsigned long unused)
{
        printk(KERN_INFO "%s: current pid=%d comm=%s\n", THIS_MODULE->name, current->pid, current->comm);
}


static ssize_t irq_test_write(struct file *filp, const char *buffer, size_t length, loff_t *offset)
{
        tasklet_schedule(&irq_test_tasklet);
        return length;
}


static struct file_operations irq_test_fops = {
        .owner = THIS_MODULE,
        .write = irq_test_write,
};

static struct miscdevice irq_test_misc = {
        .minor = MISC_DYNAMIC_MINOR,
        .name  = THIS_MODULE->name,
        .fops  = &irq_test_fops,
};


static int __init irq_test_init (void)
{
        return misc_register(&irq_test_misc);
}


static void __exit irq_test_exit (void)
{
        misc_deregister(&irq_test_misc);
}
  [...]

Pour déclencher l’appel-système, il nous suffit de faire une écriture avec un echo redirigé depuis la ligne de commande du shell.

$ sudo insmod test-irq-06.ko
$ echo 1 > /dev/test_irq_06 
-bash: /dev/test_irq_06: Permission denied
pi@raspberrypi:~/article-2017-06-06$ sudo -s
root@raspberrypi:/home/pi/article-2017-06-06# echo 1 > /dev/test_irq_06
root@raspberrypi:/home/pi/article-2017-06-06# echo 1 > /dev/test_irq_06
root@raspberrypi:/home/pi/article-2017-06-06# echo 1 > /dev/test_irq_06
root@raspberrypi:/home/pi/article-2017-06-06# dmesg
  [...]
[202648.772668] test_irq_06: current pid=15 comm=ksoftirqd/1
[202666.062771] test_irq_06: current pid=3 comm=ksoftirqd/0
[202668.352760] test_irq_06: current pid=3 comm=ksoftirqd/0

Lors de la programmation d’une tasklet depuis un contexte d’appel système, c’est donc un thread du kernel qui l’exécutera. Ces threads, nommés ksoftirqd sont parfaitement visibles dans la liste des tâches du système. Notons par ailleurs que ce n’est pas toujours le même thread, le noyau dispose d’un ensemble de ksoftirqd, et en sélectionne dynamiquement un disponible.

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.4  22780  3816 ?        Ss   Jun02   0:07 /sbin/init splash
root         2  0.0  0.0      0     0 ?        S    Jun02   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Jun02   0:05 [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S<   Jun02   0:00 [kworker/0:0H]
root         7  0.0  0.0      0     0 ?        S    Jun02   0:17 [rcu_preempt]
root         8  0.0  0.0      0     0 ?        S    Jun02   0:00 [rcu_sched]
root         9  0.0  0.0      0     0 ?        S    Jun02   0:00 [rcu_bh]
root        10  0.0  0.0      0     0 ?        S    Jun02   0:00 [migration/0]
root        11  0.0  0.0      0     0 ?        S<   Jun02   0:00 [lru-add-drain]
root        12  0.0  0.0      0     0 ?        S    Jun02   0:00 [cpuhp/0]
root        13  0.0  0.0      0     0 ?        S    Jun02   0:00 [cpuhp/1]
root        14  0.0  0.0      0     0 ?        S    Jun02   0:00 [migration/1]
root        15  0.0  0.0      0     0 ?        S    Jun02   0:00 [ksoftirqd/1]
root        17  0.0  0.0      0     0 ?        S<   Jun02   0:00 [kworker/1:0H]
root        18  0.0  0.0      0     0 ?        S    Jun02   0:00 [cpuhp/2]

Conclusion

Nous avons vu le principe des tasklets pour réaliser un traitement différé depuis un handler d'interruption. Il existe d'autres mécanismes que nous verrons dans le prochain article. L'intérêt de la tasklet est d'être exécutée immédiatement, plus prioritairement que toutes les tâches ordonnancées du système. Ceci est toutefois différent si elle est programmée depuis un contexte d'appel système, puisqu'alors c'est un thread du kernel qui l'exécute.

Nous reviendrons sur cette exécution portée par un thread dans le prochain article, car cela peut nous réserver des surprises dans un contexte d'application temps réel...

Conférence Raspberry Pi à la Librairie de Provence à Aix-en-Provence

Jour de grande chaleur à Aix ce 26 mai 2017… Heureusement de nombreuses fontaines rafraichissent l’atmosphère. C’est à la Librairie de Provence, sur le Cours Mirabeau que j’ai eu le plaisir d’animer une conférence sur le Raspberry Pi et de dédicacer mon livre. Voici quelques images…

Le Raspberry Pi à la Librairie de Provence

 En premier lieu un grand merci à toute l’équipe de la Librairie de Provence. L’emplacement prévu au départ étant un peu exigu, le lieu de la conférence s’est déplacé du sous sol au… premier étage. Tout le monde a mis la main à la pâte, qui pour monter des chaises, déplacer des tables chargées de livres, aider à l’installation. Et tout ça avec le sourire et dans la bonne humeur. Un accueil qui est aussi celui qui est réservé aux clients de la Librairie. Bravo 😀

Raspberry Pi et Arduino

La Librairie de Provence dispose d’un rayon technique bien fourni. Vous n’y trouverez pas que des bouquins destinés aux nuls (que vous n’êtes pas !) mais aussi des bouquins plus techniques et en particulier ceux de la collection Ressources Informatiques des Éditions ENI. Arduino, Python ou Raspberry Pi 2, Zero et 3 sont disponibles. Sont également disponibles des Kits de démarrage Raspberry Pi (élaborés par Kubii) et comprenant le Raspberry Pi 3 Modèle B  avec 1Go de RAM, WIFI et BLUETOOTH intégré. Il comprend aussi le nouveau boîtier officiel de la Fondation, une carte NOOBS micro SD 16Go, une alimentation 5V 2,5A.  L’ensemble des accessoires sont les accessoires officiels.
Si vous êtes dans la région Aix-Marseille cette librairie est l’endroit où vous pourrez trouver des informations sur le Raspberry Pi.

Les photos de la conférence

J’ai sélectionné quelques photos prises avant, pendant et après la conférence. Vous pourrez mieux les voir en cliquant dessus.

Préparation du matériel avant la conférence

Le premier participant est arrivé, l’installation n’est pas terminée 🙂

Malgré la date choisie (le vendredi du pont de l’Ascension) 7 personnes s’étaient inscrites

On va bientôt pouvoir démarrer… En attendant, ça discute 😉

Allez, c’est parti

Un public attentif et participatif pour cette conférence

A la fin de la conférence, discussion et dédicaces pour ceux qui repartent avec le livre  🙂

Pour remercier les participants, la Librairie de Provence et les Éditions ENI avaient aussi prévu de quoi se rafraichir et grignoter. Vous pensez bien que j’ai goûté les gâteaux à la framboise (qui a dit ça se voit 😀 ) Pim’s framboise et Paille d’or framboise… Tout un programme. Même le jus de fruit avait un goût de framboise 😉

Photo souvenir avec Fabien, représentant ENI dans le sud de la France qui était venu assister à la conférence. Il a rappelé que le livre Raspberry Pi 3 ou Pi Zero était resté 6 mois en tête des ventes chez ENI, ce qui est un beau score !!

Conclusion

Un moment très convivial à la Librairie de Provence. Merci aux participants qui sont venus m’écouter malgré le pont de l’Ascension, la chaleur et pour certains les kilomètres (une centaine !).

Merci encore à l’équipe de la Librairie et à Udo avec lequel j’ai préparé cette conférence. Je reviendrai avec plaisir si vous le souhaitez 🙂

Au final la journée framboise n’était pas terminée puisqu’à l’hôtel, sur le buffet des desserts trônait une succulente tarte… à la framboise 😀 😀

Cet article Conférence Raspberry Pi à la Librairie de Provence à Aix-en-Provence a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Un boîtier façon NUC pour le Raspberry Pi

Element 14 a récemment annoncé un nouveau kit appelé Pi Desktop pour le Raspberry Pi 3. Le concept de base est similaire à l’élégant NUC, mais avec un matériel moins puissant et beaucoup plus ouvert au bricolage. Le kit exploite la puissance du Raspberry Pi et lui ajoute quelques fonctionnalités, comme une interface mSATA pour un SSD.

Pi Desktop sera vendu environ 56 $ lorsqu’il sera mis à la disposition des clients nord-américains le lundi 5 juin.

Pi Desktop, un NUC pour le Raspberry Pi

Le kit intègre une carte additionnelle qui se connecte sur le GPIO 40 broches du Raspberry Pi. Cette carte amène une interface mSATA, un contrôleur d’alimentation et une horloge système.

Le kit comprend également le boîtier, un radiateur, un adaptateur USB, la batterie de l’horloge RTC et la quincaillerie nécessaire au montage du Pi Desktop.

Une fois en possession du kit, vous devrez ajouter votre propre Raspberry Pi 3 et un disque SSD pouvant aller jusqu’à 1 To. Elément 14 indique que vous pourrez démarrer directement à partir du SSD. Le Raspberry Pi lui-même offre la plupart des fonctionnalités dont votre nouveau mini-PC aura besoin, y compris quatre ports USB, le Wi-Fi, le Bluetooth, des ports Ethernet et HDMI.

Sans avoir vu l’intérieur kit Pi Desktop il est difficile de dire s’il sera facile à assembler. On peut cependant imaginer que ce sera un peu plus compliqué que l’ajout d’un SSD et d’une RAM à un NUC Intel. On sera quand même loin de tout ce qui est nécessaire à la construction d’un PC 🙂

Tout le monde n’appréciera pas le Pi Desktop, mais il ajoutera certainement un peu plus de style et de facilité d’intégration à un mediacenter maison à base de Raspberry Pi 3. Après si cette utilisation ne vous intéresse pas, le boîtier n’en reste pas moins joli.

Conclusion

Cette nouveauté montre encore une fois l’intérêt que portent les grosses entreprises au Raspberry Pi. J’attendrai d’en avoir un exemplaire en main pour en savoir plus… Par exemple comment le SATA est connecté au RasPi…

Merci à Ivan pour cette information.

Sources

Cet article Un boîtier façon NUC pour le Raspberry Pi a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Le Commando Kieffer recrute des spécialistes

Le Commando Kieffer ce sont des marins en prise directe avec le besoin de la Marine nationale et du commandement des opérations spéciales. «Le juste besoin pour la juste compétence», telle pourrait être la devise en ressources humaines de ce «jeune commando» : Guerre électronique, drones, analyste renseignement, interprète image… les compétences recherchées sont pointues.

Le Commando Kieffer

À sa formation en 2008, le Commando Kieffer comportait moins de 30 hommes. Il n’a cessé de croîte depuis cette date. Le Commando Kieffer est chargé de fournir des compétences technologiques ou à forte valeur ajoutée. Pour cela il dispose de divers spécialistes comprenant notamment des experts dans la mise en œuvre de drones, de la guerre électronique et cyberguerre… Il est basé à Lorient. Le Commando Kieffer recrute et sélectionne ces spécialistes puis les forme pour en faire des opérateurs « Forces Spéciales ».  (source Wikipedia)

Le recrutement en cours ne concerne pas des gens pour aller sur le terrain ou dormir en extérieur ! Il s’agit de rejoindre une équipe de «geeks» travaillant dans des bureaux sur des systèmes informatiques, y compris des Arduino et… des Raspberry Pi !  L’âge (plutôt l’expérience) n’est pas un obstacle, bien au contraire !!

Le recrutement en cours

Il y a 3 postes à pourvoir, basés à Lorient (56).

Créé en 2008, le Commando Kieffer se distingue par la maîtrise et l’emploi des nouvelles technologies, aussi bien pour soutenir les autres forces que pour faire face à de nouvelles menaces. Il regroupe des spécialistes à la pointe de domaines aussi variés que le renseignement humain, les opérations dans l’espace numérique, l’emploi des drones, la cynotechnie de combat, la guerre électronique, le déminage ou le combat en environnement NRBC.

Compte tenu de la dimension croissante du Cyberespace dans les opérations et les activités maritimes, une sécurisation renforcée des systèmes d’informations est désormais nécessaire pour l’ensemble du secteur maritime et en particulier dans le domaine sensible des forces spéciales.

Conscient de cette réalité, le Commando Kieffer considère le domaine Cyber comme un domaine de lutte à part entière et recherche des VOA (Volontaires Aspirants) pour occuper des postes au sein d’une nouvelle cellule entièrement dédiée aux différents domaines de la Cyber. Ils mettront leurs compétences en œuvre pour faciliter le développement de cette cellule et accompagner sa montée en puissance tout au long de leur affectation.

ACTIVITES PRINCIPALES

  • Le VOA cyber, réseaux et télécom participe à l’optimisation et à la sécurisation des systèmes de communication du commando.
  • Il participe à la recherche et à la conception de nouveaux équipements et services employables au profit des forces spéciales.
  • le technicien peut également être amené à concevoir et développer des équipements sécurisés de traitement et d’analyse du signal à des fins opérationnelles.
  • enfin, Il réalise une veille technologique afin d’orienter les acquisitions et accroitre la performance des outils de la cellule.

Le poste proposé

Durée : 12 mois (renouvelables).
Statut : Poste sous statut militaire
Conditions pour postuler : Master 1, Master 2 ou école d’ingénieur en systèmes, réseaux & télécommunications ou cybersécurité.
Langues : anglais courant.
Réseaux : CCNA souhaité.
Niveau d’études : Bac +3 et plus

  • Le poste proposé nécessite de disposer de capacités d’adaptation, d’adhésion pour les valeurs de l’institution et de curiosité pour le métier militaire, d’un sens relationnel développé, d’initiative, de dynamisme, de rigueur et de disponibilité.
  • Le VOA Cyber dispose d’une solide culture scientifique qu’il devra entretenir pour s’adapter aux évolutions des technologies. Il maitrise les techniques de pointe en informatique ainsi que les problématiques d’infrastructure, de câblage, de protocole et de sécurité. Il a une bonne connaissance des outils de gestion et d’administration ainsi que des systèmes d’exploitation.
  • Le VOA Cyber peut être également un spécialiste des télécommunications et de la sécurité des transmissions. Il connait les principaux protocoles et est capable d’en analyser des nouveaux. Il maitrise également un langage de programmation lui permettant d’automatiser le traitement du signal.
  • En tant qu’officier, il sera autonome et il lui sera demandé de prendre en charge des projets dans leur ensemble, des qualités de leadership et management sont indispensables pour appréhender les aspects techniques et humains.

Ce recrutement s’adresse à des diplômés de niveau Bac +2 minimum
et porte sur un contrat d’engagement initial d’un an, renouvelable.
Etre de nationalité française / Savoir nager / Etre physiquement et médicalement apte
Avoir accompli sa Journée Défense & Citoyenneté (ex JAPD).
Avoir plus de 18 ans et moins de 26 ans à la date du dépôt de la candidature.

Conclusion

Je ne relaie pas souvent des offres d’emploi, mais celle-ci, qui s’adresse à des passionnés d’informatique désireux de mettre leurs compétences au service de la protection du pays et de nos marins, a retenu mon attention.
Vous pouvez postuler directement sue le site etremarin.fr et vous serez contacté si votre profil est intéressant.
Pour des raisons de sécurité et de discrétion obligatoires dans la période actuelle, merci de ne pas mettre de commentaires indiquant vos intentions à la suite de cet article. Je me réserve le droit de supprimer les commentaires inappropriés 😉

Sources

 

 

Cet article Le Commando Kieffer recrute des spécialistes a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....