I²C und SPI parallel nutzen mit nur einem SFR.

Gerdohard schrieb:
> gleichzeitig das
> CLK-Signal vom I²C - es werden also bei einem SPI-Schreibvorgang 16Bit
> an das I²C-Device übertragen

Ich revidiere...müssen ja garnicht 16 sein, da es ja vom Dateninhalt 
abhängt. Wie verhält sich also ein I²C-Device bei einer beliebigen 
Anzahl von Takten?

Gerdohard schrieb:
> Wie verhält sich also ein I²C-Device bei einer beliebigen
> Anzahl von Takten?

Wenn du Pech hast, schlecht. Ich würde mit der Select-Leitung vom SPI 
den I2C Bus schalten.

MfG Klaus

Das Problem ist keines mehr, wenn man einen Typen
eisetzt, der USCI_A0 UND UCCI_B0 separat hat-
z.B. Launchpad 1.5 mit MSP430G2553.

Klaus schrieb:
> Ich würde mit der Select-Leitung vom SPI
> den I2C Bus schalten.

Ne CS-Leitung habe ich ja garnicht. Ich toggle nur ein Latch am Ende der 
Daten, also einmal high, dann wieder low.

Torsten C. schrieb:
> Ich würde den I²C-Clock mit 'nem Oder-Gatter auf High halten, wenn SPI
> benutzt wird, hab's aber noch nicht ausprobiert.

Ist natürlich ne Möglichkeit, aber eben halt ein extra Bauteil. Wäre 
nicht schlimm aber:

Torsten C. schrieb:
> Man kann den SPI auch über Timer-Interrups ansteuern

dann würde ich im schlimmsten Fall eben bitbangen, da brauche ich ja 
nichtmal nen Timer für, auch wenn es dann nicht mehr Interrupt-gesteuert 
ist. Den SPI würde ich halt nur gerne verwenden, damit das im 
Hintergrund läuft (also evtl. wirklich mit Timer).

DS aus W schrieb:
> Das Problem ist keines mehr, wenn man einen Typen
> eisetzt, der USCI_A0 UND UCCI_B0 separat hat-
> z.B. Launchpad 1.5 mit MSP430G2553.

Da ist natürlich die Lösung des Tages. Da hätt ich noch eine: Einfach 
nen SPI-ADC, oder das SPI-Teil gegen eines mit I²C austauschen....:-\ 
Trotzdem danke!