On Fri, Feb 4, 2011 at 4:34 PM, Gilles Chanteperdrix < [email protected]> wrote:
> 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? User space. > How > long do you spin? > > 50000 nsec. R. >
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
