Add zephyr modules which are not part of name-allowlist in NCS manifest, in a custom project

I have custom project, which utilizes manifest file to fetch nRF Connect SDK. I need to add tflite-micro module to my project, which is present in zephyr.

After some research, I found out that NCS manifest file does not import tflite-micro. NCS includes the optional group from zephyr (in which the tflite-micro module can be found), but in the name-allowlist in the NCS manifest file, tflite-micro is not present.

Currently, I see only two options to add tflite-micro support to my project:

1. In my main manifest file - add the tflite-micro module as in the optional submanifest in zephyr. This approach requires to find the exact commit hash from the corresponding zephyr version used in NCS, which is not ideal. In fact, I've tried this with NCS v2.6.2 and the hello-world sample from tflite-micro is working. For reference, this is the fragment of my project manifest file that adds tflite-micro module (extracted from https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1-2/submanifests/optional.yaml, which is used in NCS v2.6.2):

- name: tflite-micro
  revision: 1a34dcab41e7e0e667db72d6a40999c1ec9c510c
  path: modules/lib/tflite-micro
  remote: zephyr

2. Make a fork of NCS and edit its manifest file to include tflite-micro in the name-allowlist section for the zephyr project. This approach requires me to maintain my fork with the NCS changes in future, for a very small patch of the manifest file.

I am wondering if there is another solution, perhaps cleaner one, to add zephyr modules not found in name-allowlist in NCS manifest?

Or maybe there is a completely different way that I am missing.

Thank you in advance.

Parents
  • Hello,

    Adding the tflite-micro project to the name-allowlist in nrf/west.yml is a solution which is a decent fit when you are developing a project with a set nRF Connect SDK version.

    There is another option to enable a project in your west workspace: using west config manifest.project-filter. This is a suitable option when you don't want to edit the west.yml file directly. See the description for the west config option in the table of Built-in Configuration Options and an example for use in the Zephyr TF Lite Hello World sample documentation. By default the changes you do with west config are saved to .west/.config in the active west workspace. For nRF Connect SDK this is in the same directory as the nrf and zephyr directories. You can change the scope for west config by passing an applicable option to west config as described here.

    Best regards,

    Maria

Reply
  • Hello,

    Adding the tflite-micro project to the name-allowlist in nrf/west.yml is a solution which is a decent fit when you are developing a project with a set nRF Connect SDK version.

    There is another option to enable a project in your west workspace: using west config manifest.project-filter. This is a suitable option when you don't want to edit the west.yml file directly. See the description for the west config option in the table of Built-in Configuration Options and an example for use in the Zephyr TF Lite Hello World sample documentation. By default the changes you do with west config are saved to .west/.config in the active west workspace. For nRF Connect SDK this is in the same directory as the nrf and zephyr directories. You can change the scope for west config by passing an applicable option to west config as described here.

    Best regards,

    Maria

Children
  • Thank you for your reply, but I can't get the tflite-micro project in that way.

    I've tried running west config manifest.project-filter.tflite-micro in my workspace folder, which was added in .west/config file, but after running west update the tflite-micro library is not downloaded, and the sample hello-world from tflite can't be built.

    In summary, I have custom project with the following manifest file (I've stripped some of the content of it, but it was not relevant to this discussion):

    manifest:
      remotes:
        - name: nordic
          url-base: https://github.com/nrfconnect
      projects:
        - name: sdk-nrf
          path: nrf
          remote: nordic
          revision: v2.6.2
          import: true
    

    And here is how my workspace tree looks like:

    .
    ├── .west
    ├── bootloader
    ├── my-project
        ├── ... other files
        └── west.yml  # main manifest file, provided above
    ├── modules
    ├── nrf
    ├── nrfxlib
    ├── test
    ├── tools
    └── zephyr

    I want to add tflite-micro module in my project. Note that I don't want to make a fork for a simple task of including a module from zephyr which is ignored in sdk-nrf, I hope there is another way to include the tflite-micro module.

  • Hello,

    After some more digging around I found that adding the project name to the name-allowlist is the preferred way to add external projects to nRF Connect SDK. I had an unrelated issue when first testing out the project-filter method, but now that I can complete it I can see that it does not add the project to my nRF Connect SDK installation either.

    How does a west update work for your project at the moment? Will the nrf/west.yml be considered at all when updating? For my nRF Connect SDK v2.6.2 installation, the tflite-micro project is added to optional\modules\lib\tflite-micro after editing the nrf/west.yml to include tflite-micro in the name-allowlist. No fork is needed, but if I uninstall my v2.6.2 installation I need to edit nrf/west.yml again of course. In a project development workflow I assume that reinstallation or upgrading of the nRF Connect SDK is not a frequent task, so please enlighten me if it is an issue to edit nrf/west.yml locally and using west update to add tflite-micro to your installation.

    My apologies if this is not the reply you wanted. Your project setup is different from the usual setup, so it takes some time to understand how we can help.

    Best regards,

    Maria

  • Thank you for your reply.

    If I run `west update`, west will always try to use the revision for sdk-nrf which I specified in my project manifest (that is v2.6.2). It ignores my local changes to the nrf/west.yml, that's why I think forking the SDK is the only option to modify the nrf/west.yml, and then specify the fork in my project manifest. Otherwise, I am probably fine with editing the nRF Connect SDK manifest to add tflite-micro in name-allowlist.

    I am using T2 topology for my project.

  • Hello,

    My apologies for the delay.

    BojanSof said:
    I am using T2 topology for my project.

    Thank you for sharing this detail. I have now gotten to know the T2 star topology, and below is a possible solution.

    Modify my-project/west.yml like in this code snippet: 

    manifest:
      remotes:
        - name: nordic
          url-base: https://github.com/nrfconnect
      projects:
        - name: sdk-nrf
          path: nrf
          remote: nordic
          revision: v2.6.2
          import: true
        - name: zephyr
          remote: nordic
          repo-path: sdk-zephyr
          revision: v3.5.99-ncs1-2
          import:
            name-allowlist:
              - tflite-micro

    On a west update from the west workspace directory the tflite-micro repository will be fetched and placed in an 'optional' directory in the west directory.

    I have tried it with the nRF Connect SDK example application and verified that the repositories which are in the name-allowlist in nrf/west.yml are included as well as tflite-micro.

    If you upgrade to another nRF Connect SDK version in the future, please refer to nrf/west.yml or this table to find out which sdk-zephyr version corresponds to the nRF Connect SDK version.

    Best regards,

    Maria

  • Hello.

    Thank you for your reply. This solution, although it is working and I can use it, it is still similar in nature to the solution I am already using - it requires to manually check the zephyr version used in the NCS. Ideally, I was looking for more 'automated' version, to directly import module from zephyr, via the parent NCS, but it looks like it is not possible.

    Thank you for your help!

    Best regards,

    Bojan

Related