How to use both USB ports on lpc18xx or lpc43xx

[lpcware]

Content originally posted in LPCWare by ccrome on Fri Apr 27 07:28:55 MST 2012
Hello,
   I would like to use both USB ports on the LPC18xx or LPC43xx devices.  However, I see that a current limitation of the library is, "Can drive only one host or device controller at a time".

I need to use both USB controllers as DEVICE (connect to 2 different hosts). 

1) Is it possible?  What kind of patches will be reuired?

2) If not possible with nxpUSBlib, are there any other solutions that would make it reasonably do-able?

Thanks,
  -Caleb

[lpcware]

Content originally posted in LPCWare by chris.bayley on Tue Apr 21 15:11:50 MST 2015
Critical to my success in this pursuit was observing the requirement that usb_param.mem_base must be 2k aligned for each interface.

[lpcware]

Content originally posted in LPCWare by inspire on Thu Apr 16 11:54:46 MST 2015
Hi,

the simultaneous USB0/USB1 usage is also needed for my application. Using both USB controllers as decives (HIDs) is sufficient. But there is no dual operation example so you have to develop it on your own. In fact, this isn't difficult since you just have to initialize everything for both USB interfaces and do it like this:
- duplicate everything (initialization, ISR etc. Except descriptors if the same configuration on both interfaces is necessary.)
- add an offset for the usb_param.mem_base of one interface so they don't overlap

With this approach I had success.
inspire

[lpcware]

Content originally posted in LPCWare by claus on Fri May 24 05:14:50 MST 2013

I'm currently trying to do some dual USB hosting on the MCB1800 Board.

Unfortunately, it seems that the MULTI_PORT functionnality has disappeared when the integration of the nxpusblib into the LPCopen platform. What is the rationale behind it ?

Will it be reintegrated in the future ? It is not fundamental in my use case, but it can ease a lot of things for me.

[lpcware]

Content originally posted in LPCWare by nxpUSBlib team on Mon Nov 12 11:40:00 MST 2012
Dual controller support:
The latest version of nxpUSBlib (v0.98) includes support for simultaneous dual host operation. What that means is that you now pass in an index in to all the host APIs to specify which host you want to control.
This new feature is enabled by defining USB_MULTI_PORTS. Unfortunately this new feature is experimental, which in this case means there is no working example, and it was not significantly tested or documented.

Dual role support:
The version also includes a new example that shows dual-role capability which means both the host and device stacks are compiled into the same image. This new example (Example_KeyboardHostDevice) was designed to run on one of our parts that has only one controller. It switches between the host and device mode via an external event. This new support is also experimental, but at least there is a working example to show you how it is done.

Selectable controller support:
By defining USB_PORT you can specify which controller the stack operates on, whether in host or device mode. This constant has been in the last few releases, tested and confirmed to be working.

So with a combination of these three capabilities in the current release it may be possible for you to modify the code to support your requirement of simultaneous host mode operation on one controller and device mode operation on the other controller. But it probably won't be a walk in the park!

[lpcware]

Content originally posted in LPCWare by rocketdawg on Tue Oct 23 08:12:26 MST 2012
Yes.  Although it was just an investigative effort.  The build is quite different for both and that is where most of the effort went.  I did get it working.
I just created thread that periodically called the two nxpUSB functions as shown in the examples.
Not all is well.  The doc says these functions must be called periodically and suggest some frequency of not less than 30ms.  I choose 10ms at first.  Fail!
However, the example code samples call these functions in a while(1) loop, which is why the samples work.
During USB enumeration, these functions must be called with a period of less than 1ms.
Then the period is really a function of how the device enumerates, described by the host polling frequency in the enumeration descriptors.

I'm sure there is a better way to handle this.  A semaphore in the USB ISR could inform the thread to unblock, but I am wary of tampering with the ISR for performance reasons.
I was thinking of generating a software interrupt (or an unused peripheral ISR) from the USB ISR.  Simple as setting a bit in some register.
This lower (one less than the USB and hopefully it will tail-chain) priority software ISR would then suffer the overhead of the FreeRTOS context switch and simply toggle the semaphore.
the thread would wake upon the semaphore or every 10ms anyway since that is my enumerated polling frequency.
There are callbacks as well.  Need to look at those for unexpected USB reset, ESD recovery, ...
I want a solution that will run on both cores M4/M0 of LPC43XX and waking a thread every 1ms is really stupid.

FreeRTOS is ok, but I cannot use a Heap.  And generally the heap is only used at startup to allocate per thread stacks and kernel resources that should/could be allocated at compile time, not runtime.
ARM has open sourced it's RTX RTOS http://www.keil.com/pr/article/1253.htm

make sure you understand this.
http://www.freertos.org/RTOS-Cortex-M3-M4.html

[lpcware]

Content originally posted in LPCWare by John Hills on Mon Oct 15 05:07:25 MST 2012
Is there any update on when multiple controllers will be supported?

We are using LPC18xx and need Host on one controller and Device on the other. The Host interface will be used to access a USB memory stick (to load/save configuration files etc). The Device interface will be used for file transfer, a CDC channel and also DFU.

We are using FreeRTOS and plan to use FatFS. I have found the FatFS example in nxpUSBLib/Project_Kiosk. Has anyone an example project using nxpUSBLib with FreeRTOS?

[lpcware]

Content originally posted in LPCWare by ccrome on Tue May 01 11:05:38 MST 2012
Oh!  That's clever.  I forgot that I actually had 2 cores there!  That should be 'easy' right?  All the sudden, this seems a lot more do-able :-) 

We looked good and hard at the M4, and it's enough to do a pretty limited version of our software.  Boy, it would be great to use though.  When we only need a few channels of processing, it might be enough, and that would be a super inexpensive option.  I will keep that in mind for sure.  But the full-blown algorithms will be taking lots and lots of DSP type MIPS, so we need more like a cortex-A8 or better.

Thanks, now I'm a little less discouraged :-)  I was even contemplating 2 separate USB micros, and I forgot that's already what I had.


-Caleb

[lpcware]

Content originally posted in LPCWare by nxpUSBlib team on Tue May 01 10:13:59 MST 2012
Writing a bare-hardware interface would probably be a lot of work. Perhaps the easiest way to do this would be to run one copy of nxpUSBlib on each core. That would eliminate any duplicate reference issues.

So the M4 core running at 205mHZ and with (single precision) DSP extensions is not going to be powerful enough for you? Too bad. We had designed the LPC43xx with the idea that the M0 core would handle all the interfaces while the M4 was free to crunch the numbers.

[lpcware]

Content originally posted in LPCWare by ccrome on Tue May 01 09:55:09 MST 2012
hi there,
   Thanks for the information. Basically, we're building a gadget that needs to appear to a PC as a USB Audio device.  So, that's 1 full speed USB port accounted for :-)   On the other hand we need to connect to many audio codecs (say, 16 channels, both directions).  For that we'll use a serial port, say the SSP probably, and put the codecs into TDM mode (the codecs can run 256 bits/frame, so we can fit 16 channels on one wire).  Then internal to our box, we need to do a ton of processing, for which we'll use ... something else.  Probably a cortex A8, A9, A15, DSP, whatever comes with the best price/performance fit for the particular application (beagleboard, beaglebone, pandaboard, whatever)

Why don't we:
   a) connect the codecs directly to the signal processor?
   b) use the host processor in device mode?

a:  Turns out that it's really a major hassle -- each processor requires custom kernel drivers to drive the codec board (and depends on OS, and even OS version), so when we switch from one processor to another (or even one linux rev to another) it would require custom kernel development.  Additionally, not all SOCs/SOC boards have serial ports exposed that can handle the audio TDM.  So, at best, it's hard to switch to a signal processing platform, at worst its impossible.

b: Not all SOCs do USB device very well.  some are broken as high speed device in one way or another, and Linux support as an audio devices doesn't work the way I need it to (it's half duplex, etc...)

So, it seems like the best compromise is to have an intermediary microcontroller -- LPC18xx or LPC43xx -- act as a proxy between the codecs<->DSP  and between DSP<->HOST.  Pretty much all SOCs/processors/borads that we might use as a DSP platform can do USB host just fine, and if I write a libusb host application, then it's portable to linux/mac/windows with virtually no software changes at all.  The cost, of course, is that we'll need an extra microcontroller, but that's not too terrible for us in the grand scheme of things.  It's really about software development cycle/cost as we move forward to new processing platforms.  I think this scheme can keep latency down to an acceptable level (say, a few milliseconds), so I don't really see the down side.

So, the connection to the PC will be USB Audio Class.  But, the connection to the other processor can be custom, and needs to be high speed.  I plan to use a high speed, interrupt endpoint so I can reserve bandwidth and latency.  We can't use isochronous because we must get every sample.  Don't want to use bulk because I want as low latency as we can get.  So, HS interrupt is the only thing left :-)  FS interrupt can't carry very much data, but HS interrupt can (as per the USB 2.0 spec).

We don't need a multi-threaded environment I don't think.  We're basically just shuttling data from SSP<->HS-USB and from HS-USB<->USB-AUDIO, in a pretty much lock-step fashion.  There will need to be some synchronization and buffering, but I don't think that'll be tragic.   BTW, we can suffer the normal USB audio hiccups on the FS host USB audio device class interface -- that's no problem.  But we can not suffer even a single sample drop on the high speed interface, we need perfect synchrony between the codecs and DSP processor.

Do you think I could use the nxpUSBlib for the audio class device, and just write a bare-hardware interface to the other USB port for the HS interrupt connection?  Or, what if I create 2 complete copies of the libusb stuff, and prefix one with a prefix, so there are no function/variable clashes?  Would that work?

I'm a newbie both to LPC development, and to USB development, so any help would be most appreciated :-)

Thanks,
-Caleb

[lpcware]

Content originally posted in LPCWare by nxpUSBlib team on Fri Apr 27 10:35:55 MST 2012
Adding support to for multiple controllers is in the plan but not expected for a couple of months. The library above the LPC layer does not have native support for this but the code below the LPC layer does. For an example of this look at the code in HCD.h.

So if a couple of months (perhaps longer) is too long of a wait and you decide to do this yourself, there are two ways to implement this support. Either add it to the layer above LPC which would require changing just about every function in the stacks, or implement a state switching mechanism which would require adding in some synchronization if you are planning on running the stack in a multi-threaded environment.

Both methods are going to be a chore although the latter would probably be quicker.

We are curious about how customers want to use the dual controllers on this part. Would you be interested in telling us a little about your application?