> So I am considering the pros and cons of using such a strategy in the
> LegoUSB driver. That is, read and write interrupt transfers are
> submitted at probe-time and these tick over in the background forever
> reading/writing data between the device and circular read and write
> buffers in the driver.
> When an application calls the driver read() it simply returns whatever
> is currently in the read buffer. Conversely, a call to write() simply
> copies data into the circular write buffer where it later transferred
> to the device by the write interrupt.
>
FWIW, this strategy is quite similar to what the Windows driver does; the
biggest difference is that I don't have a circular write buffer, but rather
pass down immediately any write requests to the USB host controller driver
(who takes care of packet splitting and other details and then sends out the
data).
I can confirm that this technique has worked fairly well so far (under
Windows at least :-)
Antonello
-----Original Message-----
From: Stewart Heitmann
To: 'legousb-devel@...'
Cc: 'sheitmann@...'
Sent: 2/2/03 9:22 AM
Subject: [Legousb-devel] a new driver read/write strategy
Hi all,
after comparing the code for the LejOS usb tower driver
and the LegoUSB driver I am starting to suspect the
read/write strategies used by both drivers are not quite
right.
I have been having limited sucess getting the LegoUSB read()
function to work on my system
Linux 2.4.18-19.7.x
usb-ohci.c: USB OHCI at membase 0xc48b8000, IRQ 10
usb-ohci.c: usb-00:01.2, Silicon Integrated Systems [SiS] 7001
I can write to the RCX and read some bytes back, but many bytes
(more than half) are lost on the return.
At first I suspected this is because the turn-around time of the
single-shot read was too long. So I modified the code to accumulate
the results from multiple interupts into a single buffer in
the driver before returning to the user, but that really didnt
help much.
I was suprised by that, because it is the same strategy used
by the LeJOS driver which was reported to work and I figured
that it would solve the problem.
Unfortunately the LeJOS driver did not work for me at all,
it could not write to my RCX
legousbtower.c : tower_write : enter, count = 7
legousbtower.c : tower_write : in progress, count = 7
legousbtower.c : tower_write : retval = _EAGAIN
legousbtower.c : tower_write : leave, return value -11
legousbtower.c : tower_write : enter, count = 7
legousbtower.c : tower_write : in progress, count = 7
legousbtower.c : tower_write : retval = _EAGAIN
legousbtower.c : tower_write : leave, return value -11
legousbtower.c : tower_write : enter, count = 7
legousbtower.c : tower_write : in progress, count = 7
legousbtower.c : tower_write : retval = _EAGAIN
legousbtower.c : tower_write : leave, return value -11
legousbtower.c : tower_write : enter, count = 7
legousbtower.c : tower_write : in progress, count = 7
legousbtower.c : tower_write : retval = _EAGAIN
legousbtower.c : tower_write : leave, return value -11
legousbtower.c : tower_interrupt_out_callback : enter, status 0
legousbtower.c: tower_interrupt_out_callback - toggle = 0, length = 7,
data = 55 ff 00 10 ef 10 ef
legousbtower.c: tower_interrupt_out_callback - toggle = 0, length = 7,
data = 55 ff 00 10 ef 10 ef
legousbtower.c : tower_interrupt_out_callback : leave, status 0
I suspect the LeJOS driver write() is misguided in creating so many
urbs, and that is why the EAGAIN messages appear, but that is another
story.
I got a bit disgruntled with both these approaches and had a look around
for other USB drivers implementing interrupt transfers and found the USB
mouse and keyboard drivers.
These drivers use a different approach, namely they submit read and
write
urbs at probe-time and leave those interrupts to tick over in the
background
for the life of the device. They do not implement read() or write() at
all,
but use the irq to call a kernel-level handler, which is what you would
expect for a keyboard and mouse but not necessarily for a Lego Tower.
So I am considering the pros and cons of using such a strategy in the
LegoUSB
driver. That is, read and write interrupt transfers are submitted at
probe-time
and these tick over in the background forever reading/writing data
between
the device and circular read and write buffers in the driver.
When an application calls the driver read() it simply returns whatever
is
currently in the read buffer. Conversely, a call to write() simply
copies
data into the circular write buffer where it later transferred to the
device
by the write interrupt.
I feel this approach is more in the spirit of the interupt transfer
mechanism.
In fact it looks to me like someone once setup read and write urbs in
the
legoprobe()
function but they have since become unused. Perhaps this approach was
tried
once before.
Does anyone have any opinions on this?
Stewart Heitmann
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Legousb-devel mailing list
Legousb-devel@...
https://lists.sourceforge.net/lists/listinfo/legousb-devel
|