lkml.org 
[lkml]   [2008]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Toggling GPIO at 38Khz
Hello Jon,

> So how do I reliably generate 38Khz without destroying latency in the
> system? I also don't want to measure the speed of the code I'm
> executing - same code has to run on 90Mhz ARM and 3Ghz Core2. If a do
> a loop with nanosleep() I need to know how fast my code is to subtract
> it's execution time form the sleep time. The existing LIRC code works
> this way and measures it's timing loop.
> hrtimers look promising, but hrtimers doesn't have a periodic API. Is

Hm, 38 kHz is a period time of 26us, for a simple clock you need at
least a twice this frequency, so you need a interrupt every 13us.
Looking at a 200MHz ARM processor (AT91 for example), the HRtimer
framework causes about 100-150us of work after each interrupt. So,
that will probably not work on a 90MHz processor...
nanosleep has similar effects in the system, so that will not work either.
Looking at a worst case interrupt latency of about 50us (still at
200MHz ARM) you still won't get an accurate 13us interval, and then we
are not talking about the execution time of the code you want at this
frequency...

So, if you want such things use a FIQ on ARM, or handle the whole
burst on a busy-idle base, while polling some accurate timer routine
(like sched_clock() for example if its implementation is accurate
enough, and do it in a non-preemptable section, 1 preemption and you
might be preempted for 50us or more), but then you will also run into
problems because of the lengthy execution time (0.79ms)...
Notice that on X86 this is not doing much better, on preempt-RT, the
worst case latency on X86 is about 30us...

So, this will not be an easy job... You probably know by now why it is
implemented this way currently in LIRC...


Good luck ;-)


Remy


> there a technique for creating periodic timing that doesn't accumulate
> error caused by rescheduling the timers? If I need to send 30 pulses
> of 38Khz, it is more important that the total time be (1/38000)*30 =
> 0.7894ms than it is for each pulse to be generated at exactly 26.3us
> intervals.
>
> Are there other techniques for generating pulse trains in the 36-56Khz
> range on a simple GPIO pin? Anyone have some sample code?
>
> --
> Jon Smirl
> jonsmirl@gmail.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>


\
 
 \ /
  Last update: 2008-10-08 20:59    [W:0.055 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site