Bon alors pour Tinara, les GPIO vus d'orbite géostationnaire...
J'en garde volontairement une vision simpliste et naïve, tant que ça suffit pour s'en servir.
Physiquement chaque broche se comporte comme un relais : elle peut être "up" ou "down" - y a du courant ou y en a pas.
On peut l'utiliser en input (quelqu'un a fermé le relais et je vois du jus) ou en output (j'ai fermé le relais et ça envoie du jus à quelque chose).
Ici input = un bouton, une diode IR... et output = un écran I2C, un DAC I2S...
Côté logiciel, le système peut lire et écrire l'état de chaque broche, et être averti en cas de changement d'état.
Le principe me rappelle furieusement la programmation des interruptions matérielles en C sous MS-DOS (y a longtemps :-).
Ici c'est déjà dans le système, avec des interfaces de plus haut niveau.
Par exemple en Python il suffit d'un import, d'une ligne pour déclarer un GPIO en entrée ou en sortie, et d'une autre pour lui affecter un callback lorsqu'un événement se produit :
Code : Tout sélectionner
import RPi.GPIO as GPIO
GPIO.setup(22, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.add_event_detect(22, GPIO.FALLING, callback=ma_fonction_callback)
Cette méthode est simplissime, mais utilisée pour gérer un input mécanique (typiquement un bouton), elle a deux gros inconvénients.
D'une part, on est ici vraiment en mode relais, on ferme un contact pour envoyer du jus.
Comme le contact physique est toujours imparfait, il se fait souvent en plusieurs fois, et le système peut détecter plusieurs événements pour un seul appui, d'où des rebonds. Ça se gère soit matériellement (rajouter des résistances en série), soit dans le code (tempos, tests), mais c'est pénible et rarement parfait.
D'autre part, c'est bourrin parce qu'il faut une broche GPIO sur une patte de chaque bouton, l'autre étant à la masse.
Or finalement sur le Raspi il n'y en a pas tant que ça :
Sur le connecteur P1 il y a 26 broches, dont deux en +5V, deux en 3.3V et quatre masses (GND).
Il reste donc 17 broches GPIO, sauf que 9 ont une double fonction, et c'est fromage ou dessert...
Par exemple moi j'utilise le 3 et le 5 pour la fonction I2C qui pilote l'écran en mode série : en mode parallèle il en faudrait 10 !
Donc si on a plusieurs périphériques ça part très vite...
D'où l'intérêt d'utiliser des modes série quand c'est possible (I2C, I2S, RS-232, SPI).
On peut aussi gérer des boutons physiques en I2C via un CI intermédiaire comme pour l'écran, ou alors utiliser l'astuce décrite plus haut pour les matrices de boutons (souvent un clavier numérique).
C'est beaucoup plus pointu déjà au niveau câblage, dans ce style-là :
Donc 8 fils pour 16 boutons et pas de masse, on est plus en mode relais...
Et côté code c'est nettement plus sioux aussi, j'ai adapté le mien à partir de ça :
http://crumpspot.blogspot.fr/2013/05/us ... berry.html
Je ne prétends pas comprendre précisément comment ça marche, mais le fait est que ça marche bien, et sans rebonds en plus !
J'ai juste remplacé dans KEYPAD les valeurs des touches par celles que j'ai données aux touches de la télécommande dans LIRC.
Puis adapté dans ROW et COLUMN le nombre de lignes/colonnes et les GPIO affectés.
Du coup mes fonctions existantes gèrent aussi bien la télécommande que le clavier.
Et puis dans ma version j'ai toiletté le code, parce que que ça ressemblait plus à du Basic ou du JS qu'à du Python :-)
