CC2652P: When will SDK support Matter?

Hi,

Our public SDK will support Matter when Matter spec/codebase is finalized. Before then, you can request an engineering SDK to work with our Matter example; please see this page's README for more details: https://github.com/project-chip/connectedhomeip/tree/master/examples/lock-app/cc13x2x7_26x2x7

To run Matter SoC, a 704K device is required (e.g. CC2652P7).

Aries Lord said:

I want CC2652P can running on DMM mode both Matter and Zigbee.

Can you clarify what you mean by this?
Do you mean Matter and Zigbee running at the same time on the same device?

• If yes, this is a more challenging question, since they both use 802.15.4 radio. (Notice that our existing DMM examples use two protocol stacks of different radio technologies (e.g. BLE + Zigbee, BLE + 15.4, BLE + proprf)).

Thanks,
Toby

Yes, I want Matter and Zigbee running at the same time on the same device. There is some mistake in my remembering that one of mode is Zigbee+Thread

I suspect TI or other Zigbee/Thread solution vendor would provide such stack and example. Since both Zigbee and Matter/Thread use 802.15.4, I personally do not see big benefit to run them at the same time on the same device.

Last day, ZigBee Alliance (CSA Alliance) China had published a video-lesson introducing that in future there will be Home Automatic Gateway supporting both ZigBee and Matter

Maybe that is two radio chips running at the same time on the gateway. I don't mean to say it's not possible or feasible to running Zigbee and Matter/Thread at the same time on the same device but it seems not reasonable to me personally.

By the way, I am interested in this video-lesson introducing that in future there will be Home Automatic Gateway supporting both ZigBee and Matter. Maybe you can provide the link for us to have a look.

there is  video-lesson: https://msu.h5.xeknow.com/s/2h4T30 

It pops the following QR code and cannot access it. Anyway, it's OK.

It needs login with your WeChart ID.

That's the problem since I don't use WeChat.

Thanks for the discussion here!

Yes, a gateway/bridge between Matter and Zigbee would make the most sense.
Most gateways have some kind of host + radio architecture. For example, Thread has Thread border router (ot-br-posix), which consists of linux host + Thread RCP, Zigbee has linux host + ZNP, 15.4 stack linux gateway has linux processor + 15.4 coprocessor.

As YK mentioned, perhaps a two radio solution could work. We will need to see how the Matter group addresses this.

If Matter and ZigBee can run at same MAC-layer and same Channel, only one radio is needed

On linux host + ZNP, the linux host have to process ZCL protocol. I think it is better that zigbee-soc can help Linux host to process some ZCL protocol, such as Read-Attribute, Write-Attribute. The linux host only needs to tell coordinate what attributes are wanted by UART.

Aries Lord said:

If Matter and ZigBee can run at same MAC-layer and same Channel, only one radio is needed

Yes, that is the challenge. Matter is using openthread, which has its own MAC functions: https://github.com/openthread/openthread/tree/main/src/core/mac

But for Zigbee, Z-Stack is using TI 15.4 MAC.

Aries Lord said:

On linux host + ZNP, the linux host have to process ZCL protocol. I think it is better that zigbee-soc can help Linux host to process some ZCL protocol, such as Read-Attribute, Write-Attribute. The linux host only needs to tell coordinate what attributes are wanted by UART.

Sure, there are different ways to distribute the Zigbee protocol between host and radio. But my thought is that for ZNP, it should run network layer only, so probably all the ZCL should be on host. The host would probably be more resource-rich than the ZNP.

What are the difference between TI 15.4 MAC and Openthread MAC?

I suppose TI 15.4 MAC is provided by TI and Openthread MAC is provided by Google/Nest.

Are they same functioning with differend code?

They should be.

As I know, there is a OS called Contiki has functioned 6-lowpan and zigbee, but its MAC is not conformance IEEE802.15.4. It has developed a new low-power mode named "RDC" instead of IEEE802.15.4's Data-poll

Yes, I know Contiki and it's another story...

I think TI should develop a Matter Stack base on TI 154 MAC, or develop new Zigbee stack base on Google/Nest MAC. 

Actually, Matter is application protocol and it's Openthread or Thread Stack would use 15.4 MAC. In the beginning, I remember TI has its own Thread MAC but it's OpenThread now. As I know, most of solution vendors use their own 15.4 MAC for Zigbee solution but use Google/Nest MAC for Openthread.

I have researched Thread MAC of CC2652. Both TI 154 MAC and Thread MAC are calling same interface to access CC2652's hardwar. The CC2652's RF core has processed CSMA/CA, retrying send, Ack pending. So they are same function, one of them can be instead.

Sure they can  be replaced but this depends on TI policy…

I'm afraid of that TI has no enough employee to develop Matter base on TI 154 Stack. My friend has told me that Z-stack for CC26x2 is developed by Ubiqua team, and TI has absented ZigBee 3.0's formulating meeting.

I cannot comment on TI internal things. There are other alternatives if you are not satisfied with TI solution.

I glad to join to this project that make Zigbee and Matter to run at same MAC. But there needs a man to start this project.