Discussion :

[Devebob]

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 !

[Obsidian]

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.

[bpy1401]

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

[fregolo52]

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).

[Devebob]

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!

[Obsidian]

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 :



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 ! :-)