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

RE: usleep seems broken


usleep is a userspace call and I think it is a wrapper
to a kernel call. This means that the kernel scheduler
will be run and the userspace application will be put to
sleep until the timer is finished AND the scheduler
decides to schedule that application again. As the man
pages indicates usleep is not intended for high precision 

Can't the delay between the writes be handled with settings
in R_WAITSTATES? I guess that you need to wait for your 
external circuit to finish processing a command before you
send the next. In that case it may be easier to have a ready
signal from the external circuit that can be polled by software
or create an interrupt to a driver.


-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com]On">mailto:owner-dev-etrax@xxxxxxx.com]On
Behalf Of Dragan Stancevic
Sent: Monday, August 20, 2001 10:35 PM
To: dev-etrax
Subject: usleep seems broken


I need to use glibc usleep function to time between writes to and from a
device attached to csp0, the reads and writes work but they seem realy slow,
I tried to figure out what was going on so I wrote a test case:


What this code does is just turns on and off a single pin on the device, I
attached a scope to that pin and timed the delay between high and low pulses
and it seems that usleep(1) which should sleep for 1 microsecond actually
delays the process for 25 miliseconds, that's right it's not a typo the
delay is in miliseconds instead of microseconds. When I replaced the
usleep(1) with usleep(25000) than the redout from the scope would show a 39
milisecond delay.

Can anyone at Axis verify this on their systems.

I need a time delay in my app to be more acurate than 25ms, maybe I should
read the time straight from the timer registers on the LX processor, what do
you think?


Peace can only come as a natural consequence
of universal enlightenment. -Dr. Nikola Tesla