Subject:
|
Re: multiplexor and legOS
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Thu, 7 Feb 2002 16:17:39 GMT
|
Viewed:
|
2400 times
|
| |
|
|
Still no luck in getting the mux working properly. I tried making use of the
code for turning sensors on and off but later realized that the ds_handler code
would still be turning the sensor off as part of its normal operation. I think
I'm going to have to just dive into that code and make my changes there.
I've been in contact with the creator of the mux and he's been quite helpfull
in descibing its internal operation. Here is an e-mail he sent me regarding
how the mux handles the frequent power drops when the RCX attempts to read the
sensor values.
In side the Mux there is electronic (RC) filter which
try to get rid of the read pulses arriving every 3
ms. however this is very highly dependent function of
load of sensor ( eg how much light is seen by light
sensor) then I do rest of the filtering in software.
when ever the pulse comes I set up the flag and test
if pulse is existing around 4 ms later. if the pulse
is there then I take it as valid signal pulse and set
up the count. the I wait for time out and check if
there are any more pulses before time out.
if I get only one pulse before time out then I select
sensor 1 if two then 2 and so.
it may be possible that changing power/read (as in
legOS) cycle can fool the filter (although it is
Low-pass) and pass the pulses up to PIC.
I asked him to clarify if his 4ms check would notice interleaving pulses and
what the timeout value was for detecting the end of the pulse train. His
responce was.
I check only low level if it exist or not. and this
operation may be taking very small time ( ~1 micro
Sec) since the pic is running at 4 MHz
and as I remember time out is some thing of ~70 ms
So if anyone has comments or suggestions as to how LegOS's power/read cycles
would interfere with this please share them.
I'm hopeing that if I can manage to write support dirrectly into ds_handler
then I will be able to get both accurate timing (withought blocking) and avoid
droping the power for read cycles while I'm sending pulse trains. Also I will
be able to take control of the length of the read cycle so that it doesn't look
like a single pulse indicating to switch to sub-port 1. I'm not sure if this
is occuring or not but it would explain why the mux switches to port 1 so
often.
As before comments and suggestiosn are very very welcome. ugh, I'm not looking
forward to playing in the assembly.
mark
|
|
Message has 1 Reply:
 | | Re: multiplexor and legOS
|
| I'm happy to report that after writing the multiplexor driver at the kernel level it's working! I'll post a patch soon once I've got it cleaned up a little bit. It looks like the problem was with the legOS power/read cycle in ds_handler. Once I took (...) (22 years ago, 10-Feb-02, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: multiplexor and legOS
|
| Ok, my last port didn't make much sense let me try that again. for an active sensor ds_handler will periodically power the sensor off to read the value. The standard firmware does this to but at a different interval. I'm wondering if this is part of (...) (22 years ago, 5-Feb-02, 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
|
|
|
|
