Changing the USB-driver datas... Using an array: usb_working_endpoint ep[ENDPOINTS-1]

Changing the USB-driver datas... Using an array: usb_working_endpoint ep[ENDPOINTS-1]

[oliver munz @ s p e a g]

I think the eCos-USB-slave endpoint data structures should be changed. The 
USB-slave-package should define one struct for all endpoint types whitout 
the control-endpoint.

The device-driver should define an array of all working endpoint-structs 
ep1..n. All enndpoint-functions should get an index variable, so that they 
can address the right struct from the array.

The device-driver and the USBS-interface should define a function to control 
the type and state of an working endpoint.

I don't see any reason in using blabla_ep1(&ep1) and so on, instead of 
something like blabla_ep(ep_array, 1);

Are there other ideas how to improve the USBS and USB-driver APIs?



Thanks
Oliver Munz 

Re: Changing the USB-driver datas... Using an array: usb_working_endpoint ep[ENDPOINTS-1]

[Frank Pagliughi]

oliver munz @ s p e a g wrote:

> I think the eCos-USB-slave endpoint data structures should be changed. 
> The USB-slave-package should define one struct for all endpoint types 
> whitout the control-endpoint.
>
> The device-driver should define an array of all working 
> endpoint-structs ep1..n. All enndpoint-functions should get an index 
> variable, so that they can address the right struct from the array.
>
> The device-driver and the USBS-interface should define a function to 
> control the type and state of an working endpoint.
>
> I don't see any reason in using blabla_ep1(&ep1) and so on, instead of 
> something like blabla_ep(ep_array, 1);
>
> Are there other ideas how to improve the USBS and USB-driver APIs?
>
>
>
> Thanks
> Oliver Munz
>
>
Sorry for the unbelievably slow response on this one. I just noticed the 
post a few days ago.

I agree completely. The eCos USB interface was defined at a time when 
USB device chips had specific endpoints for specific purposes (one for 
Bulk IN, one for Bulk OUT, etc). Now days, the chips seem to have banks 
of configurable "generic" endpoints. So I'm all for arrays of endpoints. 
And sending endpoint numbers to the driver functions.

Another idea I played with last year was the idea of slave-side USB 
request blocks (SURB's, as I called them). These were similar to 
host-side URB's. The surb layer is a low-level, device-independent, 
module that schedules access to the usb hardware.

The problem I was facing was this: in the app I was developing, 
communications were the lowest priority. Several threads were performing 
communications, each with their own USB endpoint, and each assumed 
exclusive access to the endpoint. So the driver was responsible for 
gating access to the chip from all these threads and the chip's DSR. The 
only way I figured to do this was by locking the scheduler. This, then 
played havoc with thread latency for the high-priority threads.

So rather than allowing each thread to access the chip, I set up the 
SURB driver. All threads submitted read and write requests to the SURB 
layer. Even the chip's DSR submitted a "chip needs processing" request. 
So only the SURB thread ever touches the chip (via low-level calls back 
to the driver) and no locking is necessary. Throughput might take a hit, 
but that was less important then determinism.

It might also allow for better error handling. Some of the USB chips are 
still pretty flaky, and could do with some redundant error checking.

This would be an optional layer for drivers. Individual drivers could 
use it or not at their discretions.

Frank