I2C über SPI

**nali** · 24.04.2008, 19:02

Hi,

ich bin nicht sicher, ob ich meine Frage ins richtige Forum poste (falls nicht, bitte Thread verschieben). Also mein Problem: Ich arbeite an einem Projekt mit einem MPC565 und einem Modellauto. Nun sollen an den MPC565 verschiedene Ultraschallsensoren angeschlossen werden. Es handelt sich dabei um die bekannten Modelle SRF08/10 - also per I2C-Interface anzusteuern.

Nun hat der MPC565 aber leider kein I2C-Interface. Und ich müsste ein passendes Interface selber erstellen. An sich keine große Sache: Digital-IN/Out und eine Clock, fertig bin ich. Leider kann ich aber für die Programmierung nicht 100 % an den Controller ran. Ich MUSS über eine gegebene Hardware-Abstraktionsschicht gehen.

Das hat zur Folge, dass ich z.B. KEINE Interrupts nutzen kann. Jedenfalls nicht direkt. Ich habe nur Zugriff auf verschiedene ADC, PWM, SPI, SPM und eben DIO-Kanäle über verschiedene Interfaces, welche wiederrum direkt auf die Hardware zugreifen.

Aus dieser Situation ergeben sich jetzt zwei Fragen:

1. Der Controller verfügt über ein SPI-Interface, was ich leicht nutzen kann. Ist möglich I2C-Geräte über ein SPI-Interface anzusprechen? Theoretisch müsste das doch möglich sein. Ich muss natürlich weiter ein entsprechende I2C-Interface aufsetzen, aber dieses würde intern auf einem SPI basieren. Clock, Data-In-Out sind ja auch hier vorhanden. Die Idee kam mir durch diese Seite: http://www.i2cchip.com/mix_spi_i2c.html

Hat jemand schon mal etwas ähnliches gemacht oder kann mir bestätigen, dass sowas Sinn funktioniert?

2. Falls die Variante I2C über SPI nicht funktioniert, muss ich halt ein "richtiges" I2C-Interface schreiben, aber eben ohne die Nutzung von IR. Ich kann mir dabei nicht so recht vorstellen, wie ich das Senden / Empfangen der Bytes auf das Clock-Signal synchronisieren kann. Ich bin ehrlich gesagt jetzt auch nicht sehr erfahren im Umgang mit I2C / SPI, die ganzen Gedanken entstammen jetzt eher meinem theoretischen Wissen

Nach meinem Wissen muss die Datenleitung bei I2C ja passend zum Clock-Signal gesetzt werden. Wie mache ich sowas aber ohne Interrupts? Muss ich dann in meinen i2c_read/write-Funktionen fortwährend prüfen, ob das clock-Signal passt? Das kommt mir alles etwas "gebastelt" vor.

Wie auch immer: Welche Variante wäre hier die richtige / mögliche -I2C über SPI oder I2C ohne Interrupts?

Hoffe ich habe das Problem ausführlich genug beschrieben. Ansonsten kann ich´s gerne ausführlicher machen...

Danke
Christian

**Besserwessi** · 24.04.2008, 20:58

Für I2C über 2 normale IO Pins sollte man ziehmlich leicht Code finden. Das mit dem SPI interface klingt möglich, hängt aber eventuell von der konkreten SPI hardware ab. Vermutlich wird man zumindestens eine Dioden brauchen um einen Open-Collector Ausgang zu imitieren. Zumindestens das Clockstrtching wird mit der SPI-hardware Probleme machen. Wenn man die Daten von vornherein langsam schickt sollte das aber eher selten vorkommen.

Einen 100% normkonformen I2C Bus wird man kaum hinkriegen, dazu braucht man treiber mit begrenzter Anstiegsgeschwindigkeit. Mit den meisten Geräten sollte es aber gehen, wenn die Kabel kurz bleiben.

**TheHawk** · 24.04.2008, 21:12

Hmm wozu braucht man bei I2C Interrupts???

**nali** · 24.04.2008, 22:58

Die Software-Implementierung eines I2C-Interfaces scheint also die bessere Variante zu sein, als den SPI-Bus zu nutzen.

Das Interrupts nicht zwingend für I2C nötig sind, sehe ich ein. Aber mir scheint die Variante über das regelmäßige Polling irgenwo ineffizient. Ist aber nur ein Gefühl, womit ich wohl offensichtlich falsch liege.

Habt ihr neine konkrete I2C-Implementierung, die ich als Basis gut nutzen könnte? Habe mir eben die Variante von Peter Fleury angeschaut (scheint wohl die Standard-Variante für AVRs zu sein).

Danke
Christian

**TheHawk** · 25.04.2008, 18:04

Der I2C Slave arbeitet ja mit deiner Clock Frequenz die du Auf den Bus legst. d.h. er gibt dir ja dann nur die bits wenn du eine antwort haben willst, also wenn du das clock signal änderst. sonst kannst du ja den bus pausieren sozusagen.