Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Gilles Chanteperdrix wrote:
> at91_enthus wrote:
>> On Wed, Feb 2, 2011 at 4:09 PM, Gilles Chanteperdrix <
>> gilles.chanteperdrix@xenomai.org> wrote:
>>
>>> at91_enthus wrote:
>>>> On Wed, Feb 2, 2011 at 3:39 PM, Gilles Chanteperdrix
>>>> <gilles.chanteperdrix@xenomai.org
>>>> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
>>>>
>>>>     at91_enthus wrote:
>>>>     > Hi.
>>>>     >
>>>>     > In order to get better accuracy with Xenomai, I modified the I-pipe
>>>>     > timebase (MCK divider) in arch/arm.mach-at91/at91_ipipe_time.c.
>>>>     > Unfortunately, I cannot mount the rootfs on the MMC, since the MMC
>>>>     > controller is no longer functioning. I tried to change TCx in
>>> kernel
>>>>     > configuration to no avail.
>>>>     > When I switch back to a timebase of 1 MHz, the MMC works fine.
>>>>
>>>>     The thing is that we are a bit tight on AT91. A 16 bits counter is
>>> used
>>>>     for both the timer and the tsc emulation, and this tsc must be
>>> refreshed
>>>>     at least once before it wraps. The problem is that since it is a 16
>>> bits
>>>>     counter, it wraps really fast, on my AT91SAM9263 it wraps in 20 ms,
>>> and
>>>>     since the Linux default period is 10ms we are actually quite close to
>>>>     the limit.
>>>>
>>>>     Anyway, trying to get a better accuracy than 1us is kind of useless
>>> on
>>>>     AT91, since even reading this counter takes more than 1us. So, you
>>> are
>>>>     not in fact improving anything. The 1MHz is even a bit overkill.
>>> On the other hand, the AT91SAM9G20 may be running at a better frequency.
>>> But with latencies in the order of tens of microseconds, having a better
>>> accuracy than 1us still does not make really much sense.
>>
>>
>>
>>> Why do you need
>>> this accuracy?
>>>
>> I want to time stamp the samples from a 8 channel SPI-based ADC. I know that
>> a conversion takes between 3 and 5 microseconds depending on the SPI clock.
>> What I want is to adapt the code to acquire a fixed numb

er of samples in
>> user space (I knew it was a long shot). Plain, Xenomai-free, userland
>> application was out of the question, so I figured that a userspace
>> application in Xenomai run at highest priority should doand the trick.
>>
>> On a second thought, a simple linux kernel module is what I want (this way I
>> can use interrupts and one of the platform's six timers).
> 
> You can use interrupts and the platform's six timers in a Xenomai driver
> based on the RTDM skin. The thing is, what interrupt latency is your target?
> 

To make myself clear:
you got:
- the AD conversion (amounts for an unknown amount of time between 3 and
5us)
- the SPI interrupt
- some unknown interrupt latency which amouunts to several tens of
microseconds with Xenomai, and to a few hundreds of microseconds with Linux.
- the interrupt handler is invoked.

What good will it make to have a timestamping precision with a
sub-microsecond range in the interrupt handler code?

-- 
					    Gilles.