Subject:
|
Re: multiplexor and legOS
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 4 Feb 2002 22:20:05 GMT
|
Viewed:
|
2425 times
|
| |
|
|
> I don't know about this 20ms granularity and how delay() is going to be any
> better.
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 provide better timing, although it is
expensive.
inline long mysleep(long ms) {
ms+=sys_time;
while(sys_time<ms);
}
this seems to be dead on accurate but should also suffer the granularity
problem if it gets scheduled out. Actually this could explain the entire
problem! The entire pulse train would need to fit in one timeslice, if it
didn't then one of the pulses would be extended by 20ms or more. I'll try
recording timestamps for each pule edge and see what the real train looks
like. If I'm correct here I suppose I can just extend the schedular timeslice
to fit the maximum train (3 pulses). I guess I'd need to set it to 50ms or even
70ms to be safe. I supposed to be really safe I should always yield before I
start my pulse train to make sure I get the full timeslice for the train. I
wonder what impact trippling the timeslice will have on other tasks? Perhaps I
can integrate the pulsing into the kernel so that it can't be interupted, and
then leave the timeslice value at 20ms. Anybody have ideas about this? I
suppose it could go in ds_handler?
A safer starting point would be to compile the kernel so that it is not
multithreaded (this is still available I isn't it) to ensure that my main
thread is the only one executing and then use my above mysleep routine. If
that works then I'll look into extending the scheduler time slice, or messing
with ds_handler.
I'll post the results of the above tests soon, hopefully with positive results.
mark
|
|
Message has 1 Reply:
 | | Re: multiplexor and legOS
|
| (...) Not bad. But as you say, still vulnerable to the task switching problem. (...) Instead of resorting to that, maybe there is a way to freeze task switching during critical operations. When I owned and programmed the AmigaOS (don't laugh :), (...) (23 years ago, 5-Feb-02, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: multiplexor and legOS
|
| (...) 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 (...) (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
|
|
|
|
