• State Verified Answer
  • Replies 5 replies
  • Subscribers 64 subscribers
  • Views 225 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 324479
Options

Generation of .matter files from .zap files

mlampacher

Hi,

I am currently looking into setting up a Matter project (based on the template) and reached ZAP and the required files. As far as I understood, the ".zap" file is the only file that is actually needed, the corresponding ".matter" file is generated from the ".zap" file (as documented here: https://project-chip.github.io/connectedhomeip-doc/code_generation.html#ensure-you-have-a-matter-file).

My idea is to not even keep the generated files (e.g., not place them under version control) and instead generate all files from the ".zap" file. In the template, however, you're using "BYPASS_IDL" and as described in the example for adding a new cluster (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.0/nrf/protocols/matter/getting_started/adding_clusters.html) you're relying on pre-generated files.

My real question: Is it somehow possible to really generate all files during the build, or what is the reason why the samples use "BYPASS_IDL"?

I'm a bit dumbstruck by the Matter CMake integration, which actually uses the "generate.py" generator, but instead of first passing the ".zap" file, the function `chip_codegen` assumes that the ".matter" file already exists ... This integration could generate the ".matter" file during the build step but simply doesn't.

  • 0

    Hi,

    Due to the Easter holidays in Norway, we are less staffed than usual. You can expect an answer sometime next week,

    Sorry for the inconvenience and thanks for your patience. 

    Regards, 
    Amanda

  • 0 in reply to Amanda Hsieh

    I had a deeper look into ZAP and the generator scripts and I guess I came to the same conclusion as you did:

    • The CMake integration of the Matter project does not have any targets to generate the .matter file from the .zap file (yet).

    • The chip_codegen.cmake, however, assumes that a .matter file is used (with the same name as the .zap input file, except for the file type) as input for the generate.py script.

    • Therefore, it is anyhow always necessary to trigger the code generation either via ZAP's GUI or call generate.py elsewhere.

    • Thus the code generation provided by the CMake integration may as well be skipped altogether (it is also very rare to update the .zap file and virtually impossible to forget generating the files since otherwise nothing will work anyhow), also saving some compile/configuration time.

    I'm still a bit unsure why the Matter project uses a .matter file even though the same information is present in the .zap file, which for now is always present (and can be used with generate.py to generate the correct set of files, also shown in your documentation for adding a cluster to the example application).

    They mention in their codegen documentation that they "strive to make them contain only Matter-specific data" and that the "codegen.py" has less dependencies (but currently also doesn't generate the full set of required files (?)) and that linting of .matter files is possible.

    I guess it's still a lot of "work in progress". Due to the large amount of scripts and their awkward path handling (e.g., assuming either absolute paths or paths relative to the Matter root directory as parameters) this is currently still very confusing.

    They also mention that "Currently .matter files are generated from .zap files during the application specific codegen." but that is not true for the CMake integration - or at least I couldn't find a single step where the .matter file would be generated.

  • +1 in reply to mlampacher

    Hi, 

    what is the reason why the samples use "BYPASS_IDL"?

    We use "BYPAS_IDL" in CMakeList.txt files because we decided to use static device-related Matter Data Model configuration in our samples. What does it mean? In the Matter Upstream repository, all Data Model files are generated dynamically utilizing ZAP tool while building an application. There are common .zap files for all samples and they have enabled all possible options. This approach requires the newest ZAP tool frequently, so users need to take care of it. In NCS samples we bypassed those operations, and we generated all Data Model configurations to the zap_generated directory within each sample and in this way, users don't need to update ZAP within the same NCS revision, and also we removed many unnecessary options from samples .zapfiles, and thanks to that we reduced the code size. Moreover, after bypassing those Data Model files are not generated during the building anymore.

    mlampacher said:
    I couldn't find a single step where the .matter file would be generated.

    To generate Data Model files, they can follow the instructions from here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.6.0/nrf/protocols/matter/getting_started/adding_clusters.html#edit-clusters-using-the-zap-tool or use the following command to re-generate the .matter file only (from NCS main directory):

    ./modules/lib/matter/scripts/tools/zap/generate.py -o zap-gen-dir zap-file

    Where zap-gen-dir is the directory where .matter file will be stored into, and zap-file is the source .zapfile.Also it is worth mention, that they need to remove "zap" temporary directory to avoid many problems with zap tool":Please read the note under that section: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.6.0/nrf/protocols/matter/getting_started/adding_clusters.html#edit-clusters-using-the-zap-tool

    Regards,
    Amanda H.

  • 0 in reply to Amanda Hsieh

    Thanks for the explanation! Yeah, I've added a little CMake target to generate the `.matter` file, it's straight-forward enough. I just found it very confusing that this is not part of the `chip_configure_data_model` already.

    I'm very happy that Nordic integrated the `chip` project, that's huge, great work!

Related

core_v2_widget.Hide()