Particle Device OS Updates: Comments

Would you mind posting an issue in github in the firmware repo, including the source code you’re testing with?

1 Like

Done. Issue #671

1 Like

Gee @mdma !
Software timers, serialevent, version(), update control… lots of really good stuff here ! You guys are just amazing ! Particle firmware is becoming Really Serious :smile:


I`ve upgraded all my photons from 0.4.5 to 0.4.7 , so far so good … Good work

New update looking good! The software timers are amazing, it’s great to see the RTOS features appearing :slight_smile:

1 Like

I`ve used the software timers , just for D7 flash right now, but one feature which is missing that would have been very nice is a way to change the period. eg timer.period(300)


Is anyone having problems with 0.4.7 not always registering variables/functions in the Particle Cloud? In other words, Particle CLI list does not show any Variables or Functions (and the device is online). Haven’t found a work around yet. This problem is a bit of a worry…

Good news is that the random resets have gone away (so far) - will see how it goes over night.

Agree with @peter_a, timer.period(x) is a missing piece.

do you have System_Threading enabled? i noticed exactly that yesterday - but with 0.4.6.

the functions also disappeared from IFTT (and CLI) and i was suddenly not able to call the function via the api. disabling system_threading made it working again but i thought i’d wait for 0.4.7 before further investigation.

Firmware 0.4.7 has shipped!!
Particle.variable() supports Strings #6576

Does it ? the error below occurs with 0.4.6, the same with 0.4.7

../wiring/inc/spark_wiring_cloud.h:131:9: error: static assertion failed: 
In Particle.variable("name", myVar, STRING); myVar must be declared as char myVar[] not String myVar
         static_assert(sizeof(T)==0, "\n\nIn Particle.variable(\"name\", myVar, STRING); myVar must be declared as char myVar[] not String myVar\n\n");

Compiles and works perfectly with 0.4.5 and below… before you spoiled it… :wink:

The syntax is

String myString;
Particle.variable("myString", myString);

Please see the docs for details on the new simpler syntax.

Wow !
Works perfectly.
This was the fastest support ever !

Many thanks !

Unfortunately, dashboard still doesn’t allow for anything above 0.4.1 :frowning:

1 Like

@smnnekho, yes, System_Threading is enabled (and needs to be for the use-case - need to operate whether or not the device is connected to Particle Cloud).

Glad to see that I am not the only one…

Just noticed 0.4.7 seems to have broken multithreading for me. It’s obvious in my case because I have an OLED display that usually initialises while the connection is taking place. Since 0.4.7 it doesn’t turn on until the connection with the cloud is established, leading me to think that multithreading might not be working at all…

Just checked this by reverting to the ‘latest’ branch (as in 0.4.6) and building again with the same source - multithreading working again. This is on a P1. Perhaps related to the issue you’re having @UMD?

G65434_2, @smnnekho, RE:

Reverted to firmware 0.4.6 and compiled against that. Same code, same problem… So, not a regression with 0.4.7 (good!). My issue is now off topic, I will raise another ticket.

Forgive me for the silly question, I’m new to low-level programming in C. I was just wondering how the new software timers compare to something like SparkIntervalTimer and what the technical and practical differences are?

@G65434_2, @smnnekho Case closed on the variable/function registration issue:

By the way, 0.4.7 is great, but we all know that!

@TheKiwi, SparkIntervalTimer uses hardware timers which fire an interrupts that call a user ISR. Using hardware interrupts allows precise timing at the cost of using hardware resources, some of which may impact I/O pin functions related to those resources (eg. PWM or Tone). They also allow a user to create sub-millisecond interrupts.

Software Timers are provided by the FreeRTOS kernel and have a minimum resolution of 1 milliseconds. However, they don’t user hardware resources, you can have up to 10 at a time and they are quite precise. For many timing requirements, these timers are great and remove the need to use millis() type timers in loop(), whose accuracy may be affected by delays within loop().

Like hardware interrupts, Software Timer callback functions should be non-blocking and short. Hope that helps! :smile:


Release 0.4.9 is just around the corner, ready for deployment on Monday. Anyone that’s interested in testing the current release candidate via the local toolchain are invited to pull tag v0.4.9-rc.2 from our firmware github repo.