Discussion :

[Michael Guilloux]

Quels langages utilisez-vous pour le développement de systèmes embarqués ?

Quels langages utilisez-vous pour le développement embarqué ? Dans un sondage à choix multiples similaire lancé il y a quelques années, le langage C s’est avéré le plus utilisé par les répondants, avec plus de 60 %, suivi par le C++ avec 29,41 %. Le top 5 a été complété par le langage Assembleur (20,59 %), Ada (17,65 %) et .Net (11,76 %).

Sondage Developpez.com (2013) : Quel langage utilisez-vous pour le développement embarqué ?

Il faut noter que plusieurs langages de programmation se veulent dédiés à l’embarqué. Parmi ces langages se trouvent Ada et le langage assembleur, ce dernier restant encore un choix approprié pour les systèmes soumis à des contraintes sévères de temps réel. Des langages proches de la machine comme le C et dans une moindre mesure le C++ sont aussi utilisés ; ce qui justifie leur position dans le dernier sondage.

C et C++ confortent également leur place respective dans le dernier classement de l’IEEE des meilleurs langages pour les systèmes embarqués. On voit aussi d’autres langages tels que Arduino, Haskell, D, LabVIEW et VHDL qui sont bien classés.

IEEE 2016 : meilleurs langages pour le développement de systèmes embarqués

En dehors de certains langages populaires (à usage général) qui reviennent dans les deux classements, il peut être important de donner quelques précisions sur les différents langages :

• Arduino : il s'agit du langage natif pour le microcontrôleur Arduino, qui est devenu la base d'un grand nombre de dispositifs de fabrication et de prototypage ;
• LabView : créé par National Instruments, LabView est conçu pour l'acquisition de données et le contrôle industriel ;
• VHDL : VHSIC Hardware Description Language (VHDL) est un langage de description matériel utilisé dans la création et l'analyse de circuits électroniques ;
• Ladder Logic : il s'agit d'un langage de programmation destiné au développement de contrôleurs logiques programmables industriels ;
• Erlang : créé par Ericsson pour les applications de téléphonie embarquées, la publication d'Erlang en tant que langage open source en 1998 a renforcé sa popularité parmi les programmeurs qui développent des applications qui doivent gérer de nombreuses tâches simultanées ;
• Verilog : comme VHDL, Verilog (ou Verilog HDL) est un langage de description matériel utilisé dans la création et l'analyse de circuits électroniques ;
• Ada : à l'origine conçu pour le département de défense des États-Unis, Ada est utilisé pour des applications où la fiabilité est critique, comme les systèmes de contrôle aérospatial ;
• TCL : il s'agit d'un langage de script destiné au prototypage rapide et supportant l'interface utilisateur graphique Tk utilisée principalement avec les systèmes Unix ;
• Forth : conçu à l'origine pour contrôler les radiotélescopes, Forth est toujours utilisé pour des applications telles que les boot loaders et d'autres firmwares ;
• Scade : il s'agit d'un langage pour l'embarqué critique. C'est le langage de modélisation de SCADE Suite, un environnement de développement intégré pour la conception de systèmes critiques.

Et vous ?

Quels langages utilisez-vous pour le développement embarqué ? Pourquoi ?
Lesquels préférez-vous ? Et dans quels domaines ?

Voir aussi :

Forum Systèmes embarqués
Rubrique Systèmes embarqués

[RyzenOC]

autre :
J'utilise Python et Go, (on peut produire des exécutables autonome en python et en go, pas besoin de se trimbaler l’interpréteur python au complet, j'arrive à produire des programmes < 10mo consommant 5.18 mo de ram)

Pour moi python à parfaitement sa place dans ce classement, je suis assez surpris de pas le voir.

[Steinvikel]

N'est-il pas surprenant que python ne soit pas représenté ?
Je me pose la question au vu des nombreuse carte grand publique de prototypage arduino, raspberryPy... où python permet de faire simplement et rapidement qqch de "fonctionnel" avec peu de connaissances.

[FABSGC]

Personnellement, j'ai recours au C et au C++ en développement embarqué

[hotcryx]

autre :
J'utilise Python et Go, (on peut produire des exécutables autonome en python et en go, pas besoin de se trimbaler l’interpréteur python au complet, j'arrive à produire des programmes < 10mo consommant 5.18 mo de ram)

Pour moi python à parfaitement sa place dans ce classement, je suis assez surpris de pas le voir.

Des exécutables??

Perso, j'utilise Java pour Android.

[Ashkandie]

Il faut voir ce que l'on appel embarqué, pour avoir travaillé pendant quelques années sur des systèmes embarqués, on codait uniquement en C ou en Assembleur. Les ressources mémoires étaient ridicules (de l'ordre de quelques Ko), et la fréquence mémoire très faible (quelques Mhz) donc de base tout ce qui est interprété on oublie. Si maintenant les RPi et autres cartes du même genre entrent dans la catégorie de l'embarqué, vu le proc et la mémoire dont on dispose, on peut faire comme bon nous semble.

[RyzenOC]

Des exécutables??

Perso, j'utilise Java pour Android.

oui, avec PyInstaller tu peut avoir un elf avec ces lib .so et .a dans le même dossier (même chose sous Windows, .exe avec ces dll)

les matos embarqué que j'ai développé c'est un mini ordinateur monocoeur arm avec 64mo de ram sous une version custom de linux à base de busybox.
je code pas sur la machine à lavé avec 3ko de ram.

[AoCannaille]

Il faut voir ce que l'on appel embarqué, pour avoir travaillé pendant quelques années sur des systèmes embarqués, on codait uniquement en C ou en Assembleur. Les ressources mémoires étaient ridicules (de l'ordre de quelques Ko), et la fréquence mémoire très faible (quelques Mhz) donc de base tout ce qui est interprété on oublie. Si maintenant les RPi et autres cartes du même genre entrent dans la catégorie de l'embarqué, vu le proc et la mémoire dont on dispose, on peut faire comme bon nous semble.

Carrément, RPi est un nano ordinateur, pas une carte embarquée!

D'ailleurs, pour moi, ma définition de l'embarqué, c'est une carte sans OS. Quand on voit qu'un RPi peut faire tourner un OS desktop, même pas orienté léger ou temps réèl, on est très loin de l'embarqué...

Pareil pour les smartphones...

[hotcryx]

oui, avec PyInstaller tu peut avoir un elf avec ces lib .so et .a dans le même dossier (même chose sous Windows, .exe avec ces dll)

les matos embarqué que j'ai développé c'est un mini ordinateur monocoeur arm avec 64mo de ram sous une version custom de linux à base de busybox.
je code pas sur la machine à lavé avec 3ko de ram.

Ok intéressant, je ne connaissais pas
J'ai trouvé ceci

https://www.busybox.net/live_bbox/live_bbox.html

[kilroyFR]

C/C++ et C# sous WinCE2013 (mais IHM seulement en C#, pour tout le reste, comm etc. c'est avec des libs (type libcurl etc) en C car sinon les perfs sont catastrophiques et surtout ca nous permet d'eviter au maximum les pbs de ce p*tain de garbage collector en C# (pour moi la pire des inventions car pour supprimer la rigueur dans le developpement on doit maintenant gerer ceci et eviter que l'equipement ne decharge au mauvais moment).

sinon android pour applis smartphone.

[RyzenOC]

Ok intéressant, je ne connaissais pas
J'ai trouvé ceci

https://www.busybox.net/live_bbox/live_bbox.html

ben c'est busybox linux qui tient sur quelques mo.

[Bktero]

Je fais du C et du C++ sur Cortex-M.

Par le passé, j'ai fait beaucoup de Java sur Cortex-M.

Si Raspberry rentre dans "embarqué" ici, alors j'utilise aussi du Python pour un projet perso.

[transgohan]

Je fais du C et un peu d'assembleur sur du 68000 (oui un machin qui date d'avant ma naissance ça me fait me sentir quand j'en parle).
En gros pour ceux qui connaissent pas c'est de la grosse machine à laver, mais c'est super loin d'un smartphone ou RPi.
Et encore... Je reste persuadé que certains constructeurs mettent plus puissant que ça dans une machine à laver en mettant une usine à gaz dans le code.

[Steinvikel]

Corrigez-moi si je me trompe, mais le terme "embarqué" est plutôt flou, je suppose que tout le monde se rejoins sur la notion d'élément autonome et isolé (physiquement, pas forcément non-connecté).
ex : Un module de contrôle de cuve (température, pression, niveau, gaz...) raccordé au secteur et au réseau, c'est de l'embarqué.
Pour le reste, la définition diffère pour tout le monde :
- avec ou sans OS >> dans tout les cas ça reste un (des) programme qui fait tourner le système (aussi petit et simple soit-il)
- avec peu de ressources >> 1ko, 1Mo, 1Go... le principe reste le même c'est juste une question de dimensionnement (de même pour la consommation et l'alimentation)
- avec des composants rudimentaires >> utilisant seulement des GAL/PAL, PIC, µproc... la complexité d'un système ne devrais pas définir son mode d'emploi
- c'est fait sur mesure >> sauf si c'est conçu pour être évolutif, polyvalent (une conception > plusieurs applications)
- c'est petit >> ça rest relatif... une carte de gestion d'un panneau solaire auto-rotatif c'est de l'embarqué ? > plus grand qu'une feuille A4 (donc plus grand qu'une CM µATX dans laquelle transitent de plus faibles puissances), alim par batterie, absence de proc', petits programmes, etc.

Bref tout ça pour dire que pour certains "embarqué" se résume à quelque chose qui répond à un cahier des charges limitant les possibilités, alors que pour d'autres c'est contextuel, par comparaison à son environnement, et pour d'autres encore c'est juste quelque chose qui correspond à un concept (la première ligne).

[hotcryx]

Oui ce n'est pas clair le terme "embarqué".

Il me semblait qu'à une époque Android était de l'embarqué.
En tout cas, on peut le mettre dans notre poche.

Est-ce que l'Iot (Internet of things) est de l'embarqué ??

[Vincent PETIT]

Je programme en C sur :

Microchip µc 8 bits
Atmel µc 8 bits
Texas Instruments µc 16 bits
ST µc ARM 32 bits

Ça fait longtemps que je n'ai plus fait d'assembleur et mon VHDL est très rouillé

[theMonz31]

C# pour tout

Embarqué electronique ==> Micro Framework .Net

Embarqué Windows CE ==> C# et le compact Framework (qui contrairement à ce que dit KilroyFR fonctionne parfaitement bien)..

Android ==> Xamarin et C# qui fonctionne aussi parfaitement bien (qu'on fasse du natif ou bien du Xamarin.forms)


Bref, un langage, un seul IDE... que du bonheur pour peu qu'on prenne la peine de creuser à fond chaque plateforme !!!

Et franchement, pour avoir fait de l'assembleur (6502/68xx), du C et du C++... bah, pour rien au monde je ne quitterais le monde .Net et C# pour y revenir...
(ok, perfo surement moins bonne en .Net mais quel bonheur à programmer et quelle facilité pour faire beaucoup de chose sans se prendre la tête avec des problématiques
d'il y a 30 ans - memory leak, et autre)...

[kilroyFR]

Pas de memory leak de notre coté car on maitrise tout ce qu'on fait. Faut juste etre rigoureux mais ce n'est plus ce qu'on demande aux dev C# de nos jours. Ils ont l'impression d'etre les rois du monde parce qu'il ont codé une page de code . Pour rappel C# a ete fait pour s'approcher de la simplicité de programmation de VBasic a l'epoque. Forcement on perd au passage.
et Oui je confirme ne t'en deplaise qu'on a pas mal de soucis avec Compact CE dont les versions .net ne sont pas du tout equivalentes avec leurs versions desktop. Mais ca tu t'en rends compte quand tu cherches des API que tu ne trouves pas. Ujen logiciel qu'il faut 'reveiller' regulierement pour eviter qu'il decharge des objets dont on aurait besoin immediatement (sans temps de 1ere compilation).
Je ne suis afficionados de personne, j'aime juste avoir les bons outils pour etre productif (je veux dire je me tape de connaitre les dernieres syntaxes C# a la mode pour coder en 2 lignes de codes ce qu'on faisait en 3).
Par contre quand tu utilises une API sous WinCE qui a un comportement different que son (a priori) equivalent sous PC ben tu zappes car c''est le genre de truc ou tu perds un temps fou pour decouvrir que M$ a decidé de changer un comportement d'une API entre PC et WinCE.
La plateforme WinCE est une merde et il me tarde qu'on passe totalement a Android la dessus (on doit etre les rares encore a developper sur cette plateforme).
Le seul truc de bien c'est visual studio (2008 - faut pas deconner non plus mais ca fait le taf).

Et Xamarin je me suis jeté dedans comme un fou croyant trouver l'outil miraculeux. Au final tu codes ton appli en C# dans une syntaxe/conception tres proche de ce que tu fais en java donc rien de revolutionnaire la dedans si ce n'est de pouvoir dire que tu as un seul langage (je n'ai aucun soucis avec ca, aucun n'est meilleur que l'autre) et tu te retrouves avec des applis de 60Mo qui embarquent tout le SDK Java. Moralité j'ai laissé mes applis sou java android (IDE equivalent si ce n'est meilleur que VStudio pour moi).

[marsupial]

C# fermé, lourd et gourmand donc je ferai plus confiance au vieux couple C + assembleur à mon sens. De plus normé et standard.
Un langage n'est pas là pour faciliter la vie du développeur mais celle de l'utilisateur et dans l'embarqué, appliquer un correctif dépend du bon vouloir du client pas de l'éditeur. Le jour où MS s'en va ou décide de modifier la techno, on le voit avec Oracle et Java, bonjour les dégats.

Embarqué = autonome. Embarqué avec un OS, c'est se compliquer la vie. A la limite, pour le char Leclerc ou le Rafale je peux comprendre un mini-OS car il y a interaction. Pour un drone, c'est useless.

Edit : Interaction homme-machine; pour un drone c'est de machine à machine et l'objectif d'un OS c'est de rendre la machine exploitable par un être humain. Donc un OS pour un drone à mon avis c'est superflu. Je persiste. Un module de communication est largement suffisant pour le télécommander ou lui passer les instructions et il se débrouille comme il veut. Désolé, je ne vois vraiment pas l'utilité de lui faire bouffer des Go de codes inutiles augmentant la surface de bugs et de failles.

[hotcryx]

Le jour où MS s'en va ou décide de modifier la techno, on le voit avec Oracle et Java, bonjour les dégats

Comme Silverlight, la clé sous la porte