Device OS 2.0.0-rc.4?

Lots of positives from my first try with OS 2.0.0-RC.4:
+++ WiFi (on Photon) now seems to behave correctly in all the scenarios tested so far

  • Application space usage has grown circa 1800 bytes over 1.4.4
  • Several warnings from the compiler for things that seem correct and legitimate

Not a very scientific evaluation - wondering what others have found?

Some example warnings? What seems legit often depends on subjective interpretation :wink:

I was rushing to post - here are the warnings from the compile - nextTime is declared as char nextTime[6];

-base.ino:19276:46: warning: '%02i' directive output may be truncated writing between 2 and 11 bytes into a region of size 6 [-Wformat-truncation=]
19276 |         snprintf(nextTime, sizeof(nextTime), "%02i:%02i", _hr, _min);
-base.ino:19276:46: note: directive argument in the range [-1073741839, 1073741843]
-base.ino:19276:46: note: directive argument in the range [-30, 30]
-base.ino:19276:17: note: 'snprintf' output between 6 and 16 bytes into a destination of size 6
19276 |         snprintf(nextTime, sizeof(nextTime), "%02i:%02i", _hr, _min);

Always welcome your insight on these matters.

I can add that I have now seen the memory usage for 2.0.0-RC.4 is slightly less than 1.4.4 - so that is another +ve.

These warnings are legit since the compiler doesn’t know that your _hr and _min will only ever be 0…23 and 0…59 respectively. It will go with the full range of the given data type and hence must assume you may end up losing “valuable” information when at least one of the values would require more than two digits.

Warnings are meant to flag potentially problematic regions for the programmer to make reconsider or just accept the warning.
IIRC, if one once to be very “pedantic” and get rid of all warnings you may even be able to tell the compiler to not flag this for a specific instruction since you know it’ll be fine.
But don’t ask me how it’s done with this version of GCC :wink:

1 Like

So there is nothing really I can do to silence these warnings - which are correct but ‘over protective’?

As I said, there are possibilities :wink:
This might work (or not - :man_shrugging:)

Having tried a few other apps I can see the warning ‘fine comb’ is going to be a feature!

I thought there might have been more feedback on experience with this OS??

@mstanley thanks for help on support ticket about an odd WiFi behaviour problem since OS after 0.8.0 - 2.0.0-rc.4 appears to have cured it, increased App Flash usage accepted if that is the cost.

Hey Will. I wanted to follow up on this thread to make a final note to close the loop.

Decreased flash space is going to be a consequence of upgrading to 2.0.0. from 1.4.4. Particle is looking to commit to a minimum flash space and RAM allocation in future releases. There’s no specific commitments I can call out at this time, but this is something we want to commit to to add a level of reassurance in future releases.

Thanks for following up. I have found a few issues since - they relate to the classic System.sleep() API which wasn’t working. I then migrated to Sleep2.0 and then found that the following doesn’t work:

ULTRA_LOW_POWER

SystemSleepWakeupReason wakeupReason() const;

SystemSleepResult result = System.sleep(config);
if (result.wakeupReason() == SystemSleepWakeupReason::BY_GPIO)

I am using WKP pin to wake because I need to wake from HIBERNATE on this rising.
I have therefore reverted to reading the WKP state instead.
Also, I need to test for the WKP pin being LOW and stable before calling System.sleep() otherwise it does not go to sleep correctly.

Just wondering whether a quick migration guide might be useful?

Hey Will!

Unless I’m mistaken, I believe you’ve already filed reports for these, correct? Engineering is handling these reports internally and I believe will be following up with your bug report source once deliverables or follow-up asks as they are available.