discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Timers


From: Jeremy Chew
Subject: Re: [Discuss-gnuradio] Timers
Date: Fri, 3 Nov 2006 14:06:24 +0800

This seems like a good idea, though kind of unusual to me. Is this a standard or recommended way of implementing timed processing in Unix so as to allow multiple timed events to be scheduled?

----- Original Message ----- From: "Daniel O'Connor" <address@hidden>
To: <address@hidden>
Cc: "Eric Blossom" <address@hidden>; "Jeremy Chew" <address@hidden>
Sent: Thursday, November 02, 2006 7:39 AM
Subject: Re: [Discuss-gnuradio] Timers

Would it be possible to spawn another thread and use usleep or select to wait
for the desired length of time?

(This is addressed to the OP but I deleted that message)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
I plan to use setitimer() for my GR development. I understand that each
Linux process can have only one timer at a time. Is this right?

If so, does GR use the timer? How do I avoid clashing with the GR over the
timer?

In general, we handle time by counting samples.  For example, with the
USRP as the i/o device, we _know_ the actual data rate across the USB.

We don't explicitly use setitimer, but there's a chance that Python
could be using it behind the scenes for reasons of it's own.

FYI, when the high-resolution timing support is complete, it will
effectively be counting samples too -- only this time out in the FPGA.

Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]