From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4D4C7F10.3020703@domain.hid> Date: Fri, 04 Feb 2011 23:34:56 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4D49CF24.9080700@domain.hid> <4D49D608.5020006@domain.hid> <4D4A80F6.5020600@domain.hid> <4D4A8354.7010209@domain.hid> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91) List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: at91_enthus Cc: xenomai@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 >>>>>> >>>>> > 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.