OVH Cloud OVH Cloud

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

246 réponses
Avatar
Zeldus
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 ?

J'ai pensé à l'assembleur mais vu la aujourd'hui puissance et le prix des
processeurs même les plus basiques, je pense que ce n'est pas le cas et la
tâche serait complexe pour les programmeurs.

Vient ensuite le C, celui qui serait probablement le plus adapté, ancien
mais toujours très efficace ou alors Java, complètement portable mais qui
nécessite une machine virtuelle assez lourde.

Si vous avez des infos sur le sujet,

Par avance, merci

Pierre

10 réponses

Avatar
Michael Doubez
On 9 juil, 10:37, Marc Boyer wrote:
On 2009-07-09, Michael Doubez wrote:


[snip]
>> souvent pas de pointeur, et parfois
>> même pas de variable sur la pile (tout en static).

> Le standard C++ ne prévoit pas de stack, juste un temps de vie des
> variables.

  Ne pinaille pas: tu parles de "dépassement de pile" dans le paragra phe
au dessus, qui n'est prévu ni par le standard C, ni le C++.



Pardon.
Enfin, si je voudrais pinailler un peu parce que la plupart des
langages font qu'une stack est très utile et je ne pense pas que c'est
ce qu'ils entendent pas sous-ensemble safe.

Qu'ils disent que les exceptions consomme du code inutilement à cause
de RTTI ou alors que le méchanisme a des effets de bord (je ne sais
pas) indésirable, je suis près à l'entendre.

Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
savoir plus sur leur motivation.

--
Michael
Avatar
bpascal123
>   Je ne saurait que vous conseiller deux ouvrages d'Andrew Tanenbaum,
"les réseaux" et "systèmes d'exploitation". Et puis
"Accelerated C++" aussi, de Koenig et Moo.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.http://www.inega lites.fr/spip.php?article1&id_mot0



Bonjour,

Merci pour votre réponse qui m'amènerait à d'autres questions. Mais
comme je ne suis pas sûre d'être capable de définir un bit, je préf ère
m'en tenir à un domaine que je connais ; la comptabilité.

En fait, je voulais savoir si on peut tronquer un signal gps. Par
exemple, je commets une infraction du code de la route sur une route
x, à une heure t, est-ce que je peux modifier la mémoire du télépho ne
et dire que j'étais dans une autre ville...dans une rue piétonne...?

Cordialement,

Pascal
Avatar
Wykaaa
Marc Boyer a écrit :
On 2009-07-08, wrote:
Bonjour,

Je commence à apprendre le C le soir et le week-end sans expérience
particulière en informatique ni mathématique ou électronique. Je suis
comptable de formation. La programmation peut être intéressante je
pense pour des systèmes de gestion de données comme Oracle. A
condition d'élargir l'apprentissage de la programmation à java.



De toute façon, une formation d'informaticien ne saurait se
restreindre à un seul langage, surtout un impératif type C. Il
faudrait aussi un moins un langage orienté objet (C++ ou Java),
un langage fonctionnel (Caml, Haskell, Lisp...), et puis une
formation en algorithmique.
Et puis un peu de compilation, un peu de réseau, un soupson
de complexité, un peu de base de donnée, de l'architecture
des ordinateurs, etc.
Enfin, il suffit d'aller regarder le programme des DUT d'info quoi...

Je
pense que sur 3 ou 5 ans, je peux acquérir une petite adresse. Si
j'ajoute un congé de 3-6 mois pour une formation intensive en Inde,
peut-être je peux devenir l'auxiliaire d'un consultant



Pourquoi pas un DUT en un an tout simplement ?



Tout à fait. Il te faut faire une "vraie" formation à l'informatique.
A part quelques exceptions, tous les "informaticiens" que j'ai côtoyés
et qui s'étaient formés tout seul, c'était une catastrophe...

Pour en revenir à la discussion sur les différents langages
informatiques, il me semble comprendre que le C permet de faire des
choses variées.



On devrait même pouvoir dire qu'il permet de tout faire
de ce qu'on peut faire avec un ordinateur, ou presque (pour
aller positionner certains flags du processeur, il faut
aller taper directement l'ASM).



Tout langage de programmation "Turing complet" permet de programmer
toute fonction effectivement calculable (au sens de Church et Turing).
C, Ada, Pascal, Java, etc. sont des langages Turing complet. SQL n'est
pas un langage Turing complet.
Voir : http://fr.wikipedia.org/wiki/Turing-complet

Attention cependant, tout problème n'est pas automatisable. C'est à dire
qu'il n'existe pas toujours un algorithme pour un problème. Les
problèmes indécidables ne sont pas automatisables car un problème
indécidable est un problème pour lequel il n'existe pas de procédure de
décision, donc pas d'algorithme. Le problème de la terminaison d'un
programme est un problème indécidable, par exemple, ou encore la
résolution d'équations polynomiales à coefficients et solutions entières
(équations diophantiennes) de degré quelconque.




[snip]
Avatar
Mickaël Wolff
Wykaaa a écrit :

Tout à fait. Il te faut faire une "vraie" formation à l'informatique.
A part quelques exceptions, tous les "informaticiens" que j'ai côtoyés
et qui s'étaient formés tout seul, c'était une catastrophe...



Il ne faut pas généralisé. J'ai côtoyé des développeurs qui avaient
fait un IUT, et c'était pas fameux. La formation ne fait pas tout.

Je connais un gars (ou un, pas deux) qui a appris le Basic et
l'assembleur à 11 ans sur Amiga, puis a fait une carrière de coiffeur
pour ensuite réussir à créer une boîte de développement qu'il a revendu
(il ne voulait plus être chef d'entreprise). Je l'ai rencontré dans une
formation AFPA parce qu'il avait besoin d'un diplôme qu'il puisse
montrer à des employeurs potentiels (en France, les autodidactes sont
mal perçus, même s'ils sont géniaux).

'fin bref, ça ne l'a pas trop aidé, et il a finalement monté un
nouveau business autour d'un OS qu'il a écrit. Le diplôme ne l'a pas
vraiment aidé parce que le diplôme que nous avons réussit n'est pas très
connu. Et puis, on est sorti de la formation en 2002 (sale année pour
les développeurs).

Voilà pour la parenthèse.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Seeking for a position <http://lupusmic.org/pro/>
Avatar
Marc Boyer
On 2009-07-09, wrote:

En fait, je voulais savoir si on peut tronquer un signal gps. Par
exemple, je commets une infraction du code de la route sur une route
x, à une heure t, est-ce que je peux modifier la mémoire du téléphone
et dire que j'étais dans une autre ville...dans une rue piétonne...?



C'est bien sûr théoriquement possible. Mais cela peut demander
un nombre d'heures très important (à chiffrer en années peut-être).

Et puis bon, le fait que le portable de M. X n'ait pas été
au même endroit que la voiture de M. X au moment où
commettait une infraction ne me semble pas une preuve
suffisante que l'infraction n'ait pas été commise.
Mais je ne suis pas juriste.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Avatar
Marc Boyer
On 2009-07-09, Michael Doubez wrote:
On 9 juil, 10:37, Marc Boyer wrote:
On 2009-07-09, Michael Doubez wrote:


[snip]
>> souvent pas de pointeur, et parfois
>> même pas de variable sur la pile (tout en static).

> Le standard C++ ne prévoit pas de stack, juste un temps de vie des
> variables.

  Ne pinaille pas: tu parles de "dépassement de pile" dans le paragraphe
au dessus, qui n'est prévu ni par le standard C, ni le C++.



Pardon.
Enfin, si je voudrais pinailler un peu parce que la plupart des
langages font qu'une stack est très utile et je ne pense pas que c'est
ce qu'ils entendent pas sous-ensemble safe.



Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.

Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
savoir plus sur leur motivation.



Tu dois renverser ton raisonnement quand tu parles de système critique.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.

Pour pouvoir *garantir* le débordement de pile, interdire les
allocations de variable automatiques sur la pile est un moyen.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Avatar
Michael Doubez
On 9 juil, 12:54, Marc Boyer wrote:
On 2009-07-09, Michael Doubez wrote:



> On 9 juil, 10:37, Marc Boyer wrote:
>> On 2009-07-09, Michael Doubez wrote:
> [snip]
>> >> souvent pas de pointeur, et parfois
>> >> même pas de variable sur la pile (tout en static).

>> > Le standard C++ ne prévoit pas de stack, juste un temps de vie des
>> > variables.

>>   Ne pinaille pas: tu parles de "dépassement de pile" dans le para graphe
>> au dessus, qui n'est prévu ni par le standard C, ni le C++.

> Pardon.
> Enfin, si je voudrais pinailler un peu parce que la plupart des
> langages font qu'une stack est très utile et je ne pense pas que c'es t
> ce qu'ils entendent pas sous-ensemble safe.

   Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.



En C ou dans d'autre langage.
AMA, c'est une erreur au même titre qu'une FPE, ça ne tiens pas au
langage même si le langage peut masquer ces aspects.

> Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
> savoir plus sur leur motivation.

  Tu dois renverser ton raisonnement quand tu parles de système criti que.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.



D'accord donc qu'est ce qu'ils n'ont pas pu certifier ?
Quelle partie du langage amènerait un programme unsafe (je parle pas
des fonctions unsafe par nature comme strlen ...) ?

--
Michael
Avatar
pjb
Michael Doubez writes:

On 9 juil, 12:54, Marc Boyer wrote:
On 2009-07-09, Michael Doubez wrote:
   Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.



En C ou dans d'autre langage.
AMA, c'est une erreur au même titre qu'une FPE, ça ne tiens pas au
langage même si le langage peut masquer ces aspects.



Ce n'est pas non plus un problème de langage, comme indiqué par
ailleurs, le standard C ou C++ n'impose pas un gestion particulière
d'une pile. Les cadres pourraient être alloués sur le tas, et alors
on n'aurait pas de "stack overflow" mais un normal "out of memory".


> Mais qu'ils disent qu'il y a des parites *unsafe*... j'aimerais en
> savoir plus sur leur motivation.

  Tu dois renverser ton raisonnement quand tu parles de système critique.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.



D'accord donc qu'est ce qu'ils n'ont pas pu certifier ?
Quelle partie du langage amènerait un programme unsafe (je parle pas
des fonctions unsafe par nature comme strlen ...) ?



Quasiment tout le langage C (et donc C++) est unsafe. Par exemple,
les 'arrays'. C'est pourquoi quand on mentionne 'array' en C++, tout
le monde réplique std::vector.

------------------------------------------------------------------------
int f(int x){
char h[]="hello";
return(h[x]);
}

#include <iostream>
using namespace std;
int main(){
cout<<"Output (if you're lucky): "<<f(10)<<" "<<f(-10)<<endl;
return(0);
}

/*
-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Thu Jul 9 14:21:42

SRC="/tmp/u.c++" ; EXE="u" ; g++ -Werror -Wall -pedantic -g3 -ggdb3 -o ${EXE} ${SRC} && ./${EXE} && echo status = $?
Output (if you're lucky): 64 0
status = 0

Compilation finished at Thu Jul 9 14:21:42
*/
------------------------------------------------------------------------

Notez bien que ce n'est pas strictement un problème de langage, mais
plutôt de culture. PCQJS, le langage C permet parfaitement des
implémentations qui vérifiraient les règles concernant les array et
pointeurs. Si les compilateurs de langages comme Pascal ou Lisp
peuvent le faire, pourquoi pas les compilateurs C ou C++?

Ce qui est idiot, ce n'est pas de choisir le langage C ou C++ pour un
logiciel critique, c'est de choisir un compilateur qui génère du code
aveugle. (Après, reste la question du choix d'un langage à la syntaxe
ridicule comme celle du C ou C++, mais ça c'est une question de goût
et de couleur...).

--
__Pascal Bourguignon__
Avatar
Marc Boyer
Le 09-07-2009, Michael Doubez a écrit :
On 9 juil, 12:54, Marc Boyer wrote:
On 2009-07-09, Michael Doubez wrote:



> On 9 juil, 10:37, Marc Boyer wrote:
>> On 2009-07-09, Michael Doubez wrote:
> [snip]
>> >> souvent pas de pointeur, et parfois
>> >> même pas de variable sur la pile (tout en static).

>> > Le standard C++ ne prévoit pas de stack, juste un temps de vie des
>> > variables.

>>   Ne pinaille pas: tu parles de "dépassement de pile" dans le paragraphe
>> au dessus, qui n'est prévu ni par le standard C, ni le C++.

> Pardon.
> Enfin, si je voudrais pinailler un peu parce que la plupart des
> langages font qu'une stack est très utile et je ne pense pas que c'est
> ce qu'ils entendent pas sous-ensemble safe.

   Pourtant, "stack overflow" est une erreur bien connue, et en C,
je ne connais aucun moyen de s'en prémunir.



En C ou dans d'autre langage.
AMA, c'est une erreur au même titre qu'une FPE, ça ne tiens pas au
langage même si le langage peut masquer ces aspects.



Non, en Java et Ada (si mes souvenirs sont bons), cela lève
une exception qui peut être traitée. En C, il n'y a à ma connaissance
rien pour réagir à une telle chose.

  Tu dois renverser ton raisonnement quand tu parles de système critique.
La question n'est pas d'identifier les paries "unsafe", mais les
parties certifiables dans un contexte matériel, environnemental,
le tout dans un processus de certification/d'assurance.



D'accord donc qu'est ce qu'ils n'ont pas pu certifier ?



Tu m'en demandes trop pour que je te donne les détails.
Mais de manière générale, tu raisonnes encore à l'envers. La question
n'est pas "que ne *peut-on* pas certifier", mais quelle partie
décide-t-on de certifier ?
On peut certifier qu'il n'y aura jamais de dépassement de pile
en traçant les appels de sous-programmes, en interdisant les récursions,
et en calculant les tailles maximales de variables locales utilisées
par exemple. Mais cela suppose que chaque modif dans une fonction
impose une revalidation globale. Si tu interdits les variables
locales (tu obliges à avoir du static), tu as un problème de moins.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Avatar
Bruno Desthuilliers
Wykaaa a écrit :
(snip)
Tout à fait. Il te faut faire une "vraie" formation à l'informatique.
A part quelques exceptions, tous les "informaticiens" que j'ai côtoyés
et qui s'étaient formés tout seul, c'était une catastrophe...



La catastrophe te salue bien (et retourne corriger les boulettes du
diplômé issu d'une "vraie" formation, mouarf).