Hi All.

I'm wondering how people deal with I2C at the hardware level when they
run USART0 in UART, SPI AND I2C modes in a single application & design
(obviously not at the same time !).

USART0 uses pins P3.4 and P3.5 exclusivle for the UART function -- no
problem.

USART0 uses pins P3[3..0] for the SPI function.

USART0 uses pins P3.3 and P3.1 for the I2C function.

So doing UART only, SPI only, I2C only, UART + SPI or UART + I2C is
trivial. What's not trivial is when you want to run SPI and I2C off
the USART0 peripheral.

Obviously there is no hardware conflict between the UART and either
the SPI or the I2C.

Since SPI can be configured with a -CS signal, as long as the SPI
device is not chip-selected, you can run I2C on P3.3 and P3.1 with
reckless abandon and it will not affect the SPI devices attached to
the MSP430.

But the converse is not necessarily true -- if you're running SPI,
then I2C's SCL is the SPI clock and I2C's SDA is SPI's Slave In /
Master Out.

Now, I bet the odds of a "good I2C packet" happening on the SPI lines
during SPI transfers is close to Nil. But can one count on that? Or is
it necessary to isolate the I2C bus when SPI transfers are in
progress. And if so, what's the preferred method? Power down all I2C
devices while an SPI transfer is occurring?

Obviously in-line resistors must be present just to deal with the fact
that I2C's SDA line is bidirectional ...

Looking for ideas ...

Thanks,

--Andrew

i think you consider the msp430 as master. if not so then the solution
is very implementation dependent. 
i also think that considering spi as nil for the i2c is risky as long
as i do not know the way the lines go when switching from i2c to spi
if you are interested in the opinion of a newbie like me i'll suggest
you to use an extra line to enable/disable the i2c by the clk line. 2
transistors and a resister should do the trick. Use one transistor to
make an open collector line out of i2c.clk, and the other to pull the
new clk line to ground while spi active. the resistor should pull the
line up. i hope my english satisfy you. ask more details if not.
avram

ps: if logical gates are available on the board you can use them ;)


--- aekalman <aek@aek@...> wrote:

> Hi All.
> 
> I'm wondering how people deal with I2C at the hardware level when
> they
> run USART0 in UART, SPI AND I2C modes in a single application &
> design
> (obviously not at the same time !).
> 
> USART0 uses pins P3.4 and P3.5 exclusivle for the UART function -- no
> problem.
> 
> USART0 uses pins P3[3..0] for the SPI function.
> 
> USART0 uses pins P3.3 and P3.1 for the I2C function.
> 
> So doing UART only, SPI only, I2C only, UART + SPI or UART + I2C is
> trivial. What's not trivial is when you want to run SPI and I2C off
> the USART0 peripheral.
> 
> Obviously there is no hardware conflict between the UART and either
> the SPI or the I2C.
> 
> Since SPI can be configured with a -CS signal, as long as the SPI
> device is not chip-selected, you can run I2C on P3.3 and P3.1 with
> reckless abandon and it will not affect the SPI devices attached to
> the MSP430.
> 
> But the converse is not necessarily true -- if you're running SPI,
> then I2C's SCL is the SPI clock and I2C's SDA is SPI's Slave
In /
> Master Out.
> 
> Now, I bet the odds of a "good I2C packet" happening on the SPI
lines
> during SPI transfers is close to Nil. But can one count on that? Or
> is
> it necessary to isolate the I2C bus when SPI transfers are in
> progress. And if so, what's the preferred method? Power down all I2C
> devices while an SPI transfer is occurring?
> 
> Obviously in-line resistors must be present just to deal with the
> fact
> that I2C's SDA line is bidirectional ...
> 
> Looking for ideas ...
> 
> Thanks,
> 
> --Andrew
> 
> 
> 
> 


__________________________________________________
 

--- avram ionut <avramionut_m@avra...> wrote:

> Date: Wed, 1 Feb 2006 23:01:34 -0800 (PST)
> From: avram ionut <avramionut_m@avra...>
> Subject: Re: [msp430] Anyone running I2C AND SPI AND UART on USART0?
> To: msp430@msp4...
> 
> i think you consider the msp430 as master. if not so then the
> solution
> is very implementation dependent. 
> i also think that considering spi as nil for the i2c is risky as long
> as i do not know the way the lines go when switching from i2c to spi
> if you are interested in the opinion of a newbie like me i'll suggest
> you to use an extra line to enable/disable the i2c by the clk line. 2
> transistors and a resister should do the trick. Use one transistor to
> make an open collector line out of i2c.clk, and the other to pull the
> new clk line to ground while spi active. the resistor should pull the
> line up. i hope my english satisfy you. ask more details if not.
> avram
> 
> ps: if logical gates are available on the board you can use them ;)
> 
> 
> --- aekalman <aek@aek@...> wrote:
> 
> > Hi All.
> > 
> > I'm wondering how people deal with I2C at the hardware level when
> > they
> > run USART0 in UART, SPI AND I2C modes in a single application &
> > design
> > (obviously not at the same time !).
> > 
> > USART0 uses pins P3.4 and P3.5 exclusivle for the UART function --
> no
> > problem.
> > 
> > USART0 uses pins P3[3..0] for the SPI function.
> > 
> > USART0 uses pins P3.3 and P3.1 for the I2C function.
> > 
> > So doing UART only, SPI only, I2C only, UART + SPI or UART + I2C is
> > trivial. What's not trivial is when you want to run SPI and I2C
off
> > the USART0 peripheral.
> > 
> > Obviously there is no hardware conflict between the UART and either
> > the SPI or the I2C.
> > 
> > Since SPI can be configured with a -CS signal, as long as the SPI
> > device is not chip-selected, you can run I2C on P3.3 and P3.1 with
> > reckless abandon and it will not affect the SPI devices attached to
> > the MSP430.
> > 
> > But the converse is not necessarily true -- if you're running
SPI,
> > then I2C's SCL is the SPI clock and I2C's SDA is SPI's
Slave In /
> > Master Out.
> > 
> > Now, I bet the odds of a "good I2C packet" happening on the
SPI
> lines
> > during SPI transfers is close to Nil. But can one count on that? Or
> > is
> > it necessary to isolate the I2C bus when SPI transfers are in
> > progress. And if so, what's the preferred method? Power down all
> I2C
> > devices while an SPI transfer is occurring?
> > 
> > Obviously in-line resistors must be present just to deal with the
> > fact
> > that I2C's SDA line is bidirectional ...
> > 
> > Looking for ideas ...
> > 
> > Thanks,
> > 
> > --Andrew
> > 
> > 
> > 
> > 
> 
> 
> __________________________________________________
>  
> 


__________________________________________________
 

andrew- i wrote a long reply agreeing with you, but my email system 
junked it.

the meat of it was - everything works except I2C with SPI. To get that 
to work too I think you need a transmission gate in the I2C data line, 
like a 4066.

David

Hi Avram and David.

Thanks for your replies.

Yes, I think you're both right that I shouldn't risk I2C screwups via
SPI banging away at it.

I hadn't considered just gating out one signal .. hmmm.

The Philips I2C spec has a great circuit that allows for bidrectional
level shifting:

<http://www.semiconductors.philips.com/acrobat/literature/9398/39340011.pdf>

See page 43 / Figure 45.

I already use this for for other things, and in my case (at hand) I
also have a split +5V/+3.3V system with I2C on both sides, so this
makes for an interesting circuit.

The issue is how to disable the interface -- Right now I'm looking at
whether controlling the gates (0 and +3.3V) will be OK for I2C loading
when the gates are at 0V (the body diode is the issue here).

Thanks again,

--Andrew

--- In msp430@msp4..., "David Collier" <from_yahooMSP430@...>
wrote:
>
> andrew- i wrote a long reply agreeing with you, but my email system 
> junked it.
> 
> the meat of it was - everything works except I2C with SPI. To get that 
> to work too I think you need a transmission gate in the I2C data line, 
> like a 4066.
> 
> David
>

Hi all,

I also want to make a protoboard with the MSP430F1611
as the core. In my board I will use I2C, one SPI and
one UART, but in this case the micro features two
USARTs. The first one supports SPI, UART and I2C, and
the second one only supports SPI and UART. For what
I've read in this thread, it's ok with sharing UART
with SPI or I2C, but I should never use SPI and I2C in
the same port. It's ok?

I'm looking forward next week to start working on my
protoboard. Then I'll know what is the best
combination.

Regards.


 --- aekalman <aek@aek@...> wrote:

> Hi Avram and David.
> 
> Thanks for your replies.
> 
> Yes, I think you're both right that I shouldn't risk
> I2C screwups via
> SPI banging away at it.
> 
> I hadn't considered just gating out one signal ..
> hmmm.
> 
> The Philips I2C spec has a great circuit that allows
> for bidrectional
> level shifting:
> 
>
<http://www.semiconductors.philips.com/acrobat/literature/9398/39340011.pdf>
> 
> See page 43 / Figure 45.
> 
> I already use this for for other things, and in my
> case (at hand) I
> also have a split +5V/+3.3V system with I2C on both
> sides, so this
> makes for an interesting circuit.
> 
> The issue is how to disable the interface -- Right
> now I'm looking at
> whether controlling the gates (0 and +3.3V) will be
> OK for I2C loading
> when the gates are at 0V (the body diode is the
> issue here).
> 
> Thanks again,
> 
> --Andrew
> 
> --- In msp430@msp4..., "David Collier"
> <from_yahooMSP430@...>
> wrote:
> >
> > andrew- i wrote a long reply agreeing with you,
> but my email system 
> > junked it.
> > 
> > the meat of it was - everything works except I2C
> with SPI. To get that 
> > to work too I think you need a transmission gate
> in the I2C data line, 
> > like a 4066.
> > 
> > David
> >



		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y miles desde 1 ctimo por minuto. 
http://es.voice.yahoo.com

--- In msp430@msp4..., Mario Lopez <linked82@...> wrote:
> For what
> I've read in this thread, it's ok with sharing UART
> with SPI or I2C, but I should never use SPI and I2C in
> the same port. It's ok?

It certainly is much easier --  no additional hardware is required to
run the UART and SPI or I2C on the USART0 port.

--Andrew

Alright. Now I want to connect two SPI devices to the
USART1 port. One device is a 3310 display, and the
second device is a SD card. If I want to connect them
to the same SPI port I could cascade them, so the SDO
of the first device is the SDI input of the second
device. Another option is to connect them in parallel,
and use two chip select signals to select the devices.

But now, the first connection won't work if the SD
card is unplugged. On the other hand, in the parallel
connection I must spend two pins in selecting the
devices. Moreover, in the ISR is necesary to control
these pins, and it should be a little be confusing.

Any suggestion?


 --- aekalman <aek@aek@...> wrote:

> --- In msp430@msp4..., Mario Lopez
linked82@...> wrote:
> > For what
> > I've read in this thread, it's ok with sharing
UART
> > with SPI or I2C, but I should never use SPI
and
I2C in
> > the same port. It's ok?
> 
> It certainly is much easier --  no additional
> hardware is required to
> run the UART and SPI or I2C on the USART0 port.
> 
> --Andrew
>  
> 


		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y miles desde 1 ctimo por minuto. 
http://es.voice.yahoo.com

--- In msp430@msp4..., Mario Lopez <linked82@...> wrote:
 > Alright. Now I want to connect two SPI devices to the
> USART1 port. One device is a 3310 display, and the
> second device is a SD card. If I want to connect them
> to the same SPI port I could cascade them, so the SDO
> of the first device is the SDI input of the second
> device. Another option is to connect them in parallel,
> and use two chip select signals to select the devices.
Parallel will certainly be easier ...

> 
> But now, the first connection won't work if the SD
> card is unplugged. On the other hand, in the parallel
> connection I must spend two pins in selecting the
> devices. 
Yep ... that's the cost of multi-device SPI with individual chip
selects (unless you use a single pin to control/enable both of them
using an inverter to generate -CS and -(-CS), i.e. two complentary
chip selects).

> Moreover, in the ISR is necesary to control
> these pins, and it should be a little be confusing.
Code is code -- there are many ways to code the control of the -CS
signal(s).

In my design, I've isolated the signals to the SD card (with serial
resistors in addition to pullups) AND I can control the power to the
SD card as well as its chip select. Nothing special. The other devices
on USART0[I2C, SPI] are quite happy when the SD card is absent from
the socket. You may want to read up on design issues for systems that
may have unpowered devices in them ...

--Andrew

          _    
          |         
          |
         ---
         | |  R_up
         | |  
         ---
          |
          |
          -------------------------  SCL to the slave
          |                   |
 SCLK___|/                    \|_______ #EN_I2CLK
        |\ Q1              Q2 /|  
          |                   |
          |                   |
         ---                 ---
         \ /                 \ /
        GND                   GND
     
if the remainning 0.8V-0.9V bother then use a not gate to invert the
SCLK and use a npn for Q1

avram
PS: bipolar is not a must, it is easy for me to think the logic nothing
more

--- aekalman <aek@aek@...> wrote:

> Hi Avram and David.
> 
> Thanks for your replies.
> 
> Yes, I think you're both right that I shouldn't risk I2C screwups
via
> SPI banging away at it.
> 
> I hadn't considered just gating out one signal .. hmmm.
> 
> The Philips I2C spec has a great circuit that allows for bidrectional
> level shifting:
> 
>
<http://www.semiconductors.philips.com/acrobat/literature/9398/39340011.pdf>
> 
> See page 43 / Figure 45.
> 
> I already use this for for other things, and in my case (at hand) I
> also have a split +5V/+3.3V system with I2C on both sides, so this
> makes for an interesting circuit.
> 
> The issue is how to disable the interface -- Right now I'm looking at
> whether controlling the gates (0 and +3.3V) will be OK for I2C
> loading
> when the gates are at 0V (the body diode is the issue here).
> 
> Thanks again,
> 
> --Andrew
> 
> --- In msp430@msp4..., "David Collier"
<from_yahooMSP430@...>
> wrote:
> >
> > andrew- i wrote a long reply agreeing with you, but my email system
> 
> > junked it.
> > 
> > the meat of it was - everything works except I2C with SPI. To get
> that 
> > to work too I think you need a transmission gate in the I2C data
> line, 
> > like a 4066.
> > 
> > David
> >
> 
> 
> 
> 


__________________________________________________