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

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

at91_enthus wrote:
> On Thu, Feb 3, 2011 at 4:28 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> 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.
>>
> 
> Rookie mistake. Indeed, I can have everything in userspace using Xenomai. I
> wrote a simple program that did a periodic job every 100 us and the jitter
> was very small (around 20 us without load and around 35 us with SSH-ing and
> Xenomai compilation running on board).
> 
> Somewhat unrelated to this thread, I found that when I invoked
> rt_task_set_periodic(), I got very precise timings (as expected). However,
> when I tried to insert small delays using rt_timer_spin(), the errors
> (t_meas - t_spin_func_argument) were not large, but noticeable. For example,
> I can precisely measure a 50 us periodic task on the scope. With the same
> interval in rt_timer_spin(), I get 55-60 us. As far as I understood, all
> timing-related functions use the same time base, so what's the reason for
> this behavior?

Where do you use rt_timer_spin, in kernel-space, or in user-space? How
long do you spin?


> 
> 
> Regards,
> R.
> 


-- 
                                                                Gilles.