EmbeddedRelated.com
Forums

High speed USB 2.0 OTG component availability

Started by Brad S December 18, 2004
On 20 Dec 2004 15:23:14 -0800, "Brad S" <bjskill@rocketmail.com>
wrote:

>Steve, > >Due to budget constraints, we will not be developing an ASIC for this >project. If we cannot achieve our 40 MB/s goal, then what is a >resonable goal assuming that the external device (e.g. USB 2.0 HDD) is >not the bottleneck? > >Brad.
Hi Brad, Well without knowing what OS/driver, processor, memory speed, memory bus, high speed chipset etc. that is a very difficult question. If you are buying a Philips chip, they may have an estimate. Other issues about transfer rates are latency requirements and true throughput requirements. If you cannot do your app with an IDE (or SCSI) disk, then going to USB will not help. Much work is required to answer your questions. Please send any conclusions to this list, people are interested. ~Steve -----------== Posted via Newsfeed.Com - Uncensored Usenet News ==---------- http://www.newsfeed.com The #1 Newsgroup Service in the World! -----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Steve Calfee wrote:
> On 20 Dec 2004 15:23:14 -0800, "Brad S" <bjskill@rocketmail.com> > wrote: > > >Steve, > > > >Due to budget constraints, we will not be developing an ASIC for
this
> >project. If we cannot achieve our 40 MB/s goal, then what is a > >resonable goal assuming that the external device (e.g. USB 2.0 HDD)
is
> >not the bottleneck? > > > >Brad. > > Hi Brad, > > Well without knowing what OS/driver, processor, memory speed, memory > bus, high speed chipset etc. that is a very difficult question. If
you
> are buying a Philips chip, they may have an estimate. Other issues > about transfer rates are latency requirements and true throughput > requirements. If you cannot do your app with an IDE (or SCSI) disk, > then going to USB will not help. Much work is required to answer your > questions. > > Please send any conclusions to this list, people are interested. > > ~Steve > > > -----------== Posted via Newsfeed.Com - Uncensored Usenet News
==----------
> http://www.newsfeed.com The #1 Newsgroup Service in the
World!
> -----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19
Servers =-----
Hi Steve,

We are in the early stages of a study/design phase for this project.
The results of this phase will then help determine what HW/SW
components (OS/driver, processor, memory speed/bus, HS USB 2.0 chipset)
could be utilized.  Part of the study phase will focus on determining
the practicality of implementing a HS USB 2.0 Host port and given a
pre-determined selection of some of these components, what realistic
maximum transfer data rate could be attained.

If it is determined that a realistic sustained HS USB 2.0 transfer rate
is well below 40 MB/s (e.g. 10 MB/s), then this information will be
presented to the customer together with a Pro and Con list (additional
risk, component availability, ease of data transfer, etc.) in order to
make an informed decision.  If the need for high speed, real-time data
transfer is no longer a requirement, then a transfer rate of 10 MB/s
may be more than adequate.

I realize that I mentioned in an earlier post that we required a high
speed USB 2.0 host port.  However, my crystal ball is just as cloudy as
everyone elses and, given the limited number of choices for
implementing a HS USB 2.0 host port in the near term (< 6 months),
going with a full speed USB 2.0 host port that is capable of a
sustained transfer rate of >= 1 MB/s may be just fine.  We shall see...
Brad.

We have a few USB 2.0 high speed systems here.  All have USb device 
capability, some have USB host functions as well.  Our low-end device uses a 
PowerPC running VxWorks, the device is a Cypress C680001 ( a part I 
certainly can't reccomend).  Data rates are sustained in the 8-10 MB/s 
range.  Keep in mind the host processor is rather slow, the data path to the 
USB device controller isn't optimum either.

Our high-end product uses a NetChip (now Plexus) 2280 and is interfaced over 
the PCI bus.  This system is P4 based and runs XP.  Sustained data rates are 
on the order of 25 MB/s.

On our low-end system , a host has been addded that interfaces over PCI as 
well.  We chose the NEC uPD720101.  Data rates have yet to be determined, 
but I am expecting them to be in the order of 10-15 MB/s.  The high-end uses 
the ICH4 with data rates again in the 25MB/s area.

Hope this helps.

Regards,
Glen


In article <1103641073.66489@cswreg.cos.agilent.com>,
Glen Atkins <glen_atkins@nospamagilent.com> wrote:
>We have a few USB 2.0 high speed systems here. All have USb device >capability, some have USB host functions as well. Our low-end device uses a >PowerPC running VxWorks, the device is a Cypress C680001 ( a part I >certainly can't reccomend). Data rates are sustained in the 8-10 MB/s >range. Keep in mind the host processor is rather slow, the data path to the >USB device controller isn't optimum either.
[snip] Would you care to expand on your problems with the Cypress part? Do you have any other recommendations if someone wanted to develop a slave USB 2.0 system? (data to be shipped to a PC -- no other USB activity) -frank --
"Frank Miles" <fpm@u.washington.edu> wrote in message 
news:cq9oed$a0e$1@gnus01.u.washington.edu...
> In article <1103641073.66489@cswreg.cos.agilent.com>, > Glen Atkins <glen_atkins@nospamagilent.com> wrote: >>We have a few USB 2.0 high speed systems here. All have USb device >>capability, some have USB host functions as well. Our low-end device uses >>a >>PowerPC running VxWorks, the device is a Cypress C680001 ( a part I >>certainly can't reccomend). Data rates are sustained in the 8-10 MB/s >>range. Keep in mind the host processor is rather slow, the data path to >>the >>USB device controller isn't optimum either. > > [snip] > > Would you care to expand on your problems with the Cypress part? Do you > have > any other recommendations if someone wanted to develop a slave USB 2.0 > system? (data to be shipped to a PC -- no other USB activity) > > -frank > --
Support from Cypress was virtually non-existent. Emails would take days or a couple of weeks for a response, phone calls / voice mails suffered the same fate. The part was vapor at the time of our design, despite vendor promises that it was indeed a real device. Development now may not be as big an issue. To contrast that with our experience with NetChip (now Plexus - and I have no clue what their response would be like, though we have had good response to PCI and PCI-Express questions). Emails typically were answered within the day and followed up with a phone call from them the next day. Very responsive, very knowledgeable, very helpful. If I had it to do over again, I would have used a NetChip Net2270 or Net2272. Granted, it depends on what processor is in your system, etc. Regards, Glen
Over the past four years we have used two different USB slave
components from Cypress/Anchor Chips: AN2135 (USB 1.1) and CY7C68013 -
FX2 (USB 2.0).  During the development cycles we never even attempted
making phone calls and the e-mail technical support from Cypress was
hit or miss.  Sometimes they were able to quickly provide a response
that answered the question.  Other times it took several exhanges of
e-mail's to describe the problem in great detail before they would
answer the question.  This process was very frustrating and time
consuming.  On one ocassion, we answered our own question by performing
a series of tests that should have been unnecessary.

We did look into using the Net2270 from NetChip.  We even bought their
evaluation board.  It wasn't chosen because it would have required more
embedded software to support it than the FX2 did.  Our embedded host
processor was an Intel StrongARM running a Linux OS.  The slave FIFO
mode on the FX2 was perfect for our application.  Except for the one
major issue that we resolved ourselves, the FX2 worked fine for our
application.

Did you ever consider using an FX2 or similiar part instead of the SX2
for your application?  Or was the FX2 overkill since you didn't need a
USB slave device 8051-based core?  When we were in the research phase
of our design, the SX2 was not available for consideration.  I would be
curious to know what other problems you had when you had when using the
SX2.

Brad

Glen Atkins wrote:
> > Our high-end product uses a NetChip (now Plexus) 2280 and is
PLX, not Plexus. Rob
"RobJ" <rsefton@abc.net> wrote in message 
news:32u5h8F3pp03nU1@individual.net...
> Glen Atkins wrote: >> >> Our high-end product uses a NetChip (now Plexus) 2280 and is > > PLX, not Plexus. > > Rob
Yeah, that's right - must have been on Holiday time there. Thanks Rob.
"Brad S" <bjskill@rocketmail.com> wrote in message 
news:1103729566.217466.205000@f14g2000cwb.googlegroups.com...
> Over the past four years we have used two different USB slave > components from Cypress/Anchor Chips: AN2135 (USB 1.1) and CY7C68013 - > FX2 (USB 2.0). During the development cycles we never even attempted > making phone calls and the e-mail technical support from Cypress was > hit or miss. Sometimes they were able to quickly provide a response > that answered the question. Other times it took several exhanges of > e-mail's to describe the problem in great detail before they would > answer the question. This process was very frustrating and time > consuming. On one ocassion, we answered our own question by performing > a series of tests that should have been unnecessary. > > We did look into using the Net2270 from NetChip. We even bought their > evaluation board. It wasn't chosen because it would have required more > embedded software to support it than the FX2 did. Our embedded host > processor was an Intel StrongARM running a Linux OS. The slave FIFO > mode on the FX2 was perfect for our application. Except for the one > major issue that we resolved ourselves, the FX2 worked fine for our > application. > > Did you ever consider using an FX2 or similiar part instead of the SX2 > for your application? Or was the FX2 overkill since you didn't need a > USB slave device 8051-based core? When we were in the research phase > of our design, the SX2 was not available for consideration. I would be > curious to know what other problems you had when you had when using the > SX2. > > Brad
We looked at the FX2, for our device it was extreme overkill. Actually, the SX2 is an FX2 with teh ROM masked for that specific subset of functions that define an SX2. Again, had Cypress simply told us THAT - our lives would have been much easier. They also neglected to tell us that we were the 1st product to go to production with the SX2. That little bit of info would have been very enlightening as well. At best they are hit & miss with technical support. The SX2 (& FX2 I believe) have no means by themselves to sense an attach / detach. Most other devices have the ability to detect USB power. In the Cypress solution that has to be added manually. Of course the host will see the device, but the device will need to have external hardware to detect that event if necessary. Other issues - general immaturity of the Cypress low-level software. I also recall there was a bug in the mask of the SX2 requiring a lot of push-ups from us to get it work properly. There were other issues with the SX2 that required us to go to a second plug-fest to gain certification. I would guess the part is stable enough for new development at this point. It was ugly when we went through it. Again, most of those hard feelings would have been resolved had Cypress been forthcoming with us as to the state of the device at that time. I have no issues designing with Beta or even Alpha hardware - provided I KNOW that's what I'm dealing with and have some responsive linkages to the factory. Glen