This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

External modules with Visual Studio Code extension

Hello! I'm trying to use an external module with the VSC extension and I don't think that is currently supported (or easily supported.) For reference, our module works with NCS via West: https://github.com/golioth/zephyr-sdk.

As a general feature request, it would be great if there was a way to add a module to an existing application as well as create a new app from a sample within a module. Here's some of the issues I ran into:

  • Creating an app from samples only looks for samples in specific folders. Our module has its own sample folder (which I think is the convention) but during the import process it was discovered or I wasn't able to point to a sample manually.
  • I would expect a flow to add external modules via UI in both freestanding and workspace flows. At least in workspace there is a west.yaml that we could manually modify.
  • The build configurator parses the sample.yaml for available boards. Ours lists a a few but we have a lot more listed .conf files in a boards folder, which I believe is a convention. Since the extension doesn't scan that folder or allow to manually point to a .conf, I can't create a build configuration

I think fixing these issues would enable anyone, not just Golioth! So here's my collection of feature requests:

  • Add UI flow to include an external module
  • Add wizard to create a new project (enhancement, in addition to the import application option)
  • Add ability to import sample for a specific location and/or add setting to tell the extension where to look for samples
  • Add ability to point to board .conf file and/or scan boards folder

Thank you for the great extension and hope this feedback is useful! We'd love to make it possible for our users to start using the extension!

Parents
  • Hi ,

    Thank you for your feedback!

    Ad1:

    You are correct that the extension looks for samples in specific folders. The convention is to look in <toplevel>/applications or <toplevel>/samples folder. This is a convention for extra modules in NCS such as homekit/find-my. This means that if you modify the west.yml to put your SDK in the top level, i.e., remove the path:

        # Golioth repository.
        - name: golioth
          # path: modules/lib/golioth
          revision: main
          url: https://github.com/golioth/zephyr-sdk.git

    the samples will be picked up and build fine:

    Note that there is a distinct difference between 'Creating a new application' and 'Adding existing one'. Creating a new application means that the sample is copied from the SDK to the destination folder as a freestanding (out-of-tree) application. Importing application means that you add an existing application (such as sample in the SDK) into the vscode workspace and application list.

    Ad2:

    Modules are a west concept and what you did, i.e, modify the west.yml file to add the module is the correct approach. A freestanding application needs a west workspace to build, in this case that is the NCS workspace initialized by the toolchain manager, that you need to modify in order to pull in the extra module.

    Note that our current design approach is to help users with understanding modifications needed rather than offer a UI. This means that we will more likely introduce IntelliSense or code snippets for handling west manifest modifications that a UI.

    We're close to releasing an update to the extension that has basic support for west operations with west init being one of them. This means that you should be able to init Golioth SDK right from the extension.

    Ad3:

    You are correct the extension parses the samples.yaml file to determine compatible boards. This is to align with the concept that the board listed in 'Compatible' category is being tested by the CI thus gives some reassurance that the example will work. It's up to sample maintainers to ensure that. However, it is untrue that you cannot build for the a board that is not indicated in this file. Simply select 'All boards' radio button and find the desired board. Any extra configuration you have in boards folder will be applied by zephyr build system correctly.

    Please let us know if this helps.

    Kind regards,

    Wojtek

    VSC Team

Reply
  • Hi ,

    Thank you for your feedback!

    Ad1:

    You are correct that the extension looks for samples in specific folders. The convention is to look in <toplevel>/applications or <toplevel>/samples folder. This is a convention for extra modules in NCS such as homekit/find-my. This means that if you modify the west.yml to put your SDK in the top level, i.e., remove the path:

        # Golioth repository.
        - name: golioth
          # path: modules/lib/golioth
          revision: main
          url: https://github.com/golioth/zephyr-sdk.git

    the samples will be picked up and build fine:

    Note that there is a distinct difference between 'Creating a new application' and 'Adding existing one'. Creating a new application means that the sample is copied from the SDK to the destination folder as a freestanding (out-of-tree) application. Importing application means that you add an existing application (such as sample in the SDK) into the vscode workspace and application list.

    Ad2:

    Modules are a west concept and what you did, i.e, modify the west.yml file to add the module is the correct approach. A freestanding application needs a west workspace to build, in this case that is the NCS workspace initialized by the toolchain manager, that you need to modify in order to pull in the extra module.

    Note that our current design approach is to help users with understanding modifications needed rather than offer a UI. This means that we will more likely introduce IntelliSense or code snippets for handling west manifest modifications that a UI.

    We're close to releasing an update to the extension that has basic support for west operations with west init being one of them. This means that you should be able to init Golioth SDK right from the extension.

    Ad3:

    You are correct the extension parses the samples.yaml file to determine compatible boards. This is to align with the concept that the board listed in 'Compatible' category is being tested by the CI thus gives some reassurance that the example will work. It's up to sample maintainers to ensure that. However, it is untrue that you cannot build for the a board that is not indicated in this file. Simply select 'All boards' radio button and find the desired board. Any extra configuration you have in boards folder will be applied by zephyr build system correctly.

    Please let us know if this helps.

    Kind regards,

    Wojtek

    VSC Team

Children
No Data
Related