at91_enthus wrote:
> On Thu, Feb 3, 2011 at 4:28 AM, Gilles Chanteperdrix <
> [email protected]> wrote:
>
>> Gilles Chanteperdrix wrote:
>>> at91_enthus wrote:
>>>> On Wed, Feb 2, 2011 at 4:09 PM, Gilles Chanteperdrix <
>>>> [email protected]> wrote:
>>>>
>>>>> at91_enthus wrote:
>>>>>> On Wed, Feb 2, 2011 at 3:39 PM, Gilles Chanteperdrix
>>>>>> <[email protected]
>>>>>> <mailto:[email protected]>> 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.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
