Well, I have no idea about the PIC specific hardware. but SPI isn't like a UART. If you are the Master, you don't have to keep checking if something is there. You only receive a value when you send one, so it's never a surprise.
It really depends upon the application. ie: Do you need to do something between sending/receiving bytes or can the PIC idle while waiting to send the next SPI byte?
Well, I have no idea about the PIC specific hardware. but SPI isn't like a UART. If you are the Master, you don't have to keep checking if something is there. You only receive a value when you send one, so it's never a surprise.
He didn't say internal or external clock. If the SPI's reading an external clock, then as a slave it's very possible to overrun the SPI module input buffer and underrun the output buffer. Usually not the case for an EEROM though, that communication would be PIC as a master.
If the SPI's reading an external clock, then as a slave it's very possible to overrun the SPI module input buffer and underrun the output buffer. Usually not the case for an EEROM though, that communication would be PIC as a master.
Yes, that's why I specified the master stuff. I could have done a better job explaining the alternative needed if it's a slave, but he mentioned the slave device in his post.
but I couldn't find any routines for the SPI based interrupt online. I only know how to turn on the SPI interrupts, and make it jump to the function when the SSPIF is raised, and afterwards, I get stuck there.
Any good pointers? Or must I just do a basic SPI routines without all the interrupts? Btw, I have two timers running at interrupt mode.
It seems like your question is more along the general line of "should I learn how to use interrupts?"
The answer is an unequivocal yes. As soon as possible. It doesn't matter much if this application needs it per se, you should learn how to do them right after learning basic "hello world" code writing and getting peripherals to turn on and do things.