Well, that's easy then. You can communicate at 115200 baud with an
AVR, which you can get with a 10-bit DAC and a UART for < $4.00.
Since you don't care about a dropped byte here and there, you can
probably use the AVR's internal oscillator. Together with the ARM
board's power supply and logic-level RS232, this brings your grand-
total part count to 1. Well, I 'suppose a bypass cap wouldn't hurt,
so 2 parts.
Now you can use all your AVR's RAM as a buffer, and have it control
the DAC timing with interrupts, leaving your ARM to mosy along
keeping the AVR's buffer filled with chunky writes to the serial
port. So now the ARM needs to only wake up every 125 us * AVR RAM
size. Or every 50-60 ms or so with a 512-byte buffer.
Cake!
I mean, why write cranky non-portable kerner drivers when they can
just be implemented in hardware?
Did I really just say that?
-I
On Sep 24, 2009, at 10:35 PM, Blair wrote:
> 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
>
>
>
------------------------------------
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/
|