Bonjour,
Dans l’article de ce jour, j’évoque quelques considérations concernant la mise en œuvre de la messagerie Hilscher, les modes Client / Serveur, le routage des messages…
Le document netX Dual-Port Memory Interface (DPM) explique que la messagerie peut être utilisée selon deux modes, en mode Client ou en mode Serveur.
Lorsque l’application envoie une requête de configuration ou une commande de lecture / écriture de données dans un esclave par exemple, elle utilise le mode Client.
Dans ce mode le client, l’application, envoie une requête et reçoit une confirmation qui contient la réponse de la pile de protocole, un code d’état avec les données éventuelles.
Cependant, il est également possible que l’application soit intéressée par des indications en provenance de la pile de protocole. Dans ce cas, elle doit répondre à ces indications en fournissant une réponse, éventuellement des données, et travaille ainsi en mode Serveur.
Par exemple, si l’application utilise une carte cifX exécutant un firmware CANopen esclave, configurée pour gérer un dictionnaire d’objets étendu, l’application va recevoir des indications à chaque requête de lecture / écriture via SDO et devra répondre à ces indications par des réponses, négatives si l’objet n’existe pas ou positives le cas échéant.
Lorsque l’application travaille uniquement en mode Client, elle ne va recevoir que les réponses à ses requêtes.
La gestion des boites aux lettres est très simple :
- élaboration de la requête,
- envoi dans la BAL d’émission,
- attente de la réponse,
- réception et analyse de la réponse.
C’est ce que l’on a déjà eu l’occasion de réaliser à plusieurs reprises pour la configuration des firmwares esclaves mais également ici par exemple.
En mode serveur uniquement, on va devoir soit scruter cycliquement la BAL de réception, soit enregistrer une fonction de rappel qui sera donc appelée lorsqu’un message arrive, et traiter dans un sélecteur chaque message arrivant en fonction du code de commande ou d’indication, puis poster dans la BAL d’émission la réponse.
Bien évidemment, il est possible que l’application soit à la fois Client et Serveur, cela ne fait que compliquer la situation et il est nécessaire de gérer les accès concurrents aux BAL. L’exemple cité précédemment est de ce type car il émet des requêtes pour lire les données et attend en retour les réponses à ses requêtes de lecture mais aussi les indications de déconnexion des esclaves.
Si en phase de configuration et pour des cas simples on peut envisager un traitement séquentiel des messages, en régime établi et dans un cas concret les messages fusent de toutes parts et il est nécessaire de mettre en place une architecture permettant de gérer ce flux d’événements.
Ces messages, réponses à des requêtes multiples, indications d’alarmes, de diagnostic, de lecture / écriture, etc. peuvent être soit gérées par un process monolithique, soit par des tâches dédiées à tel ou tel traitement.
C’est ici qu’interviennent les données de routage qui figurent dans l’en-tête des messages Hilscher. Voir la documentation.
Ainsi, une tâche de routage peut recevoir les messages et les router vers les tâches chargées de leur traitement.
Pour tout vous dire, c’est le mécanisme à l’œuvre de l’autre côté de la DPM.
Côté firmware, les tâches communiquent entre elles via des queues de messages. C’est très commun dans ce type d’application, la communication, et ça se fait relativement facilement, les queues font partie de la boite à outils de tout informaticien qui se respecte.
Côté application, on peut essayer de faire sans les queues. Dans ce cas, si une tâche est réceptionnaire de messages successifs qu’elle ne peut traiter immédiatement, la BAL de réception est occupée et ne peut donc être utilisée pour transmettre d’autres messages. Ce n’est pas bon pour la performance et dans les cas extrêmes les queues côté firmware sont saturées et il y a perte de paquets.
Cependant, il faut considérer que le flux de messages traités par le firmware est bien plus intense que celui à gérer au niveau applicatif. En effet, alors que l’application ne doit gérer que des communications acycliques, le firmware a en charge la communication cyclique avec tous les esclaves.
Il faut donc garder tête froide et ne pas se livrer à une optimisation trop précoce qui compliquerait une architecture plus qu’il serait souhaitable.
Ainsi, l’application de test / exemple livrée avec le pilote cifX pour Siemens WinAC RTX®, cf. la série d’articles relative, utilise une seule tâche, le bloc d’organisation OB1, et les messages sont gérés par des blocs fonctions implémentant des machines à états.
Cordialement,
Stéphane