Recyclez votre vieille souris en capteur

Magazine
Marque
Hackable
Numéro
28
|
Mois de parution
janvier 2019
|
Domaines


Résumé
Lorsque vous bricolez, le premier défi est de trouver la meilleure approche avec le matériel adéquat, tout en minimisant le coût matériel et le développement logiciel. Si vous avez juste besoin de lire l'état de quelques interrupteurs, sans contrainte de temps réel forte, la solution se trouve probablement dans une brocante à un sou, ou dans votre carton d'antiquités qui ont échappé à la benne depuis 20 ans. En effet, quoi de plus commun, économique, simple et pratique qu'une bonne vieille souris à fil ?

Body

C'est qu'il y a plein de choses sympathiques et bricolables dans une souris ! Surtout les plus anciennes, avant l'apparition des capteurs optiques et les liaisons Bluetooth. D'abord elles fournissent un câble USB, pour éviter de s'embêter à faire son câble soi-même, par exemple pour récupérer un peu de courant qui alimentera un petit circuit en 5V. Il est ironiquement moins cher d'acheter une souris « premier prix » et de lui couper la queue, que d'acheter du fil et des connecteurs à l’unité, en espérant que le montage soit fiable. Avec un peu de chance, le fil sera même branché dans la souris par un connecteur, que l'on pourra aussi récupérer. Et sur le cadavre de la souris restent encore des composants intéressants, à commencer par des boutons poussoirs (souvent d'assez bonne qualité). Il y a aussi des émetteurs et capteurs infrarouges avec leurs roues codeuses, comme sur la figure 1.

1. L'aspect matériel

Mais l'ensemble du circuit peut aussi être utilisé à d'autres fins que « dispositif de pointage », car si on regarde bien, il s'agit bêtement, pour ce qui nous concerne ici, d'un périphérique USB fournissant trois entrées « tout ou rien ». Cela permet d'éviter de dégainer votre plateforme embarquée préférée et vous pourrez ainsi développer et contrôler tout le montage confortablement sur votre PC. Sans avoir à développer le moindre pilote de périphérique, et garanti pour fonctionner partout.

_M7_6115_4416

Fig. 1 : La souris mise à nu, hors de sa carapace, libère la mécanique de la molette.

Au passage, je ne peux m'empêcher de noter l'ironie de la situation actuelle de l'informatique, qui ne fait qu'empirer. Malgré les performances ahurissantes des ordinateurs disponibles aujourd'hui au grand public, leurs capacités de communications ont touché le fond. Un ordinateur actuel est habituellement un laptop doté d'un port Ethernet, de quelques ports USB (si vous avez fait attention en l'achetant) et parfois même d'une sortie vidéo complémentaire. En rognant sur tous les coûts, donc en réduisant les options, les laptops « grand public » d'aujourd'hui sont réduits à des tablettes à clavier...

L'industrie a misé sur le « tout passe par Wifi, Bluetooth ou USB » au détriment de la simplicité matérielle et logicielle. En effet, le « super hack » de cet article aurait juste requis un trombone dans la prise DB25 du port d'imprimante parallèle, sur un PC d'il y a 20 ans. À cette époque, le feu magazine Électronique Pratique regorgeait de montages utilisant cette interface ultra-bricolable et très aisée à programmer. Mais on doit vivre avec son temps alors j'espère que Saint MacGyver me pardonnera pour cette fois. Regardons donc en quoi consiste notre « trombone 2.0 ».

Du côté matériel, il n'y a pas beaucoup à dire, et c'est bon signe. Les boutons sont habituellement mécaniques, les contacts sont du type « normalement ouverts » et leur nombre varie d'un modèle à l'autre. Il est important de vérifier soi-même chaque caractéristique électrique afin d'assurer la compatibilité de votre montage (au risque de rendre le périphérique vraiment inutile pour de bon). Donc, comme l'énonce la loi fondamentale de l'électronique : « ne supposez rien, mesurez ! ».

Une des surprises que vous pourriez rencontrer est que la plupart des modèles essaient de conserver l'énergie (surtout pour les modèles sur batterie) et restent en veille la plupart du temps. Ainsi, la souris interrogera les boutons typiquement quelques centaines de fois par seconde, durant quelques microsecondes. Si vous cherchez à mesurer la tension aux bornes de l'interrupteur, vous ne trouverez qu'une faible valeur avec votre voltmètre. Ne paniquez pas et sortez l'oscilloscope (ou regardez la figure 2 si vous n'en avez pas un).

pic_22_3

Fig. 2 : Ne vous étonnez pas que la tension aux bornes d'un interrupteur soit un peu bizarre. Voici la forme de la tension capturée par mon oscilloscope, montrant des pulsations à différentes fréquences. C'est un peu bizarre pour un simple switch, et pourtant ça fonctionne.

En conséquence, ce système n'est pas fait pour capturer des évènements à haute vitesse. Donc, contrairement à un bricolage d’antan sur le port d'imprimante parallèle, notre « trombone 2.0 » si sophistiqué sera en fait lent. Ainsi, ne vous attendez pas à une bonne fiabilité au-delà de quelques dizaines d’impulsions par seconde sur le signal d'entrée. C'est toutefois moins cher et plus facile que de sortir un Arduino ou un Pi pour lire juste deux ou trois boutons, et vous pourrez commencer à bricoler un prototype pour votre projet de domotique ou de robotique à moindres frais et avec peu de développement.

Cette lecture pulsée complique votre montage si vous souhaitez fermer le contact par un autre moyen qu'un interrupteur mécanique. L'idéal est d'utiliser un MOSFET [1] du genre BS170, mais vous devrez vérifier et valider les polarités et les tensions. Il est même possible que certains boutons ne puissent pas être contrôlés électroniquement à cause d'optimisations visant à faire des économies. Par exemple, sur le modèle que j'ai bricolé, on voit sur la figure 4 que le bouton gauche n'est pas connecté au 0V, contrairement aux deux autres. Il ne sera donc pas possible de mettre un MOSFET branché au 0V pour le déclencher. Il restera quand même 2 boutons... Puisque mon projet utilise seulement des contacts mécaniques isolés les uns des autres, je ne m'en préoccupe pas ici.

_M7_6121_3684

Fig. 3 : Le circuit imprimé, côté recto, montre tous les composants.

_M7_6125_4220

Fig. 4 : Côté verso, nous voyons les pistes qui connectent les composants. Nous repérons les points de soudure stratégiques, sur lesquels nous souderons des fils supplémentaires qui permettront de simuler l'appui sur les boutons.

Après avoir effectué quelques tests au multimètre, pour vérifier les tensions et les résistances aux points stratégiques, on y soude des fils et on valide le fonctionnement général avec un ordinateur. Mais un nouveau problème très bête apparaît alors.

2. L'aspect logiciel

Eh oui ! Il fallait s'en douter : quand on appuie sur un bouton de la souris, l'ordinateur réagit et « clique ». Après tout, c'est à cela que sert une souris, non ? Nous allons devoir désactiver ce comportement sans pour autant désinstaller la souris. Il faut juste dire à l'ordinateur de ne pas en tenir compte pour l'interface graphique.

Je précise que toute la partie logicielle cible un OS de la famille Linux. Si vous utilisez Fedora, Gentoo, Ubuntu ou une autre distribution sur votre Raspberry Pi ou votre ordinateur, aucun souci. Je suppose qu'il faudra des adaptations nombreuses sous MacOS, et je n'ose même pas considérer réfléchir à ce que ce serait sous Windows. J'espère que cet article vous donnera envie d'essayer Linux, en voyant la facilité à explorer le système et développer des petits programmes sans devoir subir tout un environnement propriétaire ou traquer des informations réservées aux développeurs enregistrés. Linux a été fait par des hackeurs pour des hackeurs, et cet article en est une jolie illustration parmi tant d'autres !

2.1 Détecter la souris

D'abord, voyons comment notre Linux détecte la souris. J'utilise Fedora, mais ces manipulations devraient fonctionner sur la plupart des autres systèmes basés sur Linux.

$ dmesg
[1015128.994372] usb 2-1.3: new low-speed USB device number 86 using ehci-pci
[1015129.078062] usb 2-1.3: New USB device found, idVendor=046d, idProduct=c077
[1015129.078069] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[1015129.078073] usb 2-1.3: Product: USB Optical Mouse
[1015129.078077] usb 2-1.3: Manufacturer: Logitech
[1015129.083902] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/0003:046D:C077.0007/input/input62
[1015129.084707] hid-generic 0003:046D:C077.0007: input,hidraw1: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.0-1.3/input0

Si vous venez de brancher la souris juste avant d'exécuter la commande dmesg, les lignes ci-dessus devraient s'afficher en dernier. Sans ambiguïté, il s'agit bien là de notre souris sacrifiée. Le fabricant et le modèle correspondent bien, mais les informations associées sont totalement absconses. Il faudra les trouver autre part, par exemple avec la commande suivante :

$ xinput list

⎡Virtual core pointer id=2 [master pointer (3)]

⎜ ↳Virtual core XTEST pointer id=4 [slave pointer (2)]

⎜ ↳PS/2 Generic Mouse id=12 [slave pointer (2)]

⎜ ↳SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]

⎜ ↳Wacom Intuos 6x8 Pen stylus id=9 [slave pointer (2)]

⎜ ↳Wacom Intuos 6x8 Pen eraser id=15 [slave pointer (2)]

⎜ ↳Wacom Intuos 6x8 Pen cursor id=16 [slave pointer (2)]

⎜ ↳ Logitech USB Optical Mouse id=17 [slave pointer (2)]

Avec cette commande (spécifique à l'environnement Xorg), nous constatons à la dernière ligne que notre suppliciée a reçu le numéro 17. On avance...

Une autre source d'informations se trouve dans un des fichiers virtuels du répertoire /proc :

$ cat /proc/bus/input/devices | grep "Name"

N: Name="Sleep Button"

N: Name="Lid Switch"

N: Name="Power Button"

N: Name="AT Translated Set 2 keyboard"

N: Name="PS/2 Generic Mouse"

N: Name="Video Bus"

N: Name="SynPS/2 Synaptics TouchPad"

N: Name="ST LIS3LV02DL Accelerometer"

N: Name="HP HD Webcam [Fixed]: HP HD Web"

N: Name="HP WMI hotkeys"

N: Name="HDA Intel PCH Mic"

N: Name="HDA Intel PCH Line"

N: Name="HDA Intel PCH Dock Line Out"

N: Name="HDA Intel PCH Headphone"

N: Name="HDA Intel PCH HDMI/DP,pcm=3"

N: Name="HDA Intel PCH HDMI/DP,pcm=7"

N: Name="Wacom Intuos 6x8 Pen"

N: Name="Logitech USB Optical Mouse"

Nous y retrouvons la liste de tous les périphériques d'entrée, alors allons fouiller un peu plus :

$ less /proc/bus/input/devices

...

I: Bus=0003 Vendor=046d Product=c077 Version=0111

N: Name="Logitech USB Optical Mouse"

P: Phys=usb-0000:00:1d.0-1.3/input0

S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/0003:046D:C077.0006/input/input61

U: Uniq=

H: Handlers=mouse3 event17

B: PROP=0

B: EV=17

B: KEY=ff0000 0 0 0 0

B: REL=103

B: MSC=10

...

Encore plein d'informations absconses, mais au milieu desquelles nous trouvons la ligne Handlers qui indique mouse3 event17. Cela correspond à des noms de fichiers virtuels situés dans le répertoire /dev/input :

[yg@localhost C]$ l /dev/input/

drwxr-xr-x. 4 root root 560 19 nov. 02:57 .

drwxr-xr-x. 21 root root 4160 19 nov. 02:57 ..

drwxr-xr-x. 2 root root 140 19 nov. 02:57 by-id

drwxr-xr-x. 2 root root 160 19 nov. 02:57 by-path

crw-rw----. 1 root input 13, 64 30 oct. 03:35 event0

crw-rw----. 1 root input 13, 65 30 oct. 03:35 event1

crw-rw----. 1 root input 13, 74 30 oct. 03:35 event10

crw-rw----. 1 root input 13, 75 30 oct. 03:35 event11

crw-rw----. 1 root input 13, 76 30 oct. 03:35 event12

crw-rw----. 1 root input 13, 77 30 oct. 03:35 event13

crw-rw----. 1 root input 13, 78 30 oct. 03:35 event14

crw-rw----. 1 root input 13, 79 30 oct. 03:35 event15

crw-rw----. 1 root input 13, 80 30 oct. 03:35 event16

crw-rw----. 1 root input 13, 81 19 nov. 02:57 event17

crw-rw----. 1 root input 13, 66 30 oct. 03:35 event2

crw-rw----. 1 root input 13, 67 30 oct. 03:35 event3

crw-rw----. 1 root input 13, 68 30 oct. 03:35 event4

crw-rw----. 1 root input 13, 69 17 nov. 18:11 event5

crw-rw----. 1 root input 13, 70 30 oct. 03:35 event6

crw-rw----. 1 root input 13, 71 30 oct. 03:35 event7

crw-rw----. 1 root input 13, 72 30 oct. 03:35 event8

crw-rw----. 1 root input 13, 73 30 oct. 03:35 event9

crw-rw-r--. 1 root input 13, 0 30 oct. 03:35 js0

crw-rw----. 1 root input 13, 63 30 oct. 03:35 mice

crw-rw----. 1 root input 13, 32 30 oct. 03:35 mouse0

crw-rw----. 1 root input 13, 33 17 nov. 18:11 mouse1

crw-rw----. 1 root input 13, 34 30 oct. 03:35 mouse2

crw-rw----. 1 root input 13, 35 19 nov. 02:57 mouse3

Il y a 20 ans, la souris était juste de type PS2 et il existait un simple fichier appelé /dev/mouse ou /dev/psaux dans lequel on pouvait lire les données des mouvements. Mais aujourd'hui, tout passe par l'USB et plusieurs dispositifs de pointage peuvent coexister. Dans mon cas, j'utilise simultanément le trackpad intégré, la tablette graphique externe et la souris optique sacrifiée.

Tous ces périphériques sont présentés individuellement avec un fichier de nom /dev/input/mouseX (où X est un numéro de périphérique), et concentrés dans /dev/input/mice qui fournira dans un seul fichier toutes les données de tous les dispositifs de pointage.

Notre souris bricolée apparaît sous le nom /dev/input/mouse3, ce qui est facile à détecter, car je viens de la brancher et la date de ce fichier est la plus récente. L'étau est maintenant bien resserré et un dernier test confirmera cette attribution.

2.2 Lire la souris sans logiciel spécial

Des outils de base installés par défaut sur la plupart des distributions GNU/Linux permettent d'inspecter le flux de données provenant d'un périphérique de type « bloc », comme ceux du répertoire /dev. La première chose est d'obtenir le droit de lire le fichier en question, et le plus simple est de se connecter en tant qu'utilisateur root. su ou sudo bash fera l'affaire.

Ensuite, il suffit de lancer un petit utilitaire dont on entend rarement parler, mais qui permet, contrairement à hexdump ou hexedit, d'afficher les octets un à un, à mesure qu'ils arrivent. Ce programme s'appelle od et sa page de manuel montre l'étendue des formats qu'il peut afficher. Nous allons le lancer en désactivant l'affichage des numéros de ligne (option -An), pour afficher uniquement un octet (option -w1) au format hexadécimal (option -t x1).

sudo od -An -v -w1 -t x1 /dev/input/mouse3

Si on déplace la souris ou si un bouton est appuyé, le terminal crache une liste de nombres... Par exemple, en bougeant le doigt devant le capteur optique :

28

0d

fc

28

0d

fc

28

0b

fe

28

02

ff

...

Cela ressemble à de la bouillie, mais tout devient clair quand on se contente d'appuyer et relâcher le bouton gauche :

09 <--- appui

00

00

08 <--- relâchement

00

00

Et si on appuie et relâche le bouton de droite :

0a <--- appui

00

00

08 <--- relâchement

00

00

C'est similaire pour le bouton du milieu :

0c <--- appui

00

00

08 <--- relâchement

00

00

On constate que le fichier renvoie des paquets de 3 octets, dont le premier contient un bit toujours à 1 pour marquer le début du paquet. C'est ce fameux 8 qui revient tout le temps. Les 3 bits suivants indiquent l'état de chaque bouton et sur les 3 octets, il est facile d'extraire les 3 bits désirés. Ainsi, le 8 se transforme en 9, A ou C selon le bouton appuyé, et toutes les combinaisons possibles si plusieurs boutons sont appuyés simultanément.

masque binaire du premier octet :

bouton gauche : bit 0

bouton droite : bit 1

bouton milieu : bit 2

début de paquet : bit 3 toujours à 1

Les 20 bits restants correspondent aux mouvements sur les axes X et Y. Ils ne nous intéressent pas, car il n'y aura aucun mouvement et on lira toujours 0. Cela garantit qu'on détectera toujours le bon octet contenant l'état des boutons, avec son bit toujours à 1. Un algorithme se dessine alors : il suffit de lire un octet, voir si le bit 3 est à 1, puis de lire l'état :-)

2.3 Configurer Xorg

Mais voilà, lorsqu'on appuie sur un bouton, l'interface graphique réagit toujours. Je vous laisse imaginer les conséquences que cela peut entraîner en pratique, lorsque le montage fonctionnera. Alors non, je ne vais pas quitter le mode graphique et désactiver gpm dans la console, j'ai pris mes habitudes maintenant. Je vais choisir la solution intelligente qui consiste à lire la documentation et chercher sur Internet !

Et en effet, la solution est relativement simple et élégante, bien qu'elle ne soit ni évidente ni facile quand on n'a pas l'habitude de fouiller dans le système. Mais les informations sont faciles d’accès ! L'endroit-clé est le fichier de configuration de l'interface graphique Xorg (sur laquelle tournent vos gestionnaires de fenêtres comme GNOME, KDE, Xfce, etc.). La plupart des informations sont en anglais, mais pas trop difficiles à comprendre. Par exemple, j'ai trouvé les informations les plus utiles à l'adresse https://fedoraproject.org/wiki/Input_device_configuration#Blacklisting_a_device.

Bloquer un périphérique :

Certains périphériques peuvent être détectés et utilisés par le serveur X alors qu'ils ne le devraient pas. Ces périphériques peuvent être configurés pour être ignorés ainsi :)

Section "InputClass"
 Identifier "no need for accelerometers in X"
 Option "Ignore" "on"

EndSection

Donc l'option Ignore permet de désactiver un périphérique sans toucher au noyau, ce qui permet à la souris de continuer de fonctionner sans affecter l'affichage. Le tout est d'indiquer correctement quel est ce périphérique, et la page nous donne les informations nécessaires :

Les options de correspondance spécifient quels périphériques sont concernés par une section.

Pour sélectionner un périphérique, toutes les options de correspondance doivent être validées.

Les critères suivants sont supportés :


MatchIsPointer, MatchIsKeyboard, MatchIsTouchpad, MatchIsTouchscreen, MatchIsJoystick : cela sélectionne un groupe ou un type de périphériques.

MatchProduct "foo|bar" : sélectionne tout périphérique dont le nom de produit contient "foo" ou "bar".

MatchVendor "foo|bar|baz" : sélectionne tout périphérique dont le nom du fabricant contient soit "foo", "bar" ou "baz".

MatchDevicePath "/dev/input/event*" : sélectionne tout périphérique donc le chemin correspond.

Avec ces informations (et quelques autres glanées ici et là), il est facile de créer une règle de configuration qui désactive notre souris et uniquement celle-ci :

Section "InputClass"

Identifier "Desactive souris Logitech"

MatchIsPointer "on"

Driver "evdev"

MatchProduct "USB Optical Mouse"

MatchVendor "Logitech"

Option "Ignore" "true"

EndSection

On retrouve l'option Ignore, le type Pointer ainsi que le nom du produit et du fabricant. Je n'ai pas spécifié un chemin de périphérique particulier, car il peut changer après un redémarrage de l'ordinateur.

Il ne reste plus qu'à écrire cela dans un fichier, au bon endroit, avec les bons droits (appartenant à root, mais lisible par tout le monde). La documentation de Fedora spécifie que

Les utilisateurs sont encouragés à mettre leurs fichiers de configuration personnels dans /etc/X11/xorg.conf

Cependant, ce fichier a disparu dans les OS récents, et il a été remplacé (pour Fedora) par le répertoire /etc/X11/xorg.conf.d. J'ai donc créé un nouveau fichier appelé /etc/X11/xorg.conf.d/01-no_optical_mouse.conf. Maintenant, il faut fermer le serveur X pour qu'il accepte la nouvelle configuration. Refusant de sacrifier mon uptime, je ferme juste la session X.

Au redémarrage... la souris Logitech ne bouge plus ! Mais tout le reste est encore fonctionnel, comme prévu, donc.

3. Exemple d'utilisation pratique

Nous avons fait tout cela pour lire des boutons. Ce n'est pas très compliqué, mais il faut bien sauter le pas... Dans mon cas, j'ai choisi d'utiliser le langage C, bien que d'autres préfèreront Python.

Le fichier suivant propose une fonction pour ouvrir le fichier d'une souris particulière, puis une autre fonction pour interpréter le flux de données, par blocs de 3 octets. J'emploie une technique de lecture non bloquante, ce qui permet de continuer le déroulement du programme même lorsque la souris ne détecte aucune activité. Ainsi, le reste du programme peut scanner la souris à intervalle régulier, et réaliser du travail utile (ou pas) entretemps. Ici, on fait simplement tourner un caractère à l'écran (avec une syntaxe de ha><Or)...

/*

boutons.c

(c) 20181118 Yann Guidon <whygee@f-cpu.org>

Lit l'état des boutons d'une souris, à partir

d'un périphérique tel que /dev/input/mice

gcc -Wall boutons.c -o boutons -DTEST_BOUTONS

*/


#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <stdlib.h>

#include <stdio.h>

#include <errno.h>

#include <unistd.h>


// quelque variables globales :

int mouse_fd, buttons;


void open_mouse(char *path) {

buttons=0;


// pour se faciliter la vie, on peut aussi

// configurer le nom de la souris dans une

// variable d'environnement :

if (!path) {

path=getenv("MOUSE_DEV");

if ((path==NULL) || (*path==0))

path="/dev/input/mice";

}

printf("ouverture de la souris à %s \n", path);

mouse_fd = open(path, O_RDONLY | O_NONBLOCK);

// l'option O_NONBLOCK permet de lire un bloc

// de taille nulle quand aucune donnée n'est

// disponible, au lieu de bloquer tout le programme.

}


// Met à jour la variable globale "buttons",

// retourne un champ de bits correspondant aux

// boutons dont l'état a changé.

int get_buttons() {

char buff[3];

int i, b=buttons, x;


while(1) {

i=read(mouse_fd, buff, 3);


if (i == -1) {

if ((errno == EAGAIN)

|| (errno == EWOULDBLOCK))
// dans ce cas, il n’y a rien à lire,

break;

perror ("erreur de lecture de la souris : ");

return 0;

}


if (i != 3) {

if (i != 0)

printf("Tiens, pas assez d'octets à lire ? %d\n", i);

break;

}


b = buff[0];

if ((b & 8) == 0) {

printf("souris : Marque de synchronisation absente\n");

return 0;

}


} // Continuer de lire jusqu'à


b &= 7; // garde juste les 3 bits des boutons

x = b^buttons; // calcule la différence

buttons = b; // sauve la dernière valeur lue

return x; // renvoie la différence

}

// Un programme de test simple

#ifdef TEST_BOUTONS

int main(int argc, char **argv) {

int i=0;


char *path=NULL;

if (argc > 1)

path=argv[1];

open_mouse(path);

if (mouse_fd == -1) {

perror("échec d'ouverture du périphérique souris");

return 0;

}


while (1) {

usleep(40*1000); // attente de 40ms

if (get_buttons())

printf("gauche=%d milieu=%d droit=%d\n",

buttons&1, (buttons&4)>>2, (buttons&2)>>1);

// spinner en une seule ligne :

printf("%c \r", "-\\|/"[i++ & 3]);

fflush(NULL);

}

}

#endif

Une fois le fichier téléchargé (vous n'allez quand même pas le retaper à la main ?), une petite commande compile le programme en activant la fonction main(), qui fournit un simple programme d'exemple :

[yg@localhost]$ gcc -Wall boutons.c -o boutons -DTEST_BOUTONS

Si vous n'êtes pas encore en root, c'est le moment de vous connecter, sinon cela donne :

[yg@localhost C]$ ./boutons

ouverture de la souris à /dev/input/mice

échec d'ouverture du périphérique souris: Permission denied

Donc retournons à la racine :-)

[root@localhost]# ./boutons

ouverture de la souris à /dev/input/mice

gauche=0 milieu=0 droit=1

gauche=0 milieu=0 droit=0

gauche=1 milieu=0 droit=0

...

Par défaut, le fichier à ouvrir est /dev/input/mice, mais on peut spécifier un autre fichier en argument sur la ligne de commandes :

[root@localhost C]# ./boutons /dev/input/mouse3

ouverture de la souris à /dev/input/mouse3

...

ou bien, en l’absence d’argument, avec une variable d'environnement :

[root@localhost C]# export MOUSE_DEV=/dev/input/mouse3

[root@localhost C]# ./boutons

ouverture de la souris à /dev/input/mouse3

gauche=0 milieu=0 droit=1

gauche=0 milieu=0 droit=0

gauche=0 milieu=1 droit=0

gauche=0 milieu=0 droit=0

gauche=1 milieu=0 droit=0

...

Et maintenant, il ne vous reste plus qu'à connecter les boutons à votre propre montage !

20181112_054727_1763

Fig. 5 : Le cadavre de souris est bouturé au Frankentesteur de relais russes.

Conclusion

J'espère que ce petit tour d'horizon vous aura fait découvrir quelques subtilités et astuces très pratiques pour vos projets. Une bête souris peut résoudre des problèmes compliqués et nous n'en avons vu que la partie la plus simple, celle des boutons. Cela me suffit pour tester le fonctionnement de relais russes dans des conditions contrôlées [2] avec le petit montage de la figure 5, mais j'imagine qu'il existe d'innombrables applications, ne serait-ce que parce que le coût est minimal et la technologie reste très basique.

Nous n'avons même pas abordé le détournement des autres capteurs, comme les disques encodeurs, qui peuvent servir de compte-tours ou de fréquencemètre rudimentaire. Je laisse cette partie à Laura Bécognée, qui en aura besoin pour son projet de banc de test de moteurs électriques.

Je me suis aussi demandé comment on pourrait modifier le capteur optique pour faire de la détection de mouvements à quelques dizaines de centimètres, au lieu de millimètres. Selon les informations disponibles, les puces modernes contiennent une sorte de mini-caméra simplifiée. Si je résous ce défi que je m'étais posé il y a plus de dix ans, je pourrai bricoler des interfaces haptiques très économiques ! J'ai buté jusqu’à maintenant sur l'optique avant de choisir d'autres solutions d’autres types, mais qui sait si un de nos lecteurs y arrivera ?

Références

[1] Guidon Y., « Nos amis les MOSFET » Hackable n°12, mai 2016, pp70-83.
Article en Creative Commons consultable à https://connect.ed-diamond.com/Hackable/HK-012/Nos-amis-les-MOSFET

[2] Le projet du testeur de relais fournit aussi le code source ci-dessus, à https://hackaday.io/project/16961-retest-yg


Sur le même sujet

La liberté jusqu’au cœur du processeur avec RISC-V

Magazine
Marque
Hackable
Numéro
31
|
Mois de parution
octobre 2019
|
Domaines
Résumé
RISC-V est un jeu d’instructions 32 bits libre, développé initialement par l’université de Berkeley. Ce jeu d’instructions (ISA pour Instruction Set Architecture) est maintenant soutenu par une fondation regroupant quasiment tous les grands noms de l’industrie informatique. Dans cet article, nous allons décrire succinctement le concept de RISC vs CISC, puis nous expliquerons les bases du jeu d’instructions avec un peu de code assembleur, enfin nous terminerons par une description de quelques émulateurs et processeurs RISC-V disponibles aujourd’hui sur le marché.

Démarrez avec MicroPython

Magazine
Marque
GNU/Linux Magazine
Numéro
228
|
Mois de parution
juillet 2019
|
Domaines
Résumé
Pour mettre sur pied une preuve de concept ou un prototype électronique, il faut habituellement choisir une carte de développement et ensuite acquérir les outils de développement logiciel du fabricant. Ces logiciels s’appuient généralement sur les langages bas niveau comme le C, dont la maîtrise n’est pas accessible à tout le monde. MicroPython est a été mis sur pied pour permettre l’utilisation d’un langage de programmation haut niveau (Python) sur microcontrôleur, pour créer de magnifiques applications d’IoT.

Contrôler vos modèles Lego au joypad à l'aide de BrickPi

Magazine
Marque
Hackable
Numéro
29
|
Mois de parution
avril 2019
|
Domaines
Résumé
Dexter Industries propose des cartes d’extension pour Raspberry Pi. Dans cet article, nous allons nous intéresser à la carte BrickPi permettant de piloter les moteurs et senseurs Lego MindStorms. Nous verrons comment piloter notre robot Lego à l’aide d’un joypad. Nous développerons notre programme grâce au langage Python.

Créez simplement votre périphérique matériel avec le langage C

Magazine
Marque
Hackable
Numéro
29
|
Mois de parution
avril 2019
|
Domaines
Résumé
Cet article présente la création et la mise en œuvre d’un périphérique matériel libre sous Linux embarqué pour la carte ZedBoard, utilisant un circuit FPGA Zynq. La synthèse de haut niveau HLS, à l’aide du langage C, sera utilisée ici pour la création du périphérique matériel.

Bus CAN : se lancer dans l'analyse des communications de votre véhicule

Magazine
Marque
MISC
HS n°
Numéro
19
|
Mois de parution
février 2019
|
Domaines
Résumé

Cet article a pour but de s’intéresser aux communications internes d’un véhicule. Il sera présenté comment réaliser sa propre interface CAN/USB basée sur un Arduino, puis sera décrite la manière d’analyser et d’injecter des paquets à l’aide d’outils d’analyse réseau classiques.

Par le même auteur

Recyclez votre vieille souris en capteur

Magazine
Marque
Hackable
Numéro
28
|
Mois de parution
janvier 2019
|
Domaines
Résumé
Lorsque vous bricolez, le premier défi est de trouver la meilleure approche avec le matériel adéquat, tout en minimisant le coût matériel et le développement logiciel. Si vous avez juste besoin de lire l'état de quelques interrupteurs, sans contrainte de temps réel forte, la solution se trouve probablement dans une brocante à un sou, ou dans votre carton d'antiquités qui ont échappé à la benne depuis 20 ans. En effet, quoi de plus commun, économique, simple et pratique qu'une bonne vieille souris à fil ?

Quelques applications des Arbres Binaires à Commande Équilibrée

Magazine
Marque
GNU/Linux Magazine
Numéro
218
|
Mois de parution
septembre 2018
|
Domaines
Résumé
Les Arbres Binaires à Commande Équilibrée, ou ABCE, ont été présentés dans GLMF n°215 [1] au moyen d'une métaphore ferroviaire. Cependant, ils sont surtout utiles dans certains circuits numériques, dont ils améliorent la vitesse et la consommation, pour la plupart des technologies. Par rapport à un arbre binaire classique, le gain de performance augmente avec la taille, ce qui est un atout précieux pour concevoir des circuits intégrés par exemple.

Revue de livre : Le réseau miniature, par Burkhard Oerthel

Magazine
Marque
Hackable
Numéro
25
|
Mois de parution
juillet 2018
|
Domaines
Résumé
Lors d'une visite dans un magasin de modélisme ferroviaire, rue de Douai, j'ai découvert un petit livre qui m'a immédiatement séduit et que je souhaite faire découvrir hors du petit cercle des modélistes. Bien qu'il ne soit pas destiné au monde du DIY, il contient la plupart des techniques importantes que le bricoleur se doit de connaître.

La fabuleuse histoire des calculateurs numériques à l'ère électromécanique

Magazine
Marque
Hackable
Numéro
25
|
Mois de parution
juillet 2018
|
Domaines
Résumé
Notre monde est aujourd'hui totalement baigné de technologie digitale !Pour en arriver à regarder des vidéos de chats sur notre téléphone dans le métro, il aura fallu bien plus que de la théorie : Boole et de Morgan avaient déjà couvert les bases mathématiques du calcul binaire au 19è siècle. À partir de là, des générations d'ingénieurs ont cherché et inventé des nouveaux circuits, puis ont travaillé sans relâche pour réduire leur taille et leur consommation, tout en accélérant leur fonctionnement. Je vous propose de retracer cette longue évolution, pour mieux apprécier et comprendre les avantages et inconvénients de chaque génération technologique. Et la première étape décisive dans l'histoire des ordinateurs fut l'utilisation des relais électromécaniques.

À la découverte des Arbres Binaires à Commande Équilibrée

Magazine
Marque
GNU/Linux Magazine
Numéro
215
|
Mois de parution
mai 2018
|
Domaines
Résumé
Dans cet article un peu théorique, nous allons jouer avec la métaphore des aiguillages. Vous pensiez peut-être que concevoir une gare de triage est un jeu d'enfant, mais quand des contraintes (fictives ? réelles ?) s'en mêlent, il faut se gratter un peu la tête et faire appel à des permutations astucieuses... C'est ainsi qu'apparaissent les ABCE, ou Arbres Binaires à Commande Équilibrée, une technique inhabituelle qui trouve sa place, entre autres, dans des circuits électroniques numériques.

La logique du Jeu de la Vie : exercices amusants de pensée latérale

Magazine
Marque
GNU/Linux Magazine
Numéro
213
|
Mois de parution
mars 2018
|
Domaines
Résumé
Le Jeu de la Vie de John H. Conway est encore loin d'avoir livré tous ses secrets ! Son créateur estime que les propriétés fondamentales de ce célèbre automate cellulaire sont maintenant déterminées [1], mais les réalisations informatiques continuent de progresser et deviennent de plus en plus audacieuses [2]. Nous décortiquerons une famille d’algorithmes « latéraux » efficaces en temps de calcul, économes en mémoire, pour débrider toute la puissance de votre PC dernier cri.