Hi,
I've returned to a subject that needs clarification!

If there are SPI peripherals, using the SPI_CLK and there are INTERRUPTs too.

Does an INTERRUPT affect the SPI_CLK in anyway?

The SPI needs to READ a whole sentence from each peripheral with no breaks. e,g, before the READing changes.
Camerart.

 

Does an INTERRUPT affect the SPI_CLK in anyway?

Generally No, but it may depend on which micro you are using, and whether it is configured as a master or a slave.
If you are reading from several peripherals with one MCU, then it will only work if the MCU is configured as the master.
In most MCUs I have used, writing to the SPI data register causes it to issue 8 (or more) clock pulses, output the data you have written on MOSI and input new data on MISO. When a byte has been received it triggers an interrupt. Until there is another write to SPI data, it doesn't issue any more clocks.

 

Generally No, but it may depend on which micro you are using, and whether it is configured as a master or a slave.
If you are reading from several peripherals with one MCU, then it will only work if the MCU is configured as the master.
In most MCUs I have used, writing to the SPI data register causes it to issue 8 (or more) clock pulses, output the data you have written on MOSI and input new data on MISO. When a byte has been received it triggers an interrupt. Until there is another write to SPI data, it doesn't issue any more clocks.

Hi I0,
Using 18F46K20 in this case, running at 8mHz.
It is set as SPI MASTER with app 4xperipherals as SLAVES.
If there is another HW peripheral, that uses an INTERRUPT (In one case I have one that interrupts at 1/ms. would they all play happily together?
C.

 

Hi I0,
Using 18F46K20 in this case, running at 8mHz.
It is set as SPI MASTER with app 4xperipherals as SLAVES.
If there is another HW peripheral, that uses an INTERRUPT (In one case I have one that interrupts at 1/ms. would they all play happily together?
C.

Is that a hardware interrupt separate from the SPI?

 

Is that a hardware interrupt separate from the SPI?

Hi I0,
Yes, CCP2, in this instance.
C

 

In that case there's plenty of scope for getting your SPI peripheral into a complete muddle, as the interrupt can occur whilst data is being transferred from any of the other peripherals.
In the interrupt service routine, set a flag to indicate that there is data at the peripheral that generated the interrupt: do nothing else in the interrupt service routine.
When a data transfer (from any of the other devices) is complete, check the flag, if the flag is true download the data from the peripheral with the interrupt and reset the flag.
How long can the device that generates interrupts wait before its data gets overwritten? Hopefully, it is longer that the time one of the other devices takes to download its data.

 

In that case there's plenty of scope for getting your SPI peripheral into a complete muddle, as the interrupt can occur whilst data is being transferred from any of the other peripherals.
In the interrupt service routine, set a flag to indicate that there is data at the peripheral that generated the interrupt: do nothing else in the interrupt service routine.
When a data transfer (from any of the other devices) is complete, check the flag, if the flag is true download the data from the peripheral with the interrupt and reset the flag.
How long can the device that generates interrupts wait before its data gets overwritten? Hopefully, it is longer that the time one of the other devices takes to download its data.

Hi I0,
In that case there's plenty of scope for getting your SPI peripheral into a complete muddle, as the interrupt can occur whilst data is being transferred from any of the other peripherals.
Ok.

I've been reading the D/Ss, and it's going to take quite a while to figure out DATA READY FLAG.
Somewhere in my memory, I think the peripheral BUFFER, will hold the sentence, while BYTEs are being picked off one at a time, until it runs out, then send 0XFF.
Thanks.
C

 

Hi I0,
In that case there's plenty of scope for getting your SPI peripheral into a complete muddle, as the interrupt can occur whilst data is being transferred from any of the other peripherals.
Ok.

I've been reading the D/Ss, and it's going to take quite a while to figure out DATA READY FLAG.
Somewhere in my memory, I think the peripheral BUFFER, will hold the sentence, while BYTEs are being picked off one at a time, until it runs out, then send 0XFF.
Thanks.
C

The key feature is the arrival time of bytes. There is no requirement in SPI that bytes must arrive synchronously. There is not even a requirement that the SPI clock pulses need to be a fixed frequency or period. If you are the master, there CANNOT be randomly arriving incoming bytes - that just cannot happen. Each "transaction involves a byte going out and a byte coming in. There could be an unlimited time between bytes as long as the chip select to the peripheral device remains active. Once you drop a byte into the SPI data register you can go away for as long as you want before you have to come back, read the received byte, and send out the next one or end the transaction by making the chip select inactive.

 

The key feature is the arrival time of bytes. There is no requirement in SPI that bytes must arrive synchronously. There is not even a requirement that the SPI clock pulses need to be a fixed frequency or period. If you are the master, there CANNOT be randomly arriving incoming bytes - that just cannot happen. Each "transaction involves a byte going out and a byte coming in. There could be an unlimited time between bytes as long as the chip select to the peripheral device remains active. Once you drop a byte into the SPI data register you can go away for as long as you want before you have to come back, read the received byte, and send out the next one or end the transaction by making the chip select inactive.

Hi P,
Am I correct then that while the CHIP SELECT to any peripheral is active, and HW INTERRUPTs occur, each retrieve their next BYTE, in turn or as the timing allows, until the end of each buffered STRING?
C

 

Hi P,
Am I correct then that while the CHIP SELECT to any peripheral is active, and HW INTERRUPTs occur, each retrieve their next BYTE, in turn or as the timing allows, until the end of each buffered STRING?
C

I'm not sure that chip select and the interrupt are related. Here's the deal. Normally the interrupt will be disabled. You have a 3-byte message to send. You activate chip select, send the first byte, enable the interrupt and go back to what you were doing. When the interrupt occurs, you read the incoming byte and send the second byte leaving the interrupt enabled and return from the interrupt. When the second interrupt occurs, you read the second byte, send the third byte and return from the interrupt. When the third interrupt occurs, you read the third byte, take the chip select inactive, disable the SPI interrupt and return from the interrupt. There is no requirement to respond to any of the SPI interrupts immediately. The MASTER is controlling the SPI bus and no new SPI events can happen from the time of the SPI interrupt until it is serviced, as long as the SPI chip select remains active. In a priority scheme this interrupt should have a low priority.

Does this clarify things for you?

 

I'm not sure that chip select and the interrupt are related. Here's the deal. Normally the interrupt will be disabled. You have a 3-byte message to send. You activate chip select, send the first byte, enable the interrupt and go back to what you were doing. When the interrupt occurs, you read the incoming byte and send the second byte leaving the interrupt enabled and return from the interrupt. When the second interrupt occurs, you read the second byte, send the third byte and return from the interrupt. When the third interrupt occurs, you read the third byte, take the chip select inactive, disable the SPI interrupt and return from the interrupt. There is no requirement to respond to any of the SPI interrupts immediately. The MASTER is controlling the SPI bus and no new SPI events can happen from the time of the SPI interrupt until it is serviced, as long as the SPI chip select remains active. In a priority scheme this interrupt should have a low priority.

Does this clarify things for you?

Hi P,
This thread is a bit wordy, for a dyslexic, and misunderstandings are easy.

There are 2x Peripherals, in this example.
1x is controlled by the MASTER with SPI, at SPI CLK speed, exchanging BYTES.
1x is HW INTERRUPTING at 1/ms, and exchanging BYTES.
Can they both work together?
C.

 

Hi P,
This thread is a bit wordy, for a dyslexic, and misunderstandings are easy.

There are 2x Peripherals, in this example.
1x is controlled by the MASTER with SPI, at SPI CLK speed, exchanging BYTES.
1x is HW INTERRUPTING at 1/ms, and exchanging BYTES.
Can they both work together?
C.

Yes they can because the interrupt rate of the SPI peripheral device can be controlled by the SPI master which is also responsible for the byte exchanges with the other device. All you need to do is insure is that one of the two processes can be delayed for a short amount of time to service the other. This is easy if the processor allows interrupt service routines to interrupt other service routines. If not, then it should still be manageable in all but the most extreme cases. If you have some numbers for the arrival time of the bytes of data and the time to service the requests, it might help to dispel some of your concerns.

Can't help with the dyslexia, there is no real good substitute that I am aware of.

 

They don't exactly work "together" as in "simultaneously". One has to wait for the other to finish.
Suppose that a read from an SPI EEPROM was happening when the interrupt arrived from the other peripheral.
The EEPROM read must be completed and its CS pin negated, before the read from the other peripheral can start.
Otherwise the EEPROM read would have to be re-started, by re-sending the "start" command and the read address.

 

They don't exactly work "together" as in "simultaneously". One has to wait for the other to finish.
Suppose that a read from an SPI EEPROM was happening when the interrupt arrived from the other peripheral.
The EEPROM read must be completed and its CS pin negated, before the read from the other peripheral can start.
Otherwise the EEPROM read would have to be re-started, by re-sending the "start" command and the read address.

Hi I0,
Ok, thanks.

Previous replies from other sources implied that there is enought time for each different peripheral READ BYTE to be woven into the PIC.
I've added a quote from another forum, for a similar question:

It must be possible somehow, so I'll have to get all the timings, and see if I can switch each READ in a compromise.
C.

The used time is a small percentage of the available time. The 1mS interrupt does not use 1mS, it uses a few cycles every mS. The servo stuff uses a few cycles when a servo pulse is generated. A usart should use a few cycles when a byte is received. This idea that the chip is being stretched processor wise is nonsense. It can easily do what it's doing and the GPS stuff as well. Where "So 4mS "free" with older 1 - 2mS analog servos, or no free time with 0.5 - 2.5mS digital servos."comes from I have no idea, it's complete nonsense. It's an interrupt - not blocking code!!!!!!!! The "free" time is very close to 100% - let's have a guess at greater than 95%.

 

No, you can’t do it a byte at a time from each peripherals, because you have to assert and negate the CS lines, and every time you assert CS yiu have to send a new command.
I’ll draw you a big timing diagram when I get home from work!

 

No, you can’t do it a byte at a time from each peripherals, because you have to assert and negate the CS lines, and every time you assert CS yiu have to send a new command.
I’ll draw you a big timing diagram when I get home from work!

Hi I0,
To clarify: Is it correct that a BYTE at a time from each peripheral is not possible, even though the INTERRUPT BYTES are loaded into a BUFFER in HW?

I appreciate a diagram, but best to wait till later, please.
C

 

Which interrupt bytes are you thinking of?

 

Which interrupt bytes are you thinking of?

Hi I0,
From memory: All of the INTERRUPTS I use are HW. PICs have different HW INTERRUPTs, UART, QEI, CCP (comparison) TIMERS etc.
e,g The UART waits for the start of a message, gets an INTERRUPT and puts the DATA in a BUFFER all in HW.
C

 

Hi I0,
From memory: All of the INTERRUPTS I use are HW. PICs have different HW INTERRUPTs, UART, QEI, CCP (comparison) TIMERS etc.
e,g The UART waits for the start of a message, gets an INTERRUPT and puts the DATA in a BUFFER all in HW.
C

This isn’t the UART. UARTs generally have FIFOs, and SPIs don’t.
SPIs only receive data when YOU tell them to output clock pulses.

 

This isn’t the UART. UARTs generally have FIFOs, and SPIs don’t.
SPIs only receive data when YOU tell them to output clock pulses.

Hi I0,
True.
I am talking about PIC hardware INTERRUPTS, that I thought went on behind the scenes. (I gave illustrations of different types of PIC HW INTERRUPTs for anyone who's interested)

I understand how SPI works with CS and CLK.
C.