[FR] Use softpwm for rgb pins when PWM_PIN on the pin is false

[arminth]

Bug Description

I am using an RGB-strip and a Neopixel ring on my Delta with SKR 1.1 pro.
When I start a print (from Octoprint), LED start showing the correct status from blue to magenta until bed is heated and then from magenta to red until nozzletemp is reached.
When printing starts, neopixel switches to white, RGB strip switches off! I can still switch it on manually.

My Configurations

Marlin_configuration.zip

Steps to Reproduce

Start a print.

Expected behavior: all LED switch to white when print starts.

Actual behavior: Neopixel goes white, RGB go out.

Additional Information

I had to replace PeripheralPins.c from C:\BIGTREETECH\Marlin-2.0.x\buildroot\share\PlatformIO\variants\BIGTREE_SKR_PRO_1v1
with PeripheralPins.c from Marlin-bugfix-2.0.x "2019-11-10"

C:\BIGTREETECH\Working Mega CoreXY\newer\Marlin-bugfix-2.0.x\buildroot\share\PlatformIO\variants\BIGTREE_GENERIC_STM32F407_5X

because of
#16158

It shouldn't affect the behavior, as LED in general work.

[davidcgu]

Same problem here but with a normal LED as cabin light and latest bugfix downloades today, I will give a try to your solution and will provide some update.

Regards

[thinkyhead]

@LinoBarreca — The last change to this file moved timer 3 to timer 8, labeled "FAN0." Is this an expected side-effect of the change? Should some boards be using a different platform variant, or could certain features be conflicting with the pin(s) associated with timer 8?

[LinoBarreca]

@thinkyhead i don't want to blame anyone(not even myself) without checking it on the computer but I remember that I completely rewrote the pinout taking it from stm (so what it pinX in code). I will check in a few hours what happened to the pins and who changed it. If no one else but me did then it's either some copy/paste gone wrong or a BTT mistake on the PCB marking. 2am here. I go back to sleep.

[davidcgu]

Tried the solution proposed of replacing PeripheralPins.c file with a previous version that was working for me without results.
I'm using a normal led connected to a PWM gpio and does not work, when start to print lights goes off and I can not turn it on anymore until the print is finished.

Regards

[arminth]

@davidcgu that was probably a misunderstanding! I had to exchange the file to get RGB running at all!
After it worked, I realized the issue.

Merry Christmas!
Armin

[davidcgu]

I don't understan, what I can tell is that previosuly was working fine and with latest bugfix I have a normal led and turns off when starts printing and on top of that is not possible to turn it on anymore until print is fhinished, I guess at some moment was done some change wrong on marlin.

Regards

[davidcgu]

note: with 2.0 stable it was working fine

[davidcgu]

My apoligies... forget what I told previously, discovered I used some pins defined in stock for fan1-2, I assigned the pins on the config but forgot to comment the original definition for same pins on pins file what drived the issue to happen.

Solved by commenting corresponding lines on pins file.

merry Xmas guys

[arminth]

@LinoBarreca
Any news on the subject with the pins?
But I assume, the pins and switching off the LED after starting print are two issues...

Cheers
Armin

[LinoBarreca]

I checked the PeripheralPins file.
Actually PF_7/8/9 are defined as analog input + digital output to save on (critical) used timers.
I don't know how Marlin handles the RGB strips, but if it uses hardware pwm that could be the problem.

To define them as PWM pins uncomment these lines:

    //{PF_7,  TIM11,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF3_TIM11, 1, 0)}, // TIM11_CH1
    //{PF_8,  TIM13,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF9_TIM13, 1, 0)}, // TIM13_CH1
    //{PF_9,  TIM14,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF9_TIM14, 1, 0)}, // TIM14_CH1

Be careful: activating them as "PWM pins" will use three different timers (no, you can't change them for hardware PWM, they are linked in hardware) I suggest you to use, if available, other pins which use the (already used for pwm) timers 3,4,8 or 9.

Leaving those lines uncommented (as in the file before my modifications) causes any analogwrite mess up with the timers used in marlin as soon as the instruction is encountered. Read it as "do not do it".

If marlin uses software pwm for rgb strip then the problem lies elsewhere.

[viper93458]

Which pins would you recommend using for RGB?

Kind regards,
William

[LinoBarreca]

I don't have a computer now so take what I am writing with the proper caution.
I would not use a rgbw strip. For this reasons:

1. they require a driving circuitry besides the board (the expansion port is 3v3 so you got to add 3/4 mosfets or something like this)
2. they require analog voltage on 3/4 pins
3. they are not addressable

All those are addressed with neopixel.

1. external power
2. digitally controlled
3. per led

...but if I must use an rgb strip I would use the three (hardware pwm) fan ports for R,G&B and configure marlin to do soft pwm for fans...
Although I would check if I can control the rgb strip with soft pwm first. It's strange that marlin doesn't already have an option for that...requiring 4 analog ports is kinda strange...and the code for softpwm is already present so I would expect it to be able to do that for rgb strip too.

[LinoBarreca]

Edit: from here https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/feature/leds/leds.cpp
It seems that marlin supports non pwm pin for rgbw (turning them high/low) probably it must be enabled somehow. (I am on the phone and I can't see who calls that and where)

[LinoBarreca]

okay. I triple checked it. The behavior of the pins is correct according to the schema and the definition

I would open a feature request about softpwm for RGB lights but the behavior of marlin is actually correct according to the board and the specifications. It's the user that uses the wrong pins. The only PWM pin for the expansion port is PC9, all the others are digital and can't be used as PWM output.
@boelle change this into a Feature Request ("Use softpwm for rgb pins when PWM_PIN on the pin is false")