Du C ou du Java dans les systèmes embarqués automobile ?

Merci de ta réponse documentée.


zwim a écrit :

Dans un réseau CAN tout est en série sur le bus, donc pour chaque
périhpérique relié au bus, il faut un microcontroleur pour implémenter
le protocle de communication .

Donc il y a plein de microcontrôleurs dans une voiture, n'est-ce pas, des
dizaines ? Ce microcontrôleur, quelqu'un l'a programmé avec un langage pour
qu'il puisse gérer le protocole de communication dont tu parles (ou alors c'est
juste une circuiterie "morte") ?

En fait c'est pas si compliqué, il y a des mesures qui circulent sur
un réseau, et un processeur avec un gros soft dedans qui utilise ces
données pour faire fonctionner la voiture et en même temps offrir des
infos de bord au conducteur.

Et c'est à ce niveau et à ce niveau seulement que notre programmeur C/Java
intervient ?

Après la miniaturisation actuelle est telle que un processeur ça peut
être minuscule de nos jours et tu le programmes comme si tu
programmais sur un pc, avec juste quelques limitations en plus.

Oui mais est-ce que le processeur qu'on va trouver dans cette montre peut servir
à autre chose que gérer le programme de fonctionnement d'une montre ?


Et notre programmeur C ou java qu'est-ce qu'il va programmer dans tout ça ? que
si j'appuie sur tel bouton, je vais passer en mode chrono, que si j'appuie en
continu sur celui-là, les chiffres devront défiler ? Est-ce que notre
programmeur doit gérer l'affichage des segments de l'affichage LCD ou encore
doit-il gérer le changement de date en fonction de l'heure ? Je pose la question
parce que finalement faire programmer à quelqu'un qui apprend le C une montre de
ce type sur un PC (pas un microcontroleur), même dans une console et
éventuellement avec ncurses ou avec une bibliothèque graphique quelconque ne
serait pas très éloigné de ce que fait un professionnel de la programmation.

On 2009-07-01, zwim <zwim@f_ree.fr> wrote:

Le Thu, 2 Jul 2009 00:42:27 +0200
Zeldus a écrit

Il y a de l'électronique partout, même là ou on ne le croit pas.

Une amie s'est vue dans l'impossibilité de démarrer sa Clio (la clé de
contact ne faisait plus rien du tout lorsqu'elle la tournait) et sa voiture
a été immobilisée sans qu'elle comprenne vraiment ce qui se passait. Selon
Renault appelé sur place, ce serait un "bug informatique" qui serait
responsable. Après mise à jour du logiciel dans la voiture (de quoi ??),
tout est rentré dans l'ordre.

Ceci est un exemple parmi d'autres...

Je suis surpris de voir que Java occupe une place visiblement importante
dans les logiciels embarqués dans les voitures.

Faut pas être surpris.

L'embarqué c'est 90% de temps réel, et qui dit temps réel dit
programmation évènementielle, multitâche, multithread, tout ce que tu
veux.

Or Java offre par défaut une gestion assez sécurisée de tout ça, et
plus facile à mettre en oeuvre qu'en C. Ca n'empêche pourtant pas le C
d'être prépondérant.

Ben, C est plus proche de la machine. Vu que la machine virtuelle
Java impose que les int soient 32 bits, sur un proc 8 bits, c'est
pas gagné.
Et Java, c'est plein de new (une sorte de malloc pour les lecteurs
de fclc par familliers avec le C), et l'allocation dynamique, en
embarqué, on aime pas trop.

Il y a bien un courant de normalisation d'un Java Real Time.
La dernière fois qu'on m'en a parlé, ils étaient à 7 classes
de stockage... A ce rythme, C++ va devenir simple en comparaison.

Une solution courante en embarqué, c'est de définir son propre
cadre/framework (on dirait DSL de nos jours) pour gérer le multitache,
et de faire du C dedans.

Pourtant on peut faire du code très propre en C++, mais c'est juste
politique.

Pas juste politique. Problème de bassin de recrutement aussi.

Reste donc C et Java, C parce que c'est le langage à tout
faire, et Java pour son côté sécurisant.

Je dirais le contraire. C parce que comme on en fait depuis
toujours, c'est sécurisant. Java parce qu'en 2009, c'est le langage
à tout faire.

Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...

On 2009-07-01, candide <candide@free.invalid> wrote:

zwim a écrit :

D'autre part en "auto" les règles de programmations sont assez
strictes (pas d'allocation dynamique par exemple, c'est la foire à la
variable globale, mais au moins pas de plantage aléatoire dû à ça),

Donc les programmeurs qui ont entendu dire pendant toute leur formation "les
variables globales vont conduiront en enfer" devront se déconditionner pendant
quelques semaines ...

Tout à fait.
Encore que, ils verront aussi pourquoi c'est pénible: besoin de
doc qui précisent regroupent toutes les var...
Et puis bon, ils auront besoin de se conditionner à plein
d'autres choses aussi.

Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...

On 2009-07-01, candide <candide@free.invalid> wrote:

Zeldus a écrit :

Bonjour,

Les voitures faisant de plus en plus appel à l'électronique pour
fonctionner, même pour les tâches les plus basiques, en quel langage
sont programmés les applications qui gèrent les différentes fonctions
électroniques intégrés aux voitures ?

Question tout à fait intéressante qui permettrait de se donner une idée de
l'importance actuelle du C en informatique industrielle. Ce serait bien surtout
si on pouvait avoir des références et en particulier des références chiffrées.

Je n'ai pas de chiffre, mais je peux te parler de ce que je connais,
le constructeur Airbus.
Dans la partie "critique", c'est en général programmé dans un langage
"métier", semi-graphique. Ce langage fait appel à des primitives, codées,
elles en C à la main.
Nous travaillons avec le CEA sur des outils d'analyse statique, donc pour
l'embarqué avion mais potentiellement aussi le nucléaire. Le langage cible
est C. Java n'est pas à ma connaissance sur les écrans radards.

Bon comme je n'y connais rien, je voudrais savoir, si on considère par exemple
une montre électronique (genre montre-bracelet courante) capable de donner
l'heure, la date, de déclencher une alarme sonore et de faire chrono avec
interruption et fonction lap, est-ce qu'une telle montre contient un
"processeur" ? Je suppose qu'on a dû coder quelque chose mais ça a été codé
comment ? dans un langage (assembleur ou autre) ou c'est juste une circuiterie
hadware ?

Aucune idée. Les microprocesseurs faible puissance (on parle aussi de micro
controleur) ont beaucoup baissé de prix, et il est peut-être moins cher
de mettre un microcontroleur générique qu'un circuit dédié. Il y a aussi
la famille des FPGA, des circuits génériques qu'on transforme en
circuit dédié...

Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...

On 2009-07-02, zwim <zwim@f_ree.fr> wrote:

Le Thu, 02 Jul 2009 01:50:01 +0200
candide a écrit

zwim a écrit :

D'autre part en "auto" les règles de programmations sont assez
strictes (pas d'allocation dynamique par exemple, c'est la foire à la
variable globale, mais au moins pas de plantage aléatoire dû à ça),

Donc les programmeurs qui ont entendu dire pendant toute leur formation "les
variables globales vont conduiront en enfer" devront se déconditionner pendant
quelques semaines ...

Bah oui et non.

Ca reste toujours une mauvaise pratique à mon sens d'en avoir qui
trainent partout, risque de confusion, de collisions de noms,
d'erreurs de link, d'appel sauvage en dehors du contexte, etc...

D'ou un besoin d'un process de développement contraignant qui
évite ce genre de chose.
Oui, c'est plus chiant de développer de l'embarqué que pour
un unix.

En revanche, définir une (ou plusieurs, par exemple une pour chaque
tâche) structure globale, mettre les variables dedans et passer un
pointeur sur la structure aux fonctions qui ont besoin des gobales
c'est satisfaisant.

Donc, à chaque appel de fonction, on passe un pointeur sur la
pile, à chaque appel à une variable, on se paye une indirection,
et il faut un processus qualité qui vérifie que tout le monde
travaille bien avec le bon pointeur sur la bonne structure.
A oui, il faut aussi que la structure soit définie dans une
unité de compilation unique.

Et si demain, la politique change, y'a qu'à allouer la structure, au
lieu de la laisser bêtement sur la pile.

D'abord, il y a de fort chance qu'elle ne soit pas sur la pile
mais dans un segment de donnée de taille fixe.

Ensuite,je suis prêt à parier assez cher qu'on ne verra pas de "malloc"
demain dans un calculateur automobile chargé de fonctions critiques.

Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...

candide <candide@free.invalid> writes:

Bon comme je n'y connais rien, je voudrais savoir, si on considère par exemple
une montre électronique (genre montre-bracelet courante) capable de donner
l'heure, la date, de déclencher une alarme sonore et de faire chrono avec
interruption et fonction lap, est-ce qu'une telle montre contient un
"processeur" ?

Je ne pense pas mais si on tappe suffisemment haut (montre avec synchro sur
signal radio ou GSM) on doit arriver a un point ou il y en a.

Je suppose qu'on a dû coder quelque chose mais ça a été codé comment ?
dans un langage (assembleur ou autre) ou c'est juste une circuiterie
hadware ?

On peut faire ca facilement avec ce que tu appelles "juste une circuiterie
hardware". Pour rappel, un processeur c'est aussi "juste une circuiterie
hardware". Le tout est de savoir a quel point la taille de la serie prevue
fait que diminuer le cout initial est plus important que de diminuer le
cout de fabrication a la piece (entre le circuit full custom et
l'utilisation de composants purement generique, le hard fournit une serie
de points de compromis -- les FPGA en sont un). Dans le cas des montres,
ca me m'etonnerait pas qu'ils fassent des modules utilises dans plusieurs
modeles vendus pour augmenter la taille des series et donc amortir les
couts fixes.

A+

--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org

candide <candide@free.invalid> writes:

Bon comme je n'y connais rien, je voudrais savoir, si on considère par exemple
une montre électronique (genre montre-bracelet courante) capable de donner
l'heure, la date, de déclencher une alarme sonore et de faire chrono avec
interruption et fonction lap, est-ce qu'une telle montre contient un
"processeur" ?

Je ne pense pas mais si on tappe suffisemment haut (montre avec synchro sur
signal radio ou GSM) on doit arriver a un point ou il y en a.

Je suppose qu'on a dû coder quelque chose mais ça a été codé comment ?
dans un langage (assembleur ou autre) ou c'est juste une circuiterie
hadware ?

On peut faire ca facilement avec ce que tu appelles "juste une circuiterie
hardware". Pour rappel, un processeur c'est aussi "juste une circuiterie
hardware". Le tout est de savoir a quel point la taille de la serie prevue
fait que diminuer le cout initial est plus important que de diminuer le
cout de fabrication a la piece (entre le circuit full custom et
l'utilisation de composants purement generique, le hard fournit une serie
de points de compromis -- les FPGA en sont un). Dans le cas des montres,
ca me m'etonnerait pas qu'ils fassent des modules utilises dans plusieurs
modeles vendus pour augmenter la taille des series et donc amortir les
couts fixes.

A+

--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
GROUP fr.comp.lang.c

On 2 juil, 01:50, candide <cand...@free.invalid> wrote:

zwim a crit :

> D'autre part en "auto" les r gles de programmations sont assez
> strictes (pas d'allocation dynamique par exemple, c'est la foire la
> variable globale, mais au moins pas de plantage al atoire d a),

Donc les programmeurs qui ont entendu dire pendant toute leur formation " les
variables globales vont conduiront en enfer" devront se d conditionner pe ndant
quelques semaines ...

Tu continues à confondre portée et persistance. C'est consternant...
Bien sûr qu'on a besoin de variables persistantes pour conserver les
données. Ce qui est démoniaque, c'est de leur donner une portée
globale. Que la persistance soit faite par allocation statique ou
dynamique ne change rien au codage (à par l'instanciation). Dans tout
les cas, il faut travailler par contexte (structures, pointeurs etc.)

Le 2 juillet 2009, candide a écrit :

Est-ce que notre programmeur doit gérer l'affichage des segments de
l'affichage LCD ou encore doit-il gérer le changement de date en
fonction de l'heure ?

Ça m'étonnerait beaucoup : faire une puce pour l'affichage ne demande que
quelques portes logiques. Il faut combiner 4 bits en entrée (pour coder
les chiffres de 0 à 9) en 7 sorties (un par segment). Par exemple, le
segment du haut est allumé pour 0 2 3 5 6 7 8 9, éteint pour 1 (0001) et 4
(0100). Donc cette sortie est !((!a & !b & !c & d) | (!a & b & !c & !d))
(avec abcd les 4 bits d'entrée).

Pour le changement de date, ce n'est qu'une sorte de propagation de
retenue, pas bien compliqué non plus.

Dans un « simple » chronomètre par exemple je doute qu'il y ait le moindre
processeur. Un bouton qui démarre/arrête l'horloge, un bouton de RàZ de
l'affichage, un bouton qui branche/débranche le lien horloge/affichage
(pour les temps intermédiaires).

--
LL

On 2 juil, 02:05, candide <cand...@free.invalid> wrote:

Donc il y a plein de microcontrôleurs dans une voiture, n'est-ce pas, d es
dizaines ? Ce microcontrôleur, quelqu'un l'a programmé avec un langag e pour
qu'il puisse gérer le protocole de communication dont tu parles (ou alo rs c'est
juste une circuiterie "morte") ?

Une circuiterie 'morte', ça s'appelle un circuit intégré (VLSI etc.)
ou un FPGA (un peu à la frontière entre CI et µC). Sinon, un µC est
par définition programmable et comprend un programme qui a été écri t
un jour par un humain (probabbement en C) puis traduit en exécutable,
comme d'habitude. ce n'est pas plus bizearre ou mystérieux que ton
PCquand il démarre. Le programme ede démarrage est placé dans une
'PROM' (le plus souvent, une mémoire flash, de nos jours) et il
exécute ce qu'il faut au RESET.

Et c'est à ce niveau et à ce niveau seulement que notre programmeur C /Java
intervient ?

Il intervient pour la mise en oeuvre des périphériques (VLSI et autres
FPGA) qui sont souvent programmables. Iil faut mettre des valeurs dans
certains registres pour assurer telle ou telle fonction, superviser
les états, valeurs physiques, alarmes etc.

Oui mais est-ce que le processeur qu'on va trouver dans cette montre peut servir
 à autre chose que gérer le programme de fonctionnement d'une montr e ?

Oui, mais ça dépend des périphériques.

Et notre programmeur C ou java qu'est-ce qu'il va programmer dans tout ça ? que
si j'appuie sur tel bouton, je vais passer en mode chrono, que si j'appui e en
continu sur celui-là, les chiffres devront défiler ? Est-ce que notre
programmeur doit gérer l'affichage des segments de l'affichage LCD  o u encore
doit-il gérer le changement de date en fonction de l'heure ? Je pose la question
parce que finalement faire programmer à quelqu'un qui apprend le C une montre de
ce type sur un PC (pas un microcontroleur), même dans une console et
éventuellement avec ncurses ou avec une bibliothèque graphique quelco nque ne
serait pas très éloigné de ce que fait un professionnel de la progr ammation.

Très éloigné, en effet. Dans mon ex-métier (application embarquée s
pour réseaux numériques), je n'ai jamais utilisé ncurses ! La plupart
du fonctionnement est invisible (quelques LEDs, c'est tout). Par
contre, les machines étant communicantes, on récupère les données s ur
un poste du supervision qui permet de visualiser les alarmes et autres
informations en temps réel... Le poste en question est une station
(PC) sous Windows avec une application en VB.

Idem pour la configuration... (en fait c'est un peu plus compliqué, il
y a un serveur et des clients...)