topic Re: LPC11U35 and custom class in LPC Microcontrollers

LPC11U35 and custom class

lpcware — Wed, 15 Jun 2016 16:48:22 GMT

Content originally posted in LPCWare by fjarnjak on Thu May 16 02:30:44 MST 2013

Hello,

I am evaluating LPC11U35 for a simple DAQ device where PC application would use libusb to communicate to it using a simple protocol.

I have looked at:

http://www.lpcware.com/content/forum/nxpusblib-windows-winusb-driver-custom-class

but I have additional questions:

I see that LPC11U35 has ROM Based drivers for common communication classes and also USB core stack (enumeration, etc).

Is there a way to use ROM based USB stack for making sure USB protocol is handled correctly, and then registering simple endpoint handlers in bulk mode for IN and OUT where I do my custom protocol implementation?

Something similar to nxpUSBLib v0.98b Device Bandwidth Test code, but I do not want the device to appear as mass storage device while enumerating.

I have been looking at the new LPCOpen library 1.03 and it seems Device Bandwidth Test example is gone. Is this a limitation or? Since nxpUSBLib is retired...

Also, if this above is not possible I may use LPC1769 which I use for other projects, so if anyone has some experience doing this...

Re: LPC11U35 and custom class

lpcware — Wed, 15 Jun 2016 16:48:23 GMT

Content originally posted in LPCWare by fjarnjak on Mon May 20 00:58:10 MST 2013

UPDATE:

I have ported device bandwidth test from nxpUSBLib to a new project.

PC USB test application from the device bandwidth test project correctly detects the device but only as "low speed" device, which is odd.

What needs to be changed?

Re: LPC11U35 and custom class

lpcware — Wed, 15 Jun 2016 16:48:24 GMT

Content originally posted in LPCWare by durgesh on Fri Jun 21 11:21:23 MST 2013

Did you check the traffic on bus? Is it really low-speed ?

This could be a bug in bandwidth test code (PC side). It assumes the speed based on the value returned by <strong>WinUsb_QueryDeviceInformation() </strong>routine. The code outputs the speed based on return value as below

0x3 - high speed, 0x2 - full speed, 0x1 - low speed.

Looks like MSFT update the document http://msdn.microsoft.com/en-us/library/windows/hardware/ff540290(v=vs.85).aspx saying "0x03 indicates high-speed or higher; 0x01 indicates full-speed or lower."

So PC tool should be updated with the change in WinUSB interface.