😷 👃 📽️ Chien de garde basé sur Arduino Nano 👩🏻‍✈️ 👩🏻‍🚀 🎟️

Watchdog est un appareil conçu pour détecter et résoudre les problèmes matériels. Habituellement, un temporisateur est utilisé pour cela, dont un redémarrage périodique empêche l'envoi d'un signal au redémarrage.

Le serveur principal sur Gentoo est utilisé par moi principalement pour des expériences, cependant, il exécute un certain nombre de services qui, si possible, devraient être disponibles sans interruption. Malheureusement, les conséquences de certaines expériences conduisent à la panique du noyau, à 100% de charge CPU et à d'autres problèmes au moment le plus inopportun. L'idée d'ajouter un chien de garde a donc longtemps retenu l'attention et s'est finalement concrétisée dans cet appareil.

Après une inspection minutieuse de ce qui était disponible et une évaluation du temps disponible, le chien de garde assemblé sur la base de l'Arduino Nano était la meilleure option. Une liste d'exigences est apparue autour de la même:

Démarrage et arrêt du démon pour travailler avec une minuterie, un outil de système d'exploitation normal (OpenRC).
Propre chien de garde sur l'appareil, dans ATmega, vous devez l'utiliser.
Le journal des événements sur l'appareil pour fixer le redémarrage et la minuterie.
Synchronisez l'heure de l'appareil avec l'hôte pour enregistrer l'heure correcte dans le journal.
Recevoir et afficher l'état de l'appareil et ses entrées de journal.
Effacer le journal et réinitialiser l'appareil à son état d'origine.

Ainsi, le «microscope» a été retrouvé, le «clou» est marqué… on peut marteler.

Matériel

La base de l'appareil était le clone chinois Arduino Nano, fabriqué sur la base de la puce CH340. Les nouveaux noyaux Linux (testés depuis la 3.16) ont un pilote approprié, donc le périphérique est facilement détecté comme un port série USB.

Redémarrage indésirable Arduino

Chaque fois que le terminal est connecté, l'Arduino redémarre. La raison en est que le terminal envoie un signal DTR (Data Terminal Ready), ce qui provoque le redémarrage de l'appareil. Ainsi, l'IDE Arduino met l'appareil en mode de chargement des croquis.

Il existe plusieurs options pour résoudre le problème, mais une seule s'est avérée fonctionner - il est nécessaire d'installer un électrolyte de 10µF (C1 dans le diagramme ci-dessous) entre les contacts RST et GND. Malheureusement, cela bloque également le téléchargement de croquis sur l'appareil.

En conséquence - le schéma est le suivant:

Dessiné à l'aide de KiCad

Explications du schéma

R1 — , PC817: (5V — 1.2V / 0.02A) = 190Ω, 180Ω.
U2 — Arduino PC. , ( USB ), .
JP1 — , . .
1 — , DTR.
MB_RST, MB_GND — RESET , RST (GND). , .
BTN_RST, BTN_GND — , , , , .

Boucle de démarrage (redémarrage cyclique) lors de l'utilisation de WDT

Les microcontrôleurs ATmega ont un mécanisme de réinitialisation WDT (WatchDog Timer) intégré. Cependant, toutes les tentatives d'utilisation de cette fonction ont conduit à une boucle de démarrage, qui ne pouvait être interrompue qu'en coupant l'alimentation.

Peu de recherches ont révélé que les chargeurs de démarrage de la plupart des clones Arduino ne prennent pas en charge WDT. Heureusement, ce problème a été résolu dans le chargeur de démarrage alternatif Optiboot .

Afin de flasher le chargeur de démarrage, vous avez besoin d'un programmeur qui peut fonctionner en utilisant le protocole SPI, il est également souhaitable que l'IDE Arduino connaisse cet appareil «en personne». Dans ce cas, un autre Arduino est idéal.

Si nous prenons Arduino UNO, en tant que programmeur, et la dernière version d'Arduino IDE v1.6.5, alors l'algorithme sera le suivant:

boards-1.6.txt optiboot hardware/arduino/avr/boards.txt Arduino IDE.
Arduino Uno, File → Examples → ArduinoISP.

Arduino Nano :

Arduino Uno ()

Arduino Nano (ICSP )

5V → Vcc

GND → GND

D11 → MOSI

D12 → MISO

D13 → SCK

D10 → Reset

Pin1 (MISO) ← D12	Pin2 (Vcc) ← 5V
Pin3 (SCK) ← D13	Pin4 (MOSI) ← D11
Pin5 (Reset) ← D10	Pin6 (GND) ← GND

Dans l'IDE Arduino, dans le menu Outils, définissez les paramètres comme dans la capture d'écran:
Sélectionnez l'élément de menu Outils → Graver Bootloader et assurez-vous que le processus s'est terminé sans erreur.

Après cette procédure, vous devez télécharger des croquis à Arduino Nano en choisissant les mêmes paramètres - Conseil : Optiboot sur 32 broches CPUs, Processeur : ATMEGA328P, CPU Speed : 16MHz.

Soudure

Ensuite, vous devez tout souder pour qu'il ressemble à une seule pièce.

Ici, une prise USB était nécessaire en raison du fait que j'ai une carte mère mini-ITX avec un seul connecteur pour une paire d'USB2.0, qui sont nécessaires sur le panneau avant, et il n'y avait rien à connecter au pad USB3.0. Si possible, ces appareils doivent être connectés directement à la carte mère afin que les fils ne dépassent pas.

La soudure, en règle générale, ne pose pas de problème, mais dans ce cas, une planche à pain est utilisée, et cela a ses propres spécificités.

Comment souder des pistes sur une planche à pain

( , ). .

:

Résultat:

il peut sembler que certains contacts sont mal soudés, mais ce n'est qu'un flux. La consommation de soudure sur la planche à pain est assez importante, donc tout ce qui est possible est enduit d'un flux ici. En fait, c'est un bon exemple de la façon dont vous n'avez pas besoin de quitter le produit après le soudage. Le flux doit être lavé, sinon il peut y avoir des problèmes de corrosion des composés. Je vais ajouter et aller me laver ... C'est mieux:

Partie logiciel

Objectivement parlant, le code de ce projet n'a pas un intérêt particulier. Les introductions sont loin d'être extrêmes, et l'architecture est décrite en une phrase: envoyer une commande - attendre une réponse. Par souci d'ordre, je décrirai ici les fonctionnalités principales et m'attarderai brièvement sur les points les plus intéressants, de mon point de vue.

Tout le code est publié sur GitHub, donc si vous êtes familier avec Bash et C / C ++ (dans le contexte des croquis Arduino), la lecture à ce stade peut être terminée. Si vous êtes intéressé, le résultat final peut être trouvé ici .

Connexion chien de garde

Lorsque vous connectez le chien de garde, un fichier de périphérique est créé contenant le numéro de série. Si le système possède d'autres périphériques ttyUSB (dans mon cas, un modem), il y a un problème de numérotation. Pour identifier de manière unique le périphérique, vous devez créer un lien symbolique avec un nom unique. Pour cela, udev est conçu, qui existe probablement déjà dans le système.

Vous devez d'abord trouver visuellement le chien de garde connecté, par exemple, en consultant le fichier journal du système. Ensuite, en remplaçant / dev / ttyUSB0 par le périphérique souhaité, écrivez dans le terminal:

udevadm info -a -p "$(udevadm info -q path -n /dev/ttyUSB0)"

Exemple de sortie

  looking at device '/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4:1.0/ttyUSB0/tty/ttyUSB0':
    KERNEL=="ttyUSB0"
    SUBSYSTEM=="tty"
    ...
    
  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4:1.0/ttyUSB0':
    KERNELS=="ttyUSB0"
    SUBSYSTEMS=="usb-serial"
    DRIVERS=="ch341-uart"
    ...
    
  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4:1.0':
    ...
    
  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4':
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{idVendor}=="1a86"
    ATTRS{idProduct}=="7523"
    ATTRS{product}=="USB2.0-Serial"
    ...

Dans ce cas, la règle ressemblera à ceci:

ACTION=="add", KERNEL=="ttyUSB[0-9]*", SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyrst-watchdog"

Vous devez le placer dans un fichier séparé dans le répertoire /etc/udev/rules.d , par exemple, 51-ttyrst-watchdog.rules et dire à udev de recharger les règles:

udevadm control --reload-rules

À partir de ce moment, lors de la connexion du chien de garde, un lien / dev / ttyrst- watchdog sera créé sur le périphérique souhaité, qui sera utilisé plus tard.

Script bash (ttyrst-watchdog.sh)

La communication avec le chien de garde s'effectue à une vitesse de 9600 bauds. Arduino fonctionne sans problème avec les terminaux à haute vitesse, mais les commandes pour travailler avec du texte (chat, écho, etc.) ne reçoivent et n'envoient que des ordures. Il est possible que ce soit une caractéristique de ma seule copie de l'Arduino Nano.

Pour le cycle de redémarrage du minuteur principal et pour les fonctions de ligne de commande, un script est utilisé. La raison en est que les deux composants utilisent une ressource commune - le fichier de périphérique, et il est nécessaire de lui fournir un accès synchrone.

La synchronisation consiste essentiellement en une boucle d'attente:

while fuser ${DEVICE} >/dev/null 2>&1; do true; done

et capturer l'appareil pendant le temps requis:

cat <${DEVICE}

De toute évidence, un tel régime est soumis à une condition de concurrence. Vous pouvez gérer cela de manière adulte (par exemple, pour organiser une file d'attente de messages), mais dans ce cas, il suffit de définir correctement les délais afin de garantir un résultat dans un délai acceptable. En fait, l'ensemble du script fonctionne avec des délais d'attente.

La diabolisation (exécutée en arrière-plan) est effectuée à l'aide du package OpenRC. Il est supposé que ce script se trouve dans le fichier /usr/local/bin/ttyrst-watchdog.sh et que le script OpenRC se trouve dans /etc/init.d/ttyrst-watchdog .

Lorsque le démon s'arrête, la désactivation correcte du chien de garde est requise. Pour ce faire, le script définit le gestionnaire de signal qui doit être terminé:

trap deactivate SIGINT SIGTERM

Et ici, un problème surgit - OpenRC ne peut pas arrêter le démon, ou plutôt, mais pas souvent.

Le fait est que la commande kill envoie un signal au script et que le programme sleep, qui est utilisé pour suspendre le script, est exécuté dans un autre processus et ne reçoit pas le signal. Par conséquent, la fonction de désactivation n'est lancée qu'après la fin du sommeil, ce qui est trop long.

La solution consiste à démarrer le sommeil en arrière-plan et à attendre la fin du processus dans le script:

sleep ${SLEEP_TIME} & wait $!  #  $!  ID

Constantes de base:

WATCHDOG_ACTIVE - YES ou NO, respectivement, envoient un signal pour redémarrer lorsque le temporisateur est déclenché ou non.
WATCHDOG_TIMER - temps en secondes pour lequel la minuterie est réglée.
SLEEP_TIME - temps en secondes après lequel le temporisateur doit être redémarré. Il doit être beaucoup plus petit que WATCHDOG_TIMER, mais pas très petit, afin de ne pas créer de charge excessive sur le système et l'appareil. Aux délais d'attente actuels, un minimum raisonnable est d'environ 5 secondes.
DEFAULT_LOG_LINES - le nombre d'entrées de journal de périphérique récentes retournées par la commande de journal par défaut.

Commandes de script:

démarrer- début du cycle de redémarrage de la minuterie principale. Vous pouvez ajouter un code de vérification supplémentaire à la fonction is_alive, par exemple, pour vérifier la possibilité de se connecter via ssh.
état - affiche l'état de l'appareil.
reset - réinitialisation de l'EEPROM (données de journal) et redémarrage de l'appareil pour restaurer le chien de garde à son état d'origine.
log <nombre d'entrées> - affiche le nombre spécifié d'entrées de journal récentes.

Croquis Arduino (ttyrst-watchdog.ino)

Pour compiler avec succès l'esquisse, vous avez besoin d'une bibliothèque de temps tierce , nécessaire à la synchronisation de l'heure.

Un croquis se compose de deux fichiers. Cela est dû au fait que l'IDE Arduino n'accepte pas les structures (struct) déclarées dans le fichier principal, elles doivent être déplacées vers un fichier d'en-tête externe. De plus, pour déclarer une structure, le mot-clé typedef n'est pas nécessaire, il est probablement même dangereux ... après avoir vérifié les options standard, je n'ai pas trouvé la syntaxe appropriée. Le reste est du C ++ plus ou moins standard.

Les fonctions wdt_enable et wdt_reset fonctionnent avec le chien de garde intégré dans le microcontrôleur. Après avoir initialisé le WDT, la principale chose à retenir est de le réinitialiser dans la boucle principale et à l'intérieur des boucles de toutes les opérations longues.

Les entrées de journal sont écrites dans la mémoire EEPROM non volatile, sa taille disponible peut être spécifiée dans logrecord.h, dans ce cas, il est 1024. Le journal est fait sous forme d'anneau, le séparateur est une structure avec des valeurs nulles. Le nombre maximum d'entrées pour 1 Kio EEPROM est de 203.

Un enregistrement sur le chargement de l'appareil ne parvient au journal qu'après synchronisation de l'heure. La synchronisation est effectuée en même temps que le temporisateur est redémarré et avant l'exécution de toute commande lors de l'initialisation du périphérique. Sinon, il ne sera pas possible de comparer l'heure correcte avec cet événement, et les informations sur les redémarrages des périphériques, isolément du démon de travail, ne sont pas très intéressantes.

C'est tout, merci d'avoir regardé!

Les fichiers source du projet sont situés sur GitHub

Chien de garde basé sur Arduino Nano