I have another question - do SPI and I2C (using either software or MSSP) still work ok when interrupts are also in use?
Andy
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
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.
Interrupts can only be a problem on SPI Slaves, which you're not going to bit-bang anyhow.Are other interrupts only an issue when using bit-banged SPI or are there still problems when using the (M)SSP module?
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.
DT
Bookmarks