paparazzi-devel
[Top][All Lists]
Advanced

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

Re: [Paparazzi-devel] Please help regarding code for BOOZ MS2100 magneti


From: Felix Ruess
Subject: Re: [Paparazzi-devel] Please help regarding code for BOOZ MS2100 magnetic sensor
Date: Thu, 10 Feb 2011 22:14:55 +0100

Hi Thomas,

as far as I can tell the procedure should be fine.

As you said the mag conversion is started after the ADC max11680 is read and the mag is currently idle:
* mag is selected and the request for the next axis sent (and IMU_SSP_STA_BUSY_MS2100)
* on the next SSP interrupt the dummy reply is read and the mag unselected (imu_ssp_status back to IMU_SSP_STA_IDLE)
* now this might take a while and the adc is read again in between
* when you get the external interrupt that the mag conversion is finished ms2001_status is set to MS2001_GOT_EOC
* on the next SSP interrupt the max is read again and since a mag conversion is ready, the mag is selected and a request to read the result is sent to the mag
* since imu_ssp_status is now MU_SSP_STA_BUSY_MS2100 again on the next SSP interrupt the measurement is read (in Ms2001OnSpiInt) and the mag again unselected.
** if there are still axes missing, a new measurement is requested (mag selected again, the dummy reply read on the next interrupt and the mag unselected again)
** if we have all three axes, the mag data is marked as available and then read in the imu mag handler

So it should be fine if the actual mag measurements take quite a while...

So it might really be some hardware problem.

P.S. If you are making a new board, it would make sense to use the STM32 and not the LPC anymore. And the HMC5843 mag....

On Sun, Feb 6, 2011 at 7:48 PM, Thomas Wuensche <address@hidden> wrote:
Hi all,

Coming from some problems with my magnetic sensor I tried to
study and understand the code for taking measurements on
the BOOZ IMU.

Situation is that I have unreliable measurements from the
sensor. The unreliability is not (only?) in the measurement
values, but in how regularly they are taken. Sometimes
I get values, sometimes not.

Trying to understand what is happening I see that there are
a number of state machines, some driven from the cyclic
processing in the main loop, some driven from three different
interrupts.

What I see is that reading of the A/D converter on the IMU is
started within the 512Hz main periodic process. Correspondingly
there is a chip select to the A/D converter approx. every 2ms,
the request for a reading, the reading complete signal to be
processed in the interrupt. So far everything is OK, I can follow
the relevant signals on the scope.

What I understand is that after the reading of the A/D is complete,
the reading for the magnetic sensor is started, one component at
a time. When measurements are running, I then see the signals
to/from the magnetic sensor. The observation is that the comple-
tion of the measurement cycle is longer than the main periodic
cycle (handling A/D converter). So before the magnetic sensor
signals complete, there are 1 or two further samplings of the
A/D converter. Should it be that way? Is the code safe to handle
that?

Even if that is running, samples are sometimes taken only once
a second, sometimes faster, sometimes slower. This is something
I don't understand at all. I think if one magnetic measurement
is completed, the next should be started after the next A/D
sample is complete, right? But I do not even see the chip select
to the magnetic sensor get active, so the guess is that the
software does not trigger the next conversion.

And sometimes I get no conversion at all. The magnetic sensor
receives a measurement request once after power up, and then
nothing happens any more.

Basically I think my magnetic sensor may be somehow broken from
the hardware side, sometimes delivering measurements, sometimes
not. But despite that I wonder how stable the mixture of the
different state machines is, if a measurement takes longer than
to the beginning of the next run of the main periodic loop.
If it would be stable, at least further measurements should be
tried, even if one fails.

I'm willing to investigate that further, but it would be nice
to have some information on what are the (conceptual) prerequi-
sites of the existing code. Is the completion signal for the
magnet expected to be set before the next run of the main
periodic loop? In this case structure would be clear and there
could be no mix of the different interrupt procedures. If not,
how are the different state machines interlocked, given the
fact that some are handled in the interrupt. Is the common
hardware (SPI access) locked sufficiently so that not an access
from the main loop or an interrupt can be disturbed by another
interrupt (accessing SPI to one of the peripherals while the
chip select to the other is also set)? What is the intended
mechanism for that?

Thanks a lot for any information,

Thomas
--
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106
Phone: +49-8441-490260
Fax  : +49-8441-81860
http://www.ems-wuensche.com

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


reply via email to

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