Discussion :

[3DArchi]

Bonjour,
Quels sont les langages qui vous occupent le plus dans vos développements embarqués ?
Ce sondage doit être l'occasion de nous raconter les langages que vous aimez et que vous devez utiliser pour le développement embarqué. N'hésitez pas à préciser quels sont les environnements de vos projets : OS riches ou pas, temps réels, compilateurs, etc.

N'hésitez pas à parler d'autres langages qui ne soient pas présents dans la liste.

[gorgonite]

il faudrait déjà définir le mot embarqué... parce qu'a priori, presque tous les langages sont susceptibles d'être utilisés


après si en plus d'embarqué, on ajoute temps-réel ou critique en terme de fiabilité, ou à empreinte mémoire extrêmement faible (parce que l'embarqué à 1Go ça existe dans l'industrie ^^), là on peut parfois supprimer quelques technos non pas pour des incompatibilités réelles mais plus pour la non-orientation de leurs implantations vers cette problématique
ensuite si l'on ajoute qu'on souhaite ne pas être seul dans son coin et faire avec des technos déjà éprouvées dans ce domaine, ça élimine certaines solutions exotiques... mais aussi certains choix technologiquement prometteurs mais peu conventionnels

enfin, si l'on ajoute également des obligations de certifications, là ça peut vite se réduire jusqu'un sous-ensemble de C et d'Ada pour la partie soft

[Aquanum]

Comme le dit gorgonite, ça dépend complètement du contexte, du matériel, des besoins et du temps alloué au développement du projet.

Pour ma part je travaille en environnement linux embarqué. Distributions maison (pas d'Android pour le moment). Du coup je développe en C/C++ et pas mal aussi en bash/python.

Et si je dois mettre Android sur un projet, je développerai les applications en Java. Si je devais mettre un système emdebian, angström, ubuntu, ou autre cela dépendrait des ressources et de ce que l'on souhaite faire.

Après cela dépend surtout de la RAM disponible, du processeur et s'il existe des JVM qui peuvent tourner dessus pour faire tourner du JAVA.

Le C est bien pour travailler dans des environnements à fort contrainte, mais faire un système complet en C prend plus de temps qu'en JAVA avec les lib qui vont bien. C'est vraiment du cas par cas. C'est aussi là l'intérêt des systèmes embarqués. Ce n'est jamais pareil

[ClaudeBg]

Salut
-----

Comme ça a été dit: "embarqué", ça couvre des réalités complètement différentes. Un serveur NAS, c'est de l'embarqué, un programmateur de machine à lessiver aussi. On peut difficilement ranger ça dans la même catégorie concernant le choix d'un langage.

Mes préférences :
-----------------

Pour les cartes à base de microcontrôleurs 8 bits sans OS: langage d'assemblage sans aucune hésitation.

Pour les cartes à base de microcontrôleurs 16 bits sans OS : langage d'assemblage et/ou C

Pour les cartes à base de microcontrôleurs 32 bits sans OS : C et langage d'assemblage si nécessaire

Pour les cartes avec OS : tout langage convenant en fonction du cahier des charges et du matériel (portabilité, exécution en environnement graphique, rapidité d'exécution, proche ou non du hardwdare, etc). Donc : C, Java, C# (je préfère C# à Java, et vu que maintenant mono existe...) etc.

Par contre, je n'ai jamais aimé C++ (avis personnel), j'ai l'impression d'avoir affaire à une espèce de "surcouche" ajouté au C pour faire de l'objet. On doit continuer à mettre le nez dans le cambouis comme en C alors qu'on est sensé être à un haut niveau d'abstraction évitant de savoir par exemple si on passe un objet en référence ou un pointeur sur le dit objet. Mais évidemment, je ne juge pas, je ne fais que donner, comme demandé, mon sentiment personnel.

Donc, moi j'aime les extrémités : le très bas niveau avec contact direct avec le hardware (souvent fait "maison), soit le très haut niveau avec un degré d'abstraction maximal avec un maximum de convivialité et "pur objet".

Je pourrais donc tout cocher, en fait, mais si je ne devais en conserver que 2, ce seraient les 2 extrêmes :

Langage d'assemblage et C#

Ps: langage d'assemblage et non "assembleur"


A+
Claude

[3DArchi]

Effectivement, le type du langage va dépendre grandement du contexte projet. C'est donc l'occasion de préciser aussi quel type de projet, quel plateforme, quelles contraintes, etc.

[ram-0000]

Il manque un langage (au moins), c'est ADA. C'est un langage qui est (était ?) très largement utilisé dans les projets Industriels.

Pour ma part, j'ai eu 3 expérience en embarqué :

• La partie bootstrap de cartes VME, donc là pas le choix, c'est de l'assembleur et dès que possible on passe la main à du code en C.
• L'écriture d'une couche X25 sur une carte avec un micro controleur à base de 68000, là c'était du C.
• Un projet sur un micro satellite avec une très grosse partie en ADA et les routines très bas niveau (gestion des controleurs) en C et assembleur

[wokerm]

sans hésitation les languages .net en particulier visual basic Ou Boo si c'est possible

[abitaf]

Pour moi c'est TinyOS, car je travaille sur les réseaux de capteurs sans fil multimédia.

[Priato]

Comme indiqué au-dessus, il manque ADA dans la liste... Et selon moi il est beaucoup mieux adapté à l'embarqué que .Net, Java ou même C++. Je le mettrais même devant C en particulier pour son typage très poussé.

Petite précision: Je me situe dans le cas d'hautes performances, pour de l'embarqué + temps réel sur des systèmes plutôt "Safe" dans le secteur industriel (voitures, avions, satellites, chemin de fer...etc.)

Je ne parle pas de téléphonie où il sera peut être plus rentable de développer plus vite et en ayant moins de contraintes de performances ou de temps réel.

[air-dex]

Je ne parle pas de téléphonie où il sera peut être plus rentable de développer plus vite et en ayant moins de contraintes de performances ou de temps réel.

Dans ce cas là, il s'agit plus de programmation mobile que d'embarqué, non ?

Pour ma part j'ai déjà touché à l'embarqué à l'occasion de mes études avec le langage C mais on ne m'y reprendra plus jamais avec ce type de programmation.

[lequebecois79]

faudra spécifier embarqué, car de nos jours ça signifie pu grand chose....... ça peut êtr eun système à 50mhz avec 2 meg de ram...... comme ça peut être un système dual core avec 4 gig de ram....

[ClaudeBg]

Salut
-----

Ca peut même être un composant à 1Mhz avec Ram de 70 octets.

C'est pourquoi j'ai pris soin de préciser mes choix pour chaque grande famille de plateformes.

L'embarqué, c'est vaste, et, du coup, il faut comprendre que ça aborde des tas de domaines différents. De plus, il n'y a plus comme avant une limite franche entre les petites et les grandes "ressources", c'est "étalé" uniformément depuis le minuscule microcontroleur 6 pattes jusqu'à la bêbête de course montée sur une platine complète.

L'embarqué, moi je considère ça (mais il y a d'autres façons de le voir) comme un matériel contrôlé par un logiciel, l'ensemble étant destiné à remplir une fonction ou un ensemble spécifique de fonctions agissant sur un environnement physique ciblé.

- Une centrale d'alarme "intelligente", c'est de l'embarqué
- Une centrale domotique aussi
- Un programmateur à microcontroleur de machine à laver: pareil
- La carte de programmation d'un four électroménager
- Un pilote automatique d'avion
- Un allumage électronique "intelligent"
- Un GSM

Mais un PC faisant tourner une suite bureautique: non
Pas parce que c'est un PC, mais parce que tel qu'utilisé ce n'est pas destiné à agir sur un environnement physique ciblé.

Pour moi, s'il y a un ensemble électronique/programmation qui sont liés dans un but précis avec des contraintes physiques, ça devient de l'embarqué: Avec ou sans OS, avec ou sans mobilité.

A la limite, un PC de bureau, si on fait tourner dessus un logiciel particulier destiné par exemple à piloter une machine/outil, ça devient de l'embarqué, parce qu'on est confronté aux mêmes contraintes qu'avec de l'embarqué sur carte dédicacée. Aucun matériel programmable n'est exclus d'office du domaine de l'embarqué.

Et, inversement, une carte destinée prioritairement à l'embarqué (ex: la pandaboard) sur laquelle on ne ferait tourner qu'une suite bureautique, ce n'est plus vraiment de l'embarqué, c'est une application informatique tournant juste sur un matériel particulier.

Donc, ma vision à moi, c'est que la définition nécessite autant de faire intervenir l'application finale que le matériel.

Chacun ayant évidemment son approche personnelle et sa vision des choses, on peut définir l'embarqué de plein de façons différentes. Au final, ça ne dérange pas trop, à condition que pour une question donnée on prenne soin de préciser le contexte.

Du coup, c'est clair que sur ce site on a pour l'instant par défaut des informaticiens, et donc des gens qui voient l'embarqué à son plus haut niveau (cartes de développement récentes): c'est l'opportunité pour eux de faire tourner leurs outils habituels sur des cartes ciblées.

Inversement, sur un site d'électroniciens on a par défaut des gens qui viennent du hardware, et donc qui vont chercher le composant plutôt que la carte, et travailler de préférence à plus bas niveau en utilisant des techniques hardwares plutôt que des outils informatiques classiques.

Enfin, il y a ceux qui ont la double qualification, et, comme on l'a déjà dit, ne trouvent pas d'endroit où poser leurs questions (avant ce forum). La double qualification permet de naviguer partout dans la famille "embarqué" sans se retrouver "coincé". Ces internautes ont l'opportunité de pouvoir développer du soft en pensant au hardware qui est derrière, et inversement.

C'est pourquoi il faut bien veiller à laisser "la porte ouverte" et à ne pas restreindre la vision de l'embarqué à un type de matériel précis, sinon on aura raté l'objectif de ce forum. Heureusement, je pense que ce n'est pas du tout le cas jusqu'à présent.

Maintenant, comme il a été dit, la contrepartie de cette ouverture, c'est de ne pas oublier de préciser le contexte lorsqu'on pose une question.

Par exemple: la question initiale posée sur ce sujet est intéressante si chacun précise le contexte de ses applications. Par contre le sondage est complètement biaisé car les réponses dépendent de la plateforme ciblée, et donc à la fois des applications et de la qualification des utilisateurs: Je me vois mal programme en C# sur un 16F84, par contre si je peux éviter le langage d'assemblage sur une application embarquée avec OS, ben tant mieux. Dans le premier cas le langage d'assemblage est un maître choix objectif, et dans le second c'est un mal nécessaire si on ne sait pas faire autrement.

Du reste, on voit bien sur le sondage la prédominance du C. Or ce sondage ne montre pas en réalité que le C est le choix le plus "quelque chose", ça montre plutôt que ceux qui programment en bas niveau peuvent utiliser le langage d'assemblage OU le C, et ceux qui programment plus haut niveau utiliseront le C EN COMPLEMENT d'un autre langage plus abstrait. Le C pour les uns est un langage évolué, alors que pour les autres c'est un langage de bas niveau. Moralité, le C est utilisé dans "les deux mondes" et donc devient majoritaire si on fait un sondage de ce type.

A+
Bigonoff

[3DArchi]

Pour ma part j'ai déjà touché à l'embarqué à l'occasion de mes études avec le langage C mais on ne m'y reprendra plus jamais avec ce type de programmation.

Intéressant. Qu'est-ce qui t'as rebuté ?

[air-dex]

Intéressant. Qu'est-ce qui t'as rebuté ?

Trop de hardware pour moi.

[danielfr40]

Dans l'aéronautique, nos développements embarqués sont soumis à une certification qui exige une maîtrise et un déterminisme du comportement derrière une ligne de code très stricte.
A partir d'un certain niveau de criticité, tout mécanisme dynamique qui n'est pas déterministe en temps (garbage collector), ou abstraction (héritage/fonctions virtuelles) est prohibé et nous en revenons au bon vieux langage C.
A plus faible niveau de criticité, nous retrouvons c++, java, etc...

[lequebecois79]

Du reste, on voit bien sur le sondage la prédominance du C. Or ce sondage ne montre pas en réalité que le C est le choix le plus "quelque chose", ça montre plutôt que ceux qui programment en bas niveau peuvent utiliser le langage d'assemblage OU le C, et ceux qui programment plus haut niveau utiliseront le C EN COMPLEMENT d'un autre langage plus abstrait. Le C pour les uns est un langage évolué, alors que pour les autres c'est un langage de bas niveau. Moralité, le C est utilisé dans "les deux mondes" et donc devient majoritaire si on fait un sondage de ce type.

A+
Bigonoff

en fait, ça dépent justement sur le type de matériel que la personne a travaillé
si c'était sur une machine à 75Mhz et 2 meg de ram..... pas grand chose qu'elle est installé une jvm embarqué dessus

je sais pas si oracle les offres encore, mais sun avait supportait de multiple cpu avec ses vm pour l'embarqué: mips, arm, x86

après ta des produits qui supporte que des sous ensemble de java... pour x,y z raison, ta ensuite des produits qui traduit java dans un autre langage

[argv225]

Micro: STM32
Langage: C++
IDE: Keil µVision
Domain: comptage électrique

[AlexG34]

Pour les ATMEL ARM (AT926JSE):
* Langage: C
* Compilateur: GCC
avec des portions en assembleur pour les routines critiques.
J'ai testé les compilateurs "propriétaires" (Keil et autres), mais je préfère définitivement le libre, même si les libs contiennent parfois des erreurs.

[3DArchi]

Salut,
Pour une discussion spécifique sur ce qu'est ou pas l'embarqué, je vous propose cette discussion : Quelle est votre définition de l'Embarqué ?
Cette discussion reste pour présenter le ou les langages utilisés et dans quelles typologies de projets.

[dlandelle]

Je me suis éclaté en C sur des cartes VME, et un petit OS temps réel qui s'appelle pSOS.
L'OS faisait moins de 100Ko, avec presque tout dedans, sémaphore, section critique, messagerie, et bien sûr gestion mémoire et process.
J'aime bien C++, mais je trouve que ça fait moins embarqué, et Java je n'y penserai même pas, pas confiance, car pour moi embarqué veut dire "les yeux fermés"