AW: [ECOS] Splitting USB-Packets

AW: [ECOS] Splitting USB-Packets

[Fuchs, Torsten]

Hi,

I'm using a philips ISP1583 with a self-written driver in a digital camera to implement the PTP (Picture transfer protocol). So there are only bulk and some interrupt transfers. The hardware does not send the zero packet automatically. Modifying the device driver is not the problem but getting a flag through the overlying slave package, that I want to use. It seems I have to modify it and be no more compatible to the original package. I just wondered if no-one had the problem of splitting larger packets into pieces until now. 
The PTP-Standard says that the first short or zero packet ends the transfer, so I think there is no other way than modifying the driver.

The host side is a PC or MAC. I did not know that WinXP breaks up the packets in smaller units when they exceed a certain size. But relying on this "feature" is not a safe way for the device.

Torsten Fuchs


-----Ursprüngliche Nachricht-----
Von: Frank Pagliughi [mailto:fpagliughi@mindspring.com]
Gesendet: Mittwoch, 13. April 2005 23:41
An: Fuchs, Torsten; ecos-discuss@sources.redhat.com
Betreff: RE: [ECOS] Splitting USB-Packets


Which USBS device/driver are you using? Does the hardware automatically send
the zero packet? I assume not, so you could modify the driver for your
specific application - if that's what you really want to do. I've been
working with Philips chips, where you have to send the zero packet
explicitly. And you do *need* to do this by default, especially if you're
using the higher level File I/O functions.

BTW, are you talking about Bulk transfers?

And what are you using on the host side? I don't know that low-level USB
functions guarantee undivided packets back to user mode code (or even upper
level drivers). In a Windows XP device driver I just wrote I would see Bulk
IN packets broken up by the underlying bus driver when they were around the
4kB page size. That would require repeated read() calls by the application
to reconstruct the full packet, sort of like reading a TCP stream.

Frank Pagliughi


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Splitting USB-Packets

[Frank Pagliughi]

Yes, I've wrestled with a few items in the USB Slave package myself. My
biggest problem in a driver for the Philips ISP1181 is that the endpoint
data structures aren't enumerated, or self-identifying, other than their
command function pointers. The 1181 has 14 identical, configurable
endpoints. The driver would be considerably more flexible and compact if  I
could have set all the start & halt functions to generic versions, then used
the endpoint number when handling the request. Or something like that.

Also, if there were a generic ioctl() that could be handled by the driver
and/or endpoints, it could take care of application-specific items (like
witholding the zero packet) and configuring the device's interfaces or
endpoints.

I believe the eCos USB Slave package was designed & implemented when the USB
chips were still fairly rigid (and buggy). Now that some are getting more
flexible, perhaps the slave package should be modified to support them.

As for the Windows stuff, I'm no driver expert, but in my driver, if I sumit
a URB for a 4k IN (read) and I do a 4k transfer from the device, I ALWAYS
get back 4032 bytes. I need to do a second read, which then returns the
remaining 68 bytes. Never asked why. I just keep reading till I get what I
expected or an error occurs.

Frank Pagliughi
Software & Systems Engineer
SoRo Systems, Inc


-----Original Message-----
From: Fuchs, Torsten [mailto:Torsten.Fuchs@jenoptik.com]
Sent: Thursday, April 14, 2005 4:24 AM
To: Frank Pagliughi; ecos-discuss@sources.redhat.com
Subject: AW: [ECOS] Splitting USB-Packets


Hi,

I'm using a philips ISP1583 with a self-written driver in a digital camera
to implement the PTP (Picture transfer protocol). So there are only bulk and
some interrupt transfers. The hardware does not send the zero packet
automatically. Modifying the device driver is not the problem but getting a
flag through the overlying slave package, that I want to use. It seems I
have to modify it and be no more compatible to the original package. I just
wondered if no-one had the problem of splitting larger packets into pieces
until now.
The PTP-Standard says that the first short or zero packet ends the transfer,
so I think there is no other way than modifying the driver.

The host side is a PC or MAC. I did not know that WinXP breaks up the
packets in smaller units when they exceed a certain size. But relying on
this "feature" is not a safe way for the device.

Torsten Fuchs


-----Ursprüngliche Nachricht-----
Von: Frank Pagliughi [mailto:fpagliughi@mindspring.com]
Gesendet: Mittwoch, 13. April 2005 23:41
An: Fuchs, Torsten; ecos-discuss@sources.redhat.com
Betreff: RE: [ECOS] Splitting USB-Packets


Which USBS device/driver are you using? Does the hardware automatically send
the zero packet? I assume not, so you could modify the driver for your
specific application - if that's what you really want to do. I've been
working with Philips chips, where you have to send the zero packet
explicitly. And you do *need* to do this by default, especially if you're
using the higher level File I/O functions.

BTW, are you talking about Bulk transfers?

And what are you using on the host side? I don't know that low-level USB
functions guarantee undivided packets back to user mode code (or even upper
level drivers). In a Windows XP device driver I just wrote I would see Bulk
IN packets broken up by the underlying bus driver when they were around the
4kB page size. That would require repeated read() calls by the application
to reconstruct the full packet, sort of like reading a TCP stream.

Frank Pagliughi




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss