Subject:
|
LNPd keeps sending TX_FAILURE
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 7 Jan 2005 00:15:24 GMT
|
Viewed:
|
7050 times
|
| |
|
|
I’m running LNPd on Gentoo Linux 2.6.7. Everything seems to work fine except
transmitting messages to the RCX. The lnptest application that comes with LNPd
keeps reporting a Collision every time it tries to transmit something. It does
however correctly report messages that it receives (from the corresponding
program for the RCX). I tried going in transceiver.c of the LNPd source and
commenting out sections that called tx_error(), but then another section would
call it. In fact, all of the places that could call tx_error() called it when
the one before it was commented out: the frame error check in rcx_read() (I
don’t pretend to know what a frame error is), the transmit collision check
that compares rcv_buffer with tx_verify, and check_interbyte_timeout().
Here’s the information I’ve been able to glean about each of these errors. It’s
not that long of a read. The frame error seems to be triggered if a call to
ioctl() requesting TIOCGICOUNT, which apparently “reads serial port inline
interrupt counts”, returns a different value than the previous value in
rcx_read(). Doesn’t exactly clear things up for me, but hopefully it will help
determine the problem. tx_verify is a global variable and is set by
rcx_write() during a write. It is compared to rcv_buffer, which is read from
the transceiver by rcx_read() (which does the checking). If they differ,
tx_error() is called which causes LNPd to send TX_FAILURE. Both of these
error checks only call tx_error() if the global active varible is true,
which is set in rcx_write(). So, it seems that after a write (rcx_write()
called), rcx_read() reads back the data that was written (an echo?) and
compares it to the data that should have been written. It also checks to make
sure that no “inline interrupts” have been called since the last write, I’m not
sure exactly what this means, possibly that something was sent to the
transceiver (but don’t take my word for it). As for check_interbyte_timeout(),
it’s called by run_transceiver() when there isn’t anything to read and checks
if the “interbyte timeout” has been reached, which is updated every
rcx_read(). I don’t know how correct my inferences are, but hopefully it’ll
help those who haven’t gone as in-depth into the source as I have to figure it
out.
Can anyone explain why this might be happening? Transmitting to the RCX is vital
to the project I’m working on, so any help is greatly appreciated.
Tyler Mandry
|
|
Message has 2 Replies:
 | | Re: LNPd keeps sending TX_FAILURE
|
| I don't use LNPd or BrickOS so I don't know if this will work. It makes all sorts of problems go away when using the RCX ROM message handling routines, I don't know how much of the ROM routines are used by LNPd or whether, if it doesn't, it has (...) (20 years ago, 7-Jan-05, to lugnet.robotics.rcx.legos)
| | | Re: LNPd keeps sending TX_FAILURE
|
| (...) Keep in mind that lnpd out of the box does _not_ work with brickOS out of the box! This item was discussed in this forum several times, you should search for lnpd in older postings. The next version of brickOS will be accompanied by an updated (...) (20 years ago, 7-Jan-05, to lugnet.robotics.rcx.legos)
|
6 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
