Subject:
|
Re: light sensor problem?
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 24 Jul 2000 16:19:39 GMT
|
Viewed:
|
1831 times
|
| |
|
|
> I looked through the dsensor stuff, and it looks quite bad to me...
:-) It is not the best implementation I've seen... :-)
> We execute a delay loop inside an interrupt handler.
> We issue the command to start the next read from that same handler.
Yes. I hate the delay loop but we I can't imagine how to do it better if we
still need maximum speed in reading values from sensors. The routine also change
his sampling speed if we need a reading for 1, 2 or 3 sensors and if we need to
handle a rotation sensor too... This is a price to pay for a total IRQ handling
of ADC & sensors... :-(((
But sampling rate is maximized...
I thought to change the routine to read all sensors in one shot, but I've not
changed the code after last patch that made it stable.
> This will read the sensors very quickly, for the cost of high interrupt
> load and (maybe) inproper driving of the sensors (See Kekoa's comments
> in e-mails last year).
Solved by settle time (but I have no digital scope to test electrical signals).
The e-mail is not aligned with actual implementation.
> I doubt we need this very fast reading of sensors. This makes implementing
> more sophisticated events like change over time and such harder.
I've done some projects were 1ms time for reading light values could be a
disaster... :-)
> Another aproach for the dsensor driver would be this:
> Get a wakeup every X milliseconds. Inside the called routine:
>
> - Turn of the output driver to the active sensors.
> - Program timer compare B to wake up after the required
> delay time.
X millisecond is too late... :-)
> Inside the timer interrupt:
>
> - Program the A/D to sample all sensors and generate an interrupt.
>
> Inside the A/D interrupt:
>
> - Turn off A/D sampling.
> - Read the A/D values for all sensors.
> - Turn the output driver for the active sensors back on.
>
> This scheme would be very efficient considering CPU resources. I did
> not measure it yet, but we would probably sleep a lot more in the idle
> process, so we should have better battery savings.
I agree for effects but you lose sampling speed... :-(((
> If ACTIVE_SENSORS in the sample code below is defined to 0 (the default
> state in legOS when no program is run, or no light/rotation sensor are
> active), this code reduces power consumption from 26.3 mA to 18.1 mA
> (I just measured it, after hacking up the sample, this seems to prove
> the statement about efficiency above).
Actual legOS implementation already turn off active sensors if not in use or no
program is run.
> Personally I like this code (or some code like this, if this evolves
> into an actual driver) better for another reason: It contains less
> assembly, which makes it easier to follow...
I also like your code, if only it could sample faster... :-(((
Bye,
Paolo.
---
Sbatti la fronte sulla tastiera per continuare
|
|
Message has 2 Replies:
 | | RE: light sensor problem?
|
| (...) I've used the OC1B interrupt for my servo driver code in pbForth. You could use the OC1B to set the settle time for each reading, and then actually read the results when the interrupt expires. Having a structure to tell you which A/D to read (...) (24 years ago, 24-Jul-00, to lugnet.robotics.rcx.legos)
| | | Re: light sensor problem?
|
| (...) Let me think about how to uncouple this from sys_time, so the code can get higher resolutions. (...) Yes, but even if all active sensors are turned of we are running with a lot of CPU power due to the high sampling speed. If you lower the (...) (24 years ago, 24-Jul-00, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: light sensor problem?
|
| (...) I looked through the dsensor stuff, and it looks quite bad to me... We execute a delay loop inside an interrupt handler. We issue the command to start the next read from that same handler. This will read the sensors very quickly, for the cost (...) (24 years ago, 24-Jul-00, to lugnet.robotics.rcx.legos)
|
26 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
|
|
|
|
