Firmware microcontrôleur
Développement bas-niveau sur Cortex-M et RISC-V 32 bits : architecture RTOS, ordonnancement temps-réel, gestion des interruptions, optimisation mémoire (RAM et Flash comptées en kB).
Expertise interne
Du microcontrôleur sous Zephyr au SoC Linux custom — le développement bas-niveau en interne, pas en sous-traitance.
Un PCB bien routé qui tourne avec un firmware approximatif ne livre pas sa promesse. Chez Codium, le développement logiciel embarqué fait partie intégrante du bureau d'études — le même ingénieur conçoit la carte et sait ce qui va tourner dessus.
Deux mondes coexistent : les microcontrôleurs sous RTOS — Cortex-M, RISC-V, contraintes mémoire serrées, déterminisme temps-réel — et les processeurs applicatifs sous Linux embarqué — Cortex-A, drivers kernel, BSP Debian/Fedora custom. Nous maîtrisons les deux.
Du driver I2C en bare-metal au service systemd sur Linux embarqué — chaque couche logicielle a ses règles. Nous les connaissons.
Développement bas-niveau sur Cortex-M et RISC-V 32 bits : architecture RTOS, ordonnancement temps-réel, gestion des interruptions, optimisation mémoire (RAM et Flash comptées en kB).
Portage et configuration du kernel Linux pour votre SoC (Cortex-A, i.MX, AM335x, RK3568). BSP sur base Debian ou Fedora, rootfs optimisé, démarrage sécurisé (secure boot), gestion des overlays Devicetree.
Mise en route d'un nouveau hardware : bootloader (U-Boot, SPL), configuration du Devicetree, validation de tous les périphériques. Livraison d'un BSP propre et documenté utilisable en production.
Écriture de drivers Linux kernel (char device, platform driver, driver SPI/I2C/UART/DMA) et de drivers Zephyr natifs pour vos périphériques. Respect des patterns kernel mainline.
Intégration et configuration des stacks réseau : LTE-M (PSM/eDRX), DECT NR+, BLE, LoRaWAN, Zigbee. Gestion correcte des modes veille et de la reprise réseau pour maximiser l'autonomie batterie.
Stratégies de gestion de l'énergie pour objets sur batterie : power domains, deep sleep, wake-up sources, PSM/eDRX modem. On ne coupe pas le modem violemment — on lui dit de se mettre en sommeil correctement.
Le choix ne se fait pas sur un critère unique. Puissance, mémoire, latence, mise sur le marché, certification sécurité — chaque paramètre pèse. On vous aide à choisir la bonne plateforme pour votre produit, pas celle qu'on préfère.
Concrètement : un capteur IoT sur batterie à 2 € de BOM va sur MCU. Une gateway industrielle avec interface web, gestion de fichiers et mise à jour robuste va sur Linux. La frontière est souvent la nécessité d'un OS complet.
| MCU + RTOS | Linux embarqué | |
|---|---|---|
| Mémoire | kB à quelques Mo | Dizaines à centaines de Mo |
| Latence | Déterministe (µs) | Variable (PREEMPT_RT possible) |
| Consommation | µA en deep sleep | mA en idle minimum |
| Démarrage | Immédiat (< 1 ms) | Plusieurs secondes |
| Protocoles réseau | Stack minimale intégrée | Stack complète (TCP/IP, TLS, MQTT…) |
| Mise à jour OTA | FOTA Zephyr / custom | SWUpdate / RAUC (robuste A/B) |
| Sécurité | TrustZone, secure boot | Secure boot, SELinux, dm-verity |
Zephyr vs FreeRTOS vs NuttX, le Devicetree expliqué, les drivers Linux kernel, la réalité d'un BSP Debian en production — retour de 15 ans d'expérience de développement embarqué dans notre article complet.
Lire l'article technique →Parlez-en directement à notre équipe. Premier échange gratuit, sans engagement.