«

Paul wrote:
> On Mar 6, 9:24 am, Andrew Smallshaw <andr...@sdf.lonestar.org> wrote:
>> On 2008-03-06, Paul <Quiller...@gmail.com> wrote:
<snip>
> Again, more B. S.! The Type A and B connectors perform
> the same function, then are just different physically!
>
> Maybe your name is really Andrew Smallbrain.....

Well, I think that about wraps things up for this thread. Clearly, you
know far more about USB than any of the experienced engineers in these
groups. There is no point in people giving help and advice if that's
all the thanks they get.

On 2008-03-06, Paul <> wrote:
> On Mar 6, 9:24*am, Andrew Smallshaw <andr...@sdf.lonestar.org> wrote:
>>
>> Which connector your device needs depends on what it is doing. *If
>> it is to be plugged into a computer and work as a peripheral it
>> needs a 'B' socket. *If it is to replace a computer and control a
>> devices, whether it be a printer, flash drive, keyboard or whatever,
>> it needs an 'A' socket.
>
> Again, more B. S.! The Type A and B connectors perform
> the same function, then are just different physically!

If you already know all the answers why did you bother to post in
the first instance? It appears to me that you are unwilling to
make what should be a simple decision, i.e. should my device be a
USB host or peripheral? This does not take much reasoning, it
either is or should be a simple instinctive judgement based on what
the device does.

Don't think that going for On The Go as you have mentioned in
another subthread simplifies things by avoiding the need to make
a simple decision. It doubles complexity since your device is now
both and you still have to determine which mode it should be in at
any particular time. On The Go is only appropriate for a fairly
narrow class of devices.

Yes, as you mentioned in your first reply to my post, it is only
four wires. That does not make things simpler but more complex.
It means that you don't have separate wires on which to send and
recive data. You don't have a wire that says that your particular
device is the one currently being addressed. You don't have an
interrupt request line so that your device can request the computer's
attention. These are all handled by the USB _protocol_ which is
much more complex to deal with than a 100 signal bus where everything
has its own line. The hardware side of USB is one thing, but that
is nothing without the _software_ that makes the whole thing work
and where the real complexity is.

My initial post pointed out that USB is not straightforward and
politely pointed out that if you are lacking knowledge of the
fundamentals then any project you attempt is unlikely to be
successful, at least not without a thorough grounding in the basics
first. I see that you have also apparently chosen to ignore
reference to the standard and other documents that others have
referred you to. This also does not bode well. Finally you hurl
abuse at people who attempt to assist you simply becasue that
assistance is not to your liking. This does not encourage others
to help in future and further diminishes the probability of your
success.

Ultimately though, it does not affect me. I can and have developed
USB peripherals, and vitriol such as yours will not alter that.
You are still incapable of doing so. An attitude such as you have
already displayed will ensure that you do not alter that either.

--
Andrew Smallshaw

On Mar 7, 1:50*pm, Andrew Smallshaw <andr...@sdf.lonestar.org> wrote:
> On 2008-03-06, Paul <Quiller...@gmail.com> wrote:
>
> > On Mar 6, 9:24*am, Andrew Smallshaw <andr...@sdf.lonestar.org> wrote:
>
> >> Which connector your device needs depends on what it is doing. *If
> >> it is to be plugged into a computer and work as a peripheral it
> >> needs a 'B' socket. *If it is to replace a computer and control a
> >> devices, whether it be a printer, flash drive, keyboard or whatever,
> >> it needs an 'A' socket.
>
> > * * * Again, more B. S.! * *The Type A and B connectors perform
> > the same function, then are just different physically!
>
> If you already know all the answers why did you bother to post in
> the first instance? *It appears to me that you are unwilling to
> make what should be a simple decision, i.e. should my device be a
> USB host or peripheral? *This does not take much reasoning, it
> either is or should be a simple instinctive judgement based on what
> the device does.
>

If it's clear that I'm absolutely a newbie to USB,
why keep telling me how ignorant i am? Oh, to boost your
sagging self-image at work?

The devices are gonna be Hosts. As in, they should control
peripheral
devices like a mouse, keyboard, printer, memory stick. etc....

However, it would be nice to be able to transfer data from
one Host to another, which appears to be impossible (no one
connects one computer to another to transfer data). So maybe the
OTG would be the correct choice, also because of the 480Mbps data
rate.


> Don't think that going for On The Go as you have mentioned in
> another subthread simplifies things by avoiding the need to make
> a simple decision. *It doubles complexity since your device is now
> both and you still have to determine which mode it should be in at
> any particular time. *On The Go is only appropriate for a fairly
> narrow class of devices.
>
> Yes, as you mentioned in your first reply to my post, it is only
> four wires. *That does not make things simpler but more complex.
> It means that you don't have separate wires on which to send and
> recive data. *You don't have a wire that says that your particular
> device is the one currently being addressed. *You don't have an
> interrupt request line so that your device can request the computer's
> attention. *These are all handled by the USB _protocol_ which is
> much more complex to deal with than a 100 signal bus where everything
> has its own line. *The hardware side of USB is one thing, but that
> is nothing without the _software_ that makes the whole thing work
> and where the real complexity is.
>

Dude! I only want to hook up the hardware! I'm not a
programmer at all!

Why are you making a simple question so difficult?


> My initial post pointed out that USB is not straightforward and
> politely pointed out that if you are lacking knowledge of the
> fundamentals then any project you attempt is unlikely to be
> successful, at least not without a thorough grounding in the basics
> first. *I see that you have also apparently chosen to ignore
> reference to the standard and other documents that others have
> referred you to. *This also does not bode well. *Finally you hurl
> abuse at people who attempt to assist you simply becasue that
> assistance is not to your liking. *This does not encourage others
> to help in future and further diminishes the probability of your
> success.
>
> Ultimately though, it does not affect me. *I can and have developed
> USB peripherals, and vitriol such as yours will not alter that.
> You are still incapable of doing so. *An attitude such as you have
> already displayed will ensure that you do not alter that either.
>

If you think i'm gonna kiss your ass just to get
help, you are sorely mistaken, SmallBrain.

Try getting off your high-horse, and maybe people
will be more open and receptive to your advice.....

"Paul" <> wrote in message
news:3207bf57-739b-4d84-86ac-...
On Mar 7, 1:50 pm, Andrew Smallshaw <andr...@sdf.lonestar.org> wrote:
" However, it would be nice to be able to transfer data from
one Host to another, which appears to be impossible (no one
connects one computer to another to transfer data)."

They make "USB data transfer cables" for this very purpose; inside the cable
are two USB clients that share some SRAM or similar. You're correct that it's
impossible to transfer data between two USB hosts with "just a cable" --
unless both hosts support USB on-the-go, that is.

"Dude! I only want to hook up the hardware! I'm not a
programmer at all!"

Good hardware designs take the software into consideration -- some of the best
hardware design I've done is when I did both the software AND the hardware,
because you'll think you've designed the hardware well, but as you're sitting
there doing the software you'll find some really annoying behavior due to that
hardware's design... but happily you've still got the "out" to go and fix it.

I wonder if anyone's collected anecdotes of hardware that -- from software's
point of view -- was poorly designing; it'd probably make for entertaining
reading!

On Mar 7, 5:46*pm, "Joel Koltner" <zapwireDASHgro...@yahoo.com> wrote:
> "Paul" <Quiller...@gmail.com> wrote in message
>
> news:3207bf57-739b-4d84-86ac-...
> On Mar 7, 1:50 pm, Andrew Smallshaw <andr...@sdf.lonestar.org> wrote:
> " * * * *However, it would be nice to be able to transfer data from
> one Host to another, which appears to be impossible (no one
> connects one computer to another to transfer data)."
>
> They make "USB data transfer cables" for this very purpose; inside the cable
> are two USB clients that share some SRAM or similar. *You're correct that it's
> impossible to transfer data between two USB hosts with "just a cable" -- *
> unless both hosts support USB on-the-go, that is.
>

So maybe one day, all computers will have OTG USB, so
that we won't need memory sticks to transfer huge datafiles from
harddrive to harddrive.


> "Dude! *I only want to hook up the hardware! *I'm not a
> programmer at all!"
>
> Good hardware designs take the software into consideration -- some of the best
> hardware design I've done is when I did both the software AND the hardware,
> because you'll think you've designed the hardware well, but as you're sitting
> there doing the software you'll find some really annoying behavior due to that
> hardware's design... but happily you've still got the "out" to go and fix it.
>
> I wonder if anyone's collected anecdotes of hardware that -- from software's
> point of view -- was poorly designing; it'd probably make for entertaining
> reading!

Of course, you have a major point. But if i'm just gonna
have a host port, it's really only D+, D-, and +5V and Ground.

OTG USB looks a bit more complicated. See Figure 5 here:

http://www.maxim-ic.com/appnotes.cfm...e_number/1822/


OTG requires switchable pull-up and pull-down resistors, a
switchable
+5V power supply, and an ID pin. This looks way more complicated,
and
will take up a lot of real estate.

I'm leaning towards a simple Host USB port, using one of
these:

http://www.alliedelec.com/Images/Pro...CS/3741829.pdf


I don't think we will need to move data from unit to unit.
Just support
for memory sticks, keyboards, mouse, and maybe printers.

Thanks, Joel.

Joel Koltner wrote:
>
.... snip ...
>
> Good hardware designs take the software into consideration --
> some of the best hardware design I've done is when I did both
> the software AND the hardware, because you'll think you've
> designed the hardware well, but as you're sitting there doing
> the software you'll find some really annoying behavior due to
> that hardware's design... but happily you've still got the
> "out" to go and fix it.
>
> I wonder if anyone's collected anecdotes of hardware that --
> from software's point of view -- was poorly designing; it'd
> probably make for entertaining reading!

The reverse also applies. Quite a few years ago I had to interface
a pre-existing LAN system to my brand new embedded systems. I
designed a comprehensive interface, stage by stage, with removable
internal test drivers. We built the first one, and it worked
fine. Then we tried to build a second one, and lay artwork. Woops
- things were too complex. Without the stage by stage assembly we
just couldn't untangle the faults in finite time. So I redesigned
completely, needing much more supervision from the CPU, and wrote
the appropriate software. Everything worked, and we could build
quite a few of them without any difficulties. The (interrupt
driven) software load was trivial.

The critical thing is to have both the software and hardware under
your control. Then you can select an optimum, or nearly so, set of
trade-offs. It helps to be good in both fields.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

On Mar 5, 10:20 pm, Paul <nos...@needed.com> wrote:
> Paul wrote:
> > Hi,
>

>
> Unzip the following package. It contains the USB 2.0 standard.
> Open usb_20.pdf and flip to the first page of Chapter 6. There,
> you'll see examples of upstream and downstream connectors.
> Your very own computer, uses the flat connector, so you can
> see an example in the I/O area on the back of your computer.
>
> http://www.usb.org/developers/docs/usb_20_092407.zip
>
> If you want to be a USB designer, then reading these may
> help as well.
>
> http://www.usb.org/developers/docs/h...y_motherboards...
>
> Paul


Thanks for posting these. I trimmed alt.computer. I have read until
saturation this weekend, so now I am full of more questions.

I have a PIC32 Starter Kit. I've exercised the LEDs and pushbuttons
and want to move on. Any day now the postman should bring my PIC32
fanout board from Olimex.

My proposal is a USB 2.0 host controller expansion board. This should
give me access to keyboard, later WiFi, and thence everything. Also,
the PIC32 is new and this particular expansion board should be
received well by the PIC32 community. Perhaps it will also have an
upstream facing port with a PIC18F4550. This is a daunting project,
but it seems like the one that is needed.

AfterGoogle, I went to Mouser and focused on the Host controllers that
they had in stock. I have done a mock up schematic and board in
EAGLE using the NEC uPD720102EC-YEB. This is a straightforward
reproduction of the schematics from the NEC datasheet, S17998E. By
mock up I mean that I have placed "capacitors," and such, but without
referring to a catalog and specific mfr and dimension information.
That will be a subsequent "design for prototype" pass. At this time,
I have not connected the programming ports and the PIC32. The many
VDD levels, both on the PIC and the NEC are not managed. It is little
more than a napkin doodle.

I read Paul's post and read once through the power delivery
whitepaper. I've added 470pF across pins 1,4 on each USB receptacle.
I added a 360uF across the +USB and gnd traces near the downstream
facing ports.

What I don't see in reference schematics is any attention to fuses. I
figure the same concerns on fuses and overcurrent exist in both Host
and Hub designs, and I am looking at the ATmel AT43301 datasheet,
doc1137.pdf (secured, no NDA). Figure 2.2 (Self-powered Hub) shows
a switch connected to the AT43301, but no fuse. They do have a
MIC2525-2 in their figure 5-2. Does the MIC2525-2 have the right
stuff to be used instead of a fuse?

The white paper mentions the polycrystalline resistor/fuse. I know
that Mouser had them a few years ago. I remember thinking they were
interesting. Are these used in designs today?

If you happen to have EAGLE, you can view a snapshot at
http://home.grandecom.net/~aubrey/au...C/USB_host.brd Sorry, but
I haven't installed a pdf printer, and my board house doesn't require
Gerbers. Perhaps someone else has both EAGLE and Acrobat.

I'd like to do this right. By that, I mean a design that is
satisfying and could receive the logo. I assume the process is to
make a working prototype, then job it out for "design for
manufacture" I assume that the logo goes on a specific model and
revision of a design. I was hoping to make a design element that was
known to qualify and then just put it on the web.

Questions follow from this. I assume the cost is at least k$10 to do
this before the enclosure is considered. Can anyone give an actual
total cost (electrical and mechanical separated) for a 1st unit with a
logo for, say, an ordinary 4 port hub?

If this is an expansion board and the power is from the mother board,
what is the implication on the certification process (I haven't done
my reading here) If it is an intelligent hub with the power from an
upstream port, a PIC32 (MIPS processor) in the middle, the Host facing
downstream, the PIC32 powered from the upstream USB but detachable,
can the total assembly receive certification?

Actually, I don't see a USB logo on the PIC32 Starter Kit. Maybe this
is a non issue.