And then I need to modify that file manually each time change to project happens, or write another script…
I could place .ini file with in root folder and then use one workspace, but not being able to define custom build directories will not let me have use from that that anyway
Yes, it’s a drawback of Microsoft VisualStudio Code to not let one .vscode/c_cpp_properties.json be applicable to all opened workspaces. But thata’s how their program works.
Yeah its clear, but is there any way to work with source codes in folders others than src if I move platformio.ini to the root directory ?
If your sources aren’t in the workspace it should work if you follow the header files (ctrl-click) and then in the filepath at the top of the Window switch to the .c/.cpp implementation.
Otherwise on Linux /Mac you can easily symlink .vscode/c_cpp_properties.json to point to your one-and-only c_cpp_properties.json in the main project through ln -s. You can do the equivalent on Windows – I have however not tested that.
The foolproof way is to make VSCode happy by giving it the .vscode/c_cpp_properties in each workspace and updating it if you know the configuration changes (such as global defines). This doesn’t tend to happen a lot in my experience.
I’d like to follow up on the semi-hosting side of things. It may be slow, but it’s useful to be able to use this at times. It turns out to be easy with a Black Magic Probe, all that’s needed is an extra_script.py containing:
Import("env")
env.Append(LINKFLAGS=["--specs=rdimon.specs"])
Tried on a Blue Pill with code such as:
#include <stdio.h>
extern void initialise_monitor_handles (void);
int main (void) {
initialise_monitor_handles();
// printf, getch, fopen, whatever ...
}
Unfortunately, this line is not working, as simple replacement for the extra Python script:
build_flags = -Wl,--specs=rdimon.specs
This one-liner would be a convenient way to try out semi-hosting, when sometimes all you need is a super-simple way to get some printf info (to debug a serial port driver, for example).