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

RE: [ECOS] Splitting USB-Packets

[Frank Pagliughi]

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

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Fuchs,
Torsten
Sent: Wednesday, April 13, 2005 10:07 AM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] Splitting USB-Packets


Hi,

I need to send or receive large amounts of data via USB using the usbs
slave. The data sizes can under certain circumstances be larger then the RAM
in the system so I have to split the data into blocks. From the hosts point
of view there shall be only one big USB-packet.

Receiving is not a problem but transmitting. When sending multiples of the
maximum packet size (64 Bytes) the device driver generates a zero length
packet to end the data transfer. So the host sees an interrupted packet. I
need an option to supress the generation of this zero length packet to
continue the transmission with another call of usbs_start_tx. Only the last
block should be finished with a zero length packet.

Every modification would not be compatible to the slave package so how can I
solve this problem? In my opinion there should be an additional flag to
enable/ disable the generation of the last packet by the driver.

Thanks
Torsten

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




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

[ECOS] Splitting USB-Packets

[Fuchs, Torsten]

Hi,

I need to send or receive large amounts of data via USB using the usbs slave. The data sizes can under certain circumstances be larger then the RAM in the system so I have to split the data into blocks. From the hosts point of view there shall be only one big USB-packet.

Receiving is not a problem but transmitting. When sending multiples of the maximum packet size (64 Bytes) the device driver generates a zero length packet to end the data transfer. So the host sees an interrupted packet. I need an option to supress the generation of this zero length packet to continue the transmission with another call of usbs_start_tx. Only the last block should be finished with a zero length packet.

Every modification would not be compatible to the slave package so how can I solve this problem? In my opinion there should be an additional flag to enable/ disable the generation of the last packet by the driver.

Thanks
Torsten

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