zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.51k stars 6.44k forks source link

Matter(CHIP) support #45993

Closed ck-telecom closed 2 years ago

ck-telecom commented 2 years ago

Origin

Matter(CHIP) https://github.com/project-chip/connectedhomeip

Purpose

Matter(It don't matter) is an Application Layer Protocol for home IoT

Mode of integration

module?

Pull Request

Not yet

Description

For now to integrate to Zephyr based project is a little hard, user could only integrate Matter only add as External Project and it does not make sense of much flexible for configuration

What problem are you trying to solve? Hum... I don't know how to say

Why is this the right component to solve it (e.g., SQLite is small, easy to use, and has a very liberal license.)

Dependencies

Lower protocol such as Thread and etc

Revision

The latest version

License

SPDX identifier (https://spdx.org/licenses/) same with with Zephyr

carlescufi commented 2 years ago

@ck-telecom let me understand, you'd like Matter to be part of the Zephyr distribution by default by integrating it as a module upstream?

ck-telecom commented 2 years ago

Yes, But not sure, the build system is not same with Zephyr, I think it is worth talking about this topic.

Now the Matter(CHIP) only support nrfconnect, in some sense it is ONLY support nrf5x series with Zephyr

LuDuda commented 2 years ago

Hello @ck-telecom

Well, it is not true that Matter SDK only supports nRF5x series with Zephyr.

Matter SDK takes approach of the "main" repository, and apart of the Matter stack it contains also platforms integration. You can find three related to Zephyr platforms already:

  1. Zephyr platform- it implements generic functionalities for all Zephyr platforms e.g. BLE Host, Settings, Logging, Thread integration and so on.
  2. nRF Connect platform - it implements functionalities specific to nRF Connect SDK (i.e. nRF SoCs) e.g. NFC, DFU, Configuration management. This platform inherits from Zephyr platform and just adds and overrides some modules.
  3. Telink platform - it implements functionality specific to Telink platform. This platform also inherits from Zephyr platform and just adds and overrides some modules.

We've done some effort at the beginning to separate Zephyr platform from nRF specific functionality (nRF Connect), which was reused later on by Zephyr-based Telink platform.

ck-telecom commented 2 years ago

@LuDuda Thanks for your reply!

We've done some effort at the beginning to separate Zephyr platform from nRF specific functionality (nRF Connect), which was reused later on by Zephyr-based Telink platform.

I do think that your effort on the separate Zephyr platform coz I can not configure my /zephyr/module.yml file as the following, that only depends on zephyr platform:

name: connectedhomeip

build:
    cmake: config/zephyr/chip-module
    kconfig: config/zephyr/Kconfig
    depends:
    - openthread

after separate from zephyr, nrf connect and telink could import the basic zephyr configuration for their addtions and overrides

LuDuda commented 2 years ago

@ck-telecom thanks. Could you please elaborate more what are you trying to achieve and a little bit more about the issue? Are you referring to the fact that there is no CMakeLists.txt inside config/zephyr folder?

Currently, Zephyr platform is not a standalone platform, but allows for building Zephyr-based platforms like nRF Conenct or Telink. As for now we have no plans to change this behavior - but of course feel free to contribute.

ck-telecom commented 2 years ago
name: connectedhomeip

build:
    cmake-ext: Ture
    kconfig: config/zephyr/Kconfig
    depends:
    - openthread

I think if we integrate Matter(CHIP) to Zephyr as a module to upstream, and add ${ZEPHY_BASE}/modules/matter/CMakeLists.txt that like openthread, I am not sure the Matter upstream will support CMake build system because the CMakeLists.txt is a empty file

Damian-Nordic commented 2 years ago

@ck-telecom I think the best way to add support for standalone Zephyr platform in Matter is:

  1. Create a similar directory structure in MATTER-REPO/config/Zephyr as we have in MATTER-REPO/config/nrfconnect and MATTER-REPO/config/telink. Kconfig file for Zephyr already exists, but CMakeLists.txt is missing. Also, since Matter uses GN build system, a GN project definition for Zephyr is needed.
  2. Add missing files in src/platform/Zephyr, such as CHIPDeviceConfig.h or CHIPDevicePlatformConfig.h
  3. Review Matter's BUILD.gn and *.gni files. Verify that conditions such as chip_device_platform == "nrfconnect" don't need to be extended on other Zephyr platforms.
  4. Create a fork of the Matter repo in zephyrproject-rtos.
  5. On the fork, add zephyr/module.yml that uses CMakeLists.txt and Kconfig from MATTER-REPO/config/Zephyr/chip-module.

That way, the only conflict we will have between Zephyr's and nRF Connect's Matter fork will be the Zephyr module manifest.

ck-telecom commented 2 years ago

@Damian-Nordic Thanks for your tips!

I have started in my repo: https://github.com/ck-telecom/connectedhomeip/tree/zephyr_standalone Anyway, it is an extra module for zephyr.

ck-telecom commented 2 years ago

PR for Matter: https://github.com/project-chip/connectedhomeip/pull/19504 merged to upstream

ck-telecom commented 2 years ago

Create a fork of the Matter repo in zephyrproject-rtos.

@Damian-Nordic how about this?

Damian-Nordic commented 2 years ago

I guess we need someone with higher privileges. @carlescufi are you in charge of creating repos in zephyrproject-rtos?

carlescufi commented 2 years ago

I guess we need someone with higher privileges. @carlescufi are you in charge of creating repos in zephyrproject-rtos?

I don't think the TSC has approved this yet. Let me come back to you once we've raised it again.

carlescufi commented 2 years ago

@ck-telecom or @Damian-Nordic for the TSC to approve this we need additional details in the issue body (eg. clear statement about module and maintainership and also a PR showing how the integration would work.

github-actions[bot] commented 2 years ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.