{"id":3529,"date":"2013-04-15T08:00:44","date_gmt":"2013-04-15T07:00:44","guid":{"rendered":"http:\/\/www.blaess.fr\/christophe\/?p=3529"},"modified":"2013-04-12T14:26:10","modified_gmt":"2013-04-12T13:26:10","slug":"attentes-passives-sur-gpio","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2013\/04\/15\/attentes-passives-sur-gpio\/","title":{"rendered":"Attentes passives sur GPIO"},"content":{"rendered":"

\"GPIO<\/a>Nous avons d\u00e9j\u00e0 vu dans plusieurs articles qu’il \u00e9tait facile de manipuler les GPIO<\/a> sous Linux depuis l’espace utilisateur avec l’interface \/sys<\/code>. Jusqu’\u00e0 pr\u00e9sent je ne m’\u00e9tais int\u00e9ress\u00e9 qu’aux lectures et \u00e9critures, mais il est \u00e9galement possible de faire des attentes passives de changement d’\u00e9tat avec select()<\/code><\/strong> ou poll()<\/code><\/strong>. Voyons-en une mise en \u0153uvre sur le Raspberry Pi.<\/p>\n

\n\n<\/p>\n

Il est facile de faire une attente de changement d’\u00e9tat en \u00e9crivant un petit driver dans le kernel qui s’accrochera \u00e0 l’interruption d\u00e9clench\u00e9e par la broche GPIO. Nous l’avons m\u00eame r\u00e9alis\u00e9 avec un driver RTDM pour Xenomai<\/a>. Toutefois ceci pose un probl\u00e8me de portabilit\u00e9, car le code n’est pas directement r\u00e9utilisable sur une autre architecture (bien qu’il n’y ait pas beaucoup de variations). En outre cela impose un d\u00e9veloppement en mode noyau, n\u00e9cessitant donc des privil\u00e8ges d’administration et augmentant surtout le risque de crash syst\u00e8me en cas d’erreur.<\/p>\n

C’est pour simplifier ces acc\u00e8s que le noyau propose une interface passant par le syst\u00e8me de fichiers virtuels \/sys<\/code>. On peut tr\u00e8s bien r\u00e9aliser des op\u00e9rations sur les GPIO de mani\u00e8re plus efficace en employant par exemple mmap()<\/code> pour acc\u00e9der \u00e0 une projection en m\u00e9moire virtuelle des ports d’entr\u00e9e-sortie. N\u00e9anmoins ceci pose de gros probl\u00e8mes de portabilit\u00e9 et d’\u00e9volutivit\u00e9 des applications. Je pr\u00e9f\u00e8re donc, autant que possible, me contenter des acc\u00e8s via \/sys<\/code>.<\/p>\n

Dans de nombreux cas d’application, il est important d’attendre passivement le changement d’\u00e9tat d’une broche (bouton, signal externe, capteur, etc.) en \u00e9vitant absolument toute m\u00e9thode de polling<\/em> (scrutation en boucle p\u00e9riodique de l’\u00e9tat de l’entr\u00e9e). Si la broche GPIO concern\u00e9e est \u00e9ligible pour le d\u00e9clenchement d’une interruption, Linux nous permet d’utiliser l’appel-syst\u00e8me select()<\/code> ou l’appel poll()<\/code> pour attendre un \u00e9v\u00e9nement (un changement d’\u00e9tat qui se mat\u00e9rialisera par une interruption) sans consommer de CPU pendant la dur\u00e9e de l’attente.<\/p>\n

Test avec select()<\/h1>\n

Voici un petit programme qui ouvre le fichier qu’on lui indique en argument, puis il attend l’arriv\u00e9e d’un \u00ab\u00a0\u00e9v\u00e9nement exceptionnel\u00a0\u00bb sur le descripteur. Ces \u00ab\u00a0\u00e9v\u00e9nements exceptionnels\u00a0\u00bb trait\u00e9s par select()<\/code> d\u00e9pendent du type de descripteur de fichier. Pour une socket TCP par exemple, il peut s’agir de trames urgentes. Pour un descripteur d’\u00e9tat de GPIO dans sysfs<\/em>, il s’agit d’un changement de niveau ayant d\u00e9clench\u00e9 une interruption.<\/p>\n

Lorsqu’il est r\u00e9veill\u00e9 par un changement d’\u00e9tat, notre programme lit alors la valeur sur la broche et l’affiche pr\u00e9c\u00e9d\u00e9e de l’heure avant de se rendormir en attente du prochain r\u00e9veil.<\/p>\n

gpio-select.c:<\/a><\/strong>\n#include <fcntl.h>\n#include <stdio.h>\n#include <stdlib.h>\n#include <unistd.h>\n#include <sys\/select.h>\n\nint main(int argc, char * argv[])\n{\n    int fd;\n    fd_set fds;\n    struct timeval tv;\n    char buffer[2];\n\n    \/\/ On attend en argument un fichier \"value\" de GPIO.\n    \/\/ Par exemple : \/sys\/class\/gpio\/gpio23\/value\n    if (argc != 2) {\n        fprintf(stderr, \"usage: %s \\n\", argv[0]);\n        exit(EXIT_FAILURE);\n    }\n    \/\/ Ouvrir le fichier\n    if ((fd = open(argv[1], O_RDONLY)) < 0) {\n        perror(argv[1]);\n        exit(EXIT_FAILURE);\n    }\n\n    while (1) {\n        \/\/ Preparer la table des evenements exceptionnels attendus\n        FD_ZERO(& fds);\n        \/\/ Avec uniquement le descripteur du fichier.\n        FD_SET(fd, & fds);\n        \/\/ Attente passive (pas de timeout, donc infinie...\n        if (select(fd+1, NULL, NULL, & fds, NULL) < 0) {\n            perror(\"select\");\n            break;\n        }\n        \/\/ Lire l'heure du changement d'etat.\n        gettimeofday(& tv, NULL);\n        \/\/ Revenir au debut du fichier (lectures successives).\n        lseek(fd, 0, SEEK_SET);\n        \/\/ Lire la valeur actuelle du GPIO.\n        if (read(fd, & buffer, 2) != 2) {\n            perror(\"read\");\n            break;\n        }\n        \/\/ Effacer le retour-chariot.\n        buffer[1] = '\\0';\n        \/\/ Afficher l'heure et l'etat.\n        fprintf(stdout, \"[%ld.%06ld]: %s\\n\", tv.tv_sec, tv.tv_usec, buffer);\n    }\n    close(fd);\n    return EXIT_SUCCESS;\n}<\/pre>\n
Essayons notre programme sur un Raspberry Pi auquel j’ai connect\u00e9 un petit oscillateur \u00e0 4Hz sur la broche 16 du port d’extension. Ceci correspond au GPIO 23<\/a>. Commen\u00e7ons donc par demander au kernel de nous offrir l’acc\u00e8s \u00e0 ce GPIO depuis sysfs<\/em>.<\/p>\n
R-Pi login: root<\/strong>\nPassword:\nroot@R-Pi [\/root]# cd \/sys\/class\/gpio\/<\/strong>\nroot@R-Pi [gpio]# ls<\/strong>\nexport     gpiochip0  unexport\nroot@R-Pi [gpio]# echo 23 > export<\/strong>\nroot@R-Pi [gpio]# ls<\/strong>\nexport     gpio23     gpiochip0  unexport\nroot@R-Pi [gpio]# cd gpio23\/<\/strong>\nroot@R-Pi [gpio23]# ls<\/strong>\nactive_low  direction   edge        subsystem   uevent      value\nroot@R-Pi [gpio23]#<\/pre>\n
Essayons notre programme…<\/p>\n
root@R-Pi [gpio23]# \/root\/gpio-select .\/value<\/strong>\n[47.742961]: 0\n   (rien ne se passe...)\n^C<\/strong>\nroot@R-Pi [gpio23]#<\/pre>\n
Avant de conclure que notre programme est erron\u00e9, v\u00e9rifions sur quels types de fronts (montants ou descendants) du signal l’interruption est-elle d\u00e9clench\u00e9e.<\/p>\n
root@R-Pi [gpio23]# cat edge<\/strong>\nnone\nroot@R-Pi [gpio23]#<\/pre>\n
Voici donc l’explication. Par d\u00e9faut aucune interruption n’est produite par les changements d’\u00e9tat sur les broches GPIO (heureusement, car avec les variations permanentes de tension se produisant sur les broches laiss\u00e9es libres, il y aurait des interruptions sans cesse, ce qui consomme du CPU). Configurons donc notre GPIO pour qu’il nous r\u00e9veille sur les fronts montants.<\/p>\n
root@R-Pi [gpio23]# echo rising > edge<\/strong>\nroot@R-Pi [gpio23]# \/root\/gpio-select .\/value<\/strong>\n[98.887860]: 1\n[99.137953]: 1\n[99.388067]: 1\n[99.638183]: 1\n[99.888280]: 1\n[100.138399]: 1\n[100.388500]: 1\n[100.638604]: 1\n[100.888726]: 1\n[101.138819]: 1\n[101.388940]: 1\n[101.639035]: 1\n[101.889145]: 1\n[102.139269]: 1\n[102.389365]: 1\n[102.639479]: 1\n[102.889577]: 1\n[103.139686]: 1\n[103.389810]: 1\n[103.639901]: 1\n^C<\/strong>\nroot@R-Pi [gpio23]#<\/pre>\n
Tr\u00e8s bien. Les \u00e9carts entre les d\u00e9clenchements sont bien de 250ms (soit 4Hz), et les valeurs lues sont toujours \u00e0 1<\/code> car le signal chaque fois de monter pour atteindre +3.3V. Essayons de d\u00e9tecter les fronts descendants…<\/p>\n
root@R-Pi [gpio23]# echo falling > edge<\/strong>\nroot@R-Pi [gpio23]# \/root\/gpio-select .\/value<\/strong>\n[133.285615]: 0\n[133.527846]: 0\n[133.777937]: 0\n[134.028055]: 0\n[134.278160]: 0\n[134.528262]: 0\n[134.778380]: 0\n[135.028480]: 0\n[135.278598]: 0\n[135.528694]: 0\n[135.778802]: 0\n[136.028923]: 0\n[136.279026]: 0\n[136.529134]: 0\n[136.779234]: 0\n[137.029345]: 0\n[137.279467]: 0\n[137.529560]: 0\n^C<\/strong>\nroot@R-Pi [gpio23]#<\/pre>\n
Tout \u00e0 fait logiquement, ce sont maintenant des valeurs \u00e0 0<\/code> qui sont toujours lues car le signal d’entr\u00e9e vient donc de descendre pour d\u00e9clencher l’interruption.<\/p>\n
Essayons de d\u00e9tecter simultan\u00e9ment les deux types de fronts.<\/p>\n
root@R-Pi [gpio23]# echo both > edge<\/strong>\nroot@R-Pi [gpio23]# \/root\/gpio-select .\/value<\/strong>\n[151.806837]: 0\n[151.910795]: 1\n[152.035833]: 0\n[152.160890]: 1\n[152.285962]: 0\n[152.411002]: 1\n[152.536047]: 0\n[152.661102]: 1\n[152.786164]: 0\n[152.911212]: 1\n[153.036265]: 0\n[153.161328]: 1\n[153.286373]: 0\n[153.411429]: 1\n[153.536494]: 0\n[153.661542]: 1\n[153.786587]: 0\n[153.911645]: 1\n[154.036705]: 0\n[154.161756]: 1\n[154.286890]: 0\n^C<\/strong>\nroot@R-Pi [gpio23]#<\/pre>\n
Cela fonctionne \u00e9galement, les valeurs lues sont alors alternativement 0<\/code> et 1<\/code> et les d\u00e9clenchements sont espac\u00e9s de 125ms.<\/p>\n
Et poll() ?<\/h1>\n
L’appel-syst\u00e8me poll()<\/code> est mal nomm\u00e9. Il n’assure pas un polling<\/em> tel qu’on peut l’entendre en programmation micro-contr\u00f4leur par exemple o\u00f9 l’on vient examiner l’\u00e9tat d’une entr\u00e9e en boucle pour d\u00e9tecter ses variations. Sous Linux, poll()<\/code> fonctionne de la m\u00eame mani\u00e8re que select()<\/code> en endormant passivement la t\u00e2che appelante jusqu’\u00e0 ce qu’une interruption signale un \u00e9v\u00e9nement susceptible d’int\u00e9resser le demandeur.<\/p>\n
Voici l’impl\u00e9mentation du m\u00eame programme en employant poll()<\/code> plut\u00f4t que select()<\/code>.<\/p>\n
gpio-poll.c:<\/a><\/strong>\n#include <fcntl.h>\n#include <poll.h>\n#include <stdio.h>\n#include <stdlib.h>\n#include <unistd.h>\n\nint main(int argc, char * argv[])\n{\n    int fd;\n    struct pollfd  fds;\n    struct timeval tv;\n    char buffer[2];\n\n    if (argc != 2) {\n        fprintf(stderr, \"usage: %s \\n\", argv[0]);\n        exit(EXIT_FAILURE);\n    }\n    if ((fd = open(argv[1], O_RDONLY)) < 0) {\n        perror(argv[1]);\n        exit(EXIT_FAILURE);\n    }\n    while (1) {\n        fds.fd = fd;\n        fds.events = POLLPRI;\n        if (poll(& fds, 1, -1) < 0) {\n            perror(\"poll\");\n            break;\n        }\n        gettimeofday(& tv, NULL);\n        lseek(fd, 0, SEEK_SET);\n        if (read(fd, & buffer, 2) != 2) {\n            perror(\"read\");\n            break;\n        }\n        buffer[1] = '\\0';\n        fprintf(stdout, \"[%ld.%06ld]: %s\\n\", tv.tv_sec, tv.tv_usec, buffer);\n    }\n    close(fd);\n    return EXIT_SUCCESS;\n}<\/pre>\n
Les r\u00e9sultats d’ex\u00e9cution sont exactement les m\u00eames que ceux du pr\u00e9c\u00e9dent programme.<\/p>\n
Conclusion<\/h1>\n
L’attente passive de changement d’\u00e9tat sur un GPIO est une op\u00e9ration tr\u00e8s utile dans de nombreuses applications o\u00f9 une entr\u00e9e signale un \u00e9v\u00e9nement (alarme, acquisition d’un capteur, pression sur un bouton, etc.). L’interface sysfs<\/em> de Linux nous permet d’y acc\u00e9der de mani\u00e8re simple et portable, m\u00eame si le temps de prise en charge est un peu plus long que depuis un driver dans le kernel.<\/p>\n
Notez que mes exemples ci-dessus sont \u00e9crits en C, du fait de ma familiarit\u00e9 avec ce langage, mais qu’ils pourraient parfaitement fonctionner dans d’autres langages. Si vous avez envie de les r\u00e9\u00e9crire, par exemple en Python, n’h\u00e9sitez pas \u00e0 m’en faire part, j’en mettrai volontiers une copie ici.<\/p>\n
PS : je tiens \u00e0 remercier la personne d’Hydequip dont je n’ai pas not\u00e9 le nom et avec qui j’ai parl\u00e9 de ce th\u00e8me il y a quelques semaines lors d’un atelier Cap’tronic \u00e0 Rouen. C’est suite \u00e0 cette conversation que j’ai eu envie d’approfondir ce sujet.<\/p>\n
","protected":false},"excerpt":{"rendered":"
Nous avons déjà vu dans plusieurs articles qu’il était facile de manipuler les GPIO sous Linux depuis l’espace utilisateur avec l’interface \/sys. Jusqu’à présent je ne m’étais intéressé qu’aux lectures et écritures, mais il est également possible de faire des attentes passives de changement d’état avec select() ou poll(). Voyons-en une mise en œuvre sur […]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,10,11],"tags":[],"class_list":["post-3529","post","type-post","status-publish","format-standard","hentry","category-linux-2","category-microprocesseur","category-raspberry-pi"],"_links":{"self":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/3529","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/comments?post=3529"}],"version-history":[{"count":14,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/3529\/revisions"}],"predecessor-version":[{"id":3531,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/3529\/revisions\/3531"}],"wp:attachment":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/media?parent=3529"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/categories?post=3529"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/tags?post=3529"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}