Request: add memory usage to Particle Dev

Hi There!
The Particle platform is growing fast and it’s reaching some level of maturity.
For any serious developer it would be a nightmare to build in the web, (backup, version
control, etc)
However by using the Particle Dev client you miss some basic information, like the
RAM and FLASH usage.

It will great to have the above information built into the Particle Dev client.
Thank you!

4 Likes

The IDEs are currently receiving a major overhaul and things should get better.

  • version control with Web IDE
  • uniform and easy library import for all IDEs
  • and much more
5 Likes

Are there any progress reports on these developments. Using Git etc is not something I’m wholly familiar with and something very basic along the lines of the Team Explorer in visual studio integrated right into both Particle IDE and the web one so users could pick and choose would be great.

Over the weekend I was seeing slightly odd behaviour from Particle IDE, if I made s small change in my code and then clicked flash, you’d get the little whirly animation that it was being compiled for the blink of an eye and then it would say completed. however the next stage where it should say “Flashing Device” never happened and I had to repeat the process multiple time until that message appeared and the device was updated. In the console the device was never sent an update so its not like it tried and failed but the Particle status page showed everything as operational.

Off topic entirely, I have an older unit that fails to flash perhaps 95% of the time, it seems to receive the update, flash starts, reports success, vanishes offline and then comes back online with the error “Update Timeout” now I assume that unit is dead but any ideas what might have killed it? It chats away and largely functions as normal otherwise.

There are other possible reasons for that too.
e.g. your installed code can make the OTA update trip in many ways - like starving the system thread of µC cycles.
The same can happen with your other devices.

Try putting your devices into Safe Mode to prevent that.
If your currently installed code uses multi threading and/or System.sleep() with interrupts you might need to reset twice before SM (at least that's sometimes required on my devices).

Hmm assuming your suggestion only applies to the quoted bit. I don’t think it is starved of cycles just a pretty standard average of some sensor readings, calculated every 15secs using Milli timers and uploaded and shoved out the serial port. No evil delay or sleep and the same code runs on on newer modules. I have accidentally managed to swamp the controller once though to get the same result, I think I had to change the System Mode to Semiautomatic and then do something pretty dumb to manage it tho. Otherwise as far as I understand it the system will free up some cycles at the top of every loop to run particle.process regardless of what I do inside loop();