Addressable LEDs

[MrRSquared]

Hello, I may have found another bug. I was trying out the Addressable LED library in WPILib 2020, and though I began trying to write it from scratch, when it did not work, I tried using the built-in example. I had the same error each time.

If I comment out the Addressable LED section the program runs fine.

Here is the error I receive in the RIOLog.

VMX HAL: pigpio library version 69 opened.
VMX HAL: SPI Aux Channel 2 opened with baudrate of 4000000.
VMX HAL: Established communication with VMX-pi model 0x32, hardware rev 60, firmware version 3.0.411
VMX HAL: Acquired navX-Sensor configuration.
VMX HAL: Library version 1.1.207
Set VMX CAN Mode to NORMAL.
Server Running...
********** Robot program starting **********
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb6e89e44, pid=1317, tid=1321
#
# JRE version: OpenJDK Runtime Environment (11.0.3+7) (build 11.0.3+7-post-Raspbian-5)
# Java VM: OpenJDK Server VM (11.0.3+7-post-Raspbian-5, mixed mode, concurrent mark sweep gc, linux-)
# Problematic frame:
# C [libpthread.so.0+0x8e44] pthread_mutex_lock+0x8
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# //hs_err_pid1317.log

I cannot find the referenced .log file. If anyone can help me locate it, I will upload it.

[kauailabs]

We won't be supporting the addressable LED API in the first release of the WPI 2020 Library (for the FRC Training Robot).

The VMX-pi doesn't provide sufficient current to drive a significant number of LEDs. Our strategy is to implement these in the Titan Quad motor controller, where there is sufficient available current to run a large string of LEDs.

Our strategies are always modifiable of course and we're open to input that helps us understand the uses cases folks are looking for.

One short-term action on this topic will be to output a more meaningful message in the current release if an attempt is made to use the Addressable LED API. Once that occurs, this ticket will be closed and we'll create a "new feature" tick in our planning "Zenhub".

[MrRSquared]

Thank you for the quick reply. I totally understand this mentality. TBH, I wonder how the RIO deals with this issue. I could be wrong, but I feel the VMX has a significantly larger amount of current protection. My biggest concern is not current but reverse polarity as the typical LED Strip goes +S- not -+S.

However, if it were up to me, I would like it available. I used to think LEDS were just a frivolity, but they are an incredibly helpful tool to teach programming. Here is why we like them.

1. LEDs are cool. Students love them. They are beautiful and a bit magical.
2. They teach how to safely run loops in an otherwise iterated environment.
3. They teach arrays
4. They teach some unique syntax because they are arrays. This is an important piece because most array tutorials iterate through text (which is cool to me, but not so much to some students).
5. They open a door to programming creativity (how can we use these to help the drive team?
6. They provide a mechanism for safe instant feedback to programmers just getting started.

Because they are so useful to teams, some of whom may not be able to justify the Titan Quad because it is not tournament legal, It would be nice if there were a way to safely implement the LEDs. Is there a way to implement them safely by checking the number of LEDS or disabling the power pin for that channel if it is assigned to LEDs?

Does the VMX have .5AMps on the entire output bus? This does go quick if you are using the maximum output metric (60mA per pixel according to Adafruit.

Edit: I just read further, and if the external device limit is 12mA, that is not enough to power even one LED safely. So, is it possible to disable the power to a specific output? If not, I do not see a way to allow them safely either.

However, this issue is not much different than with other devices. For instance, one way we are using the VMX is for Vex Motor controllers (they can pull 3 amps). But, we are wiring them using the separate power supply.

Regardless, I totally understand the decision. Too many LEDs can be dangerous.

P.S. If there were a way to disable the power features on the Titan Quad and get it approved by FRC , that would be amazing and make it been more affordable for teams.

[kauailabs]

The total current available on all of the "power" pins on the 33 VMX-pi channels (that includes the FlexDIO, the High-current DIO, the Analog Inputs and the CommDIOs is 500mA.

One thing we can consider doing is enabling this feature, but with the instructions that the LED power should be supplied via an external 5VDC supply. Although VMX-pi has a 3A power supply, 2.5A is reserved for the worst-case power usage in the Raspberry Pi, and the full amount is reserved because a current level below the full requirement could cause the Raspberry Pi to shutdown/reboot which would be disastrous.

Since the remaining 500mA budget is not reasonably sufficient for a sting than about 8 LEDs, an external supply is required.

Do you think that this is a reasonable approach (for systems that don't have a TitanQuad to manage the LED updating and power)?

[MrRSquared]

Thank you for your reply. I think that is an excellent approach. I guess I have two questions.

What happens if people do not listen and try to run a 50 strand at full bright white? Would the current limit kick in and just turn them off? If that is the case, this sounds like a perfect solution. If it is not...

Is there a way (or need) to disable the power output in that event?

For our practice LED setups, we actually use USB Phone Batteries (and few LEDs). It could be helpful to have a recommendation of a level converter for those who want to use their same PDP, but that may not be necessary. We already have multiple options (Titan, External Battery, figure out level conversion yourself).

[kauailabs]

What happens if people do not listen and try to run a 50 strand at full bright white? Would the current limit kick in and just turn them off? If that is the case, this sounds like a perfect solution. If it is not...

In this case, the current limit kicks in and shuts down all output power on all power pins (all 33 channels of them). The system does this to ensure that sufficient power remains to maintain sufficient curently flow so that the "brains" (the Raspberry Pi, and the VMX-pi onboard microcontroller) continue to operate. Very similar to the RoboRIO.

Is there a way (or need) to disable the power output in that event?

As you surmised, the above solution is very effective. The power output is immediately disabled, and it's managed in hardware so it happens in less than a millisecond. It'll resume after a short period (100ms or so); if the overcurrent condition persists, this sequence will repeat.

On Sun, May 17, 2020 at 5:02 PM Mr. Roth-Ritchie notifications@github.com wrote:

Thank you for your reply. I think that is an excellent approach. I guess I have two questions.

What happens if people do not listen and try to run a 50 strand at full bright white? Would the current limit kick in and just turn them off? If that is the case, this sounds like a perfect solution. If it is not...

Is there a way (or need) to disable the power output in that event?

For our practice LED setups, we actually use USB Phone Batteries (and few LEDs). It could be helpful to have a recommendation of a level converter for those who want to use their same PDP, but that may not be necessary. We already have multiple options (Titan, External Battery, figure out level conversion yourself).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kauailabs/allwpilib/issues/36#issuecomment-629919992, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXLTCEEDW6J3DUHCW45MSDRSCQMXANCNFSM4M2X3JEQ .

-- Scott Libert - Founder, Kauai Labs [image: https://www.kauailabs.com] https://www.kauailabs.com/

[MrRSquared]

That is excellent. Then I personally think it would be excellent to enable them with the warning that without the external power, they will not work (and this is true of the Rio as well. I am not convinced its power management is as safe).

[kauailabs]

Here's finding from Analysis:

• There are two classes of LED strips; the "1-wire" LED strips (e.g., WS2811, WS2812, SK6812, WS2812B, aka "neopixels") and the "2-wire" LED strips (e.g., APA102C, WS2801, aka "DotStar")

• The WPI Library interface supports "1-wire" LED strips on a single port; the API does not provide a way to specify the two ports required to control "2-wire" LED strips.

• The "1-wire" LED strips have very tight timing requirements (+/- 150 nanoseconds accuracy), whereas 2-wire strips (which are driven by both clock and data signals) do not have tight timing requirements.

• The "1-wire" LED strips are more commonly used currently, likely because they are typically less expensive.

• How to support 1-wire strips: To meet these stringent timing requirements, the "1-wire" LED strips can be supported on the VMX-pi platform on two pins: (a) (the "MOSI" pin of the VMX-pi SPI interface) and the (b) second HighCurrentDIO pin. The fully support (a), it is required that the Raspberry Pi not drop into power-saving mode (because that causes the core clock frequency driving the tight timing to change, breaking the timing requirements) and to support (b), it is required to disable the "snd_bcm2835" driver which produces medium-quality audio using the "hardware PWM" circuitry.

Proposal 1: Support 1-wire LEDs using the "MOSI" pin of the VMX-pi SPI interface; the two downsides of this approach is it disallows the use of the VMX-pi SPI interface, and it will require disabling the Raspberry Pi from dropping into power-saving mode.

Proposal 2: Support 1-wire LEDs using the second HighCurrentDIO pin; the two downsides of this approach is it disallows use of the Raspberry Pi audio interface (requiring special driver blacklisting, requiring a reboot) and disallows other use of the Raspberry Pi hardware PWM circuitry (e.g., for sending arbitrary waveforms out GPIO pins).

The two above proposals are now out for comment; thanks for any input you may have.

[MrRSquared]

Yes, I am aware of this issue. I had assumed the VMX-pi rose above it because of the pwm support, but I do understand the constraints.

My initial thought is if this choice is able to be made through software, perhaps have the user decide. If that is not a possibility, I guess the only option would be option 1. I feel many of our test projects will use pwm for motors (as opposed to CAN). So, if it disables the timing for motors, then, motor safety will likely take over and mess with timing loops anyway.

[kauailabs]

This new feature is now supported in the VMX-pi. Details can be found on the VMX Forum at this page: https://groups.google.com/forum/#!topic/vmx-pi/ryiP2V451PI