Re: USB 2.0

[Jonathan Larmour <jifl at eCosCentric dot com>]

Fuchs, Torsten wrote:
> Hi,
>
> 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.

> ecos/pacakges/io/usb/common/current/include/usb.h:
> - added device qualifier and other speed configuration descriptor
> - added defines for testmodes
>
> ecos/packages/io/usb/slave/current/include/usbs.h
> ecos/packages/io/usb/slave/current/src/usbs.c
> - 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?

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
------["The best things in life aren't things."]------      Opinions==mine