Searching \ for '[PIC]: I2C & SPI shared bus' 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: 'I2C & SPI shared bus'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: I2C & SPI shared bus'
2005\08\18@123204 by Shawn Tan

flavicon
face
Hi,

I'm wondering if anyone has tried sharing the same bus for I2C and SPI
peripherals before.. I'm trying to connect a SPI and I2C device to a 28pin
PIC with only 1 MSSP.. I plan to run the SPI at 2Mbps and I2C at 100kHz

The SPI devices can each be deselected through their SELECT pins.. So,
deselect the SPI devices during I2C transmission.. Looks okay so far.. Then
during SPI transfers, there shouldn't be anything that resembles a valid I2C
transaction on the bus.. So the I2C device should ignore all SPI
transmissions..

Am I right in assuming that we can share them??

cheers..

with metta,
Shawn Tan.

2005\08\18@130406 by Harold Hallikainen

face picon face
I got away with sharing SPI and I2C in a product. As you point out, the
SPI devices are deselected during I2C transactions, and an SPI transaction
does not have the clock/data relationship of an I2C start, so I2C devices
should ignore the SPI data.

Harold



--
FCC Rules Updated Daily at http://www.hallikainen.com

2005\08\18@130507 by olin piclist

face picon face
Shawn Tan wrote:
> I'm trying to connect a SPI and I2C device to a
> 28pin PIC with only 1 MSSP.. I plan to run the SPI at 2Mbps and I2C at
> 100kHz
>
> The SPI devices can each be deselected through their SELECT pins.. So,
> deselect the SPI devices during I2C transmission.. Looks okay so far..

That's probably OK.

> Then during SPI transfers, there shouldn't be anything that resembles a
> valid I2C transaction on the bus.

Huh!!?.  You are practically guaranteed to get some bus start and bus stop
sequences.  Depending on the edge timing of data versus clock, you could
also accidentally get a sequence of real bits.  If any of those looked like
a valid address you get into serious trouble.

> Am I right in assuming that we can share them??

This sounds like a really bad idea to me.  Also keep in mind that SPI lines
are all single ended and driven both high and low, whereas IIC lines are
both open collector busses.  I'd feel a lot better about your scheme if you
could disable the IIC devices while doing SPI.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\08\19@082930 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

>> Then during SPI transfers, there shouldn't be anything that resembles a
>> valid I2C transaction on the bus.
>
> Huh!!?.  You are practically guaranteed to get some bus start and bus
> stop sequences.  

Since SPI isn't really well-defined WRT data changes vs. clock changes,
this may or may not work. If any of your SPI devices requires you to
configure the SPI master so that there are data changes while the clock is
high or may produce such changes as slave, you are practically guaranteed
to create an IIC start condition while you are sending SPI data.

If OTOH you can guarantee that all SPI data transitions happen while the
clock is low, you can get away with it; in this case there won't be an IIC
start condition during SPI transfers.

I've done it before, and it can work. But it depends on the SPI devices and
their data transition timing.

Gerhard

2005\08\19@101838 by Mario Mendes Jr.

flavicon
face
I've posted this before, but still have had not time to play with it myself.

You can separate the SCK/SCL signals with 2 and gates and an inverter as
the following lifelike a la Picasso ASCII art shows:

PIC                           -----
SCL/SCK --+-------------------|    \
pin       |                   |     |----- SCKOUT
         |   I/O pin -----+--|    /
         |                |  -----
         |                |
         |                V  <- inverter
         |                o
         |                |  -----
         |                +--|    \
         |                   |     |----- SCLOUT
         +-------------------|    /
                             -----

If I/O pin is high, then SCKOUT is active and if I/O pin is low, then
SCLOUT is active.

I believe that those AND gates need to have open collector outputs, but
someone with more knowledge of the I2C/SPI than me will need to confirm or
deny this fact.

In theory, the above works really well, but like I said, I still have not
had time to play with this myself so I can't guarantee it will work.  If
you do try it and it works, let us know.

Good luck.


-Mario


{Quote hidden}

> -

2005\08\19@103838 by Michael Rigby-Jones

picon face


{Quote hidden}

It should work, the only snags I can see are the use of an extra port pin, and the I2C can only be a master, not a slave and it cannot supprt clock stretching as a master.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\08\19@110200 by Harold Hallikainen

face picon face
Another solution would be to bit bang one of them (I2C or SPI). This'd
take no additional hardware.

Harold
(the ideal design has zero parts)




--
FCC Rules Updated Daily at http://www.hallikainen.com

2005\08\19@110259 by Mario Mendes Jr.

flavicon
face
No free lunch!  =)

{Quote hidden}

> -

2005\08\19@130728 by olin piclist

face picon face
Harold Hallikainen wrote:
> Another solution would be to bit bang one of them (I2C or SPI). This'd
> take no additional hardware.

Given the choice, I would let the hardware to IIC and do the SPI in
firmware.  Neither is difficult, and I've got code for both, but SPI is
definitely easier.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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