Subject:
|
RE: The pain of communicating with the RCX
|
Newsgroups:
|
lugnet.robotics.rcx.pbforth
|
Date:
|
Fri, 10 Mar 2000 17:55:38 GMT
|
Viewed:
|
2393 times
|
| |
|
|
> > 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?
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...
> But then you can't use those constants (i.e the words, rather than the values)
> from the commandline anymore, either.
If you use the GUI, it can intercept words as you type them and translate
for you. This is a feature for later anyways. I'd rather get the basic stuff
working first :-)
> > 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?)
Yup. And I have that done. regexps are really very powerful. We only have
to make sure that ( inside .S or S" strings are left alone...
You can easily preprocess your source using a regexp filter, but I like
things like that to be done in a script...
> > > 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?
Thats what it used to do. I gave up on the Tcl thing before I had RCX_EMIT
though. It used to have to track two echoes, one from the RCX, and the other
from the tower itself..
> 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?
I think that NMI is the power button. That's how it comes out of the power
down state in the first place. I'll look into leaving it enabled all the
time. The RCX firmware enables NMI when powering down to make usre it can wake
up again. After that, it polls for power-down...
> What's a P.Eng? Pbforth Engineer, Phantastic Engineer, Process Engineer...?
Professional Engineer, like Dipl.Ing. in Germany (which is where I come
from originally)
Cheers,
Ralph Hempel - P.Eng
------------------------------------------------------
The train stops at the train station,
The bus stops at the bus station,
So why am I sitting at a work station?
------------------------------------------------------
Reply to: rhempel at bmts dot com
------------------------------------------------------
|
|
Message is in Reply To:
 | | Re: The pain of communicating with the RCX
|
| (...) 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? (...) But then you can't use those constants (i.e the words, (...) (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
|
|
|
|
