L'équipement comporte des objets mobiles distants, en plongée ou en surface voire dans les airs, avec lesquels il faut garder le contact autant que faire se peut. C'est ainsi que la technique des serveurs Restful apparaît très pratique et que le test trouve une raison de s'appliquer.
Partant de la configuration IP des divers services tournant dans des containers Docker j'ai créé une série de tests capables de se connecter depuis un autre container sur des serveurs (Technique du Publish and Subscribe) assurant l'échange des données. Ils ont été écrits en Python et selon la forme rigoureuse d'ECA.
Réalisé :
ï· tests utilisant une module de classes Python maison, en frontal d'une librairie C++ écrite dans le département. Échanges avec les serveurs en HTTP via un VPN ou en clair par des requêtes émises par CURL. Utilisation d'un module Swagger client pour réaliser la même opération. Tests variés.
ï· Utilisation du module Scapy pour réaliser un sniffer de réseau et détecter les échanges chiffrés (demandé par l'industriel client pour démontrer qu'il y en a un ou non)
ï· Utilisation de Git / Docker
Reprise de modules de code sur une application multinœuds CAN en robotique médicale. Pour Robocath, à Rouen, startup de R&D dans l’angioplastie.
Intervention sur le code de 3 modules temps réels (Superviseur, HMI, Display) développés en OSless, sur cœur ARM Cortex M3 et M7.
Réalisé :
ï· Je suis intervenu sur l'afficheur LCD représentant l'activité du robot (déplacement en translation et en rotation des cathéters). Ce noeud CAN est en relation avec le superviseur qui lui fournit une synthèse de l'état instantané de la cinématique du robot par bus CAN. L'animation affichée est assez complexe et sa mise au point consiste à d'abord comprendre le fonctionnement du robot, puis à pallier les faiblesse et carences du soft système fourni. L' application programmée occupe un IMXRT1050 et s'appuie sur ThreadX et Guix (fonctions gx_).
ï· Suis intervenu à moindre titre sur le superviseur et sur le gestionnaire de boutons actionneurs permettant de piloter le robot. La carte du superviseur est basée sur un chip S32K144 et celle du module HMI sur un Microchip PIC32.
ï· Installation et usage des IDE S32 Design Studio for ARM et de MPLab X.
ï· Prise de contact, préparation réunion avec fournisseurs pour utilisation d'un Hyperviseur sur SoC Multi-coeur (SysGo – PikeOS et Green Hills – Integrity). Idem pour l'intégration d'une stack TCP-IP sécurisée en tant que logiciel tiers. Revue sur les piles graphiques.
Résultat :
ï· Amélioration de l’algorithmique de l’afficheur (suppression des rafraichissements intempestifs notamment). Correction de la perte de trames CAN. Flashage des mise-àjour sur les cartes in-situ. Test.
Environnement technique:
ï· Logiciel : Microsoft AZUR (ThreadX, GUIX).
ï· IDE : Eclipse, MCUExpresso, MPLAB X, S32DS
Reprise d’un logiciel opérationnel destiné à établir les plans de charge des avions de lignes et des personnels volants de la Lufthansa. Ce logiciel, à IHM prédominante, de type client / serveur autorise les constructions itératives par collaboration.
Reprise des entrées par socket car la montée en charge provoquait des exceptions « zéro
window » de TCP. Analyse des solutions antérieures ne se pliant pas à l'emploi des ressources de la XtIntrinsics et en relation avec des crash. Analyse des incompatibilités de version entre les librairies utilisées (et technical debt). Revue de code de l’initialisation de l’IHM, langage propriétaire de description (UIL-like), tracé graphique par handler souris. Logique « métier ».
Réalisé :
ï· Corrections de bug (core dumps ou artefacts / améliorations). Gestion de la capture des signaux Linux avec sigaction()
ï· Proposition d’une architecture de remplacement gérant la socket connectée au serveur (triplet « Fifo applicative » + « Lecteur » + « Gestionnaire de signaux UNIX / POSIX »).
ï· Solution par timer contre le flickering des vues lors de l’afflux rapide de données.
ï· Conseil auprès du client Lufthansa, mise au point technique
ï· Proposition d’approche objet (UML) pour décrire à la fois les abstractions de la partie IHM (ses contrôleurs et services) afin qu’elle assure l’affichage mixte : synchrone – dessin - ou asynchrone – rafraîchissements automatiques -). But: rendre la partie graphique moins dépendante de l’environnement ainsi que réduire les rafraîchissements intempestifs.
Permettre l'affichage distant sur un poste de type terminal X d’un éditeur réduit.
ï· Ajout de l’usage de Work Procedure de la XtIntrinsics pour créer cet asynchronisme et assurer un ordonnancement interne mieux maîtrisé du contrôleur d’IHM.
Savoir-faire et connaissances
Connaissance approfondie de X11–Xt–Motif, de l’architecture des IHM (asynchronisme). Connaissance de la gestion des signaux Linux (POSIX) couplée à la Xt Intrinsics. Analyse au debugger de sections de code confuses. Utilisation d’un système de bug tracking : HP ALM. Logiciel de conception StarUML. GCC et GDB/DDD. Gestion de conf CVS.
Développement dans un projet novateur. A partir d'une carte électronique maison, basée sur deux micro contrôleurs identiques (STM32F207ZG – Cortex M3), j'ai eu à ma charge la partie réception / adaptation des commandes reçues par les airs.
D'abord j'ai adaptaté des drivers génériques STM32 (RCC (Clocks et PLLs), GPIO, UART,
Timers, bxCAN, SPI) sur des cartes STMicroelectronics. L'application a pu se faire ensuite sur la carte électronique maison offrant toutes les fonctions, notamment comm inter-MCU.
Réalisé :
ï· La configuration de base des cartes, en utilisant dans un premier temps STM32CubeMX, conformément au schéma électronique (I/O pilotant des CSs, Latches, alimentations…)
ï· Reprise du driver bxCAN repris de la base HAL de ST destiné à piloter les bus CAN sur carte finale. Passage d'un mode par polling basé sur le tick système à un mode asynchrone. Idem pour le bus SPI. Développement du mode par interruption.
ï· Implémentation du protocole NMT (automate à états au boot, messages périodiques)
ï· Le filtrage sur le MCU principal, de TPDOx de la commande donnant l’info 2-axes : Av / Ar et Gauche / Droite ainsi que les états des actionneurs
ï· Pilotage de la direction via un double DAC externe relié en SPI au processeur, permettant
d'assurer les consignes de sécurité édictée dans EN-1175
ï· Envoi en continu de trames PDO (commandes reformatées) vers le nœud maître ï· Implémentation des fonctions indispensables du Safety board (sur deuxième proc.)
ï· Développement sous Eclipse GCC, avec la suite logicielle de GNU. Flashage et Debug
via sonde ST-Link V2-Isol et OpenOCD.
Savoir-faire et connaissances: Développement croisé (GNU ARM EABI toolchain). Gestion
des interruptions / tâche de fond, savoir lié aux périphériques via le datasheet du STM32F207.
Tests avec l’espion PCAN-USB de PEAK System. Normes CAN (conformation des trames /
protocole électrique) /CANOpen (layers applicatifs). Transceivers MCP2551 et TI-SN65HVD233
sur réseau filaire. Utilisation d’un RPi 3 avec carte additionnelle CAN SPI Click de MikroE.
Projet lié à la partie « face avant » d'un équipement de Radio
Mobile au standard PMR (coopérant avec la base, i.e. partie Radio). ARM Cortex A5.
Reprise du code en l'état ayant tourné en partie sur ATMEL sama5d3 et à compléter et finaliser
sur un sama5d2 implanté sur une nouvelle carte électronique dotée d'un chip audio.
Savoir-faire utilisé : Embarqué. Reprise d'un projet en grande partie développé, à mener à
bien dans un nouvel environnement de dév. croisé vers cible Cortex A5. Test.
Réalisé :
ï· Bootstrap / bootloader, init du soc (modification sur la configuration des GPIOs, Flash
Nand, Usart, accès aux registres ...
14 décembre 2020 - 11 juin 2021 COURS, TD
Ingima : Application « Banc de test » pour tête de visée
avril 2019 – octobre 2019 : Portage d’un logiciel temps réel de banc de test, existant dans l’environnement Windows 2000 / RTX, écrit en C++, vers l’environnement Linux pthreads.
Reprise du code ancien, pour régénérer un nouveau code compilable au standard C++11 et le relinker sous Linux pour réaliser une rétro-ingénierie et un refactoring. Evolution vers une nouvelle application Linux basée sur les pthreads, de nouvelles cartes comm et leur drivers.
Réalisé :
ï· Analyse de l’application (souvent sous debugger) programmée sans conception préalable
ï· Programme de test des nouvelles cartes électroniques (usage de leurs API fabricant)
ï· Principe de nouvelle architecture (pthreads, serveurs TCP, variables conditionnelles)
ï· Réalisation de plusieurs serveurs TCP (epoll et select, à raison d'un serveur par thread)
ï· Démon Start-and-Stop sur calculateur recevant les commandes du programme Start-andStop résidant sur le PC IHM et capable d'arrêter le calculateur et le relancer. Transit des données au travers de l'application, réponse à requête IHM avec les valeurs collectées
Savoir-faire et connaissances: Utilisation de Jira et Git. Connaissance générale C++ et Linux.
Développement sous VS Code, chaîne de compilation GCC et debugger GDB / DDD.