Subject:
|
Re: Sensor Sampling; Progress?
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sat, 18 Jan 2003 17:36:40 GMT
|
Viewed:
|
3198 times
|
| |
|
|
Joe,
Great job on taking the bull by the horns!
The following are my suggestions on a system configuration.
Please note that the term "divider" is being used here to
indicate the function should only be performed every Nth
interrupt.
OCRA interrupt (1ms fixed interval):
1. Increment sys_timer
2. Motor handler (adjustable divider, default = 2)
3. Sound handler (adjustable divider, default = 2)
4. Key handler (fixed divider)
5. LNP timeout (lnp_timeout_counter is the divider)
6. Task switching (tm_current_slice is the divider)
OCRB interrupt (adjustable interval):
1. Cut sensor power (if active)
2. Small delay (adjustable)
3. Start A/D conversion
A/D completion interrupt:
1. Restore sensor power (if active)
2. Handle rotation sensor (if enabled)
3. Handle sensor mux (if enabled)
4. Sensor value ready callback (optional)
5. Increment channel #
Move to high priority task (in multitasking mode):
1. LCD refresh
2. Auto shutoff
3. Battery indicator
4. Other LCD indicators (i.e. vis_handler)
Ok, the comments: ;-)
The basic idea is is to split the current A/D handler
in half, putting half the code in the OCRB interrupt
to start a conversion, and the other half in the A/D
interrupt to finish processing the results. This
scheme ensures that power to active sensors is only
cut during the actual time of conversion (17us). This
allows the A/D sample rate to be adjusted (via the
OCRB interval) through a wide range of values without
worring about starving sensors for power.
OCRA remains the heartbeat of the system. Functions
that need to be performed less often use dividers.
Some of the dividers are adjustable so users can
select their preference at runtime for performance vs.
CPU utilization.
Many of the current subsystem functions can be moved
to a seperate high priority task. This keeps time spent
in interrupts at a minimum, allowing the A/D interrupts
to fire more predictably and achieve higher sample
rates (when required).
There's also an option for a sensor callback function
(you mentioned this in one of your emails), so that
high performance sensors can have custom handlers
without building a special kernel. There would be
one callback per channel.
Mark
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | 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)
|
6 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
|
|
|
|
