VREF_REFSEL_VDD_gc undefined in VS Code

[dpetican]

It still compiles properly though. I think this affects all the reference macros. I get a similar problem with things like ADC0.SAMPCTRL = 128 for instance

[SpenceKonde]

At the preprocessor level it is an undefined constant because preprocessor can't see names from enums. But it diesn't need to get resolved at that time soit;'sfine.

When it comes time to actually compile them, it can see the enums so everything works, that name is defined in the microchip-supplied io header files.

And I have no idea what you are talking about with "a similar problem with" what you claim, - I don[t understand how a similar problem could possibly come about with ADC0.SAMPCTRL = 128. That doesn't depend on anything in the core, it's purely from the io headers.

You appear to not have access to the io headers. This is a problem with your build environment using an outdated toolchain instead of the updated toolchain supplied by the core. Which is why we supply that with the core, per json file.

I don't know VSCode, but it sounds like a configuration issue there, not something we have control over.
This is the version of the toolchain we pull in:

          "name": "avr-gcc",
          "version": "7.3.0-atmel3.6.1-azduino4b",
          "systems": [
            {
              "size": "41351111",
              "checksum": "SHA-256:a0b8a6327a4ce0b2aee3e559a71ea0b61ccecc48e358ec5fac50ba10710981a0",
              "host": "i686-mingw32",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4b-i686-w64-mingw32.tar.bz2",
              "url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4b-i686-w64-mingw32.tar.bz2"
            },
            {
              "size": "37878659",
              "checksum": "SHA-256:23becaaf746e8cf3b23ebcd261bf52d5eebcc094c3500fe8d533f0911b870c60",
              "host": "aarch64-linux-gnu",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4a-aarch64-pc-linux-gnu.tar.bz2",
              "url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-aarch64-pc-linux-gnu.tar.bz2"
            },
            {
              "size": "34220996",
              "checksum": "SHA-256:dacef5c90b38e6728e2cd161a54133b008352ff6f6513e67ab71f3117331c758",
              "host": "arm-linux-gnueabihf",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4a-arm-linux-gnueabihf.tar.bz2",
              "url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-arm-linux-gnueabihf.tar.bz2"
            },
            {
              "size": "36887243",
              "checksum": "SHA-256:a3f4833034b5526a7375b20fed7031e5fd0ff6956703e7b4bcf48e914fb94d6c",
              "host": "i686-linux-gnu",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4a-i686-pc-linux-gnu.tar.bz2",
              "url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-i686-pc-linux-gnu.tar.bz2"
            },
            {
              "size": "37530243",
              "checksum": "SHA-256:61c9ad88f9e75664fc6b96350dd4b3f95946e1c6eeca2158504aecc515f475a3",
              "host": "x86_64-apple-darwin14",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4a-x86_64-apple-darwin14.tar.bz2",
              "url": "https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino4a-x86_64-apple-darwin14.tar.bz2"
            },
            {
              "size": "37412841",
              "checksum": "SHA-256:60d879e7052db01383cd89c54e46fa20c81ca180e20a8c0a681ffecec20c24d8",
              "host": "x86_64-linux-gnu",
              "archiveFileName": "avr-gcc-7.3.0-atmel3.6.1-azduino4a-x86_64-pc-linux-gnu.tar.bz2",
              "url": "https://github.com/SpenceKonde/DxCore/releases/download/1.3.4/avr-gcc-7.3.0-atmel3.6.1-azduino4a-x86_64-pc-linux-gnu.tar.bz2"
            }
          ]
        }

[SpenceKonde]

(and yes, i know that many of those show as azduino4a - only windows version of 4a was bad.

[dpetican]

The problem is as you said that the io.h or some file is not being read when VS Code is linting (correct term?) but at compile time everything resolves okay. Without being able to resolve the define, autocompletion does not work and it appears there are errors where none actually exists. To be fair I've had similar issues with standard cores like the Mega2560 so its likely a problem in VS Code's Intellisense feature or the Arduino extension.

Including the file avr/ioavr128db28.h makes the errors go away in the editor but the compile fails with this error:

c:\users\admin\appdata\local\arduino15\packages\dxcore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino4b\avr\include\avr\ioavr128db28.h:38:4: error: #error "Attempt to include more than one <avr/ioXXX.h> file."
 #  error "Attempt to include more than one <avr/ioXXX.h> file."

So that got me thinking about VS Code's Arduino extension. When you initialize a project it creates a file called c_cpp_properties.json This is the relevant section:

            "name": "Arduino",
            "compilerPath": "C:\\Users\\admin\\AppData\\Local\\Arduino15\\packages\\DxCore\\tools\\avr-gcc\\7.3.0-atmel3.6.1-azduino4b\\bin\\avr-g++",
            "compilerArgs": [
                "-w",
                "-std=gnu++11",
                "-fpermissive",
                "-fno-exceptions",
                "-ffunction-sections",
                "-fdata-sections",
                "-fno-threadsafe-statics",
                "-Wno-error=narrowing"
            ],
            "intelliSenseMode": "gcc-x64",
            "includePath": [
                "C:\\Users\\admin\\AppData\\Local\\Arduino15\\packages\\DxCore\\hardware\\megaavr\\1.3.6\\cores\\dxcore\\api\\deprecated",
                "C:\\Users\\admin\\AppData\\Local\\Arduino15\\packages\\DxCore\\hardware\\megaavr\\1.3.6\\cores\\dxcore",
                "C:\\Users\\admin\\AppData\\Local\\Arduino15\\packages\\DxCore\\hardware\\megaavr\\1.3.6\\variants\\28pin-standard",
                "C:\\Users\\admin\\Documents\\Arduino\\libraries\\BlockNot\\src",
                "C:\\Users\\admin\\Documents\\Arduino\\libraries\\ArduinoJson\\src",
                "C:\\Users\\admin\\Documents\\Arduino\\libraries\\Adafruit_MCP23017_Arduino_Library",
                "C:\\Users\\admin\\AppData\\Local\\Arduino15\\packages\\DxCore\\hardware\\megaavr\\1.3.6\\libraries\\Wire\\src",
                "c:\\users\\admin\\appdata\\local\\arduino15\\packages\\dxcore\\tools\\avr-gcc\\7.3.0-atmel3.6.1-azduino4b\\lib\\gcc\\avr\\7.3.0\\include",
                "c:\\users\\admin\\appdata\\local\\arduino15\\packages\\dxcore\\tools\\avr-gcc\\7.3.0-atmel3.6.1-azduino4b\\lib\\gcc\\avr\\7.3.0\\include-fixed",
                "c:\\users\\admin\\appdata\\local\\arduino15\\packages\\dxcore\\tools\\avr-gcc\\7.3.0-atmel3.6.1-azduino4b\\avr\\include"
            ],
            "forcedInclude": [
                "C:\\Users\\admin\\AppData\\Local\\Arduino15\\packages\\DxCore\\hardware\\megaavr\\1.3.6\\cores\\dxcore\\Arduino.h"
            ],

But I can't force include ioavr128db28.h because the c_cpp_properties.json file gets rebuilt every time I compile. I used to be able to hand edit this file and have the changes stick in earlier versions, but alas that appears to not be the case anymore. Please leave this issue open. When I have time I will raise this with the VS Code Arduino extension team. Before I can be more helpful with this I need to learn how VS Code knows what information to put in the json file when initializing a project.

[SpenceKonde]

Thething is that the Arduino.h file itself should be core_devices.h which should be pulling in avr/io.h, which in turn should be o pulling in the right io header and it sounds luike it does for compiling, but isnt fully resolving them for linting >.< this seemsto be a VS code issue that I can't be particularly helpful The IO headers were meant to be pulled in by including io.h and then from there it sorts out what file to include.\

[SpenceKonde]

Does not appear to be a defect in the core but in VScode. Moved to discussions because not an action item for core

[SpenceKonde]

Oh - read this again, and though - maybe this is related to the fact that the preprocessor can't see the _gc constants?
Unlike the rest of the io-header defined constants, they are not #defines but members of an enum.

The preprocessor can only see things that are #defined. (you can't use them to test whether a variable exists either).

But that's fine, they are substituted in as text, find/replace style, and during the actual compile process, they are defined and all is well.

The fact that you can't do #if defined(PERIPHERAL_OPTION_SETTING_gc) is very annoying; there is no shortage of cases where that is exactly what you want to test in core libraries.