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

15

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"


la source
2
Y a-t-il un langage de niveau supérieur particulier que vous aimeriez voir sur les systèmes embarqués? EDIT: ou plutôt, quelles sont les fonctionnalités de langage qui vous intéressent que C ne fournit pas?
Jon L
1
@ JonL - Il y a un tas de fonctionnalités de bas niveau que j'aurais aimé avoir. EG meilleure manipulation bit / nibble / octet / mot à l'intérieur de grands nombres entiers. Un meilleur support de sécurité, par exemple les types de fonctionnalités d'Ada.
Rocketmagnet
3
Embedded n'est pas strictement C. Voici un tas de langages de haut niveau pour les systèmes embarqués: electronics.stackexchange.com/questions/3423/…
Kellenjb
1
"Embarqué" a différentes significations. Un microcontrôleur 4 bits exécutant un grille-pain est différent d'un ECU ou d'un décodeur. Ce spectre rend votre question difficile à répondre.
Toby Jaffey
1
Et, comme prévu, cela a été fermé. J'espérais que cette question recevrait des réponses de haute qualité et que les gens travailleraient pour la garder comme une grande question, ce n'est pas le cas. Au lieu de cela, nous obtenons de nombreuses réponses qui sont une phrase qui reçoit plusieurs votes positifs, nous avons une réponse qui est une prose qui a une guerre contre les votes négatifs avec des drapeaux à gogo, et les autres réponses ont généré plus de drapeaux en 1 jour, puis le reste du site combiné . Le problème est que pour de nombreuses personnes, il existe de nombreuses bonnes réponses différentes pour expliquer pourquoi elles n'ont pas changé.
Kortuk

Réponses:

18

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 ++.

Wouter van Ooijen
la source
+1 - belle réponse. Ada semble un langage intéressant, existe-t-il des compilateurs Ada pour les petits micros?
Oli Glaser
Il y a GNAT, le compilateur GCC Ada. Mais AFAIK, il n'a pas été beaucoup utilisé sur les micros, vous aurez donc du mal à trouver quelque chose qui est prêt à fonctionner.
Wouter van Ooijen
Ouais, j'ai vu GNAT mentionné sur la page Wiki. Vous avez raison, pas grand-chose pour les petits micros, mais il semble y avoir un bon support (comme vous vous en doutez) pour les trucs critiques sur 68k, x86, MIPS, etc. (par exemple DDCI )
Oli Glaser
Je vois qu'il y a aussi SPARK Ada, comme mentionné par Deek ci-dessous. Je vais devoir vérifier quand j'aurai quelques trucs insaisissables qu'ils appellent le temps ...
Oli Glaser
2
Ada, sous la forme de Gnat, fonctionne très bien sur le microprocesseur AVR, comme on le voit dans Arduino. Le plus petit exécutable Gnat que j'ai construit était de 65 octets. Certes, il n'a fait que clignoter une LED, bien que l'esquisse Arduino équivalente soit supérieure à 1K. Au moment où mon exécutable a atteint 600 octets, il entraînait 2 moteurs pas à pas indépendamment ... Vous n'avez pas besoin de SPARK - sauf si vous voulez prouver que votre clignotant LED est formellement correct!
Brian Drummond
9

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.

mctylr
la source
5

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.

vsz
la source
1
Je pense qu'un aspect majeur en faveur de C est qu'il permet d'optimiser le code pour une plate-forme particulière tout en permettant à ce code de s'exécuter (peut-être pas aussi efficacement) sur d'autres. Sur quelque chose comme un PIC, de nombreuses instructions C se traduiront de manière prévisible en instructions machine; une boucle comme celle- unsigned char i=63,j=128; do {something;} while(--j); while(--i);ci ne sera pas aussi lisible que unsigned int i=16000; do {something;} while(--i);, mais elle s'exécutera plus rapidement et sera plus efficace sur le PIC. Si le code était déplacé vers l'ARM, la deuxième approche serait plus efficace, mais la première fonctionnerait toujours.
supercat
4

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, ...)
Sam
la source
4

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 .

PHP double claw hammer.

Rocketmagnet
la source
Si vous voulez discuter de la question, utilisez des commentaires ou une méta, si vous voulez tapoter l'utilisateur dans le dos pour une bonne question, voter ou commenter.
Kortuk
Vous pouvez toujours utiliser Pascal - il semble avoir les limitations supplémentaires que vous recherchez :-). Ou une forme de Super-Lint.
Russell McMahon
2
Une raison probablement très importante pour C est qu'il est bien plus facile d'écrire un compilateur C de base qu'un compilateur C ++. J'en ai travaillé un pendant un moment avant que des tâches plus importantes ne m'éloignent. Truc amusant! Vous écrivez un compilateur C ++? Pouah. Je préfère cependant le C ++ en tant qu'utilisateur.
darron
1
@RussellMcMahon - Je ne peux pas utiliser Pascal, car il n'y a pas de compilateur Pascal pour les MCU que j'utilise.
Rocketmagnet
@darron - C'est un très bon point. Cependant, il existe de très bons compilateurs C ++ open source, comme gpp. Ils auraient juste besoin d'écrire un back-end pour cela.
Rocketmagnet
4

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?

Deek
la source
Intéressant, merci - je n'avais pas entendu parler de SPARK, allez le vérifier.
Oli Glaser
Certaines études montrent une accélération par rapport à une application existante en C - regardez le serveur DNS "Ironsides" ...
Brian Drummond
3

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é.

AndrejaKo
la source
1
C est populaire parce que C est populaire? :-)
stevenvh
2
@stevenvh Oui, c'est vrai. C'est une sorte de boucle de rétroaction positive. Plus il est populaire, plus il devient populaire.
AndrejaKo
3

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.

tylerl
la source
3

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.

starblue
la source
2

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

Amit Tomar
la source
1

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?

fceconel
la source
4
C ++ peut générer beaucoup de surcharge mais le compilateur C ++ entièrement conforme que j'ai utilisé pour MSP430 ne nécessitait pas d'exécution, C ++ a compilé en code natif. Je suis désolé, dire aux autres est un mauvais service et je vous ai déçu. Vous pouvez supprimer le downvote en fournissant des références qui me convainquent que je me trompe (ce qui sera difficile, j'ai lu la liste des assemblages de C ++ compilé pour mes projets, en partie pour m'assurer qu'il compile efficacement) ou vous pouvez supprimer votre réponse qui supprimera l'affect sur votre réputation (bien qu'à ce stade, vous recevez +8 net rep)
Kortuk
3
Je suis entièrement d'accord avec Kortuk. Certaines parties de C ++ nécessitent une prise en charge étendue au moment de l'exécution, mais la partie qui ne l'est pas est toujours un bien meilleur C (et entièrement OO). La restriction de ce sous-ensemble est facilement appliquée par certains commutateurs du compilateur et de l'éditeur de liens. Dans certaines parties (le redoutable printf par exemple), C ++ a au moins le potentiel de langage pour nécessiter beaucoup moins de support d'exécution (si seulement std :: cout a été implémenté avec de petits systèmes à l'esprit ...)
Wouter van Ooijen
1
@Kortuk, désolé de ne pas être clair là-bas, mais quand j'ai dit que "C est le seul langage qui ..." ne voulait pas dire que C ++ n'a pas ces deux choses, je voulais dire que C avait la combinaison des deux et C ++ en a un. Mon accent était mis sur la partie runtime. Je ne dis pas non plus qu'il est complètement impossible d'utiliser C ++ sans runtime, mais c'est assez inhabituel. Je ne vois pas comment vous pouvez avoir des choses comme la gestion des exceptions et RTTI sans runtime, par exemple, et ce sont des fonctionnalités assez importantes. Mais je m'excuse si la façon dont j'ai exprimé cela a conduit à de possibles idées fausses.
fceconel
@fceconel, je n'ai jamais utilisé C ++ avec un environnement d'exécution, et nous discutons des systèmes embarqués ici, je n'ai jamais utilisé d'exécution sur mes microcontrôleurs. Cette question est un peu différente alors vous l'avez peut-être lue, elle demande pourquoi C / C ++ sont les seuls choix répandus, pas pourquoi C au lieu de C ++. J'avoue, en utilisant quelque chose d'aussi simple que cout ne se produira jamais dans mon micro, j'ai quelques broches gratuites, pas un écran.
Kortuk