|
|
 | | Re: BrickOS Threading...
|
| Joe, (...) Maybe a special kernel build for testing purposes that increments the lower sys_time word by 0x4000 instead of 1. This will greatly increase the opportunity for this glitch to occur (from once every 65 seconds to once every 4ms.) You (...) (22 years ago, 13-Dec-02, to lugnet.robotics.rcx.legos)
| | | | | Re: BrickOS Threading...
|
| Steve, I checked in some changes this morning (into cvs) to put the motor controller back at the 1 ms interval. However, I want to complete the get_sys_time() updates that Mark Riley has proposed; so that can be tested as well. I am not sure when (...) (22 years ago, 13-Dec-02, to lugnet.robotics.rcx.legos)
| | | | | Re: sys_time (long post)
|
| (...) It turns out that the nature of the glitch depends on the order you read the upper and lower 16-bits of sys_time. If the compiler generates code that reads the high word first (which it seems to do), then your example will work. However, if (...) (22 years ago, 13-Dec-02, to lugnet.robotics.rcx.legos)
| | | | | Re: BrickOS Threading...
|
| (...) In trying to balance an RCX on two wheels, every little bit makes a difference. I didn't think it would matter quite that much, but my robot really shakes more with the new version. Thanks for the work, Steve (22 years ago, 13-Dec-02, to lugnet.robotics.rcx.legos)
| | | | | setjmp/longjmp for brickOS
|
| Hi all, I am currently attending to a lecture in real time system on my university and we were assigned the homework to do exception handling in C on the RCX using setjmp and longjmp. Of course those are not available in brickOS so that task (...) (22 years ago, 13-Dec-02, to lugnet.robotics.rcx.legos)
|
|
