Subject:
|
Re: multiplexor and legOS
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 4 Feb 2002 20:07:19 GMT
|
Viewed:
|
2459 times
|
| |
|
|
In lugnet.robotics.rcx.legos, Mark Falco writes:
> > Don't ask me for a cite, but I seem to remember something about msleep
> > only having 20ms granularity. If that's the case, your msleep(10) is
> > either not sleeping at all or is sleeping 20ms, either one of which could
> > cause problems.
> >
> > I'd suggest at the very least verifying your timing using sys_time in the
> > code. If msleep indeed isn't accurate enough, then you could make some
> > kind of busy-waiting loop.
>
> Thanks, I'd suspected that msleep might not be very accurate but never
> considered that it's true granularity could be so large. I did a quick test
> with my current configuration and when I asked msleep to sleep for 12ms it
> slept for 20. This may mean that it does have the 20ms granularity or it could
> be a 10ms or some other number. I also tried the delay function but it was far
> worse. So now I'm just using a simple while loop and watching the value of
> sys_time, and my tester function reports that I get exactly the time I'm asking
> for. Of course since I'm using sys_time to test this all it really means is
> that my thread isn't being preempted for to long. Assuming the RCX clock which
> sys_time is attached to is decently accurate I guess I have the sleep issue
> taken care of.
I don't know about this 20ms granularity and how delay() is going to be any
better. Here's the code for each function:
//! delay execution allowing other tasks to run.
/*! \param msec sleep duration in milliseconds
\return number of milliseconds left if interrupted, else 0.
\bug interruptions not implemented.
*/
unsigned int msleep(unsigned int msec)
{
#if defined(CONF_TIME) && defined(CONF_TM)
(void) wait_event(&tm_sleep_wakeup, sys_time + MSECS_TO_TICKS(msec));
#else
delay(msec);
#endif
return 0;
}
//! uncalibrated delay loop
/*! \param ms approximate time in ms
*/
void delay(unsigned ms)
{
unsigned i;
while (ms-- > 0)
for (i = 0; i < 600; i++) // not well calibrated.
;
}
delay() is just a not very well calibrated loop. msleep() uses delay if
time and task management routines are not implemented anyway. Othewise it
uses wait_event (and sys_time), which should be a good thing (?).
Couldn't find any information about msleep() having a 20ms granularity. The
standard firmware can do 10ms. Why should LegOS with assembler interface
and compiled code be limited to 20ms?
The only reference to 20ms that I can find anywhere is task switch
timeslices of that amount as default ("Introduction to the LegOS Kernel",
sect. 2.2, Stig Nielsson). So, I can only assume that when one calls
msleep() or sleep() (which calls msleep()), task switching can occur, which
may induce a minimum mandatory 20ms wait. This, of course, if true, would
mean that the granularity would increase with the number of running tasks.
And, lo and behold, in "Extreme Mindstorms...", Luis Villa tells us that "It
is important to note that msleep() shouldn't be used as a timer if exact
time is important, because the OS waits the specified number of seconds and
then executes the next line of code ONLY AFTER (my emphasis) the current
task is finished."
So, there should only be a granularity problem if running more than one task
(not a good thing), unless there is another issue that has not been mentioned.
I'm just as interested in your problem, Mark, since I too have one of Nil
Patil's multiplexers (which I have not had a chance to use yet) and LegOS.
The information you seek would go a long way to assist me and anyone else
under similar circumstances.
Robert Templeton
|
|
Message has 2 Replies:
 | | Re: multiplexor and legOS
|
| (...) I agree about the cause for the msleep granularity, I'd seen the same stuff in tm and assumed that would cause the problem. Sorry my last note was a little unclear, I tried msleep and delay but am now using my own function which seems to (...) (23 years ago, 4-Feb-02, to lugnet.robotics.rcx.legos)
| | | Re: multiplexor and legOS
|
| (...) Most people's legOS kernels will be compiled so msleep uses wait_event. I haven't looked at the code, but my understanding of how wait_event works is that whenever that thread becomes eligible to execute, your even function is called. (...) (23 years ago, 5-Feb-02, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: multiplexor and legOS
|
| (...) Thanks, I'd suspected that msleep might not be very accurate but never considered that it's true granularity could be so large. I did a quick test with my current configuration and when I asked msleep to sleep for 12ms it slept for 20. This (...) (23 years ago, 4-Feb-02, to lugnet.robotics.rcx.legos)
|
19 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
