Les solutions libres ont longtemps été ignorées par l'industrie en raison des divergences entre les contraintes industrielles strictes et les pratiques du développement libre. Par ailleurs, plusieurs reproches étaient formulés contre les logiciels libres : manque de fonctionnalités clés (ex. : temps réel dur), manque de garanties et coûts de support, gestion des licences...Cela a pris des années, mais c'est maintenant acquis et parfaitement connu des acteurs majeurs de l'industrie.
OPEN WIDE : L’open source pour les systemes embarques Temps reel
Les solutions libres pour les systèmes embarqués
1. 1Logiciels libres et SE
Solutions libres pour les systèmes embarqués
Pierre FICHEUX (pierre.ficheux@openwide.fr)
Mars 2015
2. 2Logiciels libres et SE
Programme
● Présentation
● Rappels sur les systèmes embarqués et temps réel
● Le logiciel libre
● Linux comme système embarqué
● Extensions temps réel de Linux
● Android « embarqué »
● eCOS et RTEMS
● Les outils libres pour l'embarqué
● Open hardware
● Co-design
3. 3Logiciels libres et SE
Présentation Open Wide
● Société d'ingénierie créée en septembre 2001 avec le
concours de THALES et Schneider Electric
● Rachat d'ESG-France (automotive) en 2014
● Environ 160 salariés sur Paris, Lyon, Toulouse et
bientôt Grenoble
● Industrialisation de composants open source
– Développement
– Conseil / Formation
● Trois activités :
– OW Système d'Information (Java/PHP)
– OW Outsourcing: hébergement
– OW Ingénierie: informatique industrielle
4. 4Logiciels libres et SE
Présentation PF
● Ingénieur Arts et Métiers + Sup'Aéro
● Utilisateur de logiciels libres depuis 1989
● Utilisateur de Linux depuis 1992
● Auteur des 4 éditions de l'ouvrage « Linux embarqué »
(Eyrolles), 4ème édition parue en juin 2012 avec E. Bénard
● Auteur GNU Linux Magazine et Open Silicium
● CTO Open Wide Ingénierie, enseignant EPITA, ENSEIRB
6. 6Logiciels libres et SE
Système / logiciel embarqué
● Un système est l'association matériel + logiciel
● Logiciel utilisé dans un équipement industriel ou un
bien de consommation
● On dit aussi logiciel dédié ou intégré → embedded
software
● L'équipement est valorisé pour son coté fonctionnel et
non pas pour le logiciel !
● Un bon logiciel embarqué doit savoir se faire oublier !
● On parle parfois de logiciel enfoui ou profondément
enfoui → « deeply embedded »
7. 7Logiciels libres et SE
Domaines d'application
● 1960-70 : remplacer / compléter des systèmes
analogiques (spatial)
● 1980 : RTOS (Real Time OS) génériques
● 2000 : OS libres, grand public
● Domaines historiques/industriels
– Militaire, spatial (RTOS/360, VRTX sur Hubble)
– Contrôle de processus industriel
– Transport : AUTOSAR/OSEK, ARINC 653 →
certification (DO-178)
– Internet/Telecom : routeurs, PABX
● « Nouveaux » domaines
– Multimédia
– automobile (IVI), objets connectés
– médical
8. 8Logiciels libres et SE
Les nouveaux domaines
● Équipement grand public (multimédia, domotique, …)
● Téléphonie → 1+ milliards de téléphones Android !
● Infotainment transport: automobile, aéronautique
– Ajout de fonctions communicantes → utilisation de
protocoles standards de type IP et dérivés (HTTP,
DHCP, etc.)
– Difficile d'intégrer ces couches dans des logiciels
embarqués propriétaires → utilisation d'un OS
● « Boite noire » dédiée à un ensemble de fonctions
(passerelle médicale, set-top box avec services
étendus)
● Internet des objets → #iot :-)
9. 9Logiciels libres et SE
Avantages d'un OS
● Affranchit le développeur d'un travail d'adaptation au
matériel pour les interfaces de base (PCI, USB,
Ethernet...)
● Permet de bénéficier des dernières avancées
technologiques et de faire évoluer le système:
protocoles réseau, multimédia, etc.
● Recrutement aisé de développeurs (Linux, Android) !
● Utilisation de matériel « standard »
● Focalisation sur le métier de l'entreprise
10. 10Logiciels libres et SE
Inconvénients d'un OS
● Empreinte mémoire
● Performances
● Consommation d'énergie (nombreux travaux en cours)
● Criticité (sauf OS spécialisés)
● Perte de maîtrise du système
11. 11Logiciels libres et SE
Les systèmes temps réel
● Les applications embarquées historiques étaient temps
réel
● Les systèmes d'exploitation embarqués propriétaires
sont TR (VxWorks, LynxOS, VRTX, ...) → RTOS
● La progression des OS libres dans l'industrie et dans
l'embarqué en général modifie la donne !
– Linux est utilisable dans l'industrie
– Linux n'est pas TR
– Linux peut être modifié pour être TR (PREEMPT-RT,
Xenomai)
– Il existe des RTOS libres (RTEMS, FreeRTOS, ...)
13. 13Logiciels libres et SE
Historique
● Modèle économique du marché informatique → du
matériel vers le logiciel
● Projets logiciels libres majeurs (chronologie)
– UNIX BSD
– X Window System (X11)
– GNU (tout d'abord sur UNIX propriétaire)
– Linux → GNU/Linux
– Apache
● Apparition de licences libres (vs « freeware »)
– BSD
– GPL (dérivation et « contamination »)
– ASL
14. 14Logiciels libres et SE
Quelques éléments sur le LL
● A peu près équivalent à la notion d'open source, voir
http://www.opensource.org
● Libre ne veut pas dire gratuit
● La confusion vient de la signification anglaise
– free = libre / gratuit
● Différents types de logiciels
– Le freeware : gratuit mais sources non disponibles, pas
forcément de licence (abandon de la « paternité » du
code)
– Le shareware : sources non disponibles, coût modique,
licence souvent propriétaire
– Le logiciel libre: sources disponibles, licence open
source, non liée à la notion de gratuité (on peut
vendre un logiciel libre)
15. 15Logiciels libres et SE
Importance du logiciel libre
● Le logiciel libre est important dans le SI (serveurs)
● Le logiciel libre a pris un part importante dans les
systèmes embarqués
– OS (Linux, Android)
– Outils de base (compilateur, éditeur, débogueur, ...)
– « build systems » (Buildroot, Yocto/OE)
– IDE (Eclipse)
● La plupart des éditeurs ont au catalogue des
composants basés sur du logiciel libre (Wind River,
Adacore, LynuxWorks, ...)
16. 16Logiciels libres et SE
Avantages/inconvénients du LL
● Avantages
– Disponibilité du code source → maîtrise et
maintenabilité dans le temps
– Redistribution sans « royalties »
– Outils de développement souvent « gratuits » !
– Support de la communauté
● Inconvénients
– Méfiance vis à vis d'un modèle décentralisé (support)
– Contraintes de certaines licences (GPL, LGPL)
– Support de certains matériels (?)
– Outils moins « ciblés »
– Documentation (?)
18. 18Logiciels libres et SE
Linux comme (RT)OS
● Réservé aux systèmes complexes
– 32 bits minimum
– Gestion complexe de la mémoire (MMU, pagination +
segmentation)
– Empreinte mémoire importante: 2 Mo pour µCLinux
(sans MMU), 4 Mo pour Linux
– Consommation mémoire vive : 16 Mo minimum
● Problème de migration de anciens RTOS car Linux
n’est pas TR → évolution avec les extensions
PREEMPT-RT et Xenomai
● Incompatible avec les systèmes critiques/certifiés
● Souvent utilisé pour les outils, les simulateurs et
architectures « mixtes » (banc de test)
20. 20Logiciels libres et SE
Extensions TR pour Linux
● L'utilisation de Linux comme RTOS est souvent
intéressante
– POSIX
– Approche hybride avec quelques tâches TR
– On conserve le confort d'un système classique
● Deux approches possibles :
– Modifier le noyau Linux afin d'améliorer ses
performances TR (PREEMPT-RT)
– Ajouter un « co-noyau » TR qui partage le matériel avec
le noyau Linux (RTLinux, RTAI, Xenomai) → approche
« virtualisation »
21. 21Logiciels libres et SE
PREEMPT-RT
● Branche expérimentale pour le noyau 2.6, voir
https://rt.wiki.kernel.org
● Initié par Ingo Molnar, contributeur majeur du noyau
● Maintenu par Thomas Gleixner
● Surtout utilisé sur x86 et des processeurs performants
(TSC = Time Stamp Counter)
● Fonctionne également sur ARM (11 ou plus), Nios II,
Microblaze, ...
● Nécessite un noyau « mainline » (ou proche) mais ne
sera probablement jamais intégré à la branche officielle
● Mise en place très simple (application d'un patch)
● Mêmes API de programmation que Linux standard
22. 22Logiciels libres et SE
PREEMPT-RT, caractéristiques
Utilisation d'un thread noyau (interruptible) pour le
traitement de chaque interruption
4 2 root SW< 0 0% 0% [sirq-high/0]
5 2 root SW< 0 0% 0% [sirq-timer/0]
6 2 root SW< 0 0% 0% [sirq-net-tx/0]
● Prévention des inversions de priorité (par héritage)
● Timers noyau haute précision (HRTIMER)
● Amélioration des mécanismes de synchronisation
● Le résultat est un noyau (presque) « préemptif », mais
reste un noyau Linux
23. 23Logiciels libres et SE
PREEMPT-RT, résumé
● Changements significatifs du code noyau
– Verrouillage des sections critiques
– Volume du patch important
● Utilisation de mlockall() → verrouillage des pages
mémoire en RAM
● Le coût de la préemption peut être important si le
nombre de tâches TR augmente
● Temps de latence maximum nettement amélioré
– dépend largement de la plate-forme matérielle (TSC)
– dépend de la configuration logicielle
– Bons résultats sur x86 depuis de nombreuses années
● Permet de garantir moins de 50 µs de jitter (x86)
● Risque sur la maintenance (financement) ?
24. 24Logiciels libres et SE
Linux avec co-noyau
● Ajout d'un « co-noyau » pour la gestion du temps-réel
– Sous-système temps-réel intégré à un module noyau
– Patch de « virtualisation » des interruptions
● Différents modèles de programmation
– Noyau uniquement (RTLinux, version libre)
– Noyau et espace utilisateur, semi-intégration Linux
(RTAI, www.rtai.org)
– Noyau & espace utilisateur, intégration Linux complète
(Xenomai, www.xenomai.org)
25. 25Logiciels libres et SE
Linux avec co-noyau
● Séparation entre le composant temps-réel et Linux
– Ordonnanceur temps-réel spécifique
– Pas de dépendance sur les sections critiques Linux :-)
● Virtualisation de la gestion d'interruptions Linux
– Routage prioritaire des IRQs vers le co-noyau
● Linux comme tâche idle du co-noyau
● Volume du patch noyau plus faible qu'avec PREEMPT-
RT
● Se rapproche de la technique de « para-virtualisation »
des hyperviseurs (adaptation de l'OS)
26. 26Logiciels libres et SE
Linux + co-noyau, suite
● Peu de modifications sur le noyau Linux
– patch de virtualisation (très bas niveau)
– notion de domaine d'exécution (temps-réel / normal)
● Pas d'impact sur l'écriture de code noyau classique
● Impact sur l'écriture de code temps-réel !
– utilisation des API fournies par le co-noyau
● Excellentes performances TR
– ordonnanceur spécifique indépendant
– sous-système temps-réel bien délimité
– jitter maximal de l’ordre de 10 µs sur Atom/x86 !
27. 27Logiciels libres et SE
RTLinux
● Projet universitaire (NMT) développé par Victor
Yodaiken et Michael Barabanov en 1999
● Produit commercial développé par FSMLabs
● Dépôt d’un brevet logiciel → conflit avec la FSF
● Vendu à WIND RIVER en 2007
● Développement en espace noyau (?)
● Version GPL obsolète (2.6.9) retirée par WIND RIVER
30. 30Logiciels libres et SE
RTAI
● Real Time Application Interface
● Un « fork » de RTLinux développé au DIAPM de l’école
polytechnique de Milan → Dipartimento di Ingegneria
Aerospaziale (Paolo Montegazza)
● Utilisé au DIAPM pour des travaux d’enseignement et
de recherche
● Quelques utilisations industrielles
● Position douteuse / brevet logiciel FSMLabs
● Toujours actif mais peu d’évolution → version 3.8 en
février 2010, 3.9 en août 2012
31. 31Logiciels libres et SE
Xenomai
● Xenomai est un sous-système temps-réel de Linux
– Programmation de tâches en espace utilisateur
– API d'application et de pilotes temps réel
(RTDM) dédiées
● Intégré au noyau Linux → « Real-time sub-system »
● Supporte de nombreuses architectures
● Dispose de « skins » permettant d'émuler des API
temps réel (POSIX, VxWorks, VRTX, uITRON, ...)
● Plus complexe à mettre en œuvre que PREEMPT-RT
mais performances 5 à 10 fois supérieures
● Licence GPL (cœur), LGPL (interfaces, espace
utilisateur)
32. 32Logiciels libres et SE
Architecture générale
● Xenomai utilise un micro-noyau (ADEOS) pour partager
le matériel avec le noyau Linux
● Un processus contient des threads TR et TP (Linux)
micro-noyau
noyau TR
API TR
pilote TR
Processus Linux
33. 33Logiciels libres et SE
Répartition sur les deux domaines
Hardware
VFS/FS ...
Pile réseau Xenomai RTOS
Adeos I-Pipe
Noyau
Code applicatif VxWorks
glibc
Xenomai
libvxworks
Code applicatif POSIX
Xenomai
libpthread
Appels système
glibc
libpthread_rt
Noyau Linux
35. 35Logiciels libres et SE
Android
● Android = un système d'exploitation basé sur un noyau
Linux
● Un « framework » fournissant des applications et
permettant d'en ajouter facilement
● Basé sur Dalvik (puis ART), une machine virtuelle Java
(très) optimisée pour le mobile
● Navigateur web basé sur Webkit puis Chrome
● Graphique optimisé en 2D ou 3D basé sur OpenGL/ES
● Nouvel environnement de développement « Android
Studio » compatible avec Android « wear » (#IoT)
● Partiellement open source mais pas réellement du
logiciel libre...
36. 36Logiciels libres et SE
Android et l'industrie
● Linux fournit des API graphiques (Qt, EFL) mais
« difficiles » à programmer
● Android est avantageux si le projet utilise une IHM
● Base importante d'applications Android !
● Android est conçu pour la téléphonie et les tablettes
mais des BSP Android sont fournis pour les cartes
(ARM) récentes (BB Black, i.MX6, ...)
● Android utilise un noyau Linux :-)
● Assez peu de projets pour l'instant
● Concurrence de Yocto !
37. 37Logiciels libres et SE
Avantages/inconvénients
● Avantages
– Programmation Java (simple et répandue) + IHM
– Communauté importante
– Fait rêver les managers (tablette = grand public → bon
marché)
● Inconvénients
– Compatibilité POSIX partielle
– Système de « build » statique assez rudimentaire par
rapport à ceux de Linux (Buildroot, OE)
– Qualité des BSP variable mais portage « simple »
– Pas réellement un projet libre ni communautaire :-(
– Google fait peur !
– Interfaces matérielles industrielles non supportées
(CAN, I2C, SPI, …)
38. 38Logiciels libres et SE
eCOS
● embeddable Configurable OS (CYGNUS 1997)
● Supporte de nombreux CPU (16), 32 et 64 bits
● Empreinte mémoire de 10 à 100 Ko
● Outils de configuration avancé, gestion de «paquets»
● Version « pro » par
● Utilisé dans le multimédia :
– http://www.ecoscentric.com/ecos/examples.shtml
39. 39Logiciels libres et SE
RTEMS
● RTEMS = Real Time Executive for Multiprocessor
Systems
● Initialement « Missile Systems » puis « Military
Systems »
● Exécutif temps réel embarqué diffusé sous licence libre
(GPL avec exception)
● Ce n'est pas exactement un système d'exploitation car
l'application est « liée » au noyau → un seul processus
mais plusieurs « threads »
● Programmation C, C++, Ada
● Plus de 100 BSP disponibles pour 20 architectures
● API RTEMS « classique » ou POSIX
● Utilisé par EADS Astrium, ESA, NASA, etc.
40. 40Logiciels libres et SE
RTEMS, suite
● RTEMS est un exécutif TR :
– Un seul processus
– Beaucoup plus petit qu'un OS → en sélectionnant les
composants on peut arriver à une taille de quelques
dizaines de Ko :-)
– Pas (peu) de support MMU
– De nombreuses fonctionnalités sont optionnelles :
réseau, système de fichiers, etc.
– Configuration statique de l'application
● Permet d'ajouter « facilement » API, ordonnanceur
● Léger, environ 600K lignes pour la version 4.11 (15 M
pour le noyau Linux)
42. 42Logiciels libres et SE
Typologie des outils
● Outils de base → « toolchain » + mise au point →
GCC, GDB, LLVM
● IDE → Eclipse (?)
● Construction de distribution → Buildroot, Yocto/OE
● Émulation / simulation → QEMU
● Gestion de version (Git, SVN)
→ Les meilleurs de ces outils existent dans le monde
du logiciel libre :-)
43. 43Logiciels libres et SE
Production de distribution (Linux)
● Un outil crée la distribution à partir des sources des
composants adaptés en appliquant des « patch »
● Il ne s'agit pas de distribution mais d'outil de création
de distribution
● L'outil ne fournit pas les sources mais les règles de
production et prend en compte les dépendances
● L'outil peut produire la chaîne de compilation croisée
● L'outil produit les différents éléments de la distribution
– Image du bootloader
– Noyau Linux
– Images du root-filesystem
● Meilleure solution qu'une distribution « générique »
– sécurité
– traçabilité
44. 44Logiciels libres et SE
Les principaux outils disponibles
● Yocto/OpenEmbedded
– Moteur écrit en Python
– Très puissant mais lourd
– Basé sur des fichiers de configuration
● Buildroot
– Basé sur la commande « make »
– Au départ un démonstrateur pour uClibc
– Désormais un véritable outil, bien maintenu !
– Approche statique (pas de paquets)
● OpenWrt
– Dérivé de BR
– Orienté vers les IAD (Internet Access Device)
– Gère les paquets binaires
46. 46Logiciels libres et SE
Buildroot
● Lié au projet uClibc (micro-C-libc) = libC plus légère
que la Glibc
● But initial: produire des root-filesystem simples pour
tester uClibc
● Moteur uniquement basé sur des fichiers Makefile et
quelques scripts-shell →utilisation de GNU-Make
● Outil de configuration utilise le langage Kconfig
● Peut produire la chaîne de compilation (uClibc, Glibc,
Eglibc, ...) ou importer une chaîne existante
● Approche statique
● Pas de version « officielle » avant 2009 (2009.02)
47. 47Logiciels libres et SE
Buildroot aujourd’hui
● Repris en 2009 par Peter Korsgaard et Thomas
Petazzoni
● Une version officielle tous les 3 mois: 2009.02, ...
2012.11, ..., 2015.02
● Projet géré sous Git : http://git.buildroot.net/buildroot
● Bonne documentation :
http://buildroot.uclibc.org/docs.html
● Plus de 1200 composants adaptés (2015.02)
● Support CPU x86, ARM, PowerPC, SH4, ...
● Il est désormais simple d’ajouter un support de carte
par des fichiers de configuration
● Projets très dynamique !
48. 48Logiciels libres et SE
Yocto / OE
● Similaire à BR mais plus évolué et modulaire
● Utilisé par les éditeurs pour leurs produits commerciaux
→ Wind River
● Utilisé par les fabricants de matériel pour les BSP
(Board Support Package) → Freescale, Gumstix, TI, ...
● Yocto n'est pas une distribution mais fournit des
« templates » et outils pour créer des distributions →
« méta données » organisées en couches (layers)
– Support matériel (meta-intel, meta-raspberrypi)
– Distributions (meta-yocto, meta-angstrom)
– Composants « métier » (meta-ivi) → GENIVI
http://layers.openembedded.org/layerindex
It's not an embedded Linux distribution
– it creates a custom one for you
51. 51Logiciels libres et SE
Émulateur QEMU
● Émulateur de matériel initialement développé par
Fabrice Bellard, diffusé sous GPL v2
● Exécuté dans l'espace utilisateur de Linux
● Permet d'émuler diverses architectures: x86, PowerPC,
ARM, etc.
● Émulation de carte complète → outil de
développement, mise au point, test automatique
● Outil de certification DO-178 (Adacore/Couverture)
http://www.open-do.org/projects/couverture
● Désormais, large communauté avec dépôt Git sur
http://git.savannah.gnu.org/cgit/qemu.git
53. 53Logiciels libres et SE
(R)évolution du matériel
● Évolution du x86 vers ARM
● Création d'un marché autour des « hobbyistes » en
électronique
– Arduino, Raspberry Pi & friends
– Adafruit, Snootlab & friends
● Les professionnels utilisent parfois ces plate-formes ou
du moins profitent de la baisse des coûts → attention
au choix !
● Développement et conception simplifiés
– généralisation d'un open-hardware pragmatique
– utilisation de modules CPU
– nouveaux langages (HTML5, Python)
● Nouveaux canaux de distribution et plate-formes de
financement (kickstarter, ...)
55. 55Logiciels libres et SE
Cependant...
● Certaines plate-formes génériques permettent de créer
une « maquette » mais difficilement la version
définitive → qualité insuffisante
● La connectivité nécessaire n'est pas toujours disponible
– Wi-Fi
– BT
– Capteurs divers
● Un créateur n'est PAS un développeur logiciel et
encore moins un intégrateur système → « fusion » art /
design / technologie
● Quelques plates-forme dédiées sont désormais
disponibles → WeIO (démo!)
● Pour l'industrie ne pas oublier la durée de
maintenance !
58. 58Logiciels libres et SE
Situation actuelle
● Les systèmes embarqués deviennent de plus en plus
complexes
– Hier → RTOS mono-tâche (1 seule application)
– Aujourd'hui → système multitâche proche d'un OS
classique (Linux, Android, …)
● Exemples de systèmes :
– Encodeur / décodeur vidéo HD
– Système « mixte » temps réel et traitement des données
(banc de test)
● Le CPU n'est pas forcément capable de répondre aux
exigences fonctionnelles du système
● L'utilisation du multi-cœur améliore les choses mais
décale le problème (et augmente prix + consommation)
59. 59Logiciels libres et SE
Évolution de la conception
● On travaille maintenant au niveau système (ou
fonctionnalité) et non au niveau porte logique
● Les fonctionnalités peuvent être implantées dans des
composants spécifiques de type ASIC (Application
Specific Integrated Circuit). On parle alors de Système
sur Silicium « SoC » (System on Chip).
● Les fonctionnalités peuvent être implantées dans des
composants logiques programmables de type FPGA
(Field Programmable Gate Array). On parle alors de
système « SoPC » (System on Programmable Chip).
● Le plus souvent le système dispose d'un CPU (avec
OS) + d'un accélérateur matériel pour des tâches
dédiés (compression, génération de signal, …)
● L'association des deux parties correspond au « co-
design »
60. 60Logiciels libres et SE
Exemple de système
● Le processeur est en général externe→ SoC associé à
un FPGA
● Exemple de SoC : i.MX (Freescale), AM335x (TI)
● Exemple de FPGA : Altera Cyclone, Xilinx
Spartan/Virtex
● Système hybride : Armadeus, Zynq
61. 61Logiciels libres et SE
Avantages du co-design
● L'OS – et donc le CPU - est déchargé de tâches très
coûteuses (voire inaccessibles) en calcul logiciel
● L'approche FPGA permet de garantir la souplesse →
utilisation d'un langage de programmation (Verilog ou
VHDL) → portabilité sur plusieurs modèles de FPGA
● Cette même approche garantit la propriété intellectuelle
dans le cas de licences parfois contraignantes
– La fonctionnalité « métier » dans le FPGA
– Le pilote (GPL si Linux) est une simple interface
● On trouve des bibliothèques fonctionnelles (des « IP »)
comme avec le logiciel classique → €€€ !
● Le co-design peut également concerner l'association
µP (CPU) / micro-contrôleur reliés – par exemple - par
un bus de type SPI
62. 62Logiciels libres et SE
Association µC / Linux
● Cette approche « hybride » assure un faible coût en
garantissant les performances
63. 63Logiciels libres et SE
Système Linux « pur »
● Cette approche nécessite souvent un adaptation coté
noyau → temps réel (Xenomai, PREEMPT-RT, …)
64. 64Logiciels libres et SE
Choix du matériel
● Solution 1 :
– Module type SoC
– FPGA ajouté à la carte finale
– Nécessite un design matériel
● Solution 2 :
– Module SoC intégrant directement un FPGA
– Xilinx (Zynq), Altera, Armadeus APF27/APF51
– Pas (ou peu) de design matériel
– La demande du marché pousse ce type de solution
65. 65Logiciels libres et SE
Cas d'exemple
● Un système nécessite une horloge de synchronisation
(période = 1 ms)
– Réalisable sur certains systèmes (tâche périodique sur
un GPIO) → Raspberry Pi/ARM + Linux-TR
– Impossible à réaliser sur d'autres architectures (x86)
sans 1 carte PCI dédiée (€€€)
● Une solution hybride utilise :
– Un système sous Linux (architecture x86, ARM, …) non
TR
– Un contrôleur matériel FPGA sur bus USB
– Simple à mettre en place en langage HDL
– Le calculateur Linux pilote le contrôleur par message
USB mais ne gère pas le TR → insensible aux
variations de charge
66. 66Logiciels libres et SE
Raspberry Pi + FPGA
KNJN DragonPCI-E
Bugblat sur bus local
USB