 | | RE: The pain of communicating with the RCX
|
|
(...) Depends on which side of the fence you are on... (...) Hmmm. This is not good. I have ghad very good success with CRT, but I'm going to try a more general solution with Tcl. (...) I stopped supporting it late last year because it only worked (...) (25 years ago, 9-Mar-00, to lugnet.robotics.rcx.pbforth)
|
| |
| | Re: The pain of communicating with the RCX
|
|
On Thu, Mar 09, 2000 at 09:04:26PM +0000, Ralph Hempel wrote: [...On a TCL program to communicate with the RCX...] (...) Uploading srec files has been without problem for me; it's uploading text that's painful. Does your program uses some protocol (...) (25 years ago, 10-Mar-00, to lugnet.robotics.rcx.pbforth)
|
| |
| | 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)
|
| |
| | 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)
|
| |
| | 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)
|
