NCS CAF leds modules work inversely?

[Harvey Zheng]

Hi，

I have a problem about CAF leds modules. I submit a led event to turn on led for 3600ms and turn off led for 500ms, but it work inversely in fact.

I find that leds.c will delay 3600ms firstly withoud turn on led, it will turn on led for 500ms after 3600ms.

static void led_update(struct led *led)
{
	k_work_cancel_delayable(&led->work);

	led->effect_step = 0;
	led->effect_substep = 0;

	if (!led->effect) {
		LOG_DBG("No effect set");
		return;
	}

	__ASSERT_NO_MSG(led->effect->steps);

	if (led->effect->step_count > 0) {
		int32_t next_delay =
			led->effect->steps[led->effect_step].substep_time;

		k_work_reschedule(&led->work, K_MSEC(next_delay));
	} else {
		LOG_WRN("LED effect with no effect");
	}
}

static void work_handler(struct k_work *work)
{
	struct led *led = CONTAINER_OF(work, struct led, work);

	const struct led_effect_step *effect_step =
		&led->effect->steps[led->effect_step];

	__ASSERT_NO_MSG(effect_step->substep_count > 0);
	int substeps_left = effect_step->substep_count - led->effect_substep;

	for (size_t i = 0; i < ARRAY_SIZE(led->color.c); i++) {
		int diff = (effect_step->color.c[i] - led->color.c[i]) /
			substeps_left;
		led->color.c[i] += diff;
	}
	set_color(led, &led->color);

	led->effect_substep++;
	if (led->effect_substep == effect_step->substep_count) {
		led->effect_substep = 0;
		led->effect_step++;

		if (led->effect_step == led->effect->step_count) {
			if (led->effect->loop_forever) {
				led->effect_step = 0;
			} else {
				struct led_ready_event *ready_event = new_led_ready_event();

				ready_event->led_id = LED_ID(led);
				ready_event->led_effect = led->effect;

				EVENT_SUBMIT(ready_event);
			}
		}
	}

	if (led->effect_step < led->effect->step_count) {
		int32_t next_delay =
			led->effect->steps[led->effect_step].substep_time;

		k_work_reschedule(&led->work, K_MSEC(next_delay));
	}
}

[Håkon Alseth]

Hi,

 

Thank you for sharing the sample you use.

Here's the configuration loaded (for nrf52840dk atleast):

https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/samples/caf/configuration/nrf52840dk_nrf52840/led_state_def.h

 

This example uses PWM as the "backend" for the LEDs, as shown here in the DT overlay:

https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/samples/caf/boards/nrf52840dk_nrf52840.overlay

 

The inversion happens with this property:

https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/samples/caf/boards/nrf52840dk_nrf52840.overlay#L44

 

Kind regards,

Håkon

[Harvey Zheng]

Hi,

Thank you for your reply.

I change LED_EFFECT_LED_BLINK to this. (use PWM as backend for the LEDs)

#define LED_EFFECT_LED_BLINK(_period, _color)					\
	{									\
		.steps = ((const struct led_effect_step[]) {			\
			{							\
				.color = _color,				\
				.substep_count = 1,				\
				.substep_time = (2000),			\
			},							\
			{							\
				.color = LED_NOCOLOR(),				\
				.substep_count = 1,				\
				.substep_time = (500),			\
			},							\
		}),								\
		.step_count = 2,						\
		.loop_forever = true,						\
	}

So, normally, led should be turned on for 2000ms，and be turned off for 500ms. But it work inversely in fact(on for 500ms，off for 2000ms). You can test it use this sample: https://github.com/nrfconnect/sdk-nrf/tree/v1.8.0/samples/caf

[Håkon Alseth]

Hi,

 

As mentioned, the PWM channels are by default inversed.

If you change this line (and do the similar to the other PWM pins that you use):

github.com/.../nrf52840dk_nrf52840.overlay

To:

/delete-property/ ch0-inverted;

 

Then it should not be inversed after rebuilding and flashing.

 

Kind regards,

Håkon

[Harvey Zheng]

Hi，

Thank you. I change the file as you said. Now it works as I set it up, but there is still a delay at the beginning, it seems to be caused by this line: https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/subsys/caf/modules/leds.c#L169

And, I have a next question. What do I need to change when I use GPIO as  backend for the LEDs? It has the same problem as PWM.

[Håkon Alseth]

Hi,

 

Harvey Zheng said:

Thank you. I change the file as you said. Now it works as I set it up, but there is still a delay at the beginning, it seems to be caused by this line: https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/subsys/caf/modules/leds.c#L169

Is this the initial delay that is problematic?

 

Harvey Zheng said:

And, I have a next question. What do I need to change when I use GPIO as  backend for the LEDs? It has the same problem as PWM.

This is configurable in kconfig, using these configurations:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.8.0/nrf/libraries/caf/leds.html#configuration

 

Kind regards,

Håkon