Questions regarding SPI (and I2C)

[Andy Wood]

Hello,

Having never experimented much with SPI (or I2C for that matter), I need to ask a rather basic question - Do SPI and I2C require the use of an accurate (eg. crystal) oscillator, or do they work ok with standard internal oscillators?

What are the pros / cons of SPI vs. I2C?

Regards,

Andy

[Jerson]

Both can work with the standard internal oscillators without any fuss.

I2C is 2 wires, SPI is 4 wire.

[Andy Wood]

Thanks Jerson.

Andy

[Amoque]

I am not very familiar in using SPI, nor I2C for that matter, but as it is on topic and may help both the OP and myself...

Is it correct that I2C must be initiated by the master always, so that the slave device cannot initiate a communication? Say, by example, an I2C clock cannot (by I2C protocol alone) initiate an interrupt (like by the second); rather, must wait for the master unit to read data and determine for itself that the second register is updated? Of course an interrupt line may be used - independent of the protocol - if one is available...

SPI also has this interrupt built into the protocol and one of the required lines may signal that new data is available, yes? Therefore SPI may be more suitable for "active" devices? As our clock example above, the SPI clock (or other SPI device) may signal an updated second register so that the master unit may service this as an interrupt and not bother itself until notified by the slave.

[Jerson]

I2C has 2 variants I2Cmaster and I2Cslave. The master always is in command and the slave responds to the master initiated query/commands.

SPI usually has 4 wires MISO, MOSI, SCLK, CS (Master In Slave Out, Master out slave In, serial clock, chip select). Some devices may signal availability of data on the MISO line when the CS is held inactive. That is implementation specific to that device.

An interrupt line has no relation to the 2 protocols except you might be able to enable / disable the feature via the communications by setting of some register

[Andy Wood]

I have another question - do SPI and I2C (using either software or MSSP) still work ok when interrupts are also in use?

Andy

[Art]

Yes, but there could be error if interrupt happens during the communication.
I found this could occur with LCDOUT when interrupt occurs,
but if you are always updating, it will correct itself next time.

Some clock chips have a pulse per second output that could be used to
interrupt the chip independently of the I2C communication.

[Darrel Taylor]

I2C is by nature a Multi-Master Bus.
Any device on the bus can be the "Master".
And the same device can also be a "Slave", it just needs to switch back and forth between the modes.
There's also some collision detection / arbitration to do, but it's definitely possible.

Most manufactured I2C devices like EEPROM or RTC's are only Slaves.
But a PIC can easily be both.

SPI can only have one Master, and it is always the Master.
SPI lines are "Driven" instead of open collector with pull-ups, and two Master's can't "Drive" the lines at the same time.

Interrupts will not affect the data transmission from a Master.
But it can ruin the response times of a Slave if not using "Clock Stretching".

Slaves must be ready and waiting to do the bidding of their Master.

---

Interrupts will not affect LCDOUT either, unless your ISR is misbehaving.

[Andy Wood]

Hi Darrel,

Thank you for your detailed explanation. Can you elaborate on "Clock Stretching" please?

Are other interrupts only an issue when using bit-banged SPI or are there still problems when using the (M)SSP module?

Sorry for all the questions! I am trying to do my homework as best I can before embarking on my project. It's better to ask dumb questions that to make dumb mistakes....

Andy

[Darrel Taylor]

Can you elaborate on "Clock Stretching" please?

I'll let Wikipedia explain that ...
http://en.wikipedia.org/wiki/I%C2%B2...hing_using_SCL

In PBP when using I2CREAD/I2CWRITE, the Master would use ... DEFINE I2C_HOLD 1 ... to respond properly to Clock Stretching.
In I2C Slave mode, the MSSP module can automatically hold the SCL line low after each byte, which gives your program time to respond.

Are other interrupts only an issue when using bit-banged SPI or are there still problems when using the (M)SSP module?

Interrupts can only be a problem on SPI Slaves, which you're not going to bit-bang anyhow.
The Master dictates when the Slave needs to send data.
If the Slave's off in an interrupt, it may not be ready to send anything when the Master cracks it's whip.

The MSSP will generate interrupts to help the Slave be ready, and on an 18F that can be a High Priority interrupt that interrupts any Low priority interrupts which may be running.
But on a 16F, you can't interrupt an interrupt.

SPI does not have "Clock Stretching".
Be ready to send ... or lose data.
Typically, the SPI Master will have to wait long enough to insure the Slave had time to prepare.

Yes, you can do things like having a separate line to indicate when the SPI Slave is ready.
But technically, that would no longer be called SPI.

[Andy Wood]

Thanks again Darrel.