Yes, I managed to get myself into trouble with the scheduler resolution. I
wrote some software timer based code on my Mac which cheerfully lets you run at
the microsecond level (I think). Cross-compiled it and ran it on the 7260 and
it totally went south.
Seems like there's all this power to the hardware that's inaccessible to a
standard app. One example is why the ADC24 docs claim you can get 1Msps
performance but I've never been able to get more than about 100Ksps. Hardware
timers are another example. Seems like there should be at least an open-source
driver for this because it's seems such a basic thing to want to do. Seems
like you should be able to run the timer and have it generate an IRQ and your
user-space code is waiting at a poll call.
What I had in mind was the poor-man's WAV player using the DAC portion of a
9700 board. Use the WAV data to set the DAC value and hook it to an amp. Of
course that means you need to set the value at regular intervals e.g. 125 usecs
for an 8k WAV file.
But now I'm sort of seeing the futility of the approach when it comes to
designing a commercial product. The DAC option on the 9700 costs $30. Maybe
you spend a couple of bucks on an amp circuit. A Turtle Beach USB Audio dongle
is $40. Of course that means getting 2.6 running on the 7260 which is one of
my goals anyway.
--- In Ilya Goldberg <> wrote:
>
> I don't believe you can actually do this in user-space with a
> preemptive kernel.
> Using the hardware timer doesn't help you unless all you need is to
> time a 125 us interval every 10ms or so. If you're doing a periodic
> task every 125 us, there's really no way to do it because this is a
> much finer resolution than the kernel's scheduler (10 ms on a stock
> kernel).
>
> The general answer to FA'd timer questions is:
> There is no way to send your process to sleep for a time period
> shorter than the kernel's scheduler resolution (otherwise known as a
> "jiffy"). This is 10ms on the stock TS kernel (and most other
> kernels), and no shorter than 1ms on any "normal" kernel.
> Regardless of the parameter you use, usleep() will cause your process
> to sleep for at least one jiffy (10ms).
> You can write a busy-loop checking on a hardware timer and consume
> 100% of the CPU in the process, but even this loop will be preempted
> by the kernel, which will sleep your process for as long as it wants,
> though generally for no more than one jiffy.
>
> I had a similar issue, and ended up implementing what I needed on an
> AVR (which has gcc support), and communicating more chunky and less
> time-sensitive data to the ARM CPU over RS232 (and as a bonus got to
> use a stock kernel, drivers, and portable software and hardware).
> Another option might be to implement something on the FPGA.
> A custom kernel driver may be the way to go too. Depending on what
> you're doing in those 125 us, an 8 kHz interrupt for the kernel might
> be OK.
> Heck, there might even be a way to do this with "real-time"
> extensions, but all of these are hacks around the fact that user-
> space can't be used for periodic tasks occurring at a higher
> frequency than the kernel's scheduler.
> -I
>
> On Sep 24, 2009, at 2:33 PM, Blair wrote:
>
> > --- In Jim Jackson <jj@> wrote:
> >>
> >>
> >>
> >>
> >> On Wed, 23 Sep 2009, Blair wrote:
> >>
> >>> Question: The T4 hardware timer can run at about 980kHz. What's the
> >>> fastest you can make use of it in a user space app? I'd like to
> >>> be able
> >>> to do a periodic task every 125 microseconds or maybe half that.
> >>> Do I
> >>> have to write a kernel driver to do this?
> >>
> >> This is an FAQ. Please try and search back in the group.
> >>
> >
> > Got anything more definitive to go on? I've bee searching hardware
> > timer, T4 timer, etc and all I seem to be able to find are comments
> > like "yeah you can do that" without the actual solution. If this
> > is a FAQ, where is the FAQA (Frequently Asked Question Answer), or
> > ATFAQ (not related to AFLAC). Source code would be useful. I've
> > tried the T4timer.c code sample but what I'm seeing is the timeout
> > if-then lines overshooting the desired time by huge amounts.
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|