PIO new project missing basic intellisense setup

I’m using the latest version of VS Code and PlatformIO (as of today), and installed 3 extensions: C/C++ (Intellisense, debugging, code browsing), Arduino, PlatformIO IDE. Within PlatformIO, I’ve also installed a couple of library extensions.

When I create a new project through PIO and select a board, it seems to do everything correctly. However, when I add an include file from one of the libraries downloaded via the library manager, Intellisense stops working and I get the green squiggly line.

Ok, so I read through the forums and found the fix, to add the library manager’s download path to c_cpp_properties.json under includePath and browse.path. I did that and initially it still didn’t work - I had to restart VS Code to get it to pick up the changes.


  1. when changing c_cpp_properties.json, can there be a “rebuild/rescan” button to avoid having to restart VS Code?
  2. why do we even need to do this step in the first place, and for every project I may add? since one of the main points of PIO is to manage and integrate the libraries, it seems very odd that at the very least browse.path doesn’t include the library manager’s download path by default, I would think this is a given that it should be a basic feature of setting up a project.
    I know that includePath is exact (not recursive) paths, however, I did put only the base .platformio/lib path in includePath and upon restart, VS Code or PIO automatically expanded that into all the resolved paths under lib, which is what I would expect it to do when building a new project (besides adding the BSP paths).

Is this a feature that can be added?

I’ve read that the Arduino extension often conflicts with PIO…

Already present, see “Rebuild Intellisense Index” target.

1 Like

I found the rebuild option, thanks for that.

Still, it doesn’t make sense that this feature isn’t in a new project by default.

Does you see this library in the Dependency Graph? If yes, it should be in c_cpp_properties.json too. What is your platformio.ini?

1 Like

Are you editing .cpp or .ino files? As the .ino files and Arduino extension don’t play well with PlatformIO, and in fact the Arduino extention is not needed to work with Arudino projects ported to standard C++ and PlatformIO.

I’m not using Arduino at all and I’ve uninstalled the extension. I’m only working with cpp files in platformio created projects.

There’s nothing in my platformio.ini file other than the basic few lines the project setup adds for the board type. The dependency graph is correct and shows the libs that are included.

The issue is that the new libs that were added to and resolved by the project (via #include statement) don’t automatically get added to c_cpp_properties. It works fine if I add them myself, and I’m just noting that this wouldn’t be an issue if out of the box the project setup includes the libs folder under the tag parser browse.path - that way nothing would need to be added manually.

So are you not specifying in your platformio.ini which libraries your project is dependent on?


platform = atmelavr
board = nanoatmega328
framework = arduino
lib_deps = 
  Adafruit Unified Sensor
  DHT sensor library

Which then a) means you don’t install libraries globally, b) letting platformio manage them on a project by project basis, c) allowing you to version control of libraries where needed or d) letting platformio work out dependencies. This you still need all your #include <whatevers>, but platformio goes and fetches any libraries needed/missing at the start of each build.

It’s the libraries listed in lib_deps that get added to the c_cpp_properties include path…


that’s right, I’m not directly specifying libs through lib_deps, instead PIO is auto-discovering libs to be linked by scanning the libs folder based on the #include statement. And the reason that I didn’t use that is because the docs aren’t very clear on how to set this up, they just say to add the lib name without explaining where to get the lib name from. For example, I didn’t know that “Adafruit Unified Sensor” was the actual lib name that was supposed to go there (I figured it would have underscores instead of spaces). Now that you’ve given this working example, I can see that the name that needs to go in this list is the value specified by library.properties:name= ; as a newer user to PIO, I think the doc should state this explicitly for the lib_deps section.

So, since I didn’t get that to work initially I instead used the auto resolving feature. But I don’t understand your commend about not installing libraries globally, how would I not? I did use the library manager to install libs so that they’re available to all projects. Also, are you saying with lib_deps set up correctly, it’s not necessary to use #include to add those libs to the project?

Have at a look at the PlatformIO Registry for libraries, and at the installation tab for examples of how to install / include them in your platformio.ini. e.g. the Adafruit GFX Library

When you use lib_deps, libraries are not installed globally, they are installed into the .piolibdeps folder alongside the code for your project. Hence different projects can have different versions of libraries, are self contained, and there will not be any conflicts.

You still needs to use #includes. The PlatformIO library management handles installation or updating of libraries and frameworks as needed.

Cool, thanks for the tip, I see how it works now.

1 Like