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? Regards, R.
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
