linux-kernel - Re: Toggling GPIO at 38Khz

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3efb10970810081157s5e0f8034n63856d2da42b3ad3@mail.gmail.com>
Date:	Wed, 8 Oct 2008 20:57:30 +0200
From:	"Remy Bohmer" <linux@...mer.net>
To:	"Jon Smirl" <jonsmirl@...il.com>
Cc:	"ARM Linux Mailing List" <linux-arm-kernel@...ts.arm.linux.org.uk>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: 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@...il.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/