Afficheur autonome de DX cluster : Le DX Ticker (2/3)
La première partie de cet article est disponible ici…
Avant tout, la première étape consiste à installer OpenWRT sur le routeur, et le configurer pour qu’il accède à votre réseau Wi-Fi. De nombreux tutoriaux existent sur le sujet, et également des vidéos (même en français). Pour se familiariser avec cette distribution, il est également possible de l’installer dans une machine virtuelle dans sa version x86. Avant de se lancer, il est bon de s’imprégner du sujet et la lecture du Wiki d’OpenWRT s’avère indispensable, notamment en cas de volonté de mise à jour ultérieure, ou pour tout réinstaller (sans perdre les fichiers de config. si possible) si ça se passe mal.
Port série
La toute première modification hardware effectuée est d’installer un connecteur 3 broches (TxD, RxD, GND) au pas de 2.54 pour sortir un port série (qui sera au niveau 3v3). Ce port sera utilisé en cas d’urgence si le firmware installé se trouvait corrompu et bloquait entièrement la connectivité réseau. On est jamais trop prudent. Il s’est avéré que je n’en ai pas eu besoin, mais bon…
Il s’agit donc juste d’installer un mini-connecteur DIL 3 broches à l’emplacement d’une LED qui n’est pas câblée, couper les pistes de la LED absente, et gratter le vernis épargne pour souder la broche de masse. Puis relier par du fil à wrapper ces broches aux points tests nommés TP_IN et TP_OUT sur la sérigraphie en bas à droite côté composants. Une fois la soudure effectuée sur ces test-points, je conseille fortement de les noyer sous une goutte de colle à chaud pour éviter de les arracher par une mauvaise manip.
Pour vérifier que tout fonctionne, il suffit de rebooter le routeur (ON/OFF) en ayant connecté ce port série via, par exemple, un adaptateur USB / Série 3v3 à PuTTY en 115200 8N1.
Hub USB
En faisant quelques essais préliminaires avec OpenWRT sur le WR703N, il apparait un premier souci : Le clavier numérique USB n’est pas reconnu en tant que tel par le système. En fait, le port USB 2.0 ne reconnait directement que les périphériques High Speed, mais il ne sait pas gérer les périphériques Low Speed comme les claviers ou les souris. Le seul moyen est donc d’utiliser un hub USB 2.0 High Speed qui va assurer la transition entre ces protocoles. Avoir un élément supplémentaire ne m’enchante guère, mais à la lecture de plusieurs sites, il est possible d’intégrer un tel hub dans le routeur. Ce sera ma première modification sérieuse.
J’ai fini par trouver un hub USB qui convient pour quelques euros, et l’ai dépouillé totalement pour l’intégrer dans le boitier. Il suffit de démonter le connecteur USB, sortir 4 fils pour aller vers le hub et réinstaller un connecteur USB femelle à la place de l’ancien avec des broches droites, reliées au hub. J’ai même ainsi à ma disposition 3 ports USB supplémentaires disponibles si besoin.
Par expérience, sachez qu’il existe de nombreux modèles de hubs qui utilisent tous le même boitier plastique noir et des connecteurs « en araignée ». Certains ne sont pas High Speed, mais seulement Full Speed, et ne conviennent donc pas à cette utilisation. Certains vendeurs changent aussi de fournisseur, sans prévenir, et sans véritablement contrôler les caractéristiques du produit. On pourra s’assurer de la vitesse effective du hub par la commande « lsusb -vt » sous OpenWRT (ne pas oublier d’installer les packages adéquats), ou par exemple avec l’utilitaire UsbTreeView sous Windows.
root@OpenWrt:~# lsusb -vt /: Bus 01.Port 1: Dev 1,, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0,, Driver=hub/4p, 480M |__ Port 1: Dev 3, If 0, Interface Device, Driver=usbhid, 1.5M root@OpenWrt:~#
Le clavier est alors reconnu comme HID dans dmesg :
root@OpenWrt:/# dmesg | grep usb [ 4.670000] usbcore: registered new interface driver usbfs [ 4.680000] usbcore: registered new interface driver hub [ 4.680000] usbcore: registered new device driver usb [ 5.080000] usb 1-1: new high-speed USB device number 2 using ehci-platform [ 5.510000] usb 1-1.1: new low-speed USB device number 3 using ehci-platform [ 9.050000] input: HID 1710:8812 as /devices/platform/ehci-platform/usb1/1-1/1-1.1/1-1.1:1.0/input/input0 [ 9.060000] hid-generic 0003:1710:8812.0001: input,hidraw0: USB HID v1.10 Keyboard [HID 1710:8812] on usb-ehci-platform-1.1/input0 [ 9.070000] usbcore: registered new interface driver usbhid [ 9.070000] usbhid: USB HID core driver root@OpenWrt:/#
Sortie I2C
Arrive alors la modification la plus délicate : Utiliser deux broches GPIO de l’AR7240 comme interface I2C. Il s’agit de dessouder 2 résistances CMS 0402 (lunettes / loupe / microscope indispensable) de pull-down R15 et R17 situés à gauche du SoC côté composants, et souder 2 fils à wrapper à la place. Comme pour la sortie série, la goutte de colle à chaud après l’opération est conseillée. Ces sorties sont au niveau 2v7 et il est donc indispensable d’utiliser un circuit d’adaptation si l’on veut commander un périphérique I2C 5v. J’ai également récupéré du 2v5 sur un point test nommé TP_2V5 côté cuivre, vers le centre, pour faciliter le câblage de cet adaptateur, que j’ai choisi d’installer côté LCD. Donc, sortent sur un connecteur HE10 (un peu surdimensionné) : GND, SDA (br 29), SCL (br 7), 2v5 et 5v.
Pour disposer d’un port I2C avec ces 2 broches, il faut installer les packages kmod-i2c-gpio-custom, kmod-i2c-core et i2c-tools (optionnel mais pratique pour tester). Puis installer les modules i2c-dev (insmod i2c-dev) et i2c-gpio-custom en précisant les paramètres adéquats (insmod i2c-gpio-custom bus0=0,29,7). Si tout va bien, dmesg doit contenir ces 2 lignes :
root@OpenWrt:/# dmesg | grep i2c [ 8.940000] i2c /dev entries driver [ 8.960000] i2c-gpio i2c-gpio.0: using pins 29 (SDA) and 7 (SCL) root@OpenWrt:/#
L’adaptateur I2C 5v consiste pour chaque ligne SDA et SCL en une résistance de pull-up de chaque « côté » (2v5 et 5v) et un N-FET pour assurer la transition. Pour ma part, j’ai « cannibalisé » un adaptateur déjà câblé, qui était prévu pour adapter du 5v à du 3v3, en retirant ce qui gênait, à savoir le régulateur 3v3 et une diode.
Afficheur LCD
Concernant l’afficheur, mon choix s’est porté sur un modèle à 4 lignes de 20 caractères, rétro-éclairé, avec interface I2C (5v) déjà connectée. Le circuit qui pilote le LCD est un classique HD44780, extrêmement répandu dans tous ces modules. Il est câblé en mode data 4-bits avec le PCF 8574 (I2C I/O expander) sur l’interface I2C, qui comporte 8 sorties. Les 4 autres sorties correspondent au 3 signaux de commande RS, R/W et EN, et à la commande du rétroéclairage (backlight).
Une fois l’adaptateur I2C 5v/3v3 connecté sur l’afficheur LCD via l’interface I2C, et sur le routeur, il faut tester si le PCF8574 est vu sur le bus I2C, avec i2cdetect :
root@OpenWrt:~# i2cdetect 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0. I will probe address range 0x03-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- 27 -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@OpenWrt:~#
Il est bien vu par le système, et i2cdetect indique même son adresse 0×27 (39).
Les éléments extérieurs fonctionnent donc, et sont vus par OpenWRT : Le clavier (numérique), et l’afficheur LCD via l’interface I2C.
Il va falloir maintenant passer au software pour mettre tout cela en musique !
Suite et fin dans la troisième partie…
Bsr Laurent,
Voilà du beau boulot ! (dixit mon QRPP
73 Denis F4FBP