Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Quel langage pour le développement embarqué ?
J'aimerai avoir vos avis à propos du choix de langage de developpement embarque.
Car j'adore l'électronique et je debute en informatique(d'ailleurs j'adore aussi!!), en C et en assembleur.
Donc pour allier les deux j'ai pensé à me mettre à l'embarqué.
Je souhaiterai donc savoir si le langage C est bien pour l'embarqué ou si d'autres langages seraient plus adaptés.
D'avance merci.
La réponse est : ça dépend !!
Ca dépend de tes connaissances, des contraintes financières, matérielles et temporelles que tu as. Ca dépend si tu fais ça juste pour toi, ou pour une entreprise. Et ça dépend aussi de la définition de l'embarqué que tu te donnes.
Aujourd'hui, la mode est à Java (sur les PDAs, sur les téléphones portables, sur les cartes à puces, etc). On trouve sur Internet d'excellents environnements de développement pour les différents matériels cibles. Donc pour moi, Java / J2ME serait un choix privilégié si je devait m'y mettre.
La seule restriction : ceci n'est valable que sur un matériel pour lequel une JVM existe déjà.
En fait, mon but est de prende de l avance sur mes etude. En commencant l apprentissage d'un langage pour moi puis l 'etendre a une entreprise plus tard.
Pour mes connaissance, elles sont assez limitées , je fait un peu de C et de l ASM.
Enfin l embarqué pour moi c'est la programmation de carte comprenant proc ou µcontroleur et quelques peripheriques, incluant peu de memoire, pouvant ou non etre dotees d'un OS.
je ne sais pas si ma definition est la bonne, mais si vous en avez une plus clair ou meilleur, n'hésitez pas a me corriger.
La question fondamentale, amha, c'est : as-tu une contrainte de traitement temps réel ? Si oui, ça simplifie grandement tes choix (ça les limite, en fait). Pas de J2ME, par exemple.
Qu'appelle tu développement embarqué ?
Developpement PDA ?
Pour le developpement sur PDA, avec interface graphique
C++
Si le but est seulement de prendre de l'avance sur un langage de programmation, alors choisi tout de suite un langage objet fortement typé. Delphi, Java et Ada95 sont des excellents choix. Ca te donneras de bonnes habitudes de programmation, et après, même si tu reviens sur du C, ou d'autres langages moins typés, tu garderas tes habitudes. Par contre rien à voir avec l'embarqué. C'est juste pour apprendre la programmation objet.
D'un point de vue embarqué : tu devras toujours utiliser de l'assembleur. Tous les langages sont embarquables, il suffit d'avoir les bon outils de développement (plate-forme de compilation croisée) et les bons BSP (Board Support Package : le "driver" en quelque sorte pour le matériel considéré) et bcp de temps et de patience, parceque souvent il faudra ré-écrire de nombreuses routines de bas niveau, voir un OS complet. Le hic c'est que justement, il existe très peu de ces environnements, et ils sont souvent chers.
Le point que soulève Traroth mérite également ton entière attention : pratiquement tous les développements embarqués réalisés sur des matériels spécifiques ont une composante temps réelle. Là également, les noyaux temps réel ne sont pas donnés et à moins que tu ne sois le fils de Cresus, je doute que tu puisses acheter des licenses si facilement.
Par ailleurs, les noyaux et les environnements de compilation croisée existants sont faits pour des matériels +/- standard. Si tu développes ton propre ASIC, FPGA, DLP ou je ne sais quel chip, tu ne trouveras de toutes façons aucun OS le supportant. Il te faudra écrire le BSP correspondant en assembleur.
En fait mon but premier est de developper avec un nouveau langage, qui pourra me servir si toutefois j avais l opportunite de faire de l embarqué(mon objectif).
Donc pour le moment je ne prendrai pas garde aux notions de temps reel, de cout, ou encore de "driver". je m'en préoccuperai lorsque j 'aurai atteint un niveau suffisant pour faire de l'embarqué.
Ceci dit, j'ai pensé a apprendre des langages OO mais je savais pas vraiment si c'était un bonne voie à prendre, justement car trop haut niveau. mais puisque vous me le conseillez je vais surement m'y mettre. Le meilleur serait alors java ou delphi (plus proche de l'embarqué)
:
Encore merci de vos réponses
Les modérateurs vont nous taper sur les doigts si on (re)commence ici un débat du style "Quel langage apprendre en premier ?". Je te conseille de passer en revue les messages du forum correspondant. Il y a plein d'avis intéressants sur Java, Delphi et les autres langages.
Maintenant pour l'embarqué, c'est pas si simple. Globalement, quand tu feras de l'embarqué (ce que je te souhaite), tu utiliseras le langage que la boite dans laquelle tu travailleras te donnera. Ca pourra être du C++ ou du C, mais ça pourra tout aussi bien être du Java, de l'Ada, ou n'importe quel langage plus rare et plus exotic qu'on apprend même pas à l'école, mais qui correspond exactement aux besoins de la-dite boite.
Donc mon conseil est : préoccupe-toi d'abord d'apprendre un langage OO. Tu en auras toujours besoin dans ta carrière. Tu d'adapteras ensuite au besoin à n'importe quel autre langage, même s'il n'est pas OO.
Bonne chance...
ok merci, je pense que je vais aller faire un tour du coté des post comparatif.
@+
Je n'ai l'expérience que de l'embarqué dans l'aéronautique. Ils sont plutot en retard car les contraintes sont bcp plus fortes. Deux langages sont utilisés: le C et l'ADA83. En fait on arrive au C++ et ADA95 (elle est pas belle la vie???). L'équipement sur lequel j'ai bosser comportait un tout petit OS RT (real time) écrit en assembleur.
Le Java ne te permettra certes pas de faire du temps réel. D'ailleurs pour moi Java fait du code portable, non embarquable (j'entend par là sur des plateformes aux ressources limitées...).
Je te conseillerai quand meme de t'entrainer à programmer un peu sur PC avant de faire de l'embarqué. Si tu utilise des plateforme avec peu de ressources, le C et l'ADA conviennent.
Je pense que tu peux regarder aussi les sites de robotique, car c'est exactement de l'embarqué qu'ils font.
D'ailleurs je m'amuse avec le Lego Mindstorm de mon frangin, je trouve ça terrible!!!
D'ailleurs tu peux peut etre aussi programmer en grafcet, si tu as un compilo C qui va bien, et un editeur grafcet approprié.
Moults regrets, mais les petits jeux et autres programmes en Java sur ton téléphone portable sont embarqués. Donc ton assertionne tient pas.Java fait du code portable, non embarquable
Par ailleurs, mais à titre d'information parce que je ne sais pas où ils en sont, des groupes de travail planchent sur un Java Real-Time. Voir par exemple JBED (http://www.ddj.com/documents/s=897/ddj9911h/9911h.htm) ou encore RTJ (http://www.rtj.org/)
Je suis d'accord sur le fait que c'est du code embarqué, et je suis aussi au cour du Java RT. Mais le gros pb de Java vient du fait que c'est un langage interprété. Ce qui implique une exécution bcp plus lente, donc un processeur plus puissant pour faire la meme chose. Donc pour moa Java est portable et le restera, mais c'est une question de concept tout ça... En revanche je suis pas sur que le Java RT soit un jour certifiable dans l'aéro... On arrive au Power PC nous.
Je pense que Java c'est bien pour ton tel et ta cafetière... Mais imagine que tu pourrais peut etre faire bien plus de truc avec ton telephone si ct programmer en autre chose.
Mais comme partout on préfère rajouter 10000 transistor et quelque ko de mémoire en plus pour faire la meme chose... On fait payer plus cher le client!!!
Ben ça dépend de la JVM. Maintenant presque toutes les JVMs intègrent un JIT (Just In Time compiler), qui compile les classes chargées à la volée (si t'es sur Windows, le JIT HotSpot est utilisé par défaut, sans que tu t'en rendes compte). Et puis, c'est pas Java lui-même qui est interprété ou compilé, mais son ByteCode.le gros pb de Java vient du fait que c'est un langage interprété
Que JavaRT soit certifiable ou non, à la limite, c'est pas si important. Y a pas que l'aéronautique qui fait de l'embarqué, même si c'est un domaine privilégié pour en faire.
Je suis un peu comme toi, j'ai eu la chance de développer en Ada (Ada83 puis Ada95) sur des plateformes Motorola, mais nous, on n'a pas eu le temps de passer au PowerPC. Mon impression sur cette expérience est : c'était génial
!! J'ai vraiment pris mon pied pendant ces qq années. Et si cétait à refaire, je n'hésiterai pas une seule seconde.
Depuis j'ai fait aussi du C, C++ et du Java dans l'industrie, et bien que le C et le C++ soient censés être hautement véloces, pour rien au monde je ne les conseillerai pour faire de l'embarqué temps réel.
Quand à Java, c'est le seul language depuis Ada avec lequel je me sens bien. Et même s'il ne sera jamais certifié pour l'aéronautique (et rien n'est moins sûr), si on me demande de choisir un language pour des applis embarquées, c'est celui-là que je choisirais.
Si je ne me trompe le temps réel ne signifie pas "vitesse" mais "temps d'éxécution déterministe".
Pour l'aéronautique je suis d'accord qu'en plus du temps réel il y a des contraintes de rapidité mais d'une manière plus générale la "lenteur" de java ne le relégue pas au rang des langages non temps réel.
Oui c'est exact. C'est pourquoi les 68000 sont encore de mises dans l'aéro.
Cela dépend d'ailleurs surtout de l'ordonnanceur du noyau temps réel.
Un four à verre a un temps de réponse de plusieurs heures (équilibre thermique), pourtant le système de controle peut etre un système temps réel.
Un processeur lent avec un bon ordonnanceur sera meilleur qu'un super pentium4 sous windows...
En tout cas j'apprécie Java pour sa clarté du concept objet. On ne peut pas en dire autant d'ADA95.
C'est exactement ça. C'est LE gros problème avec Java pour le RT : Si ta JVM est justement en train de faire passer le Garbage Collector ou si ton JIT est justement en train de compiler un bout de code, ton temps de réponse sera alteré, et ça ne sera plus du temps réel. Dans le projet JBED, d'ailleurs (j'ai lu en vitesse, donc pardon), ils semblent alterer assez profondement le fonctionnement de Java. En dehors d'une syntaxe Java pour le langage, est-ce vraiment encore du Java ?Envoyé par etaix
Pour revenir à la question de freakydoz, je pense voir exactement ce que tu veux dire par embarqué, je suis en BTS électronique et j'adore l'informatique puisque l'un ne va pas sans l'autre. Tu parles de programmation sur µC. Je suis dans le même cas que toi car ce que j'adore le plus dans l'électronique c'est programmer; C/ASM pour les µC et VHDL pour les PAL, GAL, FPGA et autres composants programmables CPLD (j'aime aussi le reste bien sur).
Donc si tu veux apprendre un langage utile, apprend le C, le VHDL, l'ASM du µC cible. Si tu es dans l'électronique comme moi tu comprendras qu'apprendre un langage orienté objet ne t'apportera rien sur un µC, sauf si tu t'orientes vers l'informatique.
Personnellement je n'ai jamais entendu parler de compilateur µC Java et très très très peu en Pascal.
Je pense que pour beaucoup d'entre nous le terme embarqué a mal était définie, on est sur un forum de développeur informatique plutot orienté PC.
Donc il se peut que les informaticiens n'aient pas entendu le mot embarqué dans le sens de l'électronicien. A moins que je me trompe complétement sur ton point de vue.
Tout a fait d'accord avec Vincent.
Perso je travaille dans l'embarque, j'entends par la programmation de microcontrolleur avec bidouille des registres et autres interruptions. Quelque soit le client ou le domaine d'application, le langage utilise est le C.
Et a chaque fois des connaissance en assembleur sont utiles. Si ton programme plante sans aucune raison apparente, tu es souvent oblige d'aller voir le code genere par le compilateur pour savoir ce qui ne va pas.
Par contre des que tu touches a un niveau plus eleve genre IHM ou programmation PC (domaine habituel des developpeurs) le langage C++ devient a mon avis une excellente base.
Je suis pas d'accord. On peut faire de l'embarqué sans connaitre l'assembleur. Il existe des noyau temps réel pour compatible avec des processeur type 68000, PowerPC... Ce noyau sert de système d'exploitation. On trouvera parmis ce genre de noyau LynxOs et VXwork. De plus l'Ada est aussi très utilisé en embarqué (puisque conçu pour ça). Personnelement je trouve même qu'il est beaucoup mieux que le C. C'est vrai que les compilo C se trouve bcp + facilement. Reste à noter, que tu peux faire de l'embarqué avec les restes d'un 386... Je crois que certains parte de ça pour leur robot.
De plus l'embarqué, normallement c'est tout sauf de la bidouille. Un bon système embarqué est un système ou le bouton Reset n'éxiste pas, puisque inutile (là c'est quand même de l'utopie...).
Plus précisement, si le délai de réaction qu'exige ton appli est inférieur au temps qu'il faut au garbage ou au jit pour rendre la main, c'est mauvais.
Je crois que le temps réel n'a pas le même propos que Java : avec le temps réel, tu parles forcément matériel concret ; avec Java, au contraire, tu essaies de parler quelque soit le matériel. Une appli temps réel, quasiment par définition, n'est pas portable ; une appli java, quasiment par définition, est portable.
Maintenant, si tu utilises Java sur un matériel définit et une JVM définie, tu peux, en général, configurer le ramasse miette et le JIT pour qu'ils fassent ce que tu veux qu'ils fassent au moment où tu veux qu'ils le fassent. Et donc tu peux envisager d'utiliser Java pour du temps réel. Je ne sais pas si cela est pertinent, mais cele se peut.
Répondre avec citation
Partager