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

Re: [gulliver] Python et la gestion des signaux


From plaunay1 <pierre dot launay at ac-rennes dot fr>
Subject Re: [gulliver] Python et la gestion des signaux
Date Sat, 12 Apr 2008 23:39:29 +0200

Patrick Lamaizière a écrit :
Le Thu, 10 Apr 2008 19:24:50 +0200,
Patrick Lamaizière <patgul+gul at davenulle dot org> a écrit :

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

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

Y'en a même 4 en fait :


while (STOP==FALSE) {
printf(".\n");usleep(100000);
/* after receiving SIGIO, wait_flag = FALSE, input is
available and can be read */
if (wait_flag==FALSE) { res = read(fd,buf,255);
buf[res]=0;
printf(":%s:%d\n", buf, res);
if (res==1) STOP=TRUE; /* stop loop if only a CR was input */
wait_flag = TRUE; /* wait for new input */ }
}


Le premier c'est un débordement de buf si read() lit 255
caractères, buf[255] n'a alors pas la place pour buf[res]=0.
OK, mais tu chipotes
Le second c'est que "by design" ça ne marche pas.
C'est quoi "by design" "par dessin ???"
 Le gestionnaire de
signal met un drapeau à FALSE, mais il y a toujours une fenêtre de temps
entre le moment où il est testé dans le programme principal et le
moment où il est remis à true par celui ci. Si dans cette fenêtre de
temps un signal SIGIO est reçu il n'est pas pris en compte.

Je commence en C sur PC, je travaille en C sur microcontroleur uniquement.
Mais j'ai l'impression que la réception passe d'abord par
void signal_handler_IO (int status)
{
printf("received SIGIO signal.\n");
wait_flag = FALSE;
}
Sur les microcontroleurs on peut bloquer le traitement d'une nouvelle interruption tant qu'une interruption est en cours de traitement, mais cela se traite dans la partie des interruptions que l'on ne voit pas ici.
Le troisième c'est que printf() n'est pas autorisé dans un gestionnaire
de signal. La liste des fonctions "saines" est donnée dans man
sigaction

Pas en français
$ man sigaction|grep printf
Remise en forme de sigaction(2), attendez SVP...
$
(si je remplace printf par signal j'ai plein de lignes
J'ai essayé aussi /printf dans le man sans succès

Enfin errno n'est pas sauvegardée dans le gestionnaire. printf n'a pas
l'air de changer errno mais c'est une bonne pratique de le faire. Ça
permet d'éviter des nervous breakdown comme on dit de nos jours.
C'est encore quoi tes nervous breakdown (tension de claquage des nerfs ?, en électronique je l'utilise pour les diodes uniquement)

Cet exemple ne me correspond pas vraiment car il est en "canonique"
http://www.docmirror.net/fr/linux/howto/programming/Serial-Programming-HOWTO/Serial-Programming-HOWTO.html#toc2.3

On utilisera systématiquement le non-canonique.
Pour info avec la liaison série et les microcontrôleurs on travaille en "brut" ou binaire, on envoie pas des caractères mais des octets (bytes), ça prend moins de place et moins de traitement et surtout moins de temps que l'ascii, pour une liaison déjà trop lente.
C'est vrai pour Liberlab mais aussi plein de petits robots, que les logiciels soient français , espagnol ou anglais.
Si le logiciel coté microcontroleur envoie en "binaire" pas "ascii", il le reçoit ainsi coté PC.


Pierre



---- Liste gulliver ---- Archives, http://gulliver.eu.org/ml-archives/ Description, http://gulliver.eu.org/ml/ml.html Bons usages, http://gulliver.eu.org/wiki/UsagesCourriels