Justement, comment fait-on pour trouver "simplement" ce type de carte ?
Est-ce qu'il y a des sites qui répertorient en fonction de ce qu'on veut ? (processeur, connectivité)
Justement, comment fait-on pour trouver "simplement" ce type de carte ?
Est-ce qu'il y a des sites qui répertorient en fonction de ce qu'on veut ? (processeur, connectivité)
Beaucoup de choses ont été listées, presque toutes vraies (compilateurs vieux ou non standard ou inexistants, grande variabilité des processeurs utilisés, problème majeur des allocations de mémoire et des exceptions, etc.). Il y a encore certaines idées reçues qui trainent... (les exceptions C++ "mal comprises" par les programmeurs embarqués... pardon ? S'il y a vraiment un truc que les programmeurs embarqués comprennent fondamentalement avec leurs tripes, c'est bien le traitement robuste de tout type de situation exceptionnelle, qu'elle soit C++, matérielle, asynchrone, velue, ou verte à pois rouges...).
Je voulais rajouter deux ou trois idées en vrac:
Capabilité du processeur
Certains processeurs ne proposent que le C car ils n'ont tout simplement pas les instructions nécessaires pour implémenter certains concepts fondamentaux du C++. Certains se souviennent du fait qu'il fallait utiliser un 68020 au lieu d'un 68000 pour pouvoir accéder à certaines instructions atomiques nécessaires à l'implémentation d'un OS multiprocesseur, eh bien c'est pareil aujourd'hui pour certaines choses, comme par exemple les vtables pour la POO (il fut un temps pas si ancien où on n'avait carrément aucune possibilité d'indirection en GPU, ni même les moyens d'itérer sur une table d'adresses.).
Exception et conception.
Dans certains cas d'embarqué (comme l'ont souligné beaucoup, c'est un terme peu précis, je parle donc de la frange des instruments autonomes), le besoin d'exception dans le code indique un problème de conception dans le matériel. Ça peut paraître curieux aux programmeurs OS/web/client riche, mais c'est dû au fait que le programmeur embarqué travaille de concert avec le concepteur du système complet, et qu'il n'existe parfois tout simplement pas d'environnement extérieur à qui reporter une exception. Dans certains cas on peut se contenter d'une solution à la watchdog, mais quand on ne peut pas se le permettre, on se focalise sur l'élimination dans le matériel de la raison pour laquelle le logiciel a besoin d'une exception.
Décoration du C++
On peut aussi mentionner les cas où on contrôle le firmware. Pour ceux qui ne sont pas familiers avec ce genre de projet, on peut se placer dans le cas d'un modèle de programmation ultra moderne (microprocesseur dit "softcore"), avec ciblage possible par gcc, tout en permettant certaines fonctions intrinsèques câblées qui sont totalement spécifiques à l'application. A coté, le C ou même l'assembleur x86 parait de très haut niveau. Exemple typique en traitement de signal: classe de nombres sur 19 bits normalisés entre -0.93 et +0.6 à étagement exponentiel, sans division mais avec convolution câblée. Ou à l'inverse monter en abstraction et câbler un double dispatch, apparaissant comme du C++ natif moyennant un peu de magie par préprocesseur. Cela n'est pas si frivole que ça en a l'air, surtout en traitement numérique ou l'on peut, par une écriture très naturelle, enchainer les opérations sans se préoccuper du type réel à l'exécution des opérandes. C'est très léger à l'exécution (câblé), mais peut demander un pré-traitement lourd si on veut être général... ce qui est très rare en embarqué . Nous avons ainsi une "petite" librairie sympa VHDL où on manipule des signaux de type variable comme s'ils étaient des flottants à multiplication spéciale, tout en ne dégradant jamais le type résultat.
Edit: ce n'est pas clair dans la rédaction originale: même si on génère le code par gcc, un microprocesseur softcore est souvent limité à l'"embedded C++", qui est un sous ensemble finalement très limité du C++. Par exemple on a des constructeurs, mais pas de polymorphisme. Des gestions d'interruptions matérielles, mais pas d'exceptions logicielles (!). Etc.
un exemple: sur certains procs il est (était) impossible de sauter à une adresse "indéfinie", telle qu'une adresse contenue dans un registre. Il est seulement possible de sauter à une adresse absolue (connue a la compilation donc) ou bien un offset de la position courante (pour faire des if ou des bidules comme ca).
Salut,
Je crois qu'il y a 2 choses distinctes : la nécessité d'une robustesse 'à toutes épreuves' et le transport d'erreur par exceptions pour son traitement au niveau approprié. Et c'est là où je disais que les exceptions au sens C++ sont souvent mal comprises. Le rejet des exceptions pour cause de surcoût en termes de code, je comprend et j'adhère. En revanche, j'ai vu souvent le rejet des exceptions pour des raisons plus fumeuses qui me semblaient traduire plutôt une mauvaise compréhension de leur rôle et de leur fonctionnement. Ce qui aboutit souvent au final à de fausses robustesses.
Ceci dit, si tu as eu la chance de bosser sur des projets embarqués avec une équipe ayant une bonne compréhension du C++ alors c'est un signe de mutation encourageant.
Il y a un domaine où le C++ n'a pas sa place en embarqué, c'est dans le cas des applications aéronautiques régies par le standard DO-178B.
En fait, ce sont même l'ensemble de la programmation objet qui n'est pas autorisée même s'il existe un document sur cette utilisation. Bon, ça changera peut-être pour la révision C du standard.
Dans ma boite un petit projet embarqué C était en train de devenir un vrai monstroplante ( malloc, et realloc de partout difficile a suivre )
On l'as réécrit en c++ sans allocation dynamique avec des jolies classes.
la perfo était au rendez-vous, les évolutions suivantes sans problèmes.
la cible est basé sur un freescale EPPC-4xx avec gcc 2.95, du coup le c++ était dispo et la cible "suffisamment" puissante.
Ben si vous avez réussi à le refaire sans allocation dynamique en C++, c'est que c'était faisable en C aussi alors ?
Donc, c'est un problème de conception à l'origine.
Pour ce qui est des perfs, c'est forcément mieux, vu le temps que prend l'allocation dynamique.
Je n'ai rien vu dans les url que tu mets en lien qui semble interdire l'utilisation du C++ ou de l'orienté objet. Je les ai parcourrues vite, donc si tu as un lien plus précis... Comme d'un autre côté, je sais que le C++ est utilisé par certaines compagnies fabriquant des avions...
En fait, la DO-178B ne précise rien sur la programmation objet en tant que telle, car "livrée" en 92, et c'est la raison d'être du second document. Donc, en effet, le C++ n'est pas proscrit de la DO.
Ceci dit, les niveaux B et A demande une vérification du code (source et objet au sens généré) au niveau branchement et instruction ce qui peut poser des problèmes dans le cas de l'utilisation du polymorphisme, me semble-t-il (cf. la présentation
J'oubliais de dire que dans le cadre de la DO-178B, les compilateurs et RTOS doivent être certfiés
Je découvre ce fil et je voudrais signaler juste ceci.
Le dernier ouvrage de Stroustrup Programming : Principles and Practise Using C++, décembre 2008, contient un chapitre entier consacré à l'embarqué : chapitre 25 Embedded Systems Programming. Très intéressant.
D'autre part dans Masterminds of Programming : Conversations with the Creators of Major Programming Languages (par Biancuzzi et Warden), le premier chapitre est une interviouve de Stroustrup. Il évoque le rôle du C++ dans l'embarqué.
On y lit ceci notamment :
I helped write the coding guidelines for the mission-critical software for Lockheed Martin's Joint Strike Fighter. That's an "all C++ plane". You may not be particularly keen on military planes, but there is nothing particularly military about the way C++ is used and well over 100,000 copies of the JSF++ coding rules have been downloaded from my home pages in less than a year, mostly by nonmilitary embedded systems developpers, as far as I can tell.C++ has been used for embedded systems since 1984, many useful gadgets have been programmed in C++, and its use appears to be rapidly increasing. Examples are mobile phones using Symbian or Motorola, the iPods, and GPS systems. I particularly like the use of C++ on the Mars rovers: the scene analysis and autonomous driving subsystems, much of the earth-bases communication systems, and the image processing.
Par parenthèses, ceci contredit donc frontalement ce qui a été dit plus haut :
A l'époque ou je faisais du ferroviaire, il y'avait les normes SIL (de 1 à 4) et plus tu montais de niveau plus les contraintes étaient forte et le jeu d'instruction réduit.
Pour l'ada par exemple les structure à partie variante est les allocations dynamique disparaissait dès le niveau 2. Tu devais aussi sortir des rapports de couverture de code pour les tests unitaire qui incluaient les conditions d'entrées dans les branches avec un algorithme du style:
tu devais prouver que tu étais rentré dans la branche avec
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 si (condition_a ou ou condition_b) alors commande_1 finsi
- condition_a = vrai
- condition_b = vrai
- tu devais aussi qu'un test n'étais pas rentré.
Salut jabbounet,
Je suis interessé pour de la documentation SIL niveau 1 à 3.A l'époque ou je faisais du ferroviaire, il y'avait les normes SIL (de 1 à 4) et plus tu montais de niveau plus les contraintes étaient forte
Si tu en as, je suis prenneur.
Je travaille dans l'embarqué pour l'industrie.
La norme SIL est définie pour le secteur de l'industrie.
Je crois que les principaux secteurs ayant définit leur norme de codage sont:
avionnique (DO-178B)
militaire
industriel (SIL 1à4).
médical.
Malheureusement je ne les ai plus.
Le niveau SIL correspond surtout au niveau de réduction de risque que tu souhaite atteindre avec ton système.
Par exemple pour un train, Le système qui gère le freinage ou qui vérifie que les portes sont bien fermées avant de partir le sera probablement sil 2 ou 3, contrairement au système de climatisation.
Appliqué à un langage informatique, il faut évaluer le risque que chaque instructions ne fasse pas ce qu'elle doit faire voir t'envoie dans un code qu'il n'etait pas prévu d'exécuter (cela s'appelait un hors-code à l'époque ou j'étais dedans).
A partir de là tu cherche le moyen de te protéger de ce phénomène (système redondé, prédétermination des signatures de ton code, interdiction des instructions pouvant créer des problèmes comme les allocation dynamique, ...)
Tu peux avoir des normes relative a la sureté de fonctionnement ici par exemple (mais c'est payant).
http://www.iec.ch/functionalsafety/
http://www.61508.org/index.htm
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager