USB stack artificially limits endpoints for LPC17XX

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USB stack artificially limits endpoints for LPC17XX

858 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by smoorby on Wed Apr 18 07:42:38 MST 2012
With the USB device block in the LPC17XX family there is support for 16 bidirectional logical endpoints.  This is realised by 32 physical endpoints alternating OUT / IN.  The nxpUSBlib code limits this in two ways :-

1/ ENDPOINT_TOTAL_ENDPOINTS is defined to be 6.
This is easily changed as needed.

2/ The global variable variable 'endpointhandle' is an array storing the mapping from logical to physical endpoint.  This array only allows you to map a logical endpoint number to either OUT or IN, not both as is supported by the hardware. 
This leads to what seems to me to be a strange descriptor for the 'Example_VirtualSerial' code.  CDC_TX_EPNUM is 2 and CDC_RX_EPNUM is 5.  Looking at it from the device point of view you might also expect the RX_EPNUM to be 2 rather than having to jump to the next endpoint capable of bulk transfers.  There's also several places in the code I've seen that assumes this restriction.

I guess this might not be of practical importance for a lot of applications, as long as they have enough endpoints for the application they perform.  Seems stange to me though that nxpUSBlib doesn't make best use of the very good USB device block in the LPC17XX.

Regards
Steve
Labels (1)
0 Kudos
2 Replies

712 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by smoorby on Thu Apr 19 14:35:14 MST 2012
Hi Tuong,

That would certainly work and is probably the most robust solution.  However, you might get away with just using the context of the operation that's being performed as well as the endpoint number.  For example both CD_TX_EPNUM and CDC_RX_EPNUM could be 2, a read for this endpoint would refer to physical endpoint 4 (OUT) and a write to this endpoint would refer to physical endpoint 5 (IN).

Regards
Steve
0 Kudos

712 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by tuong on Wed Apr 18 19:33:42 MST 2012
Dear Smoorby,

I think the problem is because CDC_TX_EPNUM or CDC_RX_EPNUM stores only number, they don't contain direction, ex. 0x00 for OUT and 0x80 for IN. And the application layer uses this only number to talk to the lower layers like class, usbd.. endpointhandle is needed for the lower layers understand what application layer is asking.

To improve as your request, I think CDC_TX_EPNUM and CDC_RX_EPNUM have to store direction information. At this moment, endpointhandle can be removed.

With best regards,
Tuong Nguyen
0 Kudos