From 51da2ceb2e9613db492af5769b9c2cb3eb2eb208 Mon Sep 17 00:00:00 2001 From: Andrei Litvin Date: Wed, 13 Apr 2022 08:34:42 -1000 Subject: [PATCH] Attempt to skip code in misspell (#17335) * Attempt to skip code in misspell * Changed a readme.md containing odd words to see if filtering works * Escape a md file and try to ignore hyperlink content in spellcheck * More escaping for code in mbedos_commissioning.md * Add instructions for local spelling run * More updates to make spell checker happy * Cleanup some image logic in mbed unit test files * More updates for spelling - move code blocks into code blocks * More paths updates for lwip patch readme * Restyle * update for allow language in 3 backticks, replaced a lot of mbedos logo pictures * Code and image block updates on guides * Updating several nrf files for code blocks * update k32w android doc for code blocks * Code blocks for several readmes * Code blocks for some silabs and esp32 * Code blocks * More code blocks * More code blocks * More code blocks * More code blocks * More code blocks * Roll back some of the wordlist - this takes too long. Just fix some super obvious ones and have some code improvements * Restyle * Fix misplaced backtick --- .github/.wordlist.txt | 14 -- .spellcheck.yml | 41 ++++++ docs/api/device_runner.md | 4 +- docs/discussion/lwip_ipv6.md | 6 +- .../PID_allocation_for_example_apps.md | 44 +++---- docs/guides/BUILDING.md | 2 +- docs/guides/matter-repl.md | 4 +- docs/guides/mbedos_add_new_target.md | 4 +- docs/guides/mbedos_commissioning.md | 10 +- docs/guides/mbedos_platform_overview.md | 8 +- .../nrfconnect_android_commissioning.md | 8 +- docs/guides/nrfconnect_examples_cli.md | 6 +- .../nrfconnect_examples_configuration.md | 12 +- .../nrfconnect_examples_software_update.md | 70 +++++++--- docs/guides/nxp_imx8m_linux_examples.md | 112 +++++++++------- docs/guides/nxp_k32w_android_commissioning.md | 121 +++++++++++++----- docs/guides/openthread_rcp_nrf_dongle.md | 30 +++-- docs/guides/silabs_efr32_software_update.md | 24 +++- docs/guides/ti_platform_overview.md | 4 +- examples/all-clusters-app/ameba/README.md | 24 +++- examples/all-clusters-app/esp32/README.md | 62 ++++++++- examples/all-clusters-app/linux/README.md | 34 +++-- examples/all-clusters-app/mbed/README.md | 14 +- .../all-clusters-app/nrfconnect/README.md | 6 +- examples/all-clusters-app/p6/README.md | 30 ++++- examples/bridge-app/esp32/README.md | 34 ++++- examples/bridge-app/linux/README.md | 10 ++ examples/chip-tool/README.md | 56 +++++++- examples/common/pigweed/rpc_console/README.md | 13 ++ examples/ipv6only-app/esp32/README.md | 20 +++ .../lighting-app/bouffalolab/bl602/README.md | 14 +- examples/lighting-app/efr32/README.md | 58 +++++++-- examples/lighting-app/mbed/README.md | 20 ++- examples/lighting-app/nrfconnect/README.md | 46 ++++++- examples/lock-app/efr32/README.md | 50 +++++++- examples/lock-app/mbed/README.md | 4 +- examples/ota-provider-app/linux/README.md | 2 +- examples/ota-requestor-app/linux/README.md | 4 +- examples/ota-requestor-app/mbed/README.md | 4 +- examples/pigweed-app/mbed/README.md | 4 +- examples/shell/mbed/README.md | 4 +- .../images/chip-build-crosscompile/README.md | 2 +- src/README.md | 2 +- src/lwip/patches/README.md | 10 +- src/test_driver/efr32/README.md | 35 +++-- src/test_driver/esp32/README.md | 10 +- .../mbed/integration_tests/README.md | 4 +- src/test_driver/mbed/unit_tests/README.md | 16 ++- src/trace/README.md | 2 +- 49 files changed, 833 insertions(+), 285 deletions(-) diff --git a/.github/.wordlist.txt b/.github/.wordlist.txt index 97d375cd8e26f6..3eb6cef2f112c1 100644 --- a/.github/.wordlist.txt +++ b/.github/.wordlist.txt @@ -8,7 +8,6 @@ 21 22 AAAA -aabbccddeeff aarch abcdef abfb @@ -510,7 +509,6 @@ ffeebaefa FFF fffe fffff -fHtcwcAAAAAAAAAwQAAAAAAXPMlAAAAAAA Fi filepath fini @@ -1392,7 +1390,6 @@ xAAAA xab xaver xb -xBEEF xbef xc xcd @@ -1400,9 +1397,6 @@ Xcode xcodeproj xcworkspace xd -xDEAD -xDEADBEEF -xdeadbeefcafe xds xdsdfu xEA @@ -1420,15 +1414,8 @@ xFF xFFF xFFFF xfffff -xFFFFFFFD -xffffffffe -xfffffffff -xffffffffffff -xffffffffffffXXXX xtensa xwayland -XXXX -XXXXXXXX xyz xz xzvf @@ -1439,7 +1426,6 @@ YNJV Yocto yoctoproject YourFolder -yWsC zapt zaptool ZCL diff --git a/.spellcheck.yml b/.spellcheck.yml index a6c56411bcc5a6..225ab2ed951c8f 100644 --- a/.spellcheck.yml +++ b/.spellcheck.yml @@ -12,12 +12,53 @@ # See the License for the specific language governing permissions and # limitations under the License. +# To run locally: +# Prerequisits (only once): +# +# apt-get install aspell aspell-en +# pip install pyspelling +# +# Actual run: +# +# pyspelling pyspelling --config .spellcheck.yml + matrix: - name: markdown dictionary: wordlists: - .github/.wordlist.txt pipeline: + # See https://facelessuser.github.io/pyspelling/configuration/#pipeline + # and https://facelessuser.github.io/pyspelling/filters/context/ + + # context-aware logic: we have a LOT of code examples in markdown, + # avoid trying to spellcheck code. + - pyspelling.filters.context: + context_visible_first: true + escapes: \\[\\`~] + delimiters: + # Ignore multiline content between fences (fences can have 3 or more back ticks) + # ``` + # content + # ``` + # + # Allows language marker (since github allows it) like: + # ```python + # content + # ``` + - open: '(?s)^(?P *`{3,})[a-z]*$' + close: '^(?P=open)$' + # Ignore text between inline back ticks + - open: '(?P`+)' + close: '(?P=open)' + # Ignore URL in hyperlinks [title](url) + - open: '\[[^]]*\]\(' + close: '\)' + # Ignore code markers + - open: '' + close: '' + + # converts markdown to HTML - pyspelling.filters.markdown: sources: - '**/*.md|!third_party/**|!examples/common/**/repo/**' diff --git a/docs/api/device_runner.md b/docs/api/device_runner.md index 3b621eb8e70675..db9c5993eff6d8 100644 --- a/docs/api/device_runner.md +++ b/docs/api/device_runner.md @@ -99,5 +99,5 @@ enable reusing tests between different devices. The TSG is targeting the following platforms/boards for early bringup: - Nordic nRF52 board -- SiLabs XXXX board -- Espressif ESP32 XXXX board +- SiLabs `XXXX` board +- Espressif ESP32 `XXXX` board diff --git a/docs/discussion/lwip_ipv6.md b/docs/discussion/lwip_ipv6.md index adaabe5ddfcac2..674be43e227a16 100644 --- a/docs/discussion/lwip_ipv6.md +++ b/docs/discussion/lwip_ipv6.md @@ -27,8 +27,8 @@ addresses for communication to nodes on the same network (wifi or thread). When there is more than one netif in the system (ex. loopback, softAP, STA), the link local address needs more information to determine which link the address is local to. This is normally added as the link local scope and can be seen on -addresses ex. FE80::xxxx:xxxx:xxxx:xxxx%, where the identifies -the netif (something like %wlan0 or %eno1 etc.). +addresses ex. `FE80::xxxx:xxxx:xxxx:xxxx%`, where the identifies +the netif (something like `%wlan0` or `%eno1` etc.). Without this indicator, the link local address can only be resolved if there is one netif. LwIP will also allow a direct address match to the netif source @@ -122,7 +122,7 @@ Instead, it might be better to build this into the ICMP layer itself. LwIP's DNS handling isn’t great and breaks down when the router supports IPv4/IPv6. There is a single list of DNS servers, DHCP, SLAAC and DHCPv6 all update the list without locks. Basically, whatever wrote to the list last gets -to set the list. Although there is handling for IP type (requesting A or AAAA +to set the list. Although there is handling for IP type (requesting A or `AAAA` records), there isn’t handling to specify an IPv6 or IPv4 server specifically, which can be challenging since not all servers serve all record types. diff --git a/docs/examples/discussion/PID_allocation_for_example_apps.md b/docs/examples/discussion/PID_allocation_for_example_apps.md index 09960b31d25f87..18e71a20698964 100644 --- a/docs/examples/discussion/PID_allocation_for_example_apps.md +++ b/docs/examples/discussion/PID_allocation_for_example_apps.md @@ -3,34 +3,34 @@ Unless specifically overridden by the platform, example apps in this SDK use the Example credentials implementation in `DeviceAttestationCredsExample.cpp`. -The SDK holds example certificates for VID '0xFFF1' and any PID in -'0x8000-0x801F'. The device VID and PID supplied by the basic information +The SDK holds example certificates for VID `0xFFF1` and any PID in +`0x8000-0x801F`. The device VID and PID supplied by the basic information cluster must correspond to the VID/PID given in the certificate for the device to pass verification. Certificates are selected using the value in CHIP_DEVICE_CONFIG_DEVICE_PRODUCT_ID. The vendor ID for every example app is the -same because they are all signed by the same PAI (vendor id '0xFFF1'). +same because they are all signed by the same PAI (vendor id `0xFFF1`). In order to allow some differentiation between the various example apps, each app is assigned a PID from the list below: -| App | PID | -| ----------------------- | ------ | -| All Clusters | 0x8001 | -| Bridge | 0x8002 | -| Door Lock | 0x8003 | -| Light switch | 0x8004 | -| Lighting | 0x8005 | -| Lock | 0x8006 | -| OTA provider | 0x8007 | -| OTA requestor | 0x8008 | -| Persistent Storage | 0x8009 | -| Pigweed | 0x800B | -| Pump | 0x800A | -| Pump Controller | 0x8011 | -| Shell | 0x8012 | -| Temperature measurement | 0x800D | -| Thermostat | 0x800E | -| TV | 0x800F | -| Window | 0x8010 | +| App | PID | +| ----------------------- | -------- | +| All Clusters | `0x8001` | +| Bridge | `0x8002` | +| Door Lock | `0x8003` | +| Light switch | `0x8004` | +| Lighting | `0x8005` | +| Lock | `0x8006` | +| OTA provider | `0x8007` | +| OTA requestor | `0x8008` | +| Persistent Storage | `0x8009` | +| Pigweed | `0x800B` | +| Pump | `0x800A` | +| Pump Controller | `0x8011` | +| Shell | `0x8012` | +| Temperature measurement | `0x800D` | +| Thermostat | `0x800E` | +| TV | `0x800F` | +| Window | `0x8010` | diff --git a/docs/guides/BUILDING.md b/docs/guides/BUILDING.md index 5c700760de476e..94bc989484fcb8 100644 --- a/docs/guides/BUILDING.md +++ b/docs/guides/BUILDING.md @@ -182,7 +182,7 @@ To run all tests, run: ninja -C out/host check ``` -To run only the tests in src/inet/tests, you can run: +To run only the tests in `src/inet/tests`, you can run: ``` ninja -C out/host src/inet/tests:tests_run diff --git a/docs/guides/matter-repl.md b/docs/guides/matter-repl.md index 89655045887095..f5c9214d2c652b 100644 --- a/docs/guides/matter-repl.md +++ b/docs/guides/matter-repl.md @@ -149,9 +149,7 @@ cloud-hosted playground. The following icon is present at the top of applicable guides that can be launched into the playground: - -drawing - +![Launch playground icon](https://i.ibb.co/hR3yWsC/launch-playground.png")

## Guides diff --git a/docs/guides/mbedos_add_new_target.md b/docs/guides/mbedos_add_new_target.md index 92e38a8eb27ac6..07d34bb3705690 100644 --- a/docs/guides/mbedos_add_new_target.md +++ b/docs/guides/mbedos_add_new_target.md @@ -1,6 +1,4 @@ -

- ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png)

Mbed-OS add new hardware target

diff --git a/docs/guides/mbedos_commissioning.md b/docs/guides/mbedos_commissioning.md index 773960246dcf93..19e19d2a3d5dc6 100644 --- a/docs/guides/mbedos_commissioning.md +++ b/docs/guides/mbedos_commissioning.md @@ -1,6 +1,4 @@ -

- ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png)

Matter Arm Mbed OS provisioning guide

@@ -67,7 +65,9 @@ After building, install the application by completing the following steps: 1. Install the Android Debug Bridge (adb) package by running the following command: + ``` $ sudo apt install android-tools-adb + ``` 2. Enable **USB debugging** on your smartphone. See the [Configure on-device developer options](https://developer.android.com/studio/debug/dev-options) @@ -94,7 +94,9 @@ complete the following steps: accessory device. You can use **mbed-tools** for this purpose ([mbed-tools](https://github.com/ARMmbed/mbed-tools)): + ``` mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off + ``` To start the rendezvous, CHIPTool must get the commissioning information from the Matter device. The data payload is encoded within a QR code and is printed @@ -104,8 +106,10 @@ to the UART console. - Find a message similar to the following one in the application logs: + ``` [INFO][CHIP]: [SVR]Copy/paste the below URL in a browser to see the QR Code: [INFO][CHIP]: [SVR]https://dhrishi.github.io/connectedhomeip/qrcode.html?data=MT%3AYNJV7VSC00CMVH7SR00 + ``` - Open URL from the console to display the QR in a web browser. diff --git a/docs/guides/mbedos_platform_overview.md b/docs/guides/mbedos_platform_overview.md index 7252f992369422..95a1a3ee67f0c7 100644 --- a/docs/guides/mbedos_platform_overview.md +++ b/docs/guides/mbedos_platform_overview.md @@ -1,6 +1,4 @@ -

-ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png) # Mbed-OS platform overview @@ -11,9 +9,7 @@ Mbed-OS 6. The following diagram shows a simplified structure of a Matter application which runs on the top of the Mbed-OS. -

- matter_mbedos_overview_simplified -

+![matter_mbedos_overview_simplified](images/matter_mbedos_overview_simplified.png) # ARM Mbed-OS diff --git a/docs/guides/nrfconnect_android_commissioning.md b/docs/guides/nrfconnect_android_commissioning.md index b6260873b968d7..f24a12ddeb0394 100644 --- a/docs/guides/nrfconnect_android_commissioning.md +++ b/docs/guides/nrfconnect_android_commissioning.md @@ -111,7 +111,9 @@ After building, install the application by completing the following steps: 1. Install the Android Debug Bridge (adb) package by running the following command: - $ sudo apt install android-tools-adb + ``` + sudo apt install android-tools-adb + ``` 2. Enable **USB debugging** on the smartphone. See the [Configure on-device developer options](https://developer.android.com/studio/debug/dev-options) @@ -122,7 +124,9 @@ After building, install the application by completing the following steps: 5. Run the following command to install the application, with _chip-dir_ replaced with the path to the Matter source directory: - $ adb install -r chip-dir/src/android/CHIPTool/app/build/outputs/apk/debug/app-debug.apk + ``` + adb install -r chip-dir/src/android/CHIPTool/app/build/outputs/apk/debug/app-debug.apk + ``` 6. Navigate to settings on your smartphone and grant **Camera** and **Location** permissions to CHIPTool. diff --git a/docs/guides/nrfconnect_examples_cli.md b/docs/guides/nrfconnect_examples_cli.md index eed5e14e95cbd3..07871a5750a041 100644 --- a/docs/guides/nrfconnect_examples_cli.md +++ b/docs/guides/nrfconnect_examples_cli.md @@ -10,10 +10,12 @@ To access the CLI console, use a serial terminal emulator of your choice, like Minicom or GNU Screen. Use the baud rate set to `115200`. For example, to start using the CLI console with Minicom, run the following -command with _/dev/ttyACM0_ replaced with the device node name of your +command with `/dev/ttyACM0` replaced with the device node name of your development kit: - $ minicom -D /dev/ttyACM0 -b 115200 + ``` + minicom -D /dev/ttyACM0 -b 115200 + ``` When you reboot the kit, you will see the boot logs in the console, similar to the following messages: diff --git a/docs/guides/nrfconnect_examples_configuration.md b/docs/guides/nrfconnect_examples_configuration.md index b0d94ae84540d4..236008b740f6c4 100644 --- a/docs/guides/nrfconnect_examples_configuration.md +++ b/docs/guides/nrfconnect_examples_configuration.md @@ -34,12 +34,16 @@ Complete the following steps: directory, with _build-target_ replaced with the build target name of the kit, for example _nrf52840dk_nrf52840_: - $ west build -b build-target + ``` + west build -b build-target + ``` 2. Run the terminal-based interface called menuconfig by typing the following command: - $ west build -t menuconfig + ``` + west build -t menuconfig + ``` The menuconfig terminal window appears, in which you can navigate using arrow keys and other keys, based on the description at the bottom of the @@ -93,7 +97,9 @@ that you rebuild your application after editing them by typing the following command in the example directory, with _build-target_ replaced with the build target name of the kit, for example _nrf52840dk_nrf52840_: - $ west build -b build-target + ``` + west build -b build-target + ```
diff --git a/docs/guides/nrfconnect_examples_software_update.md b/docs/guides/nrfconnect_examples_software_update.md index 50180d20ef451a..588f69aff7d9b9 100644 --- a/docs/guides/nrfconnect_examples_software_update.md +++ b/docs/guides/nrfconnect_examples_software_update.md @@ -31,11 +31,15 @@ To test the DFU over Matter, you need to complete the following steps: 1. Navigate to the CHIP root directory. 2. Build the OTA Provider application for Linux: - $ scripts/examples/gn_build_example.sh examples/ota-provider-app/linux out/provider chip_config_network_layer_ble=false + ``` + scripts/examples/gn_build_example.sh examples/ota-provider-app/linux out/provider chip_config_network_layer_ble=false + ``` 3. Build chip-tool for Linux: - $ scripts/examples/gn_build_example.sh examples/chip-tool out/chiptool 'chip_mdns="platform"' + ``` + scripts/examples/gn_build_example.sh examples/chip-tool out/chiptool 'chip_mdns="platform"' + ``` 4. Run OTA Provider application with _matter.ota_ replaced with the path to the Matter OTA image which you wish to provide to the Matter device. Note that @@ -49,7 +53,9 @@ To test the DFU over Matter, you need to complete the following steps: 5. Commission the OTA Provider into the Matter network using Node Id 1: - $ ./out/chiptool/chip-tool pairing onnetwork 1 20202021 + ``` + ./out/chiptool/chip-tool pairing onnetwork 1 20202021 + ``` 6. Use the OTBR web interface to form a new Thread network using the default network settings. @@ -58,19 +64,25 @@ To test the DFU over Matter, you need to complete the following steps: Operational Dataset. It can be retrieved from the OTBR in case you have changed the default network settings when forming the network. - $ ./out/chiptool/chip-tool pairing ble-thread 2 hex:000300000f02081111111122222222051000112233445566778899aabbccddeeff01021234 20202021 3840 + ``` + ./out/chiptool/chip-tool pairing ble-thread 2 hex:000300000f02081111111122222222051000112233445566778899aabbccddeeff01021234 20202021 3840 + ``` 8. Configure the Matter device with the default OTA Provider by running the following command. The last two arguments are Requestor Node Id and Requestor Endpoint Id, respectively: - $ ./out/chiptool/chip-tool otasoftwareupdaterequestor write default-ota-providers '[{"fabricIndex": 1, "providerNodeID": 1, "endpoint": 0}]' 2 0 + ``` + ./out/chiptool/chip-tool otasoftwareupdaterequestor write default-ota-providers '[{"fabricIndex": 1, "providerNodeID": 1, "endpoint": 0}]' 2 0 + ``` 9. Configure the OTA Provider with the access control list (ACL) that grants _Operate_ privileges to all nodes in the fabric. This is necessary to allow the nodes to send cluster commands to the OTA Provider: - $ ./out/chiptool/chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": null, "targets": null}]' 1 0 + ``` + ./out/chiptool/chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": null, "targets": null}]' 1 0 + ``` 10. Initiate the DFU procedure in one of the following ways: @@ -79,14 +91,18 @@ To test the DFU over Matter, you need to complete the following steps: option, which enables Matter shell commands, run the following command on the device shell: - $ matter ota query + ``` + matter ota query + ``` - Otherwise, use chip-tool to send the Announce OTA Provider command to the device. The numeric arguments are Provider Node Id, Provider Vendor Id, Announcement Reason, Provider Endpoint Id, Requestor Node Id and Requestor Endpoint Id, respectively. - $ ./out/chiptool/chip-tool otasoftwareupdaterequestor announce-ota-provider 1 0 0 0 2 0 + ``` + ./out/chiptool/chip-tool otasoftwareupdaterequestor announce-ota-provider 1 0 0 0 2 0 + ``` Once the device is made aware of the OTA Provider node, it automatically queries the OTA Provider for a new firmware image. @@ -154,7 +170,9 @@ Complete the following steps to perform DFU using mcumgr: 4. Upload the application firmware image to the device by running the following command in your example directory: - $ sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image upload build/zephyr/app_update.bin -n 0 -w 1 + ``` + sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image upload build/zephyr/app_update.bin -n 0 -w 1 + ``` The operation can take a few minutes. Wait until the progress bar reaches 100%. @@ -162,12 +180,15 @@ Complete the following steps to perform DFU using mcumgr: 5. Obtain the list of images present in the device memory by running following command: - $ sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image list + ``` + sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image list + ``` The displayed output contains the old image in slot 0 that is currently active and the new image in slot 1, which is not active yet (flags field empty): + ``` Images: image=0 slot=0 version: 0.0.0 @@ -180,16 +201,20 @@ Complete the following steps to perform DFU using mcumgr: flags: hash: cbd58fc3821e749d3abfb00b3069f98c078824735f1b2a333e8a1579971e7de1 Split status: N/A (0) + ``` 6. Swap the firmware images by calling the following method with `image-hash` replaced by the image present in the slot 1 hash (for example, `cbd58fc3821e749d3abfb00b3069f98c078824735f1b2a333e8a1579971e7de1`): - $ sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image test image-hash + ``` + sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image test image-hash + ``` You can observe that the `flags:` field in the image for slot 1 changes value to `pending`: + ``` Images: image=0 slot=0 version: 0.0.0 @@ -202,6 +227,7 @@ Complete the following steps to perform DFU using mcumgr: flags: pending hash: cbd58fc3821e749d3abfb00b3069f98c078824735f1b2a333e8a1579971e7de1 Split status: N/A (0) + ``` > **_NOTE:_** If you are using the nRF5340DK board, that supports multi-image > device firmware upgrade, complete Steps 7-9. If not using one, go straight to @@ -210,7 +236,9 @@ Complete the following steps to perform DFU using mcumgr: 7. Upload the network core firmware image to the device by running the following command in your example directory: - $ sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image upload build/zephyr/net_core_app_update.bin -n 1 -w 1 + ``` + sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image upload build/zephyr/net_core_app_update.bin -n 1 -w 1 + ``` The operation can take a few minutes. Wait until the progress bar reaches 100%. @@ -218,13 +246,16 @@ Complete the following steps to perform DFU using mcumgr: 8. Obtain the list of images present in the device memory by running following command: - $ sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image list + ``` + sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image list + ``` The displayed output contains the old application image in slot 0 that is currently active, the new application image in slot 1 in pending state, and the new network image which is in slot 1 and not active yet (flags field empty): + ``` Images: image=0 slot=0 version: 0.0.0 @@ -242,16 +273,20 @@ Complete the following steps to perform DFU using mcumgr: flags: hash: d9e31e73cb7a959c26411250c2b3028f3510ae88a4549ae3f2f097c3e7530f48 Split status: N/A (0) + ``` 9. Swap the firmware images by calling the following method with `image-hash` replaced by the image present in the slot 1 hash (for example, `d9e31e73cb7a959c26411250c2b3028f3510ae88a4549ae3f2f097c3e7530f48`): - $ sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image test image-hash + ``` + sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' image test image-hash + ``` You can observe that the `flags:` field in the image for slot 1 changes value to `pending`: + ``` Images: image=0 slot=0 version: 0.0.0 @@ -269,21 +304,26 @@ Complete the following steps to perform DFU using mcumgr: flags: pending hash: d9e31e73cb7a959c26411250c2b3028f3510ae88a4549ae3f2f097c3e7530f48 Split status: N/A (0) + ``` 10. Reset the device with the following command to let the bootloader swap images: - $ sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' reset + ``` + sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_name='ble-device-name' reset + ``` The device is reset and the following notifications appear in its console: + ``` *** Booting Zephyr OS build zephyr-v2.5.0-1101-ga9d3aef65424 *** I: Starting bootloader I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1 I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3 I: Boot source: none I: Swap type: test + ``` Swapping operation can take some time, and after it completes, the new firmware is booted. diff --git a/docs/guides/nxp_imx8m_linux_examples.md b/docs/guides/nxp_imx8m_linux_examples.md index ffda37fbbe318b..bd8d47994a51cd 100644 --- a/docs/guides/nxp_imx8m_linux_examples.md +++ b/docs/guides/nxp_imx8m_linux_examples.md @@ -45,23 +45,29 @@ to be generated. This document is tested with the i.MX Yocto 5.10.35_2.0.0 release. Run the commands below to download this release: - $ mkdir ~/bin - $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo - $ chmod a+x ~/bin/repo - $ export PATH=${PATH}:~/bin - - $ mkdir yocto # this directory will be the top directory of the Yocto source code - $ cd yocto - $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-hardknott -m imx-5.10.35-2.0.0.xml - $ repo sync + ``` + mkdir ~/bin + curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo + chmod a+x ~/bin/repo + export PATH=${PATH}:~/bin + ``` + + ``` + mkdir yocto # this directory will be the top directory of the Yocto source code + cd yocto + repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-hardknott -m imx-5.10.35-2.0.0.xml + repo sync + ``` To build the Yocto Project, some packages need to be installed. The list of packages required are: - $ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ - build-essential chrpath socat cpio python3 python3-pip python3-pexpect \ - xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \ - pylint3 xterm + ``` + sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ + build-essential chrpath socat cpio python3 python3-pip python3-pexpect \ + xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \ + pylint3 xterm + ``` More information about the downloaded Yocto release can be found in the corresponding i.MX Yocto Project User’s Guide which can be found at @@ -70,8 +76,10 @@ to be generated. Change the current directory to the top directory of the Yocto source code and execute the commands below to generate the Yocto SDK: - $ MACHINE=imx8mmevk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland - $ bitbake imx-image-core -c populate_sdk + ``` + MACHINE=imx8mmevk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland + bitbake imx-image-core -c populate_sdk + ``` After the execution of the previous two commands, the SDK installation file can be found at tmp/deploy/sdk as a shell script. With the test environment @@ -82,9 +90,11 @@ to be generated. Change the current directory to the top directory of the Yocto source code and execute the commands below to generate the Yocto SD card image: - $ MACHINE=imx8mmevk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland - $ echo "IMAGE_INSTALL_append += \"libavahi-client\"" >> conf/local.conf - $ bitbake imx-image-core + ``` + MACHINE=imx8mmevk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland + echo "IMAGE_INSTALL_append += \"libavahi-client\"" >> conf/local.conf + bitbake imx-image-core + ``` The Yocto image can be found at tmp/deploy/images/imx8mmevk/imx-image-core-imx8mmevk.wic.bz2. The `bzip2` @@ -97,49 +107,57 @@ to be generated. represents a microSD card connected to the host machine with a USB adapter, however the output device name may vary. - $ bzip2 -d imx-image-core-imx8mmevk-20210812084502.rootfs.wic.bz2 - $ sudo dd if=imx-image-core-imx8mmevk-20210812084502.rootfs.wic of=/dev/sdc bs=4M conv=fsync + ``` + bzip2 -d imx-image-core-imx8mmevk-20210812084502.rootfs.wic.bz2 + sudo dd if=imx-image-core-imx8mmevk-20210812084502.rootfs.wic of=/dev/sdc bs=4M conv=fsync + ``` - Install the NXP Yocto SDK and set toolchain environment variables. Execute the SDK installation file with root permission. - $ sudo tmp/deploy/sdk/fsl-imx-xwayland-glibc-x86_64-imx-image-full-cortexa53-crypto-imx8mmevk-toolchain-5.10-hardknott.sh + ``` + sudo tmp/deploy/sdk/fsl-imx-xwayland-glibc-x86_64-imx-image-full-cortexa53-crypto-imx8mmevk-toolchain-5.10-hardknott.sh + ``` After the Yocto SDK is installed on the host machine, an environment setup script is also generated, and there are prompt lines telling the user to source the script each time when using the SDK in a new shell, for example: - $ . /opt/fsl-imx-xwayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux + ``` + . /opt/fsl-imx-xwayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux + ``` - Build the example application: Assuming that the working directory has been changed the CHIP Linux Examples code, all the other steps are the same. + ``` # If the all-clusters example is to be built - $ cd ~/connectedhomeip/examples/all-clusters-app/linux + cd ~/connectedhomeip/examples/all-clusters-app/linux # If the lighting example is to be built - $ cd ~/connectedhomeip/examples/lighting-app/linux + cd ~/connectedhomeip/examples/lighting-app/linux # If the thermostat example is to be built - $ cd ~/connectedhomeip/examples/thermostat/linux - - $ git submodule update --init - $ source third_party/connectedhomeip/scripts/activate.sh - $ PLATFORM_CFLAGS='-DCHIP_DEVICE_CONFIG_WIFI_STATION_IF_NAME=\"mlan0\"", "-DCHIP_DEVICE_CONFIG_LINUX_DHCPC_CMD=\"udhcpc -b -i %s \"' - $ PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR} \ - PKG_CONFIG_LIBDIR=${PKG_CONFIG_PATH} \ - gn gen out/aarch64 --args="target_os=\"linux\" target_cpu=\"arm64\" arm_arch=\"armv8-a\" - import(\"//build_overrides/build.gni\") - target_cflags=[ \"--sysroot=${SDKTARGETSYSROOT}\", \"${PLATFORM_CFLAGS}\" ] - target_ldflags = [ \"--sysroot=${SDKTARGETSYSROOT}\" ] - custom_toolchain=\"\${build_root}/toolchain/custom\" - target_cc=\"${OECORE_NATIVE_SYSROOT}/usr/bin/aarch64-poky-linux/aarch64-poky-linux-gcc\" - target_cxx=\"${OECORE_NATIVE_SYSROOT}/usr/bin/aarch64-poky-linux/aarch64-poky-linux-g++\" - target_ar=\"${OECORE_NATIVE_SYSROOT}/usr/bin/aarch64-poky-linux/aarch64-poky-linux-ar\"" - $ ninja -C out/aarch64 + cd ~/connectedhomeip/examples/thermostat/linux + + git submodule update --init + source third_party/connectedhomeip/scripts/activate.sh + PLATFORM_CFLAGS='-DCHIP_DEVICE_CONFIG_WIFI_STATION_IF_NAME=\"mlan0\"", "-DCHIP_DEVICE_CONFIG_LINUX_DHCPC_CMD=\"udhcpc -b -i %s \"' + PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR} \ + PKG_CONFIG_LIBDIR=${PKG_CONFIG_PATH} \ + gn gen out/aarch64 --args="target_os=\"linux\" target_cpu=\"arm64\" arm_arch=\"armv8-a\" + import(\"//build_overrides/build.gni\") + target_cflags=[ \"--sysroot=${SDKTARGETSYSROOT}\", \"${PLATFORM_CFLAGS}\" ] + target_ldflags = [ \"--sysroot=${SDKTARGETSYSROOT}\" ] + custom_toolchain=\"\${build_root}/toolchain/custom\" + target_cc=\"${OECORE_NATIVE_SYSROOT}/usr/bin/aarch64-poky-linux/aarch64-poky-linux-gcc\" + target_cxx=\"${OECORE_NATIVE_SYSROOT}/usr/bin/aarch64-poky-linux/aarch64-poky-linux-g++\" + target_ar=\"${OECORE_NATIVE_SYSROOT}/usr/bin/aarch64-poky-linux/aarch64-poky-linux-ar\"" + ninja -C out/aarch64 + ``` The executable file is built under out/aarch64, it can be executed on the **i.MX 8M Mini EVK** which running the Yocto image previously generated as @@ -229,31 +247,39 @@ Thermostat-app is used as an example below. - Initialize the BT device on the **i.MX 8M Mini EVK** board - $ modprobe moal mod_para=nxp/wifi_mod_para.conf # Load the Wi-Fi/BT firmware - $ hciattach /dev/ttymxc0 any 115200 flow # Initialize the BT device + ``` + modprobe moal mod_para=nxp/wifi_mod_para.conf # Load the Wi-Fi/BT firmware + hciattach /dev/ttymxc0 any 115200 flow # Initialize the BT device + ``` - Find the Bluetooth device id for **i.MX 8M Mini EVK** by executing the command below. The number following string `hci` is the Bluetooth device id, `0` in this example. + ``` $ hciconfig hci0: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:71:13 ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING RX bytes:73311 acl:1527 sco:0 events:3023 errors:0 TX bytes:48805 acl:1459 sco:0 commands:704 errors:0 + ``` - Run the Linux Example App - $ /home/root/thermostat-app --ble-device 0 --wifi # The bluetooth device used is hci0 and support wifi network + ``` + /home/root/thermostat-app --ble-device 0 --wifi # The bluetooth device used is hci0 and support wifi network + ``` - Run [ChipDeviceController](../../src/controller/python) on the controller device to communicate with **i.MX 8M Mini EVK** running the example. + ``` $ sudo out/python_env/bin/chip-device-ctrl # execute the tool chip-device-ctrl > connect -ble 3840 20202021 8889 # connect to i.MX 8M Mini EVK chip-device-ctrl > zcl Thermostat SetpointRaiseLower 8889 1 0 mode=1 amount=10 # send command to i.MX 8M Mini EVK via BLE + ``` (Note that the last two commands `connect -ble 3840 20202021 8889` and `zcl Thermostat SetpointRaiseLower 8889 1 0 mode=1 amount=10` are Python diff --git a/docs/guides/nxp_k32w_android_commissioning.md b/docs/guides/nxp_k32w_android_commissioning.md index 93ec768876b2de..f52ab2efe89c3d 100644 --- a/docs/guides/nxp_k32w_android_commissioning.md +++ b/docs/guides/nxp_k32w_android_commissioning.md @@ -88,19 +88,27 @@ the RCP firmware onto an K32W061 DK6: 1. Clone the OpenThread repository into the current directory (we recommand using commit ced158e65a00dd5394c04548b7b187d3a3f11eef): - $ git clone https://github.com/openthread/openthread.git + ``` + git clone https://github.com/openthread/openthread.git + ``` 2. Enter the _openthread_ directory: - $ cd openthread + ``` + cd openthread + ``` 3. Install OpenThread dependencies: - $ ./script/bootstrap + ``` + ./script/bootstrap + ``` 4. Set up the build environment: - $ ./bootstrap + ``` + ./bootstrap + ``` 5. Build OpenThread for the K32W061 DK6: @@ -130,10 +138,13 @@ To make your PC work as a Thread Border Router, complete the following tasks: - Install the required package: - $ sudo apt-get install hostapd + ``` + sudo apt-get install hostapd + ``` - Configure hostapd (create new file and add content): + ``` $ sudo vim /etc/hostapd/hostapd.conf interface=wlan0 @@ -150,69 +161,88 @@ To make your PC work as a Thread Border Router, complete the following tasks: wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP + ``` - We need to tell hostapd to use our config file by editing the main hostapd configuration file. Change the line that starts with - #DAEMON_CONF (remember to remove #): - \$ sudo vim /etc/default/hostapd + #DAEMON_CONF (remember to remove #): + + ``` + $ sudo vim /etc/default/hostapd DAEMON_CONF="/etc/hostapd/hostapd.conf" + ``` - Start hostapd: - $ sudo systemctl unmask hostapd - $ sudo systemctl enable hostapd + ``` + sudo systemctl unmask hostapd + sudo systemctl enable hostapd + ``` 3. Configure Dnsmasq - Install the required package: - $ sudo apt-get install dnsmasq + ``` + sudo apt-get install dnsmasq + ``` - Make a backup of the default config file: - $ sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.org + ``` + sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.org + ``` - Set the DHCP range: + ``` $ sudo vim /etc/dnsmasq.conf interface=wlan0 dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h + ``` - On System startup, dnsmasq will not wait for wlan0 interface to initialize and will fail. We need to tell systemd to launch it after networks get ready, so we will modify dnsmasq service file by specifying the initialization order under the _After=_ and _Wants=_ sections: + ``` $ sudo vim /lib/systemd/system/dnsmasq.service [Unit] ... After=... network-online.target Wants=... network-online.target + ``` - Force systemd to avoid using port 53 (used by dnsmasqd service): + ``` $ sudo vim /etc/systemd/resolved.conf DNSStubListener=no + ``` 4. Configure static IP for the Wi-Fi AP interface - Modify the cloud-init file and add content to it (use spaces, not tabs, USE THE ): + ``` $ sudo vim /etc/netplan/50-cloud-init.yaml wlan0: dhcp4: false addresses: - 192.168.4.1/24 + ``` - The final configuration file should like like this (pay attention to the spacing used): + ``` network: version: 2 ethernets: @@ -223,17 +253,22 @@ To make your PC work as a Thread Border Router, complete the following tasks: dhcp4: false addresses: - 192.168.4.1/24 + ``` 5) Set up RADVD - Install required package: - \$ sudo apt-get install radvd + ``` + sudo apt-get install radvd + ``` - - Configure RADVD for distributing the prefix _fd11:33_::/64 to the + - Configure RADVD for distributing the prefix `_fd11:33_::/64` to the devices connected to the AP, while announcing them that is also has a - route to _fd11:22::/64_ - \$ sudo vim /etc/radvd.conf + route to `_fd11:22::/64_` + + ``` + $ sudo vim /etc/radvd.conf interface wlan0 { AdvManagedFlag on; @@ -248,32 +283,40 @@ To make your PC work as a Thread Border Router, complete the following tasks: route fd11:22::/64 { }; }; + ``` - Enable radvd service: - $ sudo chmod u=rw,g=r,o=r /etc/radvd.conf - $ sudo systemctl enable - radvd.service + + ``` + sudo chmod u=rw,g=r,o=r /etc/radvd.conf + sudo systemctl enable radvd.service + ``` 6. Configure routing: - Create a configuration file for setting the routing behavior (forward between Thread and Wi-Fi AP interfaces): + ``` $ sudo vim configurations.sh #!/bin/bash sudo iptables -A FORWARD -i wlan0 -o wpan0 -j ACCEPT sudo iptables -A FORWARD -i wpan0 -o wlan0 -j ACCEPT + ``` - Set the executable bit for the above file: - $ sudo chmod +x configurations.sh + ``` + sudo chmod +x configurations.sh + ``` - Configure the above script to be run each time the PC is restarted using a systemd service configuration (change the path for _ExecStart_): + ``` $ sudo vim /etc/systemd/system/br.service [Unit] @@ -286,12 +329,14 @@ To make your PC work as a Thread Border Router, complete the following tasks: [Install] WantedBy=multi-user.target - + ``` - Then run: - $ sudo systemctl daemon-reload - $ sudo systemctl enable br.service + ``` + sudo systemctl daemon-reload + sudo systemctl enable br.service + ``` 7. As a quick checkpoint, restart the PC and make sure that the mobile phone can connect to the _OT-BR_ AP (password: 12345678). Also, check that it gets @@ -299,10 +344,12 @@ To make your PC work as a Thread Border Router, complete the following tasks: with the prefix _fd11:33::/64_. Commands for debugging possible issues with the services: - $ sudo service hostapd status - $ sudo service dnsmasq status - $ sudo service radvd status - $ sudo service br status + ``` + sudo service hostapd status + sudo service dnsmasq status + sudo service radvd status + sudo service br status + ```
@@ -332,7 +379,9 @@ After building, install the application by completing the following steps: 1. Install the Android Debug Bridge (adb) package by running the following command: - $ sudo apt install android-tools-adb + ``` + sudo apt install android-tools-adb + ``` 2. Enable _USB debugging_ on the smartphone. See the [Configure on-device developer options](https://developer.android.com/studio/debug/dev-options) @@ -343,7 +392,9 @@ After building, install the application by completing the following steps: 5. Run the following command to install the application, with _chip-dir_ replaced with the path to the CHIP source directory: - $ adb install -r chip-dir/src/android/CHIPTool/app/build/outputs/apk/debug/app-debug.apk + ``` + adb install -r chip-dir/src/android/CHIPTool/app/build/outputs/apk/debug/app-debug.apk + ``` 6. Navigate to settings on your smartphone and grant _Camera_ and _Location_ permissions to CHIPTool. @@ -371,7 +422,9 @@ CHIPTool is now ready to be used for commissioning. 5. In case you ever want to reset these parameters issue this command from the border router shell: - $ sudo ot-ctl factoryreset + ``` + sudo ot-ctl factoryreset + ``` 6. Info: For debugging the Border Router, _ot-ctl_ offers an entry point to [Thread CLI Commands](https://github.com/openthread/openthread/blob/master/src/cli/README.md). @@ -379,11 +432,15 @@ CHIPTool is now ready to be used for commissioning. 7. In case there is any issue with the Web GUI check the logs on the Border Router side / restart the daemon: - $ sudo service otbr-web status + ``` + sudo service otbr-web status + ``` In case the status is not _leader_ then restart the service: - $ sudo service otbr-web restart + ``` + sudo service otbr-web restart + ``` ## Preparing accessory device @@ -402,8 +459,10 @@ To prepare the accessory device for commissioning, complete the following steps: the device. 4. Find a message similar to the following one in the application logs: + ``` I: 666[SVR] Copy/paste the below URL in a browser to see the QR Code: https://dhrishi.github.io/connectedhomeip/qrcode.html?data=CH%3AI34DV%2A-00%200C9SS0 + ``` 5. Open the URL in a web browser to have the commissioning QR code generated. diff --git a/docs/guides/openthread_rcp_nrf_dongle.md b/docs/guides/openthread_rcp_nrf_dongle.md index f772529cd238cf..4f682f139897ef 100644 --- a/docs/guides/openthread_rcp_nrf_dongle.md +++ b/docs/guides/openthread_rcp_nrf_dongle.md @@ -18,15 +18,21 @@ nRF52840 Dongle: 1. Clone the OpenThread nRF528xx platform repository into the current directory: - $ git clone --recursive https://github.com/openthread/ot-nrf528xx.git + ``` + git clone --recursive https://github.com/openthread/ot-nrf528xx.git + ``` 2. Enter the _ot-nrf528xx_ directory: - $ cd ot-nrf528xx + ``` + cd ot-nrf528xx + ``` 3. Install OpenThread dependencies: - $ ./script/bootstrap + ``` + ./script/bootstrap + ``` 4. Build OpenThread for the nRF52840 Dongle: @@ -36,18 +42,24 @@ nRF52840 Dongle: 5. Convert the RCP image to the `.hex` format: - $ arm-none-eabi-objcopy -O ihex build/bin/ot-rcp build/bin/ot-rcp.hex + ``` + arm-none-eabi-objcopy -O ihex build/bin/ot-rcp build/bin/ot-rcp.hex + ``` 6. Install [nRF Util](https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Util): - $ python3 -m pip install -U nrfutil + ``` + python3 -m pip install -U nrfutil + ``` 7. Generate the RCP firmware package: - $ nrfutil pkg generate --hw-version 52 --sd-req=0x00 \ + ``` + nrfutil pkg generate --hw-version 52 --sd-req=0x00 \ --application build/bin/ot-rcp.hex \ --application-version 1 build/bin/ot-rcp.zip + ``` 8. Connect the nRF52840 Dongle to the USB port. @@ -55,7 +67,9 @@ nRF52840 Dongle: LED on the dongle starts blinking. 10. To install the RCP firmware package onto the dongle, run the following - command, with _/dev/ttyACM0_ replaced with the device node name of your + command, with `/dev/ttyACM0` replaced with the device node name of your nRF52840 Dongle: - $ nrfutil dfu usb-serial -pkg build/bin/ot-rcp.zip -p /dev/ttyACM0 + ``` + nrfutil dfu usb-serial -pkg build/bin/ot-rcp.zip -p /dev/ttyACM0 + ``` diff --git a/docs/guides/silabs_efr32_software_update.md b/docs/guides/silabs_efr32_software_update.md index c4afffdcc33502..53f46d1220208c 100644 --- a/docs/guides/silabs_efr32_software_update.md +++ b/docs/guides/silabs_efr32_software_update.md @@ -14,8 +14,10 @@ all of the EFR32 example applications. - On a Linux or Darwin platform build the chip-tool and the ota-provider-app as follows: + ``` scripts/examples/gn_build_example.sh examples/chip-tool out/ scripts/examples/gn_build_example.sh examples/ota-provider-app/linux out/debug chip_config_network_layer_ble=false + ``` - Build or download the Gecko Bootloader binary. Bootloader should be built with the Gecko SDK version 3.2.1 or earlier. For the bootloader using the @@ -26,7 +28,9 @@ all of the EFR32 example applications. User’s Guide". Pre-built binaries for some configurations should be available in + ``` third_party/efr32_sdk/repo/platform/bootloader/sample-apps/bootloader-storage-spiflash-single + ``` - Using the commander tool upload the bootloader to the device running the application. @@ -34,35 +38,47 @@ all of the EFR32 example applications. - Create a bootable image file (using the Lighting application image as an example): + ``` commander gbl create chip-efr32-lighting-example.gbl --app chip-efr32-lighting-example.s37 + ``` - Create the Matter OTA file from the bootable image file: + ``` ./src/app/ota_image_tool.py create -v 0xFFF1 -p 0x8005 -vn 1 -vs "1.0" -da sha256 chip-efr32-lighting-example.gbl chip-efr32-lighting-example.ota + ``` - In a terminal start the Provider app passing to it the path to the Matter OTA file created in the previous step: + ``` rm -r /tmp/chip_* ./out/debug/chip-ota-provider-app -f chip-efr32-lighting-example.ota + ``` - In a separate terminal run the chip-tool commands to provision the Provider: - ./out/chip-tool pairing onnetwork 1 20202021 - ./out/chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": null, "targets": null}]' 1 0 + ``` + ./out/chip-tool pairing onnetwork 1 20202021 + ./out/chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": null, "targets": null}]' 1 0 + ``` - If the application device had been previously commissioned hold Button 0 for six seconds to factory-reset the device. - In the chip-tool terminal enter: - ./out/chip-tool pairing ble-thread 2 hex: 20202021 3840 + ``` + ./out/chip-tool pairing ble-thread 2 hex: 20202021 3840 + ``` where operationalDataset is obtained from the OpenThread Border Router. - Once the commissioning process completes enter: - ./out/chip-tool otasoftwareupdaterequestor announce-ota-provider 1 0 0 0 2 0 + ``` + ./out/chip-tool otasoftwareupdaterequestor announce-ota-provider 1 0 0 0 2 0 + ``` - The application device will connect to the Provider and start the image download. Once the image is downloaded the device will reboot into the diff --git a/docs/guides/ti_platform_overview.md b/docs/guides/ti_platform_overview.md index 37a8e065232810..50d96f361963ee 100644 --- a/docs/guides/ti_platform_overview.md +++ b/docs/guides/ti_platform_overview.md @@ -6,9 +6,7 @@ Incorporated SimpleLink SDK. The following diagram is a simplified representation of a Matter application which built on the TI Platform. -

- matter_ti_overview_simplified -

+![matter_ti_overview_simplified](images/matter_ti_overview_simplified.png) ## Texas Instruments SimpleLink SDK diff --git a/examples/all-clusters-app/ameba/README.md b/examples/all-clusters-app/ameba/README.md index 0b333950067ca7..3c51bc43cabda9 100644 --- a/examples/all-clusters-app/ameba/README.md +++ b/examples/all-clusters-app/ameba/README.md @@ -26,19 +26,27 @@ The CHIP demo application is supported on - Pull docker image: + ``` $ docker pull connectedhomeip/chip-build-ameba:latest + ``` - Run docker container: + ``` $ docker run -it -v ${CHIP_DIR}:/root/chip connectedhomeip/chip-build-ameba:latest + ``` - Setup build environment: + ``` $ source ./scripts/bootstrap.sh + ``` - To build the demo application: + ``` $ ./scripts/build/build_examples.py --target ameba-amebad-all-clusters build + ``` The output image files are stored in `out/ameba-amebad-all-clusters/asdk/image` folder. @@ -67,7 +75,7 @@ There are two commissioning modes supported by Ameba platform: - Set `chip_config_network_layer_ble = true` -2. In "connectedhomeip/src/platform/Ameba/CHIPDevicePlatformConfig.h" +2. In `connectedhomeip/src/platform/Ameba/CHIPDevicePlatformConfig.h` - Set `#define CHIP_DEVICE_CONFIG_ENABLE_CHIPOBLE 1` @@ -79,11 +87,11 @@ There are two commissioning modes supported by Ameba platform: ### IP mode -1. In "connectedhomeip/config/ameba/args.gni" +1. In `connectedhomeip/config/ameba/args.gni` - Set `chip_config_network_layer_ble = false` -2. In "connectedhomeip/src/platform/Ameba/CHIPDevicePlatformConfig.h" +2. In `connectedhomeip/src/platform/Ameba/CHIPDevicePlatformConfig.h` - Set `#define CHIP_DEVICE_CONFIG_ENABLE_CHIPOBLE 0` @@ -103,17 +111,21 @@ to be On or Off. - Via [Chip-Tool](https://github.com/project-chip/connectedhomeip/tree/master/examples/chip-tool#using-the-client-to-send-matter-commands) + ``` $ ./chip-tool onoff on ${NODE_ID_TO_ASSIGN} 1 $ ./chip-tool onoff off ${NODE_ID_TO_ASSIGN} 1 + ``` ## Running RPC Console - Connect a USB-TTL Adapter as shown below + ``` Ameba USB-TTL A19 TX A18 RX GND GND + ``` - Build the [chip-rpc console](https://github.com/project-chip/connectedhomeip/tree/master/examples/common/pigweed/rpc_console) @@ -123,13 +135,19 @@ to be On or Off. also created in the output folder: out/debug/chip_rpc_console_wheels. To install the wheel files without rebuilding: + ``` $ pip3 install out/debug/chip_rpc_console_wheels/*.whl + ``` - Launch the chip-rpc console after resetting Ameba board + ``` $ chip-console --device /dev/tty -b 115200 + ``` - Get and Set lighting directly using the RPC console + ```python rpcs.chip.rpc.Lighting.Get() rpcs.chip.rpc.Lighting.Set(on=True, level=128, color=protos.chip.rpc.LightingColor(hue=5, saturation=5)) + ``` diff --git a/examples/all-clusters-app/esp32/README.md b/examples/all-clusters-app/esp32/README.md index 9af884bd7fabfd..11b321ee0e742f 100644 --- a/examples/all-clusters-app/esp32/README.md +++ b/examples/all-clusters-app/esp32/README.md @@ -44,6 +44,7 @@ step. To install these components manually, follow these steps: - Clone the Espressif ESP-IDF and checkout [v4.4 release](https://github.com/espressif/esp-idf/releases/tag/v4.4) + ``` $ mkdir ${HOME}/tools $ cd ${HOME}/tools $ git clone https://github.com/espressif/esp-idf.git @@ -52,9 +53,11 @@ step. To install these components manually, follow these steps: $ git submodule update --init $ ./install.sh $ . ./export.sh + ``` To update an existing esp-idf toolchain to v4.4: + ``` $ cd ~/tools/esp-idf $ git fetch origin $ git checkout v4.4 @@ -63,36 +66,47 @@ step. To install these components manually, follow these steps: $ git clean -fdx $ ./install.sh $ . ./export.sh + ``` - Install ninja-build + ``` $ sudo apt-get install ninja-build + ``` Currently building in VSCode _and_ deploying from native is not supported, so make sure the IDF_PATH has been exported(See the manual setup steps above). - Setting up the environment + ``` $ cd ${HOME}/tools/esp-idf $ ./install.sh $ . ./export.sh $ cd {path-to-connectedhomeip} + ``` To download and install packages. + ``` $ source ./scripts/bootstrap.sh $ source ./scripts/activate.sh + ``` If packages are already installed then simply activate them. + ``` $ source ./scripts/activate.sh + ``` - Target Set To set IDF target, run set-target with one of the commands. - $ idf.py set-target esp32 - $ idf.py set-target esp32c3 + ``` + $ idf.py set-target esp32 + $ idf.py set-target esp32c3 + ``` - Configuration Options @@ -101,8 +115,10 @@ demo application. To build a specific configuration (as an example `m5stack`): + ``` $ rm sdkconfig $ idf.py -D 'SDKCONFIG_DEFAULTS=sdkconfig_m5stack.defaults' build + ``` Note: If using a specific device configuration, it is highly recommended to start off with one of the defaults and customize on top of that. Certain @@ -111,7 +127,9 @@ To build a specific configuration (as an example `m5stack`): To customize the configuration, run menuconfig. + ``` $ idf.py menuconfig + ``` Select ESP32 based `Device Type` through `Demo`->`Device Type`. The device types that are currently supported include `ESP32-DevKitC` (default), @@ -119,7 +137,9 @@ that are currently supported include `ESP32-DevKitC` (default), - To build the demo application. + ``` $ idf.py build + ``` - After building the application, to flash it outside of VSCode, connect your device via USB. Then run the following command to flash the demo application @@ -131,7 +151,9 @@ that are currently supported include `ESP32-DevKitC` (default), devices this is labeled in the [functional description diagram](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-devkitc.html#functional-description). + ``` $ idf.py -p /dev/tty.SLAB_USBtoUART flash monitor + ``` Note: Some users might have to install the [VCP driver](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers) @@ -144,7 +166,9 @@ that are currently supported include `ESP32-DevKitC` (default), - If desired, the monitor can be run again like so: + ``` $ idf.py -p /dev/tty.SLAB_USBtoUART monitor + ``` ## Commissioning and cluster control @@ -153,26 +177,32 @@ Commissioning can be carried out using WiFi or BLE. 1. Set the `Rendezvous Mode` for commissioning using menuconfig; the default Rendezvous mode is BLE. - $ idf.py menuconfig + ``` + $ idf.py menuconfig + ``` Select the Rendezvous Mode via `Demo -> Rendezvous Mode`. NOTE: to avoid build error `undefined reference to 'chip::DevelopmentCerts::kDacPublicKey'`, set VID to -0xFFF1 and PID in range 0x8000..0x8005. +`0xFFF1` and PID in range `0x8000..0x8005`. `idf.py menuconfig -> Component config -> CHIP Device Layer -> Device Identification Options` 2. Now flash the device with the same command as before. (Use the right `/dev` device) + ``` $ idf.py -p /dev/tty.SLAB_USBtoUART flash monitor + ``` 3. The device should boot up. When device connects to your network, you will see a log like this on the device console. + ``` I (5524) chip[DL]: SYSTEM_EVENT_STA_GOT_IP I (5524) chip[DL]: IPv4 address changed on WiFi station interface: ... + ``` 4. Use [python based device controller](https://github.com/project-chip/connectedhomeip/tree/master/src/controller/python) @@ -187,7 +217,9 @@ NOTE: to avoid build error Note: The ESP32 does not support 5GHz networks. Also, the Device will persist your network configuration. To erase it, simply run. + ``` $ idf.py -p /dev/tty.SLAB_USBtoUART erase_flash + ``` - Once ESP32 is up and running, we need to set up a device controller to perform commissioning and cluster control. @@ -224,7 +256,9 @@ remote device, as well as the network credentials to use. The command below uses the default values hard-coded into the debug versions of the ESP32 all-clusters-app to commission it onto a Wi-Fi network: + ``` $ ./out/debug/chip-tool pairing ble-wifi 12344321 ${SSID} ${PASSWORD} 20202021 3840 + ``` Parameters: @@ -239,7 +273,9 @@ Parameters: To use the Client to send Matter commands, run the built executable and pass it the target cluster name, the target command name as well as an endpoint id. + ``` $ ./out/debug/chip-tool onoff on 12344321 1 + ``` The client will send a single command packet and then exit. @@ -256,17 +292,19 @@ Usage: - First set IDF target, run set-target with one of the commands. + ``` $ idf.py set-target esp32 $ idf.py set-target esp32c3 + ``` - Execute below sequence of commands -``` + ``` $ export ESPPORT=/dev/tty.SLAB_USBtoUART $ idf.py build $ idf.py flashing_script $ python ${app_name}.flash.py -``` + ``` ### Note @@ -285,28 +323,36 @@ actual effect of the commands. You can use the rpc default config to setup everything correctly for RPCs: + ``` $ export SDKCONFIG_DEFAULTS=$PROJECT_ROOT/examples/all-clusters-app/esp32/sdkconfig_m5stack_rpc.defaults $ rm sdkconfig $ idf.py fullclean + ``` Alternatively, Enable RPCs in the build using menuconfig: - Enable the RPC library and Disable ENABLE_CHIP_SHELL + ``` Component config → CHIP Core → General Options → Enable Pigweed PRC library Component config → CHIP Core → General Options → Disable CHIP Shell + ``` - Ensure the UART is correctly configured for your board, for m5stack: + ``` PW RPC Debug channel → UART port number → 0 PW RPC Debug channel → UART communication speed → 115200 PW RPC Debug channel → UART RXD pin number → 3 PW RPC Debug channel → UART TXD pin number → 1 + ``` After configuring you can build and flash normally: + ``` $ idf.py build $ idf.py flash + ``` After flashing a build with RPCs enabled you can use the rpc console to send commands to the device. @@ -315,15 +361,19 @@ Build or install the [rpc console](../../common/pigweed/rpc_console/README.md) Start the console + ``` chip-console --device /dev/ttyUSB0 + ``` From within the console you can then invoke rpcs: + ```python rpcs.chip.rpc.WiFi.Connect(ssid=b"MySSID", secret=b"MyPASSWORD") rpcs.chip.rpc.WiFi.GetIP6Address() rpcs.chip.rpc.Lighting.Get() rpcs.chip.rpc.Lighting.Set(on=True, level=128, color=protos.chip.rpc.LightingColor(hue=5, saturation=5)) + ``` ## Device Tracing diff --git a/examples/all-clusters-app/linux/README.md b/examples/all-clusters-app/linux/README.md index d029d6eff5f14d..d0ce8dba69774d 100644 --- a/examples/all-clusters-app/linux/README.md +++ b/examples/all-clusters-app/linux/README.md @@ -8,13 +8,17 @@ This example supports compilation with libfuzzer enabled. To compile with libfuzzer enabled on Mac, run: - $ ./scripts/run_in_build_env.sh "./scripts/build/build_examples.py --target darwin-x64-all-clusters-no-ble-asan-libfuzzer-clang build" +``` +$ ./scripts/run_in_build_env.sh "./scripts/build/build_examples.py --target darwin-x64-all-clusters-no-ble-asan-libfuzzer-clang build" +``` at the top level of the Matter tree. Similarly, to compile on Linux run: - $ ./scripts/run_in_build_env.sh "./scripts/build/build_examples.py --target linux-x64-all-clusters-no-ble-asan-libfuzzer-clang build" +``` +$ ./scripts/run_in_build_env.sh "./scripts/build/build_examples.py --target linux-x64-all-clusters-no-ble-asan-libfuzzer-clang build" +``` ### Running libfuzzer-enabled binaries @@ -22,19 +26,25 @@ Similarly, to compile on Linux run: To run the resulting binary with no particular inputs do: - $ ./out/darwin-x64-all-clusters-no-ble-asan-libfuzzer-clang/chip-all-clusters-app-fuzzing +``` +$ ./out/darwin-x64-all-clusters-no-ble-asan-libfuzzer-clang/chip-all-clusters-app-fuzzing +``` or - $ ./out/linux-x64-all-clusters-no-ble-asan-libfuzzer-clang/chip-all-clusters-app-fuzzing +``` +$ ./out/linux-x64-all-clusters-no-ble-asan-libfuzzer-clang/chip-all-clusters-app-fuzzing +``` If this crashes, it will output the input that caused the crash in a variety of formats, looking something like this: - 0xe,0x0,0xf1,0xb1,0xf1,0xf1,0xf1,0xf1,0xed,0x73,0x7,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xc1,0x0,0x0,0x0,0x0,0x0,0x5c,0xf3,0x25,0x0,0x0,0x0,0x0,0x0, - \016\000\361\261\361\361\361\361\355s\007\000\000\000\000\000\000\000\301\000\000\000\000\000\\\363%\000\000\000\000\000 - artifact_prefix='./'; Test unit written to ./crash-c9fd2434ccf4a33a7f49765dcc519e1fd529a8e5 - Base64: DgDxsfHx8fHtcwcAAAAAAAAAwQAAAAAAXPMlAAAAAAA= +``` +0xe,0x0,0xf1,0xb1,0xf1,0xf1,0xf1,0xf1,0xed,0x73,0x7,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xc1,0x0,0x0,0x0,0x0,0x0,0x5c,0xf3,0x25,0x0,0x0,0x0,0x0,0x0, +\016\000\361\261\361\361\361\361\355s\007\000\000\000\000\000\000\000\301\000\000\000\000\000\\\363%\000\000\000\000\000 +artifact_prefix='./'; Test unit written to ./crash-c9fd2434ccf4a33a7f49765dcc519e1fd529a8e5 +Base64: DgDxsfHx8fHtcwcAAAAAAAAAwQAAAAAAXPMlAAAAAAA= +``` Note that this creates a file holding the input that caused the crash. @@ -44,11 +54,15 @@ To run the binary with a specific input, place the input bytes in a file (which a crashing run of the fuzzer does automatically). If `$(INPUT_FILE)` is the name of that file, then run: - $ ./out/darwin-x64-all-clusters-no-ble-asan-libfuzzer-clang/chip-all-clusters-app-fuzzing $(INPUT_FILE) +``` +$ ./out/darwin-x64-all-clusters-no-ble-asan-libfuzzer-clang/chip-all-clusters-app-fuzzing $(INPUT_FILE) +``` or - $ ./out/linux-x64-all-clusters-no-ble-asan-libfuzzer-clang/chip-all-clusters-app-fuzzing $(INPUT_FILE) +``` +$ ./out/linux-x64-all-clusters-no-ble-asan-libfuzzer-clang/chip-all-clusters-app-fuzzing $(INPUT_FILE) +``` #### Additional execution options. diff --git a/examples/all-clusters-app/mbed/README.md b/examples/all-clusters-app/mbed/README.md index 547d9436f90d79..a08a96a9af6433 100644 --- a/examples/all-clusters-app/mbed/README.md +++ b/examples/all-clusters-app/mbed/README.md @@ -1,6 +1,4 @@ -

- ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png)

Matter Arm Mbed OS All Clusters Example Application

@@ -210,13 +208,17 @@ open a terminal session and connect to the serial port of the device. You can use **mbed-tools** for this purpose ([mbed-tools](https://github.com/ARMmbed/mbed-tools)): + ``` mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off + ``` After device reset these lines should be visible: + ``` [INFO][CHIP]: [-]Mbed all-clusters-app example application start ... [INFO][CHIP]: [-]Mbed all-clusters-app example application run + ``` The all-clusters-app application launched correctly and you can follow traces in the terminal. @@ -229,9 +231,9 @@ within a WiFi network. ## Supported devices -| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components | -| ----------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------: | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [Cypress
Semiconductor](https://www.cypress.com/) | [CY8CPROTO-062-4343W](https://os.mbed.com/platforms/CY8CPROTO-062-4343W/) | `CY8CPROTO_062_4343W` |
CY8CPROTO-062-4343WCY8CPROTO-062-4343W
| :heavy_check_mark: |
LEDs
  • Board has only one usable LED (LED4) which corresponds to USER LED from UI.
Buttons
  • Unused
Slider
  • Unused
| +| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components | +| ----------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------ | :----------------: | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| [Cypress
Semiconductor](https://www.cypress.com/) | [CY8CPROTO-062-4343W](https://os.mbed.com/platforms/CY8CPROTO-062-4343W/) | `CY8CPROTO_062_4343W` | ![CY8CPROTO-062-4343W](https://os.mbed.com/media/cache/platforms/p6_wifi-bt_proto.png.250x250_q85.jpg) | :heavy_check_mark: |
LEDs
  • Board has only one usable LED (LED4) which corresponds to USER LED from UI.
Buttons
  • Unused
Slider
  • Unused
| #### Notes diff --git a/examples/all-clusters-app/nrfconnect/README.md b/examples/all-clusters-app/nrfconnect/README.md index 4c6f144fbba787..29ca4bcb7e4648 100644 --- a/examples/all-clusters-app/nrfconnect/README.md +++ b/examples/all-clusters-app/nrfconnect/README.md @@ -4,10 +4,8 @@ The nRF All Clusters Example Application implements various ZCL clusters populated on three endpoints. You can use this example as a reference for creating your own application. -

- Nordic Semiconductor logo - nRF52840 DK -

+![Nordic Smiconductor logo](../../platform/nrfconnect/doc/images/Logo_RGB_H-small.png) +![nRF52840 DK](../../platform/nrfconnect/doc/images/nRF52840-DK-small.png) The example is based on [Matter](https://github.com/project-chip/connectedhomeip) and Nordic diff --git a/examples/all-clusters-app/p6/README.md b/examples/all-clusters-app/p6/README.md index 95b82a4cd147e9..25b8e53b04d697 100644 --- a/examples/all-clusters-app/p6/README.md +++ b/examples/all-clusters-app/p6/README.md @@ -39,21 +39,29 @@ will then join the network. tools. - Install some additional tools (likely already present for Matter - developers): \$ sudo apt install gcc g++ clang ninja-build python - python3-venv libssl-dev libavahi-client-dev libglib2.0-dev git cmake - python3-pip + developers): + + ``` + sudo apt install gcc g++ clang ninja-build python \ + python3-venv libssl-dev libavahi-client-dev libglib2.0-dev git cmake \ + python3-pip + ``` - Supported hardware: [CY8CKIT-062S2-43012](https://www.cypress.com/CY8CKIT-062S2-43012) * Build the example application: + ``` $ ./scripts/examples/gn_p6_example.sh ./examples/all-clusters-app/p6 out/clusters_app_p6 + ``` - To delete generated executable, libraries and object files use: + ``` $ cd ~/connectedhomeip $ rm -rf out/ + ``` @@ -65,8 +73,10 @@ will then join the network. - On the command line: + ``` $ cd ~/connectedhomeip $ python3 out/clusters_app_p6/chip-p6-clusters-example.flash.py + ``` @@ -83,12 +93,16 @@ perform commissioning and cluster control. - Set up python controller. + ``` $ cd {path-to-connectedhomeip} $ ./scripts/examples/gn_build_example.sh examples/chip-tool out/debug + ``` - Execute the controller. + ``` $ ./out/debug/chip-tool + ``` @@ -97,6 +111,7 @@ perform commissioning and cluster control. Run the built executable and pass it the discriminator and pairing code of the remote device, as well as the network credentials to use. + ``` $ ./out/debug/chip-tool pairing ble-wifi 1234 ${SSID} ${PASSWORD} 20202021 3840 Parameters: @@ -105,6 +120,7 @@ remote device, as well as the network credentials to use. 3. Node ID: 1234 (you can assign any node id) 4. SSID : Wi-Fi SSID 5. PASSWORD : Wi-Fi Password + ``` @@ -113,6 +129,8 @@ remote device, as well as the network credentials to use. Raspberry Pi 4 BLE connection issues can be avoided by running the following commands. These power cycle the BlueTooth hardware and disable BR/EDR mode. - $ sudo btmgmt -i hci0 power off - $ sudo btmgmt -i hci0 bredr off - $ sudo btmgmt -i hci0 power on + ``` + sudo btmgmt -i hci0 power off + sudo btmgmt -i hci0 bredr off + sudo btmgmt -i hci0 power on + ``` diff --git a/examples/bridge-app/esp32/README.md b/examples/bridge-app/esp32/README.md index 12ca5f4160fead..a0751afeb023f4 100644 --- a/examples/bridge-app/esp32/README.md +++ b/examples/bridge-app/esp32/README.md @@ -88,6 +88,7 @@ step. To install these components manually, follow these steps: - Clone the Espressif ESP-IDF and checkout [v4.4 release](https://github.com/espressif/esp-idf/releases/tag/v4.4) + ``` $ mkdir ${HOME}/tools $ cd ${HOME}/tools $ git clone https://github.com/espressif/esp-idf.git @@ -95,29 +96,38 @@ step. To install these components manually, follow these steps: $ git checkout v4.4 $ git submodule update --init $ ./install.sh + ``` - Install ninja-build + ``` $ sudo apt-get install ninja-build + ``` Currently building in VSCode _and_ deploying from native is not supported, so make sure the IDF_PATH has been exported(See the manual setup steps above). - Setting up the environment + ``` $ cd ${HOME}/tools/esp-idf $ ./install.sh $ . ./export.sh $ cd {path-to-connectedhomeip} + ``` To download and install packages. + ``` $ source ./scripts/bootstrap.sh $ source ./scripts/activate.sh + ``` If packages are already installed then simply activate them. + ``` $ source ./scripts/activate.sh + ``` - Configuration Options @@ -127,7 +137,9 @@ make sure the IDF_PATH has been exported(See the manual setup steps above). - To build the demo application. + ``` $ idf.py build + ``` - After building the application, to flash it outside of VSCode, connect your device via USB. Then run the following command to flash the demo application @@ -138,7 +150,9 @@ make sure the IDF_PATH has been exported(See the manual setup steps above). before flashing. For ESP32-DevKitC devices this is labeled in the [functional description diagram](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-devkitc.html#functional-description). + ``` $ idf.py -p /dev/tty.SLAB_USBtoUART flash monitor + ``` Note: Some users might have to install the [VCP driver](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers) @@ -151,7 +165,9 @@ make sure the IDF_PATH has been exported(See the manual setup steps above). - If desired, the monitor can be run again like so: + ``` $ idf.py -p /dev/tty.SLAB_USBtoUART monitor + ``` ## Commissioning and cluster control @@ -160,20 +176,26 @@ Commissioning can be carried out using WiFi or BLE. 1. Set the `Rendezvous Mode` for commissioning using menuconfig; the default Rendezvous mode is BLE. + ``` $ idf.py menuconfig + ``` Select the Rendezvous Mode via `Demo -> Rendezvous Mode`. 2. Now flash the device with the same command as before. (Use the right `/dev` device) - $ idf.py -p /dev/tty.SLAB_USBtoUART flash monitor + ``` + $ idf.py -p /dev/tty.SLAB_USBtoUART flash monitor + ``` 3. The device should boot up. When device connects to your network, you will see a log like this on the device console. - I (5524) chip[DL]: SYSTEM_EVENT_STA_GOT_IP - I (5524) chip[DL]: IPv4 address changed on WiFi station interface: ... + ``` + I (5524) chip[DL]: SYSTEM_EVENT_STA_GOT_IP + I (5524) chip[DL]: IPv4 address changed on WiFi station interface: ... + ``` 4. Use [python based device controller](https://github.com/project-chip/connectedhomeip/tree/master/src/controller/python) @@ -188,7 +210,9 @@ Select the Rendezvous Mode via `Demo -> Rendezvous Mode`. Note: The ESP32 does not support 5GHz networks. Also, the Device will persist your network configuration. To erase it, simply run. + ``` $ idf.py -p /dev/tty.SLAB_USBtoUART erase_flash + ``` - Once ESP32 is up and running, we need to set up a device controller to perform commissioning and cluster control. @@ -225,7 +249,9 @@ remote device, as well as the network credentials to use. The command below uses the default values hard-coded into the debug versions of the ESP32 all-clusters-app to commission it onto a Wi-Fi network: + ``` $ ./out/debug/chip-tool pairing ble-wifi 12344321 ${SSID} ${PASSWORD} 20202021 3840 + ``` Parameters: @@ -240,6 +266,8 @@ Parameters: To use the Client to send Matter commands, run the built executable and pass it the target cluster name, the target command name as well as an endpoint id. + ``` $ ./out/debug/chip-tool onoff on 12344321 2 + ``` The client will send a single command packet and then exit. diff --git a/examples/bridge-app/linux/README.md b/examples/bridge-app/linux/README.md index 5ff4087b7d89c0..9960be56f504a3 100644 --- a/examples/bridge-app/linux/README.md +++ b/examples/bridge-app/linux/README.md @@ -112,20 +112,26 @@ value/label pair `"room"`/`[light name]`. - Install tool chain + ``` $ sudo apt-get install git gcc g++ python pkg-config libssl-dev libdbus-1-dev libglib2.0-dev ninja-build python3-venv python3-dev unzip + ``` - Build the example application: + ``` $ cd ~/connectedhomeip/examples/bridge-app/linux $ git submodule update --init $ source third_party/connectedhomeip/scripts/activate.sh $ gn gen out/debug $ ninja -C out/debug + ``` - To delete generated executable, libraries and object files use: + ``` $ cd ~/connectedhomeip/examples/bridge-app/linux $ rm -rf out/ + ``` @@ -151,6 +157,7 @@ value/label pair `"room"`/`[light name]`. number after `hci` is the bluetooth device number, `1` in this example. + ``` $ hciconfig hci1: Type: Primary Bus: USB BD Address: 00:1A:7D:AA:BB:CC ACL MTU: 310:10 SCO MTU: 64:8 @@ -163,13 +170,16 @@ value/label pair `"room"`/`[light name]`. UP RUNNING PSCAN ISCAN RX bytes:8609495 acl:14 sco:0 events:217484 errors:0 TX bytes:92185 acl:20 sco:0 commands:5259 errors:0 + ``` - Run Linux Bridge Example App + ``` $ cd ~/connectedhomeip/examples/bridge-app/linux $ sudo out/debug/chip-bridge-app --ble-device [bluetooth device number] # In this example, the device we want to use is hci1 $ sudo out/debug/chip-bridge-app --ble-device 1 + ``` - Test the device using ChipDeviceController on your laptop / workstation etc. diff --git a/examples/chip-tool/README.md b/examples/chip-tool/README.md index b825b5b307612b..8911d648f06d28 100644 --- a/examples/chip-tool/README.md +++ b/examples/chip-tool/README.md @@ -67,40 +67,52 @@ remote device, as well as the network credentials to use. The command below uses the default values hard-coded into the debug versions of the ESP32 all-clusters-app to commission it onto a Wi-Fi network: + ``` $ chip-tool pairing ble-wifi ${NODE_ID_TO_ASSIGN} ${SSID} ${PASSWORD} 20202021 3840 + ``` where: -- \${NODE_ID_TO_ASSIGN} (which must be a decimal number or a 0x-prefixed hex +- \${NODE_ID_TO_ASSIGN} (which must be a decimal number or a `0x`-prefixed hex number) is the node id to assign to the node being commissioned. -- \${SSID} is the Wi-Fi SSID either as a string, or in the form hex:XXXXXXXX +- \${SSID} is the Wi-Fi SSID either as a string, or in the form `hex:XXXXXXXX` where the bytes of the SSID are encoded as two-digit hex numbers. - \${PASSWORD} is the Wi-Fi password, again either as a string or as hex data For example: + ``` $ chip-tool pairing ble-wifi 0x11 xyz secret 20202021 3840 + ``` or equivalently: + ``` $ chip-tool pairing ble-wifi 17 hex:787980 hex:736563726574 20202021 3840 + ``` #### Pair a device over IP The command below will discover devices and try to pair with the first one it discovers using the provided setup code. + ``` $ chip-tool pairing onnetwork ${NODE_ID_TO_ASSIGN} 20202021 + ``` The command below will discover devices with long discriminator 3840 and try to pair with the first one it discovers using the provided setup code. + ``` $ chip-tool pairing onnetwork-long ${NODE_ID_TO_ASSIGN} 20202021 3840 + ``` The command below will discover devices based on the given QR code (which devices log when they start up) and try to pair with the first one it discovers. + ``` $ chip-tool pairing qrcode ${NODE_ID_TO_ASSIGN} MT:####### + ``` In all these cases, the device will be assigned node id `${NODE_ID_TO_ASSIGN}` (which must be a decimal number or a 0x-prefixed hex number). @@ -117,11 +129,15 @@ Attestation Verification. It will also discover devices with long discriminator 3840 and try to pair with the first one it discovers using the provided setup code. + ``` $ chip-tool pairing onnetwork-long ${NODE_ID_TO_ASSIGN} 20202021 3840 --paa-trust-store-path path/to/PAAs + ``` ### Forget the currently-commissioned device + ``` $ chip-tool pairing unpair + ``` ## Using the Client to Send Matter Commands @@ -130,7 +146,9 @@ the target cluster name, the target command name as well as an endpoint id. The endpoint id must be between 1 and 240. + ``` $ chip-tool onoff on 1 + ``` The client will send a single command packet and then exit. @@ -167,35 +185,45 @@ must be configured appropriately. To configure the client please use the groupsettings option + ``` $ chip-tool groupsettings + ``` A group with a valid encryption key needs to be set. The groupid and the encryption key must match the one configured on the end device. To add a group + ``` $ chip-tool groupsettings add-group TestName 0x1010 + ``` To add a keyset + ``` $ chip-tool groupsettings add-keyset 0xAAAA 0 0x000000000021dfe0 hex:d0d1d2d3d4d5d6d7d8d9dadbdcdddedf + ``` Take note that the epoch key must be in hex form with the 'hex:' prefix Finally to bind the keyset to the group + ``` $ chip-tool groupsettings bind-keyset 0x1010 0xAAAA + ``` ## Using the Client to Send Group (Multicast) Matter Commands To use the Client to send Matter commands, run the built executable and pass it the target cluster name, the target command name, the Group Id in Node Id form -(0xffffffffffffXXXX) and an unused endpoint Id. Take note that Only commands and -attributes write can be send with Group Id. +(`0xffffffffffffXXXX`) and an unused endpoint Id. Take note that Only commands +and attributes write can be send with Group Id. E.G. sending to group Id 0x0025 + ``` $ chip-tool onoff on 0xffffffffffff0025 1 + ``` The client will send a single multicast command packet and then exit. @@ -204,7 +232,9 @@ The client will send a single multicast command packet and then exit. To get the list of supported clusters, run the built executable without any arguments. + ``` $ chip-tool + ``` Example output: @@ -236,25 +266,33 @@ Usage: To get the list of commands for a specific cluster, run the built executable with the target cluster name. + ``` $ chip-tool onoff + ``` ### How to get the list of supported attributes for a specific cluster To the the list of attributes for a specific cluster, run the built executable with the target cluster name and the `read` command name. + ``` $ chip-tool onoff read + ``` ### How to get the list of parameters for a command To get the list of parameters for a specific command, run the built executable with the target cluster name and the target command name + ``` $ chip-tool onoff on + ``` ### Run a test suite against a paired peer device + ``` $ chip-tool tests Test_TC_OO_1_1 + ``` ## Using the Client for Setup Payload @@ -263,26 +301,36 @@ with the target cluster name and the target command name To parse a setup code, run the built executable with the `payload` cluster name and the `parse-setup-payload` command + ``` $ chip-tool payload parse-setup-payload code + ``` #### QR Code + ``` $ chip-tool payload parse-setup-payload "MT:#####" + ``` #### QR Code with optional Vendor Info + ``` $ chip-tool payload parse-setup-payload "MT:#####" + ``` #### Manual Setup Code + ``` $ chip-tool payload parse-setup-payload "#####" + ``` # Using the Client for Additional Data Payload To parse an additional data payload, run the built executable with the `payload` cluster name and the `parse-additional-data-payload` command + ``` $ chip-tool payload parse-additional-data-payload "#####" + ``` # Command Reference diff --git a/examples/common/pigweed/rpc_console/README.md b/examples/common/pigweed/rpc_console/README.md index 7ba3a4117294b8..09226c2eec1ceb 100644 --- a/examples/common/pigweed/rpc_console/README.md +++ b/examples/common/pigweed/rpc_console/README.md @@ -18,34 +18,47 @@ files required for CHIP. If this is the first time using the checkout the environment must first be bootstrapped to install all dependencies. + ``` $ source /scripts/bootstrap.sh + ``` If bootstrap has previously been run, then simply activate. + ``` $ source /scripts/activate.sh + ``` The python console is built and installed in the venv using gn: + ``` $ cd /examples/common/pigweed/rpc_console $ gn gen out/debug $ ninja -C out/debug + ``` After building the output directory also contains a folder (chip_rpc_console_wheels), with all the wheels required for the tool. These can be used to install the console without needing the sdk. Simply install all the wheels in the folder: + + ``` $ cd /examples/common/pigweed/rpc_console/out/debug $ pip install chip_rpc_console_wheels/*.whl + ``` ## Running To start the console provide the path to the device, for example: + ``` $ chip-console --device /dev/ttyUSB0 + ``` Note that `chip-console` is an entry point for chip_rpc.console and could also be run with `python -m chip_rpc.console`. An example RPC command: + ```python $ rpcs.chip.rpc.Device.GetDeviceInfo() + ``` diff --git a/examples/ipv6only-app/esp32/README.md b/examples/ipv6only-app/esp32/README.md index 0bc7ef61eef976..ad7f47c8295cc9 100644 --- a/examples/ipv6only-app/esp32/README.md +++ b/examples/ipv6only-app/esp32/README.md @@ -23,6 +23,7 @@ step. To install these components manually, follow these steps: - Clone the Espressif ESP-IDF and checkout [v4.4 release](https://github.com/espressif/esp-idf/releases/tag/v4.4) + ``` $ mkdir ${HOME}/tools $ cd ${HOME}/tools $ git clone https://github.com/espressif/esp-idf.git @@ -30,10 +31,13 @@ step. To install these components manually, follow these steps: $ git checkout v4.4 $ git submodule update --init $ ./install.sh + ``` - Install ninja-build + ``` $ sudo apt-get install ninja-build + ``` ### To build the application, follow these steps: @@ -42,29 +46,39 @@ make sure the IDF_PATH has been exported(See the manual setup steps above). - Setting up the environment + ``` $ cd ${HOME}/tools/esp-idf $ ./install.sh $ . ./export.sh $ cd {path-to-connectedhomeip} + ``` To download and install packages. + ``` $ source ./scripts/bootstrap.sh $ source ./scripts/activate.sh + ``` If packages are already installed then simply activate them. + ``` $ source ./scripts/activate.sh + ``` - Select IDF Target + ``` $ idf.py set-target esp32(or esp32c3) + ``` - Configuration Options To choose from the different configuration options, run menuconfig + ``` $ idf.py menuconfig + ``` This example uses UART0 for serial communication. You can change this through `PW RPC Example Configuration`. As a result, the console has been shifted to UART1 @@ -84,7 +98,9 @@ make sure the IDF_PATH has been exported(See the manual setup steps above). before flashing. For ESP32-DevKitC devices this is labeled in the [functional description diagram](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-devkitc.html#functional-description). + ``` $ idf.py flash -p /dev/tty.SLAB_USBtoUART + ``` Note: Some users might have to install the [VCP driver](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers) @@ -96,10 +112,13 @@ Build or install the [rpc console](../../common/pigweed/rpc_console/README.md) Start the console: + ``` $ chip-console --device /dev/ttyUSB0 -b 115200 + ``` An example flow of performing a scan, connecting, and getting the IPv6 address: + ``` scan = rpcs.chip.rpc.WiFi.StartScan(pw_rpc_timeout_s=5) ap = next(filter(lambda a: b"SSID\000" in a.ssid, next(scan.responses()).aps)) @@ -107,3 +126,4 @@ An example flow of performing a scan, connecting, and getting the IPv6 address: rpcs.chip.rpc.WiFi.Connect(connect, pw_rpc_timeout_s=10) rpcs.chip.rpc.WiFi.GetIP6Address() + ``` diff --git a/examples/lighting-app/bouffalolab/bl602/README.md b/examples/lighting-app/bouffalolab/bl602/README.md index b11e98aa1ed29d..8cb3295646a644 100644 --- a/examples/lighting-app/bouffalolab/bl602/README.md +++ b/examples/lighting-app/bouffalolab/bl602/README.md @@ -14,12 +14,16 @@ Generated files + ``` connectedhomeip/out/lighting_app_bl602/chip-bl602-lighting-example.bin + ``` - To delete generated executable, libraries and object files use: - $ cd ~/connectedhomeip/ - $ rm -rf out/ + ``` + $ cd ~/connectedhomeip/ + $ rm -rf out/ + ``` ## Flash @@ -32,19 +36,24 @@ commissioning and cluster control. - Set up python controller. + ``` $ cd {path-to-connectedhomeip} $ ./scripts/build_python.sh -m platform + ``` - Execute the controller. + ``` $ source ./out/python_env/bin/activate $ chip-device-ctrl + ``` ### Commissioning over BLE - Establish the secure session over BLE. BLE is the default mode in the application and is configurable through menuconfig. + ``` - chip-device-ctrl > ble-scan - chip-device-ctrl > set-pairing-wifi-credential TESTSSID P455W4RD - chip-device-ctrl > connect -ble 3904 20202021 135246 @@ -58,6 +67,7 @@ commissioning and cluster control. We have chosen a random node ID which is 135246. 4. TESTSSID : Wi-Fi SSID 5. P455W4RD : Wi-Fi Password + ``` ### Cluster control diff --git a/examples/lighting-app/efr32/README.md b/examples/lighting-app/efr32/README.md index db44ef9c3ac2c6..79c2831ad3dff4 100644 --- a/examples/lighting-app/efr32/README.md +++ b/examples/lighting-app/efr32/README.md @@ -54,9 +54,9 @@ Silicon Labs platform. - Install some additional tools(likely already present for CHIP developers): -#Linux \$ sudo apt-get install git libwebkitgtk-1.0-0 ninja-build +#Linux `sudo apt-get install git libwebkitgtk-1.0-0 ninja-build` -#Mac OS X \$ brew install ninja +#Mac OS X `brew install ninja` - Supported hardware: @@ -80,55 +80,73 @@ Silicon Labs platform. * Build the example application: + ``` cd ~/connectedhomeip ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32/ ./out/lighting-app BRD4161A + ``` - To delete generated executable, libraries and object files use: + ``` $ cd ~/connectedhomeip $ rm -rf ./out/ + ``` OR use GN/Ninja directly + ``` $ cd ~/connectedhomeip/examples/lighting-app/efr32 $ git submodule update --init $ source third_party/connectedhomeip/scripts/activate.sh $ export EFR32_BOARD=BRD4161A $ gn gen out/debug $ ninja -C out/debug + ``` - To delete generated executable, libraries and object files use: + ``` $ cd ~/connectedhomeip/examples/lighting-app/efr32 $ rm -rf out/ + ``` * Build the example as Sleepy End Device (SED) + ``` $ ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32/ ./out/lighting-app_SED BRD4161A --sed + ``` or use gn as previously mentioned but adding the following arguments: + ``` $ gn gen out/debug '--args=efr32_board="BRD4161A" enable_sleepy_device=true chip_openthread_ftd=false' + ``` * Build the example with pigweed RPC + ``` $ ./scripts/examples/gn_efr32_example.sh examples/lighting-app/efr32/ out/lighting_app_rpc BRD4161A 'import("//with_pw_rpc.gni")' + ``` or use GN/Ninja Directly + ``` $ cd ~/connectedhomeip/examples/lighting-app/efr32 $ git submodule update --init $ source third_party/connectedhomeip/scripts/activate.sh $ export EFR32_BOARD=BRD4161A $ gn gen out/debug --args='import("//with_pw_rpc.gni")' $ ninja -C out/debug + ``` [Running Pigweed RPC console](#running-pigweed-rpc-console) For more build options, help is provided when running the build script without arguments + ``` ./scripts/examples/gn_efr32_example.sh + ``` @@ -136,8 +154,10 @@ arguments - On the command line: + ``` $ cd ~/connectedhomeip/examples/lighting-app/efr32 $ python3 out/debug/chip-efr32-lighting-example.flash.py + ``` - Or with the Ozone debugger, just load the .out file. @@ -165,14 +185,18 @@ after flashing the .out file. * Install the J-Link software + ``` $ cd ~/Downloads $ sudo dpkg -i JLink_Linux_V*_x86_64.deb + ``` * In Linux, grant the logged in user the ability to talk to the development hardware via the linux tty device (/dev/ttyACMx) by adding them to the dialout group. + ``` $ sudo usermod -a -G dialout ${USER} + ``` Once the above is complete, log output can be viewed using the JLinkExe tool in combination with JLinkRTTClient as follows: @@ -181,15 +205,21 @@ combination with JLinkRTTClient as follows: For MG12 use: + ``` $ JLinkExe -device EFR32MG12PXXXF1024 -if JTAG -speed 4000 -autoconnect 1 + ``` For MG21 use: + ``` $ JLinkExe -device EFR32MG21AXXXF1024 -if SWD -speed 4000 -autoconnect 1 + ``` - In a second terminal, run the JLinkRTTClient to view logs: + ``` $ JLinkRTTClient + ``` @@ -273,12 +303,12 @@ combination with JLinkRTTClient as follows: need to add a static ipv6 addresses on both device and then an ipv6 route to the border router on your PC -#On Border Router: \$ sudo ip addr add dev 2002::2/64 +#On Border Router: `sudo ip addr add dev 2002::2/64` -#On PC(Linux): \$ sudo ip addr add dev 2002::1/64 +#On PC(Linux): `sudo ip addr add dev 2002::1/64` -#Add Ipv6 route on PC(Linux) \$ sudo ip route add /64 -via 2002::2 +#Add Ipv6 route on PC(Linux) +`sudo ip route add /64 via 2002::2` @@ -354,27 +384,35 @@ passed to the build scripts. ### Disabling logging -chip_progress_logging, chip_detail_logging, chip_automation_logging +`chip_progress_logging, chip_detail_logging, chip_automation_logging` + ``` $ ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32 ./out/lighting-app BRD4164A "chip_detail_logging=false chip_automation_logging=false chip_progress_logging=false" + ``` ### Debug build / release build -is_debug +`is_debug` + ``` $ ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32 ./out/lighting-app BRD4164A "is_debug=false" + ``` ### Disabling LCD -show_qr_code +`show_qr_code` + ``` $ ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32 ./out/lighting-app BRD4164A "show_qr_code=false" + ``` ### KVS maximum entry count -kvs_max_entries +`kvs_max_entries` + ``` Set the maximum Kvs entries that can be stored in NVM (Default 75) Thresholds: 30 <= kvs_max_entries <= 255 $ ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32 ./out/lighting-app BRD4164A kvs_max_entries=50 + ``` diff --git a/examples/lighting-app/mbed/README.md b/examples/lighting-app/mbed/README.md index 8c39ce7b772414..02a41c085e68d9 100644 --- a/examples/lighting-app/mbed/README.md +++ b/examples/lighting-app/mbed/README.md @@ -1,6 +1,4 @@ -

- ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png)

Matter Arm Mbed OS Lighting Example Application

@@ -87,7 +85,9 @@ the network. Before building the example, check out the Matter repository and sync submodules using the following command: + ``` $ git submodule update --init + ``` Building the example application requires the use of **ARM Mbed-OS** sources and the **arm-none-gnu-eabi** toolchain. @@ -223,13 +223,17 @@ open a terminal session and connect to the serial port of the device. You can use **mbed-tools** for this purpose ([mbed-tools](https://github.com/ARMmbed/mbed-tools)): + ``` mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off + ``` After device reset these lines should be visible: + ``` [INFO][CHIP]: [-]Mbed lighting-app example application start ... [INFO][CHIP]: [-]Mbed lighting-app example application run + ``` The lighting-app application launched correctly and you can follow traces in the terminal. @@ -266,24 +270,34 @@ parameters as arguments: Example: + ``` chip-console -d /dev/ttyUSB0 -b 115200 -o /tmp/pw_rpc.out + ``` To control the lighting type the following command, where you define if 'on' state is true or false: + ``` In [1]: rpcs.chip.rpc.Lighting.Set(on=True) + ``` The response from the device should be: + ``` Out[1]: (Status.OK, pw.protobuf.Empty()) + ``` To check the lighting state type the following command: + ``` In [1]: rpcs.chip.rpc.Lighting.Get() + ``` The response from the device should contain the current lighting state: + ``` Out[1]: Status.OK, chip.rpc.LightingState(on=True)) + ``` For more details about RPC console and supported services visit [CHIP RPC console](../../common/pigweed/rpc_console/README.md). diff --git a/examples/lighting-app/nrfconnect/README.md b/examples/lighting-app/nrfconnect/README.md index e2e4c4ae5b88c4..ff8013e360ad93 100644 --- a/examples/lighting-app/nrfconnect/README.md +++ b/examples/lighting-app/nrfconnect/README.md @@ -5,10 +5,8 @@ dimmable light bulb. It uses buttons to test changing the lighting and device states and LEDs to show the state of these changes. You can use this example as a reference for creating your own application. -

- Nordic Semiconductor logo - nRF52840 DK -

+![Nordic Smiconductor logo](../../platform/nrfconnect/doc/images/Logo_RGB_H-small.png) +![nRF52840 DK](../../platform/nrfconnect/doc/images/nRF52840-DK-small.png) The example is based on [Matter](https://github.com/project-chip/connectedhomeip) and Nordic @@ -265,7 +263,9 @@ NFC. Before building the example, check out the Matter repository and sync submodules using the following command: + ``` $ git submodule update --init + ``` The example requires a specific revision of the nRF Connect SDK. You can either install it along with the related tools directly on your system or use a Docker @@ -283,18 +283,24 @@ To use the Docker container for setup, complete the following steps: 1. If you do not have the nRF Connect SDK installed yet, create a directory for it by running the following command: + ``` $ mkdir ~/nrfconnect + ``` 2. Download the latest version of the nRF Connect SDK Docker image by running the following command: + ``` $ docker pull nordicsemi/nrfconnect-chip + ``` 3. Start Docker with the downloaded image by running the following command, customized to your needs as described below: + ``` $ docker run --rm -it -e RUNAS=$(id -u) -v ~/nrfconnect:/var/ncs -v ~/connectedhomeip:/var/chip \ -v /dev/bus/usb:/dev/bus/usb --device-cgroup-rule "c 189:* rmw" nordicsemi/nrfconnect-chip + ``` In this command: @@ -314,8 +320,10 @@ To use the Docker container for setup, complete the following steps: 4. Update the nRF Connect SDK to the most recent supported revision, by running the following command: + ``` $ cd /var/chip $ python3 scripts/setup/nrfconnect/update_ncs.py --update + ``` Now you can proceed with the [Building](#building) instruction. @@ -342,16 +350,20 @@ To use the native shell for setup, complete the following steps: nRF Connect SDK installation directory, and _toolchain-dir_ with the path to GNU Arm Embedded Toolchain. + ``` $ source nrfconnect-dir/zephyr/zephyr-env.sh $ export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb $ export GNUARMEMB_TOOLCHAIN_PATH=toolchain-dir + ``` 4. Update the nRF Connect SDK to the most recent supported revision by running the following command (replace _matter-dir_ with the path to Matter repository directory): + ``` $ cd matter-dir $ python3 scripts/setup/nrfconnect/update_ncs.py --update + ``` Now you can proceed with the [Building](#building) instruction. @@ -366,13 +378,17 @@ environment: 1. Navigate to the example's directory: + ``` $ cd examples/lighting-app/nrfconnect + ``` 2. Run the following command to build the example, with _build-target_ replaced with the build target name of the Nordic Semiconductor's kit you own, for example `nrf52840dk_nrf52840`: - $ west build -b build-target + ``` + $ west build -b build-target + ``` You only need to specify the build target on the first build. See [Requirements](#requirements) for the build target names of compatible kits. @@ -385,14 +401,18 @@ If you're planning to build the example for a different kit or make changes to the configuration, remove all build artifacts before building. To do so, use the following command: + ``` $ rm -r build + ``` ### Building with release configuration To build the example with release configuration that disables the diagnostic features like logs and command-line interface, run the following command: + ``` $ west build -b build-target -- -DCONF_FILE=prj_release.conf + ``` Remember to replace _build-target_ with the build target name of the Nordic Semiconductor's kit you own. @@ -405,7 +425,9 @@ host computer. To build the example with the RPC server, run the following command with _build-target_ replaced with the build target name of the Nordic Semiconductor's kit you own: + ``` $ west build -b build-target -- -DOVERLAY_CONFIG=rpc.overlay + ``` ### Building with Device Firmware Upgrade support @@ -415,13 +437,17 @@ To enable DFU over Bluetooth LE, run the following command with _build-target_ replaced with the build target name of the Nordic Semiconductor kit you are using (for example `nrf52840dk_nrf52840`): + ``` $ west build -b build-target -- -DCONFIG_CHIP_DFU_OVER_BT_SMP=y + ``` To completely disable support for both DFU methods, run the following command with _build-target_ replaced with the build target name of the Nordic Semiconductor kit you are using (for example `nrf52840dk_nrf52840`): + ``` $ west build -b build-target -- -DCONF_FILE=prj_no_dfu.conf + ``` > **Note**: > @@ -470,7 +496,9 @@ using the menuconfig utility. To open the menuconfig utility, run the following command from the example directory: + ``` $ west build -b build-target -t menuconfig + ``` Remember to replace _build-target_ with the build target name of the Nordic Semiconductor's kit you own. @@ -527,7 +555,9 @@ the nRF52840 Dongle. To flash the application to the device, use the west tool and run the following command from the example directory: + ``` $ west flash --erase + ``` If you have multiple development kits connected, west will prompt you to pick the correct one. @@ -535,7 +565,9 @@ the correct one. To debug the application on target, run the following command from the example directory: + ``` $ west debug + ``` @@ -575,13 +607,17 @@ Build or install the [rpc console](../../common/pigweed/rpc_console/README.md) Start the console + ``` $ chip-console --device /dev/ttyUSB0 + ``` From within the console you can then invoke rpcs: + ```python rpcs.chip.rpc.Lighting.Get() rpcs.chip.rpc.Lighting.Set(on=True, level=128, color=protos.chip.rpc.LightingColor(hue=5, saturation=5)) + ``` ## Device Tracing diff --git a/examples/lock-app/efr32/README.md b/examples/lock-app/efr32/README.md index 61c53124287916..ab1fe655e5a037 100644 --- a/examples/lock-app/efr32/README.md +++ b/examples/lock-app/efr32/README.md @@ -52,9 +52,9 @@ Silicon Labs platform. - Install some additional tools(likely already present for CHIP developers): -#Linux \$ sudo apt-get install git libwebkitgtk-1.0-0 ninja-build +#Linux `sudo apt-get install git libwebkitgtk-1.0-0 ninja-build` -#Mac OS X \$ brew install ninja +#Mac OS X `brew install ninja` - Supported hardware: @@ -78,55 +78,73 @@ Silicon Labs platform. * Build the example application: + ``` cd ~/connectedhomeip ./scripts/examples/gn_efr32_example.sh ./examples/lock-app/efr32/ ./out/lock_app BRD4161A + ``` - To delete generated executable, libraries and object files use: + ``` $ cd ~/connectedhomeip $ rm -rf ./out/ + ``` OR use GN/Ninja directly + ``` $ cd ~/connectedhomeip/examples/lock-app/efr32 $ git submodule update --init $ source third_party/connectedhomeip/scripts/activate.sh $ export EFR32_BOARD=BRD4161A $ gn gen out/debug --args="efr32_sdk_root=\"${EFR32_SDK_ROOT}\" efr32_board=\"${EFR32_BOARD}\"" $ ninja -C out/debug + ``` - To delete generated executable, libraries and object files use: + ``` $ cd ~/connectedhomeip/examples/lock-app/efr32 $ rm -rf out/ + ``` * Build the example as Sleepy End Device (SED) + ``` $ ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32/ ./out/lighting-app_SED BRD4161A --sed + ``` or use gn as previously mentioned but adding the following arguments: + ``` $ gn gen out/debug '--args=efr32_board="BRD4161A" enable_sleepy_device=true chip_openthread_ftd=false' + ``` * Build the example with pigweed RCP + ``` $ ./scripts/examples/gn_efr32_example.sh examples/lock-app/efr32/ out/lock_app_rpc BRD4161A 'import("//with_pw_rpc.gni")' + ``` or use GN/Ninja Directly + ``` $ cd ~/connectedhomeip/examples/lock-app/efr32 $ git submodule update --init $ source third_party/connectedhomeip/scripts/activate.sh $ export EFR32_BOARD=BRD4161A $ gn gen out/debug --args='import("//with_pw_rpc.gni")' $ ninja -C out/debug + ``` [Running Pigweed RPC console](#running-pigweed-rpc-console) For more build options, help is provided when running the build script without arguments + ``` ./scripts/examples/gn_efr32_example.sh + ``` @@ -134,8 +152,10 @@ arguments - On the command line: + ``` $ cd ~/connectedhomeip/examples/lock-app/efr32 $ python3 out/debug/chip-efr32-lock-example.flash.py + ``` - Or with the Ozone debugger, just load the .out file. @@ -163,14 +183,18 @@ after flashing the .out file. * Install the J-Link software + ``` $ cd ~/Downloads $ sudo dpkg -i JLink_Linux_V*_x86_64.deb + ``` * In Linux, grant the logged in user the ability to talk to the development hardware via the linux tty device (/dev/ttyACMx) by adding them to the dialout group. + ``` $ sudo usermod -a -G dialout ${USER} + ``` Once the above is complete, log output can be viewed using the JLinkExe tool in combination with JLinkRTTClient as follows: @@ -179,15 +203,21 @@ combination with JLinkRTTClient as follows: For MG12 use: + ``` $ JLinkExe -device EFR32MG12PXXXF1024 -if JTAG -speed 4000 -autoconnect 1 + ``` For MG21 use: + ``` $ JLinkExe -device EFR32MG21AXXXF1024 -if SWD -speed 4000 -autoconnect 1 + ``` - In a second terminal, run the JLinkRTTClient to view logs: + ``` $ JLinkRTTClient + ``` @@ -306,27 +336,35 @@ features can easily be toggled on or off. Here is a short list of options : ### Disabling logging -chip_progress_logging, chip_detail_logging, chip_automation_logging +`chip_progress_logging, chip_detail_logging, chip_automation_logging` + ``` $ ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32 ./out/lighting-app BRD4164A "chip_detail_logging=false chip_automation_logging=false chip_progress_logging=false" + ``` ### Debug build / release build -is_debug +`is_debug` + ``` $ ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32 ./out/lighting-app BRD4164A "is_debug=false" + ``` ### Disabling LCD -show_qr_code +`show_qr_code` + ``` $ ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32 ./out/lighting-app BRD4164A "show_qr_code=false" + ``` ### KVS maximum entry count -kvs_max_entries +`kvs_max_entries` + ``` Set the maximum Kvs entries that can be stored in NVM (Default 75) Thresholds: 30 <= kvs_max_entries <= 255 $ ./scripts/examples/gn_efr32_example.sh ./examples/lighting-app/efr32 ./out/lighting-app BRD4164A kvs_max_entries=50 + ``` diff --git a/examples/lock-app/mbed/README.md b/examples/lock-app/mbed/README.md index 7f6db4d2886c4a..cc48cebeb68ae9 100644 --- a/examples/lock-app/mbed/README.md +++ b/examples/lock-app/mbed/README.md @@ -1,6 +1,4 @@ -

- ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png)

Matter Arm Mbed OS Lock Example Application

diff --git a/examples/ota-provider-app/linux/README.md b/examples/ota-provider-app/linux/README.md index 5eff4f0532f938..c993f77c1081e0 100644 --- a/examples/ota-provider-app/linux/README.md +++ b/examples/ota-provider-app/linux/README.md @@ -101,7 +101,7 @@ out/chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "auth to all nodes for the OTA Provider cluster (0x0029) on every endpoint In the example above, the provider is on fabric index 1 with provider node ID -being 0xDEADBEEF on endpoint 0. +being `0xDEADBEEF` on endpoint 0. ## Current Limitations diff --git a/examples/ota-requestor-app/linux/README.md b/examples/ota-requestor-app/linux/README.md index fd49cdaee0357b..a306eb1e3899dd 100644 --- a/examples/ota-requestor-app/linux/README.md +++ b/examples/ota-requestor-app/linux/README.md @@ -251,7 +251,7 @@ out/chip-tool otasoftwareupdaterequestor announce-ota-provider 0xDEADBEEF 0 0 0 The OTA Requestor application with node ID 0x1234567890 will process this command and send a QueryImage command to the OTA Provider with node ID -0xDEADBEEF, as specified in the `AnnounceOTAProvider` command. +`0xDEADBEEF`, as specified in the `AnnounceOTAProvider` command. ### Trigger using DefaultOTAProviders attribute @@ -309,7 +309,7 @@ out/chip-tool otasoftwareupdaterequestor write default-ota-providers '[{"fabricI Every 60 seconds from when the OTA Requestor application has launched, the OTA Requestor application with node ID 0x1234567890 will send a QueryImage command -to the OTA Provider with node ID 0xDEADBEEF, as specified in the +to the OTA Provider with node ID `0xDEADBEEF`, as specified in the `DefaultOTAProviders` attribute. ## DefaultOTAProviders attribute diff --git a/examples/ota-requestor-app/mbed/README.md b/examples/ota-requestor-app/mbed/README.md index 7c26810e345230..6e6fd542808811 100644 --- a/examples/ota-requestor-app/mbed/README.md +++ b/examples/ota-requestor-app/mbed/README.md @@ -1,6 +1,4 @@ -

- ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png)

Matter Arm Mbed OS Lock Example Application

diff --git a/examples/pigweed-app/mbed/README.md b/examples/pigweed-app/mbed/README.md index 44612c82a3edef..19f9a13012dc1e 100644 --- a/examples/pigweed-app/mbed/README.md +++ b/examples/pigweed-app/mbed/README.md @@ -1,6 +1,4 @@ -

- ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png)

Matter Arm Mbed OS Pigweed Example Application

diff --git a/examples/shell/mbed/README.md b/examples/shell/mbed/README.md index e2b8e119dfa219..02738126c8e0de 100644 --- a/examples/shell/mbed/README.md +++ b/examples/shell/mbed/README.md @@ -1,6 +1,4 @@ -

- ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png)

Matter Arm Mbed OS Shell Example Application

diff --git a/integrations/docker/images/chip-build-crosscompile/README.md b/integrations/docker/images/chip-build-crosscompile/README.md index 92674967a5cbeb..d27fc2fe601233 100644 --- a/integrations/docker/images/chip-build-crosscompile/README.md +++ b/integrations/docker/images/chip-build-crosscompile/README.md @@ -44,7 +44,7 @@ image yet), the following symlinks are required: - `usr/lib/arm-linux-gnueabihf` to `usr/lib/armv7-linux-gnueabihf` - `usr/include/arm-linux-gnueabihf` to `usr/lib/armv7-linux-gnueabihf` -Once the sysroot is on the host machine, create the corresponding tar.xz file: +Once the sysroot is on the host machine, create the corresponding `tar.xz` file: ``` tar cvfJ ubuntu-21.04-aarch64-sysroot.tar.xz ubuntu-21.04-aarch64-sysroot diff --git a/src/README.md b/src/README.md index 5d25de7f39f6d4..ad40f1a0807d02 100644 --- a/src/README.md +++ b/src/README.md @@ -2,7 +2,7 @@ ### Directory Structure -The CHIP src directory is structured as follows: +The CHIP `src` directory is structured as follows: | File / Folder | Contents | | ------------- | -------------------------------------------------- | diff --git a/src/lwip/patches/README.md b/src/lwip/patches/README.md index 2561a71bd574f9..b41708670b2ef9 100644 --- a/src/lwip/patches/README.md +++ b/src/lwip/patches/README.md @@ -24,11 +24,11 @@ recent API change on upstream LwIP. The previous version of this function is ### Malformed neighbor solicitation packet fix - issue raised here - https://github.com/project-chip/connectedhomeip/issues/9791 + [Issue 9791](https://github.com/project-chip/connectedhomeip/issues/9791) - fixed in matter fork by - https://github.com/project-chip/connectedhomeip/pull/10160 + [Issue 10160](https://github.com/project-chip/connectedhomeip/pull/10160) - fixed in upstream by - https://git.savannah.nongnu.org/cgit/lwip.git/commit/?id=bc08c1d2b79b4763fc0f8f0bf0ed58e0c2899b3a + [PATCH](https://git.savannah.nongnu.org/cgit/lwip.git/commit/?id=bc08c1d2b79b4763fc0f8f0bf0ed58e0c2899b3a) ### DHCPv6 DNS bug @@ -37,5 +37,5 @@ stateless, it would set the DNS server as an ipv4 address, which ended up being garbage. This would invalidate the whole DNS table, and lwip does not have a default backup. -- fixed in upstream here: - https://git.savannah.nongnu.org/cgit/lwip.git/commit/?id=941300c21c45a4dbf1c074b29a9ca3c88c9f6553 +- fixed in upstream in this + [commit](https://git.savannah.nongnu.org/cgit/lwip.git/commit/?id=941300c21c45a4dbf1c074b29a9ca3c88c9f6553) diff --git a/src/test_driver/efr32/README.md b/src/test_driver/efr32/README.md index 0f0e2153273b11..9cdad098b1cecd 100644 --- a/src/test_driver/efr32/README.md +++ b/src/test_driver/efr32/README.md @@ -33,9 +33,9 @@ test runner. - Install some additional tools(likely already present for CHIP developers): -#Linux \$ sudo apt-get install git libwebkitgtk-1.0-0 ninja-build +#Linux `sudo apt-get install git libwebkitgtk-1.0-0 ninja-build` -#Mac OS X \$ brew install ninja +#Mac OS X `brew install ninja` - Supported hardware: @@ -59,17 +59,21 @@ test runner. OR use GN/Ninja directly - $ cd ~/connectedhomeip/src/test_driver/efr32/ - $ git submodule update --init - $ source third_party/connectedhomeip/scripts/activate.sh - $ export EFR32_BOARD=BRD4161A - $ gn gen out/debug - $ ninja -C out/debug + ``` + cd ~/connectedhomeip/src/test_driver/efr32/ + git submodule update --init + source third_party/connectedhomeip/scripts/activate.sh + export EFR32_BOARD=BRD4161A + gn gen out/debug + ninja -C out/debug + ``` - To delete generated executable, libraries and object files use: - $ cd ~/connectedhomeip/src/test_driver/efr32/ - $ rm -rf out/ + ``` + cd ~/connectedhomeip/src/test_driver/efr32/ + rm -rf out/ + ``` @@ -77,13 +81,16 @@ OR use GN/Ninja directly Build the runner using gn: - $ gn gen out/debug - $ ninja -C out/debug runner + ``` + gn gen out/debug + ninja -C out/debug runner + ``` The runner will be installed into the venv and python wheels will be packaged in the output folder for deploying. - To run the tests: - \$ python -m nl_test_runner.nl_test_runner -d /dev/ttyACM1 -f - out/debug/chip-efr32-device_tests.s37 -o out.log + ``` + python -m nl_test_runner.nl_test_runner -d /dev/ttyACM1 -f out/debug/chip-efr32-device_tests.s37 -o out.log + ``` diff --git a/src/test_driver/esp32/README.md b/src/test_driver/esp32/README.md index 757a490f90caf9..7c1f0dfb58cd94 100644 --- a/src/test_driver/esp32/README.md +++ b/src/test_driver/esp32/README.md @@ -58,9 +58,13 @@ follow these steps: - Setup ESP32 QEMU. This will build QEMU and install necessary artifacts to run unit tests. - $ source idf.sh - $ ./qemu_setup.sh + ``` + source idf.sh + ./qemu_setup.sh + ``` - Run specific unit tests - $ idf make -C build/chip/src/crypto/tests check + ``` + idf make -C build/chip/src/crypto/tests check + ``` diff --git a/src/test_driver/mbed/integration_tests/README.md b/src/test_driver/mbed/integration_tests/README.md index 4db0e025fdc623..934a22be5bb109 100644 --- a/src/test_driver/mbed/integration_tests/README.md +++ b/src/test_driver/mbed/integration_tests/README.md @@ -1,6 +1,4 @@ -

- ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png)

Matter Arm Mbed OS Integration Tests

diff --git a/src/test_driver/mbed/unit_tests/README.md b/src/test_driver/mbed/unit_tests/README.md index 9d1b02e08c62d3..693b30a119ba88 100644 --- a/src/test_driver/mbed/unit_tests/README.md +++ b/src/test_driver/mbed/unit_tests/README.md @@ -1,6 +1,4 @@ -

- ARM Mbed-OS logo -

+![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png)

Matter Arm Mbed OS Unit Tests Application

@@ -168,28 +166,34 @@ terminal session and connect to the serial port of the device. You can use **mbed-tools** for this purpose ([mbed-tools](https://github.com/ARMmbed/mbed-tools)): + ``` mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off + ``` After device reset these lines should be visible: + ``` [INFO][CHIP]: [-]Mbed unit-tests application start ... [INFO][CHIP]: [-]Mbed unit-tests application run + ``` The unit tests application launched correctly and registered tests are executed. The final result is the number of tests that failed: + ``` [INFO][CHIP]: [-]CHIP test status: 0 + ``` ## Supported devices The application supports building and running on the following mbed-enabled devices: -| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components | -| ----------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [Cypress
Semiconductor](https://www.cypress.com/) | [CY8CPROTO-062-4343W](https://os.mbed.com/platforms/CY8CPROTO-062-4343W/) | `CY8CPROTO_062_4343W` |
CY8CPROTO-062-4343WCY8CPROTO-062-4343W
| :heavy_check_mark: |
LEDs
  • Board has only one usable LED (LED4) which corresponds to USER LED from UI.
Buttons
  • Unused
Slider
  • Unused
| +| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components | +| ----------------------------------------------------- | ------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------ | :----------------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| [Cypress
Semiconductor](https://www.cypress.com/) | [CY8CPROTO-062-4343W](https://os.mbed.com/platforms/CY8CPROTO-062-4343W/) | `CY8CPROTO_062_4343W` | ![CY8CPROTO-062-4343W](https://os.mbed.com/media/cache/platforms/p6_wifi-bt_proto.png.250x250_q85.jpg) | :heavy_check_mark: |
LEDs
  • Board has only one usable LED (LED4) which corresponds to USER LED from UI.
Buttons
  • Unused
Slider
  • Unused
| #### Notes diff --git a/src/trace/README.md b/src/trace/README.md index 64e699d4b08db0..04963e6e8ec2b2 100644 --- a/src/trace/README.md +++ b/src/trace/README.md @@ -7,7 +7,7 @@ execution of the application. It depends on ## How to add trace events 1. Include "trace/trace.h" in the source file. -2. Add "\${chip_root}/src/trace" as deps in BUILD.gn. +2. Add `${chip_root}/src/trace` as deps in BUILD.gn. 3. Add MATTER*TRACE_EVENT*\* in functions to be traced. ## Example