 | | | | | | |
| |
|
Dear Juergen and Andy,
I found the option to turn on data debugging on legousbtower this
evening. It all turned out to be an issue between uhci and legousbtower.
From the out_callback I could tell, it always sent 8 bytes no matter
what tower_send submitted. The RCX brick was probably choked by the
extra bytes.
Looking at the uhci code, I found that it was dma'ing acording to
urb->transfer_buffer_length instead of the urb->actual_length.
I don't have the specifications to tell what uhci should be looking at.
Anyway I modified tower_send to submitted bytes_to_write as
buffer_length as a workaround/fix.
It is now working!!!
As promised Juergen this morning, I am sending in the changes I made.
Please feel free to try and optimize them. (The usleeps I I added may
not be optimal nor accurate at all The locks I added may not be that
necessarily after all.)
Thank you very much again for your kind response and time.
Cheers,
P.C. Chan
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
P.S.
To use RCX_USBTowerPipe_linux.cpp, please put it into the rcxlib
directory under nqc-2.4.a4 and modify the Makefile to take
RCX_USBTowerPipe_linux.o instead of RCX_USBTowerPipe_none.o
To use legousbtower,
-> // please mknod /dev/tower0 c 240 180
// ( mknod /dev/tower1 c 240 181.. if you have more than 1 tower.)
( chmod if necessary.) before insmod.
-> It works with uhci but NOT usb-uhci.
---
***Sorry typos: mknod /dev/tower0 c 180 240
mknod /dev/tower1 c 180 241 ...
valid minor nodes 240 to 245 (but not yet registered.)
********************************************************************
--
MIME ATTACHMENTS DISCARDED:
1. Content-Type: application/octet-stream;
name="legousbtower.c-1.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="legousbtower.c-1.gz"
Content-Length: 9040
2. Content-Type: application/octet-stream;
name="RCX_USBTowerPipe_linu-1.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="RCX_USBTowerPipe_linu-1.gz"
Content-Length: 2077
| | | | | | | | | | | | | | | |
Hello,
I can confirm, that this worked!
First time lego usb support on my linux machine:
jstifter@suba:~/nqc-2.4.a4 > bin/nqc -Susb -TRCX2 -d test.nqc
Downloading Program:..complete
Battery Level = 9.2 V
jstifter@suba:~/nqc-2.4.a4 >
I had to comment out the last line of legousbtower.c, since I run kernel
2.4.7-ac9 at the moment. and it doesn't understand
MODULE_LICENSE("GPL");
Great work. Thanks to you!
Jan
| | | | | | | | | | | | | | | | | |
| |
|
At 23:00 -0500 2002-01-11, PC CHAN wrote:
> Dear Juergen and Andy,
>
> I found the option to turn on data debugging on legousbtower this
> evening. It all turned out to be an issue between uhci and legousbtower.
>
> From the out_callback I could tell, it always sent 8 bytes no matter
> what tower_send submitted. The RCX brick was probably choked by the
> extra bytes.
>
> Looking at the uhci code, I found that it was dma'ing acording to
> urb->transfer_buffer_length instead of the urb->actual_length.
>
> I don't have the specifications to tell what uhci should be looking at.
> Anyway I modified tower_send to submitted bytes_to_write as
> buffer_length as a workaround/fix.
I believe this is correct. actual_length is only used on incoming
data because the amount of data supplied may be less than the maximum
buffer size (held in transfer_buffer_length).
On the transmission side you just use transfer_buffer_length
> It is now working!!!
Excellent...now to see if it is any better on the OHCI HCD.
Stu
--
The Janitorium <http://www.janitorium.co.uk/>
| | | | | | |
