We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I am stuck at the point where the endpoints at my disposal are not enough to fulfill the functional requirements. I am using lpc3131 from NXP and it provides 3 endpoints ( excluding 1 control EP). But my device communicates at 4 endpoint addresses. So, is there a way that i can share a physical endpoint with two logical pipes so that when host requests data from device's two endpoints say 81 and 85 , but only available being 81 , request at 85 is also serviced by the 81 or 82 or 83( as only 3 are available)?
What is "your device"? What is stopping you from multiplexing data on a single endpoint, so the PC just asks for "data" and if you have any data you send back both the data and a marker telling if it was data for ADC channel 3 or temperature sensor 9. Is there a situation where the PC just must not retrieve the wrong data from your device?
Okay...i am working on a development board containing lpc3131 in device mode to communicate with my host(PC). There is a restriction or i need that one device function's data will always be on EP 85 but lpc3131 hard wires its logical EPs to the physical EPs i.e. logical EP1 will be going to be physical EP 81 or 01 and same for rest 2 available. Now how do i proceed for BULK IN at 85 as host will request for 85 but will not find that EP. How can i tweak the settings in firmware or host side so that i am able to communicate with this EP 85 using available 3 physical EP on lpc.
As the chapter title, "1.5 Fixed endpoint configuration - USB OTG", shows on the LPC3131 user manual, the endpoint addresses and transfer type are fixed for this USB engine. To work with this MCU, you have to change the endpoint address on the PC application code.
Using fixed endpoint address on PC side is a bad practice. It causes this trouble on device migration, because most of USB MCU can't change endpoint address freely.
Better coding practice is that PC app retrieves the endpoint address by reading out the descriptor from the device on run time.
For WinUSB example, WinUsb_QueryInterfaceSettings() returns the number of endpoints on the interface (USB_INTERFACE_DESCRIPTOR.bNumEndpoints). WinUsb_QueryPipe() returns the endpoint address (PipeId) and transfer type (PipeType) in WINUSB_PIPE_INFORMATION structure for each endpoint on the interface. The endpoints are indexed by the order in which they appear on the descriptor set. Using these APIs, your PC app can identify the target endpoint(s), by the order, transfer direction and type.
WinUsb_QueryInterfaceSettings msdn.microsoft.com/.../ff540292(VS.85).aspx WinUsb_QueryPipe msdn.microsoft.com/.../ff540293(VS.85).aspx
Decent generic device drivers certainly provide this type of API. When the PC application follows this practice, re-usability of the code improves so much.
Tsuneo
Ah, if you are working with a class driver on the PC, such as HID and CDC, you don't need to worry about the endpoint address on the device. USB classes define the number and transfer direction/type of mandatory and optional endpoints on the interface. Class drivers determine target endpoints automatically, following above good coding practice.
Just for generic driver, you have to take care of this practice.
I agree with you, and able to see all the descriptor information.But the problem is still there : My device application wants to put it's 6 different functionality on 6 different end point numbers but the processor lpc3131 has only 3 Physical EPs. I am able to make changes in firmware side to put a function for lets say EP5 same as they have defined for EP1, and my host application can also logically establish connection with this EP5 through pipe, but as there is no physical EP 5 , so no data is returned from device, which is not the case if it is done with EP1,2 or 3 because there exists a register for each EP to control it.So how to approach now to let these 6 different functions( 6 different EPs...thats the problem) work using 3 EPs. I am using USBmem example.
Still no answer why you need 6 separate channels using end points, and why you can't multiplex data?
After all, you can create a device that has 128 telephony channels - 128*64kbit is only 8Mbit. But you can't expect 128 end points to handle each individual phone line.
Why is it important that a poll of channel 6 do not also retrieve any pending data from channel 5 or 4?
Because my requirement says that data will be put only on EP 85 but processor does not support EP 5 . Also, i am able to make logical connection i.e pipe between host and EP5 in firmware and somehow or through multiplexing i need to use these available EPs(81,82,83) to work as EP85. Elaborate on multiplexing with respect to this as i am unclear. and correct me if my logic of this endpoint problem is not correct.
Thanks
> Because my requirement says that data will be put only on EP 85
The requirement is unreasonable. Maybe, it was made by those who don't know USB well. As a specialist of MCU, you have to point it out. And change the requirement. Teach them about above good coding practice on PC side.
A multiplexed solution would ask on an end point: "any data".
And the MCU would check if it has data on ADC0 or ADC1 or ADC2 or ADC3. If any data is available, it would send back not only one or more measurements but also one or more bytes informing which channel the measurements was taken from.
So the result may be: C0: 0 samples C1: 0 samples C2: 2 samples (13.7, 15.2) C3: 1 sample (199.1)
The PC application then gets this data and demultiplex it. Nothing on 0. Nothing on 1. 13.7 and 15.2 on channel 2. 199.1 on channel 3.
It's only when a read would also perform some form of auto-acknowledge in your device that the multiplexing gets problematic - maybe you did not want to read out and acknowledge channel3. Multiplexing in a single endpoint will not allow you to leave the C3 sample in the device. This means that the PC must be able to consume data from all multiplexed channels since it can't just freeze a single channel for a while unless you send data in the other direction to your MCU to inform it that you want to pause C3 retrieval.
I feel sure with the statement you made. Thanks for your support.
I get that now . Will be back to you for that kind of problem.
Show this "absolute" feature of the MCU USB engine to the client. And discuss on a new requirement, which fits to this MCU.
The USB device engine on LPC3131 provides three OUT and three IN endpoints, other than the default one. - These endpoints work at the same time, independently each other. - The endpoint addresses are fixed - OUT: 0x01, 0x02, 0x03, IN: 0x81, 0x82, 0x83 - The available transfer type for each endpoint is defined in the Table 80, "1.5 Fixed endpoint configuration" section on the datasheet.