Issue about SPI

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Issue about SPI

Jump to solution
767 Views
nlocatel
Contributor I

Hi everyone,

 

I'm using the MCF51QE128 processor in a proyect and I'm facing the following problem. When I communicate with a SPI slave, I have to wait for at least 800 microseconds before I can read de slave answer from the input buffer. Otherwise, the values I read from de buffer are dirty. The SPI in the processor is configured in a bean, I only write and read the buffer, the answers fron the slave are as expected, but it's this delay issue I would like to improve.

 

Anyone?

Thanks,

Nicolas

Labels (1)
0 Kudos
1 Solution
431 Views
armistej
Contributor III

Remember that SPI is a two-way exchange of data.  As your master sends its first byte to the slave from its TX buffer, the slave is also sending a byte back to the master, using whatever "dirty" information is left in its TX buffer.

 

By the time you read the first RX byte in the slave software, then try to process it to determine what  the master was asking for, it is possible that the master will already be clocking out the second byte of data from the slave (remember the SPI clock keeps on being generated).  So, the earliest that the master will get the reply from the slave will be in its 3rd RX byte.

 

Everyone is used to "dumb" devices like Serial EEPROM or Serial FLASH chips as SPI slaves, where they can respond almost  instantly with data.  Just remember that they are implemented as pure digital logic, with minimal delay (certainly less than the clock time between the end of one RX byte and the start of the next one) needed to transfer data into their SPI TX buffer.

 

Software-based SPI slaves, on the other hand, can only respond AFTER their interrupt routine has activated, read the SPI RX data register, do some logic, etc, and then move new data into the SPI TX data register.  All of this takes more time than a "dumb" device.

 

I hope this explanation helps you understand.

 

Another way to understand your system is to drive some general purpose IO pins on the slave and master at each phase of the SPI transaction in your software.  Looking on an oscilloscope, you can see the timing.  Nothing on a CPU occurs in zero time.  Your debug code will add a small time delay to your code, but that's the price you pay for adding debug, and it's generally an unavoidable overhead.  Just be sure to write your code as tightly as possible (no calls to functions - avoid Processor Expert and do it directly with as few opcodes as necessary)

 

Also, watch your interrupt priorities.  Make sure SPI is the highest priority possible.

 

J

View solution in original post

0 Kudos
1 Reply
432 Views
armistej
Contributor III

Remember that SPI is a two-way exchange of data.  As your master sends its first byte to the slave from its TX buffer, the slave is also sending a byte back to the master, using whatever "dirty" information is left in its TX buffer.

 

By the time you read the first RX byte in the slave software, then try to process it to determine what  the master was asking for, it is possible that the master will already be clocking out the second byte of data from the slave (remember the SPI clock keeps on being generated).  So, the earliest that the master will get the reply from the slave will be in its 3rd RX byte.

 

Everyone is used to "dumb" devices like Serial EEPROM or Serial FLASH chips as SPI slaves, where they can respond almost  instantly with data.  Just remember that they are implemented as pure digital logic, with minimal delay (certainly less than the clock time between the end of one RX byte and the start of the next one) needed to transfer data into their SPI TX buffer.

 

Software-based SPI slaves, on the other hand, can only respond AFTER their interrupt routine has activated, read the SPI RX data register, do some logic, etc, and then move new data into the SPI TX data register.  All of this takes more time than a "dumb" device.

 

I hope this explanation helps you understand.

 

Another way to understand your system is to drive some general purpose IO pins on the slave and master at each phase of the SPI transaction in your software.  Looking on an oscilloscope, you can see the timing.  Nothing on a CPU occurs in zero time.  Your debug code will add a small time delay to your code, but that's the price you pay for adding debug, and it's generally an unavoidable overhead.  Just be sure to write your code as tightly as possible (no calls to functions - avoid Processor Expert and do it directly with as few opcodes as necessary)

 

Also, watch your interrupt priorities.  Make sure SPI is the highest priority possible.

 

J

0 Kudos