Addressing more than one onboard LED?

General
1

Hi,
I’m new to this device, just recently had the chance start playing around with the BusPirate 6. I started with the tutorial first.
When going through the LED tutorial I was wondering if there was a way to directly control the other onboard LEDs as well.
During the tutorial only one LED is addressed (as shown in the pictures), can I address the others in the same mode? Or is something else needed to achieve this?
Apologies for this newbie question, I’ve already searched both this forum and via google, but was not able to find an answer, so I thought, I’ll give it a try here.

Cheers,
Max

1 Like
2

I don’t think it’s possible due to some firmware safety limits unless something changed. Here is why I think this (didn’t do a code dive to confirm this):

If I want to light up the first LED red, I send this command:

LED-()> [0xff0000.24

RESET
TX: 0xFF0000.24

which means reset, then send 24 bits, first 8 of them are 1s.

The protocol for SK6812 is that you just chain data so if I send the same hex twice and change the bit number to 48, I should be able to light 2 LEDs red, right?

LED-()> [0xff0000ff0000.48

RESET
TX: 0x000000FF0000.48

Hold up, wait a minute! What?! As you can see, sent command is not the same as what I put in. Essentially firmware is zeroing out all the bits, except the last 24 bits, which is the RGB data for the first LED. This is true for any number of bits:

LED-()> [0xff0000ff0000ff0000.72

RESET
TX: 0x000000000000FF0000.72 
LED-()> [0xff0000ff0000ff0000ff0000.96

RESET
TX: 0x000000000000000000FF0000.96
1 Like
3

Thanks for your reply :slight_smile:

Yes, the behavior you describe is what I also originally tried.
From my (granted, somewhat limited experience) with WS2812b style LEDs I also derived the idea to just chain the next 24 bits for the second LED.
Same result.

You mention this might be a safety feature. Are you thinking about the current necessary to drive all LEDs in full brightness?
Driving all 18 LEDs at full brightness white should exceed the current rating of the onboard power supply (at least the 500mA of the PPSU)

1 Like
4

Hi @flatc4p - thanks for checking out the Bus Pirate.

We’re just going to control one of them because all 16 LEDs at full power would be too much current for some USB ports.

Yes, it is indeed a safety measure.

The LEDs are powered directly from the USB power supply (VUSB/~5volts). If all the LEDs are lit fully, it would exceed the current limit of the USB port. This might cause the computer to disable the port, or worse.

The firmware only allows you to light the first LED, all others are set to 0x000000.

If you are lighting external LEDs, then you would send multiple frames:

0xff0000 0x00ff00 0x0000ff

This would light a string of 3 LEDs.

1 Like
5

Hi @ian
Thanks for manufacturing and maintaining such a cool device :smiley:
And thanks for the clarification!

1 Like
6

For the single internal LED, a better API has just not been a priority (yet), as no extension / command has had a need for the LEDs. I’ve had various improved APIs in progress, but … it would be slightly messy. When there is a need for more granular control, then I am happy to work to make that happen.

As for the current safety on internal LEDs, a current limiter is easy enough to add. The per-LED current is known, so it’s not terribly difficult to limit brightness based on the color content being displayed. This capability is in multiple other LED controllers (FastLED, WLED), so would just need to be ported.

For external LEDs, I imagine the current regulator for external power would be usable. Doesn’t the external LED control already allow controlling multiple LEDs? (or is it also limited to one LED for some reason?)

7

For external (reels) of led strips an external power supply is almost mandatory. It will handle as many LEDs as you can fit frames in the syntax buffer.

1 Like