Verwendung von I2C- und SPI-Kommunikation auf denselben Takt- und Datenleitungen

Ich glaube nicht. Eine vereinfachte gemeinsame Nutzung der Takt- und Datenleitungen zwischen SPI- und I ² C-Geräten sieht nicht nach einer guten Idee aus. Eine solche gemeinsame Nutzung kann einen Fehlermodus einführen, der die SPI-Kommunikation beschädigen kann.

Stellen Sie sich vor, dass MOSI/SDA und SCLK/SCK gemeinsam genutzt werden. Wir kommunizieren mit dem SPI-Gerät. Die I ² C-Slave-Geräte „sehen“ auch die Uhr und die Daten. ^{Es ist möglich, dass eine zufällige Kombination von Bits in den SPI-Daten für das I 2} C-Gerät wie eine Startbedingung und eine Slave-Adresse aussieht . Das I ² C-Slave-Gerät interpretiert dies als Beginn einer I ² C-Lesetransaktion, beginnt mit der Übertragung, zieht den MOSI/SDA auf Low. Dies würde die SPI-Kommunikation beschädigen.

Was kann man also tun. Sie haben ein SPI-Gerät, das eine Hochgeschwindigkeitskommunikation erfordert, und viele I ² C-Geräte, die mit einer relativ langsamen Kommunikation auskommen. Eine Situation wie Ihre ist keine Seltenheit. Betrachten Sie diese:

• Verwenden Sie das Hardware-Peripheriegerät (MSSP im PIC) für SPI. Bit-Bang I ² C auf einem Paar separater digitaler I/O-Pins.
• Verwenden Sie MSSP für die SPI-Kommunikation. Verbinden Sie die I ² C-Geräte über eine SPI-zu-I ² C-Brücke (SPI-Slave, I ² C-Master) .
• Verwenden Sie den MSSP für beide Busse. Setzen Sie die I ² C-Geräte auf einen eigenen Zweig, der über einen Schalter verfügt, der die I ² C-Geräte während der SPI-Kommunikation vom Bus trennen kann.
• Suchen Sie nach einem Bild mit 2x MSSP-Peripheriegeräten.

Bearbeiten:
Das Thema der Verwendung desselben MSSP für SPI und I ² C ist im Laufe der Jahre einige Male in den Foren aufgetaucht: CCS-Forum 2003 , PicList 2005 (solide Diskussion) , Microchips eigenes Forum 2012 , EE.SE 2012

Es ist möglich, I2C- und SPI-Pins gemeinsam zu nutzen, wenn Code, der jede Schnittstelle verwendet, garantieren kann, dass Geräte, die die andere verwenden, niemals eine Impulsfolge sehen, die sie veranlassen würde, Maßnahmen zu ergreifen oder Daten auszugeben. Um zu vermeiden, dass eine Impulsfolge mit einer I2C-Adressierungsfolge verwechselt wird, sollte man sicherstellen, dass es niemals acht aufeinanderfolgende Low-High-Low-Übergänge auf der I2C-Taktleitung gibt, in denen sich der Zustand der I2C-Datenleitung nicht ändert. Bei Verwendung eines typischen SPI-Masters und der Verkabelung von CLK mit SCK und MOSI oder MISO mit SDA kann eine solche Garantie nicht erfüllt werden, da sich Uhr und Daten ungefähr gleichzeitig ändern würden und wie das I2C-Gerät sie interpretiert, davon abhängen würde, welches Signal es zuerst geändert hat .

Wenn die Hardware jedoch ausreichend konfigurierbar ist, um CLK mit SDA und MOSI mit SCK zu verbinden, könnten die Dinge bei einer typischen SPI-Implementierung sicher funktionieren, vorausgesetzt, man vermeidet I2C-Adressen, die nur Nullen oder nur Einsen enthalten, da dies für MOSI unmöglich wäre von niedrig nach hoch und dann mehr als einmal (viel weniger achtmal) von hoch nach niedrig gehen, ohne zwischengeschalteten Übergang auf CLK.

Ein Vorbehalt besteht darin, dass einige Geräte versuchen, die angeschlossene Schnittstelle "automatisch zu erkennen", und einige automatische Erkennungsmethoden können Signalsequenzen, die nicht in einer Schnittstelle definiert sind, als Hinweis darauf betrachten, dass sie eine andere Schnittstelle verwenden sollten. Es sollte für Geräte möglich sein, Schnittstellen durch Strapping ohne eine solche falsche Erkennung automatisch auszuwählen, wenn einige Schnittstellen, die eine Teilmenge der Drähte verwenden, erfordern, dass andere Drähte zusammengebunden werden (z. B. für ein Gerät, das SPI und I2C unterstützt, Verkabelung sowohl /CS als auch CLK zu SDA und MOSI zu SCK), aber viele Geräte verwenden grobe und unzuverlässige Erkennungsmethoden, die verheerende Folgen haben können, selbst wenn sie mit anderen Geräten des gleichen Typs verwendet werden .

Ich glaube, die unten gezeigte Schaltung wird das erreichen, was Sie brauchen. Ein I2C-Gerät wird zusammen mit zwei SPI-Geräten gezeigt. Die Schaltung kann einfach auf eine beliebige Anzahl von I2C- oder SPI-Geräten erweitert werden. Die erforderlichen zusätzlichen Logikgatter werden von allen Geräten geteilt; Es sind keine Logikgatter pro Gerät erforderlich, wodurch die Anzahl der Teile niedrig gehalten wird. Es wird nur ein zusätzliches Kabel über den maximal vier (plus SPI-Chip-Selects) benötigt, die für die Standard-I2C/SPI-Schnittstellen benötigt werden.

Auf dem PIC18F25K80 befinden sich SCL (I2C-Takt) und SCLK (SPI-Takt) auf demselben Pin und SDA (I2C-Daten) und SDI (SPI-Dateneingang) auf demselben Pin. SDO (SPI data out) liegt an einem eigenen Pin.

Es gibt zwei Probleme: Eine besteht darin, das/die I2C-Gerät(e) zu deaktivieren, wenn ein SPI-Gerät ausgewählt ist (und umgekehrt, die Ausgangsleitung(en) des/der SPI-Gerät(e) zu deaktivieren, wenn sie nicht ausgewählt sind); und zweitens, um das Problem von Pull-ups auf den I2C-Leitungen zu behandeln, wenn das SPI-SDO-Lead die SDA/SDI-Leitung auf dem Mikrocontroller antreibt.

Um das erste Problem zu behandeln, werden alle SPI-Chipauswahlen UND-verknüpft. Ich zeige ein 74HCT21-UND mit vier Eingängen und zwei unbenutzten Eingängen; dies könnte auf eine beliebige Anzahl von Chipauswahlen erweitert werden.

Wenn eine Chipauswahl 0 ist, dann ist der Ausgang des UND-Gatters 0, wodurch der Analogschalter deaktiviert wird, sodass der SCL-Takt des Mikrocontrollers nicht an das/die I2C-Gerät(e) gelangt. Wenn alle Chipauswahlen 1 sind, dann ist der Ausgang des UND-Gatters 1, wodurch der Analogschalter aktiviert wird, sodass der SCL-Takt bidirektional zwischen dem Mikrocontroller und dem/den I2C-Gerät(en) weitergegeben wird.

Für das zweite Problem wird ein Pullup auf den SDA-Pins gemäß der I2C-Spezifikation bereitgestellt. Natürlich setzt dies auch einen Pullup auf den SDA/SDI-Pin des Mikrocontrollers. Da SPI-Geräte nicht so eingerichtet sind, dass sie gegen einen Pullup fahren, habe ich einen 74HCT07 Open-Collector-Puffer hinzugefügt, um dieses Problem zu beheben.

Dem Puffer ist ein ODER-Gatter vorangestellt, mit einem Eingang von derselben Leitung, die den I2C-Takt aktiviert/deaktiviert. Wenn also die I2C-Schnittstelle aktiviert ist, wird das ODER-Gatter immer aktiviert, wodurch der Open-Collector-Ausgang des Puffers hoch bleibt.