SPI Master Slave Communication

A catchall for PSoC3 discussions not captured by the other forums.

Moderator: ericb

SPI Master Slave Communication

Postby tylerjaywilson » Thu Feb 06, 2014 11:21 am

I am trying to communicate from a PSOC3 SPI Master to a PSOC4 SPI slave. I can see on the scope that the data is being sent to the slave but I am failing to receive any data back from the slave.

PSOC3 psuedo code:
for(;;)
{
Chip Select goes low
Write TX data
wait for tx fifo to be emtpy
chip select goes high

chip select goes low
Read Rx data
chip select goes high
}

PSOC4 pseudo code:
for(;;)
{
SPI_S_SpiUartWriteTxData(0xDB);
dat = SPI_S_SpiUartReadRxData();
}

I hope that this is enough information to get started. I can see that I am sending data on the oscilloscope to the psoc4 slave but i cannot seem to read in the data.
Also, I do not see any data being sent back to the psoc3 master.

Any ideas?

Thanks
tylerjaywilson
Bite-Size Cheese
Bite-Size Cheese
 
Posts: 14
Joined: Tue Jul 16, 2013 1:52 pm

Re: SPI Master Slave Communication

Postby tylerjaywilson » Thu Feb 06, 2014 1:05 pm

I was trying to run my SPI Master in an interrupt when the SPI slave set a pin high indicating that data was available to be sent. It appears that I am not able to run SPI communication in the interrupts. When I removed my code from the interrupt, the communication began to work flawlessly. Hopefully this helps others.

Can you do SPI communication in an interrupt?
tylerjaywilson
Bite-Size Cheese
Bite-Size Cheese
 
Posts: 14
Joined: Tue Jul 16, 2013 1:52 pm

Re: SPI Master Slave Communication

Postby bobmarlowe » Fri Feb 07, 2014 1:06 am

Can you do SPI communication in an interrupt?

Of course not!
Handling an interrupt will prevent *ALL* other interrupts from beeing handled until the "return from interrupt" (RETI) instruction is executed or interrupts are enabled again.
Since any I/O communication will wait (in a loop) for some conditions getting active this would stall all other parts of your program.
Additionally the I2C (and some other) communication uses interrupts for themselfes so that prohibits already your nested handling.

Some rule-of-thumb for handlers are:
- keep them short, avoid loops
- DO NOT WAIT for a condition
- avoid function calls within the handler, that increases generated push / pops
- do not forget to remove the cause of the interrupt, otherwise it will be fired again when exiting handler
- best practice: Remove cause, set a flag that is looked at in main-loop and acted on (and reset when done)

Happy coding
Bob
User avatar
bobmarlowe
The Big Cheese
The Big Cheese
 
Posts: 1490
Joined: Thu Oct 06, 2011 2:03 am
Location: Germany


Return to “%s” PSoC3 General

Who is online

Users browsing this forum: No registered users and 2 guests