This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: Changing the USB-driver datas... Using an array: usb_working_endpoint ep[ENDPOINTS-1]
- From: Frank Pagliughi <fpagliughi at mindspring dot com>
- To: "oliver munz @ s p e a g" <munz at speag dot ch>
- Cc: ecos-devel at sourceware dot org
- Date: Fri, 02 Jun 2006 11:22:49 -0400
- Subject: Re: Changing the USB-driver datas... Using an array: usb_working_endpoint ep[ENDPOINTS-1]
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=oBzq25utBqUzQj8e79kJk1CVO8Jw8dnzpeBRvkyip1anUbcB/aF0JywDvd5NPR9I; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
- References: <049901c62b7a$08013860$1f01a8c0@haus.hellmutstrasse.ch>
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