| |
Hello out there,
maybe someone can explain to me why the current brickOS release seems to have
msleep()-amnesia ;-)
We've been testing the data transfer to our Lepomux device. For some strange
reason we were still using kernel 0.2.6.07nmChg with a slightly patched motor
output and everything went fine.
After switching to 0.2.6.10 we had very strange results - bad transfer rates and
lots of errors. First we thought, it's the Lepomux' fault, but then we took a
look at the RCX output ...
msleep() doesn't seem to have any influence on the motor output anymore. It
didn't make a difference if we paused for one, three or more milliseconds - the
output was completely bogus.
Did anyone of you experience similar problems? Or can anyone tell what's
wrong/changed in the current kernel version?
For those who don't know what Lepomux is: take a look at http://www.lepomux.org
:-)
Cheers
Gunther
|
|
Message has 2 Replies:
 | | Re: Strange BrickOS Timing
|
| Hi Gunther, (...) have (...) I'm NOT really an expert in brickOS, but these are the sources of delay and msleep: void delay(unsigned ms) { unsigned i; while (ms-- > 0) for (i = 0; i < 600; i++) // not well calibrated. ; } //! delay execution (...) (21 years ago, 3-Dec-03, to lugnet.robotics.rcx.legos)
| | | Re: Strange BrickOS Timing
|
| Hi Gunther, (...) have (...) After some investigation I found this page on YOUR site: (URL) YOU state: Using Lepomux requires a stable timing on the motor port because it is used as a serial data port. Since brickOS does a lot of stuff (...) (21 years ago, 3-Dec-03, to lugnet.robotics.rcx.legos)
|
5 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
