Discussion :

[benji8937]

Bonjour à tous,

Comme toujours pour ce genre de question, il n'y a, à mon sens, pas de bon ou de mauvais langage, il n'y a qu'une bonne ou une mauvaise appréciation des besoins que l'on a. En fonction du système embarqué et du type d'application que l'on souhaite en faire il faudra plus un langage qu'un autre.
Pour la plupart des besoins que j'ai pu avoir dans les systèmes embarqués, le C a été suffisant, et je l'ai trouvé suffisamment flexible et puissant pour pouvoir l'adapter à tous mes besoins.

[singman]

Quand je vois ca , je me dis quand même qu'il faudrait passer a autre chose que du C et réussir a trouver un langage qui puissent offrir

• Une empreinte mémoire faible
• Une simplicité d’utilisation
• Une capacité de vérification formelle importante

Quand je vois que tu prends l'exemple d'un cas mortel pour étayer ton argumentation, en ignorant les milliard d'heures ou le même logiciel et tout les autres ont fonctionné parfaitement, je me dis que peut être tu ne maîtrises pas le sujet.
Si je lis la suite de ton message, ou tu énonces deux des avantages du C (empreinte mémoire faible et simplicité d'utilisation) comme étant des arguments en sa défaveur, cela confirme ma première impression.

Je vote pour le C, pour moi l'embarqué démarre à la limite de l'automatisme (simple automate logique) jusqu'au petit PC ultra spécialisé. J'inclus dedans les systèmes comme les PIC Microchip, les cartes genre Arduino, celles basées sur de l'ARM, jusqu'à l'Atom et autres puces ultra basse consommation. Pour ces matériels, le langage C est le plus adapté : compilateurs existants et fiables, code précis et optimisé, bibliothèques, facilité pour trouver des programmeurs, performance, simple a mettre en oeuvre, peu de limitations hardware. Soit, il n'est pas "moderne" mais ses inconvénients sont connus et encadrés.

[jabbounet]

Quand je vois ca , je me dis quand même qu'il faudrait passer a autre chose que du C et réussir a trouver un langage qui puissent offrir

• Une empreinte mémoire faible
• Une simplicité d’utilisation
• Une capacité de vérification formelle importante

Il ne faut pas considérer uniquement le langage, mais tout l'environnement qui a conduit à l'apparition de ce bug (comme par exemple la chaine de validation), le même problème peut se produire dans n'importe quel langage.

Ce n'est pas pour rien que dans certains secteur il y'a des normes très strictes autour du développement logiciel je perse a DO178b pour l'avionique et les normes SIL pour le ferroviaire et même avec ces normes on ne fait que limiter fortement le risque d'apparition d'un problème.

[Davidbrcz]

Si je lis la suite de ton message, ou tu énonces deux des avantages du C (empreinte mémoire faible et simplicité d'utilisation) comme étant des arguments en sa défaveur, cela confirme ma première impression.

Euh non, justement, ce sont des arguments en sa faveur et qu'il faudrait retrouver ailleurs. C'est ce que je dis

compilateurs existants et fiables, code précis et optimisé, bibliothèques, facilité pour trouver des programmeurs, performance, simple a mettre en oeuvre, peu de limitations hardware. Soit, il n'est pas "moderne" mais ses inconvénients sont connus et encadrés.

Le premier compilateur existant certifié (et encore qui ne supporte pas tout le C) date de quelques années. Et encore, ca ne fait que garantir que le binaire a la même sémantique que le code écrit, pas que ce dernier est bon ! Donc des compilateurs éprouvés par le temps et l'experience, oui, surement, fiable à 100% non.

Pour le reste, tu as (quasiment) aucune garantie formelle sur le comportement de ton code. Tu sais juste qu'il passe les tests que tu as écrits, qu'il évite les écueils détectables à la compilation (pointeur null, buffer overflow...) et qu'il suit les normes imposées en fonction du domaine. Ca ne te certifie formellement en rien ton programme, ca diminue juste (grandement) les risques.

Ensuite les bons programmeurs C vont commencer à devenir quelque chose de rare. Ce n'est plus un langage qui est fortement enseigné (20 ou 30H de cours ca ne suffit pas...) au détriment d'autres langages, même dans les parcours spécialisés. Produire du bon code C (à fortiori dans l'embarque), ca demande pas mal d’années d’expérience.

Il ne faut pas considérer uniquement le langage, mais tout l'environnement qui a conduit à l'apparition de ce bug (comme par exemple la chaine de validation), le même problème peut se produire dans n'importe quel langage.

C'est vrai et je ne connais le processus exact qui à conduit à l'erreur. Mais plus ton langage est prouvable, plus tu les chances d'erreur et de comportements non voulu (sans forcement de bug logiciel) deviennent difficile à provoquer. Et en l'etat actuel, bah le C, c'est pas ca =p.

Attention, je ne dis pas qu'il jeter le C par la fenêtre mais qu'il faut faire évoluer l'industrie pour remplacer certaines parties.

[bpy1401]

Bonjours à tous

Pour éclaircir un peu le sujet sur le C. il faut savoir que ce langage très proche de l'assembleur permet d'optimiser la charge CPU et la mémoire utilisée par le logiciel. Ces deux facteurs sont un point important dans le prix du produit final qui doit toujours être le bas possible.

Le C a aussi ces défauts. il permet tout et n'importe quoi.
Plusieurs tests existent pour vérifier le codage que vos avez fait.
Les test unitaires permettent de vérifier la fonctionnalité d'une fonction C, mais aussi le résultat de la compilation.
Les test d'intégration permettent de vérifier que tous les sources C cohabitent ensemble.
Pour finir, les tests de validation vérifient la fonctionnalité du logiciel.

Mais i l existe toujours des trous dans la raquette, et forcement un bug peut toujours survenir, mais cela c'est valable pour tous les langages.

En automobile, la norme ISO26262 (sureté de fonctionnement) permet de gérer les événements redoutés (générateurs de bugs), mais comme toujours, c'est celui que l'on n'a pas imaginé qui va se produire.

Pour finir, on voit ce qui ne fonctionne pas, mais on ne remarque jamais les choses qui fonctionnent.

A+

[Bestel74]

Personnellement j'aime bien la flexibilité du C/C++.
Quand je fais du bas niveau je peux sans soucis "injecter" de l'assembleur.

[Tryph]

j'ai l'impression que dans l'esprit de certain, embarqué = temps réel...
ce qui, selon moi, est juste faux.

perso, en loisir et par curiosité, j'ai fait un peu de programmation de microcontroleurs en C et en assembleur quand j'ai du mesurer un temps au 100e de miliseconde près...

depuis quelques mois, je bosse sur un projet embarqué dans le ferroviaire en... python, oui oui
tant qu'on fait pas de temps réel et que la carte sur laquelle tourne le soft est surdimensionnée, ça fonctionne pas mal...
en même temps dans le même boite, j'ai déjà fait du bureau à distance sur un windows XP installé sur une carte electronique qu'on retrouve dans plein de métros et de tramway... alors plus rien ne m'étonne.

[minnesota]

j'ai déjà fait du bureau à distance sur un windows XP installé sur une carte electronique qu'on retrouve dans plein de métros et de tramway...

[Invité]

j'ai l'impression que dans l'esprit de certain, embarqué = temps réel...
ce qui, selon moi, est juste faux.

perso, en loisir et par curiosité, j'ai fait un peu de programmation de microcontroleurs en C et en assembleur quand j'ai du mesurer un temps au 100e de miliseconde près...

depuis quelques mois, je bosse sur un projet embarqué dans le ferroviaire en... python, oui oui
tant qu'on fait pas de temps réel et que la carte sur laquelle tourne le soft est surdimensionnée, ça fonctionne pas mal...
en même temps dans le même boite, j'ai déjà fait du bureau à distance sur un windows XP installé sur une carte electronique qu'on retrouve dans plein de métros et de tramway... alors plus rien ne m'étonne.

temps réel = vitesse est tout aussi faux

[jabbounet]

temps réel = vitesse est tout aussi faux

malheureusement cette erreur est très fréquente dans la tête de certaines personnes (souvent commerciaux, parfois techniques mais hors du domaine)

[Bktero]

Sinon, un Core i7 serait forcément plus temps réel qu'un PIC18

[bluehangel]

En automobile, c'est du "C" car les contraintes sont fortes: tailles du code, charge CPU, etc...

En ce qui concerne l'apprentissage du code "C", en entreprise tu as une formation aux outils internes, des règles de codage à respecter, des bibliothèques à utiliser car testé et validé, des outils de vérifications et de tests, et la majeur partie des codes sont simples (présence de variables pour le monitoring et l'acquisition, peu de pointeurs,...), le code est produit à partir de spécification fonctionnelles écrite sous Simulink ou équivalent. Lorsque cela ce complique, tu as des experts qui travaillent sur les fonctions "coeur" qui peuvent apporter de l'aide.

Au delà de la syntaxe d'un langage, l'apprentissage de la programmation c'est la maîtrise de l'algorithmie et la capacité à lire et comprendre rapidement un code pour le débuguer

Je parle bien sûrs pour la partie que je connais.

[forthx]

J'ai fait un peu de programmation embarquée, et cela dans plusieurs langages.

"L'embarqué" c'est assez large comme dit plus haut (un porte avion ça compte? ). Je distingue 3 cas de figures, qui peuvent guider vers un langage, bien que je corrobore le fait que de dépend aussi du projet.

Pour une petite plateforme (ex : ST7, softcore sur FPGA, ...)ayant des interfaces simples, avec un comportement temps réel attendu ou de fortes contraintes mémoire, je penche pour l'assembleur : c'est généralement long à développer, la maintenance est parfois délicate, mais quant chaque cycle et chaque bit compte c'est un outil de choix (on peu aussi envisager un code mixte C/assembleur).

Si la plateforme est un petit système avec périphérique (ex: Raspberry Pi), le C sera mon langage de prédilection : dépendamment de l'architecture on peu obtenir les librairies qui vont bien, cela permet de ne pas réinventer les roues, on garde une empreinte mémoire relativement faible, et des possibilités temps réel. On peu développer des programmes de belle taille sans trop souffrir et profiter de la présence d'un OS plus facilement qu'en assembleur. Si la plateforme est surdimensionnée par rapport au projet on peu même envisager tout un panel d'autre langages.

Pour de l'embarqué "lourd" (ex: téléphone "intelligent", ordinateur de bord, ...) avec système d'exploitation, on a plus vraiment les contraintes du matériel de l'embarqué (je ne parle pas ici des contraintes de fiabilité et de redondance qu'on va avoir dans les avions par exemple). Pour ma part apprécie java pour son API, sa portabilité, et ses performances actuelles. On peu facilement interfacer du code java avec des librairies écrites en C, ce qui permet de prendre en charge les spécificités matérielles de la plateforme, tout en développant plus vite. Si une machine virtuelle fiable est disponible sur la plateforme, et que le projet le justifie, c'est une option qui peut être considérée. Si ce n'est pas nécessaire, pour ma part je reste sur du C.

[ManusDei]

Pour le reste, tu as (quasiment) aucune garantie formelle sur le comportement de ton code. Tu sais juste qu'il passe les tests que tu as écrits, qu'il évite les écueils détectables à la compilation (pointeur null, buffer overflow...) et qu'il suit les normes imposées en fonction du domaine. Ca ne te certifie formellement en rien ton programme, ca diminue juste (grandement) les risques.

Ensuite les bons programmeurs C vont commencer à devenir quelque chose de rare. Ce n'est plus un langage qui est fortement enseigné (20 ou 30H de cours ca ne suffit pas...) au détriment d'autres langages, même dans les parcours spécialisés. Produire du bon code C (à fortiori dans l'embarque), ca demande pas mal d’années d’expérience.

Les rares solveurs que j'ai vu ne font de la preuve que pour le C.
Tu as un exemple d'un solveur qui fonctionnerait avec un autre langage ?

tant qu'on fait pas de temps réel et que la carte sur laquelle tourne le soft est surdimensionnée, ça fonctionne pas mal...
en même temps dans le même boite, j'ai déjà fait du bureau à distance sur un windows XP installé sur une carte electronique qu'on retrouve dans plein de métros et de tramway... alors plus rien ne m'étonne.

C'est ce qu'ils disaient sur le projet où je suis quand ils l'ont commencé il y a 20 ans
Maintenant on tourne au dessus de 90% d'utilisation des ressources.

[gorgonite]

Les rares solveurs que j'ai vu ne font de la preuve que pour le C.
Tu as un exemple d'un solveur qui fonctionnerait avec un autre langage ?

1) y en a aussi sur Ada, C++ (au sens outil un peu formel...), sans parler de tous les DSL type schéma-bloc avec leur moteur de preuve intégré

2) qu'appelles-tu solveurs ?

[ManusDei]

2) qu'appelles-tu solveurs ?

Des outils permettant de prouver formellement du code.
solver est le terme anglais que j'ai vu, j'imagine qu'en français on dit plutôt moteur de preuve.

[gangsoleil]

Il en existe sur du C++, mais de la a me souvenir du nom... Je crois que le laboratoire VERIMAG travaillait dessus si tu veux chercher.

[gorgonite]

Des outils permettant de prouver formellement du code.
solver est le terme anglais que j'ai vu, j'imagine qu'en français on dit plutôt moteur de preuve.

Ok, donc le sens le plus générique du mot...

Tout d'abord, tu te doutes sûrement qu'on travaille souvent avec des sous-ensembles de langage (cf les règles MISRA & cie)
Alors prenons quelques exemples (plus ou moins industriels) :

1. Si tu as déjà du code
   
   • Pour Ada: SPARK
   • Pour C: Frama-C
   • Pour C et C++: Polyspace, Coverity
   • Pour C#: Spec#
2. Si tu veux générer un code "prouvé"
   
   • Atelier-B pour générer vers de l'Ada ou du C (voire du VHDL)
   • Simulink et les module Design Verifier & Coder (anciennement Real-Time Workshop)
3. Si tu veux compiler ce qui a été vérifié au dessus de manière fiable
   
   • les compilo classiques avec désactivation de (toutes ?) optimisations
   • CompCert cité précédemment

Et la liste est très longue

[ManusDei]

Tout d'abord, tu te doutes sûrement qu'on travaille souvent avec des sous-ensembles de langage (cf les règles MISRA & cie)

Oui, sur celui que j'utilise, vu qu'on est au niveau TU (enfin, preuve unitaire), on a par exemple pas le droit aux variables globales, ni droit à certains opérateurs du C ( cond ? fun1 : fun2 ; est interdit par exemple).

De toute la liste je connais que Frama-C, et CompCert.

Merci beaucoup pour les infos.

[alves1993]

C++