Flashing does not reclaim internal RGB LED

Hi, during reflashing I have discovered that the flashing process does not reclaim the control over the RGB LED.

That is, if I have taken control of the LED via RGB.control(true);, it does not flash magenta during flashing (no pun intended), only a few seconds before the device restarts.

Is this intentional? Are you planning to change the behaviour?
Thank you, and thank you for this awesome tiny device!

1 Like

I noticed this as well. My impression is that is should, however I was thinking about how this might not be the best solution when trying to minimise power usage (ie. on batteries).

I haven’t tried lately but this must be a new thing because I remember it would take control over the LED when flashing the firmware if I took control on my code.

The current bootloader doesn’t claim back control over the RGB led if the user took over control in the code and thereafter start performing an OTA.

@wgbartley asked this before https://community.spark.io/t/pre-ota-flash-function/4350

It can be changed but would require a change to the bootloader though.

1 Like

Hey guys, I was trying to gain control over the RBG-led with RGB.control(true)…
but the only thing it does with my core is NOT flashing green when searching for wifi (after flashing)… when wifi is found it just starts breathing magenta as before…
even tho’ i’ve set RGB.brightness(50) and RGB.color(50, 0, 0)…

any ideas?

Could you post your code here, that’ll make it easier to indentify potential problems? Also, could you try a factory reset, that might be enough.
Thanks, and good luck!

1 Like

hey guys!

this is the code i’ve tried:

void setup {
RGB.control(true);
RGB.color(50, 0 ,0);
RGB.brightness(50);
}

will do a factory-reset next week, maybe that will clear things up…

tnx !

Hello,

I have a problem with the control of the RGB LED in Photon.

I am testing a example RGB control.

What I want is the LED status as default (cyan fading when everything is OK) and every 10 seconds (when I call a blink function) the LED should blink in white and them continue working as default (fading in cyan).

When I give the control to the system it nevers continue fading cyan again, is it normal?

Here is my code:

void setup() {
}

void loop() {
  delay(10000);
  blinkLeds();
}


void blinkLeds()
{
    RGB.control(true);
    RGB.brightness(64);
    RGB.color(255, 255, 255);
    delay(1000);
    RGB.brightness(0);
    delay(1000);
    RGB.control(false);
}

The problem lies in this line

    RGB.brightness(0);

The RGB.brightness() not only controls the brightness when you demand control for the RGB-LED, but also for the system.

You might rather try this

  RGB.color(0,0,0); // instead of RGB.brightness(0);

And I would also suggest you avoid using something like this delay(10000);.

uint32_t ms;
void loop() {
  if (millis() - ms > 10000)
  {
    blinkLeds();
    ms = millis();
  }
}

It’s a bit longer to write, but it keeps your code more responsive to cloud actions.

1 Like

We really should fix delay() so that it works in all cases. This code is fine for single threaded code, but for multithreaded, it will consume processor cycles unnecessarily - for multithreaded a single delay() call is preferred.

Ideally delay() should work in all cases - I’ll put it on our list of things to do this sprint. It’s meant to work, so we need to investigate why it doesn’t. :wink: Then folks can continue writing the nice simple code and have it working as expected for both single and multithreaded.

It does work with delay() - I just meant to encourage to think of using the non-blocking aproach too.

Thanks, it works.

1 Like