Logiciel embarqué sur ARM, du driver noyau Linux au firmware bare-metal.

Je développe des drivers noyau Linux, du firmware pour microcontrôleurs et du code optimisé SIMD pour plateformes ARM, avec une spécialité : le traitement vidéo temps réel.

Pour les fabricants de cartes et de FPGA, et pour les sociétés de conseil Linux qui cherchent un sous-traitant. Au forfait, par livrable, avec un objectif de performance fixé ensemble. À distance, en marque blanche si besoin.

Cortex-A · Linuxapplication · IHMbibliothèque userspacedriver noyauDevice Treeusernoyau/dev · ioctl · mmapNEONUART · I²CCortex-M · bare metalfirmwaredrivers · DMA · IRQpériphériquesHelium · DSPDrivers Linux · firmware bare-metal · optimisation SIMD

Sélection de travaux

1280 × 1024 @ 60 fps
Pipeline vidéo en ARM NEON, tenu en continu sur Raspberry Pi 4 (Cortex-A72).
V4L2
Driver de capture Linux écrit de zéro pour une carte Raspberry Pi.
< 1 image
Latence d’un framework vidéo pour microcontrôleurs (Helium, DSP Armv8-M), selon les étapes activées.

Cibles et outils

  • Noyau Linux
  • Device Tree
  • V4L2
  • Raspberry Pi
  • Cortex-A72
  • STM32
  • Cortex-M55
  • Cortex-M33
  • ARM NEON
  • Helium (MVE)
  • Armv8-M DSP
  • C99

Services

Du logiciel embarqué sur ARM, du noyau Linux au microcontrôleur. Ces dernières années, j’ai surtout travaillé sur de la vidéo temps réel.

Drivers noyau Linux

Des drivers pour du matériel spécifique sur cartes ARM sous Linux, et le logiciel qui les utilise.

  • Drivers caractère, plateforme et V4L2, écrits de zéro ou étendus
  • Intégration Device Tree
  • Interfaces noyau–userspace : ioctl, sysfs, mmap
  • Bibliothèques userspace, outils et interfaces graphiques au-dessus du driver
Espace utilisateur
Application · IHM
Bibliothèque userspace
Interface
/dev · sysfs · ioctl
Noyau
Driver noyau
Device Tree
Matériel
Matériel spécifique

Firmware bare-metal sur Cortex-M

Du firmware déterministe pour microcontrôleurs, des drivers au niveau registre jusqu’à l’application.

  • Famille STM32 et autres microcontrôleurs Cortex-M
  • Drivers de périphériques : DMA, interruptions, timers, interfaces de communication
  • C99 portable, allocation statique, HAL constructeur en option

MCU Cortex-M

CœurHelium / DSP
SRAM · buffers statiques
DMA
Périphériques · registres
  • C99
  • sans malloc
  • sans HAL

Optimisation de performance sur ARM

Amener du code C à son objectif sur le vrai matériel : profilage, travail algorithmique et SIMD.

  • ARM NEON sur Cortex-A
  • Helium (MVE) sur Cortex-M55, instructions DSP sur Cortex-M33
  • Une référence en C portable conservée à côté de chaque version optimisée
  • Des gains mesurés sur la cible, pas estimés
Voies de 8 bits par instructionNEON · Cortex-A128-bitHelium · Cortex-M55128-bit4 beats × 32-bitDSP · Cortex-M3332-bit
rgb_to_y.cARM NEON · C99
#include <arm_neon.h>// RGB888 -> 8-bit luma, BT.601 weights 77/150/29 (sum 256).// 16 pixels per iteration; n is a multiple of 16.void rgb_to_y(const uint8_t *rgb, uint8_t *y, size_t n){    const uint8x8_t kr = vdup_n_u8(77);    const uint8x8_t kg = vdup_n_u8(150);    const uint8x8_t kb = vdup_n_u8(29);    for (size_t i = 0; i < n; i += 16) {        // Load 16 pixels and de-interleave R, G, B.        uint8x16x3_t px = vld3q_u8(rgb + 3 * i);        uint16x8_t lo = vmull_u8(vget_low_u8(px.val[0]), kr);        lo = vmlal_u8(lo, vget_low_u8(px.val[1]), kg);        lo = vmlal_u8(lo, vget_low_u8(px.val[2]), kb);        uint16x8_t hi = vmull_u8(vget_high_u8(px.val[0]), kr);        hi = vmlal_u8(hi, vget_high_u8(px.val[1]), kg);        hi = vmlal_u8(hi, vget_high_u8(px.val[2]), kb);        vst1q_u8(y + i, vcombine_u8(vshrn_n_u16(lo, 8),                                    vshrn_n_u16(hi, 8)));    }}

Extrait illustratif : RGB888 vers luminance (BT.601), 16 pixels par itération.

Traitement vidéo temps réel

Ma spécialité : des pipelines qui tiennent une cadence et un budget de latence, de la capture à la sortie.

  • Sous Linux embarqué ou sur microcontrôleur bare-metal
  • Objectifs de cadence et de latence fixés dès le départ
  • Du driver de capture aux étapes de traitement optimisées
  1. capture
  2. traitement
  3. sortie

fps · latence

Fonctionnement

Des projets ciblés et bien délimités, proches de mon expertise, chacun chiffré comme un livrable.

  1. Périmètre et objectif

    Nous définissons ensemble le livrable et un objectif mesurable : débit, latence, cadence ou empreinte mémoire, sur votre cible.

  2. Devis au forfait

    Vous recevez un prix fixe pour le livrable. Pas de taux journalier, pas de facturation ouverte.

  3. Livraison mesurée

    Le code est livré avec les résultats mesurés par rapport à l’objectif convenu.

Conditions d’intervention

Tarif
Forfait par livrable
Objectif
Un objectif mesurable pour chaque mission
Sous-traitance
Marque blanche possible pour les sociétés de conseil
Lieu
100 % à distance : France, Europe et international

Réalisations

Une sélection de travaux, décrits par ce qu’ils font et la vitesse à laquelle ils tournent.

1280 × 1024 @ 60 fps

SXGA, en continu

Pipeline de traitement vidéo en ARM NEON

Un pipeline complet de traitement vidéo écrit de zéro en ARM NEON, qui tient le SXGA à 60 images par seconde sur Raspberry Pi 4.

Cible
Raspberry Pi 4 · Cortex-A72
Budget par image
16,7 ms
Débit
78,6 Mpixel/s
RGB888 · 1280 × 1024NEON · 16 × u8vld3q_u8RGBvmull_u8 · vmlal_u8 · vshrn_n_u16Yvst1q_u816 px / iteration016,733,350,066,7 ms60 fps · 16,7 ms par image

< 1 image

de latence de bout en bout*

Framework vidéo temps réel pour microcontrôleurs

Un framework de traitement vidéo portable pour microcontrôleurs, qui gère plusieurs résolutions jusqu’au SXGA à 60 fps. Chaque algorithme de traitement existe en version C générique de référence et en versions optimisées SIMD pour deux cœurs ARM.

Cortex-M55
Helium (MVE)
Cortex-M33
Instructions DSP Armv8-M
Code
C99 pur, sans malloc, sans HAL
Portabilité
Tout microcontrôleur ; porté sur deux cibles différentes

* Selon le nombre d’étapes de traitement activées.

entréesortieNNN+1N+1N+2N+2< 1 image

V4L2

écrit de zéro

Driver de capture Linux

Un driver de capture V4L2 écrit de zéro pour une carte Raspberry Pi.

Sous-système
Video4Linux2 (V4L2)
Plateforme
Raspberry Pi
noyauuserspacematérielde capturedriver V4L2/dev/video0applicationV4L2 · Video4Linux2

Parcours

Je suis François Descamps. Je suis venu au logiciel par l’électronique, et je travaille toujours là où les deux se rejoignent : drivers, firmware et code optimisé qui doit tenir ses contraintes de temps sur le vrai matériel.

J’ai aussi une première expérience d’indépendant : en 2018–2019, j’ai réalisé un prototype de radio connectée sur Raspberry Pi comme ingénieur systèmes embarqués, de l’installation Linux et du code audio en C jusqu’à la carte électronique.

Formation et expérience

  1. BTS électronique

    Diplôme de technicien supérieur, en deux ans.

  2. Ingénieur systèmes embarqués, indépendant

    Prototype de radio connectée sur Raspberry Pi : pilotage de puces de réception radio en I²C et I²S, flux audio en C avec JACK, transmission audio en Ethernet over USB, installation et administration Debian (réseau, clustering), et le PCB sur mesure sous KiCad, du schéma et du routage jusqu’à la soudure et au débogage.

  3. École 42

    Développement logiciel, avec beaucoup de C.

  4. Mines Saint-Étienne

    Diplôme d’ingénieur en systèmes électroniques embarqués, en parallèle de l’École 42, en alternance chez Thales sur des sujets embarqués.

  5. Traitement vidéo temps réel sur ARM

    Depuis 2025

    Logiciel embarqué pour la vidéo temps réel : pipelines NEON, Helium et DSP Cortex-M, driver de capture V4L2.

Contact

Le plus simple pour démarrer : un e-mail qui décrit votre cible.

Utile à préciser

  • Plateforme et cœur cibles
  • Ce qu’il faut développer
  • Objectif de performance : débit, latence, cadence…
  • Échéance
Nouveau message
À
francois@descamps-systems.com
Objet
Demande de projet

Bonjour François,

Plateforme / cœur cible :

Ce qu’il faut développer :

Objectif de performance :

Échéance :