 | | Re: LinuxPPC and "No response from RCX" problem
|
|
(...) This may not be a driver bug - it may be a hardware limitation. AFAIK, parity is most commonly used with 7 bit words - support for a ninth bit (8 data plus parity) is poor or non-existant on some UARTs. Dave (24 years ago, 4-Nov-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: LinuxPPC and "No response from RCX" problem
|
|
(...) This helped me track down the problem - the minute I add the odd parity bit the serial driver changes the word length from 8 to 7. Doesn't look like I can do much about it from the Linux side either. :( Thanks for the help everyone, looks like (...) (24 years ago, 4-Nov-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: LinuxPPC and "No response from RCX" problem
|
|
(...) Perhaps timing is a problem. Try: nqc -t 1000 -raw 10 This forces a longer (1 second) timeout per packet instead of the dynamic retry timing. Is the output any different? Echo is coming back from the tower, which means communication between (...) (24 years ago, 4-Nov-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: LinuxPPC and "No response from RCX" problem
|
|
(...) Have you tried using setserial to set the correct baud rate and other options? Also note that when using "su" it sometimes doesn't take over all the settings from the user account that you used to log on. Perhaps the sudo command would work (...) (24 years ago, 4-Nov-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: LinuxPPC and "No response from RCX" problem
|
|
(...) Umm.. note the prompt ;)) I'd done an su root before testing to avoid permissions problems. This seems like a problem with nqc on LinuxPPC 3Q99, but I can't understand quite what it is as the tower obviously works - the green light is visible (...) (24 years ago, 3-Nov-00, to lugnet.robotics.rcx.nqc)
|
