When I compile code that includes the “Thread” function on the Web-IDE, it will not run on an electron if it’s compiled with target firmware 1.4.1 or 1.4.2.
The device will show a solid white light.
If I select target firmware 1.2.1 in the IDE, the code will run.
Here’s a sample code to try
#include "Particle.h"
#include "Serial4/Serial4.h"
#include "Serial5/Serial5.h"
#include "cellular_hal.h"
SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);
void threadFunction(void *param);
Thread thread("testThread", threadFunction);
system_tick_t lastThreadTime = 0;
volatile int counter = 0;
unsigned long time5;
volatile unsigned long timer5s = 0;
void setup()
{
Serial5.begin(38400);
time5 = millis();
}
void threadFunction(void *param) {
while(true) {
counter++;
// Delay so we're called every 10 milliseconds (100 times per second)
os_thread_delay_until(&lastThreadTime, 10);
}
// You must not return from the thread function
}
void loop()
{
if (millis() - time5 > 5000 || millis() < time5) {
timer5s++;
Serial5.println("Loop. Millis=" + String(millis()));
time5 = millis();
Serial5.println("Counter: " + String(counter));
}
}
@avtolstoy or @rickkas7 - would you be willing to comment on any Device OS changes w/r/t threading in the above?
Strikethrough: Ignore the context about solid white light, that’s by design. (I misread this as breathing white, not solid white, apologies, working way too quickly this AM).
Actually, @ahk - are you saying that your device breathes cyan on 1.2.1 running this code?? That would be surprising to me. Mine does not, mine breathes white. But the loop fails.
I cannot duplicate the connection side of things (mine breathes white on 1.2.1 after a proper downgrade), but I can confirm the firmware failure, so I look forward to the eyes of someone with greater insight into DeviceOS changes.
The sample code breathes white because it’s missing a Particle.connect();
in setup()
As soon as I select “Device OS target” >= 1.3.1 in the Web IDE, the devices will be solid white.
The actual firmware on the devices does not matter. I have some electrons flashed OTA (where there is no firmware downgrade) so they are running firmware 1.4.1 and the code compiled with “Device OS target” = 1.2.1. (works). Compile with Device OS target 1.4.1 and they fail.
I believe the problem is likely the use a globally allocated thread. Because the order of object initialization varies unpredictably, this is not a good idea. I will update the threads tutorial to not do that in the future if this is what is happening.
What is the difference between creating a thread in the way you mention, vs using os_thread_create ? I see that used sometimes in users’ code and libraries etc, but don’t see any reference to it in the docs and I’m just curious.