Je crée une alarme pour me réveiller le matin. Le système est composé de 3 sous-systèmes:
- (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.
- (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.
- (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)
Réponses:
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.
Pensez au MCU de votre système qui connaît:
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:
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".
la source
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é.
la source
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.
la source