This is the mail archive of the
mailing list for the eCos project.
Re: USB 2.0
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: "Fuchs, Torsten" <Torsten dot Fuchs at jenoptik dot com>
- Cc: ecos-patches at sourceware dot org, Bart Veer <bartv at ecoscentric dot com>, Andrew Lunn <andrew at lunn dot ch>
- Date: Thu, 16 Nov 2006 15:39:54 +0000
- Subject: Re: USB 2.0
- References: <5A8A17126B73AC4C83968F6C4505E3C505AAACF1@JO-EX01.JENOPTIK.NET>
Fuchs, Torsten wrote:
i have added support for USB 2.0 to the ecos usb packages, in detail:
That sounds like a very useful patch. If we are to include this in eCos, we
will need a copyright assignment, which is part of the standard procedure.
You can read more about this at http://ecos.sourceware.org/assign.html
which includes the relevant forms. Your colleague Alexander completed one
for himself a while back, so Jenoptik have been through this already.
Sorry about the bureaucracy, but it is important.
- added device qualifier and other speed configuration descriptor
- added defines for testmodes
- usbs_enumeration_data has new members for other speed configurations and high- and full speed endpoints
- usbs_control_endpoint has new or different members:
- speed of the requested descriptors
- state_change_fn receives a new parameter: current speed
- current_speed stores the current usb speed
- current_packet_size stores the maximum packet size allowed for the current_speed
- extensions to the endpoints:
- endopints have a new member index (their usb index)
- new member end_packet says if the driver shall end the packet. If the packet size is
a multiple of the max packet size, and end_packet is set, no zero length packet is
sent or expected. So packets can be sent or received in multiple portions (e.g.
12000 bytes in a portion of 8192 bytes (end_packet = 0) and an other of 3808
(with end_packet = 1). This reduces the neccessary buffer size in the application.
- enable_dma says if the driver shall use DMA for the respective endpoint.
- pointer to a function that shall be called from a dsr (e.g. to handle a switch to thread context)
The problem might be, that since some members and function declarations changed, old code is not compatible and needs to be updated.
Unfortunately I don't have much of an idea myself on how easy or not it
would be to have a stab at updating the existing drivers to this new
interface. It would certainly be very desirable.
Regardless, would it make sense to add a CDL configuration option to
control USB 2 specific changes? Could people still want to be able to
provide a USB 1 only device?
I think the details of reviewing the patch will need to be handled by
someone more familiar with the USB code. Bart? Andrew? Care to volunteer?
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
------["The best things in life aren't things."]------ Opinions==mine