Pourquoi Embedded Strictly C / C ++ [fermé]

Je n'ai pas aimé cette question car il est difficile d'y répondre, mais je peux peut-être reformuler: "Qu'est-ce qui empêche Embedded de changer de langue?"

Par exemple, nous voyons à peu près C / C ++ pour l'embarqué (je pense que j'ai déjà entendu ADA mentionné aussi? Corrigez-moi si je me trompe)

Mais qu'est-ce qui empêche exactement le monde embarqué de changer de langue? Est-ce simplement que C est trop facile à utiliser ou qu'il n'y a tout simplement pas vraiment un "besoin" de changement puisque C fait tout bien?

Cela m'a toujours un peu dérouté, pas que je me plaigne. Depuis le garder dans quelques langues maintient les choses standardisées. Mais la question demeure.

Je me rends compte que c'est une sorte de question subjective, mais ma principale question est "Pourquoi" et non "SI / QUAND"

Tout d'abord: oubliez "embarqué" car ce n'est pas une distinction utile. La propriété primordiale est "contrainte par les ressources". La ressource la plus importante est souvent le temps, auquel cas nous parlons de systèmes en temps réel, mais il peut également s'agir de mémoire ou d'alimentation.

• L'adoption d'une nouvelle langue est difficile et rare. Cela nécessite un recyclage, de nouveaux outils et la recherche d'un bon moyen de travailler avec la nouvelle langue. Cela coûte cher, en particulier pour les premiers utilisateurs. C'est aussi un problème de poule et d'oeuf: sans une grande base d'utilisateurs, il n'y aura pas d'outils et de bibliothèques de bonne qualité, mais sans ceux-ci, il n'y aura pas une grande base d'utilisateurs. Par conséquent, une nouvelle langue doit avoir un grand avantage sur les langues existantes, sinon elle n'aura aucune chance.

• La plupart des nouveaux développements "récents" dans les langues ont comblé l'écart entre la puissance CPU disponible et les besoins de l'utilisateur. En d'autres termes: ils peuvent être inefficaces en vitesse, mais compenser en étant plus faciles pour le programmeur. Pensez à l'essor de langages tels que Java, Python, Perl, Tcl qui sont essentiellement gérés par un interprète (peut-être après une certaine compilation) et qui font un usage intensif de la gestion dynamique de la mémoire. Mais cela ne correspond pas bien au monde aux ressources limitées, où nous voulons tirer le meilleur parti des ressources disponibles, même au détriment de plus d'efforts de programmation, et b) une utilisation prévisible des ressources.

• C et C ++ (ou un sous-ensemble approprié) sont toujours les langages de plus haut niveau qui sont couramment utilisés (suffisamment pour que de bons outils, suffisamment de programmeurs formés et de vastes bibliothèques soient disponibles) qui peuvent répondre à des exigences prévisibles d'espace et de temps qui ne sont pas trop éloignées de ce qui est possible sur le matériel actuel. Je pense que le seul concurrent est Ada, mais il a souffert d'un mauvais départ: les premières implémentations étaient (perçues comme étant?) Trop lentes et inefficaces, et maintenant (même si de bonnes implémentations sont disponibles) le langage a pris un peu de retard dans fonctionnalités (par rapport à C ++). Personnellement, je pense que c'est dommage, toutes choses étant égales par ailleurs, je préfère voler dans un avion programmé en Ada plutôt qu'en avion en C ou C ++.

Avec les systèmes embarqués basés sur des microcontrôleurs 8 et 16 bits, il se résume à développer plus facilement des logiciels pouvant s'adapter aux ressources limitées de ces limitations de stockage très modestes (peut-être quelques 100 octets). de RAM pour les microcontrôleurs 8 bits bas de gamme). , avec 2-8 Ko de ROM ou EPROM / Flash pour le stockage de code).

Dans ces cas, les petits langages comme C ou l'assembly ont tendance à être les langages de développement les plus couramment utilisés. À titre de comparaison relative très approximative, un assembleur complet et un compilateur C99 peuvent tenir sur une seule disquette, tandis que vous avez besoin de plusieurs MiB pour un système de développement C ++ moderne (avec STL, etc.).

Lorsque vous regardez des micros haut de gamme (16 bits haut de gamme, et principalement 32 bits, avec 64 bits assez rares) et DSP dans des environnements intégrés, les restrictions s'affaiblissent et le développement de logiciels peut constituer l'essentiel du développement Il est donc logique d'utiliser les outils de développement les plus productifs, y compris des langages plus avancés avec des fonctionnalités telles que les langages de programmation orientée objet (POO) tels que C ++, et des langages plus récents (Java, Perl, Ruby, Python).

Il est possible dans l'assemblage et C de prédire la quantité de mémoire utilisée, de sorte qu'une conception à espace limité soit possible, mais des fonctionnalités avancées telles que les modèles, la gestion des exceptions et la liaison au moment de l'exécution rendent impossible de connaître exactement l'empreinte mémoire nécessaire pour un programme C ++ standard à l'avance. Je ne connais pas assez MISRA C ++ , qui est un sous-ensemble de C ++, pour le commenter.

Les langages basés sur des machines virtuelles exécutant du code octet (Java, Perl, Python) sont moins matures dans l'expérience du développeur intégré, et comme ces langages sont conçus pour isoler le programmeur du matériel particulier, il est également plus difficile d'être conscient de les limites et restrictions de ce système matériel embarqué. C'est moins un problème avec les processeurs 32 bits rapides (par exemple ARMv7) avec MiB sinon GiB de RAM.

Toutes les implémentations BASIC que je connais sont assez simplistes dans les fonctionnalités du langage, restant largement fidèles à l'héritage de Dartmouth BASIC des années 1960. Cela signifie que le langage n'a pas de bibliothèques d'exécution complexes ou de gestion des exceptions, et un interprète ou un compilateur est assez simple à écrire et est également de petite taille. La plupart des microcontrôleurs disposent d'au moins un compilateur BASIC.

J'espère que les grandes lignes expliquent les raisons pour lesquelles vous trouverez le C et l'assemblage principalement utilisés sur des systèmes embarqués plus petits ou plus anciens, et avec les limitations des nouveaux systèmes embarqués de moyenne à haute gamme ne diffèrent que légèrement d'un ordinateur de bureau traditionnel.

La plupart des réponses indiquaient déjà les raisons historiques (bien connues, tout le monde l'utilise, il ne serait pas facile de changer les habitudes, etc.). Bien que je sois d'accord avec eux, nous devons garder à l'esprit qu'il existe une autre raison importante.

Ce n'est pas que "C est un mauvais choix ou obsolète mais nous l'utilisons toujours par habitude" (comme les claviers QWERTY).

C est en soi un très bon choix pour le développement embarqué, en particulier dans les applications à temps critique. Pourquoi?

• il est suffisamment bas pour être facilement utilisé pour mettre en œuvre des programmes en temps réel. Si vous devez mesurer le temps en nanosecondes, devez intercepter une interruption toutes les 5 microsecondes ou utiliser exactement 64 octets de RAM totale, alors avec un langage de très haut niveau, il serait le plus souvent impossible ou très difficile à résoudre . C vous donne un bien meilleur contrôle sur le matériel que les langages de niveau supérieur, c'est l'une des différences les plus importantes entre le développement pour embarqué et PC.

• il est suffisamment élevé pour être rapide et facile à coder, par rapport à Assembly.

Ainsi, C est le meilleur (ou l'un des meilleurs) compromis entre la vitesse et l'accès matériel direct d'Assembly, et la lecture et la compréhension faciles des langages de haut niveau.

C'est exactement la même raison pour laquelle en programmation régulière les langages (les plus utilisés) ne changent pas (vraiment):

1. Énorme quantité de code existant (bibliothèques / implémentations existantes)
2. Grand ensemble d'outils pouvant fonctionner avec ces langages (IDE, simulateurs, ...)

Dans le monde embarqué, il peut être beaucoup plus difficile (voire impossible) de fournir des mises à jour logicielles, et il est donc d'autant plus essentiel de garantir l'exactitude. Malheureusement, C fournit très peu d'aide à cet égard et permet au programmeur de jouer rapidement et librement.

Cela me fait mal d'utiliser le C pour les systèmes embarqués, et j'aimerais au moins pouvoir passer au C ++ pour les nombreux avantages qu'il offre sous la forme de contraintes comme const, références, typage stringer, etc.

Je suppose que la réponse est simplement que nous sommes coincés avec C parce que le changement n'est pas commercialement viable. Tout le monde connaît C, il y a des tas de compilateurs pour lui, des bibliothèques pour lui et des outils pour le générer. Avec une nouvelle langue, nous partirions de zéro.

Je suppose que c'est pourquoi les gens utilisent toujours PHP .

Personne ici n'a entendu parler de SPARK Ada?

Il s'agit d'une "petite" version du langage Ada et des outils de développement associés pour les systèmes embarqués, par exemple l'avionique et d'autres applications critiques pour la sécurité comme les équipements médicaux.

Des études ont montré une perte de vitesse de traitement de 5 à 10% par rapport à C / C ++ avec le codage SPARK plus fiable.

Je pense que la prolifération du C dans les systèmes embarqués est due à des raisons économiques:

• Il est déjà là et généralement utilisable pour la plupart des applications - et la plupart des applications en volume ne sont pas critiques, personne ne mourra si la machine à laver déborde - alors pourquoi changer?

• Le jeu d'outils SPARK va représenter une dépense supplémentaire en soi et pour la formation du personnel à son utilisation.

• Les avantages supplémentaires de SPARK (ou d'autres langages non-C) pour le contrôleur / système de gestion intégré peuvent ne pas être suffisants pour justifier la prime nécessaire dans le prix du produit aux yeux du consommateur - surtout quand ils voient des marques concurrentes apparemment "bonnes" vendre pour un prix inférieur.

• La société AdaCore prend soin de ne pas aller trop loin dans les applications du marché de masse, car celles-ci exigeront inévitablement une forte augmentation du personnel de support technique pour traiter les problèmes non essentiels. AdaCore est une société d'expertise de haut niveau, fière d'elle-même et propose ses produits et services à des entreprises de haute technologie. Il est inhabituel qu'une langue pénètre de nouveaux marchés à moins que ses principales parties prenantes ne le veuillent vraiment.

Alors, @ Wouter, vous n'avez pas à vous soucier de mourir dans le ciel faute de code intégré Ada!

Il est déjà dans les systèmes d'avion depuis de nombreuses années. De même pour votre stimulateur cardiaque.

Mais pour le lave-vaisselle, le système de contrôle des services du bâtiment, le contrôleur de la fournaise de laboratoire et d'autres arènes pas si strictement réglementées - cela vaut-il la peine économiquement d'aller plus loin?

Je suppose que la principale raison de la popularité de C est que premièrement: C est populaire et beaucoup de gens le savent et deuxièmement: Aucun des nouveaux langages populaires comme Java, C # et même de nombreux aspects de C ++ ne conviennent au travail intégré. Fondamentalement, les 3 autres langues que j'ai mentionnées dépendent beaucoup de la mémoire dynamique, ce qui entraîne une exécution non déterministe du programme, des objets, qui apportent de la mémoire dynamique avec eux, de grandes exigences en mémoire (car l'un des aspects les plus importants de l'OO est l'utilisation de plus grand nombre de classes), la popularité croissante de la compilation juste à temps (et de nombreuses plates-formes embarquées ne peuvent même pas du tout compiler leur propre code C) ...

Il y a aussi le fait que la plupart des bibliothèques livrées avec Java ou C # sont inutiles pour un grand nombre de projets intégrés.

D'un autre côté, nous avons des langages plus anciens comme Pascal ou Basic. De mon point de vue, ils ne sont pas aussi populaires parce que C s'est fait le langage "standard de l'industrie" et un très grand nombre de programmeurs et d'ingénieurs apprennent le C aujourd'hui. Dans certaines écoles, Pascal ou Basic ne sont même pas appris. Il y a aussi le fait que de nombreux langages populaires aujourd'hui ont une syntaxe de type C et l'utilisation de Pascal serait étrange pour un programmeur C.

Quant au FORTRAN, je suppose qu'il est entré dans un domaine de niche et est principalement utilisé par des ingénieurs et des scientifiques travaillant dans des zones où il existe un écosystème approprié pour son utilisation. Je ne vois aucune raison particulière (autre que celles que j'ai mentionnées pour Pascal et Basic), il n'est pas utilisé sur les systèmes embarqués.

Notez que dans cette réponse, je me suis concentré principalement sur les petits systèmes. Il existe également de nombreux périphériques embarqués qui utilisent des systèmes d'exploitation plus complexes tels que GNU / Linux ou un autre dérivé Unix et pour les programmer, plus ou moins n'importe quel langage popualr peut être utilisé.

C est un langage très simple, et a été plus d'une fois appelé langage d'assemblage de fantaisie . C'est presque la quantité minimale d'abstraction que vous pouvez fournir au-dessus du code assembleur, car les constructions C mappent assez directement sur les constructions au niveau de la machine.

Pour cela et plusieurs autres raisons, il est très facile d'implémenter un compilateur C sur une nouvelle puce. Une grande partie du travail est déjà fait, il y a relativement peu de complexité ou de problèmes, et le contrôle de bas niveau vous permet de gérer assez facilement les caprices de votre matériel.

C ++ peut être (en fait à l'origine était) implémenté en tant que couche de traduction de code source au-dessus de C, ce qui signifie que vous obtenez gratuitement C ++ (ou au moins une version de celui-ci) avec votre compilateur C.

Avec C et C ++, vous disposez d'un bootstrap à peu près tout ce dont vous avez besoin pour votre nouvelle puce, ce qui en fait l'endroit logique pour commencer.

Certaines raisons que les autres n'ont pas mentionnées:

• Espace problématique: C convient aux systèmes petits et simples. Si tout ce que vous faites est de réagir aux signaux externes et de pousser quelques chiffres, alors C fonctionne plutôt bien (pas de structures de données complexes, pas de malloc, pas de gestion d'erreur complexe).

• Volume de production: si vous avez de grandes séries de production, il est économiquement judicieux d'économiser sur chaque unité matérielle et de dépenser plus pour les programmeurs, car la programmation est un coût unique.

Je pense que c'est parce que C / C ++ sont les langages de bas niveau et de haut niveau.

En fait, pour les petits systèmes embarqués, C est beaucoup plus populaire que C ++. Et la raison en est la même que pour ne pas utiliser d'autres langues. C ++ nécessite un runtime, sauf si vous cédez la plupart des fonctionnalités qui le rendent différent de C.

Mis à part l'assemblage, C est le seul langage que je connaisse qui compile en code natif et pour lequel avoir un runtime est facultatif. Il est donc garanti d'être la plus petite empreinte et le temps d'exécution le plus rapide dans un environnement restreint (sauf si vous utilisez l'assemblage).

D'un autre côté, dans les systèmes embarqués moyens et grands (j'entends par là plus de mémoire et d'horloge, une plus grande taille de mot), je ne dirais pas que C (ou C ++) est si répandu. J'ai vu des systèmes prenant en charge Python, Forth ... même Java.

Mais bien sûr, vous avez presque toujours la possibilité d'utiliser C / C ++, évidemment, pour les mêmes raisons que celles mentionnées ci-dessus. Et ayant l'option, et étant vous-même quelqu'un qui est déjà à l'aise avec C pour small-embedded, pourquoi choisiriez-vous une autre langue?