USB Bus power >100mA

Ideas 1 and 2 look practical on the surface, if perhaps a bit "cheaty".

In your previous threads you mentioned that the devices in question would be a an FPGA or a high-power processor. Is it possible to get either of them shoe-horned to less than standby current by running them really slowly, then ramp up the clocks when you get the OK?

Alternately, are you sure there aren't any USB PHY devices that can handle the bus configuration and standby queries, that maybe has an EEPROM that lets you configure it for how much current to ask for? I checked the FTDI website and I'm mildly surprised to see that they don't address this market already -- but they do have chips that are good for

Tim Wescott wrote in news:UtGdnTUETPM40ZfTnZ2dnUVZ snipped-for-privacy@web-ster.com:

Maybe, I am all for elegant.

Is it possible to get

The DSP power is dominated by leakage current. This is really more a function of temperature than MIPs or Clock.

I probably can't make it even without the DSP

You would think so?

I haven't found one yet. I would love for someone to point me to the part I missed. I have looked.

Al

As soon as you get your board done, someone will come out with what you need :).

What about a micro with built-in USB? Maybe you could get lucky with some combination that'd let you pump data out to your 'real' processor.

You have full control of the software, right?

This is a violation of the in-rush current requirements. But why? Start your system in 2 stages: Before and after set configuration.

Why not? If the USB controller is built into the processor, the designers most likely considered this problem. (suspend current is 2.5 mA)

What kind of host system will your device be connected to? PCs? Is USB certification required?

A way to bypass the suspend current problem is to add a (small/useless) battery, since battery powered devices are allowed to draw 100 mA during suspend.

Leo Havmøller.

I have a somewhat similar situation but I'm using the USB port for power only. I am not using USB for any communications so I'm not enumerating a device. When I first started worrying about this I was thinking about using a FTDI chip and program it for 500mA power level and then figure out some way to manage a load switch with it. However, what I have found is that the usb ports will give me full power anyway.

I got a 10 ohm, 5W resistor and started hanging it across USB ports and measuring the voltage and current. I was getting 4.8/4.9 and close to the 500mA. In the 6 I tried, Dell, HP and generics, none of them did a 100mA limit.

Again - please note that I am not using the USB protocol and am not enumerating any device. I'm just drawing power and does not seem to be an issue. I'm also not having to deal with a generic USB implementation. I'm lucky this time in that I have a very defined set of host that I have to deal with. It sounds like you have an integrated system so if you have control over the host look at any software power management settings. Linux can be told to never suspend a device.

You might use a PIC, AVR, (pick your uC) as a USB "gateway" for your heavy power device. Have it enumerate for 500, turn on a load switch and start relaying traffic. USB on one side and some serial or parallel interface on the heavy power side.

The ports are not limited. It's just that the OS keeps track of used current. If a device requests, say, 300 mA from a bus powered hub and some other device already got 300 mA by request, the second device's request will not be granted.

Meindert

Joe Chisolm wrote in news:x- GdnafNjsg1VJfTnZ2dnUVZ snipped-for-privacy@earthlink.com:

I have done this experiment also. The only place it seems to matter is the place where bus power is actually important - notebook PCs.

These computers actually care about power consumption and may exert more control.

settings.

My application can not assume that I have control of the PC side. The OS is likely some flavor of Windows.

This is really just a subset of "Idea 1". I need the high speed USB interface. It's not negotiable.

Thanks

Al

Leo Havmøller wrote in news:iuefaj$rm2$ snipped-for-privacy@speranza.aioe.org:

Actually USB is not specifically part of the processor. It uses a ULPI transceiver.

I don't need official certication, but it must work reliably. Assume the host is a modern noetbook PC running Windows 7 or XP.

I haven't heard this idea. I have been wondering if there is a way to take advantage of charging circuits in some way.

Thanks

Al

Wait a minute -- aren't there Blackfin devices that have embedded USB?

For that matter, I _know_ that TI's Stellarus line has some ARM devices with USB. I don't know if they'd have the throughput to act as a communications front end for you, but I _do_ know that their SSI ports have at least minimal DMA functionality -- there may be enough stuff there to put together something.

Some Blackfins do have USB support. We make a Blackfin 527 module that has this.

I have a specific self powered design that already exists. I am not trying to find a new processor that has USB integration.

What I am really trying to do is solve a fairly common problem where USB bus power is desired and it is difficult to meet both suspend current and 100mA requirements.

This is a common problem when using ULPI transceivers since the "brains" are often external processors that are not specifically designed to manage low power. DSPs and FPGAs are typical examples of this. The problem is generally more severe for high speed requirements because high speed implies devices that can take advantage of the data.

Al

Which is precisely why I was suggesting (not very directly, I admit) that you investigate the possibility of finding the smallest, cheapest processor that will work as a USB communications peripheral. It's not the most elegant solution -- that would be a true high-speed interface chip along FTDI lines but capable of 400MBPS. But it may get you where you want to go, and be cheap and functional enough to serve.

In fact -- how about I figure out how to make it work with a Stelarrus chip. I'll program it, grind the part numbers off of it, put a Wescott Design Services sticker on it, and I'll sell it to you for about twice the DigiKey 1ea pricing for the blank chip. Then you won't have to think about a whole ARM core that's sitting there doing almost nothing, while pretending to be about 500 gates.

1. It will just work in the 99% of cases.

1. However, if you are constrained to one USB socket, the only way to satisfy the above without breaking some rules is charging a battery or a supercap from USB and using them at the moments when you need some extra power.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Vladimir Vassilevsky wrote in news:y6CdnZsUeslEDJbTnZ2dnUVZ snipped-for-privacy@giganews.com:

Thanks Vlad

Al

Well, then I think you can solve the problems with some simple power management in software. Start your system in multiple stages. Dont power up peripherals and clock up your CPU until you receive set configuration. You will want to reduce current sonsumption during suspend as much as possible. Consider the case when your device is connected to a laptop that is sleeping; Your device should not draing the laptop battery. Shutdown everything, clock your CPU way down (100kHz or less), and make a tight loop that polls your USB controller for resume/reset events and nothing else.

Leo Havmøller.