[Paparazzi-devel] 16b vs 8b YAPA SPI and other subjects

[Mauro Garcia Acero]

Hey guys,

 

since all this time that you have been helping me, I have the IMU communicating with the YAPA in a dedicated subsystem.

 

Still, I have seen some strange behaviours with the working SPI. I ennumerate them:

 

1) The size of the arrays (spi_trans.in/output_length) and/or the size of the buffers (spi_trans.in/output_buf) seem to desestabilize the driver of the SPI. Every time I try to modify these values over 7 bytes, the port gets blocked and nothing executes anymore (I have a led blinking for testing the execution and it doesn't blink anymore).

 

2) Lengths of the output and input (spi_trans.dss) are referred to words, indendently if they are formed by 8 or 16 bytes.

 

3) The Clock Polarity attribute (spi_trans.cpol) is referred to the voltage level of the clock when there are not transmission going on (what is supposed to be known by some but not by me). So SPICpolIdleHigh means CPOL = 1 and SPICpolIdleLow means CPOL=0 (for the description on http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus)

 

4) Clock Phase attribute (spi_trans.cpha) possibilities SPICphaEdge1 and SPICphaEdge2 are referred to data capture on the first or second edge of the clock, CPHA = 0 and CPHA = 1 respectively.

 

So here there is a small table with the values for each SPI mode. It would be nice to add it in some place on the documentation.

 

-----------------------------------------------

| SPI MODE    |      CPOL      |    CPHA      |

| Mode 0      | SPICpolIdleLow | SPICphaEdge1 |

| Mode 1      | SPICpolIdleLow | SPICphaEdge2 |

| Mode 2      | SPICpolIdleHigh| SPICphaEdge1 |

| Mode 3      | SPICpolIdleHigh| SPICphaEdge2 |

-----------------------------------------------

 

 

But the more strange problem is when I try to send three requests of 3 words each in a row, so, considering 2 bytes words, 6 bytes + 6 bytes + 6 bytes. The second buffer (6 bytes in the middle of the transmission), even if I have completely modified the values, all of them are erased and they are an exact copy of the last 6 bytes.

 

I have tried several ways to get rid of this without success:

1) To put the three requests in different functions and being called separately in a row.

2) To put a big array of 18 elements. This option completely blocks the autopilot pilot (?)

3) To create an pseudo state-machine in a for loop for the three requests using the same array.

4) To declaring three separate tx[7] arrays, initialize with different values for each send and pointing the spi_trans.output_buf = &(tx[0]).

 

None of this options worked. Only if I wait for a whole AP loop before of requesting a new SPI transfer, can I have more than two different transactions.

 

In my case, it is not a big problem because the third measure is the magnetometer, so I can delay the cadence of readings because it is less important that accelerometers and gyroscopes.

 

Anyway, if someone has an idea how to make it work, it would be highly appreciated.

 

Best regards,

Mauro.