XII. Étude de cas n° 2 : driver RTDM Fiji-Oslink▲
XII-A. Ressources utiles▲
Le site de Captain Universe contient des exemples de drivers RTDM : http://www.captain.at/xenomai.php.
L'exemple discuté dans ce chapitre est intéressant car il est très simple (pas de gestion d'interruption).
XII-B. Fonctionnalités▲
La sonde Fiji se connecte sur un port parallèle, elle implémente le protocole bidirectionnel Oslink.
La réception des données se fait par polling car la ligne habituellement utilisée pour lever une interruption (ACK) est utilisée comme ligne d'entrée de données.
XII-C. Anatomie d'un driver RTDM▲
Un driver RTDM peut être divisé en deux parties : une partie fonctionnelle qui est identique dans un driver Linux « classique », et une partie interfaçage avec Xenomai. C'est ce second point qui est développé ici.
XII-C-1. Comment interfacer un driver RTDM : la structure rtdm_device▲
Cette structure contient les informations propres au driver, comme par exemple :
- la version ;
- le nom du périphérique dans l'arborescence Xenomai ;
- la correspondance entre les opérations standard proposées par le driver et l'implémentation interne.
Le comportement des opérations open , close... des drivers RTDM est configurable selon le contexte d'appel (RT ou non).
Cette configuration utilise les champs *_rt ou *_nrt de la structure rtdm_driver.
Les fonctions RT et non RT peuvent être identiques. La discrimination peut être faîte à l'intérieur de la fonction grâce à rtdm_in_rt_context() qui renvoie un booléen .
Dans un driver, l'appel de fonctions depuis un mauvais contexte peut conduire au crash du système.
XII-C-2. Où mémoriser l'état d'un périphérique ouvert : le contexte▲
Plutôt qu'utiliser des variables globales pour stocker l'état du périphérique (vitesse, état de la ligne, parité...), les drivers RTDM utilisent la notion de contexte. Ce contexte est accessible depuis toutes les fonctions du driver puisque c'est leur premier paramètre (struct rtdm_dev_context*).
Une partie de cette structure (le champ dev_private) est réservée au développeur, qui peut y placer les données spécifiques à l'équipement (vitesse, parité...).
XII-C-3. Comment accéder à des zones de mémoire partagée avec les applications ?▲
Cela concerne les paramètres de type buffer lors des read, write et autres ioctl.
La zone de mémoire que l'on va trouver dans le driver peut être visible depuis le reste de l'application, des tâches peuvent alors potentiellement y accéder.
La solution consiste à sécuriser ces données en les copiant à l'intérieur du driver, les opérations rtdm_copy_from_user et rtdm_copy_to_user sont là pour ça.
 |
Que cela soit en lecture ou en écriture, l'accès doit auparavant toujours être testé avec les fonctions rtdm_rw_user_ok() et rtdm_read_user_ok(). |
XII-C-4. Comment partager du code en fonction du contexte d'appel ?▲
La fonction rtdm_in_rt_context renvoie un booléen(39) valant vrai si l'appel à la fonction est réalisé depuis une tâche Xenomai.
XII-D. Installation et désinstallation▲
Comme pour les drivers Linux classiques, on utilise les fonctions module_init et module_exit.
L'arborescence des drivers Xenomai est mise à jour dans ces fonctions par rtdm_dev_register et rtdm_dev_unregister.