Considérations importantes sur le modèle de communication master-slave de votre système embarqué

Cela peut prendre quelques semaines ou quelques mois pour terminer un prototype fonctionnel d'un système embarqué. Il faut parfois passer des jours à travailler sur une seule partie du projet.

Alors, lorsque votre patron vous demande quotidiennement des mises à jour, cela peut être particulièrement distrayant et nuire à votre productivité.

Lorsque j'ai commencé mon entreprise de design, j'ai appris à ne pas répéter ces erreurs dans mon équipe.

À l'instar des êtres humains, il existe des systèmes embarqués de différentes formes et tailles, et surtout proposant différentes fonctionnalités et capacités.

En plus de répondre à un contrôleur situé plus haut dans la chaîne de commande, un système embarqué doit accomplir ses autres tâches efficacement.

Cela inclut la surveillance des entrées, le calcul et la conversion des valeurs. Il doit également fournir des mises à jour fiables ou des commandes de traitement.

Lorsqu'un système embarqué est constamment perturbé par les demandes d'un autre contrôleur, il est moins efficace. Dans certains cas, il peut même planter sans prévenir.

Comment fonctionnent les réseaux de communications master-slave des systèmes embarqués

Le moyen le plus simple pour les systèmes embarqués de communiquer entre eux consiste à utiliser une structure master-slave, ou maître-esclave.

Dans ce cas, un seul système embarqué est désigné comme maître et est chargé d'initier la communication avec les systèmes embarqués qui lui sont connectés.

La communication master-slave présente un modèle prévisible de transmission des messages dans l'interface de communication. Les contrôleurs esclaves ne sont pas autorisés à transmettre des paquets de données à moins que le contrôleur maître ne le leur demande.

L'un de mes derniers projets utilisant une configuration master-slave est un système de surveillance pour les machines de fabrication de caoutchouc.

Un contrôleur de surveillance des capteurs était placé sur chaque machine pour surveiller leurs cycles de fonctionnement à l'aide de divers capteurs. Un contrôleur maître était connecté à tous les contrôleurs de capteurs et utilisait la mémoire non volatile pour stocker les données recueillies.

Considérations importantes sur la conception d'un système embarqué master-slave

Aussi simple que cela puisse paraître, ne pas tenir compte des considérations de conception suivantes peut entraîner des problèmes après le déploiement.

1. Puissance de traitement des microcontrôleurs

Souvent, les contrôleurs maîtres et esclaves sont alimentés par des microcontrôleurs avec une puissance de traitement variable. Un contrôleur maître est souvent alimenté par un microcontrôleur plus puissant qu'un contrôleur esclave.

Les contrôleurs esclaves effectuent généralement des tâches spécifiques, comme la surveillance des entrées de capteurs ou le pilotage d'un moteur, il est donc logique de les équiper d'un microcontrôleur de gamme moyenne ou inférieure.

Les programmeurs qui écrivent du code pour le contrôleur maître doivent ne pas interrompre le programmateur esclave trop souvent avec des demandes de mise à jour de statut.

Comme ils ont une capacité de traitement limitée, l'interruption peut submerger le contrôleur esclave. Si un contrôleur esclave n'est pas conçu pour traiter un volume élevé de demandes, il peut subir un dépassement de stack ou de mémoire et peut tomber en panne.

Les contrôleurs maîtres et esclaves peuvent fonctionner à une vitesse très différente.

2. Limiter le nombre de contrôleurs esclaves

En théorie, vous pouvez relier votre contrôleur maître à autant de programmateurs esclaves que leurs normes d'interface de communication le permettent / qu'ils autorisent les normes d'interface de communication.

Par exemple, RS458 peut avoir jusqu'à 32 appareils connectés à une seule connexion. Cependant, en pratique, vous devez prendre en compte les effets qui relient un grand nombre de programmateurs esclaves sur un seul canal à la vitesse de récupération des informations.

Par exemple, un programmateur esclave met 10 millisecondes pour répondre à une demande. S'il y a 31 programmateurs esclaves, il faudra 310 millisecondes pour recevoir les mises à jour du même programmateur au cycle suivant.

Si le contrôleur maître exige que les mises à jour soient actualisées à une vitesse plus rapide, vous devrez limiter le nombre de programmateurs esclaves connectés à un seul canal.

3. Conception pour redondance

Les systèmes embarqués configurés de manière master-slave sont souvent connectés à l'aide d'un câble unique qui fait une boucle d'un contrôleur à l'autre.

Cette méthode de câblage multi-points est simple et économique, mais elle expose également l'ensemble du système à un risque en cas de rupture du câble. Par exemple, un câble qui se brise entre le cinquième et le sixième programmateur esclave réduit la communication du maître avec les cinq premiers contrôleurs esclaves.

Dans les applications critiques, les développeurs et les concepteurs de systèmes doivent envisager d'ajouter une connexion redondante du contrôleur maître au dernier contrôleur esclave dans la boucle comme sauvegarde. Si le contrôleur maître détecte une rupture potentielle du câble, il peut activer la connexion de secours pour rétablir les communications.

La redondance s'avère payante dans les applications critiques.

Peu importe si vous concevez un contrôleur maître ou esclave, il est important de choisir le bon microcontrôleur et les composants qui l'accompagnent. Les logiciels PCB comme Altium Designer^® et Altium Vault^® vous donnent accès à des bibliothèques de composants pour simplifier vos processus.

Si vous avez des doutes sur la mise en œuvre des communications master-slave ou maître-esclave, contactez l'un des experts d'Altium.