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

[Mauro Garcia Acero]

Tx Felix for your remarks,

 

I'm working right now in making more clear the code I have done and more readable. I will try to make different transactions for each communication, good idea.

 

I will push the new code as soon as it is ok.

 

Best regards,
Mauro.

 

 

---

From: address@hidden [mailto:address@hidden On Behalf Of Felix Ruess
Sent: martes, 26 de febrero de 2013 23:00
To: Paparazzi devel list
Subject: Re: [Paparazzi-devel] 16b vs 8b YAPA SPI and other subjects

 

Hi Mauro,

 

first a general note:

If you have problems with your code, the easiest and quickest way is to commit it and push it to github.

Then you can directly point it out what you did and we don't have to guess what exactly you did/didn't do...

 

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).

 

Hm.. The max1168 driver uses 8 data words and according to Gautier works fine on lpc.

 

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

 

Yes.

 

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)

 

Yes.

 

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.

 

Yes.

 

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 |

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

 

Patches/pull requests with updated doxygen comments for all this in sw/airborne/mcu_periph/spi.h would be very much appreciated!!

This will then automatically land in the generated docs at http://paparazzi.github.com/docs/latest/group__spi.html

 

 

 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.

 

Did use the same spi_transaction for these subsequent requests?

If you submit multiple requests in a row you have be careful not to overwrite the values in the previous spi_transaction structure.

Either make sure the previous one is finished if you want to reuse the transaction structure or make a separate one for each request.

 

Hope that is of some help for now...

But as I said, the often repeated mantra of "show me the code" is also very true here ;-)

 

Cheers, Felix