[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gulliver] Python et la gestion des signaux


From Patrick Lamaizière <patgul+gul at davenulle dot org>
Subject Re: [gulliver] Python et la gestion des signaux
Date Thu, 10 Apr 2008 19:24:50 +0200

Le Wed, 09 Apr 2008 22:03:07 +0200,
plaunay1 <pierre dot launay at ac-rennes dot fr> a écrit :

> > Tu peux peut être faire un select() ? J'ai jamais utilisé les ports
> > séries sous *nix.
> > 
> >> Peut-on gérer un signal asynchrone ? comme une interruption IRQ 
> >> (masquable ou non masquable) sur microcontrôleur et en python.
> > 
> > Je dirais que non. Déjà dans un gestionnaire de signal UNIX(tm) tu
> > ne peux utiliser qu'une poignée de fonctions et pas faire
> > d'allocation mémoire. Alors avec un langage interprété ça risque de
> > pas le faire. 
> > 
> > Ceci dit il doit y avoir des libs qui font le lien avec Python, ou
> > il est possible de linker du C.
> 
> J'ai essayé select() mais
> Sur google :Résultats 1 - 10 sur un total d'environ 953 000 000 pour 
> select() (0,17 secondes)
> Faut combien de temps pour tous les regarder ?

Ben la page de man. Les appels systèmes ont normalement une page de
manuel.

> Concrètement je voudrais créer un évènenement (event) pour une
> interface python graphique à partir de cette interruption.
> 
> Mais aussi un joli dessin
> http://www.linux.it/~rubini/docs/serial/serial.html
> Data flow in reading and writing

Tu n'as pas accès à cet interruption. Ça se passe au niveau du noyau.

Bon. Brievement sous UNIX l'abstraction de base est le fichier. Tu
accèdes aux périphériques via leur "device node" (/dev/quelquechose)
Après ça s'utilise comme un fichier avec les primitives read ou write
pour lire ou écrite dedans. 

L'appel ioctl() permet de "faire des choses" sur le périphérique, là
faut voir la doc parce que c'est différent suivant le type du
périphérique ou du fichier et assez peu portable en plus.

Après tu as deux sortes d'entrées sorties : les IO bloquantes et les IO
non bloquantes (ou asynchrones). Si une IO est bloquante, l'appel
système (par exemple read()) bloque tant qu'il n'y a rien à lire. En non
bloquant, l'appel système renvoie aussitôt.

Quand un appel système bloque, le processus (enfin le thread)
s'endort et ne consomme pas de CPU. Il est arrêté. Quand des
données sont disponibles, le noyau réveille le processus et l'appel rend
la main.

Select() permet de surveiller plusieurs fichiers et de savoir si on
peut lire, écrire, ou si une erreur est survenue. Il bloque et rend la
main quand une opération est possible sur un des fichiers. Avec des
entrées sorties asynchrones ça évite de pooler comme un cochon.

Voilà. Donc en gros pour ton problème je ferais un thread qui fait un
select() sur le device du port série, et qui génére ensuite un évenement
pour ton programme graphique : ça peut être une fonction callback, ou
un message je sais pas trop comment marche python à ce niveau.
 
 
> Je rame à 75 bauds, recherche idée, piste ... pour avancer à 1200
> bauds (comme le minitel) avant d'atteindre le 115kbauds de
> l'USB/série 

Tu as le serial programming howto (je sais pas si c'est à jour)
http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html

La méthode avec select() est l'exemple "3.4. Waiting for Input from
Multiple Source". 

Dans l'exemple "3.3. Asynchronous Input" il y a 3 bugs, ami lecteur les
trouveras tu ?