• State Suggested Answer
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 94 subscribers
  • Views 3438 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 338073
Options

Correct place to set Kconfig parameter CONFIG_GPIO=y using nRF Connect SDK v2.9.0?

Ken58

Hi,

What file or files should contain CONFIG_GPIO=y for a simple application developed with nRF Connect SDK v2.9.0 such that VS Code does not show squiggles under #include <zephyr/drivers/gpio.h>  indicating error:  The GPIO drivers must be enabled by CONFIG_GPIO to be included in build (missing_kconfig_param).

I have a similar problem with CONFIG_PWM.  I have tried setting it in prj.conf and also my custom_board_defconfig file without solving the problem.

Thanks,

Ken

Parents
  • 0

    This is because this whole ecosystem is full of abstraction rot AFAICT. You'll note in the build messages that the compiler isn't complaining, rather the applet in VS Code that Nordic supplies is complaining, but the applet is confused because this appears to be like the third time all of the abstraction models changed between VS Code, NRF Connect, and ARM gcc. It's really sad how poor all of this is and how often you click the link for help and it flits off to the Nordic web site which says "content doesn't exist or has moved." I mean really? Instead of saving me any time at all, this stuff has be extracting by hand the various bits of source code for zephyr, the nfrx drivers, etc. Building makefiles that gmake understands and creating a sane build environment that works reliably. This has reduced my "SDK" work to, download the SDK, pull it apart, run a script to find if there are any files in the SDK that haven't been moved over to the build tree, and for every file that is already there check to see if there are any changes. Sigh.

Reply
  • 0

    This is because this whole ecosystem is full of abstraction rot AFAICT. You'll note in the build messages that the compiler isn't complaining, rather the applet in VS Code that Nordic supplies is complaining, but the applet is confused because this appears to be like the third time all of the abstraction models changed between VS Code, NRF Connect, and ARM gcc. It's really sad how poor all of this is and how often you click the link for help and it flits off to the Nordic web site which says "content doesn't exist or has moved." I mean really? Instead of saving me any time at all, this stuff has be extracting by hand the various bits of source code for zephyr, the nfrx drivers, etc. Building makefiles that gmake understands and creating a sane build environment that works reliably. This has reduced my "SDK" work to, download the SDK, pull it apart, run a script to find if there are any files in the SDK that haven't been moved over to the build tree, and for every file that is already there check to see if there are any changes. Sigh.

Children
No Data
Related
Terms of service