Discussion :

[jobe]

Bonjour,

Je doit développé une application pour linux permettent de gérrer des procesus temps réel de bas niveau et qui est commandé par une interface graphique.

J'ai plusieurs composant matérielle à gérrer et je doit donc écrire une partie de mon application dans l'espace noyau afin d'accéder au entrée sortie de mon processeur. Ma question est de savoir si il est plus simple et surtout plus performant (d'un point de vue de la latence) de regroupé les "drivers" de tous ces composants dans un seul module qui s'occupe de tous gérrer la partie bas niveau de façon temps réel ou si il faut crée un module pour chaque composant dans le vrai sens du mots driver puis de crée un module qui s'occupe de interraction entre ces drivers ?

Ma deuxième question est de savoir quel sont les moyens les plus simple et les plus performant (toujours d'un point de vue de la latence) pour assurer la communication entre l'application de commande (espace utilisateur) et le ou les modules (espace noyau) ?

Toutes pistes de réponse ou de documentation pouvant me permettre de m'informer un peut plus me sera très utile...

Merci Jobe

[gandalfar]

Moi je te conseil de faire un module pour chacun des devices c'est beaucoup plus propre.

Au niveau de la communication userland kernelland fait ca a l aide de l api driver du kernel: par exemple pour les devices en mode charactere tu pourra avoir un write un read un open un close un ioctl un poll etc...

Fait tes drivers génériques et après contrôle le tout en userland c'est pas gourmand en perf et c 'est plus propre. C'est en tout cas ce que je fait a chaque fois que je bosse sur de l'embarqué.

documentation : Linux Device Driver 3 il est en pdf gratuit sur le web.

[jobe]

oui on est d'accord que c'est plus propre et plus protégé mais en sachant que toute la boucle doit gérrer un système en temps réel ou la latence est réellement critique est ce une bonne idée ?

De plus si j'applique ce modèle par quel moyen je peut faire communiquer le programme de gestion des drivers (superviseur) et l'application qui s'occupe de l'interface utilisateur ?

MErci

Jobe

[gandalfar]

oui on est d'accord que c'est plus propre et plus protégé mais en sachant que toute la boucle doit gérrer un système en temps réel ou la latence est réellement critique est ce une bonne idée ?

Oui car ca ne changera rien niveau perf tout tes bouts de code s executerons dans des process different et ce generons pas les uns les autres. de toute facon linux est pas preremptif, donc n'est pas temps reel. Si tu veux du vrai temps reel faut te tourner vers tu rtlinux ou du rtos.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
De plus si j'applique ce modèle par quel moyen je peut faire communiquer le programme de gestion des drivers (superviseur) et l'application qui s'occupe de l'interface utilisateur ?

bin un exemple bete si tu a une led tu peux fait un chardev dans par exemple /dev/led et la controler a l aide d ioctl...etc

[gandalfar]

oui on est d'accord que c'est plus propre et plus protégé mais en sachant que toute la boucle doit gérrer un système en temps réel ou la latence est réellement critique est ce une bonne idée ?

Oui car ca ne changera rien niveau perf tout tes bouts de code s executerons dans des process different et ce generons pas les uns les autres. de toute facon linux est pas preremptif, donc n'est pas temps reel. Si tu veux du vrai temps reel faut te tourner vers du rtlinux ou du rtos.

De plus si j'applique ce modèle par quel moyen je peut faire communiquer le programme de gestion des drivers (superviseur) et l'application qui s'occupe de l'interface utilisateur ?

bin un exemple bete si tu a une led tu peux fait un chardev dans par exemple /dev/led et la controler a l aide d ioctl...etc

[jobe]

Oui car ca ne changera rien niveau perf tout tes bouts de code s executerons dans des process different et ce generons pas les uns les autres. de toute facon linux est pas preremptif, donc n'est pas temps reel. Si tu veux du vrai temps reel faut te tourner vers du rtlinux ou du rtos.

Je ne suis pas d'accord avec toi la transition espace utilisateur vers espace noyau est très couteuse en temps (appel système). Et oui j'utilise un applicatif temps réel: Xenomai

Le chardev va fonctionné seulement entre un drivers et une application si j'ai deux application qui doivent communiquer ensemble je vois pas trop par quoi passé à moins d'utiliser un IPC ?!?