|
From: | Mauro Garcia Acero |
Subject: | Re: [Paparazzi-devel] SPI with 16bit on LPC2148(YAPA) |
Date: | Fri, 22 Feb 2013 20:45:32 +0100 |
Thanks for all the suggestions, I will
work this weekend on that. I hope to come with good news soon. Good weekend, Mauro. From:
address@hidden
[mailto:address@hidden On Behalf Of Felix Ruess Hi Mauro, there is no magic going on that will automatically add source files if
you add headers. Of course it doesn't complain about the structures, since they are
defined in the header... So you need to explicitly add the source files for spi. As Stephen already pointed out, it's best to use a subsystem for the
imu at the moment. Have a look at e.g. conf/firmwares/subsystems/shared/imu_aspirin_common.makefile Cheers, Felix On Fri, Feb 22, 2013 at 5:30 PM, Michal Podhradsky <address@hidden>
wrote: Hi Mauro, 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, From: paparazzi-devel-bounces+m.garcia=address@hidden
[mailto:paparazzi-devel-bounces+m.garcia=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] |