How to import header files in the zephyr\subsys\bluetooth\mesh\shell path in a project

zephyr\subsys\bluetooth\mesh

zephyr\subsys\bluetooth\mesh\shell

I need to use APIs for certain files in the path mentioned above. Currently, I can only copy the files I need to use to the project folder in order to import and call them. Can I directly call the source files in NCS by modifying cmake or other methods, without having to copy these files to the project folder every time?

Parents
  • You should not be needing to copy library files into your project, instead you should just include them in your prj.conf.

    For example, if you need shell extension in your project, you just need to add the below in your prj.conf and all the files are imported into your project to compile. You still need to add the header files in the files where you use the shell API.like #include <zephyr/bluetooth/mesh/shell.h>

    In prj.conf, you just add

    CONFIG_BT_MESH_SHELL=y

  • Actually, I encountered this problem in order to implement the Bluetooth mesh dfu function. Since the Bluetooth mesh dfu in NCS can only be completed through shell commands, I now need to write the APIs actually used in these shell commands into my project, so I need to add some header files in this path. I don't quite understand why NCS only provides the use of shell commands to complete Bluetooth mesh DFU, which is very unfriendly for developing Bluetooth mesh projects.

    I have completed the basic functions of Bluetooth mesh dfu and successfully tested it, but currently I need to copy all the files used to the project, which is too troublesome because ncs already has these files and I don't need to modify them

  • You don’t actually have to copy any of the Mesh‐shell code into your app—what you need to do is:


    In your application’s CMakeLists.txt (next to the usual find_package(Zephyr …)), add the Mesh subsystem and the Mesh‐shell directory to your include path:

    # assume you already have
    #   find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
    #   project(my_mesh_app)
    
    # add the top‐level mesh include dir (for public APIs)
    zephyr_include_directories(
      ${ZEPHYR_BASE}/subsys/bluetooth/mesh/include
    )
    # add the shell frontend headers
    zephyr_include_directories(
      ${ZEPHYR_BASE}/subsys/bluetooth/mesh/shell
    )
    With that in place you can do e.g.
    #include <bluetooth/mesh/dfu_srv.h>
    #include <bluetooth/mesh/dfu_cli.h>
    #include <mesh/shell/dfu.h> 
    Link against the Mesh libraries
    If you’ve enabled CONFIG_BT_MESH (and the DFU options) then the Mesh libraries will automatically be pulled in. Just make sure you’re calling the public DFU APIs—in most cases you should be able to do something like:
    extern struct bt_mesh_dfu_cli *dfu_cli;
    bt_mesh_dfu_cli_start_upgrade(dfu_cli, ...);
    

    rather than poking at the internal shell command source.

Reply
  • You don’t actually have to copy any of the Mesh‐shell code into your app—what you need to do is:


    In your application’s CMakeLists.txt (next to the usual find_package(Zephyr …)), add the Mesh subsystem and the Mesh‐shell directory to your include path:

    # assume you already have
    #   find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
    #   project(my_mesh_app)
    
    # add the top‐level mesh include dir (for public APIs)
    zephyr_include_directories(
      ${ZEPHYR_BASE}/subsys/bluetooth/mesh/include
    )
    # add the shell frontend headers
    zephyr_include_directories(
      ${ZEPHYR_BASE}/subsys/bluetooth/mesh/shell
    )
    With that in place you can do e.g.
    #include <bluetooth/mesh/dfu_srv.h>
    #include <bluetooth/mesh/dfu_cli.h>
    #include <mesh/shell/dfu.h> 
    Link against the Mesh libraries
    If you’ve enabled CONFIG_BT_MESH (and the DFU options) then the Mesh libraries will automatically be pulled in. Just make sure you’re calling the public DFU APIs—in most cases you should be able to do something like:
    extern struct bt_mesh_dfu_cli *dfu_cli;
    bt_mesh_dfu_cli_start_upgrade(dfu_cli, ...);
    

    rather than poking at the internal shell command source.

Children
No Data
Related