Subject:
|
Re: The pain of communicating with the RCX
|
Newsgroups:
|
lugnet.robotics.rcx.pbforth
|
Date:
|
Fri, 10 Mar 2000 17:30:38 GMT
|
Viewed:
|
1854 times
|
| |
|
|
On Fri, Mar 10, 2000 at 03:38:09PM +0000, Ralph Hempel wrote:
> The Tcl GUI is basically a text dumper. It was able to upload the SRECs very
huh? Do you mean it just writes text to the RCX without any synchronization
or checksums? Then how is it going to be an improvement over a plain ascii
upload using e.g. ascii-xfr?
> > > To make it really useful, I need to add a macro capability to translate
> > > common words into constants, and add a little XMODEM protocol. Since the
> >
> > Why the macros? To speed downloading?
>
> The let you write code with constants, like the display formatting, without
> having to do something like HEX 301F CONSTANT LCD_NUMBER and use up space
> in your dictionary. It would see that LCD_NUMBER is a pre-defined constant
> and substitute HEX 301F right away. Of course, the current base would have
> to be considered...
But then you can't use those constants (i.e the words, rather than the values)
from the commandline anymore, either.
> Finally, it would allow stripping of comments and whitespace to make
> for faster text downloads...
Use a regexp substitute? Shouldn't be too difficult, as neither forth comments
nor strings can extend across linebreaks. (Hmm. Is "(" limited to one line,
too?)
> > I patched RCX_EMIT to echo \r as \r\n when RCX_ECHO is 2. Why isn't
>
> This is a great idea, Ernst. Please send me the patches and I'll integrate
You can have it, no problem. I can add a \b -> \bBL\b translation too, if
there's any interest in it. OTOH, as these translations are primarily meant
to keep the display readable, why not make your TCL terminal handle them
in an intelligent fashion?
> > being able to abort the operation. It would be nice if pressing one of the
> > buttons on the RCX would do a QUIT. Maybe a cold restart is better in the
> > case of multiple tasks. Any ideas on how to do such a thing?
>
> I could provide a basic image that had a task that scanned for a button. The
> task switch for the interpreter happens when we send out a char, so that
> should be easy to implement...
This wouldn't help for runaway tasks that do not write out anything, though.
I don't know whether it is possible, but what about attaching an interrupt
to a button that resets pbforth to some known state?
Ernst
> Ralph Hempel - P.Eng
What's a P.Eng? Pbforth Engineer, Phantastic Engineer, Process Engineer...?
|
|
Message has 1 Reply:
 | | RE: The pain of communicating with the RCX
|
| (...) Yup. Remember that the Forth interpreter can't deal with text in special packets. It may be an improvement by limiting the time between characters. I think that ascii-xfr may dump chars without enough time between them... (...) If you use the (...) (25 years ago, 10-Mar-00, to lugnet.robotics.rcx.pbforth)
|
Message is in Reply To:
| | RE: The pain of communicating with the RCX
|
| (...) That's because the SREC upload uses the native upload code in the RCX ROM. It works really well but has to send each byte as a pair with the bits inverted. Also the header and trailer have to be added. The result is that it would be impossible (...) (25 years ago, 10-Mar-00, 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
|
|
|
|
