Ya (or Mu suggestions)

Bas Wijnen wijnen at debian.org
Mon Aug 10 17:32:01 EDT 2009

On Mon, Aug 10, 2009 at 09:45:38PM +0800, Adam Wang wrote:
>> In the Neo FreeRunner, we used the (one) mini-B connector we had to do
>> both client and host (switching in software), and we had quite a few
>> issues with it.
>> On the Ben NanoNote, we are also low on free GPIOs.
> When I was digging into design of host and client, the more seeing the
> more getting.  So far depending on switching in software, it's
> meaningful after  completely understood physical operation(including
> h/w & f/w, HNP, SRP). So I may keep  surveying if someone already
> totally realized the following article described and share to me, that
> will be  good or chance to combine into one connector.
> http://www.maxim-ic.com/appnotes.cfm?appnote_number=1822&CMP=WP-3

I did not realize before that HNP and SRP existed.  I see no problem
implementing full OTG functionality if:
- both host and device pins can be connected to the bus.  This should be
  no problem.
- pull-ups and pull-downs can be switched on and off as required.  This
  is easy if they are in the CPU.  I suppose they are when the pins are
  set up as USB host/device pins, but don't know for sure.
- the described SRP problem can be implemented: "It does this by
  delivering measured amounts of current to the VBUS wire and noting the
  resulting voltage."  This is a hard one, I think.
- any bus logic can be switched off (the parts in the jz47xx can be set
  to gpio without pull, but if external parts are needed they need to be
  disconnectable as well).
- HNP can be sent.  The article doesn't describe how it is sent, and so
  it is unclear if this needs support from the CPU.

If we only use the host function, we may not need SRP support (and thus
"solve" the hardest problem.  If the cable is plugged with the NanoNote
as B device, it has a session and can use HNP to become host.  I'm not
sure if it needs SRP anyway to start communicating, that is possible
because the A device still provides the bus power even when it is not
the host.

> but somehow this article proposed more parts added. So it's not good for  
> current scenario we met.

I agree.

>> So I don't know, for me personally I would rather not try to hook two
>> controllers that are separate inside the CPU into 1 connector.
>> I would use a micro-AB connector, but in reality only use the micro-A
>> part of it (hook it up to the USB host controller inside the CPU).
>> Given the overall circumstances that seems to be the cleanest solution.
> So far it's a solution. Yes, use the micro-A part of micro-AB.

That seems the best solution so far, but there is a problem with it.
The micro-AB connector supports plugging a micro-B cable.  If a
micro-A/micro-B cable is plugged between the NanoNote and an OTG device,
everything is fine if it is plugged with micro-A in the NanoNote.
However, when it is plugged in with micro-B in the NanoNote, the OTG
device will take the host role, and things will not work (but if done
right, at least it shouldn't blow up any parts).  This means that the
user will need to reverse the cable in that case; something which is not
very nice, and which the OTG specification specifically solves (at the
cost of extra parts, unfortunately).

>>> It would be nice if the plug could also be used for charging, but I
>>> suppose that is a lot harder, because it needs to be a power supplier
>>> when in host mode.
>> Removing the mini-B would mean that you could not charge the device
>> on the mini-B, and connect powered devices to the micro-AB at the same
>> time. That would be a nice usage case if we had mini-B plus micro-AB, IMO.

Yes, that is a serious limitation.

> the jz47xx series unless it has OTG supported to CPU, for now we'll
> use  both connectors.

Sounds reasonable, but it still leaves the question of what is the best
connector for the host function.  Micro-A seems good, but then it would
really be better if it would also allow it to be used as a device port.
So the options are:
- Micro-AB for host or unused and mini-B for device and/or power.
- Micro-AB for device and optionally power and mini-B for power or

>> But anyway, using the ID pin to distinguish between client & host is
>> definitely an interesting idea, maybe Adam has some more comments
>> from the electrical side...
> :-) I have no further comments.Sorry, but I may update to list once I 
> realize the above article linked.

If you have any specific question about the article, please ask.  I
found it interesting to learn more about OTG from it.  I think on a
jz4730 or jz4740, it shouldn't need extra parts to implement it
(as I wrote above, and with the assumptions I made there).


I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20090810/a6bd1adb/attachment.pgp>

More information about the discussion mailing list