Réponses:
Disposition du moyeu du capteur
Dans ce scénario, il y a deux bus I²C. Appelons-les bus local et bus principal . Le but du bus local est de connecter un tas de capteurs à un microcontrôleur (μC). Le μC a pour but d'interroger les capteurs, d'en agréger les informations et de détecter certains événements. Un μC dans un tel rôle est appelé concentrateur de capteurs . Le concentrateur de capteurs n'est pas responsable des fonctions d'ordre supérieur; il y a un processeur principal puissant pour cela. Le bus principal relie le concentrateur de capteurs au processeur principal. Ainsi, le concentrateur de capteurs μC est un maître sur le bus local I²C et un esclave sur le bus principal I²C.
SPI et I²C
Le PIC lié dans le message d'origine ne partage pas les broches entre SPI et I²C. Cependant, il existe d'autres PIC qui utilisent les mêmes broches pour le matériel SPI et I²C, car les deux sont implémentés avec le même périphérique MSSP. Si un PIC a deux périphériques MSSP séparés, alors l'un peut être utilisé pour le matériel SPI, tandis que l'autre est utilisé pour le matériel I²C.
Une raison très courante d'avoir besoin de plusieurs bus est d'avoir des périphériques qui fonctionnent à des vitesses différentes. À l'origine, I²C fonctionnait à un maximum de 100 kHz. Plus tard, la vitesse a été augmentée à un maximum de 400 kHz, et encore plus tard, à 1 MHz et plus.
Le problème est que, puisque l'adresse de chaque appareil est intégrée dans le protocole I²C, alors si vous avez des appareils avec des vitesses différentes sur le même bus, disons 100 kHz et 400 kHz, vous devez toujours exécuter le bus à la vitesse la plus basse commune à tous les appareils sur le même bus (100 kHz dans ce cas).
Si vous exécutez le bus à une vitesse plus élevée (400 kHz), il est évident que le périphérique à basse vitesse ne fonctionnerait pas correctement, et il pourrait même interpréter l'adresse du périphérique à grande vitesse comme la sienne, provoquant l'échec du périphérique à 400 kHz comme bien. Mais même si vous exécutiez initialement le bus à 100 kHz, puis tentiez d'accélérer le bus à 400 kHz après avoir adressé une puce à vitesse plus élevée, il serait possible (bien que probablement peu probable) que la puce à vitesse inférieure interprète l'une des les paquets de données haute vitesse incorrectement comme son adresse, et donc gâcher la communication sur le bus. Dans les deux cas, à la fin de l'échange avec le périphérique 400 kHz, le périphérique 100 kHz serait probablement dans un état inconnu.
Il est donc plus efficace, si vous avez des appareils fonctionnant à des vitesses différentes et que vous avez plusieurs ports I²C et vous avez les broches de rechange pour permettre un tel luxe, d'avoir un I²C disons pour les appareils à 100 kHz, un autre pour les appareils à 400 kHz et un autre pour les appareils à 1 MHz, selon vos besoins.
Ce n'est pas un problème avec SPI car chaque périphérique est activé (adressé) dans le matériel par une ligne de sélection de puce distincte. Ainsi, la vitesse d'horloge peut être adaptée à la vitesse de la puce sélectionnée (10 MHz, 20 MHz, peu importe) sans avoir aucun effet sur les autres puces du même bus, car elles ne sont pas activées.
Il peut également vous permettre de prendre en charge deux appareils avec la même adresse. Oui, la plupart des appareils vous permettent de sélectionner peut-être les deux derniers bits de leur adresse avec des sangles. Récemment, j'ai dû prendre en charge 4 appareils qui chacun ne vous ont permis de définir le LSB de leur adresse qu'avec une résistance. Avoir deux ports signifie aucun coût supplémentaire pour moi.
Peut-être que je veux que l'un soit le maître d'un tas de périphériques et présente l'autre comme le port esclave, donc mon maître n'a pas à attendre pour saisir le bus pour me donner une commande pendant que j'interroge un capteur de température pour le 10 000e temps.
Il semble y avoir un tas d'autres bonnes réponses dans ce fil, en ajoutant juste mes 2 cents.
La vitesse.
Si vous devez avoir besoin d'accéder à deux appareils I2C en même temps, vous pourriez avoir un conflit important. Ou, l'un devrait attendre l'autre.
Deuxièmement, I²C peut être utilisé pour obtenir plus de bande passante (vous pouvez recevoir ou envoyer deux octets en même temps).
Si vous disposez d'un ADC qui fonctionne en continu, un I²C est occupé en permanence.
Changer d'adresse prend un certain temps aussi, donc dans certains cas - vous pouvez utiliser deux ports pour deux appareils et éviter les changements d'adresse pour gagner du temps.
D'autres ont mentionné plusieurs raisons de le faire, j'en ajouterai une:
Vous avez obtenu un tas de périphériques I2C 5V et un tas de périphériques I2C 3V3.
Par exemple, j'ai un micro 3,3V qui a deux ports I2C, un tolérant 5V, l'autre 3V3 seulement.