Subject:
|
RE: IR communications related questions (long)
|
Newsgroups:
|
lugnet.robotics.rcx.pbforth
|
Date:
|
Tue, 2 May 2000 01:22:40 GMT
|
Viewed:
|
1665 times
|
| |
|
|
Steve Morris wrote:
> I am switching back to pbForth with its
> simpler communications model.
Back? You're switching back? Great! Sorry for quoting
so much, but the points are apropos the discussion...
> In the process a few questions come up. It's been a
> while so excuse me if I ask the obvious.
>
> o - What is the closest version of forth available on
> the PC, hopefully free, that I can use to work out
> algorithms? Does it share the same tasking words?
> How close is the Hendtlass "Real Time Forth Tutorial" to
> pbForth? Are they based on the same standard?
I based pbForth on hForth, by Wonyong Koh. It is pretty
much compatible with any ANSI forth as well. Check out
<http://www.forth.org> for more info. The tasking words
are directly compatible between hForth and pbForth.
Hendtlass's book is a goldmine of info. The root cause of
Forth's demise was the large number of "standard" dialects...
> o - Where do I find a (reasonaby) complete list of
> available words? I see the RCX extensions in your
> tutorial. What about everything else?
Well, you'll find that the core of all your work will
be done with 30 or so basic words that are standard
in any Forth implementation. Putting out a wordlist
would be a bit of an undertaking, but there's been enough
demand that it will eventually get done. You can scan through
the h8hforth.asm source and get a good head start on
the job if you're interested :-)
> o - Are the pbForth tasking words standard?
No, they are hForth extensions. I've found that tasking is
largely unnecessary for most robotic applications. It's nice
to use after you're more experienced with all of the real-time
issues.
> o - How do I access IR serial at the byte level. Are
> there RCX specific words I should use or do I use KEY?
> What sort of buffering is there in either direction
> that I might have to worry about flushing? Is there
> buffering in the isr? (Is there an isr?)
There is no ISR. You EMIT bytes as needed. EMIT blocks until
the UART accepts the byte into the buffer. This may be
well before any bits actually go out the door. A subsequent
EMIT will wait (block) until the DUART is ready to go.
> o - What is the interaction between tasking and IR
> serial? I assume there is an isr that buffers some
> number of characters and I periodically need to poll
> with KEY? or some equivalent, and EMIT hopefully
> is nonblocking because it puts the data into a buffer
> for the isr?
IR bytes are read only when the interpreter is waiting for
them. If your application is in a tight loop waiting for a
sensor press, no IR will happen.
> o - For that matter what is the basic structure of
> pbForth, especially as relates to I/O? I get the
> impression that pbForth uses the ROM to handle most I/O
> including the sensors just life the Lego firmware does.
> Is this true?
Kind of. The OCIA interrupt runs every 1/1000 of a second after
you call RCX_INIT. This will run the A/D, the sound, and the
motors.
You must explicitly read the sensor to make the values change.
The OCIA just buffers results, SENSOR_READ actually manipulates
the stored values.
The IR is handled by a custom IR driver, and I'd like to make it
interrupt driven and buffered eventually...
> I plan on writing a simple program on the PC (probably
> in some scripting language (Tcl? Forth?) or cygwin gcc)
> which implements a simple minded protocol with the primary
> job of preventing tower timeout. One of the tasks on the
> RXC would babysit this communication and pass things
> to/from the other tasks as required. It is my hope that
> the communication can be non blocking so that I can
> communicate in the background while keeping things humming
> in the foreground, without degrading performance.
Please pass any Tcl progress my way. Ernst de Ridder has been good
enough to send me a patch to the kernel which allows checksummed
line uploads in a transparent way. If the controlling computer
prefixes the line with a special control character, the line is
summed, otherwise it is treated normally.
I'm just finishing a Tcl uploader that takes care of image uploads
and can strip comments during script uploads. All I need to do now
is add the checksummed line loading and XMODEM file receive. Real
soon now...
> Are there any good communication examples already written
> that might help me understand the issues, perhaps the
> image upload or something?
>
> Is there anything in the pending release which might help
> me here?
See above. The thing that will help the pbForth users most is
good suggestions and contributions of help files and any other
observations. I'm happy to include them on my website with
full credit to the contributor.
The servo code will be in the next release too!
This LugNet group you are reading is the preferred discussion
forum, and I'd like to keep the distribution from my website if
possible.
Hope this helps Steve. Thanks for asking.
Cheers,
Ralph Hempel - P.Eng
--------------------------------------------------------
Check out pbFORTH for LEGO Mindstorms at:
<http://www.hempeldesigngroup.com/lego/pbFORTH>
--------------------------------------------------------
Reply to: rhempel at bmts dot com
--------------------------------------------------------
|
|
Message has 1 Reply:
Message is in Reply To:
 | | IR communications related questions
|
| I've been working with LegOS for a while but am quite frustrated. I have been unable to get lnp working and am thus unable to to communicate with the host. It is all overkill for me since I merely want to capture some simple data. I am switching (...) (25 years ago, 1-May-00, to lugnet.robotics.rcx.pbforth)
|
3 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
|
|
|
|
