Searching \ for '[PIC]: SPI and I2C Coexistence' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/i2cs.htm?key=i2c
Search entire site for: 'SPI and I2C Coexistence'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: SPI and I2C Coexistence'
2001\10\19@152413 by Eberle, Fritz

flavicon
face
Hello everyone,

I am trying to work out the hardware for a future PIC18F458 project.  It
seems that the available peripheral components which are most suitable are
not all of the same interface type.  There are, in fact, 3 types:

1) "Addressable device" components with 3 pins (e.g.. A0, A1, and A2) to
select a part within the component, 1 chip select pin (e.g.. CS1) , a
Data-in pin (e.g.. DI), and a data-out pin (e.g.. DO).

2) SPI components with at least 4 interface pins including one chip select
pin (e.g.. SCK, SDI, SDO, and CS2).

3) I2C components with at least 2 interface pins (e.g.. SCL and SDA).

There seem to be not quite enough PIC pins to go around, so I am wondering
if it is possible (and safe) to "time share" some of the pins by
alternately:

1) Use PIC pins RC3/SCK/SCL as SCL, and RC4/SDI/SDA as SDA, to talk to I2C
components with I2C module enabled.

2) Use PIC pins RC3/SCK/SCL as SCK, RC4/SDI/SDA as SDI, and RC5/SDO as SDO
to talk to SPI components with SPI module enabled.  Other unique pins would
connect to CS1 etc.

3) Use PIC pin RC3/SCK/SCL as RC3-output connecting to A0, RC4/SDI/SDA as
RC4-output  connecting to DO, and RC5/SDO as RC5-input connecting to DI to
talk to "Addressable device" components with I2C and SPI modules disabled.
Other unique pins would connect to CS0, A1, A2, etc.

It seems that if I2C slave components don't think they are being addressed
it might be ok, but that might be a "big if".  (I'm just in the studying the
datasheet stage of understanding I2C) Does anyone have any experience with
this?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\10\19@160647 by Gerhard Fiedler

flavicon
face
At 15:12 10/19/2001 -0400, Eberle, Fritz wrote:
>1) Use PIC pins RC3/SCK/SCL as SCL, and RC4/SDI/SDA as SDA, to talk to I2C
>components with I2C module enabled.
>
>2) Use PIC pins RC3/SCK/SCL as SCK, RC4/SDI/SDA as SDI, and RC5/SDO as SDO
>to talk to SPI components with SPI module enabled.  Other unique pins would
>connect to CS1 etc.
>
>3) Use PIC pin RC3/SCK/SCL as RC3-output connecting to A0, RC4/SDI/SDA as
>RC4-output  connecting to DO, and RC5/SDO as RC5-input connecting to DI to
>talk to "Addressable device" components with I2C and SPI modules disabled.
>Other unique pins would connect to CS0, A1, A2, etc.
>
>It seems that if I2C slave components don't think they are being addressed
>it might be ok, but that might be a "big if".  (I'm just in the studying the
>datasheet stage of understanding I2C) Does anyone have any experience with
>this?

I have shared 1 and 2 on some occasions, this is not a problem as long as
you don't output a start condition during SPI mode. This is the crucial
thing: as long as you can make sure that in non-I2C modes no start
condition occurs, you're safe.

Another thing you should check is that all non-I2C devies must release
(tri-state) the bus when not selected (which usually is the case) and they
must be able to drive the I2C open collector bus.

ge

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\10\20@071013 by Peter L. Peres

picon face
I just connected a I2C EEPROM into a project that is very short on IO pins
so it shares the SDA line with a LCD RS control that also  scans a
keyboard from time to time (as input). It seems to work ok (I spent some
time figuring scenarios of how a state combinations could corrupt data and
found none). The trick is to make sure that the SCL pin is never high when
SDA is changed by the other peripheral drivers connected to that pin.

Most SPI parts require that you clock a certain number of bits in and then
set enable. So you can use their data and clock bits freely as long as
enable is not asserted. Others are less tolerant.

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\10\23@160843 by Eberle, Fritz

flavicon
face
Thanks to Peter Peres and Gerhard Fiedler for responding.  I think I
understand the issue now.  Two of the four SPI modes may not be used when
sharing the pins with I2C.

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...