Ya (or Mu suggestions)

Wolfgang Spraul wolfgang at qi-hardware.com
Mon Aug 10 08:02:15 EDT 2009


Bas,

> Given the situation, it seems that it would be best to use micro-AB and
> add some logic to link it to either the host or the device port,
> depending on the ID pin.  I think that should be possible by connecting
> the ID pin to a pulled-up GPIO pin (with interrupt on change), and
> setting the device up according to that pin.  No extra logic would be
> needed AFAICS.

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.

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.

> 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.

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...
Wolfgang

On Mon, Aug 10, 2009 at 12:12:24PM +0200, Bas Wijnen wrote:
> Hi,
> 
> First of all, I didn't exactly know what "on the go" meant.  From your
> article, I understand that it is about devices that can be both host and
> device with just one connector.
> 
> On Sat, Aug 08, 2009 at 09:48:45PM +0800, Adam Wang wrote:
> > > According to wikipedia the recommendation to use micro-A as host-plug
> > > for small devices (actually for on-the-go devices) is supported by
> > > important parties, which means it will likely become a real standard.  I
> > > don't have enough experience (I haven't ever conciously seen a USB micro
> > > plug) with this type of devices to know if that claim is true, but I
> > > suppose others on the list do.
> > For those kinds of conditions we took considerations into like following 
> > thinking;
> > a) If CPU supports OTG, we should use Micro-AB receptacle.
> 
> Yes, obviously.
> 
> > b) If CPU doesn't support OTG, meant it may has 1 channel for USB device 
> > and the other one for
> >     USB host; we should choose carefully different connectors for both 
> > requirements.
> > 
> > Since your suggestions for Ya is really great to us, I posted an article 
> > [1] which depicted that
> > "How to design a circuit with usb host and device function". We'll still 
> > absorb all suggestions on
> > Ya's features and keep surveying.
> 
> Thank you for the article, it explained nicely to me what (and how) on
> the go works.
> 
> When using two connectors, I think mini-B is the best for the device
> function.  I agree with you that the host function must have a different
> connector.  It seems obvious to use micro-A for that, but according to
> wikipedia that doesn't exist (it would need micro-AB which isn't a good
> choice, IMO, because the micro-B connector fits in it).
> 
> Given the situation, it seems that it would be best to use micro-AB and
> add some logic to link it to either the host or the device port,
> depending on the ID pin.  I think that should be possible by connecting
> the ID pin to a pulled-up GPIO pin (with interrupt on change), and
> setting the device up according to that pin.  No extra logic would be
> needed AFAICS.
> 
> 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.
> 
> > I do hope you still can point out if I was wrong in this post. :-)
> 
> No, I didn't see anything that was wrong. ;-)
> 
> Thanks,
> Bas
> 
> -- 
> 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



> _______________________________________________
> Qi Developer Mailing List
> Mail to list (members only): developer at lists.qi-hardware.com
> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer




More information about the discussion mailing list


interactive