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

 C Discussion :

Nouveau projet : le C est-il pertinent ?


Sujet :

C

  1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 9
    Points : 1
    Points
    1
    Par défaut Nouveau projet : le C est-il pertinent ?
    Bonjour,

    Je commence un nouveau projet, et à ce stade, les questions qui me viennent sont : quel système, quel langage, quelles bibilothèques utiliser.

    Je ne suis pas sûr que ce soit le bon endroit pour poster, mais comme par défaut je comptais partir sur du C, je me suis dit autant prendre cette hypothèse et venir sur le forum associé. Dans le cas contraire, corrigez moi.

    J'en arrive donc à mon besoin :
    Je souhaite développer une application qui a les particularités suivante :
    - Il s'agit d'un programme présentant à la fois une partie "temps réel" et une autre "interface avec l'utilisateur (IHM)"
    - la partie "temps réel" échange, bien sûr un peu avec l'IHM, mais aussi avec des interfaces physiques, comme le port série. Je dis "temps réel" dans le sens où le programme devra, à intervalle régulier, prendre des informations sur le port série, puis faire des calculs, et renvoyer des informations avant que les nouvelles arrivent, et ce de manière garantie.
    - il faut donc pouvoir facilement et efficacement communiquer avec le port série
    - A terme la machine sera dédiée à cette application. C'est à dire que cela pourrait marcher sur un ancien système d'exploitation monotâche.
    - IHM assez standard, il faut une interface graphique, des interactions clavier/souris, mais attention ce n'est pas juste des boites de dialogues. Il y aura des éléments graphiques à faire évoluer.
    - La partie temps réelle devra également être capable de piloter la carte son au plus bas niveau (enfin si cela est possible sur un PC). Que ce soit en lecture ou en écriture. bas niveau c'est à dire que tous les Xms on envoie à la carte son les échantillons à appliquer sur la sortie son. il ne s'agit pas de jouer un fichier préenregistrer de de venir directement bidouiller le buffer de sortie de la carte son (est-ce possible ??)

    Donc avec ce cahier des charges je pensais partir sur du C, par exemple sous windows, et en étudiant plusieurs bibliothèques voir s'il est possible de faire ce que j'ai énuméré ci-dessus.

    Mais j'aimerais bien prendre un peu de recul, et si possible m'appuyer sur l'expérience d'autres personnes :
    - est-ce que le choix du C est pertinent ?
    - faut il privilégier un système d'exploitation plutôt qu'un autre?
    - est-ce possible, sur un processeur multicore, de dédier par exemple la partie temps réel à un core, et tout le reste à l'autre?
    - ne serait il pas plus simple de revenir à un ancien système monotâche où l'on accédait plus facilement au bas niveau et où un programme se déroule du début à la fin dans interruptions ?

    Je sais que c'est un peu vague ce que je demande et avec beaucoup de questions, merci d'avance à ceux qui prendront le temps de me lire !

  2. #2
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Bonjour,

    Oui, je pense que le C est un bon choix, tant en termes de versatilité que de choix de bibliothèques pour faire les tâches de plus haut niveau. Le C est même fait pour te permettre d'écrire un peu d'assembleur inline si tu te retrouves confronté à ce cas.

    Pour la carte son et autres, il faut savoir que ça se faisait beaucoup du temps du D.O.S., à l'époque où les machines étaient moins puissantes et les compilos moins évolués mais que, parallèlement, les architectures étaient plus simples, moins nombreuses, et que l'on fonctionnait entièrement en mono-tâche et en mode réel. Il était donc à la fois facile et justifié d'écrire des applications temps réel, directement liées au matériel et qui désactivaient même les interruptions pour au cycle près et de manière déterministe le temps d'exécution. C'est un savoir-faire qui se perd un peu aujourd'hui et c'est bien dommage.

    Apparemment, c'est le genre de configuration que tu envisages. Donc les choses te seront grandement facilitées. Cependant, le C reste le meilleur choix. Ou alors c'est tout en assembleur mais ça ne vaut pas le coup d'écrire l'application en entier.

    Pour la carte son, c'est tout-à-fait possible. La plus grande difficulté viendra de la nécessité de faire cohabiter cela avec ton système d'exploitation et plus celui-ci sera récent, plus ça risque d'être pénible.

  3. #3
    Membre éclairé
    Avatar de bpy1401
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2003
    Messages
    471
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Eure (Haute Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2003
    Messages : 471
    Points : 831
    Points
    831
    Par défaut
    Bonjour

    Je suis d'accord avec Obsidian, le C est bien adapté pour ce que tu souhaite faire. Ton application sera bien "temps réel", mefie toi de windows qui lui ne te certifie rien en terme de temps.

    Windows va aussi te poser des problèmes pour attaquer le bes niveau de la machine.

    Bon courage
    Page sur Developpez : http://pbriand.developpez.com

  4. #4
    Expert confirmé Avatar de fregolo52
    Homme Profil pro
    Développeur C
    Inscrit en
    Août 2004
    Messages
    2 364
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur C

    Informations forums :
    Inscription : Août 2004
    Messages : 2 364
    Points : 5 378
    Points
    5 378
    Par défaut
    Salut,

    Exemple d'un de mes anciens projets "temps réel" :
    - couche basse aplicative en C : multi-thread :
    * acquisition (flux multicast) (donc socket UDP)
    * traitement
    * communication des donnée (TCP/IP)

    - IHM C++ : communication avec la couche temps réel en TCP/IP

    Seul défaut : on n'a utilisé aucune lib multi-plateformes.

    Cahier des charges : la partie temps réel doit tourner sous Linux et l'IHM sous Windows.

    Cet architecture (comm TCP) nous a permis de faire une couche temps réel multi-plateforme (idéal pour faire des démo client avec une seul machine sous Windows).

  5. #5
    Nouveau Candidat au Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 9
    Points : 1
    Points
    1
    Par défaut
    Bonjour,

    Merci à tous pour vos infos très instructives !!
    Ca rejoint ce que j'avais commencé à me dire : les systèmes d'exploitation récents comme windows XP, Vista ne sont probablement pas adaptés.

    Pour information, à terme ce sera une unique machine qui fera tourner la partie temps réel et l'IHM, j'appelle d'ailleurs l'ensemble le "programme complet". Ensuite ce programme complet devra communiquer avec d'autres matériels par le port série.

    Il me semble donc logique de faire cela en C.

    Ceci-dit, tout n'est pas encore bien clair pour moi. Donc je poursuis dans mes questions :
    Si je prends l'hypothèse DOS :
    - est-ce qu'un DOS tournera sur un PC récent (car il me faut quand même une puissance de calcul), comme ca tournait sur nos anciens 486 ??
    - pour l'aspect graphique, il faudra globalement faire tout "à la main" ?? ce que je veux dire c'est qu'en programmation windows, pour tout ce qui est IHM, il y a toutes sortes de choses de fournies: en quelques clics on a des boutons, menus, on charge des images etc. Comment cela se passerait sous DOS ?

    Si on prend l'hypothèse LINUX:
    Désolé mais je connais pas grand chose. C'est multitâche non ? voulez vous dire que l'on peut facilement le configurer/l'utiliser pour faire du temps réel ? Est-ce qu'on parle d'une distribution particulière ou de n'importe quel linux ? Est-ce qu'on accèdera aux couches basses du PC de la même manière qu'on peut le faire sous DOS ?

    En fait, si je résume mes exigences comme cela :
    - accès facile et efficace aux ports de communication du PC
    - accès au matériel comme la carte son
    - possibilité de garantir le temps réel
    - possibilité de faire une IHM propre
    => DOS (v8?) ou LINUX (lequel ?)

    Merci encore pour votre implication!

  6. #6
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Citation Envoyé par Devebob Voir le message
    Pour information, à terme ce sera une unique machine qui fera tourner la partie temps réel et l'IHM, j'appelle d'ailleurs l'ensemble le "programme complet". Ensuite ce programme complet devra communiquer avec d'autres matériels par le port série. Il me semble donc logique de faire cela en C.

    Ceci-dit, tout n'est pas encore bien clair pour moi. Donc je poursuis dans mes questions :
    Si je prends l'hypothèse DOS :
    - est-ce qu'un DOS tournera sur un PC récent (car il me faut quand même une puissance de calcul), comme ca tournait sur nos anciens 486 ??
    Je suis tenté de dire « oui » mais la vérité est que c'est très difficile à affirmer. Ça fait longtemps que D.O.S. n'est plus entretenu. La prise en charge du 64 bits et des bus les plus récents risque donc d'être difficile. Gérer un port série, par contre, ça devrait toujours être trivial, sauf si tu tombes sur une machine vraiment bas de gamme qui émule logiciellement certains composants.

    - pour l'aspect graphique, il faudra globalement faire tout "à la main" ?? ce que je veux dire c'est qu'en programmation windows, pour tout ce qui est IHM, il y a toutes sortes de choses de fournies: en quelques clics on a des boutons, menus, on charge des images etc. Comment cela se passerait sous DOS ?
    Le plus simple est de rester en mode texte : c'est extrêmement rapide, et c'est facile à gérer, en plus d'être peu gourmand. Il ne s'agit pas de faire des lignes de commandes, mais typiquement des menus avec une barre défilante, comme ceci :

    Nom : FreeDOSMenu2.png
Affichages : 74
Taille : 10,3 Ko

    En plus c'est assez efficace et agréable d'utilisation du côté utilisateur. Il existe des bibliothèques toutes faites pour faire cela, mais je ne les connais plus.

    Si on prend l'hypothèse LINUX: Désolé mais je connais pas grand chose. C'est multitâche non ? voulez vous dire que l'on peut facilement le configurer/l'utiliser pour faire du temps réel ? Est-ce qu'on parle d'une distribution particulière ou de n'importe quel linux ? Est-ce qu'on accèdera aux couches basses du PC de la même manière qu'on peut le faire sous DOS ?

    En fait, si je résume mes exigences comme cela :
    - accès facile et efficace aux ports de communication du PC
    - accès au matériel comme la carte son
    - possibilité de garantir le temps réel
    - possibilité de faire une IHM propre
    => DOS (v8?) ou LINUX (lequel ?)

    Merci encore pour votre implication!
    Personnellement, c'est effectivement ce que je choisirais aujourd'hui également. Principalement parce que je travaille sous Linux toujours les jours bien sûr, mais également parce que tu auras beaucoup moins de contraintes à l'exploitation.

    D'abord parce que tu seras dégagé des éventuels problèmes de piratage et ensuite parce que tu es sûr que tu auras un système qui initialisera correctement les machines les plus récentes et qui te fournira d'emblée toutes les routines nécessaires pour faire ce qui prend du temps et qui ne concerne pas directement l'application métier. En plus, c'est un système particulièrement adapté à l'utilisation du C.

    Ensuite, parce que tu pourras toi-même réduire le système au minimum. Dans le cas extrême, tu pourrais presque remplacer init par ton application pour être sûr que rien d'autre ne tourne. Tu pourras en outre écrire beaucoup plus facilement tes propres pilotes si besoin, et éliminer les composants du kernel qui ne te servent pas.

    Cela dit, le port série est particulièrement lent comparé aux vitesses de traitement des machines modernes. Si ce que ta machine doit exploiter communique par ce biais, alors tu n'as pour ainsi dire pas besoin d'un système temps réel pour ce faire. Dans le cas le plus trivial, une machine dual core avec un thread pour gérer le port, un autre pour faire tout le reste (IHM, etc.) de façon asynchrone et via un segment de mémoire partagée, même si c'est du gâchis de ressources, devrait quand être même être ce qu'il y a de plus économique aujourd'hui tant en matériel qu'en coût de développement.

    SInon, pour rester sur une machine mono-cœur, la manière la plus normale de faire ce que tu veux faire est de donner une haute priorité aux interruptions en provenance du port série. Par contre, je ne sais pas par cœur comment on fait cela sous Linux. Il faudra que je remette le nez dans le manuel ! :-)

  7. #7
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Ce que tu décris ressemble plus à une application Linux embarquée sur une carte dédiée (avec effectivement la création d'une distribution Linux adaptée à tes besoins) qu'une application PC classique.

    Pour Linux en temps réel, il y a http://en.wikipedia.org/wiki/RTLinux (jamais essayé, je ne pourrais pas en dire plus)

    Il existe des bibliothèques toutes faites pour faire cela, mais je ne les connais plus.
    http://en.wikipedia.org/wiki/Ncurses

  8. #8
    Nouveau Candidat au Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 9
    Points : 1
    Points
    1
    Par défaut
    Merci encore pour vos réponses!

    Quelques commentaires :
    Citation Envoyé par Obsidian Voir le message
    Le plus simple est de rester en mode texte : c'est extrêmement rapide, et c'est facile à gérer, en plus d'être peu gourmand. Il ne s'agit pas de faire des lignes de commandes, mais typiquement des menus avec une barre défilante, comme ceci :
    Nom : FreeDOSMenu2.png
Affichages : 74
Taille : 10,3 Ko
    En plus c'est assez efficace et agréable d'utilisation du côté utilisateur. Il existe des bibliothèques toutes faites pour faire cela, mais je ne les connais plus.
    OK le mode texte est efficace, je vois bien le genre d'interface. Mais pour une appli que l'on souhaite vendre à un client, est-ce suffisament "sexy" ?
    Par ailleurs si on a un besoin de représenter graphiquement certaines choses, par exemple des cuves plus ou moins remplies, des vannes etc., il faut entièrement basculer sur un autre mode d'affichage ?
    J'ai par exemple en tête un nom de bibliothèque : Allegro (enfin je crois), qui doit être pour faire des jeux. Est-ce que je dois passer par quelque chose d'équivalent pour avoir des graphiques un peu "évolués"?

  9. #9
    Nouveau Candidat au Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 9
    Points : 1
    Points
    1
    Par défaut
    Citation Envoyé par Obsidian Voir le message

    Personnellement, c'est effectivement ce que je choisirais aujourd'hui également. Principalement parce que je travaille sous Linux toujours les jours bien sûr, mais également parce que tu auras beaucoup moins de contraintes à l'exploitation.

    D'abord parce que tu seras dégagé des éventuels problèmes de piratage et ensuite parce que tu es sûr que tu auras un système qui initialisera correctement les machines les plus récentes et qui te fournira d'emblée toutes les routines nécessaires pour faire ce qui prend du temps et qui ne concerne pas directement l'application métier. En plus, c'est un système particulièrement adapté à l'utilisation du C.

    Ensuite, parce que tu pourras toi-même réduire le système au minimum. Dans le cas extrême, tu pourrais presque remplacer init par ton application pour être sûr que rien d'autre ne tourne. Tu pourras en outre écrire beaucoup plus facilement tes propres pilotes si besoin, et éliminer les composants du kernel qui ne te servent pas.

    Cela dit, le port série est particulièrement lent comparé aux vitesses de traitement des machines modernes. Si ce que ta machine doit exploiter communique par ce biais, alors tu n'as pour ainsi dire pas besoin d'un système temps réel pour ce faire. Dans le cas le plus trivial, une machine dual core avec un thread pour gérer le port, un autre pour faire tout le reste (IHM, etc.) de façon asynchrone et via un segment de mémoire partagée, même si c'est du gâchis de ressources, devrait quand être même être ce qu'il y a de plus économique aujourd'hui tant en matériel qu'en coût de développement.

    SInon, pour rester sur une machine mono-cœur, la manière la plus normale de faire ce que tu veux faire est de donner une haute priorité aux interruptions en provenance du port série. Par contre, je ne sais pas par cœur comment on fait cela sous Linux. Il faudra que je remette le nez dans le manuel ! :-)
    Merci pour ces explications, et effectivement, je trouve cela pertinent.
    Mais est-ce envisageable de partir dans cette voie sans connaissances spécifiques de Linux? De quelle distribution/installation devrais-je partir pour répondre à mon besoin sans être submergé de choses dont je ne me servirai pas ?

  10. #10
    Nouveau Candidat au Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 9
    Points : 1
    Points
    1
    Par défaut
    Citation Envoyé par Bktero Voir le message
    Ce que tu décris ressemble plus à une application Linux embarquée sur une carte dédiée (avec effectivement la création d'une distribution Linux adaptée à tes besoins) qu'une application PC classique.

    Pour Linux en temps réel, il y a http://en.wikipedia.org/wiki/RTLinux (jamais essayé, je ne pourrais pas en dire plus)
    Merci pour l'info !
    Pour ma part (en tout cas pour le moment) je vise bien une application PC classique. Le coeur de mon projet, ou plutot sa valeur ajoutée, est dans le programme en lui-même, c'est à dire ce qu'il calcule (assez gros calculs) en fonction des échanges qu'il a avec l'utilisateur et avec d'autres appareils branchés sur ses ports de communication.
    Enfin je dis ça aujourd'hui mais tout peut encore évoluer!

  11. #11
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    - A terme la machine sera dédiée à cette application. C'est à dire que cela pourrait marcher sur un ancien système d'exploitation monotâche.
    C'est cette phrase qui m'a fait dire que ton application n'était pas une application "classique", mais une application embarquée, dans le sens où la plateforme devient dédiée à cette application. Après, une distribution Linux sur mesure peut tourner sur un x86, pas forcément besoin de passer sur des cartes spécialisées avec des processeurs ARM.

    Petite remarque : monotâche ? Tu ne veux pas faire de threads ? Genre un thread pour monitorer et traiter les données et les copier dans une zone partagée ; un thread qui va lire cette zone pour les afficher ; ....

    OK le mode texte est efficace, je vois bien le genre d'interface. Mais pour une appli que l'on souhaite vendre à un client, est-ce suffisamment "sexy" ?
    Par ailleurs si on a un besoin de représenter graphiquement certaines choses, par exemple des cuves plus ou moins remplies, des vannes etc., il faut entièrement basculer sur un autre mode d'affichage ?
    J'ai par exemple en tête un nom de bibliothèque : Allegro (enfin je crois), qui doit être pour faire des jeux. Est-ce que je dois passer par quelque chose d'équivalent pour avoir des graphiques un peu "évolués"?
    Regarde plutôt du côté de Qt. Allegro semble faite pour les jeux. Qt est plus vaste, s'embarque sur des plateformes à faible puissance si besoin, propose pléthore d'outils

  12. #12
    Nouveau Candidat au Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 9
    Points : 1
    Points
    1
    Par défaut
    Bonsoir,

    Citation Envoyé par Bktero Voir le message
    C'est cette phrase qui m'a fait dire que ton application n'était pas une application "classique", mais une application embarquée, dans le sens où la plateforme devient dédiée à cette application. Après, une distribution Linux sur mesure peut tourner sur un x86, pas forcément besoin de passer sur des cartes spécialisées avec des processeurs ARM.

    Petite remarque : monotâche ? Tu ne veux pas faire de threads ? Genre un thread pour monitorer et traiter les données et les copier dans une zone partagée ; un thread qui va lire cette zone pour les afficher ; ....
    Oui je voulais dire "ca pourrait presque être du monotâche", dans le sens où c'est le seul truc qui tourne sur la machine et toutes les tâches à calculer sont déterminées à l'avance, mais je suis d'accord, c'est plus approprié de faire plusieurs threads.
    Question bête : plusieurs threads => pas de DOS, non?


    Citation Envoyé par Bktero Voir le message
    Regarde plutôt du côté de Qt. Allegro semble faite pour les jeux. Qt est plus vaste, s'embarque sur des plateformes à faible puissance si besoin, propose pléthore d'outils
    Qt, c'est pas plutôt pour C++ ?

  13. #13
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Je ne comprends pas très bien pourquoi tu souhaites utiliser DOS.... Si j'en crois Wikipedia FR, la dernière version de MS-DOS date de 2000 donc tu auras probablement pas mal de soucis de support de matériels, sauf à tenter des variantes telles que FreeDOS. Tu auras aussi sûrement des problèmes de compatibilité logicielle puisqu'il est peu probable que les bibliothèques modernes possèdent un portage pour DOS. Enfin, DOS ne supporte pas le multitâche, ce qui veut dire pas de threads si je ne dis pas de bêtises.

    L'avenir de ce genre d'application, c'est Linux... Sorry bro

    Qt est un framework C++ effectivement. Si tu veux rester en C, je crois qu'il faudra te tourner vers GTK.

  14. #14
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Hello,

    Citation Envoyé par Bktero Voir le message
    Je ne comprends pas très bien pourquoi tu souhaites utiliser DOS.... Si j'en crois Wikipedia FR, la dernière version de MS-DOS date de 2000 donc tu auras probablement pas mal de soucis de support de matériels, sauf à tenter des variantes telles que FreeDOS. Tu auras aussi sûrement des problèmes de compatibilité logicielle puisqu'il est peu probable que les bibliothèques modernes possèdent un portage pour DOS. Enfin, DOS ne supporte pas le multitâche, ce qui veut dire pas de threads si je ne dis pas de bêtises.
    Non, aucune bêtise ! :-) Cela dit, on pouvait quand même faire des TSR (Terminate and Stay Résident) quand on voulait faire des bidouilles du style horloge permanente dans le coin de l'écran, et autres. C'était du bricolage, certes, mais qu'est-ce qu'on était bien tout seuls :-)

  15. #15
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Le seul souvenir que j'ai de DOS, c'est en lançant Windows 98. On n'est pas de la même génération, monsieur Obsidian

  16. #16
    Nouveau Candidat au Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 9
    Points : 1
    Points
    1
    Par défaut
    Oui Bktero, j'entend bien tes arguments, et je suis d'accord avec toi: tout cela va finir sous Linux. C'est juste que je pose les questions jusqu'au bout pour me faire un avis suffisamment complet.

    Maintenant, y'a plus qu'à commencer la pratique !
    Mais concrètement, si j'ai un PC sous la main, il faut que je commence par installer quoi, quelle distri ?
    (sous entendu : étant donné le genre de projet dont on parle ci-dessus)

  17. #17
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    As-tu déjà utilisé Linux ?

    La distribution classique, on va dire que c'est Ubuntu. Personnellement, je n'aime pas du tout le gestionnaire de bureau (ce qui donne l'apparence à l'interface utilisateur) Unity utilisé dans les dernières versions. Pour du développement brut, je prendrais Debian. J'entends aussi beaucoup de bien de Mint (?) ces derniers temps, que je compte essayer.

    Pour commencer, tu peux utiliser une VM (virtual machine) pour tester les distributions (l'allure visuelle au moins) (en lançant les ISO en live CD ou en les installant). Si tu as des accès au matériel à faire, tu devras l'installer sur une partition séparée probablement. La VM devrait bien faire l'affaire dans un premier temps en tout cas.

  18. #18
    Membre habitué
    Profil pro
    amateur
    Inscrit en
    Avril 2012
    Messages
    145
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : amateur
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Avril 2012
    Messages : 145
    Points : 144
    Points
    144
    Par défaut
    Citation Envoyé par Devebob Voir le message
    OK le mode texte est efficace, je vois bien le genre d'interface. Mais pour une appli que l'on souhaite vendre à un client, est-ce suffisament "sexy" ?
    Par ailleurs si on a un besoin de représenter graphiquement certaines choses, par exemple des cuves plus ou moins remplies, des vannes etc., il faut entièrement basculer sur un autre mode d'affichage ?
    J'ai par exemple en tête un nom de bibliothèque : Allegro (enfin je crois), qui doit être pour faire des jeux. Est-ce que je dois passer par quelque chose d'équivalent pour avoir des graphiques un peu "évolués"?
    Ah, apparemment ce que tu veux faire c'est de l'automatisme ! (C'est mon premier métier.)
    Je sais qu'il existe des bibliothèques dédiées pour le contrôle / la simulation / la visualisation de processus automatisé sur des PC. En gros, c'est un peu comme un GUI tout simple, avec des petits modules graphiques auquels tu associes des E/S. Les entrèes font évoluer la visu, les sorties des variables qui, typiquement, vont à travers ta boucle principale s'appliquer sur des sorties physiques (qui elles-même commandent uin circuit de puissance, genre pour faire varier la vitesse d'un moteur).

    Deux points:
    * Côté programmation, la logique de contrôle/commande est en général triviale (en comparaison d'applis ordinaires). C'est du très bas niveau, logique en if sur des bits ou nombres entiers, mais simplissime. Donc, c'est tout le reste qui pose problème, notamment la visu et la communication avec entrèes/sorties physiques.
    * Au cas où tu le saurais pas, il existe des appareils dédiés, "automates industriels" ("PC" en anglais! "programmable controller"). Ca vaut peut-être le coup de jeter un oeil, je n'ai aucune idée du prix (je bossais chez Siemens, je les achetais pas ). Ce genre d'appareil a les entrées-sorties qu'il faut (et rien de plus, c'est modulaire) ; et un langage adapté (super simple à l'époque).

    Denis

  19. #19
    Nouveau Candidat au Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 9
    Points : 1
    Points
    1
    Par défaut
    Citation Envoyé par Bktero Voir le message
    As-tu déjà utilisé Linux ?

    La distribution classique, on va dire que c'est Ubuntu. Personnellement, je n'aime pas du tout le gestionnaire de bureau (ce qui donne l'apparence à l'interface utilisateur) Unity utilisé dans les dernières versions. Pour du développement brut, je prendrais Debian. J'entends aussi beaucoup de bien de Mint (?) ces derniers temps, que je compte essayer.

    Pour commencer, tu peux utiliser une VM (virtual machine) pour tester les distributions (l'allure visuelle au moins) (en lançant les ISO en live CD ou en les installant). Si tu as des accès au matériel à faire, tu devras l'installer sur une partition séparée probablement. La VM devrait bien faire l'affaire dans un premier temps en tout cas.
    Oui j'avais déjà essayé des live CD, mais sans l'utiliser plus que cela. Et c'est un peu pour ca que je posais cette question : s'il y a clairement une distrib à privilégier pour ce genre de projet, autant que je la prenne directement . Mais je pense que sur le fond ca ne change pas grand chose. J'ai l'impression que tu vas dans ce sens.

  20. #20
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Oui

    Utilise une distribution où tu te sens à l'aise, c'est le principal.

Discussions similaires

  1. Réponses: 1
    Dernier message: 20/02/2006, 14h04
  2. [MFC]creation nouveau projet
    Par tus01 dans le forum MFC
    Réponses: 10
    Dernier message: 05/01/2006, 17h37
  3. [Info]workspace/projet ==> chemin relatif est-ce possible
    Par eclipseboy993 dans le forum Eclipse Java
    Réponses: 1
    Dernier message: 02/08/2005, 14h47
  4. [J2EE]importation d'un war pour un nouveau projet
    Par gibson83 dans le forum Eclipse Java
    Réponses: 3
    Dernier message: 14/02/2005, 13h58
  5. [Création nouveau projet] - Référencer un autre projet
    Par TexAvery dans le forum Eclipse Java
    Réponses: 5
    Dernier message: 17/08/2004, 13h55

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