|
From: | Mauro Garcia Acero |
Subject: | Re: [Paparazzi-devel] SPI with 16bit on LPC2148(YAPA) |
Date: | Fri, 22 Feb 2013 08:41:21 +0100 |
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, From:
address@hidden
[mailto:address@hidden On Behalf Of Stephen Dwyer 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
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 Hi, 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, _______________________________________________ Paparazzi-devel mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
|
[Prev in Thread] | Current Thread | [Next in Thread] |