IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Affichage des résultats du sondage: Quels langages pour le développement embarqué ?

Votants
73. Vous ne pouvez pas participer à ce sondage.
  • Assembleur

    16 21,92%
  • C

    48 65,75%
  • C++

    25 34,25%
  • Java

    15 20,55%
  • .Net

    7 9,59%
  • Autres

    10 13,70%
Sondage à choix multiple
Embarqué Discussion :

Logiciel embarqué : quels langages pour le développement embarqué ?


Sujet :

Embarqué

  1. #21
    Membre habitué Avatar de monnoliv
    Homme Profil pro
    Opticien-ébéniste: lunettes de WC
    Inscrit en
    Août 2003
    Messages
    139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Opticien-ébéniste: lunettes de WC

    Informations forums :
    Inscription : Août 2003
    Messages : 139
    Points : 195
    Points
    195
    Par défaut
    Pour le petit embarqué (8-16bits), sans hésiter, le C.
    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. Si le timing est critique à un moment donné, je désassemble le code compilé juste pour voir s'il est bien optimisé).
    Aussi, si possible pas d'OS afin de faire ce que j'appelle du vrai temps réel (100% de maîtrise du temps, pas 99.5%), bien sûr il faut en avoir besoin.
    Pour le gros embarqué (32bits) on a plus de choix puisqu'en général ces systèmes ont de plus grandes ressources processeur (mais ce n'est pas nécessairement vrai dans tous les cas, voire le Cortex-M0 par exemple), donc je prendrais du C++ voire peut-être un langage managé. Malheureusement avec ces langages reposant sur des OS (linux, RTOS,...) multiprocess, on perd la maîtrise du "vrai temps réel" (le 100%).
    IoT CC3200, ESP8266
    8051, ARM Cortex-M (forever)/Cortex A (TI, Silabs, NXP), FPGA, Bare Metal Raspberry-PI programming
    VHDL-ALTERA-XILINX
      0  0

  2. #22
    Membre confirmé
    Profil pro
    Inscrit en
    Février 2007
    Messages
    229
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Février 2007
    Messages : 229
    Points : 543
    Points
    543
    Par défaut
    langage utilise : C C++ et ADA
    Le choix du langage depend pas mal de la complexite du programme et de ressources dispo
    Sur un micro controleur 8 bits on va pas faire du C++

    experience perso:
    C: l outil a tout faire. on le trouve sur des gros (taille du code et ressources) projets ou sur des tout petit (genre le micro controleur qui va gerer l ouverture des portes de la voiture)

    c++ : moins courant, performances inferieure a C. Utilise en general sur des systeme moins critique. par exemple l interface graphique. Un exemple est l Audi MMI

    ADA : surtout utilise dans l aeronautique/spacial. Maintenant il y a une version oriente objet (que j ai jamais utilise. J ai seulement utilise ada 83)
    C est le langage que j aime le moins. Il n est pas possible d etre vraiment proche du materiel (pointeur nexiste pas par ex) . De plus le prix d un compilateur ADA est tres eleve. Avec la meme somme on peu avoir pas mal d outil C/C++ qui permettent d avoir du code de qualite (polyspace, purify ...)
      0  1

  3. #23
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Citation Envoyé par cdubet Voir le message
    c++ : [...]performances inferieure a C.
    Totalement faux.
      2  0

  4. #24
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par 3DArchi Voir le message
    Totalement faux.
    si on met un développeur Java sur du C++ histoire d'embarqué du code... oui
    si on prend quelqu'un d'un peu sérieux, pas sûr qu'on perde énormément
    si on prend un mega-expert et qu'on espère ne plus avoir à relire le boulot... ça peut même aller vite
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog
      1  0

  5. #25
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    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

  6. #26
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par 3DArchi Voir le message
    si on met un développeur Java sur du C++ C histoire d'embarqué du code on aura le même problème
    mais certains pensent C++ = POO => Java-compliant (j'en vois beaucoup )
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog
      1  0

  7. #27
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Citation Envoyé par gorgonite Voir le message
    mais certains pensent C++ = POO => Java-compliant (j'en vois beaucoup )
    J'ai pas compris ce que tu voulais dire
    En tout cas, POO en C++ ne veut pas dire moins performant que C.
      0  0

  8. #28
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    En ce moment, C++ (enfin ... en version pré-98 étant limité à gcc 2.95.3), sur un XScale PXA270/ARM v5te, avec un OS linux 2.6.19 pas RT.
    Je suis très frustré par les déficiences dont je suis prisonnier (vieux gcc, pas d'atomics/TLS directement compris par gcc), mais bon, c'est toujours mieux que sans les + (en ce qui me concerne)
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
      1  0

  9. #29
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    612
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2008
    Messages : 612
    Points : 1 050
    Points
    1 050
    Par défaut
    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

  10. #30
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par 3DArchi Voir le message
    J'ai pas compris ce que tu voulais dire
    En tout cas, POO en C++ ne veut pas dire moins performant que C.
    je dis que pour beaucoup trop de "managers" un langage OO implique le sous-ensemble de UML portable partout, et ils seraient capables de prendre des dev Java pour les passer en C++ sur un projet ponctuellement... ce qui tuerait les perfs
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog
      1  0

  11. #31
    Membre habitué

    Homme Profil pro
    Developpeur
    Inscrit en
    Mars 2011
    Messages
    115
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Developpeur

    Informations forums :
    Inscription : Mars 2011
    Messages : 115
    Points : 188
    Points
    188
    Par défaut Reponse au Question
    Pou moi : Système Embarqué = Système informatique (Avec OS ou sans OS) pour réaliser une tache bien précise.
    Coté langage

    - Roi du système embarqué : ASM et C (pouvant manipuler des taches bas niveaux et haut niveaux)
    - Les descendants (tendances) : C++, C# et Java (Faciliter d'u
    Innovation = Blending of idea , science and practice engineering
      0  0

  12. #32
    Membre habitué Avatar de monnoliv
    Homme Profil pro
    Opticien-ébéniste: lunettes de WC
    Inscrit en
    Août 2003
    Messages
    139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Opticien-ébéniste: lunettes de WC

    Informations forums :
    Inscription : Août 2003
    Messages : 139
    Points : 195
    Points
    195
    Par défaut
    "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.
    Bon, désolé mais je ne peux pas, laisser passer ça non plus

    1. Le langage d'assemblage (d'abord est-ce bien un langage) n'est pas portable contrairement au C qui lui, l'est bien. Et je regrette mais le langage d'assemblage est bien illisible.
    2. "C qui se compile le mieux" veut dire : plus près de la machine donc plus véloce une fois compilé, contrairement à Pascal par exemple. Mais il est évident que C sera toujours plus lent que l'assembleur (bien programmé).
    3. Tu parles du PIC16F, il me semble que j'ai déjà eu une discussion avec toi sur un autre forum, ce microcontroleur est une vraie plaie. Son architecture est merdique, c'est le seul que je connaisse qui n'a qu'un seul registre !!! On ne compare pas des pommes et des poires. Tout qui connait un peu l'historique de la compilation C sur cette m... sait qu'on a mis du temps à développer un vrai compilateur ANSI C pour cette cible tellement ce n'était pas évident avec son monoregistre . M'étonne pas que du écrives "on constate que le taux d'expansion est énorme"

    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.
    C'est pour cela que je mets "vrai temps réel" entre guillemets. Je connais la définition du temps réel mais elle ne me convient pas du tout. Je la trouve nulle et à ce compte n'importe quel OS est temps réel.
    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.
    Faux, Il suffit de travailler avec les interruptions. Ne me parle pas des sauvegardes de registres, de jitter, ... tout ça peut être parfaitement borné (u compris en C, encore une fois, il suffit de désassembler le code). Si tu n'es pas convaincu, je suis prêt à déposer un petit exemple ici même.

    Maintenant, entendons-nous, je ne t'attaque pas et je n'attaque pas tes choix
    Je l'entends bien mais le problème c'est que tu répands des contre-vérités en prenant des exemples qui fonctionnent bien dans tes cas à toi.
    Chacun fait des choix qui lui convient le mieux en fonction de ses besoins. Il n'en reste pas moins vrai qu'il y a clairement des généralités qu'on peut exprimer sans se tromper dans la majorité des cas.
    A+
    Olivier
    IoT CC3200, ESP8266
    8051, ARM Cortex-M (forever)/Cortex A (TI, Silabs, NXP), FPGA, Bare Metal Raspberry-PI programming
    VHDL-ALTERA-XILINX
      0  0

  13. #33
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par monnoliv Voir le message
    1. Le langage d'assemblage (d'abord est-ce bien un langage) n'est pas portable contrairement au C qui lui, l'est bien. Et je regrette mais le langage d'assemblage est bien illisible.
    pas plus que le C pour un non initié

    Citation Envoyé par monnoliv Voir le message
    Mais il est évident que C sera toujours plus lent que l'assembleur (bien programmé).
    bof... vu les perfs des optimisations actuelles, et si l'on sait minimiser les dépendances statiques, ça devrait pouvoir se faire (point de vue vitesse). et avec les nouveaux éditeurs de lien "intelligents" ça devrait encore améliorer les compilos... sachant que pour les rares opérations critiques, C autorisé d'inliner de l'asm dans son code

    Citation Envoyé par monnoliv Voir le message
    Son architecture est merdique, c'est le seul que je connaisse qui n'a qu'un seul registre !!!
    et alors ?
    y a encore des contrôleurs entièrement à pile
    suffit de s'adapter à cette contrainte (ou d'adapter le langage )

    Citation Envoyé par monnoliv Voir le message
    C'est pour cela que je mets "vrai temps réel" entre guillemets. Je connais la définition du temps réel mais elle ne me convient pas du tout. Je la trouve nulle et à ce compte n'importe quel OS est temps réel.
    ah
    selon ma définition de temps-réel aucun OS grand public ne l'est... et tous les OS tentant d'être mieux qu'une simple boucle lançant une séquence de tâches n'arrivent que rarement à être temps-réel dur
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog
      0  0

  14. #34
    Membre habitué Avatar de monnoliv
    Homme Profil pro
    Opticien-ébéniste: lunettes de WC
    Inscrit en
    Août 2003
    Messages
    139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Opticien-ébéniste: lunettes de WC

    Informations forums :
    Inscription : Août 2003
    Messages : 139
    Points : 195
    Points
    195
    Par défaut
    pas plus que le C pour un non initié
    A supposer qu'on connaisse le C et l'assembleur (d'une cible particulière), il me semble évident que C est plus lisible
    et alors ?
    y a encore des contrôleurs entièrement à pile
    suffit de s'adapter à cette contrainte (ou d'adapter le langage )
    On peut aussi encore programmer sur le Z80 ou le 6502 mais y a mieux actuellement
    selon ma définition de temps-réel aucun OS grand public ne l'est
    Effectivement,
    IoT CC3200, ESP8266
    8051, ARM Cortex-M (forever)/Cortex A (TI, Silabs, NXP), FPGA, Bare Metal Raspberry-PI programming
    VHDL-ALTERA-XILINX
      0  0

  15. #35
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par monnoliv Voir le message
    On peut aussi encore programmer sur le Z80 ou le 6502 mais y a mieux actuellement

    reste que des dérivés de Z80 sont encore utilisés dans de vrais gros projets industriels de nos jours
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog
      0  0

  16. #36
    Membre habitué Avatar de monnoliv
    Homme Profil pro
    Opticien-ébéniste: lunettes de WC
    Inscrit en
    Août 2003
    Messages
    139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Opticien-ébéniste: lunettes de WC

    Informations forums :
    Inscription : Août 2003
    Messages : 139
    Points : 195
    Points
    195
    Par défaut
    Je ne sais pas pour le Z80 mais en ce qui concerne le 8051, les dérivés actuels sont bien plus puissants en terme de vitesse (x100 sans problème) et de périphériques que l'original! Il n'y a vraiment plus que le code d'assemblage qui reste commun.
    IoT CC3200, ESP8266
    8051, ARM Cortex-M (forever)/Cortex A (TI, Silabs, NXP), FPGA, Bare Metal Raspberry-PI programming
    VHDL-ALTERA-XILINX
      0  0

  17. #37
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    C'est pour cela que je mets "vrai temps réel" entre guillemets. Je connais la définition du temps réel mais elle ne me convient pas du tout. Je la trouve nulle et à ce compte n'importe quel OS est temps réel.
    http://en.wikipedia.org/wiki/Real-time_operating_system

    Wikipedia dit que tu as tord.
      0  3

  18. #38
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par Klaim Voir le message

    ce serait bien d'argumenter... parce qu'en l'état ta réponse n'a aucune valeur ajoutée

    au passage, Wikipedia ce n'est pas toujours la panacée
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog
      1  0

  19. #39
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    au passage, Wikipedia ce n'est pas toujours la panacée
    Voyons, voyons, soyons sérieux deux minutes, ce n'est pas comme si la notion de "temps réél" avait des définitions multiples et Wikipédia est une très bonne source pour les notions générales des domaines spécifiques. Rien de mieu que des gee...ahem "spécialistes" pour maintenir des pages purement techniques.

    D'après wikipédia (et le reste de l'industrie informatique, mais wikipédia est juste "une référence" de poids pour faire argument), on qualifie de temps réél les sytèmes qui ont une contrainte de temps fixe pour chaque "action" (pour parler vulgairement). Dans le lien que j'ai fournis, il est question d'OS qui sont effectivement "temps réél". Or on voit bien dans la liste que tous les OS ne sont pas considéré comme "temps réél", pour de bonnes raisons.

    Le fait est qu'il y a eu pendant longtemps une utilisation abusive tu terme "temps réél", notemment dans le domaine du jeu vidéo et de tout ce qui est est très réactif visuellement, et que du coup le terme est détourné pour parler d'applications qui réagissent "au doigt et à l'oeil". Or ce n'est pas forcément lié. Je suppose que monnoliv sous entendait cela, puisqu'il semble savoir ce qu'est le temps réél tel que définis en informatique, mais je voulais préciser que techniquement "pour moi tous les OS sont temps réél" le met en tord (même si encore une fois je comprends ce qu'il sous entends).

    Liens dispo dans le lien précédent : http://en.wikipedia.org/wiki/List_of...rating_systems

    ce serait bien d'argumenter... parce qu'en l'état ta réponse n'a aucune valeur ajoutée
    Evidemment, sans lire le lien référencé, c'est sur qu'il n'y a pas d'argument. L'argument est dans le lien.
      0  0

  20. #40
    Membre éprouvé
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    612
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2008
    Messages : 612
    Points : 1 050
    Points
    1 050
    Par défaut
    Salut
    -----

    Wikipédia est une très bonne source pour les notions générales des domaines spécifiques
    Attention quand même avec Wikipedia. Je me souviens d'une discussion animée sur RS485 en 2007 suite à laquelle un interlocuteur m'a renvoyé sur Wiki. Il se trouve qu'un chapitre entier était faux et soutenait la version de mon contradicteur, et donc je l'ai intégralement modifié (ce sont toujours mes phrases modifiées qui sont en ligne).

    Bref, Wiki me donnait tort et maintenant il me donne raison, puisque j'ai modifié en ce sens. Note que j'ai modifié uniquement après que les autres intervenants soient du même avis que moi, et après avoir reçu confirmation écrite de Texas Instrument concernant le point litigieux relatif à ses propres périphériques, qui confirmait mon point de vue.

    N'empêche, j'aurais pu écrire des choses inexactes juste "pour avoir raison", et donc, Wiki est très utile mais à manipuler avec précautions. J'ai déjà modifié plusieurs fois le contenu d'articles de Wiki, et, si j'y ai vu des erreurs c'est que forcément il doit y en avoir plein d'autres.

    Or on voit bien dans la liste que tous les OS ne sont pas considéré comme "temps réél", pour de bonnes raisons.
    Je suis d'accord.
    Il y a des OS non temps réel, des OS nativement temps réel, des OS non nativement temps réels mais patchés pour devenir temps réel, etc. Sans compter les différents modes de temps réel (dur ou mou).

    Bref, mon avis est qu'il est aussi faux de dire qu'il n'existe aucun OS temps réel que de dire que tous les sont. Ceci étant encore compliqué par la notion de temps réel elle-même par rapport à la notion de temps de réaction, du déterminisme qui en fait peut vouloir dire déterminisme logique ou temporel, et on en arrive à ne plus rien pouvoir généraliser et à devoir faire du cas par cas.

    Du reste, je n'aime pas les généralisations, c'est trop souvent beaucoup trop réducteur de réalités beaucoup plus vastes.

    Ceci étant dit, tu as compris la phrase de Monoliv de travers, puisqu'en fait il dit justement qu'on ne peut pas dire que tous les OS sont temps réel, ce qui est exact, malgré le fait que j'estime que le reste de son argumentation ne le soit pas, étant entendu que je n'ai pas envie de remettre le couvert en disant où et quoi.

    Bref, il a dit "

    à ce compte n'importe quel OS est temps réel.
    ce qui veut dire "SI" il acceptait la définition, ce qu'il ne fait justement pas.

    et non

    pour moi tous les OS sont temps réél

    Bref, je suis contre l'avis de Monoliv pour ce qui est de son argumentation, mais il ne faut pas non plus lui faire dire ce qu'il n'a pas dit

    A+
    Bigonoff
      1  0

Discussions similaires

  1. Réponses: 40
    Dernier message: 04/05/2014, 22h42
  2. Quel langage pour le développement embarqué ?
    Par freakydoz dans le forum Débats sur le développement - Le Best Of
    Réponses: 37
    Dernier message: 23/04/2007, 20h31
  3. Réponses: 3
    Dernier message: 07/12/2006, 12h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo