https://twitter.com/PlatformIO_Org/status/1169695100810813443
3 Likes
More developers using it and contributing to the ecosystem! One PlatformIO to rule them all! 
2 Likes
Not by any means a dealbreaker for me, but the stability of the VSCode extension during startup could be improved. Often, when PIO is enabled, the VSCode extension host randomly crashes. Upon restarting it from the balloon notification that pops up, it usually starts working normally.
I don’t have a screenshot or anything atm, but if you tell me what you would need from me, I’d be more than happy to report back when it inevitably happens again.
1 Like
How to reproduce it? If disable PlatformIO extension, does VSCode extension work normally? Our extension is very simple and light-weight. It just wraps PlatformIO Core CLI functionality. It seems that other extensions are not stable or C/C++ extension.
If you can provide some logs, I would be thankful. Please report them to Issues · platformio/platformio-vscode-ide · GitHub.
1 Like
Yes, disabling the PIO extension will in my experience prevent the extension host from ever crashing. I share your confusion, however I refute that it’s a light one in comparison to other common VSCode extensions like C/C++, Python, etc. It’s load time is ~ and order of magnitude slower than most others on my i5-8250u and SATA SSD machine.
I’m not familiar with where PIO dumps its logs. Could you point me to where in the ~/.platformio folder the logs you would be looking for are? Like I said, I’d be more than happy to oblige.
Do you see any errors in VSCode > Help > Developer tools > Console?
1 Like
How about memory profiling? If you could get some way of profiling memory usage, diagnosing memory leaks, etc on different microcontrollers that would be a killer feature.
I think you maybe could do this using the debugger. Something like for each platform/framework you define the memory functions, in the background set breakpoints on those functions, store relevant details on entry/exit, and stick a pretty GUI on top.
1 Like
This is what the latest release already gives you in the form of running a static code analyser (cppcheck) (link).
Depending on the framework this is entirely possible already. For example, mbed-os already has heap memory tracing (hooked free() and malloc() and stored alloc/dealloc metadata in a table, really not black magic) and stack usage tracing for the all the threads.
Though static analysers are pretty powerful, a dynamic approach, as you would e.g. do with valgrind on Unix like systems, would be nice for embedded systems. Based on how valgrind works this tool is basically impossible to run on a microcontroller without very significant modifications.
1 Like
Thanks for pointing out pio check I had missed that, definitely a good start.
I agree there is some support for dynamic memory profiling in specific platforms, I have recently been looking at the ESP32 IDF myself, but the power of platform IO is that it hides all the platform specific stuff and just works. I think that would be a great addition if all the platform/framework stuff could be wrapped up and it would just work.
Oh my… I’m not running the dev branch just atm, so that’ll be nice to try once 4.1 is released. 
Any analysers or code checker is handy… like shellcheck for linux shell scripts… spots some of the silly errors you make before they blow up your face! 
1 Like