OK, let me know if I got this right. The idea is to:
Priority is BP5 idle, let’s say 150 mA.
Then Vout, which has the default limit of 300 mA. (Although we can request up to 500 mA. There’s also unlimited option.)
Last is onboard LEDs, which can be anywhere from 0 mA to 350 mA depending on the Vout consumption.
Even with the first two priorities, there is the possibility of exceeding the 500 mA USB supply limit. But let’s say that we’ll always stay within the limit, adhering to the priority list.
This is the case when we are in any mode:
I2C, SPI, external LEDs etc. are expected, we don’t want the onboard LEDs to impact anything we are powering when we are trying to do actual work.
But also in LED mode when onboard LEDs are selected and all the output signals are being sent to the internal LEDs, we may be powering something else via the Vout pin as we still can read/write IO pins with a/A/@ commands. So technically there’s the possibility of not having any current budget for the onboard LEDs as we are powering something externally that consumes >= 350 mA.
There may still be some behavioral edge case options, such as when the user explicitly chooses no limit on Vout. For example:
Temporarily disable animations? (Y/n)
Show API-driven pixel data at low brightness? (Y/n)
Finally, perhaps the power budget can be overridden (dynamic config … never saved to config file), such as where it’s known that the powered USB hub is happy to supply up to 2A per port.
But those are “nice to haves”, vs. core … so I think you’ve got it right.
Found the power budget but it is pretty old and not at all accurate.
I looked up the AP2127 datasheet, which is the part we landed on during the supply chain crisis. Its intended max output is 300mA. The extra headroom on the fuse is so that momentary inrush current from the caps doesn’t blow the fuse. The VREG should not actually use much more than 300mA continuously (though I know I can get mine to ~400mA with a good VUSB, so maybe that is not to be believed).
3.3volt supply
mA
Vusb supply
Rp2040 Cores
35
153LEDs
315
RP2040 Misc
2
LCD LEDs
60
RP2040 IO
40
74hc4067
0.1
Comparator
0.1
74hc4066
0.1
Opamp
0.1
74hct245
0.1
74hc595
0.1
I sense Opamp
0.1
DAC
0.1
Pull up/downs
20
LCD
6
Buffer * 8
20
120
SD card
20
Pull-up and down
20
3.3V supply
143.4
143.4
MAX: 220ma
538.8
Typ max ~145ma
Typical: ~100mA
This is the power budget I found, it is not the final one, but it is what I could find. It is part of a larger spreadsheet of calculations for the current sense, VOUT margining, packpower calculations, etc. I have no idea when it was updated, the file says REV10 but it could be any sheet updated for REV10. At this point it appears we have 15 SK6812s, an SPI DAC and an SD card.
This is worse case scenario:
All RP2040 buffer IOs fully loaded in bus contention
IO buffers fully loaded in contention (20 vs 120mA)
40mA budgeted for pull-up and downs, which is way way high given most are 100K or 1M resistors.
It appears I decided to limit the LEDs to 30% brightness via firmware, for 20mA each max, which is consistent with the current firmware options. Again, worse case, as few animations run all three dies at once.
Looks like I gave no consideration to the VOUT power supply at this point.
Assuming the typical max on the 3.3v vreg (145mA) and Vusb pull with all LED dies at 30%, we eek out just above the 500mA limit.
As Tayken found with real world current tests, the consumption is nowhere near this. With all LEDs at 100% the current draw is basically equal to the LED total (if I understand your findings correctly).
Does anyone know what is involved in requesting eg 1A from USB? I don’t have my hardware hat on at the moment, but I feel the resistors used on the USBC connector currently request 500mA.
Without a USB PD handshake, a USB-C charger can advertise either “Default USB power”, 5V @ 1.5A, or 5V @ 3A. The device can determine which one is being advertised by measuring the voltage on the CC wire. See Table 4-26 in the USB-C spec.
The two 5.1K resistors on the CC1 pins indicate to the upstream port to provide 5V and up to 1.5A (whether the upstream can supply that much current depends on what you’re connecting to.
See a PDF put out by TI, page 8, for overview. (BusPirate’s USB-C port is an upstream-facing port (UFP) and power sink.)
So… it seems that while you can request the higher power via resistors, to verify it’s actually available (without using USB-C PD) you need to measure the voltage on the two CC pins?
I’m not an expert here … thus my linking to the sources of information.
That is the exact configuration we have. Given that out of shipped units we’ve had zero reports of USB short errors on any OS, I’m guessing we pretty much get that 1.5amps all the time? I generally use USBC to USBa cables though, so not sure how that applies.
I don’t think the resistors on the CC lines help at all, when using USB-C to USB-A cables.
Having the resistors is only half the battle. The resistors tell the power source the maximum current the power sink (BP) will take. That’s half the battle for getting higher amperage 5V.
Detecting that the source actually provides higher power is more complex.
If I'm understanding things correctly
Check for USB-C compliant power
Only works for USB-C to USB-C cables?
Requires a USB-C compliant power source
Requires compliant cables … separate CC1 and CC2 wires, etc.
Supports 5V @ 3A and 5V @ 1.5A
Resistors indicate sink’s maximum requested amps
Sink must measure BOTH CC1 and CC2 voltages to confirm actual amps provided by the source
Else, do the USB BC1.2 negotiation
Allows up to 1.5A with USB-A cables
BusPirate is ready for enumeration in < 1 second, so only needs to support primary detection method
One page gives details of this … more analog voltage measurements, this time on D+/D-.
Else, if device reports USB3.1 capability and host does also, can rely on 900mA (???)
I think this may not be possible with the RP2040 / RP2350?
Else, pretty much only guaranteed 500mA …
Are there connections and hardware on the buspirate to measure the voltage levels of:
Ok. I think, without being able to read those voltages (or having a controller chip in between), that there is not an option to know, from the buspirate side, whether the power source provides greater than 900mA (USB 3.1 mode) / 500mA. Since these RP MCUs don’t do USB3.1, I do not think the detection is available.
I’d love to be wrong… so if you’re an expert, please jump in and help me know what I misunderstood … I’m just learning!
Ian … are there leftover / unused analog measuring channels on any of the chips in the current BOM? If so, I suppose it’s possible to provide detection of 5V USB-C 3A / 1.5A sources, with just a few readings and a few extra traces … no PD communications required!
Cool. My initial thinking was that in onboard LED mode we’re focusing on communicating with LEDs, so dedicating any power to anything external doesn’t make sense. But now I understand your train of thought.
I’d stay away from assuming we can get more than 500 mA due to HW limitations. Short version is we need to be able to measure the current/voltage on the CC line(s). Here is a Hackaday article if you’d like to read a bit more. There’s also the case of cables and ports being used. I personally use mine with a USB-C to USB-A cable as I don’t have enough ports. For that style of cable , the CC line internally has a resistor connection to VBUS, which sets it to the default power (500 mA for USB 2.0, 900 mA for USB 3.1). I’m not sure if BP can get 900 mA as RP2040 has a USB 1.1 controller. I have to do a bit more research to confirm this but usually you need to request this limit increase from the host during device enumeration, at least that’s how I remember it.
We can get more power from the USB port, but as @henrygab mentioned, we’ll need some HW changes by at least adding some ADC lines connected to CC lines. If one version supports this and another doesn’t, then it’ll complicate the firmware. Not sure if the added effort is worth it. So I’d suggest sticking with the 500 mA USB current limit instead of some dynamic current detection method. I feel like we’re going a bit overboard, especially when you consider that AP2127 has maximum output current limit of 450 mA.
I agree that attempting to get (and be able to rely on) >500mA from the USB port will require hardware changes. If higher power budget becomes an explicit goal of a next-generation revision of busPirate, let’s open a new thread for that discussion.
Given the 500mA limit on USB, it seems this thread’s main purpose now is to add a dynamic brightness limiter to the pixels.
given how small the buffer is, it probably also makes sense to have a copy of the pre-power-limited values cached. This allows the pixels to be updated when power budget changes, without forcing them to be redrawn / regenerated. RAM cost: 72 bytes (for 18 pixels, each stored in a uint32_t).