 | | Re: Interesting BrickOS Timing Results
|
|
(...) I've found that any interrupt on the RCX has a minimum overhead of 101 to 113 states (or about 7 us). This is the time taken by the CPU to recognize and dispatch the interrupt plus the time the ROM routine takes to dispatch the interrupt to (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
Joe, That's definitely an improvement! So, that would be a 250 Hz sample rate for any given sensor. I just tried a modification similar to yours that did all 4 conversions every OCRA/B interrupt (or 1 KHz sample rate) and got: IDLE: 82 2ROT: 77 (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
I did some "real world" tests with this update. I was Astounded at what a difference it makes. The bot I was testing with is a killough platform; which I had tried for hours previously, to get it to follow a line smoothly. I think BrickOS was giving (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
Mark, I retrieved the latest BrickOS from CVS, made clean and made the cpu test program you listed. I then made two small changes (to see what would happen); first the results, then the changes: IDLE: 89 2ROT: 87 NOAD: 91 (see below) NIRQ: 98 (see (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
(...) The delay was added a long time ago after a bit of discussion on this newsgroup/list. A search through old newsgroup posts will turn up a brief series of three posts with subject "Rom sensor read routine" from Apr/May 1999. The explanation (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Patches on SourceForge? A good/bad way to get changes into brickOS?
|
|
I've just posted (URL) note that there are 4 other patches lingering from as far back as September. Will my patch be looked at because it has been posted there? For info, here is the patch description The last version of binutils that brickOS works (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
This was a terrific analysis. It's not surprizing that current implementation hogs so much CPU time. If all four A/D channels are scanned every 150 us then the A/D interrupt is occuring every 37.5 us since each A/D channel generates its own (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
(...) This would be my favourites. If one builds a fast moving robot, main concern will be how fast the robot reacts to light sensor changes or how small the structures could be that the light sensor will "see". If one builds a thinking robot, for (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
Mark, ANOTHER great find! You are pushing BrickOS to new heights! Ok, so what can we do about this? 1) Provide a constant to set the update frequency at compile time. 2) Provide a variable to set the update frequency at run time. 3) Optimize the (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Interesting BrickOS Timing Results
|
|
Oops, found a little bug. ;-) Forgot to turn off the rotation sensors. Caused a wrong reading if you let the program run through the readings more than once. The rotation sensor section should read like this: // with two rotation sensors enabled (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
|
