 | | 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)
|
| |
| | Re: multiplexor and legOS
|
|
#include <sys/time.h> void systime_set_timeslice (unsigned char slice); include/sys/time.h:43-45: #ifdef CONF_TM #define TM_DEFAULT_SLICE 20 file://!< default multitasking timeslice #endif hope that helps, Albert "Michael J Ash" (...) (23 years ago, 4-Feb-02, to lugnet.robotics.rcx.legos)
|
| |
| | 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
|
|
(...) 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)
|
| |
| | 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)
|
