Afficheur autonome de DX cluster : Le DX Ticker (3/3)
Les deux premières parties de cet article sont disponibles ici et ici…
Plutôt que de vouloir faire un programme monolithique qui gère tout, je me suis appuyé sur des solutions existantes pour le clavier et l’afficheur. Ce sera triggerhappy pour le clavier, et lcd4linux pour l’afficheur, qui sont des « daemons » qui tournent en tâche de fond.
Concernant le programme principal, il doit se connecter au DX-cluster, récupérer les infos, les mettre en forme pour l’afficheur, et selon les actions sur le clavier, « scroller » dans l’historique, faire afficher au LCD au choix les spots, les données WWV ou les données WCY. J’ai écarté les annonces pour l’instant. Comment écrire et développer ce process principal ? La première solution qui vient à l’esprit est le classique C (ou C++). Néanmoins, on est dans un environnement qui nécessitera de la cross-compilation, et le debugging risque alors d’être particulièrement lourd. En effet, il est pas possible d’installer d’environnement de développement directement sur le router (ses caractéristiques en terme de mémoire de masse et de RAM l’interdisent, sans parler de la vitesse d’éxecution des outils). Cette perspective ne m’enchante pas vraiment, surtout que je n’ai aucune expérience en matière de cross-developpement.
Par contre, le langage interprété Lua, très léger et très rapide, peut être installé sur le routeur sous forme de package, puisqu’il est utilisé par exemple pour l’interface web de paramétrage Luci (que je n’ai pas installé pour gagner de la place). Je connais déjà Lua pour l’avoir implémenté en tant que langage de script dans Win-Test et il conviendra parfaitement. Il faut juste lui adjoindre la bibliothèque de sockets (package LuaSocket) pour permettre la connexion au DX-cluster. Par contre, hélas, il n’est pas multi-thread nativement et il va falloir un peu jongler, notamment pour gérer le clavier sans trop de latence.
Pour les échanges entre le clavier et le script principal, j’utilise un fichier de type fifo, dans le répertoire /tmp qui est en fait en RAM. Ainsi, pas de latence, et pas d’usure du media ! Lorsque l’on appuie sur une touche, triggerhappy la détecte, et met un caractère (dépendant de la touche – cf le fichier de config de triggerhappy ci-dessous) dans le fifo, et lorsque le script va scruter le fifo, il va le récupérer et le traiter. La répétition automatique n’est gérée que pour les touches Up et Down, à savoir 8 et 2 sur le keypad.
root@OpenWrt:/etc/triggerhappy/triggers.d# cat dxticker.conf KEY_KP1 1 echo "1" > /tmp/fifo KEY_KP2 1 echo "2" > /tmp/fifo KEY_KP2 2 echo "2" > /tmp/fifo KEY_KP3 1 echo "3" > /tmp/fifo KEY_KP4 1 echo "4" > /tmp/fifo KEY_KP5 1 echo "5" > /tmp/fifo KEY_KP6 1 echo "6" > /tmp/fifo KEY_KP7 1 echo "7" > /tmp/fifo KEY_KP8 1 echo "8" > /tmp/fifo KEY_KP8 2 echo "8" > /tmp/fifo KEY_KP9 1 echo "9" > /tmp/fifo KEY_KP0 1 echo "0" > /tmp/fifo KEY_KPENTER 1 echo "E" > /tmp/fifo root@OpenWrt:/etc/triggerhappy/triggers.d#
Pour l’afficheur, j’utilise là aussi un autre fichier intermédiaire en RAM (/tmp/lcd.txt) qui va être écrit par le script Lua, et relu régulièrement par lcd4linux qui va envoyer les 4 premières lignes sur l’afficheur. Le problème n’est pas là. Ce qui pose un GROS problème, c’est que le driver lcd4linux pour le circuit HD44780 sur bus I2C est basé sur une assignation des broches du PCF 8574 totalement différente, et notamment pour les 4 bits de données, de celle de l’interface I2C de l’afficheur !
Et là, ça se corse ! Je dois modifier le driver en question du package lcd4linux, le recompiler, et réinstaller le package sur le routeur. Et bien entendu, il faut recommencer la manip à chaque essai… J’installe donc une Debian Wheezy dans une machine virtuelle de VirtualBox, et « en avant les pelles et les pioches ». Je vous passe tous les détails de la manip, mais il me faut quelques (longues) soirées pour arriver à mes fins ! J’obtiens aussi l’assistance d’un Bordelais dont le pseudo est Squonk, trouvé sur le forum OpenWRT, à l’origine du rétro-engineering du WR703N, qui me sort de plusieurs impasses. De voir enfin quelque chose s’afficher sur le LCD en question a été une grande satisfaction 
Mais j’ai beaucoup appris, et c’est là l’essentiel.
Le script principal Lua d’environ 500 lignes se résume donc à :
- Initialisation
- Lancement de la connexion au cluster
- Récupération des infos (spot, wwv, etc.)
- Remise en forme pour que les infos essentielles tiennent sur les 20 colonnes du LCD
- Ajout dans l’historique et mise à jour de l’affichage
- Traitement du clavier
- Et on boucle sur la récup des données (point 3).
Le script est aussi prévu pour se reconnecter en cas de rupture du lien Wi-Fi ou autre.
Je le fais démarrer au boot du routeur, après toutes les inits, rendant ainsi le dispositif totalement autonome.
L’ensemble est alimenté par un chargeur USB de téléphone et sa (très) faible consommation me permet de le laisser tourner toute la journée si je veux. La charge CPU n’excède pas quelques pourcents, et il reste environ 1/4 de la RAM dispo avec un historique possible de 100 spots.
Le seul inconvénient est la latence de l’afficheur LCD en lui-même rend le scrolling un peu chaotique si l’on veut faire défiler un long historique, mais il n’y a pas grand chose à y faire, sauf à utiliser un autre afficheur de type TFT ou OLED par exemple.
Je vais maintenant certainement améliorer un peu le programme pour pouvoir inclure également les annonces (ça ne coûte pas cher).
Il existe probablement bien d’autres applications et de fonctions liées à notre activité que ce routeur peut assurer à moindre coût. Si vous en menez une à son terme, n’hésitez pas à nous en faire part dans les commentaires.
