Projet Pi-Logger
Lors de la mise au point d’un système industriel, il est souvent nécessaire de surveiller les signaux de sortie d’un équipement.
Bien sûr l’oscilloscope et l’analyseur de trames sont indispensables pour l’analyse des signaux instantanés, mais lors des phases de validation d’un produit, il faut généralement faire des observations longues, sur plusieurs heures ou plusieurs jours. Je vous propose un petit outil prévu pour ce genre d’analyse.
Contexte
J’ai récemment dû vérifier le comportement des signaux de sortie d’une carte embarquée (un module à processeur i.MX6) qui pilote, par l’intermédiaires de relais, les pompes de traitement de piscines et de spas. Les signaux (des sorties sur GPIO) sont issus d’algorithmes d’automatisation du traitement, après analyse de divers senseurs (température, pH, ORP, taux de chlore, etc.).
Je souhaitais obtenir un suivi des signaux relativement précis (avec une résolution de l’ordre de la seconde), sur des durées longues (quelques semaines). Le fait que les signaux de sortie du module intégré soient aux niveaux électriques {0, +3.3V} m’a incité à les injecter dans un Raspberry Pi pour les enregistrer et les analyser ensuite.
Pour éviter d’enregistrer à chaque instant tous les signaux, j’ai écrit un petit programme qui ne les affiche (ou ne les stocke) que lors des changements d’état. Ce programme a été compilé et utilisé sur une distribution Raspbian du 18 avril dernier, il est disponible sous licence libre (GPL v.2).
Afin d’assurer la meilleure portabilité possible, je n’ai pas utilisé de bibliothèque comme WiringPi, mais simplement l’accès aux GPIO via les fichiers de /sys/class/gpio/
. Ainsi ce programme est utilisable sur tout système proposant des GPIO sous Linux quelque soit le processeur et le type d’OS.
Attention : les GPIO d’entrée du Raspberry Pi (et de la plupart des Single Board Computers du même genre) ne supportent que des tensions entre 0 et +3.3V. Ne leur soumettez pas directement des signaux {0, +5V} issus par exemple d’un Arduino.
Installation
J’ai pour habitude d’héberger mes projets libres, les exemples de mes article et les contenus de mes sesssions de formations sur Github. Suite aux événements des derniers mois, et à l’incertitude quant à l’avenir de cette plate-forme, j’ai décidé de tester un nouveau dépôt libre.
J’ai choisi Framagit, service proposé par l’association Framasoft que j’aime beaucoup et que je vous encourage à supporter.
Le projet se trouve ici https://framagit.org/cpb/pi-logger.
La compilation se fait simplement ainsi :
$ git clone https://framagit.org/cpb/pi-logger.git Clonage dans 'pi-logger'... remote: Counting objects: 40, done. remote: Compressing objects: 100% (39/39), done. remote: Total 40 (delta 16), reused 0 (delta 0) Dépaquetage des objets: 100% (40/40), fait. Vérification de la connectivité... fait. $ cd pi-logger $ make gcc -Wall -pthread -g -D_PI_LOGGER_VERSION="0.1.2" pi-logger.c -o pi-logger $
Dans le cas d’une cross-compilation, il suffit de renseigner le préfixe CROSS_COMPILE sur la ligne de commande de make
. Je pourrais fournir à l’avenir des recettes de compilation pour Buildroot et Yocto si des utilisateurs intéressés se manifestent.
Utilisation
Le programme est facile à utiliser, il suffit de le lancer en lui indiquant sur sa ligne de commande la liste des entrées GPIO à surveiller. A priori, il n’y a pas de limite au nombre de GPIO suivies, autre que celle des entrées disponibles sur la carte.
Il affiche alors sur sa sortie standard une table contenant une nouvelle ligne à chaque changement d’état. L’horodatage et les valeurs d’entrées de chaque GPIO sont indiqués dans des colonnes distinctes.
Si l’on souhaite récupérer le résultat dans un fichier, pour le traiter dans un tableur par exemple, l’option « -c
» permet d’obtenir une sortie au format CSV (Comma Separated Values) et l’option « -o
» envoie les données dans un fichier plutôt que sur sa sortie standard.
Enfin, il peut être nécessaire d’attendre un petit moment de stabilisation après chaque changement d’état, avant de lire les valeurs. Par exemple dans mon projet, les relais ont tendance à rebondir pendant une centaine de microsecondes. Pour palier ce défaut, l’option « -w
» permet d’indiquer un délai d’attente en microsecondes.
Voici un exemple d’exécution en surveillant trois sorties de mon système, reliées aux broches du Raspberry Pi 15, 16 et 18 (respectivement les GPIO 22, 23 et 24).
$ sudo ./pi-logger -w 1000 22 23 24 +----------+----+----+----+ | TIME | 22 | 23 | 24 | +----------+----+----+----+ | 13:30:01 | 0 | 1 | 0 | | 15:30:01 | 0 | 0 | 0 | | 00:30:00 | 1 | 0 | 0 | | 00:40:11 | 0 | 0 | 0 | | 04:00:01 | 0 | 0 | 1 | | 05:11:38 | 0 | 1 | 1 | | 05:12:52 | 0 | 0 | 1 | | 06:00:01 | 0 | 0 | 0 | (Ctrl-C) $
Voici un autre exemple d’exécution où les données sont stockées directment dans un fichier, en utilisant un format CSV :
$ sudo ./pi-logger -w 1000 22 23 24 -c -o datalog.csv ^C $ cat datalog.t.csv TIME,22,23,24, 08:14:31:1,0,0, 08:16:02:0,0,0, 11:10:01:0,0,1, 11:21:01:0,0,0 13:47:56,0,1,0, $
Conclusion
Ce petit outil m’est très utile pour assurer le monitoring de mon système embarqué. Je serais enchanté qu’il puisse servir à d’autres.
Il est bien adapté à des changements d’états relativement lents (quelques centaines de microsecondes ou quelques millisecondes au minimum), et ne prétend pas pouvoir analyser des signaux à fréquence élevée.
Toutes les suggestions, remarques et retours d’utilisation sont les bienvenus !
Bonjour,
Est-ce que tu as rencontré des problèmes de corruption dsur le long terme es fichiers sur la carte SD de la raspberry pi ?
Je me suis pour ma part résigné à reflasher la carte SD tous les 6 mois après avoir essayé plusieurs choses (rpi sur onduleur pour éviter les coupures intempestives, limitation de l’écriture des logs, …) sans succès.
Je n’ai pour le moment pas trouvé de SBC capable de tourner avec une distrib « facile » (du genre Raspbian) en RAM pour éviter ce genre de mésaventure même s’il y a eu une tentative avec le projet IPE de NutCom qui semble mort…
Bonjour Manu,
Je n’utilise de distribution (comme Raspbian) que pour les systèmes que je garde sous mon contrôle (alimentation de labo, shutdown propre, pas d’écritures intensives sur la flash, etc.).
C’est le cas pour le système mentionné dans cet article.
Je n’hésite pas à reflasher la distribution assez régulièrement (une à deux fois par an environ). J’ai fait quelques essais pour renforcer une distribution Raspbian (voir cet article) mais ça demande beaucoup de boulot.
Dès que je dois installer un SBC (Raspberry Pi ou autre) qui n’est plus sous mon contrôle (déployé chez un client, installé pour une expérimentation « dans la nature »), je préfère construire mon propre système avec un outil comme Buildroot ou Yocto afin de m’assurer :
Ce n’est pas aussi facile d’accès que d’installer une distribution toute prête, mais ça permet d’avoir un système résistant dans le temps.
C’est ce qu’il me semblait : pas de raccourci, il faut passer par la manière dure…
J’ai pour ma part une raspbian faisant tourner un système domotique gérant la maison (chauffage/alarme et stats température etc…), basé sur Domoticz… sur un PI3 depuis presque 2 ans.
Le première carte a duré moins d’un an, mais en 9/10 mois les perfs devenaient déjà alarmantes (une flash qui s’use, c’est des temps de cycle d’erase secteur qui passent du typique au max, annonçant la fin!).
Avec une nouvelle (gamme indus Kingston, même si chez eux c’est surtout les plages de températures qui étaient visé j’espérais au moins un wear levelling statique correct), cela tourne depuis plus d’un an sans perte notable de perfs, mais avec cependant qq améliorations:
Logs en tmpfs avec ceux qui font rotation plus régulièrement effacés, les autres (ceux tout le temps ouverts par le processus mais sans rotate) le sont chaque semaine avec un « truncate -s 0 Fichier.log » via un cron afin de ne pas exploser le tmpfs.
Et la grosse erreur initiale: Le FTP qui reçoit les captures des caméras (et les envoie par tranche de 10s, compressés/chiffrés, à un compte mail externe avant de les effacer) est lui aussi passé sur un tmpfs. Rien de tel pour tuer un uSD gamme grand public (et son wear levelling dynamique de base) très vite.
Pour info, dans les projets embarqués on log car c’est utile au debug (+ zone de « flight recorder » en DDR configurée pour passer en auto-refresh pendant la phase de reset, car on n’a pas tt le temps/possibilité d’écrire un log avant le crash non contrôlé), les média flash derrière contrôleur sont basés sur les mêmes contrôleurs que des SD/clef USB grand public, mais avec une gestion plus proche de que l’on retrouve en grand public sur les stockages internes… et sans même utiliser de la coûteuse SLC on y arrive.
Les compteurs de cycles d’erase tenus par ces controleurs de stockage (présentant uen flash comme un « disque » et ses LBA) sont en effet dans une ram controleur.
=> Aucun bénéfice, vu les temps uptime/alimenté, à faire dans un cadre exctractible une gestion de wear levelling chiadée car aucune tâche de fond possible hors période active: Le media sera débranché!
Dommage que les PI ne puissent accepter des eUSB… j’ai plein de samples en stock!
Je ne connaissais pas Framagit !
Je pense que c’est une alternative intéressante, j’aime bien ce que fait Framasoft.