 | | Re: Interesting BrickOS Timing Results —Mark Riley
|
| | | 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)
|
| | | |
| | | | | Re: Interesting BrickOS Timing Results —Joseph Woolley
|
| | | | | 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 —Michael Obenland
|
| | | | | | (...) 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 —Joseph Woolley
|
| | | | 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 —Joseph Woolley
|
| | | | | 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 Riley
|
| | | | 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 —Gunther Lemm
|
| | | | (...) Timer B is usually unused but has a lower priority than Timer A. If you do a lot of stuff in the timer A routine, this will block timer B interrupts (especially if timer B generates more interrupts than timer A). The mean thing is that those (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: Interesting BrickOS Timing Results —Joseph Woolley
|
| | | | 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)
|
| | | | |
| | | | | | Re: Interesting BrickOS Timing Results —Mark Riley
|
| | | | (...) My thought was that the OCRA interrupt could be used as the general 1ms interrupt and the subsystem handler (which is currently using OCRB) could be called every other time from the OCRA handler by using a flag (toggled every 1ms). Actually, (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: Interesting BrickOS Timing Results —Gunther Lemm
|
| | | | Hi Marc, (...) Nice idea, but wouldn't that result in at least one of four cycles beeing blocked by OCRA? or is our system interrupt finished within less than 250msec? (...) Right, that was what I did for my Lepomux patch - works fine. Gunther (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: Interesting BrickOS Timing Results —Joseph Woolley
|
| | | | | 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)
|
| | | | | |
| | | | | | | RE: Interesting BrickOS Timing Results —Ralph Hempel
|
| | | | | | (...) I have been following this thread in my peripheral vision for a while now. All of the talk is very interesting and appears to be leading to a general question about how and why the drivers are the way they are.... As a point of interest, some (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos, lugnet.robotics.rcx.pbforth)
|
| | | | | | |
| | | | | | Re: Interesting BrickOS Timing Results —Mark Riley
|
| | | | (...) 250msec? Not blocked entirely, but delayed. That's what I meant by "stutter". I've measured the general interrupt handler to take anywhere from 70-150us. So, the higher the sample rate the more significant the disruption. Anything faster than (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: Interesting BrickOS Timing Results —Mark Riley
|
| | | | (...) I forgot to mention... This is *almost* the same as moving some of the subsystem code into a seperate high priority task. For example, LCD refresh code is executed in the 1ms timer ISR. It really doesn't need to be in the ISR. It can do it's (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
| | | | |
