sleep for nanoseconds without using POSIX
Manjeet Singh Chhabra
I have a problem i want to slepp a task for a few nanoseconds.
but i can no use nanosleep because of restriction of not using POSIX methods.
can anyone tell me how can i do this.
Thanks
Manjeet
Paul D. Smith
msc> I have a problem i want to slepp a task for a few nanoseconds.
msc> but i can no use nanosleep because of restriction of not using
msc> POSIX methods.
???
You have a restriction that you _CAN'T_ use POSIX functions, no matter
what?
Bizarre. Why?
--
-------------------------------------------------------------------------------
Paul D. Smith <paus...@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Gary M
with determining if you can do this at all.
"Manjeet Singh Chhabra" <manj...@yahoo.com> wrote in message
news:8d0fbe67.02090...@posting.google.com...
Leonid Rosenboim
it's actual resolution still depends on the system clock interrupts,
which come by default 60 times a second, and if needed could be
stretched to a few thousands Hertz, but for nanosecond resolution
it would require an interrupt rate no processor can sustain.
Therefore, your onlu choise is a busy-loop delay, but for nanoseconds
it would probably sufficie if you simply write a series of CPU instructions
that have a deterministic execution time, either NOPs or accesses to
an uncached memory location.
"Manjeet Singh Chhabra" <manj...@yahoo.com> wrote in message
news:8d0fbe67.02090...@posting.google.com...
Manjeet Singh Chhabra
> %% manj...@yahoo.com (Manjeet Singh Chhabra) writes:
>
> msc> I have a problem i want to slepp a task for a few nanoseconds.
> msc> but i can no use nanosleep because of restriction of not using
> msc> POSIX methods.
>
> ???
>
> You have a restriction that you _CAN'T_ use POSIX functions, no matter
> what?
>
> Bizarre. Why?
that is because out system has such a restriction
do you have any idea how to do this ?
Paul D. Smith
>> %% manj...@yahoo.com (Manjeet Singh Chhabra) writes:
msc> I have a problem i want to slepp a task for a few nanoseconds.
msc> but i can no use nanosleep because of restriction of not using
msc> POSIX methods.
>> You have a restriction that you _CAN'T_ use POSIX functions, no matter
>> what?
>>
>> Bizarre. Why?
msc> that is because out system has such a restriction
Yes, I understood that from your original post. The question is "why?"
Do you also have a rule that you cannot use any ISO C standard
functions, like memcpy(), etc.? Note that the POSIX standard includes
(by reference) all the functions in the ISO C standard, so technically
if you're not allowed to use any POSIX functions you can't use ISO C
functions (malloc, free, strcpy, strcmp, memcpy, memcmp, assert,
etc. etc. etc.), either.
msc> do you have any idea how to do this ?
As others have pointed out there is no way to sleep for less than the
clock tick size of your platform (which you have neglected to
mention)--the tick size is certainly going to be larger than "a few
nanoseconds" unless you're working on very strange hardware indeed! :).
A PPC, for example, uses a tick size of 8 ms (IIRC).
If you want to pause for "a few nanoseconds" and that is a hard limit
(you need it to be pretty accurate) then you have no choice but to spin
in a busy loop.
Luckily for you, I don't think there's any POSIX function which provides
this capability.
I'm interested to know what the VxWorks function that does a calibrated
busy delay loop is, if someone knows it: on QNX for example there is
nanospin()--very nice.
Claudio Potenza
Even if you were allowed (?!) to use nanosleep (what a strange
negative requirement: "don't use POSIX"!!), it would not be of any
help, I believe.
As the reference manual says:
The suspension may be longer than requested due to the rounding
up of the request
to the timer's resolution...
That is, "nanosleep()" has the granularity of the system clock rate.
This is by "default" 60 ticks per second. You can check the exact
value by calling "sysClkRateGet()".
Said another way, nanosleep('1 nanosecond') is exactly like
taskDelay(1) and delays your task anywhere between 0 and 1/60 of a
second
Brett Wilson
busy loop or how to sleep for less than the system tick time which is 1ms in
our system (which is less than what WindRiver recommends and we would like
to go lower!).
Brett Wilson
DSP Software Engineer
General Dynamics
"Paul D. Smith" <paus...@nortelnetworks.com> wrote in message
news:p5wupux...@lemming.engeast.baynetworks.com...
Behzad Abareshi
Tell us why you want a few nanosecs delay in the first place; you may be
pleasantly surprised that what you think you need is often times very
different from what you really need! Talking from my own experience, of
course :-)
joe durusau
to see how long it takes on the average. Note that this is not
really a matter of the task sleeping, it's a matter of the task marking time
and burning CPU time for some short minimum. You can get hardware timers
that will send you an int after a given time delay, (the shortest I've ever
heard
of is 1 uS), but there is no way that you are going to get a repeatable and
calibrated time of say 10 nS unless your task is the only one active at the time
and interrupts are disabled. Note that the hardware timers I mentioned
will give you a _minimum_ delay, not a calibrated _exact_ delay. If you use
a busy loop, remember that it will work only for one specific platform and
that specific version of the OS. I suggest that you probably really don't
need this kind of thing in software. There are people out there who will be
able to fairly easily give you a device that will output one or several signals
in a very precise time sequence, up to seconds and down to nS long,
and do it reliably. It all depends on exactly what you are trying to do,
but this is efinitely a job for hardware amd not for software.
Speaking only for myself,
Joe Durusau
H. E. Taylor
<MY_FIR...@CONSULTANT.COM> Leonid Rosenboim wrote:
>[...]
> Therefore, your onlu choise is a busy-loop delay, but for nanoseconds
> it would probably sufficie if you simply write a series of CPU instructions
> that have a deterministic execution time, either NOPs or accesses to
> an uncached memory location.
>
Manjeet did not mention what CPU he is using,
but if it is an x86 or PPC he can use an assembly routine
to access the clock tick counter. You need to calibrate
this counter initially, but the technique works fine.
<fwiw>
-het
--
"progress in software has not followed Moore's law." -John Holland
Energy Alternatives: http://www.autobahn.mb.ca/~het/energy.html
H.E. Taylor http://www.autobahn.mb.ca/~het/
Bill Pringlemeir
Joe> Well, you could write a short function, then time it with
Joe> timexN(), to see how long it takes on the average. Note that
Joe> this is not really a matter of the task sleeping, it's a matter
[snip]
Alternatively, you could look at the vxWorks FAQ. I also posted some
code, that was modified from the FAQ entry, in the last few months.
hth,
Bill Pringlemeir.
--
ANNOYED BY CORVETTE. DEPTH CHARGES. EXPLODING. U-135.
Manjeet Singh Chhabra
Actually we have a router.
Running on a COM-CPU ( i don't know hardware Architeture )
and i am writing a device driver for Galnet cross bar.
what driver does is it receives packets from the cross bar and sends
these packets to upper layers.
my driver is a task which is polling all the 8 ports of the cross bar.
in eache iteration it looks for packets and send at max 8 packets to
upperlayers. and sleeps for 1 tick ( which is processing time for 8
packets ).
to allow other task to process those packets.
but the problem is that if there are less no of packets still i have
to sleep for processing time equivalent to 8 packets because i don't
have any machnism to slepp for less than one tick.
How can i do this ?
Manjeet
David Laight
> Actually we have a router.
> Running on a COM-CPU ( i don't know hardware Architeture )
> and i am writing a device driver for Galnet cross bar.
>
> what driver does is it receives packets from the cross bar and sends
> these packets to upper layers.
>
> my driver is a task which is polling all the 8 ports of the cross bar.
>
> in eache iteration it looks for packets and send at max 8 packets to
> upperlayers. and sleeps for 1 tick ( which is processing time for 8
> packets ).
>
> to allow other task to process those packets.
>
> but the problem is that if there are less no of packets still i have
> to sleep for processing time equivalent to 8 packets because i don't
> have any machnism to slepp for less than one tick.
Seems to me you should be playing with process priorities, not timers.
David
Paul D. Smith
Umm, which one? Google returns a bunch of them. I looked in the
"Unofficial FAQ" and the FAQ for this newsgroup and didn't see
anything.
The "VxWorks/Tornado II FAQ" seemed to have some timer-related stuff,
but I didn't really see what I wanted. I realize that busy loops are to
be avoided in general, but sometimes you have to have them. And
hardware is not always the answer.
On QNX they have a very nice setup: you can run functions like:
int nanospin( const struct timespec *when );
to do a busy-wait. The first time you call this function it will do a
calibration to determine how long to spin on this system (you can also
force calibration, say early in your program, by directly calling
nanospin_calibrate()).
--
-------------------------------------------------------------------------------
Bill Pringlemeir
> Alternatively, you could look at the vxWorks FAQ.
Paul> Umm, which one? Google returns a bunch of them. I looked in
Paul> the "Unofficial FAQ" and the FAQ for this newsgroup and didn't
Paul> see anything.
google -> "vxworks faq", first link.
Paul> The "VxWorks/Tornado II FAQ" seemed to have some timer-related
Paul> stuff, but I didn't really see what I wanted. I realize that
Paul> busy loops are to be avoided in general, but sometimes you have
Paul> to have them. And hardware is not always the answer.
Didn't look much. There is a timer heading. There is also a "Hard
delay" section.
"http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt6.html#6.1"
A search on google of "delayLib.c" in comp.os.vxworks gives,
"http://groups.google.com/groups?as_q=delayLib.c&as_ugroup=comp.os.vxworks"
This includes the original post from "Geoffrey Espin".
The version I posted doesn't do the calibration (ala Qnx) and must be
called explicitly. I prefer this as the actual first call will delay
for more than necessary and you have nothing to accommodate a system
with a PLL that can change the system clock. I also added an
assembler loop for the ARM, which increases the nanosleep resolution.
Nothing like being spoon fed.
hth,
Bill Pringlemeir.
Paul D. Smith
>> Alternatively, you could look at the vxWorks FAQ.
Paul> Umm, which one? Google returns a bunch of them. I looked in
Paul> the "Unofficial FAQ" and the FAQ for this newsgroup and didn't
Paul> see anything.
bp> google -> "vxworks faq", first link.
As I said:
Paul> The "VxWorks/Tornado II FAQ" seemed to have some timer-related stuff,
This is the first link. I looked at it.
Paul> but I didn't really see what I wanted. I realize that busy
Paul> loops are to be avoided in general, but sometimes you have to
Paul> have them. And hardware is not always the answer.
bp> Didn't look much. There is a timer heading.
I read it. The only question that seemed remotely related was the first
one, and the discussion there talks about hardware timers etc. The code
referenced in this section is nothing like what I'm looking for.
bp> There is also a "Hard delay" section.
I didn't see this one: I was searching for "time", "timers", "spin",
etc., not "delay".
It would be nice if this section were moved into, or at least referenced
by, the time/timers section.
bp> A search on google of "delayLib.c" in comp.os.vxworks gives,
And why would I search for that?
bp> Nothing like being spoon fed.
Pfeh. It's all very easy when you already know what you're looking for
and what terms to look for it under.
Have a nice day.
Paul D. Smith
bp> The version I posted doesn't do the calibration (ala Qnx) and must
bp> be called explicitly. I prefer this as the actual first call will
bp> delay for more than necessary and you have nothing to accommodate
bp> a system with a PLL that can change the system clock.
As I mentioned, there's an explicit nanospin_calibrate() function you
can use if you want to (re-)calibrate at a specific time rather than as
a side effect of the first nanospin() call.
Bill Pringlemeir
[snip]
bp> Didn't look much. There is a timer heading.
Paul> I read it. The only question that seemed remotely related was
Paul> the first one, and the discussion there talks about hardware
Paul> timers etc. The code referenced in this section is nothing
Paul> like what I'm looking for.
bp> There is also a "Hard delay" section.
Paul> I didn't see this one: I was searching for "time", "timers",
Paul> "spin", etc., not "delay".
Paul> It would be nice if this section were moved into, or at least
Paul> referenced by, the time/timers section.
bp> A search on google of "delayLib.c" in comp.os.vxworks gives,
Paul> And why would I search for that?
Unfortunately, I assumed that you might scan the entire contents for
more than just "time". There is other good information in the FAQ
that Johan has put there. You might look at it just for reference.
Finding the section entitled delay, with a reference to "delayLib.c"
would give you all the information that I posted.
bp> Nothing like being spoon fed.
Paul> Pfeh. It's all very easy when you already know what you're
Paul> looking for and what terms to look for it under.
Then, I assume I helped you? Your welcome. I did my work to find
this (exactly as I described). I use Johan's FAQ all the time (and
even WindSurf). Then and only then do I ask questions here. I assume
people on c.o.v are busy. I guess you don't.
I am sorry. Manjeet (and all replies) have created over 12 posts in a
thread that isn't really all that illuminating. But then again, not
much here is...
Regards,
Bill Pringlemeir.
--
Have you ever seen large lymph nodes turn putrid 29 times in a row?
Or had large lymph nodes eat your mail while driving down the road at
120mph? Or had someone you saw at a party share intimate feelings
while drinking Sterno straight from the can? You will. And the
company that will bring it to you: AT&T.
Behzad Abareshi
Use select to watch the ports; read as soon as data is ready in any port;
store the packets in an array if you read less than 8 packets; repeat until
you have at least 8 packets; do the processing. The nice thing about select
is that it doesn't hog the CPU while waiting, so you don't need to finish
processing everything before reading more packets.
Behzad.
Paul D. Smith
bp> Nothing like being spoon fed.
Paul> Pfeh. It's all very easy when you already know what you're
Paul> looking for and what terms to look for it under.
bp> Then, I assume I helped you? Your welcome.
I really do appreciate the helpful part of your response.
bp> I did my work to find this (exactly as I described). I use
bp> Johan's FAQ all the time (and even WindSurf). Then and only then
bp> do I ask questions here.
If you had said ''look in the faq; there's something there called
"delay" or "delayLib"'' that would have been sufficient, and no more
work for you and much more helpful to me than the original response.
As I said, it's easy to find things when you know the right keywords.
bp> I assume people on c.o.v are busy. I guess you don't.
Ah, good. So, I guess I know what to tell someone the next time they
have a question about, say, GNU make. I'll just say "It's in the
manual". And if they still can't find it, I'll just say "read it all."
To think I've been wasting so much time over the years... heck, I could
just bind that "it's in the manual--read the whole thing" response to an
autoremailer in the help-make mailing list, and I could unsubscribe!!
Gary M
far. Many holes in the datasheet, etc. Nanosecond sleeping should be a
breeze compared to Galnet programming.
"Manjeet Singh Chhabra" <manj...@yahoo.com> wrote in message
news:8d0fbe67.02091...@posting.google.com...
Manjeet Singh Chhabra
your idea looks to me fine but if there are less than 8 packets and
there are no more packets those packets will remain unserved.
delaying task for those many packets is a better option i think
what do you suggest ?
Manjeet
Behzad Abareshi
> your idea looks to me fine but if there are less than 8 packets and
> there are no more packets those packets will remain unserved.
>
> delaying task for those many packets is a better option i think
> what do you suggest ?
>
Select has a timeout that you can set to suit your app; you process whatever
packages you have if you don't get anything more and select times out.
Behzad.
David Laight
> Select has a timeout that you can set to suit your app; you process whatever
> packages you have if you don't get anything more and select times out.
It is still limited to the system clock tick.
And if you increase the clock frequency above 2147Hz attempts to
sleep for sub-second times are likely to block the task forever
(and probably stuff the wall time).
David
Behzad Abareshi
"David Laight" <da...@spam.me.l8s.co.uk> wrote in message
news:alqfah$qtl$1...@venus.btinternet.com...
Note that the response was to the concern that the initial scheme I
suggested failed to explicitly address the case where less than eight
packages arrive and no package comes after those for a long time. So the
select timeout is to handle this noncritical detail, and the timeout value
would be several times the clock tick. I think this is adequate: the scheme
takes care of heavy traffic, and is relaxed when there is little traffic. I
think I have said enough on this thread :-) Peace.
Neil Horman
Manjeet Singh Chhabra wrote:
Does the cross bar not have an interrupt line that you can register a handler against? Then you wouldn't have to worry about timer loops at all.
Neil