Quel microcontrôleur doit être maître / esclave?


8

Je crée une alarme pour me réveiller le matin. Le système est composé de 3 sous-systèmes:

  1. (S1) Gestion des sept segments RVB. Composé de 5µC, un pour chaque chiffre et un pour ":". Le nombre élevé de µC est dû au fait que je n'utilise pas de CI pour les LED RGB, uniquement des transistors.
  2. (S2) Gestion des capteurs et des entrées. Un µC qui gère le capteur de distance pour l'alarme définie et l'heure actuelle; et commutateurs pour la configuration.
  3. (S3) Communication et fichier audio. Un µC qui communique avec un module Bluetooth dans UART pour un projet ultérieur, a obtenu un cristal RTC pour avoir une horloge précise et gérer la lecture audio. (Je n'ai pas encore travaillé sur l'audio)

Pendant l'exécution normale, S2 lit l'entrée et l'envoie à S3 pour traitement. S3 envoie ensuite à S1 ce qui doit s'afficher.

Je veux faire communiquer tous ces sous-systèmes ensemble, j'ai ensuite choisi d'utiliser le bus I2C. Mais voici ma question:

  • Quel µC doit être le maître?

D'une part, S3 est le centre du système mais d'autre part, S2 peut envoyer plus de messages que S3. C'est pourquoi je ne sais pas qui va être maître / esclave.

  • Existe-t-il une règle pour déterminer qui sera esclave / maître? Quelle question dois-je me poser pour faire le bon choix? (en général, pas pour ce système spécifique)

14
Pourquoi utilisez-vous 5 microcontrôleurs pour une horloge / alarme de base alors que certainement l'un ferait le travail?
Andy aka

2
Avoir un autre uC pour 'orchestrateur système' qui implémente le maître I2C. Ce n'est pas une remarque sarcastique, je le pense vraiment. Il vous offre une bonne séparation entre les périphériques et le contrôle, car vous ne semblez pas avoir peur des excès d'uC.
Neil_UK

1
@Andyaka Chaque chiffre a une couleur différente (3 * 5 PWM) et chaque segment doit être activé / désactivé sur GPIO. J'utilise MSP430 en µC avec seulement 20 broches et 4 PWM chacune. (J'en ai plus de 100 donc je dois utiliser le stock ^^ ')
M.Ferru

7
@Andyaka Il y a en fait une autre raison. Je suis un amateur à la sortie de l'école EE. Je veux apprendre à configurer une communication décente entre un système à plusieurs µC car je ne fais jamais de telles choses. Si je ne choisis qu'un µC (ce qui est bien sûr un meilleur choix), je n'apprendrai "rien de nouveau".
M.Ferru

2
@ M.Ferru Beaucoup de choses ont un impact sur ces choix. Une inquiétude concerne le degré d'incertitude et de risque pour les "inconnues" futures que je peux tolérer avant de devoir "refaire" complètement la conception. Un autre est le processus de synchronisation et le degré critique de certains. Par exemple, si j'ai besoin de prendre en charge de longs transferts avec des contraintes de temps serrées, ce seul fait peut compliquer une interface utilisateur qui fonctionne bien. Mais il s'agit d'écrire tous les détails que vous connaissez maintenant, ainsi que tout ce que vous pouvez en penser et de décider de la meilleure façon d'organiser ces détails.
jonk

Réponses:


7

Existe-t-il une règle pour déterminer qui sera [I 2 C] esclave / maître?

Oui. Seul un maître I 2 C peut démarrer une transmission. Un esclave I 2 C ne peut pas vous dire quelque chose, jusqu'à ce qu'il soit ensuite interrogé par le maître (sauf si vous ajoutez des signaux d'interruption supplémentaires, ce qui augmente la complexité globale du système).

Ignorant la fonction (rarement utilisée) d'un appareil pour basculer entre être un maître et un esclave, cela signifie que le maître I 2 C doit avoir une connaissance suffisante du système global , pour savoir comment communiquer avec tous les I 2 C esclaves sur ce bus.

Quelle question dois-je me poser pour faire le bon choix? (en général, pas pour ce système spécifique)

Pensez au MCU de votre système qui connaît:

  • plus sur l'état général du système, et peut donc décider quand envoyer des commandes I 2 C aux esclaves;
  • quelles commandes I 2 C doivent être envoyées à chaque esclave;
  • quelles données doivent être collectées auprès de chaque esclave I 2 C;
  • quels appareils I 2 C répondent purement aux commandes entrantes (cela s'appliquera à vos MCU "S1" - il semble clair qu'ils sont les plus adaptés pour être des esclaves);

Quel que soit le MCU qui sera le maître I 2 C, vous devez concevoir l'architecture globale du système et déterminer quelles commandes doivent être envoyées à chaque périphérique et à quelle vitesse les réponses doivent être reçues. Essayez de concevoir un système qui a un "maître" évident et connaît tous les états du système, et il peut alors aussi s'agir du périphérique maître I 2 C.

Tu as dit:

S3 est le centre du système mais d'autre part, S2 peut envoyer plus de messages que S3.

On ne sait pas qui envoie des messages « S2 » à . Doit-il envoyer activement des messages à quelqu'un ? Ou "S2" peut-il être interrogé par "S3" en tant que maître I 2 C, pour recevoir les informations de capteur et de commutateur collectées par "S2"? Si "S2" peut être interrogé par "S3", alors, sur la base de la description, il semble clair que "S3" MCU pourrait être le maître I 2 C.

Je suis prudent d'ajouter encore un autre MCU (appelons-le "S10") pour être le maître I 2 C. C'est parce qu'il semble qu'un MCU "S10" devrait faire beaucoup d'interrogations, juste pour rassembler la connaissance globale de l'état du système qui est déjà (?) Déjà connue par "S3". Cela semble être une duplication inutile.

Par conséquent, à moins que "S3" ne puisse pas faire le travail en raison de l'atteinte de ses limites d'espace RAM, d'espace Flash ou de cycles CPU, etc., il peut être moins compliqué de demander à "S3" de contrôler le système en le rendant maître I 2 C, plutôt que d'ajouter un contrôleur "S10" supplémentaire.

D'un autre côté, si cela ne vous dérange pas de la complexité supplémentaire, l'ajout d'un contrôleur global "S10" augmente la modularité (segmentation) du système, car "S3" ne fait que Bluetooth et audio - rien d'autre. Cela pourrait permettre une flexibilité supplémentaire pour ajouter de nouvelles fonctionnalités (imprévues) / MCU supplémentaires à l'avenir, sans avoir besoin de changer le code dans "S3".


1

S1 doit être un esclave I 2 C. Soit S2 soit S3 serait un choix judicieux pour un maître. Mais cela ne fait que reformuler ce qui a été mentionné dans la question initiale.

Souvent, le MCU qui gère la plus grande variété d'entrées est un bon candidat pour un maître. Dans votre cas, c'est soit le S2 (une variété de boutons utilisateur, RTC), soit le S3 (une variété de commandes du Bluetooth). Si vous ne pouvez pas décider lequel, alors vous pouvez obtenir un contrôleur plus grand et mettre les deux fonctionnalités S2 et S3 dans un MCU. Cette approche peut vous donner plus de flexibilité.


0

Chaque microcontrôleur de votre système peut être le maître. Cependant, certains d'entre eux conviennent davantage à cette fonction. Comme l'ont dit d'autres personnes, le microcontrôleur avec le plus d'informations devrait être le maître.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.