Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quels langages utilisez-vous pour le développement embarqué ?
Partagez votre expérience

Le , par 3DArchi

0PARTAGES

4  0 
Quels langages pour le développement embarqué ?
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.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de ClaudeBg
Membre éprouvé https://www.developpez.com
Le 30/03/2011 à 19:58
Salut
-----

Le C est le langage qui est le plus près du fonctionnement du microcontrôleur et qui se compile le mieux. Il y a l'assembleur aussi mais ça fait longtemps que je ne l'utilise plus (même dans les routines d'interruption) puisqu'il n'est pas portable, est illisible et n'apporte que peu de vitesse supplémentaire.
Désolé, mais je ne peux pas laisser dire ça, c'est une manie pour certains utilisateurs de C d'attaquer le langage d'assemblage: ce n'est pas une guerre.

Le langage qui est le plus près du fonctionnement: c'est le langage d'assemblage, ça ne souffre aucune discussion parce que c'est sa définition même.

"Qui se compile le mieux": ben j'avoue ne pas avoir compris

"puisqu'il n'est pas portable": Un logiciel sur une cible aussi proche du hardware n'est jamais portable. La portabilité est une illusion extapolée du fait que le source C est "relativement" portable lorsqu'on travaille avec un OS sous-jacent (et encore, pour moi la vraie portabilité c'est la portabilité de l'exécutable). Mais cette extrapolation est fausse sans OS pour du logiciel lié à son hardware. Déjà au niveau PIC le code source n'est même pas portable d'un compilateur à l'autre concernant la même cible, alors inter-famille mieux vaut ne même pas y penser (je fais impasse évidemment sur "printf "hello word", car on n'utilise pas un micro de ce type pour faire ça).

"est illisible": c'est encore une célèbre idée reçue complètement infondée. Ce n'est pas le langage qui fait la lisibilité, c'est le programmeur. Il y a des déclarations en C qui nécessitent de faire griller ses neurones et utiliser une feuille de papier pour essayer de comprendre ce que ça représente (tout le monde a déjà vu ça), et il y a même des concours à qui sort la ligne C la plus illisible possible.

"n'apporte que peu de vitesse supplémentaire": De nouveau, c'est une généralisation de choses qui ne le sont pas. Si on prend un PIC16Fxxx et qu'on écrit du code en C, on constate que le taux d'expansion est énorme et que le code produit est catastrophique au niveau efficacité. Le fait que 90% des applications n'ont besoin que de 10% de la puissance processeur n'y change rien: c'est inefficace. Logique : aucune gestion de pile, un seul pointeur indirect, données sur 8 bits, pas assez de RAM, jeu d'instructions insuffisamment étoffé, présence de banques qui plombent l'accès aux variables, etc. Si on prend un autre 8 bits: le 18F, le code C produit devient beaucoup plus efficace, MAIS il garde l'inconvénient de travailler sur des données 8 bits, le C n'étant pas vraiment conçu pour travailler en 8 bits natifs. Du reste, j'ai des applications dont les routines d'interruption nécessitent de maîtriser les temps de cycle, donc hors de portée du C. Sans compter des applications sur 12F qui entrent au chausse-pied et donc exit le C.

Si par contre on passe aux 16 bits (toujours niveau PIC), alors le C devient le langage "conseillé" par défaut, avec langage d'assemblage en cas de besoin. Tout simplement parce que ces composants ont été spécifiquement conçus pour être utilisés avec un compilateur C.

Bref, on ne peut pas faire de généralités, ni encore moins faire une guerre entre C et langage d'assemblage. Pour les petites cibles l'un ou l'autre est mieux adapté en fonction de la spécificité de la cible et de l'application, et souvent ils sont complémentaires et non dualistes.

Si le timing est critique à un moment donné, je désassemble le code compilé juste pour voir s'il est bien optimisé).
Désassembler du C pour le modifier en langage d'assemblage, j'appelle ça de la programmation en langage d'assemblage (sauf que c'est moins efficace car la structure du programme n'a pas été pensée pour ça). C'est aussi implicitement reconnaître que le C n'est pas aussi efficace que le langage d'assemblage.

(100% de maîtrise du temps, pas 99.5%)
Ca me semble contradictoire, parce qu'on ne maîtrise jamais le timing à 100% en C, puisque cette maîtrise nécessite l'accès à l'unité de base du processeur: son temps de cycle, et donc l'instruction machine. Et ça, ce n'est possible qu'en langage d'assemblage.

Malheureusement avec ces langages reposant sur des OS (linux, RTOS,...) multiprocess, on perd la maîtrise du "vrai temps réel" (le 100%).
Tu confonds "temps réel" avec "rapidité du processus" ou "maîtrise du temps à la µs", ou "temps de réaction". On peut faire du temps réel déterministe avec un temps de réaction de l'ordre d'une heure, c'est du temps réel tant que l'information traitée reste pertinente: Je travaille sur un projet temps réel déterministe à base de Linux + Xenomai, et ce sera du vrai temps réel et pourtant les informations seront transmises par un bus, ce qui prend du temps.

Maintenant, entendons-nous, je ne t'attaque pas et je n'attaque pas tes choix

Je veux juste dire que ce qui vaut pour ton cas particulier (tes applications avec tes cibles) ne peut pas être "généralisé" comme une évidence "mathématique": Chaque cas particulier a ses propres contraintes et mène donc à des choix différents, sans que personne ne soit forcément "dans l'erreur". Je t'ai donc interpellé parce que ton message avait un sens "d'évidence" qui n'est pas le reflet de la réalité de chacun.

Pour moi, tous les langages qui existent ont une raison d'être, et un choix n'exclut pas l'autre (je programme en C aussi, ainsi qu'en C#, en VB..)

Je pense qu'ici le but n'est pas de faire un comparatif entre langages pour savoir "lequel est le meilleur", mais simplement de faire un coup de sonde pour voir qui utilise quoi et pourquoi, en présumant que chacun est assez intelligent pour avoir choisi ce qui est adapté à son propre cas, sans compter que ce choix n'est pas immuable.



A+
Claude
7  0 
Avatar de gorgonite
Rédacteur/Modérateur https://www.developpez.com
Le 18/03/2011 à 12:54
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
6  0 
Avatar de ClaudeBg
Membre éprouvé https://www.developpez.com
Le 18/03/2011 à 14:43
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
2  0 
Avatar de ram-0000
Rédacteur https://www.developpez.com
Le 20/03/2011 à 20:51
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
2  0 
Avatar de Priato
Membre habitué https://www.developpez.com
Le 21/03/2011 à 11:17
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.
2  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 30/03/2011 à 9:17
Citation Envoyé par cdubet Voir le message
c++ : [...]performances inferieure a C.
Totalement faux.
2  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 30/03/2011 à 10:02
Citation Envoyé par gorgonite Voir le message
si on met un développeur Java sur du C++ histoire d'embarqué du code... oui
si on met un développeur Java sur du C++ C histoire d'embarqué du code on aura le même problème
2  0 
Avatar de Aquanum
Membre chevronné https://www.developpez.com
Le 18/03/2011 à 14:03
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
1  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 18/03/2011 à 18:29
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.
1  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 23/03/2011 à 12:38
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.
1  0