Subject:
|
Re: Interesting BrickOS Timing Results
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Tue, 14 Jan 2003 18:16:42 GMT
|
Reply-To:
|
Dick Swan <dickswa@sbcglobal+AvoidSpam+.net>
|
Viewed:
|
3271 times
|
| |
|
|
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 interrupt. A 6 us delay loop executed every 37.5 us chews up a
lot of time! Plus a few us of interrupt servicing overhead. I bet even
the popular PC operating systems have trouble servicing interrupts
that fast.
Here's a few things that you can do to improve the sensor handling if
you're getting into serious rewrites:
The H8 CPU has a mode where it scans all four A/D channels and
generates a single interrupt when complete. This is the method used by
the standard Lego ROM firmware. The Lego ROM firmware reads sensor
values every third time through the 1-msec interrupt routine. It
avoids the 6 us delay loop by cutting power to the active sensors at
the start of the routine, doing a bunch of other useful 1-msec
interrupt work, and then starting the A/D conversion at the end of the
interrupt handler. I'm not sure of the need for the 6 us delay; in my
homebrew OS I cut off power and immediately start A/D conversion and
don't seem to have any ill effects.
One of the possible drawbacks of the scan all four channels at once
A/D conversion is that it may introduce noise between channels and
reduce the conversion resolution. There was a thread on this a while
back. I don't think there was a definitive view on whether this
"factoid" was true.
There's not much point in performing A/D conversions faster than the
time between different time slices of user tasks. The user task won't
see the changes anyway. Rotation counters are the only exception
because the sensor value is not a simple direct function of the raw
value but rather a counter based on an algorithm looking at difference
between consecutive raw values.
So, if a user task gets to run every 10 msec, then you might want to
have A/D conversions every 5 msec if rotation counters are not used. I
suggested half the time because I read somewhere that BricOS handler
looks for two consecutive "identical" values before processing a
change in an attempt to minimize spurious counts in the rotation
counter due to transients; I use a somewhat similar technique in my
firmware but I only look at the the top eight bits of a raw value to
see if a reading has changed -- I reduced the resolution from 10 to 8
bits..
For rotation counters I'd suggest an A/D conversion every 1 msec. With
debounce this gets an analysis every 2 msec which is more than fast
enough to keep up with the fastest motor speed using a 1:1 gearing.
You don't need to scan the battery voltage anywhere near as fast as
the other sensors. Once every 20 - 50 msec is probably fine.
I did some measurements on my OS a few months ago and found the
following elapsed times for my "dummy" task similar to your 'delay_ms'
procedure.
17.0 - perform A/D conversion every 1 msec
14.6 - perform A/D conversion every 3 msec
13.7 - perform A/D conversion every 100 msec
If you make the assumption that sensor overhead is negligible at 100
msec scanning, then at 3 msec sensor "reading" overhead is 6% and at 1
msec is 19%. My firmware uses the "convert all four channels" at once
mode.
|
|
Message has 2 Replies:
 | | 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)
| | | 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)
|
Message is in Reply To:
| | 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)
|
19 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
