RE: [microblaze-uclinux] usleep

["Jay Norrish" <jay@xxxxxxxxxxx>]

Hi John, Yoshi, Aurash

My whole Idea here is to keep my application simple and not have to write
interrupts or rely on software timming loops that tie up the proccessor.
I don't need precise timming like a real time op system. The peripherals
take between 300 to 500 usec to update once started. I would just like to
start them put the application to sleep and then go read them later.
I could live with 100 hz tik rate but 1000 hz would be better.

So I changed the #define HZ to 1000. Every thing seems to work fine so far.
Telnet and thttdpd are still working. And I can still update the flash with
tftp.
I'll let you know if it causes any problems.


Just as an experiment I tried to increase the tik rate higher and got an
error.
I traced it to the timex.h file where the SHIFT_HZ is generated for the PLL.
Is there an easy explanation about what that PLL is for?

Thanks Jay

Guys,
another approach here could be the hardware (don't forget the whole
thing is configurable platform)  a dedicated peripheral will give
accurate timing and will leave CPU time for other "high level" things.

my 2 penny
Aurash


John Williams wrote:

> Hi Jay, Yasshi,
>
> Yasushi SHOJI wrote:
>
>> At Mon, 25 Oct 2004 13:53:44 -0600,
>> Jay Norrish wrote:
>
>
>>> I am trying to use the usleep() function to
>>> put my application to sleep while my peripherals
>>> do data acquisition but, I have not been able to get
>>> the function to have a resolution of less than 10ms
>>> which is the tick rate.
>>
>
> A quick surf in the sources explains why - the usleep() lib call
> translates to a nanosleep() syscall, which is implemented in the
> kernel with a schedule_timeout().  At first glance, the only way
> you'll get a wakeup before 10ms is if you are under heavy interrupt
> load from a ping flood or similar.
>
> It seems this is an established limitation of usleep.  I see some
> mailing list threads proposing ways to improve it etc, but none of
> these have been implemented in microblaze.
>
>>> I know I could change the tick rate
>>> with the #define HZ in the mb_vannilla.h file but I am worried that
>>> it will
>>> break other programs.
>>
>>
>> I wouldn't recommend to change HZ for 2.4, if you don't know the
>> kernel internal.  it might or might not work.
>
>
> Oh but it's definitely worth a try!  ;-)   Please let us know what
> happens...
>
>>> Is there another function or way to do this ?
>>
>>
>> use bigger fifo and/or interrupt.  even with those, timing is not
>> guaranteed.  Linux is not a realtime os after all.
>
>
> Perhaps you might consider a sort of busy-wait loop with calls to
> gettimeofday() - it offers near microsecond resolution.  It's not very
> friendly to other processes in the system, but if your wait is much
> shorter than the tick interval (which it must be, otherwise usleep()
> would suffice), then it mightn't matter too much.
>
> Cheers,
>
> John
>
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>
>


___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/