paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] SPI with 16bit on LPC2148(YAPA)


From: Michal Podhradsky
Subject: Re: [Paparazzi-devel] SPI with 16bit on LPC2148(YAPA)
Date: Fri, 22 Feb 2013 09:30:06 -0700

Hi Mauro,

check the file "ap_srcs.list" in var/MyPlane - I believe you have to add a flags USE_SPIX, SPI_MASTER and USE_SPI_SLAVEX (X=1,2,3) to the makefile (or the module xml file). Then it should properly compile and initialize, if that is the problem.

Michal


On Fri, Feb 22, 2013 at 12:41 AM, Mauro Garcia Acero <address@hidden> wrote:

Dear Stephen,

 

I have begun with the creation of the driver in module, a first draft of a .c and .h and try to compile it. But curiously, when I try to build it, even if I put

#include "mcu_periph/spi.h", trying to be independent of the architecture, it doesn't import the spi.o in the final var/MyPlane/.... and then it doesn't recognize the functions spi_init and spi_submit. But strange thing, it does not complain with the spi_transaction and spi_periph structures.

 

Well, I would try to create the subsystem instead from the beginning.

 

Thanks for the info,
Mauro.

 

 

 


From: paparazzi-devel-bounces+m.garcia=address@hidden [mailto:paparazzi-devel-bounces+m.garcia=address@hidden] On Behalf Of Stephen Dwyer
Sent: viernes, 22 de febrero de 2013 0:45


To: address@hidden
Subject: Re: [Paparazzi-devel] SPI with 16bit on LPC2148(YAPA)

 

Hello Mauro,

 

I think for a something as critical as an IMU, it is a better idea to use a Subsystem style of integration. You will have better control over timing and order of execution (i.e. run the IMU sampling before the AHRS estimation before the control loops).

 

I have added a little more information about how to write a subsystem as per the other email here:

 

Thanks,

-Stephen Dwyer

 

On Thu, Feb 21, 2013 at 1:14 AM, Mauro Garcia Acero <address@hidden> wrote:

Dear Stephen,

 

I saw your mail after I have sent mine. Ok, I will try to make a subsystem, but I will begin with a module that seems easier to implement for me.

 

If I have any doubts how to change from one to another, I will ask in this mail list.

 

Best regards,

Mauro.


From: paparazzi-devel-bounces+m.garcia=address@hidden [mailto:paparazzi-devel-bounces+m.garcia=address@hidden] On Behalf Of Stephen Dwyer
Sent: miércoles, 20 de febrero de 2013 23:45


To: address@hidden
Subject: Re: [Paparazzi-devel] SPI with 16bit on LPC2148(YAPA)

 

Hello Mauro,

 

Did you see my other email on the other thread about the ADIS device? Right now the best is to probably write a subsystem (as opposed to a module), as that is the general strategy for now.

 

Also, DEFINITELY use the non-arch specific spi.c/h as this is the point - the underlying arch part makes it compatible with different processors but shouldn't really be seen by the peripheral driver using the spi mcu_periph driver. That way it will be compatible with both lpc and stm32 boards.

 

Thanks,

-Stephen Dwyer

 

On Wed, Feb 20, 2013 at 3:31 PM, Mauro Garcia Acero <address@hidden> wrote:

Thanks Hienrich and Gauthier for your comments,

 

There is any module that currently uses the lpc21/mcu_periph/spi_arch for taking a look? I had the v4.2 branch, that's why I didn't notice of the new code. I have just updated to the master branch.

 

Seems to me, that the SPI interface that is pinned in the YAPA2 board is the SPI1 (P0.17, P0.18, P0.19, P0.20, ...), could you confirm?

 

In the spi_arch.c, line 359, it makes reference to a document (UM10120_1.pdf page 76) 

Actually that document correspond to other microprocessor and not the LPC2148, so the document I'm using is the UM10139.pdf from NXP and the pinout for the SPI1 is in page 61. SPI1 description is in the chapter 13, page 192.

 

I see that using airborne/mcu_periph/spi[.c|.h] may be much easier than using the first spi_arch, with struct spi_transaction and struct spi_periph. It is quite similar to linux/spidev.h (good work). Should I declare the SPI_MASTER and USE_SPI1 definition in the xml module file or directly in .c file for the device? Which is the typical paparazzi approach? I'm a newbie in paparazzi as you can see.

 

Thank you guys, I will keep you informed.

BR

Mauro.

 

 


From: paparazzi-devel-bounces+m.garcia=address@hidden [mailto:paparazzi-devel-bounces+m.garcia=address@hidden] On Behalf Of Gautier Hattenberger
Sent: miércoles, 20 de febrero de 2013 18:41
To: address@hidden
Subject: Re: [Paparazzi-devel] SPI with 16bit on LPC2148(YAPA)

 

Hi,

The uint8_t* is just a pointer to the beginning of the buffer. If you do 16 bits transfers, 2 bytes are placed in the mcu register at each time (in the master branch).
See https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/arch/lpc21/mcu_periph/spi_arch.c#L192

In the stable branches (v4.0 and v4.2), the "generic" spi driver is barely not used except for some peripherals using 8 bits transfer. The peripherals using 16 bits are actually "manually" configuring and using the spi.

Gautier


Le 20/02/2013 17:34, Mauro Garcia Acero a écrit :

Dear all,

 

The spi.h from mcu_periph is referred to transactions of 8bits words. For example:

extern uint8_t* spi_buffer_input;

 

The same for spi_arch.h from ../lpc21/mcu_periph/, but I have read that the LPC2148 can deal with 8 to 16 bits per transfer.

 

As long as I see in other modules, read registers from SPI devices are made as follows:

 

  spi_buffer_input = (uint8_t*) ....;

  spi_buffer_output = (uint8_t*) ....;

  SpiSetCPHA();

  SpiStart();

 

I don't thing that spliting every command into 2 bytes and sending them independently would work.

 

Any ideas?

 

Best regards,
Mauro.

 

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

 


_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]