Istvan De wrote:
Hi!
Sorry for the delay in replying, I was the one who started
this thread on usb-devel.
It seems that the acm driver sets the maximum transfer size to
the wMaxPacketSize field of the relevant endpoint descriptor,
this is maximum 64 bytes for a bulk high speed endpoint.
Fro
On Mon, Aug 29, 2005 at 01:52:14PM -0400, Greg Lee wrote:
> > > Currently I've made a preliminary firmware for implementing the
> > > CDC-ACM interface, however as Pavel kindly pointed out for me,
> > > currently only 64Kbyte/sec is achieveable with this driver. I've read
> > > the archives and
Alan Stern <[EMAIL PROTECTED]> said:
> On Mon, 29 Aug 2005, Brian Murphy wrote:
>
> > It seems that the acm driver sets the maximum transfer size to
> > the wMaxPacketSize field of the relevant endpoint descriptor,
> > this is maximum 64 bytes for a bulk high speed endpoint.
> > From my experime
> >900 K bits/sec or 900 K bytes/sec?
> >
> >Greg
> >
> That would be bytes :)
>
> /Brian
Thanks. 900 K bits/sec === bad, 900 K bytes/sec === good!
Greg
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22
On Mon, 29 Aug 2005, Brian Murphy wrote:
> It seems that the acm driver sets the maximum transfer size to
> the wMaxPacketSize field of the relevant endpoint descriptor,
> this is maximum 64 bytes for a bulk high speed endpoint.
> From my experiments this does not just restrict bulk packets to
>
Greg Lee wrote:
I wrote my own user space driver which has achieved write
speeds of 900k/s.
900 K bits/sec or 900 K bytes/sec?
Greg
That would be bytes :)
/Brian
---
SF.Net email is Sponsored by the Better Software Confer
> I wrote my own user space driver which has achieved write
> speeds of 900k/s.
900 K bits/sec or 900 K bytes/sec?
Greg
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Dev
Greg Lee wrote:
Currently I've made a preliminary firmware for implementing the
CDC-ACM interface, however as Pavel kindly pointed out for me,
currently only 64Kbyte/sec is achieveable with this driver. I've read
the archives and from the discussions, I suspect that this is
connected to the
> > Currently I've made a preliminary firmware for implementing the
> > CDC-ACM interface, however as Pavel kindly pointed out for me,
> > currently only 64Kbyte/sec is achieveable with this driver. I've read
> > the archives and from the discussions, I suspect that this is
> > connected to th
On Sad, 2005-08-27 at 21:49 -0700, Pete Zaitcev wrote:
> The size of flip buffers, I expect. And you cannot flip them too often.
I sent Andrew Morton the patches to fix all the tty layer buffering
limits by replacing the flip buffers with kmalloc managed rings of
buffers. I've not heard back so I'
On Sat, 27 Aug 2005 23:13:06 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> On Sat, 27 Aug 2005, Istvan De wrote:
> > I'm developing a USB2.0/Full Speed (12MBit) audio device for Linux which
> > needs high speed (>256Kbyes/sec)/low delay bidirectional data transfer.
>
> Don't refer to that
On Sat, 27 Aug 2005, Istvan De wrote:
> Hello,
>
> I'm developing a USB2.0/Full Speed (12MBit) audio device for Linux which
> needs high speed (>256Kbyes/sec)/low delay bidirectional data transfer.
Don't refer to that as "high speed". In USB, "high speed" means 480 Mb/s.
The data rate you wan
Hello,
I'm developing a USB2.0/Full Speed (12MBit) audio device for Linux which
needs high speed (>256Kbyes/sec)/low delay bidirectional data transfer.
To
ease development I'd prefer to skip driver development by implementing
some
device class, which already has a driver.
Currently I've made a p
13 matches
Mail list logo
