|
 | | 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)
| |
|  
brickos
(score: 0.454)
|
|
| | brickOS with BricxCC
|
| So far I have heard from two people who have successfully used brickOS with BricxCC. I'm interested in whether anyone else has tried using BricxCC to edit/compile/download programs to brickOS. Currently BricxCC requires that the cygwin bin directory (...) (22 years ago, 8-Jan-03, to lugnet.robotics.rcx.legos)
| |
|
brickos
(score: 0.454)
|
|
| | 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)
| |
|
brickos
(score: 0.454)
|
|
| | I cannot send more than 6 bytes with lnpd
|
| I'm trying to send some data from the RCX to my computer, using lnpd, but I have the following problem: it seems that I cannot send more than 6/7 bytes, because after this limit I have a lot of errors from lpnd (see the log below). The tower and the (...) (22 years ago, 21-Jan-03, to lugnet.robotics.rcx.legos)
| |
|
brickos
(score: 0.454)
|
|
| | 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)
| |
|
brickos
(score: 0.454)
|
|
| |
|
brickos
(score: 0.454)
|
|
| | Re: Interesting BrickOS Timing Results
|
| Mark Riley wrote: > Actually, if we move the sys_time > handler back to OCRA (instead of the watchdog NMI), > then we could just check if bit 0 of sys_time is zero to > determine if the subsystem handler should be called (plus > this will get (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
| |
|
brickos
(score: 0.454)
|
|
| | 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)
| |
|
brickos
(score: 0.454)
|
|
| | Interesting BrickOS Timing Results
|
| Hi All, The recent posts about interfacing an i2c device to an RCX sensor port (in .robotics) got me interested in looking at the kernel code that handles the sensors. So, I did and found myself looking at the ds_handler function. This function is (...) (22 years ago, 14-Jan-03, to lugnet.robotics.rcx.legos)
| |
|
brickos
(score: 0.454)
|
|
| | 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)
| |
|
brickos
(score: 0.454)
|
|
| | Re: Interesting BrickOS Timing Results
|
| OCRA and OCRB are output interrupts for the 16 bit timer. They can be programmed to fire at specific points along the timers run. So, technically, they cannot be used independently of each other. If OCRA resets the timer value back to zero, then (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
| |
|
brickos
(score: 0.454)
|
|
| | 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)
| |
|
brickos
(score: 0.454)
|
|
| | 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)
| |
|
brickos
(score: 0.454)
|
|
| | Sensor Sampling; Progress?
|
| So far, I have reconfigured a copy of BrickOS in the following way: 1) Adjusted the clock_handler to improve the accuracy of the sys_time variable. Now running at very close (if not right on) 1 msec per tick. 2) Allowed the FRC (Free-Running (...) (22 years ago, 18-Jan-03, to lugnet.robotics.rcx.legos)
| |
|
brickos
(score: 0.454)
|
|
| | Re: Sensor Sampling; Progress?
|
| I have been following this thread with great interest for two reasons. One day, someone will be persuaded to provide me with direct help and assistance in getting BrickOS running on my laptop - perhaps at BW or BF. I have built quite a few prototype (...) (22 years ago, 18-Jan-03, to lugnet.robotics.rcx.legos)
| |
|
brickos
(score: 0.454)
|
|
| | Re: Sensor Sampling; Progress?
|
| (...) Yes. (...) individually (...) That's right. (...) I agree. With the current firmware, power gets cut off to all 3 sensors for ~85us (sometimes longer). With the scheme I mentioned, power would be cut to only one sensor for ~25us. The sample (...) (22 years ago, 19-Jan-03, to lugnet.robotics.rcx.legos)
| |
|
brickos
(score: 0.454)
|
|
| |
|
mac
(score: 0.454)
|
|
| |
|
mac
(score: 0.454)
|
|
| |
|
mac
(score: 0.454)
|
|
| |
|
brickos
(score: 0.454)
|
