Subject:
|
Re: Ir transmission
|
Newsgroups:
|
lugnet.robotics.rcx.pbforth
|
Date:
|
Wed, 14 Apr 1999 14:07:39 GMT
|
Reply-To:
|
ROBOTS@JPSC.CO.nomorespamUK
|
Viewed:
|
1751 times
|
| |
|
|
> This should work, its not tested. you might put a hard spin loop
> after the EMIT to make sure the code is going out before sampling the
> light sensor.
Perhaps EMIT? would do
> something like:
>
> 100 0 DO LOOP
>
> should give you a delay. I'll provide some timing on the web site
> soon!
I'm nearly done with my NQC to pbFORTH port of the IR proximity detector,
but I'm stuck where I have at present got a 30ms delay (Sleep(3) in NQC).
I expect it isn't critical but the current detector works so well I am
loath to change any of the parameters. The timers in pbFORTH only count in
100ms steps, so how can I get a 30ms or better timer? Do you know how NQCs
Sleep is implemented?
--
John Cooper, Wallington, UK
|
|
Message has 1 Reply:
 | | RE: Ir transmission
|
| (...) Alas, I only used the firmware timers available as core RCX firmware calls. I can look through Kekoa's disassembly to see if there are higher resolution timers available ( I think the motor timers might be useful ) In general, NQC hooks in (...) (26 years ago, 15-Apr-99, to lugnet.robotics.rcx.pbforth)
|
Message is in Reply To:
| | RE: Ir transmission
|
| (...) YES!!! The standard FORTH word U. prints an insigned integer, while EMIT sends out an arbitrary byte. So, for a simple IR proximity detector, you would write something like: HEX 0 SENSOR_ACTIVE (labelled sensor #1) 3 1 SENSOR_TYPE (light (...) (26 years ago, 30-Mar-99, to lugnet.robotics.rcx.pbforth)
|
9 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
|
|
|
|
