SPI und I2C mit gemeinsamen Taktsignal?

Schadi schrieb:
> Ist es möglich den Takt vom SPI und vom I2C auf einen gemeinsamen Leiter
> zu legen?

Ja, das funktioniert.

Peter D. schrieb:
> Schadi schrieb:
>> Ist es möglich den Takt vom SPI und vom I2C auf einen gemeinsamen Leiter
>> zu legen?
>
> Ja, das funktioniert.

Prinzipliell ja. Wenn auf der CLK Leitung was kommt, auf der SDA aber 
nicht, ignorieren dass die i2c-Teilnehmer. Problem wird aber sein, dass 
der Controller kaum die Konfiguration als SPI & i2C an einem Pin 
zulassen wird?

Außerdem muss man sichergehen, dass die i2C-Slaves nichts von sich 
geben, während der SPI läuft.

Schadi schrieb:
> Der Takt soll später von einem MSP430 per HDMI kommen.
Ich stelle mir die Terminierung interessant vor. Insbesonders bei HDMI, 
wo ja schon mal ein paar Meter Leitung anfallen können...

Warum fährst du denn mit SPI aus dem Gerät heraus?
Der braucht ja immerhin 4 Leitungen (um es vorweg zu nehmen: nein, es 
ist keine gute Idee, ohne CS zu fahren).

Schadi schrieb:
> Ist es möglich den Takt vom SPI und vom I2C auf einen gemeinsamen Leiter
> zu legen?

Nein. Auch der Master darf die I2C Clock nicht aktiv "high" treiben, 
sondern nur der Pullup Widerstand. Das wäre aber für SPI vieeel zu lahm.

Jim M. schrieb:
> Nein. Auch der Master darf die I2C Clock nicht aktiv "high" treiben,

Doch, solange man nur dumme I2C-Peripherie anschließt, da ist SCL 
nämlich nur ein Eingang.
Nur I2C-MCs brauchen SCL auch als Ausgang, um dem Master sagen zu 
können, wann sie endlich in den Interrupthandler gesprungen sind.
Manche MCs mit I2C-DMA können aber auch ohne Clock Stretching auskommen.

Letztendlich spielt das aber keine Rolle, da man entweder SW-I2C und 
SW-SPI nimmt oder mit HW-I2C und HW-SPI der Pin schon passend 
umkonfiguriert wird (z.B. USI beim ATtiny24).

Schadi schrieb:
> CS Ist doch Chip select, davon war ja nicht die Rede.
War nur so ein Verdacht, der sich nicht bestätigt hat:
> CS würde ich durchaus noch verwenden für den SPI Device.

Zurück zum Thema:
> Vielleicht war das mit Takt etwas unglücklich formuliert.
> Sprich SCL und SCK zusammenführen.
Prinzipiell ja.
Aber wie gesagt: abhängig von der Leitungslänge ist die Terminierung 
interessant. Aber wenn man nicht mit allzu steilen Flanken drauf knallt, 
dass es von vorn bis hinten klingelt, dann dürfte das funktionieren...

Peter D. schrieb:
>> Nein. Auch der Master darf die I2C Clock nicht aktiv "high" treiben,
>
> Doch, solange man nur dumme I2C-Peripherie anschließt, da ist SCL
> nämlich nur ein Eingang.

Nix da. Der Slave darf den Clock auch selber runter ziehen, siehe Clock 
Streching. Auch dumme Peripherie wie ein I2C EEProm kann das sehr oft, 
und der OP hat keine konkreten Slave Chips benannt.

Außerdem kommt der I²C Chip mit den normalerweise viel höheren 
Frequenzen des SPI Takts nicht in jedem Falle klar.

Und umgekehrt muss der SPI Slave nicht unbedingt mit der relativ flachen 
0->1 Flanke des I²C SCL Taktsignals klar kommen.

Das Ergebnis wäre also eine typische Schaltung die nur im Labor aber nie 
beim Kunden funktioniert...

Jim M. schrieb:
> Nix da. Der Slave darf den Clock auch selber runter ziehen, siehe Clock
> Streching. Auch dumme Peripherie wie ein I2C EEProm kann das sehr oft
Hast du mal einen Typ dazu? Ich kenne keines.

> Außerdem kommt der I²C Chip mit den normalerweise viel höheren
> Frequenzen des SPI Takts nicht in jedem Falle klar.
Warum? Der sieht doch eh' keinen Start, dann hat er auch nichts zu 
tun...

> Und umgekehrt muss der SPI Slave nicht unbedingt mit der relativ flachen
> 0->1 Flanke des I²C SCL Taktsignals klar kommen.
Der SPI wird ja aktiv getrieben, da hat man eher das Problem mit 
Reflektionen und resultierendem Klingeln.

> Das Ergebnis wäre also eine typische Schaltung die nur im Labor aber nie
> beim Kunden funktioniert...
Wenn man die Gegenseite auch selber in der Hand hat, sehe ich da gute 
Chancen, denn dann kann man sich die "Chips", die einem schmecken, 
selber aussuchen:
> der OP hat keine konkreten Slave Chips benannt.

Jim M. schrieb:
> Auch dumme Peripherie wie ein I2C EEProm kann das sehr oft

Dann nenn mir bitte ein Beispiel, ich kenne keine.

Und wie gesagt, man kann beides eh nicht gleichzeitig betreiben. Also 
ist es kein Problem, beim Wechsel zwischen open drain und push/pull 
umzuschalten.

Lothar M. schrieb:
>> Nix da. Der Slave darf den Clock auch selber runter ziehen, siehe Clock
>> Streching. Auch dumme Peripherie wie ein I2C EEProm kann das sehr oft
> Hast du mal einen Typ dazu? Ich kenne keines.

Si7020, hält die Clock so lange unten, bis er mit Wandeln fertig ist. 
Ist eine feine Sache.
EEProms mit Clock Stretching beim Shreiben hatte ich noch nicht in den 
Fingern, obwohl es sich auch da anbieten würde.


Mit etwas Vorsicht sehe ich bei der Aktion aber kein Problem. Im 
SPI-Modus solltest du schauen, dass der SDA immer High ist, dann kommt 
keine Start Condition zustande. Im I2C-Modus den /CS der SPI-Slaves 
dauerhaft auf High halten, dann ist auch da Ruhe.


Wenn du noch externe HW spendieren willst/kannst, kannst du auch über 
einen Portpin und einen Inverter wechselweise die SPI- und die I2C-ICs 
im Reset halten. Ob das sich mit deiner Anwendung verträgt, ist eine 
andere Frage.

Max G. schrieb:
> EEProms mit Clock Stretching beim Shreiben hatte ich noch nicht in den
> Fingern, obwohl es sich auch da anbieten würde.
Keine so gute Idee, den Bus solange zu blockieren... ;-)

> Si7020, hält die Clock so lange unten, bis er mit Wandeln fertig ist
Wenn man unbedingt will:

1

While the measurement is in progress, the option of either clock stretching

2

(Hold Master Mode) or Not Acknowledging read requests (No Hold Master Mode)

3

is available to indicate to the master that the measurement is in progress;

4

the chosen command code determines which mode is used.

Wenn man ein Dutzend Bauteile am I2C hat, die dann vielleicht auch noch 
aus verschiedenen Threads abgefragt werden, ist das natürlich Mist.
Viele reale Busse haben aber vielleicht zwei, drei Sensoren, die rundum 
abgefragt werden. Da ist ein solches Verhalten völlig i.O.

Und ja, beim Si7020 wollte ich unbedingt :) - SW-seitig weitaus 
einfacher zu implementieren. Der Polling-Ansatz (so lange abfragen, bis 
wieder ein ACK kommt) ist auch nicht viel besser.

Max G. schrieb:
> Der Polling-Ansatz (so lange abfragen, bis wieder ein ACK kommt) ist
> auch nicht viel besser.
Richtig, wenn man eh' Zeit zum dauernden Pollen hat, dann kann man auch 
hardwaremäßig warten...  ;-)