Subject:
|
Which terminal on Linux? plus random thoughts.
|
Newsgroups:
|
lugnet.robotics.rcx.pbforth
|
Date:
|
Thu, 4 May 2000 16:12:39 GMT
|
Reply-To:
|
sjm@/NoMoreSpam/judgement.com
|
Viewed:
|
1501 times
|
| |
|
|
I'm interested in other people's experience with various
terminal emulators on Linux. I've been using minicom with
indifferent results, probably because it doesn't support
delays between lines which possibly overruns pbforth's
serial input. minicom is also a drag because it needs
termcap which makes it unusable under emacs. I really
want a simple tip like program that emulates the dumbest
of terminals and does little more than CR/LF handling.
emacs will handle line editing for me. Maybe I want tip
which doesn't seem to exist on my Linux box.
Also I'm currently fiddling with some simple communication
tools in Tcl but I suspect that I am covering otherwise
well travelled ground. Does anyone have example Tcl code that
they can share with me. After a hour or so of experimentation
(mostly finding documentation on setting up the serial port
in Tcl) I can send to the RCX but can't read yet.
The following is mostly blather and thinking out loud.
My goal is a set of Tcl procs that support simple
communication, hiding the echo, delaying where necessary
etc. that can then be used in developing PC code that talks
to forth code in the RCX. On top of that I will build a
simple command/response protocol with a null command mostly
to tickle the tower and keep it awake. What I mean by
command/response is that the RCX will remain silent unless
asked for data. If the RCX has anything to say it will be
buffered until the PC asks for it. I choose this method
because it is extremely easy to implement in a half duplex
environment. If it is not simple realistically I will never
get it done.
On top of that simple com layer I will make a simple
command interface which will allow me to invoke one of
a selection of forth words. I'll use a simple command
packet structure something like:
byte function
0 Possibly some flag bytes for synchronization. I usually
throw in a few for paranoia. Maybe the same as the frame
byte. Maybe not.
1 frame byte. This starts the packet.
2 target address (possibly to support multiple RCXs)
Address 0 is for idle keep alive packets.
3 sequence number. Specific each target. Used to
recognize duplicate packets.
4 command byte. This mostly specifies a forth word to
be executed on the RCX.
5 length bytes remaining in packet. Zero for simple
commands. Counts CELLS.
6-n array of 16 bit command arguements passed to
forth word.
n+1 possibly a checksum. Can I steal this from the
downloader from next release?
The response packet will be similar in format except that
address will be the address of the RCX. The sequence number
will match the highest sequence number received. The command
and data field will somehow represent the response from
the PC command. I haven't thought this completely through.
The basic reliability mechanism is:
Every command should get a response. If not, on timeout
a command will be resent. The RCX responds to a duplicate
by resending the response. It must therefor save each
response until it gets the next valid command packet.
There should be no collisions unless the RCX is slow to
reply and a retry is done from the host. Proper care
in timing should cope with that, i.e. if RCX can't send
response in the timeout period don't even try.
NOTE: This is all simpler than it probably seems. The hard
part about these communication protocols is getting the
design right, mostly making the reliability mechanism match
the actual sources of problems. Implementation is usually
quite straightforward once you know what to implement.
I suppose that is true of most software.
Is there anything I need to know about communication with
RCX besides the tower timeout and the local echo caused by
the IR seeing its own output? Can I just ignore the CTS/RTS
signals (used to detect the tower.) I suppose that I need
to configure the serial port for hardware handshake or at
least disable software handshake.
|
|
Message has 1 Reply:
7 Messages in This Thread:
   
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
