Are SPI or I2C timer interrupt based protocols?

Projects Programming
1

When I connect LCD using a standard serial enabled protocol, I noticed that Serial.begin function is using timer interrupts to send/receive data even when it is connected Rx/Tx pins.

For me that is a problem as in my code I use Arduino interrups to output very precisely spaced TTL pulses. To overcome this issue I use my LCD in parallel mode, but that is too many wires.

I don't know how SPI or I2C protocol are internally designed in Arduino Uno, will it affect the rest of my code that generates very precisely spaced TTL pulses?

2

even when it is connected to a hardware supported pins for serial communication.

Serial communication relies on interrupts.

I don't know how SPI or I2C work, will it mess up the rest of my code?

Almost certainly. Especially lines 28 to 45. Or so my crystal ball says.

3

What's the timing of the spaces?
You can code for SPI so that a byte is sent out in ~1uS, use that to feed a shift register for the LCD bits, fewer wires needed coming out of the arduino, moved to between shift register & LCD instead.

4

I don't think that any code is necessary, I simply use Timer1 interrupts to generate TTL pulses with predefined period ranging from 100us to 1ms. It is very important that they are equidistantly spaced.

If I use in my code SPI or I2C to connect the LCD will that affect the Timer1 interrups? SPI can work on 4Mhz, right? So if the Arduino need to finish something over the SPI bus, that cannot be interrupted, but still 4Mhz is way faster than a default 9600 baud rate in standard serial protocol.

5

I don't think that any code is necessary

OK. Sorry to have bothered you.

6

SPI can run at 8 MHz. Default speed is 4 MHz.
If you use SPI.transfer( ); I think it may create an interrupt at the end to signify the transfer is done. You can write your code so that the data only gets sent out after your pulse code runs. Maybe send one row of data after a pulse, next row after next pulse, etc. so that the transfer always completes within 100uS.
Can't update LCD too fast or it becomes unreadable, yes? I haven't used one in ages, I don't know if that's changed at all.

7

Thanks for the replies! So I can say that if I update the LCD over the SPI bus inside the Timer1 interrupt routine, it will work to transfer only one byte as it needs an interrupt to confirm the transfer? The datasheet of the LCD that I have says 3.3Mhz max, however I didn't test it

8

I think so.
If you use

SPDR = dataToTransfer[x];

then I think it may not interrupt at all, and will instead rely on your Timer1 code to not start another transfer prior to one completing.
Kinda guessing. Do you have an oscilloscope to monitor pulses while the LCD updates happen to confirm?