Choisir un master EtherCAT open source sous Linux embarqué

Un MainDevice en kernel module est out-of-tree : il se construit contre les sources du kernel de l’image et doit être reconstruit à chaque montée de version. Sous Yocto, cela signifie une recette de module liée à kernel-module-*, un chargement à déclarer, et une dépendance dure entre deux éléments qui évoluent à des rythmes différents.

En user space, le MainDevice est une bibliothèque ou une dépendance de l’application. Il ne connaît pas la version du kernel et ne se reconstruit pas quand elle change.

Le user space ne rend pas le système meilleur en temps réel, il rend la maintenance plus prévisible. Sur un produit maintenu dix ans, avec des correctifs de sécurité à livrer, la différence se paie à chaque montée de version.

L’argument classique contre le user space porte sur le trajet d’une trame entre la carte et l’application. Le chemin historique passe par une socket brute (AF_PACKET), et son coût se paie au retour du softirq vers le user space et à la sortie d’appel système.

Deux mécanismes plus récents du kernel réduisent ce trajet.

Ces mécanismes resserrent l’écart historique entre user space et kernel module, celui-là même qui justifiait le coût d’intégration d’un module out-of-tree.

Ils ne sont pas gratuits pour autant. XDP demande libxdp, libbpf et une configuration soignée, et surtout, en mode natif, un driver réseau qui le supporte, ce qui n’est pas le cas de beaucoup. Le mode générique fonctionne partout, mais repasse par le skb et perd l’essentiel du bénéfice.

À retenir pour le choix du matériel : la contrainte sur le contrôleur ne pèse pas que sur IgH et ses drivers natifs, elle revient dès qu’on veut AF_XDP en user space. Le chemin AF_PACKET, lui, reste disponible sur n’importe quelle carte.

Un MainDevice n’implémente pas tout EtherCAT, et le périmètre se vérifie à partir de la liste des SubDevices à piloter.

Le fonctionnement cyclique ne suffit pas : la configuration des SubDevices, la mise à jour de leur firmware et le tunnelage de protocoles passent par des mailbox protocols distincts.

Des bornes de liaison série, par exemple, se configurent par CoE : le débit, la parité et le format de trame sont des objets SDO. Sans CoE, elles restent inertes.

La vérification tient en trois gestes : lister les SubDevices retenus, relever pour chacun les mailbox protocols que sa mise en œuvre exige, puis confronter cette liste aux fonctions annoncées par chaque implémentation. Une fonction manquante se contourne rarement au niveau applicatif.

Un dernier point si des cartes spécifiques doivent être développées : la spécification EtherCAT s’obtient par l’adhésion à l’EtherCAT Technology Group, qui délivre aussi l’identifiant fabricant. L’adhésion comme l’identifiant sont gratuits, mais la spécification n’est accessible qu’à ce titre.

SOEM est une bibliothèque C en user space, éprouvée et largement déployée.

Intégration. Une recette à écrire, simple parce que sans dépendance au kernel : ni Buildroot ni les couches OpenEmbedded courantes ne l’empaquettent, seules les couches ROS le font. Depuis une application Rust, l’accès passe par FFI (Foreign Function Interface), donc par une couche unsafe à écrire et à maintenir, qui devient elle-même un composant du projet.

Licence. Elle a changé en cours de route. Les versions 1.x sont en GPLv2 avec une exception d’édition de liens, qui autorise la liaison avec du code propriétaire. La version 2.0 est en GPLv3 ou licence commerciale chez RT-Labs, sans cette exception. Pour un produit fermé, la version retenue détermine le modèle de licence.

L’architecture bloquante de SOEM impose par ailleurs une gestion manuelle de la mémoire et des verrous explicites.

IgH EtherCAT Master est implanté en kernel module, avec les meilleures caractéristiques temps réel des trois. Le code est sur GitLab, la documentation est publiée en PDF.

Intégration. C’est le plus coûteux, mais il est empaqueté : Buildroot fournit igh-ethercat, qui construit le module contre le kernel cible avec une option par driver natif, et OpenEmbedded a une recette équivalente dans meta-tanowrt. Le module se reconstruit à chaque montée de version du kernel.

IgH propose deux familles de drivers réseau. Les drivers natifs, pour des puces précises (Intel I210 à I226, e1000e, r8169, entre autres), pilotent la carte sans interruption et donnent les meilleures performances, mais ils suivent le kernel au même rythme que le module et contraignent le choix de la carte. Le driver générique fonctionne avec n’importe quelle carte gérée par Linux, au prix d’un passage par la pile réseau.

Avec un driver natif, l’image compte donc trois éléments couplés à valider ensemble : kernel, module et driver. Avec le driver générique, deux.

Licence. Les kernel modules sont en GPLv2, la bibliothèque user space en LGPLv2.1 : une application propriétaire peut s’y lier dynamiquement. La contrainte porte sur la maintenance du module, pas sur la diffusion du code applicatif.

EtherCrab est un MainDevice écrit en Rust, exécuté en user space, sans dépendance C ni kernel module, sous licence MIT ou Apache 2.0. L’API est documentée sur docs.rs.

Le développeur principal détaille plusieurs points de conception sur son blog.

Intégration. Elle n’a de sens que dans une application Rust. Le MainDevice y est une simple dépendance, déclarée dans Cargo.toml et compilée avec elle. Rien n’apparaît séparément dans l’image. Sous Yocto, Rust est pris en charge depuis la 3.4 : la classe cargo gère la compilation croisée, et cargo-bitbake génère une recette qui fige l’index des crates pour la reproductibilité. Les chemins io_uring et XDP décrits plus haut sont exposés en options de compilation, via des features Cargo.

Réserve. Le crate est en 0.x et son interface évolue encore. Sur la couverture fonctionnelle, il annonce CoE, l’autoconfiguration des SubDevices depuis leur EEPROM et les Distributed Clocks avec compensation de dérive ; EoE, FoE et SoE ne figurent pas dans la liste des fonctions annoncées.

La version se fige dans Cargo.toml, avec la possibilité de pointer une révision git ou un chemin local pour corriger un défaut sans attendre une publication, ce qui reste le meilleur recours face à une fonction manquante.

Ces réserves posées, je l’ai mis en œuvre chez plusieurs clients, sur des distributions construites avec Yocto.