Both can work with the standard internal oscillators without any fuss.
I2C is 2 wires, SPI is 4 wire.
Both can work with the standard internal oscillators without any fuss.
I2C is 2 wires, SPI is 4 wire.
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.
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
I have another question - do SPI and I2C (using either software or MSSP) still work ok when interrupts are also in use?
Andy
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.
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.
DT
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
Bookmarks