This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: USB 2.0

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 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    The eCos and RedBoot experts
------["The best things in life aren't things."]------      Opinions==mine

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]