Skip to main content ↑ ↓
Topic: v4 support for USB-OTG (Read 5017 times) previous topic - next topic

v4 support for USB-OTG

The Bus Pirate v4 hardware topic is getting quite long, at 7 pages so far, so I think the following suggestion deserves it's own topic for full attention.

[quote author="honken"]
I just had a thought.
The usb connector on the board actually has a footprint of mini-A/B.
Couldn't we then route the ID pin of the connector to the unused RP16/USBID pin of the PIC?
All other facilities i.e Vbus sensor/detector is already in place except for supply.
The supply could be taken care of by a "hacked" usb-otg cable.
Then there would be a future possibility of USB-OTG.
That could be used for rrreeeaaallllllyyy long BASIC scripts via external hard drive :-)
Or connect a hub, keyboard and the usb lcd backpack developed in another thread and then we have a handheld field testing device.
Firmware wanting of course.

But I would think it'll make the v4 hardware even more future proof.
[/quote]

Re: v4 support for USB-OTG

Reply #1 –
[quote author="honken"]The usb connector on the board actually has a footprint of mini-A/B.
Couldn't we then route the ID pin of the connector to the unused RP16/USBID pin of the PIC?[/quote]I would buy the Bus Pirate v4 just for such an OTG feature, because that would make it a cheaper PIC OTG evaluation board than anything Microchip offers.  Anyone interested in getting started with OTG programming but who doesn't want to design the initial hardware could use the BPv4 as a platform for early firmware development and testing.

Quote
All other facilities i.e Vbus sensor/detector is already in place except for supply.
The supply could be taken care of by a "hacked" usb-otg cable.
I think it might be better to add a header pin to the BPv4 board so that external power can be applied directly, and then the OTG function could operate without a hacked cable.  OTG only needs to provide 100 mA, so it shouldn't be much of an issue.  This might be more complicated than I think, though.

Quote
Then there would be a future possibility of USB-OTG.
That could be used for rrreeeaaallllllyyy long BASIC scripts via external hard drive :-)
Or connect a hub, keyboard and the usb lcd backpack developed in another thread and then we have a handheld field testing device.
Firmware wanting of course.
Yes, the PIC OTG host will only support the protocols that you program into the firmware.  There is no automatic hosting for OTG just because the hardware is there.  But having a cheap platform like the BPv4 would make it easier for the open community to start writing this sort of firmware.

Quote
But I would think it'll make the v4 hardware even more future proof.
At the very least, the unused pin should be connected so that brave firmware developers can get started.  In other words, I think you have a great idea thought here, and a worthwhile suggestion.

Re: v4 support for USB-OTG

Reply #2 –
I totally agree! I have a couple of boards in hand which support USB OTG (PIC24F series and a PIC32 series) but I didn't mess with USB as it is kind of harder than UART+BP configuration. :) If it supports that I would totally buy the new BP (if not, I would also buy v4 but not that quickly :P) and push myself for contribuing with USB peripheral and host modes.

Re: v4 support for USB-OTG

Reply #3 –
Sure, I'm going to try to get the new boards out this week. So:

*route the ID pin of the connector to the unused RP16/USBID
*external power header.
Got a question? Please ask in the forum for the fastest answers.

Re: v4 support for USB-OTG

Reply #4 –
[quote author="ian"]
Sure, I'm going to try to get the new boards out this week. So:

*route the ID pin of the connector to the unused RP16/USBID
*external power header.
[/quote]Good stuff, but on that second item we might have some work.  Check the Microchip Data Sheet for the specific PIC24 that's on the BPv4, in the section on OTG, and also Section 27 USB OTG from the PIC24 Family Reference Manual that Microchip points to.  Both mention restrictions on current, and requirements for switching.

In other words, you might need some diodes, or more likely a switchable power supply.  One of their example circuits lists a part that can only provide 120 mA, but after reading the fine print on OTG, I see that an OTG host can provide up to 500 mA for a USB device if all the usual rules about 500 mA are honored.  It's not immediately obvious to me whether a simple external power header will meet all the requirements, but perhaps.  Maybe a simple power FET would be enough to act as a cheap switch that the PIC could control.  Or, perhaps it would be up to the user to attach the external power only under the right conditions.  Anyway, this little "feature" might require some thought.

Re: v4 support for USB-OTG

Reply #5 –
Is that really necessary? Sure, if we would like to fulfill the requirements of USB-OTG certification, but if we just want to use the OTG-function we must supply power to both the BusPirate and possibly the device connected to it (no supply required if the other device is another OTG).

My idea was to use an OTG-cable with "power injector", and that injected power would supply both BusPirate and other devices.
Both devices would receive power through their respective USB-connector.

But this solution may not be satisfactory, we should check the specifications on which device should supply what voltage, power under what circumstances.

But to be able to make the BusPirate boards there could be two through-holes in the path of VUSB. If some special supply circuitry is needed, connection between those holes could be severed and the circuitry installed in place, perhaps as a daughter-board add-on. Or a single pin in one of them and supplying everything with an external 5V al'a my idea with injector-cable.

Re: v4 support for USB-OTG

Reply #6 –
I've perused the OTG USB section before and recall they recommend a chip for current limiting. It's probably not feasible to add any hardware to support USB-OTG. It's not a feature I plan to support in the firmware. If it makes it more hacker friendly though, I'm willing to add headers/traces as needed. If you were just prototyping something you could power it from your lab supply, for example. If someone does something cool with it, then a future version could add full OTG support if that's useful.
Got a question? Please ask in the forum for the fastest answers.

Re: v4 support for USB-OTG

Reply #7 –
I'm mostly trying to make sure that the circuit meets the minimums, without actively causing any damage.  I certainly do not think that the maximum support should be designed.

For one thing, current limiting seems like an optional feature, not a requirement.

My concern is that OTG has to work as both a host and a device, without breaking the rules of either.  It particularly has to work as a device since the main purpose of the BP is as a USB device.  There are some particular rules requiring that a USB device not supply current on the USB bus power (and also that no power should be sourced on the data lines when USB bus power is absent, but that's not an issue here).  Maybe the solution is as simple as saying to the user: Don't forget to disconnect the external power when using the Bus Pirate firmware - i.e. only use external power when experimenting with OTG.  That might alleviate the need for the switchable power supply.

As for OTG as a host, I think that it's up to the connected USB device to not draw more than 100 mA or 500 mA, depending upon the state.  I don't think that the host is necessarily required to cap the current, although that might retain the magic smoke a little longer.

I really only bring this up so that it is carefully considered.  There are enough ways to design a USB device incorrectly.  Even though OTG seems simple, there might be a few violations of the spec which should be avoided.