Subject:
|
Re: multiplexor and legOS
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Tue, 5 Feb 2002 01:59:21 GMT
|
Viewed:
|
2465 times
|
| |
|
|
In lugnet.robotics.rcx.legos, Mark Falco writes:
>
> 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);
> }
Not bad. But as you say, still vulnerable to the task switching problem.
> 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.
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 :), there was a means to do just this for critical operations where
task switching could or would be catastrophic. The AmigaOS was (and still
is, I guess) preemptive multitasking. I have the RKM's (ROM Kernel Manuals)
still, so I'll let you know what I find. And if it's easily implementable,
hey, what the heck. It would definitely improve time-critical sensor
operations and, in our case, allow multiplexing to work properly even while
running multiple tasks.
> I'll post the results of the above tests soon, hopefully with positive results.
Looking forward to it!
Robert Templeton
|
|
Message has 1 Reply:
 | | Re: multiplexor and legOS
|
| (...) It looks like the semaphore task_sm should prevent another task from being scheduled if I hold it for the length of the train. I've now tried this as well as incresing the timeslice to 100ms. It looks better but still is not consistent. Since (...) (23 years ago, 5-Feb-02, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | 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)
|
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
|
|
|
|
