diff --git a/.properties b/.properties index 9b3c7b3df1c..417126f6df3 100644 --- a/.properties +++ b/.properties @@ -1,6 +1,6 @@ id=com.silabs.sdk.stack.super -version=4.0.0 +version=4.0.1 label=Gecko SDK Suite description=Gecko SDK Suite diff --git a/app/bluetooth/bluetooth_production_demos.xml b/app/bluetooth/bluetooth_production_demos.xml index 5eced73b6c4..f379c17bcfe 100644 --- a/app/bluetooth/bluetooth_production_demos.xml +++ b/app/bluetooth/bluetooth_production_demos.xml @@ -4,19 +4,29 @@ - + - + Network Co-Processor (NCP) target application extended with CTE Receiver support. It enables Angle of Arrival (AoA) calculation. Use this application with Direction Finding host examples. + + + + + + + + + + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -24,9 +34,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -34,9 +44,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -44,9 +54,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -54,9 +64,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -64,9 +74,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -74,9 +84,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -84,9 +94,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -94,9 +104,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -104,9 +114,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -114,9 +124,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -124,9 +134,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -134,9 +144,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -144,9 +154,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -154,9 +164,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -164,9 +174,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -174,9 +184,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -184,9 +194,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -194,9 +204,29 @@ - + + + + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. + + + + + + + - + + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. + + + + + + + + + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use Dynamic GATT API. @@ -204,9 +234,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -214,9 +244,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -224,9 +254,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -234,9 +264,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -244,9 +274,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -254,9 +284,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -264,9 +294,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -274,9 +304,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -284,9 +314,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -294,9 +324,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -304,9 +334,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -314,9 +344,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -324,9 +354,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -334,9 +364,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -344,9 +374,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -354,9 +384,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -364,9 +394,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -374,9 +404,9 @@ - + - + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -384,9 +414,29 @@ - + - + + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. + + + + + + + + + + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. + + + + + + + + + Network Co-Processor (NCP) target application. Runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. @@ -394,27 +444,37 @@ - + - + This sample app demonstrates a CTE (Constant Tone Extension) transmitter that can be used as an asset tag in a Direction Finding setup estimating Angle of Arrival (AoA). - + - + This sample app demonstrates a CTE (Constant Tone Extension) transmitter that can be used as an asset tag in a Direction Finding setup estimating Angle of Arrival (AoA). + + + + + + + + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. + + - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -422,9 +482,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -432,9 +492,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -442,9 +502,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -452,9 +512,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -462,9 +522,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -472,9 +532,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -482,9 +542,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -492,9 +552,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -502,9 +562,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -512,9 +572,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -522,9 +582,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -532,9 +592,29 @@ - + + + + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. + + + + + + + - + + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. + + + + + + + + + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -542,9 +622,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED1 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -552,9 +632,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED1 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -562,9 +642,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED1 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -572,9 +652,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED1 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -582,9 +662,9 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED1 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. @@ -592,19 +672,29 @@ - + - + The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED1 on the board. In addition, on the board pressing or releasing BTN0 notifies the app. This is a demonstration of a simple two-way data exchange over GATT. + + + + + + + + + + Demonstrates the features of the EFR32xG24 Dev Kit Board. This can be tested with the EFR Connect mobile app. - + - + This is a Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a Proprietary protocol. To switch it via Bluetooth use the Wireless Gecko smartphone app. To switch it via Proprietary protocol use the Flex (RAIL) - Switch sample app. @@ -612,9 +702,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the mock relative humidity and temperature sensor. @@ -622,9 +712,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the mock relative humidity and temperature sensor. @@ -632,9 +722,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the mock relative humidity and temperature sensor. @@ -642,9 +732,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the mock relative humidity and temperature sensor. @@ -652,9 +742,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the mock relative humidity and temperature sensor. @@ -662,9 +752,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the mock relative humidity and temperature sensor. @@ -672,19 +762,49 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the mock relative humidity and temperature sensor. + + + + + + + + + + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the mock relative humidity and temperature sensor. + + + + + + + + + + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the mock relative humidity and temperature sensor. + + + + + + + + + + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -692,9 +812,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -702,9 +822,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -712,9 +832,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -722,9 +842,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -732,9 +852,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -742,9 +862,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -752,9 +872,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -762,9 +882,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -772,9 +892,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -782,9 +902,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -792,9 +912,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -802,9 +922,9 @@ - + - + Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard. @@ -812,9 +932,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -822,9 +942,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -832,9 +952,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -842,9 +962,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -852,9 +972,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -862,9 +982,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -872,9 +992,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -882,9 +1002,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -892,9 +1012,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -902,9 +1022,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -912,9 +1032,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -922,9 +1042,19 @@ - + - + + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. + + + + + + + + + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -932,9 +1062,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -942,9 +1072,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -952,9 +1082,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -962,9 +1092,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -972,9 +1102,9 @@ - + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -982,9 +1112,29 @@ - + + + + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. + + + + + + + + + + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. + + + + + + + - + This example tests the throughput capabilities of the device and can be used to measure throughput between 2 *EFR32* devices, as well as between a device and a smartphone using EFR Connect mobile app, through the Throughput demo tile. @@ -992,39 +1142,49 @@ - + - - Demonstrates the features of the Thunderboard EFR32BG22 Kit. This can be tested with the Thunderboard mobile app. + + Demonstrates the features of the Thunderboard EFR32BG22 Kit. This can be tested with the EFR Connect mobile app. - + - - Demonstrates the features of the Thunderboard EFR32BG22 Kit. This can be tested with the Thunderboard mobile app. + + Demonstrates the features of the Thunderboard EFR32BG22 Kit. This can be tested with the EFR Connect mobile app. - + - - Demonstrates the features of the Thunderboard Sense 2 Kit. This can be tested with the Thunderboard mobile app. + + Demonstrates the features of the Thunderboard Sense 2 Kit. This can be tested with the EFR Connect mobile app. + + + + + + + + + + Voice over Bluetooth Low Energy sample application. It is supported by Thunderboard Sense 2 and Thunderboard EFR32BG22 boards and demonstrates how to send voice data over GATT, which is acquired from the on-board microphones. - + - + Voice over Bluetooth Low Energy sample application. It is supported by Thunderboard Sense 2 and Thunderboard EFR32BG22 boards and demonstrates how to send voice data over GATT, which is acquired from the on-board microphones. @@ -1032,19 +1192,29 @@ - + - + Voice over Bluetooth Low Energy sample application. It is supported by Thunderboard Sense 2 and Thunderboard EFR32BG22 boards and demonstrates how to send voice data over GATT, which is acquired from the on-board microphones. + + + + + + + + + + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1052,9 +1222,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1062,9 +1232,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1072,9 +1242,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1082,9 +1252,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1092,9 +1262,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1102,9 +1272,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1112,9 +1282,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1122,9 +1292,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1132,9 +1302,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1142,9 +1312,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1152,9 +1322,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1162,9 +1332,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1172,9 +1342,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1182,9 +1352,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1192,9 +1362,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1202,9 +1372,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1212,9 +1382,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1222,9 +1392,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1232,9 +1402,9 @@ - + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. @@ -1242,9 +1412,29 @@ - + + + + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. + + + + + + + + + + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. + + + + + + + - + An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app. diff --git a/app/bluetooth/bluetooth_production_templates.xml b/app/bluetooth/bluetooth_production_templates.xml index 9f400e8802a..7c977094049 100644 --- a/app/bluetooth/bluetooth_production_templates.xml +++ b/app/bluetooth/bluetooth_production_templates.xml @@ -4,8 +4,8 @@ - - + + @@ -17,7 +17,7 @@ - + @@ -30,8 +30,8 @@ - - + + @@ -43,8 +43,8 @@ - - + + @@ -56,8 +56,8 @@ - - + + @@ -69,8 +69,8 @@ - - + + @@ -82,8 +82,8 @@ - - + + @@ -95,8 +95,8 @@ - - + + @@ -108,8 +108,8 @@ - - + + @@ -121,8 +121,8 @@ - - + + @@ -134,8 +134,8 @@ - - + + @@ -147,9 +147,9 @@ - - - + + + @@ -160,9 +160,9 @@ - - - + + + @@ -173,9 +173,9 @@ - - - + + + @@ -186,9 +186,9 @@ - - - + + + @@ -199,8 +199,8 @@ - - + + @@ -212,8 +212,8 @@ - - + + @@ -225,8 +225,8 @@ - - + + @@ -238,9 +238,9 @@ - - - + + + @@ -251,9 +251,9 @@ - - - + + + @@ -264,9 +264,9 @@ - - - + + + @@ -277,9 +277,9 @@ - - - + + + @@ -290,8 +290,8 @@ - - + + @@ -304,7 +304,7 @@ - + @@ -317,7 +317,7 @@ - + @@ -329,8 +329,8 @@ - - + + @@ -342,8 +342,8 @@ - - + + @@ -355,8 +355,8 @@ - - + + @@ -368,8 +368,8 @@ - - + + @@ -381,8 +381,8 @@ - - + + @@ -394,8 +394,8 @@ - - + + @@ -407,8 +407,8 @@ - - + + @@ -416,11 +416,11 @@ - + - + @@ -429,11 +429,11 @@ - + - + @@ -442,11 +442,11 @@ - + - + @@ -455,12 +455,25 @@ + + + + + + + + + + + + + - - + + diff --git a/app/bluetooth/btmesh.properties b/app/bluetooth/btmesh.properties index e4bf5a95fe5..48e72a71f33 100644 --- a/app/bluetooth/btmesh.properties +++ b/app/bluetooth/btmesh.properties @@ -2,10 +2,8 @@ id=com.silabs.stack.btMesh label=Bluetooth Mesh SDK description=Bluetooth Mesh Software Development Kit -version=2.2.0.0 -dependantSdkVersion=3.3.0 -dependentBLESdkVersion=3.3.0 -prop.subLabel=Bluetooth\\ Mesh\\ 2.2.0 +version=2.2.1.0 +prop.subLabel=Bluetooth\\ Mesh\\ 2.2.1 # Default compatibility of the BT Mesh SDK (This is needed for the documentation only) prop.boardCompatibility=.* diff --git a/app/bluetooth/btmesh_internal_demos.xml b/app/bluetooth/btmesh_internal_demos.xml index 7570813de75..e3deef8a2e6 100644 --- a/app/bluetooth/btmesh_internal_demos.xml +++ b/app/bluetooth/btmesh_internal_demos.xml @@ -4,9 +4,9 @@ - + - + Friend example for IOP test. This node acts as a friend for the low power node and caches messages sent to it when the low power node is sleeping. @@ -14,9 +14,9 @@ - + - + Friend example for IOP test. This node acts as a friend for the low power node and caches messages sent to it when the low power node is sleeping. @@ -24,9 +24,9 @@ - + - + Friend example for IOP test. This node acts as a friend for the low power node and caches messages sent to it when the low power node is sleeping. @@ -34,9 +34,9 @@ - + - + Low power node example for IOP test. This node acts as a typical low power device and sleeps most of the time. It needs a friend node to cache messages and forward them when polled. @@ -44,9 +44,9 @@ - + - + Low power node example for IOP test. This node acts as a typical low power device and sleeps most of the time. It needs a friend node to cache messages and forward them when polled. @@ -54,9 +54,9 @@ - + - + Low power node example for IOP test. This node acts as a typical low power device and sleeps most of the time. It needs a friend node to cache messages and forward them when polled. @@ -64,9 +64,9 @@ - + - + Low power node example for IOP test. This node acts as a typical low power device and sleeps most of the time. It needs a friend node to cache messages and forward them when polled. @@ -74,9 +74,9 @@ - + - + Proxy example for IOP test. This node forwards/relays messages between GATT and advertising bearers in the network. @@ -84,9 +84,9 @@ - + - + Proxy example for IOP test. This node forwards/relays messages between GATT and advertising bearers in the network. @@ -94,9 +94,9 @@ - + - + Proxy example for IOP test. This node forwards/relays messages between GATT and advertising bearers in the network. @@ -104,9 +104,9 @@ - + - + Relay example for IOP test. This node acts as a relay, i.e. if a node is out of range for another node, it relays messages between the two, provided the relay node is in range for both. @@ -114,9 +114,9 @@ - + - + Relay example for IOP test. This node acts as a relay, i.e. if a node is out of range for another node, it relays messages between the two, provided the relay node is in range for both. @@ -124,9 +124,9 @@ - + - + Relay example for IOP test. This node acts as a relay, i.e. if a node is out of range for another node, it relays messages between the two, provided the relay node is in range for both. diff --git a/app/bluetooth/btmesh_production_demos.xml b/app/bluetooth/btmesh_production_demos.xml index 5bf2af68843..8fb5613c602 100644 --- a/app/bluetooth/btmesh_production_demos.xml +++ b/app/bluetooth/btmesh_production_demos.xml @@ -4,9 +4,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -14,9 +14,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -24,9 +24,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -34,9 +34,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -44,9 +44,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -54,9 +54,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. This example is recommended for EFR32xG22 which has limited RAM and Flash, therefore some of the stack classes are disabled by default. The required stack class components need to be enabled and the stack parameters need to be configured before use. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -64,9 +64,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. This example is recommended for EFR32xG22 which has limited RAM and Flash, therefore some of the stack classes are disabled by default. The required stack class components need to be enabled and the stack parameters need to be configured before use. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -74,9 +74,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. This example is recommended for EFR32xG22 which has limited RAM and Flash, therefore some of the stack classes are disabled by default. The required stack class components need to be enabled and the stack parameters need to be configured before use. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -84,9 +84,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. This example is recommended for EFR32xG22 which has limited RAM and Flash, therefore some of the stack classes are disabled by default. The required stack class components need to be enabled and the stack parameters need to be configured before use. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -94,9 +94,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. This example is recommended for EFR32xG22 which has limited RAM and Flash, therefore some of the stack classes are disabled by default. The required stack class components need to be enabled and the stack parameters need to be configured before use. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -104,9 +104,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -114,9 +114,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -124,9 +124,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -134,9 +134,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -144,9 +144,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -154,9 +154,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -164,9 +164,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. This example is recommended for EFR32xG22 which has limited RAM and Flash, therefore some of the stack classes are disabled by default. The required stack class components need to be enabled and the stack parameters need to be configured before use. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -174,9 +174,9 @@ - + - + Bluetooth Mesh NCP (Network Co-Processor) target demonstrates the bare minimum needed for a Bluetooth Mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth Mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. This example is recommended for EFR32xG22 which has limited RAM and Flash, therefore some of the stack classes are disabled by default. The required stack class components need to be enabled and the stack parameters need to be configured before use. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. This example requires the BGAPI UART DFU Bootloader. @@ -184,9 +184,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only displayed on the LCD) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -194,9 +194,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the Thunderboard Sense 2 can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only by UART logs) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the UART. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires Internal Storage Bootloader (single image on 1MB device). @@ -204,9 +204,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only displayed on the LCD) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -214,9 +214,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only displayed on the LCD) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -224,9 +224,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only displayed on the LCD) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -234,9 +234,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only displayed on the LCD) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -244,9 +244,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only displayed on the LCD) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -254,9 +254,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only displayed on the LCD) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -264,9 +264,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only displayed on the LCD) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -274,9 +274,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only displayed on the LCD) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -284,9 +284,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity can also be set. Hue and saturation (only displayed on the LCD) can be set by hsl client. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, HSL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -294,9 +294,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV (only displayed on the LCD) can also be set. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -304,9 +304,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the Thunderboard Sense 2 can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV can also be set. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires Internal Storage Bootloader (single image on 1MB device). @@ -314,9 +314,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV (only displayed on the LCD) can also be set. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -324,9 +324,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV (only displayed on the LCD) can also be set. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -334,9 +334,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV (only displayed on the LCD) can also be set. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -344,9 +344,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV (only displayed on the LCD) can also be set. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -354,9 +354,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV (only displayed on the LCD) can also be set. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -364,9 +364,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV (only displayed on the LCD) can also be set. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -374,9 +374,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV (only displayed on the LCD) can also be set. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -384,9 +384,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV (only displayed on the LCD) can also be set. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -394,9 +394,9 @@ - + - + This example is an out-of-the-box Software Demo where the LEDs of the WSTK can be controlled by push button presses on another device (soc_btmesh_switch). Beside switching on and off the LEDs, their lighting intensity, color temperature and delta UV (only displayed on the LCD) can also be set. The example also tries to establish friendship as Friend node and prints its status to the LCD. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, CTL Model and LC Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -404,9 +404,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -414,9 +414,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -424,9 +424,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -434,9 +434,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -444,9 +444,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -454,9 +454,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -464,9 +464,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. CLI commands can substitute button presses as on the selected board only one Push Button is wired. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -474,9 +474,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. CLI commands can substitute button presses as on the selected board only one Push Button is wired. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -484,9 +484,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. CLI commands can substitute button presses as on the selected board only one Push Button is wired. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -494,9 +494,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. CLI commands can substitute button presses as on the selected board only one Push Button is wired. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -504,9 +504,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -514,9 +514,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -524,9 +524,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -534,9 +534,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -544,9 +544,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -554,9 +554,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -564,9 +564,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -574,9 +574,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (eg soc_btmesh_sensor_server). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -584,9 +584,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -594,9 +594,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature, people count and illuminance and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is sent to UART. This example requires Internal Storage Bootloader (single image on 1MB device). @@ -604,9 +604,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -614,9 +614,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -624,9 +624,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -634,9 +634,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -644,9 +644,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the measurement data to a remote device (eg soc_btmesh_sensor_client). The current status is sent to UART. CLI commands can substitute button presses as on the selected board only one Push Button is wired. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -654,9 +654,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the measurement data to a remote device (eg soc_btmesh_sensor_client). The current status is sent to UART. CLI commands can substitute button presses as on the selected board only one Push Button is wired. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -664,9 +664,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature, people count and illuminance and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is sent to UART. CLI commands can substitute button presses as on the selected board only one Push Button is available. This example requires Internal Storage Bootloader (single image on 512kB device). @@ -674,9 +674,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature, people count and illuminance and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is sent to UART. CLI commands can substitute button presses as on the selected board only one Push Button is available. This example requires Internal Storage Bootloader (single image on 512kB device). @@ -684,9 +684,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -694,9 +694,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -704,9 +704,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -714,9 +714,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -724,9 +724,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -734,9 +734,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -744,9 +744,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -754,9 +754,9 @@ - + - + This example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count and sends the mearurement data to a remote device (eg soc_btmesh_sensor_client). The current status is displayed on the LCD and also sent to UART. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -764,9 +764,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -774,9 +774,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -784,9 +784,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -794,9 +794,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -804,9 +804,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -814,9 +814,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -824,9 +824,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board (only PB0 is functional) can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -834,9 +834,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board (only PB0 is functional) can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -844,9 +844,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board (only PB0 is functional) can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -854,9 +854,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board (only PB0 is functional) can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -864,9 +864,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -874,9 +874,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -884,9 +884,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -894,9 +894,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -904,9 +904,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -914,9 +914,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -924,9 +924,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -934,9 +934,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging and LCD. Push Button presses on the development board can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -944,9 +944,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -954,9 +954,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the development board or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -964,9 +964,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -974,9 +974,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -984,9 +984,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -994,9 +994,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1004,9 +1004,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the development board (only PB0 is functional) or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1014,9 +1014,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the development board (only PB0 is functional) or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1024,9 +1024,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the development board (only PB0 is functional) or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1034,9 +1034,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the development board (only PB0 is functional) or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1044,9 +1044,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1054,9 +1054,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1064,9 +1064,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1074,9 +1074,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1084,9 +1084,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1094,9 +1094,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1104,9 +1104,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. @@ -1114,9 +1114,9 @@ - + - + This example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Push Button presses on the WSTK or CLI commands can control the state, lightness and color temperature of the LEDs and also scenes on a remote device (soc_btmesh_light). The example also acts as a LPN and tries to establish friendship. The status messages are also displayed on the LCD and sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, CTL Client Model and Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. diff --git a/app/bluetooth/btmesh_production_templates.xml b/app/bluetooth/btmesh_production_templates.xml index 22b4b39ce69..b2258871c5c 100644 --- a/app/bluetooth/btmesh_production_templates.xml +++ b/app/bluetooth/btmesh_production_templates.xml @@ -4,7 +4,7 @@ - + @@ -17,7 +17,7 @@ - + @@ -30,7 +30,7 @@ - + @@ -43,7 +43,7 @@ - + @@ -56,7 +56,7 @@ - + @@ -69,7 +69,7 @@ - + @@ -82,7 +82,7 @@ - + @@ -95,7 +95,7 @@ - + @@ -108,7 +108,7 @@ - + @@ -121,7 +121,7 @@ - + @@ -134,7 +134,7 @@ - + @@ -147,7 +147,7 @@ - + @@ -160,7 +160,7 @@ - + @@ -173,7 +173,7 @@ - + @@ -186,7 +186,7 @@ - + @@ -199,7 +199,7 @@ - + @@ -212,7 +212,7 @@ - + @@ -225,7 +225,7 @@ - + @@ -238,7 +238,7 @@ - + @@ -251,7 +251,7 @@ - + @@ -264,7 +264,7 @@ - + @@ -277,7 +277,7 @@ - + @@ -290,7 +290,7 @@ - + @@ -303,7 +303,7 @@ - + diff --git a/app/bluetooth/common/app_btmesh_util/app_btmesh_util.h b/app/bluetooth/common/app_btmesh_util/app_btmesh_util.h index 744d7e31ced..4ed76b0d3bf 100644 --- a/app/bluetooth/common/app_btmesh_util/app_btmesh_util.h +++ b/app/bluetooth/common/app_btmesh_util/app_btmesh_util.h @@ -81,22 +81,22 @@ // This macro calculates the number of precompile logging enable request in the // specific c file where the this header file is included from -#define APP_BTMESH_UTIL_COMPONENT_LOGGING \ - (CTL_CLIENT_LOGGING \ - + CTL_SERVER_LOGGING \ - + FRIEND_LOGGING \ - + GENERIC_ONOFF_SERVER_LOGGING \ - + LC_SERVER_LOGGING \ - + LIGHTING_CLIENT_LOGGING \ - + LIGHTING_SERVER_LOGGING \ - + LPN_LOGGING \ - + PROVISIONING_DECORATOR_LOGGING \ - + SCENE_CLIENT_LOGGING \ - + SCHEDULER_SERVER_LOGGING \ - + SENSOR_CLIENT_LOGGING \ - + SENSOR_SERVER_LOGGING \ - + TIME_SERVER_LOGGING \ - + VENDOR_LOOPBACK_LOGGING) +#define APP_BTMESH_UTIL_COMPONENT_LOGGING \ + (SL_BTMESH_CTL_CLIENT_LOGGING_CFG_VAL \ + + SL_BTMESH_CTL_SERVER_LOGGING_CFG_VAL \ + + SL_BTMESH_FRIEND_LOGGING_CFG_VAL \ + + SL_BTMESH_GENERIC_ONOFF_SERVER_LOGGING_CFG_VAL \ + + SL_BTMESH_LC_SERVER_LOGGING_CFG_VAL \ + + SL_BTMESH_LIGHTING_CLIENT_LOGGING_CFG_VAL \ + + SL_BTMESH_LIGHTING_SERVER_LOGGING_CFG_VAL \ + + SL_BTMESH_LPN_LOGGING_CFG_VAL \ + + SL_BTMESH_PROVISIONING_DECORATOR_LOGGING_CFG_VAL \ + + SL_BTMESH_SCENE_CLIENT_LOGGING_CFG_VAL \ + + SL_BTMESH_SCHEDULER_SERVER_LOGGING_CFG_VAL \ + + SL_BTMESH_SENSOR_CLIENT_LOGGING_CFG_VAL \ + + SL_BTMESH_SENSOR_SERVER_LOGGING_CFG_VAL \ + + SL_BTMESH_TIME_SERVER_LOGGING_CFG_VAL \ + + SL_BTMESH_VENDOR_LOOPBACK_LOGGING_CFG_VAL) // Component A shall not include the config file of another component B because // _LOGGING macro of component B could turn on the logging in the // component A unnecessarily. This is important in case of components with log. diff --git a/app/bluetooth/common/btmesh_ctl_client/config/sl_btmesh_ctl_client_config.h b/app/bluetooth/common/btmesh_ctl_client/config/sl_btmesh_ctl_client_config.h index 0cc376ce66d..8fc56f8076e 100644 --- a/app/bluetooth/common/btmesh_ctl_client/config/sl_btmesh_ctl_client_config.h +++ b/app/bluetooth/common/btmesh_ctl_client/config/sl_btmesh_ctl_client_config.h @@ -34,37 +34,37 @@ // CTL Client configuration -// CTL model retransmission count +// CTL model retransmission count // Default: 3 // CTL model retransmission count (How many times CTL model messages are to be sent out for reliability). -#define CTL_CLIENT_RETRANSMISSION_COUNT (3) +#define SL_BTMESH_CTL_CLIENT_RETRANSMISSION_COUNT_CFG_VAL (3) -// CTL model retransmission timeout [ms] <0-1275:5> +// CTL model retransmission timeout [ms] <0-1275:5> // Default: 50 // CTL model retransmission timeout. -#define CTL_CLIENT_RETRANSMISSION_TIMEOUT (50) +#define SL_BTMESH_CTL_CLIENT_RETRANSMISSION_TIMEOUT_CFG_VAL (50) -// Enable color temperature wraparound +// Enable color temperature wraparound // Default: 0 // If the color temperature reaches the max or min value then it wraps around. -#define CTL_CLIENT_TEMPERATURE_WRAP_ENABLED (0) +#define SL_BTMESH_CTL_CLIENT_TEMPERATURE_WRAP_ENABLED_CFG_VAL (0) -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable Logging for CTL Client model specific messages for this component. -#define CTL_CLIENT_LOGGING (1) +#define SL_BTMESH_CTL_CLIENT_LOGGING_CFG_VAL (1) -// Log text when new color temperature has been set. +// Log text when new color temperature has been set. // Set Log text when new color temperature has been set -#define CTL_CLIENT_LOGGING_NEW_TEMP_SET "Set temperature to %u %% / level %u K\r\n" +#define SL_BTMESH_CTL_CLIENT_LOGGING_NEW_TEMP_SET_CFG_VAL "Set temperature to %u %% / level %u K\r\n" -// Log text when sending a CTL message fails. +// Log text when sending a CTL message fails. // Set Log text in case sending a CTL message fails -#define CTL_CLIENT_LOGGING_CLIENT_PUBLISH_FAIL "CTL Client Publish failed\r\n" +#define SL_BTMESH_CTL_CLIENT_LOGGING_CLIENT_PUBLISH_FAIL_CFG_VAL "CTL Client Publish failed\r\n" -// Log text when recalling a scene recall is successful. +// Log text when recalling a scene recall is successful. // Set Log text a scene recall is successful. -#define CTL_CLIENT_LOGGING_RECALL_SUCCESS "CTL request sent, trid = %u, delay = %u\r\n" +#define SL_BTMESH_CTL_CLIENT_LOGGING_RECALL_SUCCESS_CFG_VAL "CTL request sent, trid = %u, delay = %u\r\n" // diff --git a/app/bluetooth/common/btmesh_ctl_client/sl_btmesh_ctl_client.c b/app/bluetooth/common/btmesh_ctl_client/sl_btmesh_ctl_client.c index 44ca3dbb179..90589d05bb7 100644 --- a/app/bluetooth/common/btmesh_ctl_client/sl_btmesh_ctl_client.c +++ b/app/bluetooth/common/btmesh_ctl_client/sl_btmesh_ctl_client.c @@ -148,9 +148,9 @@ static void send_ctl_request(uint8_t retrans) ); if (sc == SL_STATUS_OK) { - log_info(CTL_CLIENT_LOGGING_RECALL_SUCCESS, ctl_trid, delay); + log_info(SL_BTMESH_CTL_CLIENT_LOGGING_RECALL_SUCCESS_CFG_VAL, ctl_trid, delay); } else { - log_btmesh_status_f(sc, CTL_CLIENT_LOGGING_CLIENT_PUBLISH_FAIL); + log_btmesh_status_f(sc, SL_BTMESH_CTL_CLIENT_LOGGING_CLIENT_PUBLISH_FAIL_CFG_VAL); } // Keep track of how many requests has been sent @@ -172,7 +172,7 @@ void sl_btmesh_change_temperature(int8_t change_percentage) if (change_percentage > 0) { temperature_percent += change_percentage; if (temperature_percent > TEMPERATURE_PCT_MAX) { -#if (CTL_CLIENT_TEMPERATURE_WRAP_ENABLED != 0) +#if (SL_BTMESH_CTL_CLIENT_TEMPERATURE_WRAP_ENABLED_CFG_VAL != 0) temperature_percent = 0; #else temperature_percent = TEMPERATURE_PCT_MAX; @@ -180,7 +180,7 @@ void sl_btmesh_change_temperature(int8_t change_percentage) } } else { if (temperature_percent < (-change_percentage)) { -#if (CTL_CLIENT_TEMPERATURE_WRAP_ENABLED != 0) +#if (SL_BTMESH_CTL_CLIENT_TEMPERATURE_WRAP_ENABLED_CFG_VAL != 0) temperature_percent = TEMPERATURE_PCT_MAX; #else temperature_percent = 0; @@ -217,12 +217,12 @@ void sl_btmesh_set_temperature(uint8_t new_color_temperature_percentage) / TEMPERATURE_PCT_MAX) \ * (TEMPERATURE_MAX - TEMPERATURE_MIN) \ / TEMPERATURE_SCALE_FACTOR; - log(CTL_CLIENT_LOGGING_NEW_TEMP_SET, + log(SL_BTMESH_CTL_CLIENT_LOGGING_NEW_TEMP_SET_CFG_VAL, temperature_percent * temperature_percent / TEMPERATURE_PCT_MAX, temperature_level); // Request is sent multiple times to improve reliability - ctl_request_count = CTL_CLIENT_RETRANSMISSION_COUNT; + ctl_request_count = SL_BTMESH_CTL_CLIENT_RETRANSMISSION_COUNT_CFG_VAL; send_ctl_request(0); //Send the first request @@ -230,7 +230,7 @@ void sl_btmesh_set_temperature(uint8_t new_color_temperature_percentage) // to trigger retransmission of the request after 50 ms delay if (ctl_request_count > 0) { sl_status_t sc = sl_simple_timer_start(&ctl_retransmission_timer, - CTL_CLIENT_RETRANSMISSION_TIMEOUT, + SL_BTMESH_CTL_CLIENT_RETRANSMISSION_TIMEOUT_CFG_VAL, ctl_retransmission_timer_cb, NO_CALLBACK_DATA, true); diff --git a/app/bluetooth/common/btmesh_ctl_server/config/sl_btmesh_ctl_server_config.h b/app/bluetooth/common/btmesh_ctl_server/config/sl_btmesh_ctl_server_config.h index 1eba03576bc..6b766004a42 100644 --- a/app/bluetooth/common/btmesh_ctl_server/config/sl_btmesh_ctl_server_config.h +++ b/app/bluetooth/common/btmesh_ctl_server/config/sl_btmesh_ctl_server_config.h @@ -34,50 +34,50 @@ // CTL Server configuration -// Timeout [ms] for saving States of the model to NVM. +// Timeout [ms] for saving States of the model to NVM. // Default: 5000 // Timeout [ms] for saving States of the model to NVM. -#define CTL_SERVER_NVM_SAVE_TIME (5000) +#define SL_BTMESH_CTL_SERVER_NVM_SAVE_TIME_CFG_VAL (5000) -// PS Key for NVM Page where the States of the Lighting Model are saved. +// PS Key for NVM Page where the States of the Lighting Model are saved. // Default: 0x4005 // PS Key for NVM Page where the States of the Lighting Model are saved. -#define CTL_SERVER_PS_KEY (0x4005) +#define SL_BTMESH_CTL_SERVER_PS_KEY_CFG_VAL (0x4005) -// Periodicity [ms] for updating the PWM duty cycle during a transition. +// Periodicity [ms] for updating the PWM duty cycle during a transition. // Default: 1 // Periodicity [ms] for updating the PWM duty cycle during a transition. -#define CTL_SERVER_PWM_UPDATE_PERIOD (1) +#define SL_BTMESH_CTL_SERVER_PWM_UPDATE_PERIOD_CFG_VAL (1) -// Periodicity [ms] for updating the UI with temperature & delta UV during a transition. +// Periodicity [ms] for updating the UI with temperature & delta UV during a transition. // Default: 100 // Periodicity [ms] for updating the temperature & delta UV values on the UI. -#define CTL_SERVER_UI_UPDATE_PERIOD (100) +#define SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL (100) -// Default Color Temperature +// Default Color Temperature // Default: 6500 // Default Color Temperature value. -#define CTL_SERVER_DEFAULT_TEMPERATURE (6500) +#define SL_BTMESH_CTL_SERVER_DEFAULT_TEMPERATURE_CFG_VAL (6500) -// Default Delta UV +// Default Delta UV // Default: 0 // Default Delta UV. -#define CTL_SERVER_DEFAULT_DELTAUV (0) +#define SL_BTMESH_CTL_SERVER_DEFAULT_DELTAUV_CFG_VAL (0) -// Minimum Color Temperature +// Minimum Color Temperature // Default: 800 // Minimum Color Temperature. -#define CTL_SERVER_MINIMUM_TEMPERATURE (800) +#define SL_BTMESH_CTL_SERVER_MINIMUM_TEMPERATURE_CFG_VAL (800) -// Maximum Color Temperature +// Maximum Color Temperature // Default: 800 // Maximum Color Temperature. -#define CTL_SERVER_MAXIMUM_TEMPERATURE (20000) +#define SL_BTMESH_CTL_SERVER_MAXIMUM_TEMPERATURE_CFG_VAL (20000) -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable Logging for Lighting Server model specific messages for this component. -#define CTL_SERVER_LOGGING (1) +#define SL_BTMESH_CTL_SERVER_LOGGING_CFG_VAL (1) // @@ -86,8 +86,8 @@ // <<< end of configuration section >>> // The PWM update period shall not be greater than the UI update period -#if (CTL_SERVER_UI_UPDATE_PERIOD) < (CTL_SERVER_PWM_UPDATE_PERIOD) -#error "The CTL_SERVER_PWM_UPDATE_PERIOD shall be less than CTL_SERVER_UI_UPDATE_PERIOD." +#if (SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL) < (SL_BTMESH_CTL_SERVER_PWM_UPDATE_PERIOD_CFG_VAL) +#error "The SL_BTMESH_CTL_SERVER_PWM_UPDATE_PERIOD_CFG_VAL shall be less than SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL." #endif #endif // SL_BTMESH_CTL_SERVER_CONFIG_H diff --git a/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_server.c b/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_server.c index aada264d10e..3805caaeb3b 100644 --- a/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_server.c +++ b/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_server.c @@ -147,7 +147,7 @@ static void ctl_state_store_timer_cb(sl_simple_timer_t *handle, /***************************************************************************//** * This function loads the saved light state from Persistent Storage and * copies the data in the global variable lightbulb_state. - * If PS key with ID CTL_SERVER_PS_KEY does not exist or loading failed, + * If PS key with ID SL_BTMESH_CTL_SERVER_PS_KEY_CFG_VAL does not exist or loading failed, * lightbulb_state is set to zero and some default values are written to it. * * @return Returns SL_STATUS_OK (0) if succeed, non-zero otherwise. @@ -1933,7 +1933,7 @@ static void init_ctl_models(void) /***************************************************************************//** * This function loads the saved light state from Persistent Storage and * copies the data in the global variable lightbulb_state. - * If PS key with ID CTL_SERVER_PS_KEY does not exist or loading failed, + * If PS key with ID SL_BTMESH_CTL_SERVER_PS_KEY_CFG_VAL does not exist or loading failed, * lightbulb_state is set to zero and some default values are written to it. * * @return Returns SL_STATUS_OK (0) if succeed, non-zero otherwise. @@ -1944,7 +1944,7 @@ static sl_status_t lightbulb_state_load(void) size_t ps_len = 0; struct lightbulb_state ps_data; - sc = sl_bt_nvm_load(CTL_SERVER_PS_KEY, + sc = sl_bt_nvm_load(SL_BTMESH_CTL_SERVER_PS_KEY_CFG_VAL, sizeof(ps_data), &ps_len, (uint8_t *)&ps_data); @@ -1952,10 +1952,10 @@ static sl_status_t lightbulb_state_load(void) // Set default values if ps_load fail or size of lightbulb_state has changed if ((sc != SL_STATUS_OK) || (ps_len != sizeof(struct lightbulb_state))) { memset(&lightbulb_state, 0, sizeof(struct lightbulb_state)); - lightbulb_state.temperature_default = CTL_SERVER_DEFAULT_TEMPERATURE; - lightbulb_state.temperature_min = CTL_SERVER_MINIMUM_TEMPERATURE; - lightbulb_state.temperature_max = CTL_SERVER_MAXIMUM_TEMPERATURE; - lightbulb_state.deltauv_default = CTL_SERVER_DEFAULT_DELTAUV; + lightbulb_state.temperature_default = SL_BTMESH_CTL_SERVER_DEFAULT_TEMPERATURE_CFG_VAL; + lightbulb_state.temperature_min = SL_BTMESH_CTL_SERVER_MINIMUM_TEMPERATURE_CFG_VAL; + lightbulb_state.temperature_max = SL_BTMESH_CTL_SERVER_MAXIMUM_TEMPERATURE_CFG_VAL; + lightbulb_state.deltauv_default = SL_BTMESH_CTL_SERVER_DEFAULT_DELTAUV_CFG_VAL; // Check if default values are valid and correct them if needed lightbulb_state_validate_and_correct(); @@ -1984,7 +1984,7 @@ static sl_status_t lightbulb_state_load(void) * This function saves the current light state in Persistent Storage so that * the data is preserved over reboots and power cycles. * The light state is hold in a global variable lightbulb_state. - * A PS key with ID CTL_SERVER_PS_KEY is used to store the whole struct. + * A PS key with ID SL_BTMESH_CTL_SERVER_PS_KEY_CFG_VAL is used to store the whole struct. * * @return Returns SL_STATUS_OK (0) if succeed, non-zero otherwise. ******************************************************************************/ @@ -1992,7 +1992,7 @@ static sl_status_t lightbulb_state_store(void) { sl_status_t sc; - sc = sl_bt_nvm_save(CTL_SERVER_PS_KEY, + sc = sl_bt_nvm_save(SL_BTMESH_CTL_SERVER_PS_KEY_CFG_VAL, sizeof(struct lightbulb_state), (const uint8_t *)&lightbulb_state); @@ -2011,7 +2011,7 @@ static sl_status_t lightbulb_state_store(void) static void lightbulb_state_changed(void) { sl_status_t sc = sl_simple_timer_start(&ctl_state_store_timer, - CTL_SERVER_NVM_SAVE_TIME, + SL_BTMESH_CTL_SERVER_NVM_SAVE_TIME_CFG_VAL, ctl_state_store_timer_cb, NO_CALLBACK_DATA, false); @@ -2024,11 +2024,11 @@ static void lightbulb_state_changed(void) ******************************************************************************/ static void lightbulb_state_validate_and_correct(void) { - if (lightbulb_state.temperature_min < CTL_SERVER_MINIMUM_TEMPERATURE) { - lightbulb_state.temperature_min = CTL_SERVER_MINIMUM_TEMPERATURE; + if (lightbulb_state.temperature_min < SL_BTMESH_CTL_SERVER_MINIMUM_TEMPERATURE_CFG_VAL) { + lightbulb_state.temperature_min = SL_BTMESH_CTL_SERVER_MINIMUM_TEMPERATURE_CFG_VAL; } - if (lightbulb_state.temperature_min > CTL_SERVER_MAXIMUM_TEMPERATURE) { - lightbulb_state.temperature_min = CTL_SERVER_MAXIMUM_TEMPERATURE; + if (lightbulb_state.temperature_min > SL_BTMESH_CTL_SERVER_MAXIMUM_TEMPERATURE_CFG_VAL) { + lightbulb_state.temperature_min = SL_BTMESH_CTL_SERVER_MAXIMUM_TEMPERATURE_CFG_VAL; } if (lightbulb_state.temperature_min > lightbulb_state.temperature_max) { lightbulb_state.temperature_min = lightbulb_state.temperature_max; @@ -2150,7 +2150,7 @@ void sl_btmesh_ctl_server_on_event(sl_btmesh_msg_t *evt) break; case sl_btmesh_evt_node_reset_id: - sl_bt_nvm_erase(CTL_SERVER_PS_KEY); + sl_bt_nvm_erase(SL_BTMESH_CTL_SERVER_PS_KEY_CFG_VAL); break; } } diff --git a/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_signal_transition_handler.c b/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_signal_transition_handler.c index 6a3e3953499..2d3327555f0 100644 --- a/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_signal_transition_handler.c +++ b/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_signal_transition_handler.c @@ -61,7 +61,7 @@ #define HIGH_PRIORITY 0 // High Priority /// current temperature level -static uint16_t current_temperature = CTL_SERVER_DEFAULT_TEMPERATURE; +static uint16_t current_temperature = SL_BTMESH_CTL_SERVER_DEFAULT_TEMPERATURE_CFG_VAL; /// starting level of temperature transition static uint16_t start_temperature; /// target level of temperature transition @@ -111,7 +111,7 @@ static void transition_timer_cb(sl_simple_timer_t *timer, void *data) (void)timer; // Initialize the variable to UI update period in order to trigger a UI update // at the beginning of the transition. - static uint16_t time_elapsed_since_ui_update = CTL_SERVER_UI_UPDATE_PERIOD; + static uint16_t time_elapsed_since_ui_update = SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL; if (!temp_transitioning) { sl_status_t sc = sl_simple_timer_stop(&transition_timer); @@ -128,7 +128,7 @@ static void transition_timer_cb(sl_simple_timer_t *timer, void *data) // Set the variable to UI update period in order to trigger a UI update // at the beginning of the next transition. - time_elapsed_since_ui_update = CTL_SERVER_UI_UPDATE_PERIOD; + time_elapsed_since_ui_update = SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL; // Trigger a UI update in order to provide the target values at the end // of the current transition @@ -160,12 +160,12 @@ static void transition_timer_cb(sl_simple_timer_t *timer, void *data) } // When transition is ongoing generate an event to application once every - // CTL_SERVER_UI_UPDATE_PERIOD ms because the event is used to update + // SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL ms because the event is used to update // display status and therefore the rate should not be too high - time_elapsed_since_ui_update += CTL_SERVER_PWM_UPDATE_PERIOD; + time_elapsed_since_ui_update += SL_BTMESH_CTL_SERVER_PWM_UPDATE_PERIOD_CFG_VAL; - if (CTL_SERVER_UI_UPDATE_PERIOD <= time_elapsed_since_ui_update) { - time_elapsed_since_ui_update -= CTL_SERVER_UI_UPDATE_PERIOD; + if (SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL <= time_elapsed_since_ui_update) { + time_elapsed_since_ui_update -= SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL; sl_btmesh_ctl_on_ui_update(current_temperature, current_deltauv); } } @@ -185,10 +185,10 @@ void sl_btmesh_ctl_set_temperature_deltauv_level(uint16_t temperature, int16_t deltauv, uint32_t transition_ms) { - if (temperature < CTL_SERVER_MINIMUM_TEMPERATURE) { - temperature = CTL_SERVER_MINIMUM_TEMPERATURE; - } else if (temperature > CTL_SERVER_MAXIMUM_TEMPERATURE) { - temperature = CTL_SERVER_MAXIMUM_TEMPERATURE; + if (temperature < SL_BTMESH_CTL_SERVER_MINIMUM_TEMPERATURE_CFG_VAL) { + temperature = SL_BTMESH_CTL_SERVER_MINIMUM_TEMPERATURE_CFG_VAL; + } else if (temperature > SL_BTMESH_CTL_SERVER_MAXIMUM_TEMPERATURE_CFG_VAL) { + temperature = SL_BTMESH_CTL_SERVER_MAXIMUM_TEMPERATURE_CFG_VAL; } if (transition_ms == 0) { @@ -221,7 +221,7 @@ void sl_btmesh_ctl_set_temperature_deltauv_level(uint16_t temperature, // enabling timer IRQ -> the temperature is adjusted in timer interrupt // gradually until target temperature is reached. sl_status_t sc = sl_simple_timer_start(&transition_timer, - CTL_SERVER_PWM_UPDATE_PERIOD, + SL_BTMESH_CTL_SERVER_PWM_UPDATE_PERIOD_CFG_VAL, transition_timer_cb, NO_CALLBACK_DATA, true); diff --git a/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_signal_transition_handler.h b/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_signal_transition_handler.h index 1e1c0dd7d3c..6a390700ade 100644 --- a/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_signal_transition_handler.h +++ b/app/bluetooth/common/btmesh_ctl_server/sl_btmesh_ctl_signal_transition_handler.h @@ -81,7 +81,7 @@ void sl_btmesh_lighting_color_pwm_cb(uint16_t color); /***************************************************************************//** * Called when the UI shall be updated with the changed CTL Model state during * a transition. The rate of this callback can be controlled by changing the - * CTL_SERVER_UI_UPDATE_PERIOD macro. + * SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL macro. * * This is a callback which can be implemented in the application. * @note If no implementation is provided in the application then a default weak diff --git a/app/bluetooth/common/btmesh_dcd_configuration/dcd_config.btmeshconf b/app/bluetooth/common/btmesh_dcd_configuration/dcd_config.btmeshconf index ac22590f517..f3273915f64 100644 --- a/app/bluetooth/common/btmesh_dcd_configuration/dcd_config.btmeshconf +++ b/app/bluetooth/common/btmesh_dcd_configuration/dcd_config.btmeshconf @@ -2,7 +2,7 @@ "composition_data": { "cid": "0x02ff", "pid": "0xffff", - "vid": "0x0220", + "vid": "0x0221", "elements": [ { "name": "Main", diff --git a/app/bluetooth/common/btmesh_event_log/config/sl_btmesh_event_log_config.h b/app/bluetooth/common/btmesh_event_log/config/sl_btmesh_event_log_config.h index f89f94bb989..4ed0d1b99d0 100644 --- a/app/bluetooth/common/btmesh_event_log/config/sl_btmesh_event_log_config.h +++ b/app/bluetooth/common/btmesh_event_log/config/sl_btmesh_event_log_config.h @@ -33,13 +33,13 @@ // <<< Use Configuration Wizard in Context Menu >>> -// Enable linear output events logging +// Enable linear output events logging // Enables logging of linear output events. -#define LC_LINEAR_OUTPUT_LOG_ENABLE 0 +#define SL_BTMESH_LC_LINEAR_OUTPUT_LOG_ENABLE_CFG_VAL 0 -// Enable unknown events logging +// Enable unknown events logging // Enables logging of unknown events. -#define UNKNOWN_EVENTS_LOG_ENABLE 0 +#define SL_BTMESH_UNKNOWN_EVENTS_LOG_ENABLE_CFG_VAL 0 // <<< end of configuration section >>> diff --git a/app/bluetooth/common/btmesh_event_log/sl_btmesh_event_log.c b/app/bluetooth/common/btmesh_event_log/sl_btmesh_event_log.c index 5a09459819b..15abeff92b5 100644 --- a/app/bluetooth/common/btmesh_event_log/sl_btmesh_event_log.c +++ b/app/bluetooth/common/btmesh_event_log/sl_btmesh_event_log.c @@ -309,11 +309,11 @@ void sl_btmesh_handle_btmesh_logging_events(sl_btmesh_msg_t *evt) break; case sl_btmesh_evt_lc_server_linear_output_updated_id: -#if defined(LC_LINEAR_OUTPUT_LOG_ENABLE) && LC_LINEAR_OUTPUT_LOG_ENABLE +#if defined(SL_BTMESH_LC_LINEAR_OUTPUT_LOG_ENABLE_CFG_VAL) && SL_BTMESH_LC_LINEAR_OUTPUT_LOG_ENABLE_CFG_VAL app_log("evt:sl_btmesh_evt_lc_server_linear_output_updated_id, " "linear_output=%u\r\n", evt->data.evt_lc_server_linear_output_updated.linear_output_value); -#endif // LC_LINEAR_OUTPUT_LOG_ENABLE +#endif // SL_BTMESH_LC_LINEAR_OUTPUT_LOG_ENABLE_CFG_VAL break; case sl_btmesh_evt_lc_setup_server_set_property_id: @@ -323,12 +323,12 @@ void sl_btmesh_handle_btmesh_logging_events(sl_btmesh_msg_t *evt) break; default: -#if defined(UNKNOWN_EVENTS_LOG_ENABLE) && UNKNOWN_EVENTS_LOG_ENABLE +#if defined(SL_BTMESH_UNKNOWN_EVENTS_LOG_ENABLE_CFG_VAL) && SL_BTMESH_UNKNOWN_EVENTS_LOG_ENABLE_CFG_VAL app_log("unknown evt: %8.8x class %2.2x method %2.2x\r\n", evt_id, (evt_id >> 16) & 0xFF, (evt_id >> 24) & 0xFF); -#endif // UNKNOWN_EVENTS_LOG_ENABLE +#endif // SL_BTMESH_UNKNOWN_EVENTS_LOG_ENABLE_CFG_VAL break; } } diff --git a/app/bluetooth/common/btmesh_friend/config/sl_btmesh_friend_config.h b/app/bluetooth/common/btmesh_friend/config/sl_btmesh_friend_config.h index a025ad515e5..6eaf0dd01bd 100644 --- a/app/bluetooth/common/btmesh_friend/config/sl_btmesh_friend_config.h +++ b/app/bluetooth/common/btmesh_friend/config/sl_btmesh_friend_config.h @@ -34,10 +34,10 @@ // Friend configuration -// Enable Logging +// Enable Logging // Default: 1 // Enable or disable Logging for Friend specific messages for this component. -#define FRIEND_LOGGING (1) +#define SL_BTMESH_FRIEND_LOGGING_CFG_VAL (1) // diff --git a/app/bluetooth/common/btmesh_generic_base/config/sl_btmesh_generic_base_config.h b/app/bluetooth/common/btmesh_generic_base/config/sl_btmesh_generic_base_config.h index f89a4192d3d..5882686ca50 100644 --- a/app/bluetooth/common/btmesh_generic_base/config/sl_btmesh_generic_base_config.h +++ b/app/bluetooth/common/btmesh_generic_base/config/sl_btmesh_generic_base_config.h @@ -34,137 +34,137 @@ // Generic Base configuration -// Register size increment <0-10> +// Register size increment <0-10> // Default: 3 // The dynamically reallocated array will grow in size by this value. // Setting this value to 0 will disable reallocation. -#define GENERIC_BASE_INCREMENT 3 +#define SL_BTMESH_GENERIC_BASE_INCREMENT_CFG_VAL 3 // // Generic Models Initialization configuration -// Enable Generic Server Models +// Enable Generic Server Models // Default: 0 // Enable Generic Server functionality. -#define GENERIC_BASE_SERVER 0 +#define SL_BTMESH_GENERIC_BASE_SERVER_CFG_VAL 0 -// Generic On/Off Server +// Generic On/Off Server // Default: 0 // Initialize Generic On/Off Server. -#define GENERIC_ON_OFF_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_ON_OFF_SERVER_INIT_CFG_VAL 0 -// Generic Level Server +// Generic Level Server // Default: 0 // Initialize Generic Level Server. -#define GENERIC_LEVEL_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_LEVEL_SERVER_INIT_CFG_VAL 0 -// Generic Default Transition Time Server +// Generic Default Transition Time Server // Default: 0 // Initialize Generic Default Transition Time Server. -#define GENERIC_DEFAULT_TRANSITION_TIME_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_DEFAULT_TRANSITION_TIME_SERVER_INIT_CFG_VAL 0 -// Generic Power On/Off Server +// Generic Power On/Off Server // Default: 0 // Initialize Generic Power On/Off Server. -#define GENERIC_POWER_ON_OFF_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_POWER_ON_OFF_SERVER_INIT_CFG_VAL 0 -// Generic Power Level Server +// Generic Power Level Server // Default: 0 // Initialize Generic Power Level Server. -#define GENERIC_POWER_LEVEL_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_POWER_LEVEL_SERVER_INIT_CFG_VAL 0 -// Generic Battery Server +// Generic Battery Server // Default: 0 // Initialize Generic Battery Server. -#define GENERIC_BATTERY_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_BATTERY_SERVER_INIT_CFG_VAL 0 -// Generic Location Server +// Generic Location Server // Default: 0 // Initialize Generic Location Server. -#define GENERIC_LOCATION_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_LOCATION_SERVER_INIT_CFG_VAL 0 -// Generic Property Server +// Generic Property Server // Default: 0 // Initialize Generic Property Server. -#define GENERIC_PROPERTY_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_PROPERTY_SERVER_INIT_CFG_VAL 0 -// Light Lightness Server +// Light Lightness Server // Default: 0 // Initialize Light Lightness Server. -#define GENERIC_LIGHTNESS_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_LIGHTNESS_SERVER_INIT_CFG_VAL 0 -// Light CTL Server +// Light CTL Server // Default: 0 // Initialize Light CTL Server. -#define GENERIC_CTL_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_CTL_SERVER_INIT_CFG_VAL 0 -// Light HSL Server +// Light HSL Server // Default: 0 // Initialize Light HSL Server. -#define GENERIC_HSL_SERVER_INIT 0 +#define SL_BTMESH_GENERIC_HSL_SERVER_INIT_CFG_VAL 0 // -// Enable Generic Client Models +// Enable Generic Client Models // Default: 0 // Enable Generic Client functionality. -#define GENERIC_BASE_CLIENT 0 +#define SL_BTMESH_GENERIC_BASE_CLIENT_CFG_VAL 0 -// Generic On/Off Client +// Generic On/Off Client // Default: 0 // Initialize Generic On/Off Client. -#define GENERIC_ON_OFF_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_ON_OFF_CLIENT_INIT_CFG_VAL 0 -// Generic Level Client +// Generic Level Client // Default: 0 // Initialize Generic Level Client. -#define GENERIC_LEVEL_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_LEVEL_CLIENT_INIT_CFG_VAL 0 -// Generic Default Transition Time Client +// Generic Default Transition Time Client // Default: 0 // Initialize Generic Default Transition Time Client. -#define GENERIC_DEFAULT_TRANSITION_TIME_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_DEFAULT_TRANSITION_TIME_CLIENT_INIT_CFG_VAL 0 -// Generic Power On/Off Client +// Generic Power On/Off Client // Default: 0 // Initialize Generic Power On/Off Client. -#define GENERIC_POWER_ON_OFF_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_POWER_ON_OFF_CLIENT_INIT_CFG_VAL 0 -// Generic Power Level Client +// Generic Power Level Client // Default: 0 // Initialize Generic Power Level Client. -#define GENERIC_POWER_LEVEL_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_POWER_LEVEL_CLIENT_INIT_CFG_VAL 0 -// Generic Battery Client +// Generic Battery Client // Default: 0 // Initialize Generic Battery Client. -#define GENERIC_BATTERY_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_BATTERY_CLIENT_INIT_CFG_VAL 0 -// Generic Location Client +// Generic Location Client // Default: 0 // Initialize Generic Location Client. -#define GENERIC_LOCATION_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_LOCATION_CLIENT_INIT_CFG_VAL 0 -// Generic Property Client +// Generic Property Client // Default: 0 // Initialize Generic Property Client. -#define GENERIC_PROPERTY_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_PROPERTY_CLIENT_INIT_CFG_VAL 0 -// Light Lightness Client +// Light Lightness Client // Default: 0 // Initialize Lightness Client. -#define GENERIC_LIGHTNESS_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_LIGHTNESS_CLIENT_INIT_CFG_VAL 0 -// Light CTL Client +// Light CTL Client // Default: 0 // Initialize Light CTL Client. -#define GENERIC_CTL_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_CTL_CLIENT_INIT_CFG_VAL 0 -// Light HSL Client +// Light HSL Client // Default: 0 // Initialize Light HSL Client. -#define GENERIC_HSL_CLIENT_INIT 0 +#define SL_BTMESH_GENERIC_HSL_CLIENT_INIT_CFG_VAL 0 // diff --git a/app/bluetooth/common/btmesh_generic_base/sl_btmesh_generic_base.c b/app/bluetooth/common/btmesh_generic_base/sl_btmesh_generic_base.c index f68688dbdc1..8ef1f45c0fa 100644 --- a/app/bluetooth/common/btmesh_generic_base/sl_btmesh_generic_base.c +++ b/app/bluetooth/common/btmesh_generic_base/sl_btmesh_generic_base.c @@ -46,7 +46,7 @@ sl_status_t sl_btmesh_generic_base_init(void) { return mesh_lib_init(SL_BTMESH_GENERIC_BASE_REGISTRY_INIT_SIZE, - GENERIC_BASE_INCREMENT); + SL_BTMESH_GENERIC_BASE_INCREMENT_CFG_VAL); } void sl_btmesh_generic_base_on_event(sl_btmesh_msg_t *evt) @@ -54,118 +54,118 @@ void sl_btmesh_generic_base_on_event(sl_btmesh_msg_t *evt) sl_status_t sc = SL_STATUS_OK; switch (SL_BT_MSG_ID(evt->header)) { case sl_btmesh_evt_node_initialized_id: -#if GENERIC_BASE_SERVER || defined(SL_CATALOG_BTMESH_LIGHTING_SERVER_PRESENT) \ - || defined(SL_CATALOG_BTMESH_CTL_SERVER_PRESENT) \ - || defined(SL_CATALOG_BTMESH_HSL_SERVER_PRESENT) \ +#if SL_BTMESH_GENERIC_BASE_SERVER_CFG_VAL || defined(SL_CATALOG_BTMESH_LIGHTING_SERVER_PRESENT) \ + || defined(SL_CATALOG_BTMESH_CTL_SERVER_PRESENT) \ + || defined(SL_CATALOG_BTMESH_HSL_SERVER_PRESENT) \ || defined(SL_CATALOG_BTMESH_GENERIC_ONOFF_SERVER_PRESENT) -#if GENERIC_CTL_SERVER_INIT || defined(SL_CATALOG_BTMESH_CTL_SERVER_PRESENT) \ - || GENERIC_HSL_SERVER_INIT || defined(SL_CATALOG_BTMESH_HSL_SERVER_PRESENT) \ - || GENERIC_POWER_LEVEL_SERVER_INIT +#if SL_BTMESH_GENERIC_CTL_SERVER_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_CTL_SERVER_PRESENT) \ + || SL_BTMESH_GENERIC_HSL_SERVER_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_HSL_SERVER_PRESENT) \ + || SL_BTMESH_GENERIC_POWER_LEVEL_SERVER_INIT_CFG_VAL - #if GENERIC_CTL_SERVER_INIT || defined(SL_CATALOG_BTMESH_CTL_SERVER_PRESENT) + #if SL_BTMESH_GENERIC_CTL_SERVER_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_CTL_SERVER_PRESENT) sc = sl_btmesh_generic_server_init_ctl(); app_assert_status_f(sc, "Failed to init ctl server\n"); - #endif // GENERIC_CTL_SERVER_INIT - #if GENERIC_HSL_SERVER_INIT || defined(SL_CATALOG_BTMESH_HSL_SERVER_PRESENT) + #endif // SL_BTMESH_GENERIC_CTL_SERVER_INIT_CFG_VAL + #if SL_BTMESH_GENERIC_HSL_SERVER_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_HSL_SERVER_PRESENT) sc = sl_btmesh_generic_server_init_hsl(); app_assert_status_f(sc, "Failed to init hsl server\n"); - #endif // GENERIC_HSL_SERVER_INIT - #if GENERIC_POWER_LEVEL_SERVER_INIT + #endif // SL_BTMESH_GENERIC_HSL_SERVER_INIT_CFG_VAL + #if SL_BTMESH_GENERIC_POWER_LEVEL_SERVER_INIT_CFG_VAL sc = sl_btmesh_generic_server_init_power_level(); app_assert_status_f(sc, "Failed to init power level server\n"); - #endif // GENERIC_POWER_LEVEL_SERVER_INIT -#elif GENERIC_LIGHTNESS_SERVER_INIT || defined(SL_CATALOG_BTMESH_LIGHTING_SERVER_PRESENT) + #endif // SL_BTMESH_GENERIC_POWER_LEVEL_SERVER_INIT_CFG_VAL +#elif SL_BTMESH_GENERIC_LIGHTNESS_SERVER_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_LIGHTING_SERVER_PRESENT) sc = sl_btmesh_generic_server_init_lightness(); app_assert_status_f(sc, "Failed to init lightness server\n"); -#else // GENERIC_CTL_SERVER_INIT || GENERIC_HSL_SERVER_INIT || GENERIC_POWER_LEVEL_SERVER_INIT - #if GENERIC_LEVEL_SERVER_INIT +#else // SL_BTMESH_GENERIC_CTL_SERVER_INIT_CFG_VAL || SL_BTMESH_GENERIC_HSL_SERVER_INIT_CFG_VAL || SL_BTMESH_GENERIC_POWER_LEVEL_SERVER_INIT_CFG_VAL + #if SL_BTMESH_GENERIC_LEVEL_SERVER_INIT_CFG_VAL sc = sl_btmesh_generic_server_init_level(); app_assert_status_f(sc, "Failed to init level server\n"); - #endif // GENERIC_LEVEL_SERVER_INIT - #if GENERIC_POWER_ON_OFF_SERVER_INIT + #endif // SL_BTMESH_GENERIC_LEVEL_SERVER_INIT_CFG_VAL + #if SL_BTMESH_GENERIC_POWER_ON_OFF_SERVER_INIT_CFG_VAL sc = sl_btmesh_generic_server_init_power_on_off(); app_assert_status_f(sc, "Failed to init power on/off server\n"); - #else //GENERIC_POWER_ON_OFF_SERVER_INIT - #if GENERIC_ON_OFF_SERVER_INIT || defined(SL_CATALOG_BTMESH_GENERIC_ONOFF_SERVER_PRESENT) + #else //SL_BTMESH_GENERIC_POWER_ON_OFF_SERVER_INIT_CFG_VAL + #if SL_BTMESH_GENERIC_ON_OFF_SERVER_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_GENERIC_ONOFF_SERVER_PRESENT) sc = sl_btmesh_generic_server_init_on_off(); app_assert_status_f(sc, "Failed to init on/off server\n"); - #endif // GENERIC_ON_OFF_SERVER_INIT - #if GENERIC_DEFAULT_TRANSITION_TIME_SERVER_INIT + #endif // SL_BTMESH_GENERIC_ON_OFF_SERVER_INIT_CFG_VAL + #if SL_BTMESH_GENERIC_DEFAULT_TRANSITION_TIME_SERVER_INIT_CFG_VAL sc = sl_btmesh_generic_server_init_default_transition_time(); app_assert_status_f(sc, "Failed to init default transition time server\n"); - #endif // GENERIC_DEFAULT_TRANSITION_TIME_SERVER_INIT - #endif //GENERIC_POWER_ON_OFF_SERVER_INIT -#endif // GENERIC_CTL_SERVER_INIT || GENERIC_HSL_SERVER_INIT || GENERIC_POWER_LEVEL_SERVER_INIT -#if GENERIC_BATTERY_SERVER_INIT + #endif // SL_BTMESH_GENERIC_DEFAULT_TRANSITION_TIME_SERVER_INIT_CFG_VAL + #endif //SL_BTMESH_GENERIC_POWER_ON_OFF_SERVER_INIT_CFG_VAL +#endif // SL_BTMESH_GENERIC_CTL_SERVER_INIT_CFG_VAL || SL_BTMESH_GENERIC_HSL_SERVER_INIT_CFG_VAL || SL_BTMESH_GENERIC_POWER_LEVEL_SERVER_INIT_CFG_VAL +#if SL_BTMESH_GENERIC_BATTERY_SERVER_INIT_CFG_VAL sc = sl_btmesh_generic_server_init_battery(); app_assert_status_f(sc, "Failed to init battery server\n"); -#endif // GENERIC_BATTERY_SERVER_INIT -#if GENERIC_LOCATION_SERVER_INIT +#endif // SL_BTMESH_GENERIC_BATTERY_SERVER_INIT_CFG_VAL +#if SL_BTMESH_GENERIC_LOCATION_SERVER_INIT_CFG_VAL sc = sl_btmesh_generic_server_init_location(); app_assert_status_f(sc, "Failed to init location server\n"); -#endif // GENERIC_LOCATION_SERVER_INIT -#if GENERIC_PROPERTY_SERVER_INIT +#endif // SL_BTMESH_GENERIC_LOCATION_SERVER_INIT_CFG_VAL +#if SL_BTMESH_GENERIC_PROPERTY_SERVER_INIT_CFG_VAL sc = sl_btmesh_generic_server_init_property(); app_assert_status_f(sc, "Failed to init property server\n"); -#endif // GENERIC_PROPERTY_SERVER_INIT +#endif // SL_BTMESH_GENERIC_PROPERTY_SERVER_INIT_CFG_VAL sc = sl_btmesh_generic_server_init_common(); app_assert_status_f(sc, "Failed to common init Generic Server\n"); -#endif // GENERIC_BASE_SERVER +#endif // SL_BTMESH_GENERIC_BASE_SERVER_CFG_VAL -#if GENERIC_BASE_CLIENT || defined(SL_CATALOG_BTMESH_LIGHTING_CLIENT_PRESENT) \ +#if SL_BTMESH_GENERIC_BASE_CLIENT_CFG_VAL || defined(SL_CATALOG_BTMESH_LIGHTING_CLIENT_PRESENT) \ || defined(SL_CATALOG_BTMESH_CTL_CLIENT_PRESENT) -#if GENERIC_ON_OFF_CLIENT_INIT || defined(SL_CATALOG_BTMESH_LIGHTING_CLIENT_PRESENT) +#if SL_BTMESH_GENERIC_ON_OFF_CLIENT_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_LIGHTING_CLIENT_PRESENT) sc = sl_btmesh_generic_client_init_on_off(); app_assert_status_f(sc, "Failed to init on/off client\n"); -#endif // GENERIC_ON_OFF_CLIENT_INIT || defined(SL_CATALOG_BTMESH_LIGHTING_CLIENT_PRESENT) -#if GENERIC_LEVEL_SERVER_INIT +#endif // SL_BTMESH_GENERIC_ON_OFF_CLIENT_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_LIGHTING_CLIENT_PRESENT) +#if SL_BTMESH_GENERIC_LEVEL_SERVER_INIT_CFG_VAL sc = sl_btmesh_generic_client_init_level(); app_assert_status_f(sc, "Failed to init level client\n"); -#endif // GENERIC_LEVEL_SERVER_INIT -#if GENERIC_DEFAULT_TRANSITION_TIME_CLIENT_INIT +#endif // SL_BTMESH_GENERIC_LEVEL_SERVER_INIT_CFG_VAL +#if SL_BTMESH_GENERIC_DEFAULT_TRANSITION_TIME_CLIENT_INIT_CFG_VAL sc = sl_btmesh_generic_client_init_default_transition_time(); app_assert_status_f(sc, "Failed to init default transition time client\n"); -#endif // GENERIC_DEFAULT_TRANSITION_TIME_CLIENT_INIT -#if GENERIC_POWER_ON_OFF_CLIENT_INIT +#endif // SL_BTMESH_GENERIC_DEFAULT_TRANSITION_TIME_CLIENT_INIT_CFG_VAL +#if SL_BTMESH_GENERIC_POWER_ON_OFF_CLIENT_INIT_CFG_VAL sc = sl_btmesh_generic_client_init_power_on_off(); app_assert_status_f(sc, "Failed to init power on/off client\n"); -#endif // GENERIC_POWER_ON_OFF_CLIENT_INIT -#if GENERIC_POWER_LEVEL_CLIENT_INIT +#endif // SL_BTMESH_GENERIC_POWER_ON_OFF_CLIENT_INIT_CFG_VAL +#if SL_BTMESH_GENERIC_POWER_LEVEL_CLIENT_INIT_CFG_VAL sc = sl_btmesh_generic_client_init_power_level(); app_assert_status_f(sc, "Failed to init power level client\n"); -#endif // GENERIC_POWER_LEVEL_CLIENT_INIT -#if GENERIC_BATTERY_CLIENT_INIT +#endif // SL_BTMESH_GENERIC_POWER_LEVEL_CLIENT_INIT_CFG_VAL +#if SL_BTMESH_GENERIC_BATTERY_CLIENT_INIT_CFG_VAL sc = sl_btmesh_generic_client_init_battery(); app_assert_status_f(sc, "Failed to init battery client\n"); -#endif // GENERIC_BATTERY_CLIENT_INIT -#if GENERIC_LOCATION_CLIENT_INIT +#endif // SL_BTMESH_GENERIC_BATTERY_CLIENT_INIT_CFG_VAL +#if SL_BTMESH_GENERIC_LOCATION_CLIENT_INIT_CFG_VAL sc = sl_btmesh_generic_client_init_location(); app_assert_status_f(sc, "Failed to init location client\n"); -#endif // GENERIC_LOCATION_CLIENT_INIT -#if GENERIC_PROPERTY_CLIENT_INIT +#endif // SL_BTMESH_GENERIC_LOCATION_CLIENT_INIT_CFG_VAL +#if SL_BTMESH_GENERIC_PROPERTY_CLIENT_INIT_CFG_VAL sc = sl_btmesh_generic_client_init_property(); app_assert_status_f(sc, "Failed to init property client\n"); -#endif // GENERIC_PROPERTY_CLIENT_INIT -#if GENERIC_LIGHTNESS_CLIENT_INIT || defined(SL_CATALOG_BTMESH_LIGHTING_CLIENT_PRESENT) +#endif // SL_BTMESH_GENERIC_PROPERTY_CLIENT_INIT_CFG_VAL +#if SL_BTMESH_GENERIC_LIGHTNESS_CLIENT_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_LIGHTING_CLIENT_PRESENT) sc = sl_btmesh_generic_client_init_lightness(); app_assert_status_f(sc, "Failed to init lightness client\n"); -#endif // GENERIC_LIGHTNESS_CLIENT_INIT || defined(SL_CATALOG_BTMESH_LIGHTING_CLIENT_PRESENT) -#if GENERIC_CTL_CLIENT_INIT || defined(SL_CATALOG_BTMESH_CTL_CLIENT_PRESENT) +#endif // SL_BTMESH_GENERIC_LIGHTNESS_CLIENT_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_LIGHTING_CLIENT_PRESENT) +#if SL_BTMESH_GENERIC_CTL_CLIENT_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_CTL_CLIENT_PRESENT) sc = sl_btmesh_generic_client_init_ctl(); app_assert_status_f(sc, "Failed to init ctl client\n"); -#endif // GENERIC_CTL_CLIENT_INIT || defined(SL_CATALOG_BTMESH_CTL_CLIENT_PRESENT) -#if GENERIC_HSL_CLIENT_INIT +#endif // SL_BTMESH_GENERIC_CTL_CLIENT_INIT_CFG_VAL || defined(SL_CATALOG_BTMESH_CTL_CLIENT_PRESENT) +#if SL_BTMESH_GENERIC_HSL_CLIENT_INIT_CFG_VAL sc = sl_btmesh_generic_client_init_hsl(); app_assert_status_f(sc, "Failed to init hsl client\n"); -#endif // GENERIC_HSL_CLIENT_INIT +#endif // SL_BTMESH_GENERIC_HSL_CLIENT_INIT_CFG_VAL sc = sl_btmesh_generic_client_init_common(); app_assert_status_f(sc, "Failed to common init Generic Client\n"); -#endif // GENERIC_BASE_CLIENT +#endif // SL_BTMESH_GENERIC_BASE_CLIENT_CFG_VAL break; -#if GENERIC_BASE_SERVER || defined(SL_CATALOG_BTMESH_LIGHTING_SERVER_PRESENT) +#if SL_BTMESH_GENERIC_BASE_SERVER_CFG_VAL || defined(SL_CATALOG_BTMESH_LIGHTING_SERVER_PRESENT) case sl_btmesh_evt_generic_server_client_request_id: // intentional fall through case sl_btmesh_evt_generic_server_state_recall_id: @@ -173,11 +173,11 @@ void sl_btmesh_generic_base_on_event(sl_btmesh_msg_t *evt) case sl_btmesh_evt_generic_server_state_changed_id: mesh_lib_generic_server_event_handler(evt); break; -#endif // GENERIC_BASE_SERVER -#if GENERIC_BASE_CLIENT +#endif // SL_BTMESH_GENERIC_BASE_SERVER_CFG_VAL +#if SL_BTMESH_GENERIC_BASE_CLIENT_CFG_VAL case sl_btmesh_evt_generic_client_server_status_id: mesh_lib_generic_client_event_handler(evt); break; -#endif // GENERIC_BASE_CLIENT +#endif // SL_BTMESH_GENERIC_BASE_CLIENT_CFG_VAL } } diff --git a/app/bluetooth/common/btmesh_hsl_server/config/sl_btmesh_hsl_server_config.h b/app/bluetooth/common/btmesh_hsl_server/config/sl_btmesh_hsl_server_config.h index 557bdc4ca95..0c48f90979d 100644 --- a/app/bluetooth/common/btmesh_hsl_server/config/sl_btmesh_hsl_server_config.h +++ b/app/bluetooth/common/btmesh_hsl_server/config/sl_btmesh_hsl_server_config.h @@ -5,70 +5,70 @@ // HSL Server configuration -// Timeout [ms] for saving States of the model to NVM. +// Timeout [ms] for saving States of the model to NVM. // Default: 5000 // Timeout [ms] for saving States of the model to NVM. -#define HSL_SERVER_NVM_SAVE_TIME (5000) +#define SL_BTMESH_HSL_SERVER_NVM_SAVE_TIME_CFG_VAL (5000) -// PS Key for NVM Page where the States of the HSL Models are saved. +// PS Key for NVM Page where the States of the HSL Models are saved. // Default: 0x4008 // PS Key for NVM Page where the States of the HSL Models are saved. -#define HSL_SERVER_PS_KEY (0x4008) +#define SL_BTMESH_HSL_SERVER_PS_KEY_CFG_VAL (0x4008) -// Periodicity [ms] for updating the hue during a transition. +// Periodicity [ms] for updating the hue during a transition. // Default: 1 // Periodicity [ms] for updating the hue during a transition. -#define HSL_SERVER_HUE_UPDATE_PERIOD (1) +#define SL_BTMESH_HSL_SERVER_HUE_UPDATE_PERIOD_CFG_VAL (1) -// Periodicity [ms] for updating the saturation during a transition. +// Periodicity [ms] for updating the saturation during a transition. // Default: 1 // Periodicity [ms] for updating the saturation during a transition. -#define HSL_SERVER_SATURATION_UPDATE_PERIOD (1) +#define SL_BTMESH_HSL_SERVER_SATURATION_UPDATE_PERIOD_CFG_VAL (1) -// Periodicity [ms] for updating the UI with hue during a transition. +// Periodicity [ms] for updating the UI with hue during a transition. // Default: 100 // Periodicity [ms] for updating the hue values on the UI. -#define HSL_SERVER_HUE_UI_UPDATE_PERIOD (100) +#define SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL (100) -// Periodicity [ms] for updating the UI with saturation during a transition. +// Periodicity [ms] for updating the UI with saturation during a transition. // Default: 100 // Periodicity [ms] for updating the saturation values on the UI. -#define HSL_SERVER_SATURATION_UI_UPDATE_PERIOD (100) +#define SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL (100) -// Default Hue +// Default Hue // Default: 0 // Default Hue value. -#define HSL_SERVER_DEFAULT_HUE (0) +#define SL_BTMESH_HSL_SERVER_DEFAULT_HUE_CFG_VAL (0) -// Default Saturation +// Default Saturation // Default: 0 // Default Saturation. -#define HSL_SERVER_DEFAULT_SATURATION (0) +#define SL_BTMESH_HSL_SERVER_DEFAULT_SATURATION_CFG_VAL (0) -// Minimum Hue +// Minimum Hue // Default: 0 // Minimum Hue. -#define HSL_SERVER_MINIMUM_HUE (0) +#define SL_BTMESH_HSL_SERVER_MINIMUM_HUE_CFG_VAL (0) -// Maximum Hue +// Maximum Hue // Default: 65535 // Maximum Hue. -#define HSL_SERVER_MAXIMUM_HUE (65535) +#define SL_BTMESH_HSL_SERVER_MAXIMUM_HUE_CFG_VAL (65535) -// Minimum Saturation +// Minimum Saturation // Default: 0 // Minimum Saturation. -#define HSL_SERVER_MINIMUM_SATURATION (0) +#define SL_BTMESH_HSL_SERVER_MINIMUM_SATURATION_CFG_VAL (0) -// Maximum Saturation +// Maximum Saturation // Default: 65535 // Maximum Saturation. -#define HSL_SERVER_MAXIMUM_SATURATION (65535) +#define SL_BTMESH_HSL_SERVER_MAXIMUM_SATURATION_CFG_VAL (65535) -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable UART Logging for HSL Server models specific messages for this component. -#define HSL_SERVER_LOGGING (1) +#define SL_BTMESH_HSL_SERVER_LOGGING_CFG_VAL (1) // @@ -77,13 +77,13 @@ // <<< end of configuration section >>> // The hue update period shall not be greater than the hue UI update period -#if (HSL_SERVER_HUE_UI_UPDATE_PERIOD) < (HSL_SERVER_HUE_UPDATE_PERIOD) -#error "The HSL_SERVER_HUE_UPDATE_PERIOD shall be less than HSL_SERVER_HUE_UI_UPDATE_PERIOD." +#if (SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL) < (SL_BTMESH_HSL_SERVER_HUE_UPDATE_PERIOD_CFG_VAL) +#error "The SL_BTMESH_HSL_SERVER_HUE_UPDATE_PERIOD_CFG_VAL shall be less than SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL." #endif // The saturation update period shall not be greater than the saturation UI update period -#if (HSL_SERVER_SATURATION_UI_UPDATE_PERIOD) < (HSL_SERVER_SATURATION_UPDATE_PERIOD) -#error "The HSL_SERVER_SATURATION_UPDATE_PERIOD shall be less than HSL_SERVER_SATURATION_UI_UPDATE_PERIOD." +#if (SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL) < (SL_BTMESH_HSL_SERVER_SATURATION_UPDATE_PERIOD_CFG_VAL) +#error "The SL_BTMESH_HSL_SERVER_SATURATION_UPDATE_PERIOD_CFG_VAL shall be less than SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL." #endif #endif // SL_BTMESH_HSL_SERVER_CONFIG_H diff --git a/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_server.c b/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_server.c index 4c04ae941dd..edd7fef54fb 100644 --- a/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_server.c +++ b/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_server.c @@ -169,7 +169,7 @@ static void hsl_state_store_timer_cb(sl_simple_timer_t *handle, /***************************************************************************//** * This function loads the saved light state from Persistent Storage and * copies the data in the global variable lightbulb_state. - * If PS key with ID HSL_SERVER_PS_KEY does not exist or loading failed, + * If PS key with ID SL_BTMESH_HSL_SERVER_PS_KEY_CFG_VAL does not exist or loading failed, * lightbulb_state is set to zero and some default values are written to it. * * @return Returns SL_STATUS_OK (0) if succeed, non-zero otherwise. @@ -2769,7 +2769,7 @@ static void init_hsl_models(void) /***************************************************************************//** * This function loads the saved light state from Persistent Storage and * copies the data in the global variable lightbulb_state. - * If PS key with ID HSL_SERVER_PS_KEY does not exist or loading failed, + * If PS key with ID SL_BTMESH_HSL_SERVER_PS_KEY_CFG_VAL does not exist or loading failed, * lightbulb_state is set to zero and some default values are written to it. * * @return Returns SL_STATUS_OK (0) if succeed, non-zero otherwise. @@ -2780,7 +2780,7 @@ static sl_status_t lightbulb_state_load(void) size_t ps_len = 0; struct lightbulb_state ps_data; - sc = sl_bt_nvm_load(HSL_SERVER_PS_KEY, + sc = sl_bt_nvm_load(SL_BTMESH_HSL_SERVER_PS_KEY_CFG_VAL, sizeof(ps_data), &ps_len, (uint8_t *)&ps_data); @@ -2788,12 +2788,12 @@ static sl_status_t lightbulb_state_load(void) // Set default values if ps_load fail or size of lightbulb_state has changed if ((sc != SL_STATUS_OK) || (ps_len != sizeof(struct lightbulb_state))) { memset(&lightbulb_state, 0, sizeof(struct lightbulb_state)); - lightbulb_state.hue_default = HSL_SERVER_DEFAULT_HUE; - lightbulb_state.hue_min = HSL_SERVER_MINIMUM_HUE; - lightbulb_state.hue_max = HSL_SERVER_MAXIMUM_HUE; - lightbulb_state.saturation_default = HSL_SERVER_DEFAULT_SATURATION; - lightbulb_state.saturation_min = HSL_SERVER_MINIMUM_SATURATION; - lightbulb_state.saturation_max = HSL_SERVER_MAXIMUM_SATURATION; + lightbulb_state.hue_default = SL_BTMESH_HSL_SERVER_DEFAULT_HUE_CFG_VAL; + lightbulb_state.hue_min = SL_BTMESH_HSL_SERVER_MINIMUM_HUE_CFG_VAL; + lightbulb_state.hue_max = SL_BTMESH_HSL_SERVER_MAXIMUM_HUE_CFG_VAL; + lightbulb_state.saturation_default = SL_BTMESH_HSL_SERVER_DEFAULT_SATURATION_CFG_VAL; + lightbulb_state.saturation_min = SL_BTMESH_HSL_SERVER_MINIMUM_SATURATION_CFG_VAL; + lightbulb_state.saturation_max = SL_BTMESH_HSL_SERVER_MAXIMUM_SATURATION_CFG_VAL; // Check if default values are valid and correct them if needed lightbulb_state_validate_and_correct(); @@ -2822,7 +2822,7 @@ static sl_status_t lightbulb_state_load(void) * This function saves the current light state in Persistent Storage so that * the data is preserved over reboots and power cycles. * The light state is hold in a global variable lightbulb_state. - * A PS key with ID HSL_SERVER_PS_KEY is used to store the whole struct. + * A PS key with ID SL_BTMESH_HSL_SERVER_PS_KEY_CFG_VAL is used to store the whole struct. * * @return Returns SL_STATUS_OK (0) if succeed, non-zero otherwise. ******************************************************************************/ @@ -2830,7 +2830,7 @@ static sl_status_t lightbulb_state_store(void) { sl_status_t sc; - sc = sl_bt_nvm_save(HSL_SERVER_PS_KEY, + sc = sl_bt_nvm_save(SL_BTMESH_HSL_SERVER_PS_KEY_CFG_VAL, sizeof(struct lightbulb_state), (const uint8_t *)&lightbulb_state); @@ -2849,7 +2849,7 @@ static sl_status_t lightbulb_state_store(void) static void lightbulb_state_changed(void) { sl_status_t sc = sl_simple_timer_start(&hsl_state_store_timer, - HSL_SERVER_NVM_SAVE_TIME, + SL_BTMESH_HSL_SERVER_NVM_SAVE_TIME_CFG_VAL, hsl_state_store_timer_cb, NO_CALLBACK_DATA, false); diff --git a/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_signal_transition_handler.c b/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_signal_transition_handler.c index 9d12c92c45c..08ceabd86c7 100644 --- a/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_signal_transition_handler.c +++ b/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_signal_transition_handler.c @@ -44,14 +44,14 @@ #define HIGH_PRIORITY 0 // High Priority /// current hue level -static uint16_t current_hue = HSL_SERVER_DEFAULT_HUE; +static uint16_t current_hue = SL_BTMESH_HSL_SERVER_DEFAULT_HUE_CFG_VAL; /// starting level of hue transition static uint16_t start_hue; /// target level of hue transition static uint16_t target_hue; /// current saturation level -static uint16_t current_saturation = HSL_SERVER_DEFAULT_SATURATION; +static uint16_t current_saturation = SL_BTMESH_HSL_SERVER_DEFAULT_SATURATION_CFG_VAL; /// starting level of saturation transition static uint16_t start_saturation; /// target level of saturation transition @@ -111,7 +111,7 @@ static void hue_transition_timer_cb(sl_simple_timer_t *timer, void *data) (void)timer; // Initialize the variable to UI update period in order to trigger a UI update // at the beginning of the transition. - static uint16_t time_elapsed_since_ui_update = HSL_SERVER_HUE_UI_UPDATE_PERIOD; + static uint16_t time_elapsed_since_ui_update = SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL; if (!hue_transitioning) { sl_status_t sc = sl_simple_timer_stop(&hue_transition_timer); @@ -127,7 +127,7 @@ static void hue_transition_timer_cb(sl_simple_timer_t *timer, void *data) // Set the variable to UI update period in order to trigger a UI update // at the beginning of the next transition. - time_elapsed_since_ui_update = HSL_SERVER_HUE_UI_UPDATE_PERIOD; + time_elapsed_since_ui_update = SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL; // Trigger a UI update in order to provide the target values at the end // of the current transition @@ -147,12 +147,12 @@ static void hue_transition_timer_cb(sl_simple_timer_t *timer, void *data) } // When transition is ongoing generate an event to application once every - // HSL_SERVER_HUE_UI_UPDATE_PERIOD ms because the event is used to update + // SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL ms because the event is used to update // display status and therefore the rate should not be too high - time_elapsed_since_ui_update += HSL_SERVER_HUE_UI_UPDATE_PERIOD; + time_elapsed_since_ui_update += SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL; - if (HSL_SERVER_HUE_UI_UPDATE_PERIOD <= time_elapsed_since_ui_update) { - time_elapsed_since_ui_update -= HSL_SERVER_HUE_UI_UPDATE_PERIOD; + if (SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL <= time_elapsed_since_ui_update) { + time_elapsed_since_ui_update -= SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL; sl_btmesh_hsl_hue_on_ui_update(current_hue); } } @@ -170,7 +170,7 @@ static void saturation_transition_timer_cb(sl_simple_timer_t *timer, void *data) (void)timer; // Initialize the variable to UI update period in order to trigger a UI update // at the beginning of the transition. - static uint16_t time_elapsed_since_ui_update = HSL_SERVER_SATURATION_UI_UPDATE_PERIOD; + static uint16_t time_elapsed_since_ui_update = SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL; if (!saturation_transitioning) { sl_status_t sc = sl_simple_timer_stop(&saturation_transition_timer); @@ -186,7 +186,7 @@ static void saturation_transition_timer_cb(sl_simple_timer_t *timer, void *data) // Set the variable to UI update period in order to trigger a UI update // at the beginning of the next transition. - time_elapsed_since_ui_update = HSL_SERVER_SATURATION_UI_UPDATE_PERIOD; + time_elapsed_since_ui_update = SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL; // Trigger a UI update in order to provide the target values at the end // of the current transition @@ -206,12 +206,12 @@ static void saturation_transition_timer_cb(sl_simple_timer_t *timer, void *data) } // When transition is ongoing generate an event to application once every - // HSL_SERVER_SATURATION_UI_UPDATE_PERIOD ms because the event is used to update + // SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL ms because the event is used to update // display status and therefore the rate should not be too high - time_elapsed_since_ui_update += HSL_SERVER_SATURATION_UI_UPDATE_PERIOD; + time_elapsed_since_ui_update += SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL; - if (HSL_SERVER_SATURATION_UI_UPDATE_PERIOD <= time_elapsed_since_ui_update) { - time_elapsed_since_ui_update -= HSL_SERVER_SATURATION_UI_UPDATE_PERIOD; + if (SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL <= time_elapsed_since_ui_update) { + time_elapsed_since_ui_update -= SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL; sl_btmesh_hsl_saturation_on_ui_update(current_saturation); } } @@ -228,15 +228,15 @@ static void saturation_transition_timer_cb(sl_simple_timer_t *timer, void *data) ******************************************************************************/ void sl_btmesh_hsl_set_hue_level(uint16_t hue, uint32_t transition_ms) { -#if HSL_SERVER_MINIMUM_HUE != (0) - if (hue < HSL_SERVER_MINIMUM_HUE) { - hue = HSL_SERVER_MINIMUM_HUE; +#if SL_BTMESH_HSL_SERVER_MINIMUM_HUE_CFG_VAL != (0) + if (hue < SL_BTMESH_HSL_SERVER_MINIMUM_HUE_CFG_VAL) { + hue = SL_BTMESH_HSL_SERVER_MINIMUM_HUE_CFG_VAL; } #endif -#if HSL_SERVER_MAXIMUM_HUE != (65535) - if (hue > HSL_SERVER_MAXIMUM_HUE) { - hue = HSL_SERVER_MAXIMUM_HUE; +#if SL_BTMESH_HSL_SERVER_MAXIMUM_HUE_CFG_VAL != (65535) + if (hue > SL_BTMESH_HSL_SERVER_MAXIMUM_HUE_CFG_VAL) { + hue = SL_BTMESH_HSL_SERVER_MAXIMUM_HUE_CFG_VAL; } #endif @@ -266,7 +266,7 @@ void sl_btmesh_hsl_set_hue_level(uint16_t hue, uint32_t transition_ms) // enabling timer IRQ -> the temperature is adjusted in timer interrupt // gradually until target temperature is reached. sl_status_t sc = sl_simple_timer_start(&hue_transition_timer, - HSL_SERVER_HUE_UPDATE_PERIOD, + SL_BTMESH_HSL_SERVER_HUE_UPDATE_PERIOD_CFG_VAL, hue_transition_timer_cb, NO_CALLBACK_DATA, true); @@ -283,15 +283,15 @@ void sl_btmesh_hsl_set_hue_level(uint16_t hue, uint32_t transition_ms) ******************************************************************************/ void sl_btmesh_hsl_set_saturation_level(uint16_t saturation, uint32_t transition_ms) { -#if HSL_SERVER_MINIMUM_SATURATION != (0) - if (saturation < HSL_SERVER_MINIMUM_SATURATION) { - saturation = HSL_SERVER_MINIMUM_SATURATION; +#if SL_BTMESH_HSL_SERVER_MINIMUM_SATURATION_CFG_VAL != (0) + if (saturation < SL_BTMESH_HSL_SERVER_MINIMUM_SATURATION_CFG_VAL) { + saturation = SL_BTMESH_HSL_SERVER_MINIMUM_SATURATION_CFG_VAL; } #endif -#if HSL_SERVER_MAXIMUM_SATURATION != (65535) - if (saturation > HSL_SERVER_MAXIMUM_SATURATION) { - saturation = HSL_SERVER_MAXIMUM_SATURATION; +#if SL_BTMESH_HSL_SERVER_MAXIMUM_SATURATION_CFG_VAL != (65535) + if (saturation > SL_BTMESH_HSL_SERVER_MAXIMUM_SATURATION_CFG_VAL) { + saturation = SL_BTMESH_HSL_SERVER_MAXIMUM_SATURATION_CFG_VAL; } #endif @@ -321,7 +321,7 @@ void sl_btmesh_hsl_set_saturation_level(uint16_t saturation, uint32_t transition // enabling timer IRQ -> the temperature is adjusted in timer interrupt // gradually until target temperature is reached. sl_status_t sc = sl_simple_timer_start(&saturation_transition_timer, - HSL_SERVER_SATURATION_UPDATE_PERIOD, + SL_BTMESH_HSL_SERVER_SATURATION_UPDATE_PERIOD_CFG_VAL, saturation_transition_timer_cb, NO_CALLBACK_DATA, true); diff --git a/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_signal_transition_handler.h b/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_signal_transition_handler.h index 577035f6469..6d1073032d2 100644 --- a/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_signal_transition_handler.h +++ b/app/bluetooth/common/btmesh_hsl_server/sl_btmesh_hsl_signal_transition_handler.h @@ -66,7 +66,7 @@ void sl_btmesh_hsl_saturation_cb(uint16_t saturation); /***************************************************************************//** * Called when the UI shall be updated with the changed HSL Model state during * a transition. The rate of this callback can be controlled by changing the - * HSL_SERVER_HUE_UI_UPDATE_PERIOD macro. + * SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL macro. * * This is a callback which can be implemented in the application. * @note If no implementation is provided in the application then a default weak @@ -79,7 +79,7 @@ void sl_btmesh_hsl_hue_on_ui_update(uint16_t hue); /***************************************************************************//** * Called when the UI shall be updated with the changed HSL Model state during * a transition. The rate of this callback can be controlled by changing the - * HSL_SERVER_SATURATION_UI_UPDATE_PERIOD macro. + * SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL macro. * * This is a callback which can be implemented in the application. * @note If no implementation is provided in the application then a default weak diff --git a/app/bluetooth/common/btmesh_lc_server/config/sl_btmesh_lc_server_config.h b/app/bluetooth/common/btmesh_lc_server/config/sl_btmesh_lc_server_config.h index 159f921bfbb..1dca95c346c 100644 --- a/app/bluetooth/common/btmesh_lc_server/config/sl_btmesh_lc_server_config.h +++ b/app/bluetooth/common/btmesh_lc_server/config/sl_btmesh_lc_server_config.h @@ -34,95 +34,95 @@ // LC Server configuration -// Timeout [ms] for saving States of the model to NVM. +// Timeout [ms] for saving States of the model to NVM. // Default: 5000 // Timeout [ms] for saving States of the model to NVM. -#define LC_SERVER_NVM_SAVE_TIME (5000) +#define SL_BTMESH_LC_SERVER_NVM_SAVE_TIME_CFG_VAL (5000) -// PS Key for NVM Page where the States of the LC Model are saved. +// PS Key for NVM Page where the States of the LC Model are saved. // Default: 0x4006 // PS Key for NVM Page where the States of the LC Model are saved. -#define LC_SERVER_PS_KEY (0x4006) +#define SL_BTMESH_LC_SERVER_PS_KEY_CFG_VAL (0x4006) -// PS Key for NVM Page where the Property State of the LC Model are saved. +// PS Key for NVM Page where the Property State of the LC Model are saved. // Default: 0x4007 // PS Key for NVM Page where the Property State of the LC Model are saved. -#define LC_SERVER_PROPERTY_PS_KEY (0x4007) +#define SL_BTMESH_LC_SERVER_PROPERTY_PS_KEY_CFG_VAL (0x4007) -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable Logging for LC Server model specific messages for this component. -#define LC_SERVER_LOGGING (1) +#define SL_BTMESH_LC_SERVER_LOGGING_CFG_VAL (1) // // -// Customize LC Property states' default values -#define LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE 0 +// Customize LC Property states' default values +#define SL_BTMESH_LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE_CFG_VAL 0 // Time -// Occupancy Delay [ms] <0x000000-0xFFFFFF> +// Occupancy Delay [ms] <0x000000-0xFFFFFF> // Determines the delay for changing the LC Occupancy state upon receiving a Sensor Status message from an occupancy sensor. // LC Occupancy is a binary state that represents occupancy reported by an occupancy sensor. -#define LC_SERVER_TIME_OCCUPANCY_DELAY_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_TIME_OCCUPANCY_DELAY_DEFAULT_CFG_VAL 0 -// Fade On [ms] <0x000000-0xFFFFFF> +// Fade On [ms] <0x000000-0xFFFFFF> // Determines the time the controlled lights fade to the level determined by the LC Lightness On state. -#define LC_SERVER_TIME_FADE_ON_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_TIME_FADE_ON_DEFAULT_CFG_VAL 0 -// Run On [ms] <0x000000-0xFFFFFF> +// Run On [ms] <0x000000-0xFFFFFF> // Determines the time the controlled lights stay at the level determined by the LC Lightness On state since the occupancy input stopped detecting active occupancy information. -#define LC_SERVER_TIME_RUN_ON_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_TIME_RUN_ON_DEFAULT_CFG_VAL 0 -// Fade [ms] <0x000000-0xFFFFFF> +// Fade [ms] <0x000000-0xFFFFFF> // Determines the time the controlled lights fade from the level determined by the LC Lightness On state to the level determined by the Lightness Prolong state. -#define LC_SERVER_TIME_FADE_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_TIME_FADE_DEFAULT_CFG_VAL 0 -// Prolong [ms] <0x000000-0xFFFFFF> +// Prolong [ms] <0x000000-0xFFFFFF> // Determines the time the controlled lights stay at the level determined by the LC Lightness Prolong state. -#define LC_SERVER_TIME_PROLONG_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_TIME_PROLONG_DEFAULT_CFG_VAL 0 -// Fade Standby Auto [ms] <0x000000-0xFFFFFF> +// Fade Standby Auto [ms] <0x000000-0xFFFFFF> // Determines the time the controlled lights fade from the level determined by the LC Lightness Prolong state to the level determined by the LC Lightness Standby state when the transition is automatic. -#define LC_SERVER_TIME_FADE_STANDBY_AUTO_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_TIME_FADE_STANDBY_AUTO_DEFAULT_CFG_VAL 0 -// Fade Standby Manual [ms] <0x000000-0xFFFFFF> +// Fade Standby Manual [ms] <0x000000-0xFFFFFF> // Determines the time the controlled lights fade from the level determined by the LC Lightness Prolong state to the level determined by the LC Lightness Standby state when the transition is triggered by a change in the LC Light OnOff state. -#define LC_SERVER_TIME_FADE_STANDBY_MANUAL_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_TIME_FADE_STANDBY_MANUAL_DEFAULT_CFG_VAL 0 // // Lightness -// On <0x0000-0xFFFF> +// On <0x0000-0xFFFF> // Determines the perceptive light lightness at the Occupancy and Run internal controller states. -#define LC_SERVER_LIGHTNESS_ON_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_LIGHTNESS_ON_DEFAULT_CFG_VAL 0 -// Prolong <0x0000-0xFFFF> +// Prolong <0x0000-0xFFFF> // Determines the light lightness at the Prolong internal controller state. -#define LC_SERVER_LIGHTNESS_PROLONG_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_LIGHTNESS_PROLONG_DEFAULT_CFG_VAL 0 -// Standby <0x0000-0xFFFF> +// Standby <0x0000-0xFFFF> // Determines the light lightness at the Standby internal controller state. -#define LC_SERVER_LIGHTNESS_STANDBY_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_LIGHTNESS_STANDBY_DEFAULT_CFG_VAL 0 // // Ambient -// LuxLevel On [lux] <0x0000-0xFFFF> +// LuxLevel On [lux] <0x0000-0xFFFF> // Represents the level that determines if the controller transitions from the Light Control Standby state. -#define LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT_CFG_VAL 0 -// LuxLevel Prolong [lux] <0x0000-0xFFFF> +// LuxLevel Prolong [lux] <0x0000-0xFFFF> // Represents the required level in the Prolong state. -#define LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT_CFG_VAL 0 -// LuxLevel Standby [lux] <0x0000-0xFFFF> +// LuxLevel Standby [lux] <0x0000-0xFFFF> // Represents the required level in the Standby state. -#define LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT 0 +#define SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT_CFG_VAL 0 // diff --git a/app/bluetooth/common/btmesh_lc_server/sl_btmesh_lc_server.c b/app/bluetooth/common/btmesh_lc_server/sl_btmesh_lc_server.c index 2feef4b4c54..e7c7e7adf81 100644 --- a/app/bluetooth/common/btmesh_lc_server/sl_btmesh_lc_server.c +++ b/app/bluetooth/common/btmesh_lc_server/sl_btmesh_lc_server.c @@ -237,7 +237,7 @@ static sl_status_t lc_state_load(void) size_t ps_len = 0; struct lc_state ps_data; - sc = sl_bt_nvm_load(LC_SERVER_PS_KEY, + sc = sl_bt_nvm_load(SL_BTMESH_LC_SERVER_PS_KEY_CFG_VAL, sizeof(ps_data), &ps_len, (uint8_t *)&ps_data); @@ -278,7 +278,7 @@ static sl_status_t lc_state_load(void) ******************************************************************************/ static int lc_state_store(void) { - sl_status_t sc = sl_bt_nvm_save(LC_SERVER_PS_KEY, + sl_status_t sc = sl_bt_nvm_save(SL_BTMESH_LC_SERVER_PS_KEY_CFG_VAL, sizeof(struct lc_state), (const uint8_t *)&lc_state); @@ -297,7 +297,7 @@ static int lc_state_store(void) static void lc_state_changed(void) { sl_status_t sc = sl_simple_timer_start(&lc_save_state_timer, - LC_SERVER_NVM_SAVE_TIME, + SL_BTMESH_LC_SERVER_NVM_SAVE_TIME_CFG_VAL, lc_save_state_timer_cb, NO_CALLBACK_DATA, false); @@ -393,7 +393,7 @@ static sl_status_t lc_property_state_load(void) size_t ps_len = 0; struct lc_property_state ps_data; - sc = sl_bt_nvm_load(LC_SERVER_PROPERTY_PS_KEY, + sc = sl_bt_nvm_load(SL_BTMESH_LC_SERVER_PROPERTY_PS_KEY_CFG_VAL, sizeof(ps_data), &ps_len, (uint8_t *)&ps_data); @@ -401,27 +401,27 @@ static sl_status_t lc_property_state_load(void) // Set default values if ps_load fail or size of lc_property_state has changed if ((sc != SL_STATUS_OK) || (ps_len != sizeof(lc_property_state))) { memset(&lc_property_state, 0, sizeof(lc_property_state)); -#if LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE +#if SL_BTMESH_LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE_CFG_VAL lc_property_state.time_occupancy_delay = - LC_SERVER_TIME_OCCUPANCY_DELAY_DEFAULT; - lc_property_state.time_fade_on = LC_SERVER_TIME_FADE_ON_DEFAULT; - lc_property_state.time_run_on = LC_SERVER_TIME_RUN_ON_DEFAULT; - lc_property_state.time_fade = LC_SERVER_TIME_FADE_DEFAULT; - lc_property_state.time_prolong = LC_SERVER_TIME_PROLONG_DEFAULT; + SL_BTMESH_LC_SERVER_TIME_OCCUPANCY_DELAY_DEFAULT_CFG_VAL; + lc_property_state.time_fade_on = SL_BTMESH_LC_SERVER_TIME_FADE_ON_DEFAULT_CFG_VAL; + lc_property_state.time_run_on = SL_BTMESH_LC_SERVER_TIME_RUN_ON_DEFAULT_CFG_VAL; + lc_property_state.time_fade = SL_BTMESH_LC_SERVER_TIME_FADE_DEFAULT_CFG_VAL; + lc_property_state.time_prolong = SL_BTMESH_LC_SERVER_TIME_PROLONG_DEFAULT_CFG_VAL; lc_property_state.time_fade_standby_auto = - LC_SERVER_TIME_FADE_STANDBY_AUTO_DEFAULT; + SL_BTMESH_LC_SERVER_TIME_FADE_STANDBY_AUTO_DEFAULT_CFG_VAL; lc_property_state.time_fade_standby_manual = - LC_SERVER_TIME_FADE_STANDBY_MANUAL_DEFAULT; - lc_property_state.lightness_on = LC_SERVER_LIGHTNESS_ON_DEFAULT; - lc_property_state.lightness_prolong = LC_SERVER_LIGHTNESS_PROLONG_DEFAULT; - lc_property_state.lightness_standby = LC_SERVER_LIGHTNESS_STANDBY_DEFAULT; + SL_BTMESH_LC_SERVER_TIME_FADE_STANDBY_MANUAL_DEFAULT_CFG_VAL; + lc_property_state.lightness_on = SL_BTMESH_LC_SERVER_LIGHTNESS_ON_DEFAULT_CFG_VAL; + lc_property_state.lightness_prolong = SL_BTMESH_LC_SERVER_LIGHTNESS_PROLONG_DEFAULT_CFG_VAL; + lc_property_state.lightness_standby = SL_BTMESH_LC_SERVER_LIGHTNESS_STANDBY_DEFAULT_CFG_VAL; lc_property_state.ambient_luxlevel_on = - LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT; + SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT_CFG_VAL; lc_property_state.ambient_luxlevel_prolong = - LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT; + SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT_CFG_VAL; lc_property_state.ambient_luxlevel_standby = - LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT; -#endif // LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE + SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT_CFG_VAL; +#endif // SL_BTMESH_LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE_CFG_VAL lc_property_state.regulator_kiu = LC_REGULATOR_KIU_DEFAULT; lc_property_state.regulator_kid = LC_REGULATOR_KID_DEFAULT; lc_property_state.regulator_kpu = LC_REGULATOR_KPU_DEFAULT; @@ -461,7 +461,7 @@ static int lc_property_state_store(void) { sl_status_t sc; - sc = sl_bt_nvm_save(LC_SERVER_PROPERTY_PS_KEY, + sc = sl_bt_nvm_save(SL_BTMESH_LC_SERVER_PROPERTY_PS_KEY_CFG_VAL, sizeof(struct lc_property_state), (const uint8_t *)&lc_property_state); @@ -480,7 +480,7 @@ static int lc_property_state_store(void) static void lc_property_state_changed(void) { sl_status_t sc = sl_simple_timer_start(&lc_save_property_state_timer, - LC_SERVER_NVM_SAVE_TIME, + SL_BTMESH_LC_SERVER_NVM_SAVE_TIME_CFG_VAL, lc_save_property_state_timer_cb, NO_CALLBACK_DATA, false); @@ -1166,8 +1166,8 @@ void sl_btmesh_lc_server_on_event(sl_btmesh_msg_t *evt) break; case sl_btmesh_evt_node_reset_id: - sl_bt_nvm_erase(LC_SERVER_PS_KEY); - sl_bt_nvm_erase(LC_SERVER_PROPERTY_PS_KEY); + sl_bt_nvm_erase(SL_BTMESH_LC_SERVER_PS_KEY_CFG_VAL); + sl_bt_nvm_erase(SL_BTMESH_LC_SERVER_PROPERTY_PS_KEY_CFG_VAL); break; default: diff --git a/app/bluetooth/common/btmesh_lighting_client/config/sl_btmesh_lighting_client_config.h b/app/bluetooth/common/btmesh_lighting_client/config/sl_btmesh_lighting_client_config.h index 909b6a75436..6a3b013f8c8 100644 --- a/app/bluetooth/common/btmesh_lighting_client/config/sl_btmesh_lighting_client_config.h +++ b/app/bluetooth/common/btmesh_lighting_client/config/sl_btmesh_lighting_client_config.h @@ -34,63 +34,63 @@ // Light Lightness Client configuration -// Lighting model restransmission count +// Lighting model restransmission count // Default: 3 // Lighting model restransmission count (How many times Lighting model messages are to be sent out for reliability). -#define LIGHT_RETRANSMISSION_COUNT (3) +#define SL_BTMESH_LIGHT_RETRANSMISSION_COUNT_CFG_VAL (3) -// Lighting model restransmission timeout +// Lighting model restransmission timeout // Default: 50 // Lighting model restransmission timeout. -#define LIGHT_RETRANSMISSION_TIMEOUT (50) +#define SL_BTMESH_LIGHT_RETRANSMISSION_TIMEOUT_CFG_VAL (50) -// ONOFF model restransmission count +// ONOFF model restransmission count // Default: 3 // ONOFF model restransmission count (How many times ONOFF model messages are to be sent out for reliability). -#define ONOFF_RETRANSMISSION_COUNT (3) +#define SL_BTMESH_ONOFF_RETRANSMISSION_COUNT_CFG_VAL (3) -// ONOFF model restransmission timeout +// ONOFF model restransmission timeout // Default: 50 // ONOFF model restransmission timeout. -#define ONOFF_RETRANSMISSION_TIMEOUT (50) +#define SL_BTMESH_ONOFF_RETRANSMISSION_TIMEOUT_CFG_VAL (50) -// Enable lightness value wraparound +// Enable lightness value wraparound // Default: 0 // If the lightness reaches the max or min value then it wraps around. -#define LIGHT_LIGHTNESS_WRAP_ENABLED (0) +#define SL_BTMESH_LIGHT_LIGHTNESS_WRAP_ENABLED_CFG_VAL (0) -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable Logging for Lighting Client model specific messages for this component. -#define LIGHTING_CLIENT_LOGGING (1) +#define SL_BTMESH_LIGHTING_CLIENT_LOGGING_CFG_VAL (1) -// Light should been switched on. +// Light should been switched on. // Set Log text when Light should been switched on -#define ONOFF_LIGHTING_LOGGING_ON "Turn light(s) on\r\n" +#define SL_BTMESH_ONOFF_LIGHTING_LOGGING_ON_CFG_VAL "Turn light(s) on\r\n" -// Light should been switched off. +// Light should been switched off. // Set Log text when Light should been switched off -#define ONOFF_LIGHTING_LOGGING_OFF "Turn light(s) off\r\n" +#define SL_BTMESH_ONOFF_LIGHTING_LOGGING_OFF_CFG_VAL "Turn light(s) off\r\n" -// Log text when new lightness has been set. +// Log text when new lightness has been set. // Set Log text when new lightness has been set -#define LIGHTING_LOGGING_NEW_LIGHTNESS_SET "Set lightness to %u %% / level %u K\r\n" +#define SL_BTMESH_LIGHTING_LOGGING_NEW_LIGHTNESS_SET_CFG_VAL "Set lightness to %u %% / level %u K\r\n" -// Log text when sending a lightness message fails. +// Log text when sending a lightness message fails. // Set Log text in case sending a lightness message fails -#define LIGHTING_LOGGING_CLIENT_PUBLISH_FAIL "Lightness Client Publish failed\r\n" +#define SL_BTMESH_LIGHTING_LOGGING_CLIENT_PUBLISH_FAIL_CFG_VAL "Lightness Client Publish failed\r\n" -// Log text when sending a Lightness Model Message is successful. +// Log text when sending a Lightness Model Message is successful. // Set Log text for sending a Lightness Model Message successfuly. -#define LIGHTING_LOGGING_CLIENT_PUBLISH_SUCCESS "Lightness request sent, trid = %u, delay = %u\r\n" +#define SL_BTMESH_LIGHTING_LOGGING_CLIENT_PUBLISH_SUCCESS_CFG_VAL "Lightness request sent, trid = %u, delay = %u\r\n" -// Log text when sending a On/Off Model message fails. +// Log text when sending a On/Off Model message fails. // Set Log text in case sending a On/Off Model message fails -#define LIGHTING_ONOFF_LOGGING_CLIENT_PUBLISH_FAIL "On/Off Client Publish failed\r\n" +#define SL_BTMESH_LIGHTING_ONOFF_LOGGING_CLIENT_PUBLISH_FAIL_CFG_VAL "On/Off Client Publish failed\r\n" -// Log text when sending a On/Off Model Message is successful. +// Log text when sending a On/Off Model Message is successful. // Set Log text for successfully sending an On/Off Model Message. -#define LIGHTING_ONOFF_LOGGING_CLIENT_PUBLISH_SUCCESS "CTL On/off request sent, trid = %u, delay = %u\r\n" +#define SL_BTMESH_LIGHTING_ONOFF_LOGGING_CLIENT_PUBLISH_SUCCESS_CFG_VAL "CTL On/off request sent, trid = %u, delay = %u\r\n" // diff --git a/app/bluetooth/common/btmesh_lighting_client/sl_btmesh_lighting_client.c b/app/bluetooth/common/btmesh_lighting_client/sl_btmesh_lighting_client.c index 73aedf4c18a..de779645d17 100644 --- a/app/bluetooth/common/btmesh_lighting_client/sl_btmesh_lighting_client.c +++ b/app/bluetooth/common/btmesh_lighting_client/sl_btmesh_lighting_client.c @@ -152,9 +152,9 @@ static void send_onoff_request(uint8_t retrans) ); if (sc == SL_STATUS_OK) { - log_info(LIGHTING_ONOFF_LOGGING_CLIENT_PUBLISH_SUCCESS, onoff_trid, delay); + log_info(SL_BTMESH_LIGHTING_ONOFF_LOGGING_CLIENT_PUBLISH_SUCCESS_CFG_VAL, onoff_trid, delay); } else { - log_btmesh_status_f(sc, LIGHTING_ONOFF_LOGGING_CLIENT_PUBLISH_FAIL); + log_btmesh_status_f(sc, SL_BTMESH_LIGHTING_ONOFF_LOGGING_CLIENT_PUBLISH_FAIL_CFG_VAL); } // Keep track of how many requests has been sent @@ -204,11 +204,11 @@ static void send_lightness_request(uint8_t retrans) ); if (sc == SL_STATUS_OK) { - log_info(LIGHTING_LOGGING_CLIENT_PUBLISH_SUCCESS, + log_info(SL_BTMESH_LIGHTING_LOGGING_CLIENT_PUBLISH_SUCCESS_CFG_VAL, lightness_trid, delay); } else { - log_btmesh_status_f(sc, LIGHTING_LOGGING_CLIENT_PUBLISH_FAIL); + log_btmesh_status_f(sc, SL_BTMESH_LIGHTING_LOGGING_CLIENT_PUBLISH_FAIL_CFG_VAL); } // Keep track of how many requests has been sent @@ -230,7 +230,7 @@ void sl_btmesh_change_lightness(int8_t change_percentage) if (change_percentage > 0) { lightness_percent += change_percentage; if (lightness_percent > LIGHTNESS_PCT_MAX) { -#if (LIGHT_LIGHTNESS_WRAP_ENABLED != 0) +#if (SL_BTMESH_LIGHT_LIGHTNESS_WRAP_ENABLED_CFG_VAL != 0) lightness_percent = 0; #else lightness_percent = LIGHTNESS_PCT_MAX; @@ -238,7 +238,7 @@ void sl_btmesh_change_lightness(int8_t change_percentage) } } else { if (lightness_percent < (-change_percentage)) { -#if (LIGHT_LIGHTNESS_WRAP_ENABLED != 0) +#if (SL_BTMESH_LIGHT_LIGHTNESS_WRAP_ENABLED_CFG_VAL != 0) lightness_percent = LIGHTNESS_PCT_MAX; #else lightness_percent = 0; @@ -269,9 +269,9 @@ void sl_btmesh_set_lightness(uint8_t new_lightness_percentage) } lightness_level = lightness_percent * 0xFFFF / LIGHTNESS_PCT_MAX; - log(LIGHTING_LOGGING_NEW_LIGHTNESS_SET, lightness_percent, lightness_level); + log(SL_BTMESH_LIGHTING_LOGGING_NEW_LIGHTNESS_SET_CFG_VAL, lightness_percent, lightness_level); // Request is sent multiple times to improve reliability - lightness_request_count = LIGHT_RETRANSMISSION_COUNT; + lightness_request_count = SL_BTMESH_LIGHT_RETRANSMISSION_COUNT_CFG_VAL; send_lightness_request(0); // Send the first request @@ -279,7 +279,7 @@ void sl_btmesh_set_lightness(uint8_t new_lightness_percentage) // to trigger retransmission of the request after 50 ms delay if (lightness_request_count > 0) { sl_status_t sc = sl_simple_timer_start(&light_retransmission_timer, - LIGHT_RETRANSMISSION_TIMEOUT, + SL_BTMESH_LIGHT_RETRANSMISSION_TIMEOUT_CFG_VAL, light_retransmission_timer_cb, NO_CALLBACK_DATA, true); @@ -306,14 +306,14 @@ void sl_btmesh_change_switch_position(uint8_t position) // Turns light ON or OFF, using Generic OnOff model if (switch_pos) { - log(ONOFF_LIGHTING_LOGGING_ON); + log(SL_BTMESH_ONOFF_LIGHTING_LOGGING_ON_CFG_VAL); lightness_percent = LIGHTNESS_PCT_MAX; } else { - log(ONOFF_LIGHTING_LOGGING_OFF); + log(SL_BTMESH_ONOFF_LIGHTING_LOGGING_OFF_CFG_VAL); lightness_percent = 0; } // Request is sent 3 times to improve reliability - onoff_request_count = ONOFF_RETRANSMISSION_COUNT; + onoff_request_count = SL_BTMESH_ONOFF_RETRANSMISSION_COUNT_CFG_VAL; send_onoff_request(0); // Send the first request @@ -321,7 +321,7 @@ void sl_btmesh_change_switch_position(uint8_t position) // to trigger retransmission of the request after 50 ms delay if (onoff_request_count > 0) { sl_status_t sc = sl_simple_timer_start(&onoff_retransmission_timer, - ONOFF_RETRANSMISSION_TIMEOUT, + SL_BTMESH_ONOFF_RETRANSMISSION_TIMEOUT_CFG_VAL, onoff_retransmission_timer_cb, NO_CALLBACK_DATA, true); diff --git a/app/bluetooth/common/btmesh_lighting_server/config/sl_btmesh_lighting_server_config.h b/app/bluetooth/common/btmesh_lighting_server/config/sl_btmesh_lighting_server_config.h index 772a61c70b3..4b99db69cef 100644 --- a/app/bluetooth/common/btmesh_lighting_server/config/sl_btmesh_lighting_server_config.h +++ b/app/bluetooth/common/btmesh_lighting_server/config/sl_btmesh_lighting_server_config.h @@ -34,61 +34,61 @@ // Light Lightness Server configuration -// Timeout [ms] for saving States of the model to NVM. +// Timeout [ms] for saving States of the model to NVM. // Default: 5000 // Timeout [ms] for saving States of the model to NVM. -#define LIGHTING_SERVER_NVM_SAVE_TIME (5000) +#define SL_BTMESH_LIGHTING_SERVER_NVM_SAVE_TIME_CFG_VAL (5000) -// PS Key for NVM Page where the States of the Lighting Model are saved. +// PS Key for NVM Page where the States of the Lighting Model are saved. // Default: 0x4004 // PS Key for NVM Page where the States of the Lighting Model are saved. -#define LIGHTING_SERVER_PS_KEY (0x4004) +#define SL_BTMESH_LIGHTING_SERVER_PS_KEY_CFG_VAL (0x4004) -// Periodicity [ms] for updating the PWM duty cycle during a transition. +// Periodicity [ms] for updating the PWM duty cycle during a transition. // Default: 1 // Periodicity [ms] for updating the PWM duty cycle during a transition. -#define LIGHTING_SERVER_PWM_UPDATE_PERIOD (1) +#define SL_BTMESH_LIGHTING_SERVER_PWM_UPDATE_PERIOD_CFG_VAL (1) -// for updating the UI with lightness level during a transition. +// for updating the UI with lightness level during a transition. // Default: 100 // Periodicity [ms] for updating the UI with lightness level during a transition. -#define LIGHTING_SERVER_UI_UPDATE_PERIOD (100) +#define SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL (100) -// Timer value for minimum PWM duty cycle. +// Timer value for minimum PWM duty cycle. // Default: 1 // Timer value for minimum PWM duty cycle. -#define LIGHTING_SERVER_PWM_MINIMUM_BRIGHTNESS (1) +#define SL_BTMESH_LIGHTING_SERVER_PWM_MINIMUM_BRIGHTNESS_CFG_VAL (1) -// Timer value for maximum PWM duty cycle. +// Timer value for maximum PWM duty cycle. // Default: 0xFFFE // Timer value for minimum PWM duty cycle. -#define LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS (0xFFFE) +#define SL_BTMESH_LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS_CFG_VAL (0xFFFE) // Lightness Range -// Minimum lightness value <0x0001-0xFFFF> +// Minimum lightness value <0x0001-0xFFFF> // Determines the minimum non-zero lightness an element is configured to emit. // Default: 0x0001 -#define LIGHTING_SERVER_LIGHTNESS_MIN 0x0001 +#define SL_BTMESH_LIGHTING_SERVER_LIGHTNESS_MIN_CFG_VAL 0x0001 -// Maximum lightness value <0x0001-0xFFFF> +// Maximum lightness value <0x0001-0xFFFF> // Determines the maximum lightness an element is configured to emit. // The value of the Light Lightness Range Max state shall be greater than // or equal to the value of the Light Lightness Range Min state. // Default: 0xFFFF -#define LIGHTING_SERVER_LIGHTNESS_MAX 0xFFFF +#define SL_BTMESH_LIGHTING_SERVER_LIGHTNESS_MAX_CFG_VAL 0xFFFF // -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable Logging for Lighting Server model specific messages for this component. -#define LIGHTING_SERVER_LOGGING (1) +#define SL_BTMESH_LIGHTING_SERVER_LOGGING_CFG_VAL (1) -// Enable debug prints for each server state changed event. +// Enable debug prints for each server state changed event. // Default: 0 // Enable debug prints for each server state changed event. -#define LIGHTING_SERVER_DEBUG_PRINTS_FOR_STATE_CHANGE_EVENTS (0) +#define SL_BTMESH_LIGHTING_SERVER_DEBUG_PRINTS_FOR_STATE_CHANGE_EVENTS_CFG_VAL (0) // @@ -97,14 +97,14 @@ // <<< end of configuration section >>> // The PWM update period shall not be greater than the UI update period -#if (LIGHTING_SERVER_UI_UPDATE_PERIOD) < (LIGHTING_SERVER_PWM_UPDATE_PERIOD) -#error "The LIGHTING_SERVER_PWM_UPDATE_PERIOD shall be less than LIGHTING_SERVER_UI_UPDATE_PERIOD." +#if (SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL) < (SL_BTMESH_LIGHTING_SERVER_PWM_UPDATE_PERIOD_CFG_VAL) +#error "The SL_BTMESH_LIGHTING_SERVER_PWM_UPDATE_PERIOD_CFG_VAL shall be less than SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL." #endif // Lightness maximum value cannot be less than minimum value -#if (LIGHTING_SERVER_LIGHTNESS_MAX) < (LIGHTING_SERVER_LIGHTNESS_MIN) +#if (SL_BTMESH_LIGHTING_SERVER_LIGHTNESS_MAX_CFG_VAL) < (SL_BTMESH_LIGHTING_SERVER_LIGHTNESS_MIN_CFG_VAL) #error The value of the Lightness Range Max shall be greater than or equal to \ the value of the Lightness Range Min state. -#endif // (LIGHTING_SERVER_LIGHTNESS_MAX) < (LIGHTING_SERVER_LIGHTNESS_MIN) +#endif // (SL_BTMESH_LIGHTING_SERVER_LIGHTNESS_MAX_CFG_VAL) < (SL_BTMESH_LIGHTING_SERVER_LIGHTNESS_MIN_CFG_VAL) #endif // SL_BTMESH_LIGHTING_SERVER_CONFIG_H diff --git a/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_level_transition_handler.c b/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_level_transition_handler.c index 72e0f225ae7..fe252535841 100644 --- a/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_level_transition_handler.c +++ b/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_level_transition_handler.c @@ -101,7 +101,7 @@ static void transition_timer_cb(sl_simple_timer_t *handle, // Initialize the variable to UI update period in order to trigger a UI update // at the beginning of the transition. static uint16_t time_elapsed_since_ui_update = - LIGHTING_SERVER_UI_UPDATE_PERIOD; + SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL; if (!level_transitioning) { sl_status_t sc = sl_simple_timer_stop(&transition_timer); @@ -117,7 +117,7 @@ static void transition_timer_cb(sl_simple_timer_t *handle, // Set the variable to UI update period in order to trigger a UI update // at the beginning of the next transition. - time_elapsed_since_ui_update = LIGHTING_SERVER_UI_UPDATE_PERIOD; + time_elapsed_since_ui_update = SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL; // Trigger a UI update in order to provide the target values at the end // of the current transition @@ -137,12 +137,12 @@ static void transition_timer_cb(sl_simple_timer_t *handle, } // When transition is ongoing generate an event to application once every - // CTL_SERVER_UI_UPDATE_PERIOD ms because the event is used to update display + // SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL ms because the event is used to update display // status and therefore the rate should not be too high - time_elapsed_since_ui_update += LIGHTING_SERVER_PWM_UPDATE_PERIOD; + time_elapsed_since_ui_update += SL_BTMESH_LIGHTING_SERVER_PWM_UPDATE_PERIOD_CFG_VAL; - if (LIGHTING_SERVER_UI_UPDATE_PERIOD <= time_elapsed_since_ui_update) { - time_elapsed_since_ui_update -= LIGHTING_SERVER_UI_UPDATE_PERIOD; + if (SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL <= time_elapsed_since_ui_update) { + time_elapsed_since_ui_update -= SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL; sl_btmesh_lighting_server_on_ui_update(current_level); } } @@ -185,7 +185,7 @@ void sl_btmesh_lighting_set_level(uint16_t level, uint32_t transition_ms) // enabling timer IRQ -> the PWM level is adjusted in timer interrupt // gradually until target level is reached. sl_status_t sc = sl_simple_timer_start(&transition_timer, - LIGHTING_SERVER_PWM_UPDATE_PERIOD, + SL_BTMESH_LIGHTING_SERVER_PWM_UPDATE_PERIOD_CFG_VAL, transition_timer_cb, NO_CALLBACK_DATA, true); @@ -205,16 +205,16 @@ void sl_btmesh_set_state(int state) switch (state) { case LED_STATE_OFF: - sl_btmesh_lighting_set_level(LIGHTING_SERVER_PWM_MINIMUM_BRIGHTNESS, 0); + sl_btmesh_lighting_set_level(SL_BTMESH_LIGHTING_SERVER_PWM_MINIMUM_BRIGHTNESS_CFG_VAL, 0); break; case LED_STATE_ON: - sl_btmesh_lighting_set_level(LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS, 0); + sl_btmesh_lighting_set_level(SL_BTMESH_LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS_CFG_VAL, 0); break; case LED_STATE_PROV: if (++toggle % 2) { - sl_btmesh_lighting_set_level(LIGHTING_SERVER_PWM_MINIMUM_BRIGHTNESS, 0); + sl_btmesh_lighting_set_level(SL_BTMESH_LIGHTING_SERVER_PWM_MINIMUM_BRIGHTNESS_CFG_VAL, 0); } else { - sl_btmesh_lighting_set_level(LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS, 0); + sl_btmesh_lighting_set_level(SL_BTMESH_LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS_CFG_VAL, 0); } break; diff --git a/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_level_transition_handler.h b/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_level_transition_handler.h index aa74e44dde8..9ce6758b18d 100644 --- a/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_level_transition_handler.h +++ b/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_level_transition_handler.h @@ -67,7 +67,7 @@ void sl_btmesh_lighting_level_pwm_cb(uint16_t level); /***************************************************************************//** * Called when the UI shall be updated with the changed state of * lightning server during a transition. The rate of this callback can be - * controlled by changing the LIGHTING_SERVER_UI_UPDATE_PERIOD macro. + * controlled by changing the SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL macro. * * This is a callback which can be implemented in the application. * @note If no implementation is provided in the application then a default weak diff --git a/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_server.c b/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_server.c index 623925a4ffb..853b3bfc397 100644 --- a/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_server.c +++ b/app/bluetooth/common/btmesh_lighting_server/sl_btmesh_lighting_server.c @@ -278,8 +278,8 @@ uint16_t sl_btmesh_get_lightness_onpowerup(void) return lightbulb_state.onpowerup; } -#if defined(LIGHTING_SERVER_DEBUG_PRINTS_FOR_STATE_CHANGE_EVENTS) \ - && LIGHTING_SERVER_DEBUG_PRINTS_FOR_STATE_CHANGE_EVENTS +#if defined(SL_BTMESH_LIGHTING_SERVER_DEBUG_PRINTS_FOR_STATE_CHANGE_EVENTS_CFG_VAL) \ + && SL_BTMESH_LIGHTING_SERVER_DEBUG_PRINTS_FOR_STATE_CHANGE_EVENTS_CFG_VAL /***************************************************************************//** * This function prints debug information for mesh server state change event. * @@ -318,11 +318,11 @@ void sl_btmesh_lighting_server_on_event(sl_btmesh_msg_t *evt) } break; case sl_btmesh_evt_node_reset_id: - sl_bt_nvm_erase(LIGHTING_SERVER_PS_KEY); + sl_bt_nvm_erase(SL_BTMESH_LIGHTING_SERVER_PS_KEY_CFG_VAL); break; case sl_btmesh_evt_generic_server_state_changed_id: -#if defined(LIGHTING_SERVER_DEBUG_PRINTS_FOR_STATE_CHANGE_EVENTS) \ - && LIGHTING_SERVER_DEBUG_PRINTS_FOR_STATE_CHANGE_EVENTS +#if defined(SL_BTMESH_LIGHTING_SERVER_DEBUG_PRINTS_FOR_STATE_CHANGE_EVENTS_CFG_VAL) \ + && SL_BTMESH_LIGHTING_SERVER_DEBUG_PRINTS_FOR_STATE_CHANGE_EVENTS_CFG_VAL server_state_changed(&(evt->data.evt_generic_server_state_changed)); #endif // LOG_ENABLE break; @@ -2267,7 +2267,7 @@ static void init_models(void) /***************************************************************************//** * This function loads the saved light state from Persistent Storage and * copies the data in the global variable lightbulb_state. - * If PS key with ID LIGHTING_SERVER_PS_KEY does not exist or loading failed, + * If PS key with ID SL_BTMESH_LIGHTING_SERVER_PS_KEY_CFG_VAL does not exist or loading failed, * lightbulb_state is set to zero and some default values are written to it. * * @return Returns SL_STATUS_OK (0) if succeed, non-zero otherwise. @@ -2278,7 +2278,7 @@ static sl_status_t lightbulb_state_load(void) size_t ps_len = 0; struct lightbulb_state ps_data; - sc = sl_bt_nvm_load(LIGHTING_SERVER_PS_KEY, + sc = sl_bt_nvm_load(SL_BTMESH_LIGHTING_SERVER_PS_KEY_CFG_VAL, sizeof(ps_data), &ps_len, (uint8_t *)&ps_data); @@ -2288,8 +2288,8 @@ static sl_status_t lightbulb_state_load(void) memset(&lightbulb_state, 0, sizeof(struct lightbulb_state)); lightbulb_state.lightness_last = LIGHTNESS_LAST_DEFAULT; lightbulb_state.lightness_default = LIGHTNESS_DEFAULT_DEFAULT; - lightbulb_state.lightness_min = LIGHTING_SERVER_LIGHTNESS_MIN; - lightbulb_state.lightness_max = LIGHTING_SERVER_LIGHTNESS_MAX; + lightbulb_state.lightness_min = SL_BTMESH_LIGHTING_SERVER_LIGHTNESS_MIN_CFG_VAL; + lightbulb_state.lightness_max = SL_BTMESH_LIGHTING_SERVER_LIGHTNESS_MAX_CFG_VAL; // Check if default values are valid and correct them if needed lightbulb_state_validate_and_correct(); @@ -2349,7 +2349,7 @@ static void lightbulb_state_validate_and_correct(void) * This function saves the current light state in Persistent Storage so that * the data is preserved over reboots and power cycles. * The light state is hold in a global variable lightbulb_state. - * A PS key with ID LIGHTING_SERVER_PS_KEY is used to store the whole struct. + * A PS key with ID SL_BTMESH_LIGHTING_SERVER_PS_KEY_CFG_VAL is used to store the whole struct. * * @return Returns SL_STATUS_OK (0) if succeed, non-zero otherwise. ******************************************************************************/ @@ -2357,7 +2357,7 @@ static sl_status_t lightbulb_state_store(void) { sl_status_t sc; - sc = sl_bt_nvm_save(LIGHTING_SERVER_PS_KEY, + sc = sl_bt_nvm_save(SL_BTMESH_LIGHTING_SERVER_PS_KEY_CFG_VAL, sizeof(struct lightbulb_state), (const uint8_t*)&lightbulb_state); @@ -2376,7 +2376,7 @@ static sl_status_t lightbulb_state_store(void) static void lightbulb_state_changed(void) { sl_status_t sc = sl_simple_timer_start(&lighting_state_store_timer, - LIGHTING_SERVER_NVM_SAVE_TIME, + SL_BTMESH_LIGHTING_SERVER_NVM_SAVE_TIME_CFG_VAL, lighting_state_store_timer_cb, NO_CALLBACK_DATA, false); diff --git a/app/bluetooth/common/btmesh_lpn/config/sl_btmesh_lpn_config.h b/app/bluetooth/common/btmesh_lpn/config/sl_btmesh_lpn_config.h index dc6e4713fd1..97fb2c0fbbc 100644 --- a/app/bluetooth/common/btmesh_lpn/config/sl_btmesh_lpn_config.h +++ b/app/bluetooth/common/btmesh_lpn/config/sl_btmesh_lpn_config.h @@ -34,86 +34,86 @@ // LPN configuration -// Minimum queue length the friend must support <2-128> +// Minimum queue length the friend must support <2-128> // Default: 2 // Minimum queue length the friend must support. Choose an appropriate based on the expected message // frequency and LPN sleep period, because messages that do not fit into the friend queue are dropped. // Note that the given value is rounded up to the nearest power of 2 -#define LPN_MIN_QUEUE_LENGTH (2) +#define SL_BTMESH_LPN_MIN_QUEUE_LENGTH_CFG_VAL (2) -// Poll timeout in milliseconds <1000-345599900:100> +// Poll timeout in milliseconds <1000-345599900:100> // Default: 5000 // Poll timeout in milliseconds, which is the longest time that LPN sleeps in between querying its friend // for queued messages. Long poll timeout allows the LPN to sleep for longer periods, at the expense of increased // latency for receiving messages. Note that the given value is rounded up to the nearest 100 ms -#define LPN_POLL_TIMEOUT (5000) +#define SL_BTMESH_LPN_POLL_TIMEOUT_CFG_VAL (5000) -// Receive delay in milliseconds <10-255> +// Receive delay in milliseconds <10-255> // Default: 50 // Receive delay in milliseconds. Receive delay is the time between the LPN sending a request and listening // for a response. Receive delay allows the friend node time to prepare the message and LPN to sleep -#define LPN_RECEIVE_DELAY (50) +#define SL_BTMESH_LPN_RECEIVE_DELAY_CFG_VAL (50) -// The number of retry attempts to repeat <0-10> +// The number of retry attempts to repeat <0-10> // Default: 3 // Request retry is the number of retry attempts to repeat e.g., the friend poll message // if the friend update was not received by the LPN -#define LPN_REQUEST_RETRIES (3) +#define SL_BTMESH_LPN_REQUEST_RETRIES_CFG_VAL (3) -// Time interval between retry attempts in milliseconds <0-100> +// Time interval between retry attempts in milliseconds <0-100> // Default: 100 // Time interval between retry attempts in milliseconds -#define LPN_RETRY_INTERVAL (100) +#define SL_BTMESH_LPN_RETRY_INTERVAL_CFG_VAL (100) // Initialization timeouts -// Timeout for initializing LPN after an already provisioned Node is initialized +// Timeout for initializing LPN after an already provisioned Node is initialized // Default: 30000 // Timeout for initializing LPN after an already provisioned Node is initialized. It can delay friend // establishment to wait for possible Configuration Messages -#define LPN_TIMEOUT_AFTER_PROVISIONED (30000) +#define SL_BTMESH_LPN_TIMEOUT_AFTER_PROVISIONED_CFG_VAL (30000) -// Timeout for initializing LPN after Security Key was added +// Timeout for initializing LPN after Security Key was added // Default: 5000 // Timeout for initializing LPN after Security Key was added. It can delay friend establishment // to wait for possible other Configuration Messages -#define LPN_TIMEOUT_AFTER_KEY (5000) +#define SL_BTMESH_LPN_TIMEOUT_AFTER_KEY_CFG_VAL (5000) -// Timeout for initializing LPN after the Configuration Model changed +// Timeout for initializing LPN after the Configuration Model changed // Default: 5000 // Timeout for initializing LPN after the Configuration Model changed. It can delay friend establishment // to wait for possible other Configuration Messages -#define LPN_TIMEOUT_AFTER_CONFIG_MODEL_CHANGED (5000) +#define SL_BTMESH_LPN_TIMEOUT_AFTER_CONFIG_MODEL_CHANGED_CFG_VAL (5000) -// Timeout for initializing LPN after the Configuration Model Set Message +// Timeout for initializing LPN after the Configuration Model Set Message // Default: 5000 // Timeout for initializing LPN after the Configuration Model Set Message. It can delay friend establishment // to wait for possible other Configuration Messages -#define LPN_TIMEOUT_AFTER_CONFIG_SET (5000) +#define SL_BTMESH_LPN_TIMEOUT_AFTER_CONFIG_SET_CFG_VAL (5000) // -// Timeout between retries to find a friend +// Timeout between retries to find a friend // Default: 2000 // Timeout between retries to find a friend -#define LPN_FRIEND_FIND_TIMEOUT (2000) +#define SL_BTMESH_LPN_FRIEND_FIND_TIMEOUT_CFG_VAL (2000) -// Enable Logging +// Enable Logging // Default: 1 // Enable or disable Logging for LPN specific messages for this component. -#define LPN_LOGGING (1) +#define SL_BTMESH_LPN_LOGGING_CFG_VAL (1) -// Log text when no friend was found. +// Log text when no friend was found. // Log text when no friend was found -#define LPN_FRIEND_NOT_FOUND_LOG_TEXT "Friend not found - Ret.code 0x%lx\r\n" +#define SL_BTMESH_LPN_FRIEND_NOT_FOUND_LOG_TEXT_CFG_VAL "Friend not found - Ret.code 0x%lx\r\n" -// Log text when LPN initialization starts. +// Log text when LPN initialization starts. // Log text when LPN initialization starts -#define LPN_START_INIT_LOG_TEXT "Trying to initialize lpn...\r\n" +#define SL_BTMESH_LPN_START_INIT_LOG_TEXT_CFG_VAL "Trying to initialize lpn...\r\n" -// Log text when friend establishment is attempted. +// Log text when friend establishment is attempted. // Log text when friend establishment is attempted -#define LPN_START_FRIEND_SEARCH_LOG_TEXT "Trying to find a friend...\r\n" +#define SL_BTMESH_LPN_START_FRIEND_SEARCH_LOG_TEXT_CFG_VAL "Trying to find a friend...\r\n" // diff --git a/app/bluetooth/common/btmesh_lpn/sl_btmesh_lpn.c b/app/bluetooth/common/btmesh_lpn/sl_btmesh_lpn.c index dd01e3dd5c6..1abec800c5e 100644 --- a/app/bluetooth/common/btmesh_lpn/sl_btmesh_lpn.c +++ b/app/bluetooth/common/btmesh_lpn/sl_btmesh_lpn.c @@ -120,35 +120,35 @@ void sl_btmesh_lpn_feature_init(void) // Configure LPN minimum friend queue length result = sl_btmesh_lpn_config(sl_btmesh_lpn_queue_length, - LPN_MIN_QUEUE_LENGTH); + SL_BTMESH_LPN_MIN_QUEUE_LENGTH_CFG_VAL); if (result) { log("LPN queue configuration failed (0x%lx)\r\n", result); return; } // Configure LPN poll timeout result = sl_btmesh_lpn_config(sl_btmesh_lpn_poll_timeout, - LPN_POLL_TIMEOUT); + SL_BTMESH_LPN_POLL_TIMEOUT_CFG_VAL); if (result) { log("LPN poll timeout configuration failed (0x%lx)\r\n", result); return; } // Configure LPN receive delay result = sl_btmesh_lpn_config(sl_btmesh_lpn_receive_delay, - LPN_RECEIVE_DELAY); + SL_BTMESH_LPN_RECEIVE_DELAY_CFG_VAL); if (result) { log("LPN receive delay configuration failed (0x%lx)\r\n", result); return; } // Configure LPN request retries result = sl_btmesh_lpn_config(sl_btmesh_lpn_request_retries, - LPN_REQUEST_RETRIES); + SL_BTMESH_LPN_REQUEST_RETRIES_CFG_VAL); if (result) { log("LPN request retries configuration failed (0x%lx)\r\n", result); return; } // Configure LPN retry interval result = sl_btmesh_lpn_config(sl_btmesh_lpn_retry_interval, - LPN_RETRY_INTERVAL); + SL_BTMESH_LPN_RETRY_INTERVAL_CFG_VAL); if (result) { log("LPN retry interval configuration failed (0x%lx)\r\n", result); return; @@ -236,19 +236,19 @@ void sl_btmesh_lpn_on_event(sl_btmesh_msg_t* evt) break; case sl_btmesh_evt_node_provisioned_id: - set_configuration_timer(LPN_TIMEOUT_AFTER_PROVISIONED); + set_configuration_timer(SL_BTMESH_LPN_TIMEOUT_AFTER_PROVISIONED_CFG_VAL); break; case sl_btmesh_evt_node_model_config_changed_id: - set_configuration_timer(LPN_TIMEOUT_AFTER_CONFIG_MODEL_CHANGED); + set_configuration_timer(SL_BTMESH_LPN_TIMEOUT_AFTER_CONFIG_MODEL_CHANGED_CFG_VAL); break; case sl_btmesh_evt_node_config_set_id: - set_configuration_timer(LPN_TIMEOUT_AFTER_CONFIG_SET); + set_configuration_timer(SL_BTMESH_LPN_TIMEOUT_AFTER_CONFIG_SET_CFG_VAL); break; case sl_btmesh_evt_node_key_added_id: - set_configuration_timer(LPN_TIMEOUT_AFTER_KEY); + set_configuration_timer(SL_BTMESH_LPN_TIMEOUT_AFTER_KEY_CFG_VAL); break; case sl_btmesh_evt_lpn_friendship_established_id: @@ -262,7 +262,7 @@ void sl_btmesh_lpn_on_event(sl_btmesh_msg_t* evt) // try again after timer expires sl_status_t sc = sl_simple_timer_start(&lpn_friend_find_timer, - LPN_FRIEND_FIND_TIMEOUT, + SL_BTMESH_LPN_FRIEND_FIND_TIMEOUT_CFG_VAL, lpn_friend_find_timer_cb, NO_CALLBACK_DATA, false); @@ -278,7 +278,7 @@ void sl_btmesh_lpn_on_event(sl_btmesh_msg_t* evt) if (num_mesh_proxy_conn == 0) { // try again after timer expires sl_status_t sc = sl_simple_timer_start(&lpn_friend_find_timer, - LPN_FRIEND_FIND_TIMEOUT, + SL_BTMESH_LPN_FRIEND_FIND_TIMEOUT_CFG_VAL, lpn_friend_find_timer_cb, NO_CALLBACK_DATA, false); @@ -314,11 +314,11 @@ static void lpn_establish_friendship(void) { sl_status_t result; - log(LPN_START_FRIEND_SEARCH_LOG_TEXT); + log(SL_BTMESH_LPN_START_FRIEND_SEARCH_LOG_TEXT_CFG_VAL); result = sl_btmesh_lpn_establish_friendship(lpn_friend_netkey_idx); if (result != SL_STATUS_OK) { - log(LPN_FRIEND_NOT_FOUND_LOG_TEXT, result); + log(SL_BTMESH_LPN_FRIEND_NOT_FOUND_LOG_TEXT_CFG_VAL, result); } } @@ -356,7 +356,7 @@ static void lpn_node_configured_timer_cb(sl_simple_timer_t *handle, void *data) (void)handle; if (!lpn_active) { - log(LPN_START_INIT_LOG_TEXT); + log(SL_BTMESH_LPN_START_INIT_LOG_TEXT_CFG_VAL); sl_btmesh_lpn_feature_init(); } } diff --git a/app/bluetooth/common/btmesh_provisioning_decorator/config/sl_btmesh_provisioning_decorator_config.h b/app/bluetooth/common/btmesh_provisioning_decorator/config/sl_btmesh_provisioning_decorator_config.h index de95ef6cfcc..1778262a8cd 100644 --- a/app/bluetooth/common/btmesh_provisioning_decorator/config/sl_btmesh_provisioning_decorator_config.h +++ b/app/bluetooth/common/btmesh_provisioning_decorator/config/sl_btmesh_provisioning_decorator_config.h @@ -34,15 +34,15 @@ // Provisioning decorator configuration -// Enable Logging +// Enable Logging // Default: 1 // Enable or disable Logging for Provisioning Decorator specific messages for this component. -#define PROVISIONING_DECORATOR_LOGGING (1) +#define SL_BTMESH_PROVISIONING_DECORATOR_LOGGING_CFG_VAL (1) // -// Timeout for system restart after provisioning fails -#define PROVISIONING_DECORATOR_RESTART_TIMER_TIMEOUT (2000) +// Timeout for system restart after provisioning fails +#define SL_BTMESH_PROVISIONING_DECORATOR_RESTART_TIMER_TIMEOUT_CFG_VAL (2000) // diff --git a/app/bluetooth/common/btmesh_provisioning_decorator/sl_btmesh_provisioning_decorator.c b/app/bluetooth/common/btmesh_provisioning_decorator/sl_btmesh_provisioning_decorator.c index a89b5901237..7212777379c 100644 --- a/app/bluetooth/common/btmesh_provisioning_decorator/sl_btmesh_provisioning_decorator.c +++ b/app/bluetooth/common/btmesh_provisioning_decorator/sl_btmesh_provisioning_decorator.c @@ -176,11 +176,11 @@ void sl_btmesh_handle_provisioning_decorator_event(sl_btmesh_msg_t *evt) sl_btmesh_on_node_provisioning_failed(evt->data.evt_node_provisioning_failed.result); log("BT mesh system reset timer is started with %d ms timeout.\r\n", - PROVISIONING_DECORATOR_RESTART_TIMER_TIMEOUT); + SL_BTMESH_PROVISIONING_DECORATOR_RESTART_TIMER_TIMEOUT_CFG_VAL); sl_status_t sc = sl_simple_timer_start(&restart_timer, - PROVISIONING_DECORATOR_RESTART_TIMER_TIMEOUT, + SL_BTMESH_PROVISIONING_DECORATOR_RESTART_TIMER_TIMEOUT_CFG_VAL, prov_decor_restart_timer_cb, NO_CALLBACK_DATA, false); diff --git a/app/bluetooth/common/btmesh_scene_client/config/sl_btmesh_scene_client_config.h b/app/bluetooth/common/btmesh_scene_client/config/sl_btmesh_scene_client_config.h index 98029f2dc2a..414889be3d5 100644 --- a/app/bluetooth/common/btmesh_scene_client/config/sl_btmesh_scene_client_config.h +++ b/app/bluetooth/common/btmesh_scene_client/config/sl_btmesh_scene_client_config.h @@ -34,32 +34,32 @@ // Scene Client configuration -// Scene model restransmission count +// Scene model restransmission count // Default: 3 // Scene model restransmission count (How many times Scene model messages are to be sent out for reliability). -#define SCENE_CLIENT_RETRANSMISSION_COUNT (3) +#define SL_BTMESH_SCENE_CLIENT_RETRANSMISSION_COUNT_CFG_VAL (3) -// Scene model restransmission timeout +// Scene model restransmission timeout // Default: 50 // Scene model restransmission timeout. -#define SCENE_CLIENT_RETRANSMISSION_TIMEOUT (50) +#define SL_BTMESH_SCENE_CLIENT_RETRANSMISSION_TIMEOUT_CFG_VAL (50) -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable Logging for Scene Client model specific messages for this component. -#define SCENE_CLIENT_LOGGING (1) +#define SL_BTMESH_SCENE_CLIENT_LOGGING_CFG_VAL (1) -// Log text when recalling a new scene. +// Log text when recalling a new scene. // Set Log text in case the a new scene is recalled -#define SCENE_CLIENT_LOGGING_RECALL "Recall scene number %u\r\n" +#define SL_BTMESH_SCENE_CLIENT_LOGGING_RECALL_CFG_VAL "Recall scene number %u\r\n" -// Log text when recalling a new scene fails. +// Log text when recalling a new scene fails. // Set Log text in case the a scene recall fails -#define SCENE_CLIENT_LOGGING_RECALL_FAIL "Scene recall failed\r\n" +#define SL_BTMESH_SCENE_CLIENT_LOGGING_RECALL_FAIL_CFG_VAL "Scene recall failed\r\n" -// Log text when recalling a scene recall is successful. +// Log text when recalling a scene recall is successful. // Set Log text a scene recall is successful. -#define SCENE_CLIENT_LOGGING_RECALL_SUCCESS "Scene request sent, trid = %u, delay = %u\r\n" +#define SL_BTMESH_SCENE_CLIENT_LOGGING_RECALL_SUCCESS_CFG_VAL "Scene request sent, trid = %u, delay = %u\r\n" // diff --git a/app/bluetooth/common/btmesh_scene_client/sl_btmesh_scene_client.c b/app/bluetooth/common/btmesh_scene_client/sl_btmesh_scene_client.c index aaea6ccfe70..d67a154c437 100644 --- a/app/bluetooth/common/btmesh_scene_client/sl_btmesh_scene_client.c +++ b/app/bluetooth/common/btmesh_scene_client/sl_btmesh_scene_client.c @@ -123,9 +123,9 @@ static void send_scene_recall_request(uint8_t retrans) delay); if (SL_STATUS_OK == sc) { - log_info(SCENE_CLIENT_LOGGING_RECALL_SUCCESS, scene_trid, delay); + log_info(SL_BTMESH_SCENE_CLIENT_LOGGING_RECALL_SUCCESS_CFG_VAL, scene_trid, delay); } else { - log_btmesh_status_f(sc, SCENE_CLIENT_LOGGING_RECALL_FAIL); + log_btmesh_status_f(sc, SL_BTMESH_SCENE_CLIENT_LOGGING_RECALL_FAIL_CFG_VAL); } // Keep track of how many requests has been sent @@ -150,9 +150,9 @@ void sl_btmesh_select_scene(uint8_t scene_to_recall) scene_number = scene_to_recall; // Recall scene using Scene Client model - log(SCENE_CLIENT_LOGGING_RECALL, scene_number); + log(SL_BTMESH_SCENE_CLIENT_LOGGING_RECALL_CFG_VAL, scene_number); // Request is sent multiple times to improve reliability - scene_request_count = SCENE_CLIENT_RETRANSMISSION_COUNT; + scene_request_count = SL_BTMESH_SCENE_CLIENT_RETRANSMISSION_COUNT_CFG_VAL; send_scene_recall_request(0); // Send the first request @@ -160,7 +160,7 @@ void sl_btmesh_select_scene(uint8_t scene_to_recall) // to trigger retransmission of the request after 50 ms delay if (scene_request_count > 0) { sl_status_t sc = sl_simple_timer_start(&app_scene_retransmission_timer, - SCENE_CLIENT_RETRANSMISSION_TIMEOUT, + SL_BTMESH_SCENE_CLIENT_RETRANSMISSION_TIMEOUT_CFG_VAL, scene_retransmission_timer_cb, NO_CALLBACK_DATA, true); diff --git a/app/bluetooth/common/btmesh_scheduler_server/config/sl_btmesh_scheduler_server_config.h b/app/bluetooth/common/btmesh_scheduler_server/config/sl_btmesh_scheduler_server_config.h index 094203d217d..28e6853aff7 100644 --- a/app/bluetooth/common/btmesh_scheduler_server/config/sl_btmesh_scheduler_server_config.h +++ b/app/bluetooth/common/btmesh_scheduler_server/config/sl_btmesh_scheduler_server_config.h @@ -34,10 +34,10 @@ // Scheduler Server configuration -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable Logging for Scheduler Server model specific messages for this component. -#define SCHEDULER_SERVER_LOGGING (1) +#define SL_BTMESH_SCHEDULER_SERVER_LOGGING_CFG_VAL (1) // diff --git a/app/bluetooth/common/btmesh_sensor_client/config/sl_btmesh_sensor_client_config.h b/app/bluetooth/common/btmesh_sensor_client/config/sl_btmesh_sensor_client_config.h index 64cd9da1f8f..821e1a57b09 100644 --- a/app/bluetooth/common/btmesh_sensor_client/config/sl_btmesh_sensor_client_config.h +++ b/app/bluetooth/common/btmesh_sensor_client/config/sl_btmesh_sensor_client_config.h @@ -34,35 +34,35 @@ // Sensor Client configuration -// How many sensors can fit on screen +// How many sensors can fit on screen // Default: 5 // Defines the number of sensors which can fit on the LCD screen. -#define SENSOR_CLIENT_DISPLAYED_SENSORS (5) +#define SL_BTMESH_SENSOR_CLIENT_DISPLAYED_SENSORS_CFG_VAL (5) -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable Logging for Sensor Client model specific messages for this component. -#define SENSOR_CLIENT_LOGGING (1) +#define SL_BTMESH_SENSOR_CLIENT_LOGGING_CFG_VAL (1) -// Log text when registering devices starts +// Log text when registering devices starts // Set Log text in case the registration of devices with a specific sensor property ID is started -#define SENSOR_CLIENT_LOGGING_START_REGISTERING_DEVICES "Registration of devices for property ID %4.4x started\r\n" +#define SL_BTMESH_SENSOR_CLIENT_LOGGING_START_REGISTERING_DEVICES_CFG_VAL "Registration of devices for property ID %4.4x started\r\n" -// Log text when registering devices fails +// Log text when registering devices fails // Set Log text in case the registration of devices with a specific sensor property ID is failed -#define SENSOR_CLIENT_LOGGING_REGISTERING_DEVICES_FAILED "Registration of devices for property ID %4.4x failed\r\n" +#define SL_BTMESH_SENSOR_CLIENT_LOGGING_REGISTERING_DEVICES_FAILED_CFG_VAL "Registration of devices for property ID %4.4x failed\r\n" -// Log text when unsupported sensor property ID +// Log text when unsupported sensor property ID // Set Log text in case the specific sensor property ID is not available on the remote device (e.g. no sensor) -#define SENSOR_CLIENT_LOGGING_UNSUPPORTED_PROPERTY "Unsupported property id %4.4x\r\n" +#define SL_BTMESH_SENSOR_CLIENT_LOGGING_UNSUPPORTED_PROPERTY_CFG_VAL "Unsupported property id %4.4x\r\n" -// Log text when sensor data with property ID is requested +// Log text when sensor data with property ID is requested // Set Log text in case property ID specific sensor data is requested from the remote device(s) -#define SENSOR_CLIENT_LOGGING_GET_DATA_FROM_PROPERTY "Get Sensor Data from property ID %4.4x started\r\n" +#define SL_BTMESH_SENSOR_CLIENT_LOGGING_GET_DATA_FROM_PROPERTY_CFG_VAL "Get Sensor Data from property ID %4.4x started\r\n" -// Log text when sensor data request with property ID fails +// Log text when sensor data request with property ID fails // Set Log text in case property ID specific sensor data request is failed -#define SENSOR_CLIENT_LOGGING_GET_DATA_FROM_PROPERTY_FAIL "Get Sensor Data from property ID %4.4x failed\r\n" +#define SL_BTMESH_SENSOR_CLIENT_LOGGING_GET_DATA_FROM_PROPERTY_FAIL_CFG_VAL "Get Sensor Data from property ID %4.4x failed\r\n" // diff --git a/app/bluetooth/common/btmesh_sensor_client/sl_btmesh_sensor_client.c b/app/bluetooth/common/btmesh_sensor_client/sl_btmesh_sensor_client.c index fdcc2f699d8..1694ccd340f 100644 --- a/app/bluetooth/common/btmesh_sensor_client/sl_btmesh_sensor_client.c +++ b/app/bluetooth/common/btmesh_sensor_client/sl_btmesh_sensor_client.c @@ -81,7 +81,7 @@ static const uint16_t PUBLISH_ADDRESS = 0x0000; typedef struct { - uint16_t address_table[SENSOR_CLIENT_DISPLAYED_SENSORS]; + uint16_t address_table[SL_BTMESH_SENSOR_CLIENT_DISPLAYED_SENSORS_CFG_VAL]; uint8_t count; } mesh_registered_device_properties_address_t; @@ -166,10 +166,10 @@ sl_status_t sl_btmesh_sensor_client_update_registered_devices(mesh_device_proper NO_FLAGS, property); if (SL_STATUS_OK == sc) { - log_info(SENSOR_CLIENT_LOGGING_START_REGISTERING_DEVICES, property); + log_info(SL_BTMESH_SENSOR_CLIENT_LOGGING_START_REGISTERING_DEVICES_CFG_VAL, property); } else { log_btmesh_status_f(sc, - SENSOR_CLIENT_LOGGING_REGISTERING_DEVICES_FAILED, + SL_BTMESH_SENSOR_CLIENT_LOGGING_REGISTERING_DEVICES_FAILED_CFG_VAL, property); } return sc; @@ -190,7 +190,7 @@ static void handle_sensor_client_descriptor_status( SIZE_OF_DESCRIPTOR); uint8_t number_of_devices = registered_devices.count; if (descriptor.property_id == registering_property - && number_of_devices < SENSOR_CLIENT_DISPLAYED_SENSORS + && number_of_devices < SL_BTMESH_SENSOR_CLIENT_DISPLAYED_SENSORS_CFG_VAL && !mesh_address_already_exists(®istered_devices, evt->server_address)) { registered_devices.address_table[number_of_devices] = evt->server_address; @@ -215,10 +215,10 @@ sl_status_t sl_btmesh_sensor_client_get_sensor_data(mesh_device_properties_t pro property); if (SL_STATUS_OK == sc) { - log_info(SENSOR_CLIENT_LOGGING_GET_DATA_FROM_PROPERTY, property); + log_info(SL_BTMESH_SENSOR_CLIENT_LOGGING_GET_DATA_FROM_PROPERTY_CFG_VAL, property); } else { log_btmesh_status_f(sc, - SENSOR_CLIENT_LOGGING_GET_DATA_FROM_PROPERTY_FAIL, + SL_BTMESH_SENSOR_CLIENT_LOGGING_GET_DATA_FROM_PROPERTY_FAIL_CFG_VAL, property); } return sc; @@ -331,7 +331,7 @@ static void handle_sensor_client_status(sl_btmesh_evt_sensor_client_status_t *ev } default: - log(SENSOR_CLIENT_LOGGING_UNSUPPORTED_PROPERTY, property_id); + log(SL_BTMESH_SENSOR_CLIENT_LOGGING_UNSUPPORTED_PROPERTY_CFG_VAL, property_id); break; } } @@ -413,7 +413,7 @@ static bool mesh_address_already_exists(mesh_registered_device_properties_addres { bool address_exists = false; if (property != NULL) { - for (int i = 0; i < SENSOR_CLIENT_DISPLAYED_SENSORS; i++) { + for (int i = 0; i < SL_BTMESH_SENSOR_CLIENT_DISPLAYED_SENSORS_CFG_VAL; i++) { if (address == property->address_table[i]) { address_exists = true; break; @@ -436,7 +436,7 @@ static uint8_t mesh_get_sensor_index(mesh_registered_device_properties_address_t { uint8_t sensor_index = SENSOR_INDEX_NOT_FOUND; if (property != NULL) { - for (int i = 0; i < SENSOR_CLIENT_DISPLAYED_SENSORS; i++) { + for (int i = 0; i < SL_BTMESH_SENSOR_CLIENT_DISPLAYED_SENSORS_CFG_VAL; i++) { if (address == property->address_table[i]) { sensor_index = i; break; diff --git a/app/bluetooth/common/btmesh_sensor_people_count/config/sl_btmesh_sensor_people_count_config.h b/app/bluetooth/common/btmesh_sensor_people_count/config/sl_btmesh_sensor_people_count_config.h index 86852dac070..5480313f646 100644 --- a/app/bluetooth/common/btmesh_sensor_people_count/config/sl_btmesh_sensor_people_count_config.h +++ b/app/bluetooth/common/btmesh_sensor_people_count/config/sl_btmesh_sensor_people_count_config.h @@ -32,26 +32,26 @@ // <<< Use Configuration Wizard in Context Menu >>> -#define SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_DISCRETE_VALUE 0 -#define SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_PERCENTAGE 1 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_DISCRETE_VALUE_CFG_VAL 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_PERCENTAGE_CFG_VAL 1 // Bluetooth Mesh - People Count // Sensor attributes -// Positive tolerance of sensor. +// Positive tolerance of sensor. // <0-4095:1> // Default: 0 (Unspecified) // 12-bit Positive Tolerance value (1 - 4095) or Unspecified (0). The value is derived as ERR_P [%] = 100 [%] * x / 4095 -#define SENSOR_PEOPLE_COUNT_POSITIVE_TOLERANCE 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_POSITIVE_TOLERANCE_CFG_VAL 0 -// Negative tolerance of sensor. +// Negative tolerance of sensor. // <0-4095:1> // Default: 0 (Unspecified) // 12-bit Negative Tolerance value (1 - 4095) or Unspecified (0). The value is derived as ERR_N [%] = 100 [%] * x / 4095 -#define SENSOR_PEOPLE_COUNT_NEGATIVE_TOLERANCE 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_NEGATIVE_TOLERANCE_CFG_VAL 0 -// Sampling function +// Sampling function // Unspecified // Instantaneous sampling // Arithmetic mean @@ -63,42 +63,42 @@ // Number of "events" over the period of time defined by the Measurement Period // Reserved for Future Use // Default: Unspecified -#define SENSOR_PEOPLE_COUNT_SAMPLING_FUNCTION SAMPLING_UNSPECIFIED +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_SAMPLING_FUNCTION_CFG_VAL SAMPLING_UNSPECIFIED -// Measurement Period of sensor. +// Measurement Period of sensor. // <0-255:1> // Default: 0 (Not Applicable) // 8 bit value (1 - 255) or Not Applicable (0). Time period in seconds is derived as T [s] = 1.1 ^ (x - 64) -#define SENSOR_PEOPLE_COUNT_MEASUREMENT_PERIOD 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_MEASUREMENT_PERIOD_CFG_VAL 0 -// Update Interval of sensor. +// Update Interval of sensor. // <0-255:1> // Default: 0 (Not Applicable) // 8 bit value (1 - 255) or Not Applicable (0). Time period in seconds is derived as T [s] = 1.1 ^ (x - 64) -#define SENSOR_PEOPLE_COUNT_UPDATE_INTERVAL 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_UPDATE_INTERVAL_CFG_VAL 0 // -// Sensor cadence +// Sensor cadence // Enables Cadence. // Default: 0 -#define SENSOR_PEOPLE_COUNT_CADENCE_ENABLE 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_CADENCE_ENABLE_CFG_VAL 0 -// Fast Cadence Period Divisor +// Fast Cadence Period Divisor // <0-15:1> // Default: 0 (Divisor of 1) // 7 bit value (0-15), other values are Prohibited. The value is represented as a 2 ^ n divisor of the Publish Period. // For example value 0x00 would have a divisor of 1, the Publish Period would not change. -#define SENSOR_PEOPLE_COUNT_FAST_CADENCE_PERIOD_DIVISOR 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_FAST_CADENCE_PERIOD_DIVISOR_CFG_VAL 0 -// Status Trigger Type -// Discrete Value -// Percentage -// Default: SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_DISCRETE_VALUE +// Status Trigger Type +// Discrete Value +// Percentage +// Default: SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_DISCRETE_VALUE_CFG_VAL // Defines the unit and format of the Status Trigger Delta fields -#define SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_DISCRETE_VALUE +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_CFG_VAL SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_DISCRETE_VALUE_CFG_VAL -// Status Trigger Delta Down +// Status Trigger Delta Down // <0-65535:1> // Default: 0 // The Status Trigger Delta Down field shall control the negative change of a measured quantity that @@ -106,9 +106,9 @@ // In case of percentage Status Trigger Type the value is represented unitless with a resolution of 0.01 percent, // e.g. value 1534 represents 15.34%. In case of discrete Status Trigger Type the format represents // the people count value. -#define SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_DELTA_DOWN 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_DELTA_DOWN_CFG_VAL 0 -// Status Trigger Delta Up +// Status Trigger Delta Up // <0-65535:1> // Default: 0 // The Status Trigger Delta Up field shall control the positive change of a measured quantity that @@ -116,29 +116,29 @@ // In case of percentage Status Trigger Type the value is represented unitless with a resolution of 0.01 percent, // e.g. value 1534 represents 15.34%. In case of discrete Status Trigger Type the format represents // the people count value. -#define SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_DELTA_UP 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_DELTA_UP_CFG_VAL 0 -// Status Min Interval +// Status Min Interval // <0-26:1> // Default: 0 // 8 bit value (0-26), other values are Prohibited. The value is represented as a 2 ^ n milliseconds. // For example, the value 10 would represent an interval of 1024ms. // The Status Min Interval field shall control the minimum interval between publishing two consecutive Sensor Status messages. -#define SENSOR_PEOPLE_COUNT_STATUS_MIN_INTERVAL 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_MIN_INTERVAL_CFG_VAL 0 -// Fast Cadence Low +// Fast Cadence Low // <0-65535:1> // Default: 0 // The Fast Cadence Low field shall define the lower boundary of a range of measured quantities when // the publishing cadence is increased as defined by the Fast Cadence Period Divisor field. -#define SENSOR_PEOPLE_COUNT_FAST_CADENCE_LOW 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_FAST_CADENCE_LOW_CFG_VAL 0 -// Fast Cadence High +// Fast Cadence High // <0-65535:1> // Default: 0 // The Fast Cadence High field shall define the upper boundary of a range of measured quantities when // the publishing cadence is increased as defined by the Fast Cadence Period Divisor field. -#define SENSOR_PEOPLE_COUNT_FAST_CADENCE_HIGH 0 +#define SL_BTMESH_SENSOR_PEOPLE_COUNT_FAST_CADENCE_HIGH_CFG_VAL 0 // diff --git a/app/bluetooth/common/btmesh_sensor_server/config/sl_btmesh_sensor_server_config.h b/app/bluetooth/common/btmesh_sensor_server/config/sl_btmesh_sensor_server_config.h index 6c198b89760..f0f1d2f882a 100644 --- a/app/bluetooth/common/btmesh_sensor_server/config/sl_btmesh_sensor_server_config.h +++ b/app/bluetooth/common/btmesh_sensor_server/config/sl_btmesh_sensor_server_config.h @@ -34,10 +34,10 @@ // Sensor Server configuration -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable Logging for Sensor Server model specific messages for this component. -#define SENSOR_SERVER_LOGGING (1) +#define SL_BTMESH_SENSOR_SERVER_LOGGING_CFG_VAL (1) // // diff --git a/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server.c b/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server.c index 1e61c4cf2f5..fbe68d8cb05 100644 --- a/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server.c +++ b/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server.c @@ -152,11 +152,11 @@ void sl_btmesh_sensor_server_node_init(void) #ifdef SL_CATALOG_BTMESH_SENSOR_PEOPLE_COUNT_PRESENT { .property_id = PEOPLE_COUNT, - .positive_tolerance = SENSOR_PEOPLE_COUNT_POSITIVE_TOLERANCE, - .negative_tolerance = SENSOR_PEOPLE_COUNT_NEGATIVE_TOLERANCE, - .sampling_function = SENSOR_PEOPLE_COUNT_SAMPLING_FUNCTION, - .measurement_period = SENSOR_PEOPLE_COUNT_MEASUREMENT_PERIOD, - .update_interval = SENSOR_PEOPLE_COUNT_UPDATE_INTERVAL + .positive_tolerance = SL_BTMESH_SENSOR_PEOPLE_COUNT_POSITIVE_TOLERANCE_CFG_VAL, + .negative_tolerance = SL_BTMESH_SENSOR_PEOPLE_COUNT_NEGATIVE_TOLERANCE_CFG_VAL, + .sampling_function = SL_BTMESH_SENSOR_PEOPLE_COUNT_SAMPLING_FUNCTION_CFG_VAL, + .measurement_period = SL_BTMESH_SENSOR_PEOPLE_COUNT_MEASUREMENT_PERIOD_CFG_VAL, + .update_interval = SL_BTMESH_SENSOR_PEOPLE_COUNT_UPDATE_INTERVAL_CFG_VAL }, #endif // SL_CATALOG_BTMESH_SENSOR_PEOPLE_COUNT_PRESENT #if defined(SL_BOARD_ENABLE_SENSOR_LIGHT) \ @@ -222,11 +222,11 @@ void sl_btmesh_sensor_server_node_init(void) uint32_t update_interval; sl_btmesh_sensor_people_count_cadence_init(0); sl_btmesh_sensor_thermometer_cadence_init(get_temperature()); - update_interval = MIN(SENSOR_THERMOMETER_UPDATE_INTERVAL, SENSOR_PEOPLE_COUNT_UPDATE_INTERVAL); + update_interval = MIN(SENSOR_THERMOMETER_UPDATE_INTERVAL, SL_BTMESH_SENSOR_PEOPLE_COUNT_UPDATE_INTERVAL_CFG_VAL); #elif SENSOR_PEOPLE_COUNT_CADENCE uint32_t update_interval; sl_btmesh_sensor_people_count_cadence_init(0); - update_interval = SENSOR_PEOPLE_COUNT_UPDATE_INTERVAL; + update_interval = SL_BTMESH_SENSOR_PEOPLE_COUNT_UPDATE_INTERVAL_CFG_VAL; #elif SENSOR_THERMOMETER_CADENCE uint32_t update_interval; sl_btmesh_sensor_thermometer_cadence_init(get_temperature()); diff --git a/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server_cadence.c b/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server_cadence.c index 35f7e0929bd..be1ff4c9f4f 100644 --- a/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server_cadence.c +++ b/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server_cadence.c @@ -127,16 +127,16 @@ static bool sensor_thermometer_delta_cadence(temperature_8_t current_temperature void sl_btmesh_sensor_people_count_cadence_init(count16_t people_count) { - static uint16_t delta_down = SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_DELTA_DOWN; - static uint16_t delta_up = SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_DELTA_UP; + static uint16_t delta_down = SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_DELTA_DOWN_CFG_VAL; + static uint16_t delta_up = SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_DELTA_UP_CFG_VAL; - static uint16_t cadence_low = SENSOR_PEOPLE_COUNT_FAST_CADENCE_LOW; - static uint16_t cadence_high = SENSOR_PEOPLE_COUNT_FAST_CADENCE_HIGH; + static uint16_t cadence_low = SL_BTMESH_SENSOR_PEOPLE_COUNT_FAST_CADENCE_LOW_CFG_VAL; + static uint16_t cadence_high = SL_BTMESH_SENSOR_PEOPLE_COUNT_FAST_CADENCE_HIGH_CFG_VAL; cadences[SENSOR_PEOPLE_COUNT_INDEX].property_id = PEOPLE_COUNT; - cadences[SENSOR_PEOPLE_COUNT_INDEX].period_divisor = SENSOR_PEOPLE_COUNT_FAST_CADENCE_PERIOD_DIVISOR; - cadences[SENSOR_PEOPLE_COUNT_INDEX].status_trigger_type = SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE; - cadences[SENSOR_PEOPLE_COUNT_INDEX].min_interval = SENSOR_PEOPLE_COUNT_STATUS_MIN_INTERVAL; + cadences[SENSOR_PEOPLE_COUNT_INDEX].period_divisor = SL_BTMESH_SENSOR_PEOPLE_COUNT_FAST_CADENCE_PERIOD_DIVISOR_CFG_VAL; + cadences[SENSOR_PEOPLE_COUNT_INDEX].status_trigger_type = SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_CFG_VAL; + cadences[SENSOR_PEOPLE_COUNT_INDEX].min_interval = SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_MIN_INTERVAL_CFG_VAL; cadences[SENSOR_PEOPLE_COUNT_INDEX].fast_cadence_low.size = sizeof(cadence_low); cadences[SENSOR_PEOPLE_COUNT_INDEX].fast_cadence_low.value = (uint8_t*)(&cadence_low); cadences[SENSOR_PEOPLE_COUNT_INDEX].fast_cadence_high.size = sizeof(cadence_high); @@ -275,7 +275,7 @@ static bool sensor_people_count_delta_cadence(count16_t people_count) // Check the unit and format of the Status Trigger Delta Down and // the Status Trigger Delta Up fields. - if (SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_DISCRETE_VALUE == cadences[SENSOR_PEOPLE_COUNT_INDEX].status_trigger_type) { + if (SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_DISCRETE_VALUE_CFG_VAL == cadences[SENSOR_PEOPLE_COUNT_INDEX].status_trigger_type) { // If the temperature change is rising and the measured quantity change // exceeds the configured Status Trigger Delta Up value, Sensor Status // publishing period modification is required. @@ -291,7 +291,7 @@ static bool sensor_people_count_delta_cadence(count16_t people_count) } else { } // Same check with measured value represented unitless as percentage - } else if ((SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_PERCENTAGE == cadences[SENSOR_PEOPLE_COUNT_INDEX].status_trigger_type) + } else if ((SL_BTMESH_SENSOR_PEOPLE_COUNT_STATUS_TRIGGER_TYPE_PERCENTAGE_CFG_VAL == cadences[SENSOR_PEOPLE_COUNT_INDEX].status_trigger_type) && (prev_people_count_data != people_count)) { if (!prev_people_count_data) { delta_percent = PERCENTAGE_FULL; diff --git a/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server_cadence.h b/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server_cadence.h index a1004d49e59..5bc2b4ef2d0 100644 --- a/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server_cadence.h +++ b/app/bluetooth/common/btmesh_sensor_server/sl_btmesh_sensor_server_cadence.h @@ -57,7 +57,7 @@ #endif #if defined(SL_CATALOG_BTMESH_SENSOR_PEOPLE_COUNT_PRESENT) \ - && SENSOR_PEOPLE_COUNT_CADENCE_ENABLE + && SL_BTMESH_SENSOR_PEOPLE_COUNT_CADENCE_ENABLE_CFG_VAL #define SENSOR_PEOPLE_COUNT_CADENCE 1 #else diff --git a/app/bluetooth/common/btmesh_time_server/config/sl_btmesh_time_server_config.h b/app/bluetooth/common/btmesh_time_server/config/sl_btmesh_time_server_config.h index efed3a95b42..655f39bf4d8 100644 --- a/app/bluetooth/common/btmesh_time_server/config/sl_btmesh_time_server_config.h +++ b/app/bluetooth/common/btmesh_time_server/config/sl_btmesh_time_server_config.h @@ -34,10 +34,10 @@ // Time Server configuration -// Enable Logging +// Enable Logging // Default: 1 // Enable / disable Logging for Time Server model specific messages for this component. -#define TIME_SERVER_LOGGING (1) +#define SL_BTMESH_TIME_SERVER_LOGGING_CFG_VAL (1) // diff --git a/app/bluetooth/common/btmesh_wstk_lcd/config/sl_btmesh_wstk_lcd_config.h b/app/bluetooth/common/btmesh_wstk_lcd/config/sl_btmesh_wstk_lcd_config.h index e1954f55702..d82ab19db49 100644 --- a/app/bluetooth/common/btmesh_wstk_lcd/config/sl_btmesh_wstk_lcd_config.h +++ b/app/bluetooth/common/btmesh_wstk_lcd/config/sl_btmesh_wstk_lcd_config.h @@ -34,95 +34,95 @@ // LCD rows configuration -// Row for Device Name +// Row for Device Name // Default: 1 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the Device Name will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_NAME (1) +#define SL_BTMESH_WSTK_LCD_ROW_NAME_CFG_VAL (1) -// Row for Node Status +// Row for Node Status // Default: 2 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the Node Status will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_STATUS (2) +#define SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL (2) -// Row for Connection Status +// Row for Connection Status // Default: 3 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the Connection Status will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_CONNECTION (3) +#define SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL (3) -// Row for Friend status in a Friendship +// Row for Friend status in a Friendship // Default: 4 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the Friend status in a Friendship will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_FRIEND (4) +#define SL_BTMESH_WSTK_LCD_ROW_FRIEND_CFG_VAL (4) -// Row for LPN status in a Friendship +// Row for LPN status in a Friendship // Default: 4 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the LPN status in a Friendship will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_LPN (4) +#define SL_BTMESH_WSTK_LCD_ROW_LPN_CFG_VAL (4) -// Row for Lightness +// Row for Lightness // Default: 5 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the Lightness will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_LIGHTNESS (5) +#define SL_BTMESH_WSTK_LCD_ROW_LIGHTNESS_CFG_VAL (5) -// Row for Sensor Data +// Row for Sensor Data // Default: 5 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the First row of Sensor Data read by the client will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_SENSOR_DATA (5) +#define SL_BTMESH_WSTK_LCD_ROW_SENSOR_DATA_CFG_VAL (5) -// Row for People Count +// Row for People Count // Default: 5 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the People Count will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_PEOPLE_COUNT (5) +#define SL_BTMESH_WSTK_LCD_ROW_PEOPLE_COUNT_CFG_VAL (5) -// Row for Color Temperature / Sensor Temperature +// Row for Color Temperature / Sensor Temperature // Default: 6 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the Color Temperature / Sensor Temperature will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_TEMPERATURE (6) +#define SL_BTMESH_WSTK_LCD_ROW_TEMPERATURE_CFG_VAL (6) -// Row for Hue +// Row for Hue // Default: 6 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the Hue will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_HUE (6) +#define SL_BTMESH_WSTK_LCD_ROW_HUE_CFG_VAL (6) -// Row for Delta UV +// Row for Delta UV // Default: 7 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the Delta UV will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_DELTAUV (7) +#define SL_BTMESH_WSTK_LCD_ROW_DELTAUV_CFG_VAL (7) -// Row for Saturation +// Row for Saturation // Default: 7 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the Saturation will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_SATURATION (7) +#define SL_BTMESH_WSTK_LCD_ROW_SATURATION_CFG_VAL (7) -// Row for Illuminance +// Row for Illuminance // Default: 7 // <1-9:1> // LCD on WSTKs have 9 rows. Out of these the Illuminance will be printed in the row specified here. -#define BTMESH_WSTK_LCD_ROW_ILLUMINANCE (7) +#define SL_BTMESH_WSTK_LCD_ROW_ILLUMINANCE_CFG_VAL (7) // // LCD texts -// Text for initializting graphics. +// Text for initializting graphics. // Text for initializting graphics -#define BTMESH_WSTK_LCD_GRAPH_INIT_TEXT "SILICON LABORATORIES\nBluetooth Mesh Demo\n\n" +#define SL_BTMESH_WSTK_LCD_GRAPH_INIT_TEXT_CFG_VAL "SILICON LABORATORIES\nBluetooth Mesh Demo\n\n" -// Text to be printed on the LCD when it is initialized. +// Text to be printed on the LCD when it is initialized. // Text to be printed on the LCD when it is initialized -#define BTMESH_WSTK_LCD_INIT_TEXT "initializing" +#define SL_BTMESH_WSTK_LCD_INIT_TEXT_CFG_VAL "initializing" // diff --git a/app/bluetooth/common/btmesh_wstk_lcd/sl_btmesh_wstk_lcd.c b/app/bluetooth/common/btmesh_wstk_lcd/sl_btmesh_wstk_lcd.c index 6d864022a53..0f0f1ead825 100644 --- a/app/bluetooth/common/btmesh_wstk_lcd/sl_btmesh_wstk_lcd.c +++ b/app/bluetooth/common/btmesh_wstk_lcd/sl_btmesh_wstk_lcd.c @@ -72,9 +72,9 @@ sl_status_t sl_btmesh_LCD_init(void) { memset(&LCD_data, 0, sizeof(LCD_data)); - graphInit(BTMESH_WSTK_LCD_GRAPH_INIT_TEXT); + graphInit(SL_BTMESH_WSTK_LCD_GRAPH_INIT_TEXT_CFG_VAL); - return sl_btmesh_LCD_write(BTMESH_WSTK_LCD_INIT_TEXT, BTMESH_WSTK_LCD_ROW_STATUS); + return sl_btmesh_LCD_write(SL_BTMESH_WSTK_LCD_INIT_TEXT_CFG_VAL, SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); } /******************************************************************************* diff --git a/app/bluetooth/common/gatt_service_aio/sl_gatt_service_aio.c b/app/bluetooth/common/gatt_service_aio/sl_gatt_service_aio.c index d3687410666..62ed5f2a2b0 100644 --- a/app/bluetooth/common/gatt_service_aio/sl_gatt_service_aio.c +++ b/app/bluetooth/common/gatt_service_aio/sl_gatt_service_aio.c @@ -3,7 +3,7 @@ * @brief Automation IO GATT service ******************************************************************************* * # License - * Copyright 2020 Silicon Laboratories Inc. www.silabs.com + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com ******************************************************************************* * * SPDX-License-Identifier: Zlib @@ -32,30 +32,9 @@ #include "sl_status.h" #include "gatt_db.h" #include "app_assert.h" -#include "app_log.h" -#include "sl_simple_button_instances.h" -#include "sl_simple_led_instances.h" +#include "sli_gatt_service_aio.h" #include "sl_gatt_service_aio.h" -// ----------------------------------------------------------------------------- -// Private macros - -// AIO digital states defined by the BLE standard -#define AIO_DIGITAL_STATE_INACTIVE 0 -#define AIO_DIGITAL_STATE_ACTIVE 1 -#define AIO_DIGITAL_STATE_TRISTATE 2 -#define AIO_DIGITAL_STATE_UNKNOWN 3 - -#define AIO_DIGITAL_STATE_MASK 3 -#define AIO_DIGITAL_STATE_SIZE 2 -// AIO digital state is represented on 1 byte, thus 4 digitals are supported -#define AIO_DIGITAL_COUNT_MAX 4 - -#if (SL_SIMPLE_BUTTON_COUNT > AIO_DIGITAL_COUNT_MAX) \ - || (SL_SIMPLE_LED_COUNT > AIO_DIGITAL_COUNT_MAX) -#error Maximal AIO count exceeded. -#endif - // ----------------------------------------------------------------------------- // Private variables @@ -66,10 +45,6 @@ static uint8_t aio_connection = 0; // ----------------------------------------------------------------------------- // Private function declarations -static uint8_t aio_digital_in_get_state(void); -static uint8_t aio_digital_out_get_state(void); -static void aio_digital_out_set_state(uint8_t state); - static void aio_digital_in_notify(void); static void aio_system_boot_cb(void); static void aio_connection_opened_cb(sl_bt_evt_connection_opened_t *data); @@ -82,54 +57,29 @@ static void aio_digital_out_write_cb(sl_bt_evt_gatt_server_user_write_request_t // ----------------------------------------------------------------------------- // Private function definitions -static uint8_t aio_digital_in_get_state(void) +SL_WEAK uint8_t aio_digital_in_get_num(void) { - uint8_t aio_state = 0; - sl_button_state_t btn_state; - uint8_t i; - - // read button states - for (i = 0; i < SL_SIMPLE_BUTTON_COUNT; i++) { - btn_state = sl_button_get_state(SL_SIMPLE_BUTTON_INSTANCE(i)); - if (btn_state == SL_SIMPLE_BUTTON_PRESSED) { - aio_state |= AIO_DIGITAL_STATE_ACTIVE << (i * AIO_DIGITAL_STATE_SIZE); - } - app_log_info("AIO in: %d=%d", i, btn_state); - app_log_nl(); - } + return 0; +} - return aio_state; +SL_WEAK uint8_t aio_digital_in_get_state(void) +{ + return 0; } -static uint8_t aio_digital_out_get_state(void) +SL_WEAK uint8_t aio_digital_out_get_num(void) { - uint8_t aio_state = 0; - sl_led_state_t led_state; - uint8_t i; + return 0; +} - // read led states - for (i = 0; i < SL_SIMPLE_LED_COUNT; i++) { - led_state = sl_led_get_state(SL_SIMPLE_LED_INSTANCE(i)); - if (led_state == SL_LED_CURRENT_STATE_ON) { - aio_state |= AIO_DIGITAL_STATE_ACTIVE << (i * AIO_DIGITAL_STATE_SIZE); - } - } - return aio_state; +SL_WEAK uint8_t aio_digital_out_get_state(void) +{ + return 0; } -static void aio_digital_out_set_state(uint8_t state) +SL_WEAK void aio_digital_out_set_state(uint8_t state) { - uint8_t led_state, i; - for (i = 0; i < SL_SIMPLE_LED_COUNT; i++) { - led_state = (state >> (i * AIO_DIGITAL_STATE_SIZE)) & AIO_DIGITAL_STATE_MASK; - if (led_state == AIO_DIGITAL_STATE_ACTIVE) { - sl_led_turn_on(SL_SIMPLE_LED_INSTANCE(i)); - } else { - sl_led_turn_off(SL_SIMPLE_LED_INSTANCE(i)); - } - app_log_info("AIO out: %d=%d", i, led_state); - app_log_nl(); - } + (void)state; } static void aio_digital_in_notify(void) @@ -147,11 +97,12 @@ static void aio_digital_in_notify(void) static void aio_system_boot_cb(void) { sl_status_t sc; - uint8_t value_in = SL_SIMPLE_BUTTON_COUNT; - uint8_t value_out = SL_SIMPLE_LED_COUNT; - sc = sl_bt_gatt_server_write_attribute_value(gattdb_aio_num_of_digitals_in, 0, 1, &value_in); + uint8_t in_cnt = aio_digital_in_get_num(); + uint8_t out_cnt = aio_digital_out_get_num(); + + sc = sl_bt_gatt_server_write_attribute_value(gattdb_aio_num_of_digitals_in, 0, 1, &in_cnt); app_assert_status(sc); - sc = sl_bt_gatt_server_write_attribute_value(gattdb_aio_num_of_digitals_out, 0, 1, &value_out); + sc = sl_bt_gatt_server_write_attribute_value(gattdb_aio_num_of_digitals_out, 0, 1, &out_cnt); app_assert_status(sc); } diff --git a/app/bluetooth/common/gatt_service_aio/sl_gatt_service_aio_digital_in.c b/app/bluetooth/common/gatt_service_aio/sl_gatt_service_aio_digital_in.c new file mode 100644 index 00000000000..872f873f231 --- /dev/null +++ b/app/bluetooth/common/gatt_service_aio/sl_gatt_service_aio_digital_in.c @@ -0,0 +1,58 @@ +/***************************************************************************//** + * @file + * @brief Automation IO GATT service Digital-In strong implementations + ******************************************************************************* + * # License + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com + ******************************************************************************* + * + * SPDX-License-Identifier: Zlib + * + * The licensor of this software is Silicon Laboratories Inc. + * + * This software is provided 'as-is', without any express or implied + * warranty. In no event will the authors be held liable for any damages + * arising from the use of this software. + * + * Permission is granted to anyone to use this software for any purpose, + * including commercial applications, and to alter it and redistribute it + * freely, subject to the following restrictions: + * + * 1. The origin of this software must not be misrepresented; you must not + * claim that you wrote the original software. If you use this software + * in a product, an acknowledgment in the product documentation would be + * appreciated but is not required. + * 2. Altered source versions must be plainly marked as such, and must not be + * misrepresented as being the original software. + * 3. This notice may not be removed or altered from any source distribution. + * + ******************************************************************************/ + +#include "app_log.h" +#include "sl_simple_button_instances.h" +#include "sli_gatt_service_aio.h" + +#if (SL_SIMPLE_BUTTON_COUNT > AIO_DIGITAL_COUNT_MAX) +#error Maximal input count exceeded. +#endif + +uint8_t aio_digital_in_get_num(void) +{ + return SL_SIMPLE_BUTTON_COUNT; +} + +uint8_t aio_digital_in_get_state(void) +{ + // Read button states + uint8_t aio_state = 0; + sl_button_state_t btn_state; + + for (uint8_t i = 0; i < SL_SIMPLE_BUTTON_COUNT; i++) { + btn_state = sl_button_get_state(SL_SIMPLE_BUTTON_INSTANCE(i)); + if (btn_state == SL_SIMPLE_BUTTON_PRESSED) { + aio_state |= AIO_DIGITAL_STATE_ACTIVE << (i * AIO_DIGITAL_STATE_SIZE); + } + app_log_info("AIO in: %d=%d" APP_LOG_NL, i, btn_state); + } + return aio_state; +} diff --git a/app/bluetooth/common/gatt_service_aio/sl_gatt_service_aio_digital_out.c b/app/bluetooth/common/gatt_service_aio/sl_gatt_service_aio_digital_out.c new file mode 100644 index 00000000000..4c572f44118 --- /dev/null +++ b/app/bluetooth/common/gatt_service_aio/sl_gatt_service_aio_digital_out.c @@ -0,0 +1,71 @@ +/***************************************************************************//** + * @file + * @brief Automation IO GATT service Digital-Out strong implementations + ******************************************************************************* + * # License + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com + ******************************************************************************* + * + * SPDX-License-Identifier: Zlib + * + * The licensor of this software is Silicon Laboratories Inc. + * + * This software is provided 'as-is', without any express or implied + * warranty. In no event will the authors be held liable for any damages + * arising from the use of this software. + * + * Permission is granted to anyone to use this software for any purpose, + * including commercial applications, and to alter it and redistribute it + * freely, subject to the following restrictions: + * + * 1. The origin of this software must not be misrepresented; you must not + * claim that you wrote the original software. If you use this software + * in a product, an acknowledgment in the product documentation would be + * appreciated but is not required. + * 2. Altered source versions must be plainly marked as such, and must not be + * misrepresented as being the original software. + * 3. This notice may not be removed or altered from any source distribution. + * + ******************************************************************************/ + +#include "app_log.h" +#include "sl_simple_led_instances.h" +#include "sli_gatt_service_aio.h" + +#if (SL_SIMPLE_LED_COUNT > AIO_DIGITAL_COUNT_MAX) +#error Maximal output count exceeded. +#endif + +uint8_t aio_digital_out_get_num(void) +{ + return SL_SIMPLE_LED_COUNT; +} + +uint8_t aio_digital_out_get_state(void) +{ + // Read LED states + uint8_t aio_state = 0; + sl_led_state_t led_state; + + for (uint8_t i = 0; i < SL_SIMPLE_LED_COUNT; i++) { + led_state = sl_led_get_state(SL_SIMPLE_LED_INSTANCE(i)); + if (led_state == SL_LED_CURRENT_STATE_ON) { + aio_state |= AIO_DIGITAL_STATE_ACTIVE << (i * AIO_DIGITAL_STATE_SIZE); + } + } + return aio_state; +} + +void aio_digital_out_set_state(uint8_t state) +{ + uint8_t led_state; + for (uint8_t i = 0; i < SL_SIMPLE_LED_COUNT; i++) { + led_state = (state >> (i * AIO_DIGITAL_STATE_SIZE)) & AIO_DIGITAL_STATE_MASK; + if (led_state == AIO_DIGITAL_STATE_ACTIVE) { + sl_led_turn_on(SL_SIMPLE_LED_INSTANCE(i)); + } else { + sl_led_turn_off(SL_SIMPLE_LED_INSTANCE(i)); + } + app_log_info("AIO out: %d=%d" APP_LOG_NL, i, led_state); + } +} diff --git a/app/bluetooth/common/gatt_service_aio/sli_gatt_service_aio.h b/app/bluetooth/common/gatt_service_aio/sli_gatt_service_aio.h new file mode 100644 index 00000000000..05fdfa57edb --- /dev/null +++ b/app/bluetooth/common/gatt_service_aio/sli_gatt_service_aio.h @@ -0,0 +1,52 @@ +/***************************************************************************//** + * @file + * @brief Automation IO GATT service internal header + ******************************************************************************* + * # License + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com + ******************************************************************************* + * + * SPDX-License-Identifier: Zlib + * + * The licensor of this software is Silicon Laboratories Inc. + * + * This software is provided 'as-is', without any express or implied + * warranty. In no event will the authors be held liable for any damages + * arising from the use of this software. + * + * Permission is granted to anyone to use this software for any purpose, + * including commercial applications, and to alter it and redistribute it + * freely, subject to the following restrictions: + * + * 1. The origin of this software must not be misrepresented; you must not + * claim that you wrote the original software. If you use this software + * in a product, an acknowledgment in the product documentation would be + * appreciated but is not required. + * 2. Altered source versions must be plainly marked as such, and must not be + * misrepresented as being the original software. + * 3. This notice may not be removed or altered from any source distribution. + * + ******************************************************************************/ + +#ifndef SLI_GATT_SERVICE_AIO_H +#define SLI_GATT_SERVICE_AIO_H + +// AIO digital states defined by the BLE standard +#define AIO_DIGITAL_STATE_INACTIVE 0 +#define AIO_DIGITAL_STATE_ACTIVE 1 +#define AIO_DIGITAL_STATE_TRISTATE 2 +#define AIO_DIGITAL_STATE_UNKNOWN 3 + +#define AIO_DIGITAL_STATE_MASK 3 +#define AIO_DIGITAL_STATE_SIZE 2 + +// AIO digital state is represented on 1 byte, thus 4 digitals are supported +#define AIO_DIGITAL_COUNT_MAX 4 + +uint8_t aio_digital_in_get_num(void); +uint8_t aio_digital_in_get_state(void); +uint8_t aio_digital_out_get_num(void); +uint8_t aio_digital_out_get_state(void); +void aio_digital_out_set_state(uint8_t state); + +#endif // SLI_GATT_SERVICE_AIO_H diff --git a/app/bluetooth/common/gatt_service_rgb/gatt_service_rgb.xml b/app/bluetooth/common/gatt_service_rgb/gatt_service_rgb.xml index 07be6ff9c84..ed44145dafc 100644 --- a/app/bluetooth/common/gatt_service_rgb/gatt_service_rgb.xml +++ b/app/bluetooth/common/gatt_service_rgb/gatt_service_rgb.xml @@ -8,6 +8,13 @@ + + + + + 00 + + diff --git a/app/bluetooth/common/gatt_service_rgb/sl_gatt_service_rgb.c b/app/bluetooth/common/gatt_service_rgb/sl_gatt_service_rgb.c index caf239ccf7a..788b01a02ff 100644 --- a/app/bluetooth/common/gatt_service_rgb/sl_gatt_service_rgb.c +++ b/app/bluetooth/common/gatt_service_rgb/sl_gatt_service_rgb.c @@ -48,6 +48,7 @@ static struct { // ----------------------------------------------------------------------------- // Private function declarations +static void rgb_system_boot_cb(sl_bt_evt_system_boot_t *data); static void rgb_connection_opened_cb(sl_bt_evt_connection_opened_t *data); static void rgb_connection_closed_cb(sl_bt_evt_connection_closed_t *data); static void rgb_read_cb(sl_bt_evt_gatt_server_user_read_request_t *data); @@ -56,6 +57,20 @@ static void rgb_write_cb(sl_bt_evt_gatt_server_user_write_request_t *data); // ----------------------------------------------------------------------------- // Private function definitions +static void rgb_system_boot_cb(sl_bt_evt_system_boot_t *data) +{ + (void)data; + sl_status_t sc; + uint8_t mask; + + mask = sl_gatt_service_rgb_get_led_mask(); + sc = sl_bt_gatt_server_write_attribute_value(gattdb_ui_rgbled_mask, + 0, + sizeof(mask), + &mask); + app_log_status_error(sc); +} + static void rgb_connection_opened_cb(sl_bt_evt_connection_opened_t *data) { (void)data; @@ -105,6 +120,10 @@ void sl_gatt_service_rgb_on_event(sl_bt_msg_t *evt) { // Handle stack events switch (SL_BT_MSG_ID(evt->header)) { + case sl_bt_evt_system_boot_id: + rgb_system_boot_cb(&evt->data.evt_system_boot); + break; + case sl_bt_evt_connection_opened_id: rgb_connection_opened_cb(&evt->data.evt_connection_opened); break; @@ -131,3 +150,8 @@ SL_WEAK void sl_gatt_service_rgb_set_led(uint8_t m, uint8_t r, uint8_t g, uint8_ { app_log_debug("RGB set: %d %d %d %d\n", m, r, g, b); } + +SL_WEAK uint8_t sl_gatt_service_rgb_get_led_mask(void) +{ + return 0; +} diff --git a/app/bluetooth/common/gatt_service_rgb/sl_gatt_service_rgb.h b/app/bluetooth/common/gatt_service_rgb/sl_gatt_service_rgb.h index 5e8e7554c90..7e0d43e4d45 100644 --- a/app/bluetooth/common/gatt_service_rgb/sl_gatt_service_rgb.h +++ b/app/bluetooth/common/gatt_service_rgb/sl_gatt_service_rgb.h @@ -40,7 +40,7 @@ void sl_gatt_service_rgb_on_event(sl_bt_msg_t* evt); /**************************************************************************//** - * Setter for RGB Leds characteristic value. + * Setter for RGB LEDs characteristic value. * @param[in] m LED bitmask. * @param[in] r Red intensity. * @param[in] g Green intensity. @@ -49,4 +49,11 @@ void sl_gatt_service_rgb_on_event(sl_bt_msg_t* evt); *****************************************************************************/ void sl_gatt_service_rgb_set_led(uint8_t m, uint8_t r, uint8_t g, uint8_t b); +/**************************************************************************//** + * Returns a bitmask corresponding to the RGB LEDs the board has. + * @return RGB LED mask. + * @note To be implemented in user code. + *****************************************************************************/ +uint8_t sl_gatt_service_rgb_get_led_mask(void); + #endif // SL_GATT_SERVICE_RGB_H diff --git a/app/bluetooth/common/sensor_pressure/sl_sensor_pressure.c b/app/bluetooth/common/sensor_pressure/sl_sensor_pressure.c index 7bc1b4b2a2a..45af2183546 100644 --- a/app/bluetooth/common/sensor_pressure/sl_sensor_pressure.c +++ b/app/bluetooth/common/sensor_pressure/sl_sensor_pressure.c @@ -1,9 +1,9 @@ /***************************************************************************//** * @file - * @brief Air pressure sensor + * @brief Air Pressure Sensor ******************************************************************************* * # License - * Copyright 2020 Silicon Laboratories Inc. www.silabs.com + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com ******************************************************************************* * * SPDX-License-Identifier: Zlib @@ -30,7 +30,7 @@ #include #include "sl_board_control.h" -#include "sl_bmp280.h" +#include "sl_pressure.h" #include "sl_sensor_select.h" #include "app_assert.h" #include "sl_sensor_pressure.h" @@ -46,19 +46,19 @@ void sl_sensor_pressure_init(void) app_assert((SL_STATUS_OK == sc) && (NULL != pressure_sensor), "[E: %#04x] Pressure sensor not available\n", sc); - sc = sl_bmp280_init(pressure_sensor); + sc = sl_pressure_init(pressure_sensor); app_assert_status(sc); } -void sl_pressure_deinit(void) +void sl_sensor_pressure_deinit(void) { (void)sl_board_disable_sensor(SL_BOARD_SENSOR_PRESSURE); } -sl_status_t sl_pressure_get(float *pressure) +sl_status_t sl_sensor_pressure_get(float *pressure) { sl_status_t sc; sl_i2cspm_t *pressure_sensor = sl_sensor_select(SL_BOARD_SENSOR_PRESSURE); - sc = sl_bmp280_measure_pressure(pressure_sensor, pressure); + sc = sl_pressure_measure_temperature(pressure_sensor, pressure); return sc; } diff --git a/app/bluetooth/common/sensor_pressure/sl_sensor_pressure.h b/app/bluetooth/common/sensor_pressure/sl_sensor_pressure.h index 3aa7151e7f2..a24f28c9b43 100644 --- a/app/bluetooth/common/sensor_pressure/sl_sensor_pressure.h +++ b/app/bluetooth/common/sensor_pressure/sl_sensor_pressure.h @@ -3,7 +3,7 @@ * @brief Air pressure sensor header ******************************************************************************* * # License - * Copyright 2020 Silicon Laboratories Inc. www.silabs.com + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com ******************************************************************************* * * SPDX-License-Identifier: Zlib @@ -49,13 +49,13 @@ void sl_sensor_pressure_init(void); * function disables other sensors, because they're on the same enable pin. * Please use with caution. *****************************************************************************/ -void sl_pressure_deinit(void); +void sl_sensor_pressure_deinit(void); /**************************************************************************//** * Getter for pressure sensor measurement data. * @param[out] pressure Barometric pressure (in millibars). * @return Status of the operation. *****************************************************************************/ -sl_status_t sl_pressure_get(float *pressure); +sl_status_t sl_sensor_pressure_get(float *pressure); #endif // SL_SENSOR_PRESSURE_H diff --git a/app/bluetooth/common/simple_timer/sl_simple_timer.c b/app/bluetooth/common/simple_timer/sl_simple_timer.c index ad3020c2f94..b27af8429ee 100644 --- a/app/bluetooth/common/simple_timer/sl_simple_timer.c +++ b/app/bluetooth/common/simple_timer/sl_simple_timer.c @@ -38,6 +38,11 @@ #include "sl_simple_timer.h" #include "em_core.h" +// ----------------------------------------------------------------------------- +// Definitions + +#define LONG_TIMER_CHECK(timer) (0 != timer->overflow_max) + // ----------------------------------------------------------------------------- // Private variables @@ -91,6 +96,9 @@ sl_status_t sl_simple_timer_start(sl_simple_timer_t *timer, bool is_periodic) { sl_status_t sc; + uint32_t timeout_initial_tick; + uint32_t timer_freq; + uint64_t required_tick; // Check input parameters. if ((timeout_ms == 0) && is_periodic) { @@ -102,31 +110,56 @@ sl_status_t sl_simple_timer_start(sl_simple_timer_t *timer, if (SL_STATUS_OK != sc) { return sc; } + timer->triggered = false; + timer->overflow_counter = 0; + timer->overflow_max = 0; + + // Check if the timer has to be a long one + if (timeout_ms > sl_sleeptimer_get_max_ms32_conversion()) { + // Calculate the required ticks + timer_freq = sl_sleeptimer_get_timer_frequency(); + required_tick = ((uint64_t)timeout_ms * (uint64_t)timer_freq + 999) + / 1000; + + // Calculate the initial time in ticks for the first run and the number of + // maximum-time runs + timeout_initial_tick = (uint32_t)(required_tick % UINT32_MAX); + timer->overflow_max = (uint16_t)(required_tick / UINT32_MAX); - // Start sleeptimer. - if (is_periodic) { - sc = sl_sleeptimer_start_periodic_timer_ms( - &timer->sleeptimer_handle, - timeout_ms, - simple_timer_callback, - (void*)timer, - 0, - 0); + // Start the timer with the initial time + sc = sl_sleeptimer_start_periodic_timer(&timer->sleeptimer_handle, + timeout_initial_tick, + simple_timer_callback, + (void*)timer, + 0, + 0); } else { - sc = sl_sleeptimer_start_timer_ms( - &timer->sleeptimer_handle, - timeout_ms, - simple_timer_callback, - (void*)timer, - 0, - 0); + // Start sleeptimer with the given timeout/period. + if (is_periodic) { + sc = sl_sleeptimer_start_periodic_timer_ms( + &timer->sleeptimer_handle, + timeout_ms, + simple_timer_callback, + (void*)timer, + 0, + 0); + } else { + sc = sl_sleeptimer_start_timer_ms( + &timer->sleeptimer_handle, + timeout_ms, + simple_timer_callback, + (void*)timer, + 0, + 0); + } } if (SL_STATUS_OK == sc) { timer->callback = callback; timer->callback_data = callback_data; timer->periodic = is_periodic; + timer->timeout_ms = timeout_ms; append_simple_timer(timer); } return sc; @@ -208,9 +241,37 @@ static void simple_timer_callback(sl_sleeptimer_timer_handle_t *handle, void *data) { (void)handle; - if (((sl_simple_timer_t*)data)->triggered == false) { - ((sl_simple_timer_t*)data)->triggered = true; - ++trigger_count; + sl_simple_timer_t *timer = (sl_simple_timer_t*)data; + if (timer->triggered == false) { + if (timer->overflow_counter < timer->overflow_max) { + // Timer has to run + if (timer->overflow_counter == 0) { + // For the first round, restart periodic timer with maximum value + sl_sleeptimer_restart_periodic_timer(&timer->sleeptimer_handle, + UINT32_MAX, + simple_timer_callback, + (void*)timer, + 0, + 0); + } + timer->overflow_counter++; + } else { + if (LONG_TIMER_CHECK(timer)) { + if (timer->periodic) { + // Restart long timer + sl_simple_timer_start(timer, + timer->timeout_ms, + timer->callback, + timer->callback_data, + true); + } else { + // Stop periodic timer + sl_sleeptimer_stop_timer(&timer->sleeptimer_handle); + } + } + timer->triggered = true; + ++trigger_count; + } } } diff --git a/app/bluetooth/common/simple_timer/sl_simple_timer.h b/app/bluetooth/common/simple_timer/sl_simple_timer.h index 86095c5ed23..b21a3b53960 100644 --- a/app/bluetooth/common/simple_timer/sl_simple_timer.h +++ b/app/bluetooth/common/simple_timer/sl_simple_timer.h @@ -38,6 +38,8 @@ #ifndef SL_SIMPLE_TIMER_H #define SL_SIMPLE_TIMER_H +#include +#include #include "sl_sleeptimer.h" #include "sl_power_manager.h" @@ -61,6 +63,9 @@ struct sl_simple_timer { sl_simple_timer_t *next; bool triggered; bool periodic; + uint32_t timeout_ms; + uint16_t overflow_counter; + uint16_t overflow_max; }; /***************************************************************************//** diff --git a/app/bluetooth/common/simple_timer_freertos/simple_timer_freertos_validation.lua b/app/bluetooth/common/simple_timer_freertos/simple_timer_freertos_validation.lua index b81a18cd4da..0dbd0d1d310 100644 --- a/app/bluetooth/common/simple_timer_freertos/simple_timer_freertos_validation.lua +++ b/app/bluetooth/common/simple_timer_freertos/simple_timer_freertos_validation.lua @@ -1,36 +1,5 @@ --- automatic conversion of input parameters -function autonumber(input) - local base = 10 - local orig_input = input - if (type(input) == "string") then - input = input:gsub("[\(\)\"uUlL]", "") - if string.find(input,"[bxhBXH]") ~= nil then - if string.find(string.lower(input), "0b") == 1 then - input = input:gsub("[bB]","") - base = 2 - elseif string.find(string.lower(input), "0x") == 1 then - input = input:gsub("[xXhH]","") - base = 16 - end - elseif string.find(input, "0") == 1 then - base = 8 - end - elseif (type(input) == "number") then - return input - else - logit("autonumber() expects either a string or a number!") - return nil - end - local result = tonumber(input, base) - if result == nil then - logit("Configured value is not valid: \"" .. tostring(orig_input) .. "\" - modify it to a numeric value!") - end - return result - end - - -- simple_timer_freertos validation for configUSE_TIMERS -local cfg_value = autonumber(slc.config("configUSE_TIMERS").value) +local cfg_value = autonumber_common.autonumber(slc.config("configUSE_TIMERS").value) if cfg_value ~= nil and cfg_value == 0 then validation.error("Kernel configUSE_TIMERS config needs to be enabled", validation.target_for_defines({"configUSE_TIMERS"}), diff --git a/app/bluetooth/common/simple_timer_freertos_static/simple_timer_freertos_static_validation.lua b/app/bluetooth/common/simple_timer_freertos_static/simple_timer_freertos_static_validation.lua index 20d1acca1a4..50e5f37303c 100644 --- a/app/bluetooth/common/simple_timer_freertos_static/simple_timer_freertos_static_validation.lua +++ b/app/bluetooth/common/simple_timer_freertos_static/simple_timer_freertos_static_validation.lua @@ -1,36 +1,6 @@ --- automatic conversion of input parameters -function autonumber(input) - local base = 10 - local orig_input = input - if (type(input) == "string") then - input = input:gsub("[\(\)\"uUlL]", "") - if string.find(input,"[bxhBXH]") ~= nil then - if string.find(string.lower(input), "0b") == 1 then - input = input:gsub("[bB]","") - base = 2 - elseif string.find(string.lower(input), "0x") == 1 then - input = input:gsub("[xXhH]","") - base = 16 - end - elseif string.find(input, "0") == 1 then - base = 8 - end - elseif (type(input) == "number") then - return input - else - logit("autonumber() expects either a string or a number!") - return nil - end - local result = tonumber(input, base) - if result == nil then - logit("Configured value is not valid: \"" .. tostring(orig_input) .. "\" - modify it to a numeric value!") - end - return result -end - -- simple_timer_freertos_static validation for configUSE_TIMERS and configSUPPORT_STATIC_ALLOCATION -local timer_enable = autonumber(slc.config('configUSE_TIMERS').value) -local enable_static = autonumber(slc.config('configSUPPORT_STATIC_ALLOCATION').value) +local timer_enable = autonumber_common.autonumber(slc.config('configUSE_TIMERS').value) +local enable_static = autonumber_common.autonumber(slc.config('configSUPPORT_STATIC_ALLOCATION').value) if timer_enable ~= nil and timer_enable == 0 then validation.error("Kernel configUSE_TIMERS config needs to be enabled", diff --git a/app/bluetooth/common/throughput_central/throughput_central_validation.lua b/app/bluetooth/common/throughput_central/throughput_central_validation.lua index 67c7eb74dac..51f736a7143 100644 --- a/app/bluetooth/common/throughput_central/throughput_central_validation.lua +++ b/app/bluetooth/common/throughput_central/throughput_central_validation.lua @@ -1,33 +1,3 @@ --- automatic conversion of input parameters -function autonumber(input) - local base = 10 - local orig_input = input - if (type(input) == "string") then - input = input:gsub("[\(\)\"uUlL]", "") - if string.find(input,"[bxhBXH]") ~= nil then - if string.find(string.lower(input), "0b") == 1 then - input = input:gsub("[bB]","") - base = 2 - elseif string.find(string.lower(input), "0x") == 1 then - input = input:gsub("[xXhH]","") - base = 16 - end - elseif string.find(input, "0") == 1 then - base = 8 - end - elseif (type(input) == "number") then - return input - else - logit("autonumber() expects either a string or a number!") - return nil - end - local result = tonumber(input, base) - if result == nil then - logit("Configured value is not valid: \"" .. tostring(orig_input) .. "\" - modify it to a numeric value!") - end - return result - end - -- throughput central validation script for checking MAC adress formats in allowlist local slots = { { @@ -64,11 +34,11 @@ function check_mac(address) return false end -local wl_enabled = autonumber(slc.config("THROUGHPUT_CENTRAL_ALLOWLIST_ENABLE").value) +local wl_enabled = autonumber_common.autonumber(slc.config("THROUGHPUT_CENTRAL_ALLOWLIST_ENABLE").value) if wl_enabled ~= nil and wl_enabled == 1 then for k,v in pairs(slots) do - local slot_enabled = autonumber(slc.config(v.enable).value) + local slot_enabled = autonumber_common.autonumber(slc.config(v.enable).value) if slot_enabled ~= nil and slot_enabled == 1 then local slot = slc.config(v.slot) local slot_formatted = slot.value:gsub("\""," "):gsub("%s","") diff --git a/app/bluetooth/common_host/angle_queue/angle_queue.c b/app/bluetooth/common_host/angle_queue/angle_queue.c new file mode 100644 index 00000000000..7245bbd5ec0 --- /dev/null +++ b/app/bluetooth/common_host/angle_queue/angle_queue.c @@ -0,0 +1,342 @@ +/***************************************************************************//** + * @file + * @brief Angle queue + ******************************************************************************* + * # License + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com + ******************************************************************************* + * + * SPDX-License-Identifier: Zlib + * + * The licensor of this software is Silicon Laboratories Inc. + * + * This software is provided 'as-is', without any express or implied + * warranty. In no event will the authors be held liable for any damages + * arising from the use of this software. + * + * Permission is granted to anyone to use this software for any purpose, + * including commercial applications, and to alter it and redistribute it + * freely, subject to the following restrictions: + * + * 1. The origin of this software must not be misrepresented; you must not + * claim that you wrote the original software. If you use this software + * in a product, an acknowledgment in the product documentation would be + * appreciated but is not required. + * 2. Altered source versions must be plainly marked as such, and must not be + * misrepresented as being the original software. + * 3. This notice may not be removed or altered from any source distribution. + * + ******************************************************************************/ + +#include "angle_queue.h" +#include "aoa_util.h" + +// ----------------------------------------------------------------------------- +// Defines +#define ROUND_DIV(num, den) (((num) + ((den) / 2)) / (den)) + +// ----------------------------------------------------------------------------- +// Type definitions. + +// Forward declarations +typedef struct angle_queue angle_queue_t; +typedef struct angle_data angle_data_t; + +// Angle queue +struct angle_queue{ + aoa_id_t tag_id; + angle_data_t *data; + angle_queue_t *next; +}; + +// Angle data +struct angle_data{ + int32_t sequence; + uint32_t angle_count; + aoa_id_t *locators; + aoa_angle_t *angles; +}; + +// ----------------------------------------------------------------------------- +// Private function declarations. +static sl_status_t new_queue(aoa_id_t tag_id, angle_queue_t **queue); +static sl_status_t get_queue_by_id(aoa_id_t tag_id, angle_queue_t **queue); +static void add_data(aoa_id_t locator_id, + aoa_angle_t *angle, + angle_queue_t *queue); +static uint32_t get_data_index(int32_t sequence, angle_queue_t *queue); +static void check_data(aoa_id_t tag_id, + aoa_id_t locator_id, + angle_queue_t *queue); +static void remove_old_data(int32_t sequence, angle_queue_t *queue); +static void cleanup_data(int32_t index, angle_queue_t *queue); +static uint32_t get_expected_angles(int32_t index); +// ----------------------------------------------------------------------------- +// Module variables. + +// Queue head +static angle_queue_t *head_queue = NULL; + +// Configuration +static angle_queue_config_t angle_queue_config = ANGLE_QUEUE_DEFAULT_CONFIG; + +// Initialization status. +static bool initialized = false; + +// ----------------------------------------------------------------------------- +// Public function definitions. + +/**************************************************************************//** + * Initializes the module. + *****************************************************************************/ +sl_status_t angle_queue_init(angle_queue_config_t *config) +{ + if (initialized) { + return SL_STATUS_ALREADY_INITIALIZED; + } + + angle_queue_config.locator_count = config->locator_count; + angle_queue_config.max_sequence_diff = config->max_sequence_diff; + angle_queue_config.sequence_ids = config->sequence_ids; + angle_queue_config.on_angles_ready = config->on_angles_ready; + + if (2 > angle_queue_config.sequence_ids) { + angle_queue_config.sequence_ids = 2; + } + + // Validate configuration. + if ((0 == angle_queue_config.locator_count) + || (angle_queue_config.sequence_ids > angle_queue_config.max_sequence_diff)) { + return SL_STATUS_INVALID_CONFIGURATION; + } + initialized = true; + + return SL_STATUS_OK; +} + +/**************************************************************************//** + * Pushes a new angle data to the queue. + *****************************************************************************/ +sl_status_t angle_queue_push(aoa_id_t tag_id, + aoa_id_t locator_id, + aoa_angle_t *angle) +{ + angle_queue_t *queue = NULL; + + if (!initialized) { + return SL_STATUS_NOT_INITIALIZED; + } + + if (SL_STATUS_OK != get_queue_by_id(tag_id, &queue)) { + return SL_STATUS_ALLOCATION_FAILED; + } + + remove_old_data(angle->sequence, queue); + add_data(locator_id, angle, queue); + check_data(tag_id, locator_id, queue); + + return SL_STATUS_OK; +} + +/**************************************************************************//** + * Deinitializes the queue. + *****************************************************************************/ +void angle_queue_deinit(void) +{ + angle_queue_t *current = NULL; + angle_queue_t *next = NULL; + + for (current = head_queue; current != NULL; current = next) { + next = current->next; + for (int32_t i = 0; i < angle_queue_config.sequence_ids; i++) { + free(current->data[i].locators); + free(current->data[i].angles); + } + free(current->data); + free(current); + } + head_queue = NULL; + initialized = false; +} + +// ----------------------------------------------------------------------------- +// Private function definitions. + +/**************************************************************************//** + * Creates a new queue + *****************************************************************************/ +static sl_status_t new_queue(aoa_id_t tag_id, + angle_queue_t **queue) +{ + angle_queue_t *new = (angle_queue_t *)malloc(sizeof(angle_queue_t)); + + if (NULL == new) { + return SL_STATUS_ALLOCATION_FAILED; + } + + new->data = (angle_data_t *)malloc(angle_queue_config.sequence_ids + * sizeof(angle_data_t)); + + if (NULL == new->data) { + return SL_STATUS_ALLOCATION_FAILED; + } + + aoa_id_copy(new->tag_id, tag_id); + new->next = head_queue; + head_queue = new; + *queue = new; + + for (int32_t i = 0; i < angle_queue_config.sequence_ids; i++) { + new->data[i].angles = (aoa_angle_t *)malloc(angle_queue_config.locator_count + * sizeof(aoa_angle_t)); + + new->data[i].locators = (aoa_id_t *)malloc(angle_queue_config.locator_count + * sizeof(aoa_id_t)); + + new->data[i].angle_count = 0; + new->data[i].sequence = -1; + + if ((NULL == new->data[i].angles) || (NULL == new->data[i].locators)) { + return SL_STATUS_ALLOCATION_FAILED; + } + } + + return SL_STATUS_OK; +} + +/**************************************************************************//** + * Returns a queue by it's id. + *****************************************************************************/ +static sl_status_t get_queue_by_id(aoa_id_t tag_id, angle_queue_t **queue) +{ + angle_queue_t *current = head_queue; + while (NULL != current) { + if (0 == aoa_id_compare(current->tag_id, tag_id)) { + *queue = current; + return SL_STATUS_OK; + } + current = current->next; + } + + return new_queue(tag_id, queue); +} + +/**************************************************************************//** + * Adds a new angle data to the queue. + *****************************************************************************/ +static void add_data(aoa_id_t locator_id, + aoa_angle_t *angle, + angle_queue_t *queue) +{ + int32_t index = get_data_index(angle->sequence, queue); + + if (queue->data[index].sequence != angle->sequence ) { + for (int32_t i = angle_queue_config.sequence_ids - 1; i > index; i--) { + queue->data[i].sequence = queue->data[i - 1].sequence; + queue->data[i].angle_count = queue->data[i - 1].angle_count; + memcpy(queue->data[i].locators, + queue->data[i - 1].locators, + angle_queue_config.locator_count * sizeof(aoa_id_t)); + memcpy(queue->data[i].angles, + queue->data[i - 1].angles, + angle_queue_config.locator_count * sizeof(aoa_angle_t)); + } + queue->data[index].sequence = angle->sequence; + queue->data[index].angle_count = 0; + } + + aoa_id_copy(queue->data[index].locators[queue->data[index].angle_count], + locator_id); + + memcpy(&queue->data[index].angles[queue->data[index].angle_count], + angle, + sizeof(aoa_angle_t)); + + queue->data[index].angle_count++; +} + +/**************************************************************************//** + * Returns an index which correspondes to a sequence group. + *****************************************************************************/ +static uint32_t get_data_index(int32_t sequence, + angle_queue_t *queue) +{ + for (uint32_t i = 0; i < angle_queue_config.sequence_ids; i++) { + if (queue->data[i].sequence <= sequence) { + return i; + } + } + + return 0; +} + +/**************************************************************************//** + * Checks if the data is ready. + *****************************************************************************/ +static void check_data(aoa_id_t tag_id, + aoa_id_t locator_id, + angle_queue_t *queue) +{ + int32_t cleanup_start = -1; + + // Starting from the oldest sequence id, + // check if we have enough data. + for (int32_t i = angle_queue_config.sequence_ids - 1; i >= 0; i--) { + if (queue->data[i].angle_count >= get_expected_angles(i)) { + if (NULL != angle_queue_config.on_angles_ready) { + angle_queue_config.on_angles_ready(queue->tag_id, + queue->data[i].angle_count, + queue->data[i].angles, + queue->data[i].locators); + } + cleanup_start = i; + } + } + + if (0 <= cleanup_start) { + // Remove already processed and older data + cleanup_data(cleanup_start, queue); + } +} + +/**************************************************************************//** + * Removes old data from the queue. + *****************************************************************************/ +static void remove_old_data(int32_t sequence, angle_queue_t *queue) +{ + for (uint32_t i = 0; i < angle_queue_config.sequence_ids; i++) { + if (aoa_sequence_compare(queue->data[i].sequence, sequence) > angle_queue_config.max_sequence_diff) { + cleanup_data(i, queue); + return; + } + } +} + +/**************************************************************************//** + * Calculates the expected angle number for a given sequence group. + *****************************************************************************/ +static uint32_t get_expected_angles(int32_t index) +{ + uint32_t coeff; + + // The expected number of angles depends on the index. A smaller + // index (i.e. with more recent sequence number) expects more angles, while a + // higher index (i.e. with older sequence number) requires less angles. + // For the newest data we expect an angle from all locators, + // while for the oldest needs only 2 locators. + coeff = (angle_queue_config.locator_count < 2) ? 0 : (angle_queue_config.locator_count - 2); + return (uint32_t)(angle_queue_config.locator_count + - ROUND_DIV(index * coeff, angle_queue_config.sequence_ids - 1)); +} + +/**************************************************************************//** + * Cleanup the data in the queue from a start index. + *****************************************************************************/ +static void cleanup_data(int32_t index, angle_queue_t *queue) +{ + while (index < angle_queue_config.sequence_ids) { + queue->data[index].angle_count = 0; + queue->data[index].sequence = -1; + index++; + } +} diff --git a/app/bluetooth/common_host/angle_queue/angle_queue.h b/app/bluetooth/common_host/angle_queue/angle_queue.h new file mode 100644 index 00000000000..03a1fe74848 --- /dev/null +++ b/app/bluetooth/common_host/angle_queue/angle_queue.h @@ -0,0 +1,98 @@ +/***************************************************************************//** + * @file + * @brief Angle queue + ******************************************************************************* + * # License + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com + ******************************************************************************* + * + * SPDX-License-Identifier: Zlib + * + * The licensor of this software is Silicon Laboratories Inc. + * + * This software is provided 'as-is', without any express or implied + * warranty. In no event will the authors be held liable for any damages + * arising from the use of this software. + * + * Permission is granted to anyone to use this software for any purpose, + * including commercial applications, and to alter it and redistribute it + * freely, subject to the following restrictions: + * + * 1. The origin of this software must not be misrepresented; you must not + * claim that you wrote the original software. If you use this software + * in a product, an acknowledgment in the product documentation would be + * appreciated but is not required. + * 2. Altered source versions must be plainly marked as such, and must not be + * misrepresented as being the original software. + * 3. This notice may not be removed or altered from any source distribution. + * + ******************************************************************************/ +#ifndef ANGLE_QUEUE_H +#define ANGLE_QUEUE_H + +#include +#include +#include +#include "aoa_types.h" +#include "sl_status.h" + +#ifdef __cplusplus +extern "C" { +#endif + +// ----------------------------------------------------------------------------- +// Defines +#define ANGLE_QUEUE_DEFAULT_CONFIG { 0, 6, 20, NULL } + +// ----------------------------------------------------------------------------- +// Type definitions. +typedef void(*angle_queue_callback_t)(aoa_id_t tag_id, // Angles ready for this asset tag. + uint32_t angle_count, // Number of angles and locators. + aoa_angle_t *angle_list, // Angles that belong to the same CTE. + aoa_id_t *locator_list); // Locators that the angles originate from. + +typedef struct { + uint32_t locator_count; // Locator count in the system. + uint32_t sequence_ids; // Sequence id in the system. Set to 2 in case it is configured less than 2. + uint32_t max_sequence_diff; // Maximum difference from the new sequence id. + angle_queue_callback_t on_angles_ready; // Callback function that is called when angles are ready for position calculation. +} angle_queue_config_t; + +// ----------------------------------------------------------------------------- +// Public functions. + +/**************************************************************************//** + * Initializes the module. + * + * @param[in] config Configuration. + * + * @retval SL_STATUS_ALREADY_INITIALIZED - Already initialized. + * @retval SL_STATUS_INVALID_CONFIGURATION - Wrong configuration values. + * @retval SL_STATUS_OK - Initialization successful. + *****************************************************************************/ +sl_status_t angle_queue_init(angle_queue_config_t *config); + +/**************************************************************************//** + * Pushes a new angle data to the queue. + * + * @param[in] tag_id id of the tag. + * @param[in] locator_id id of the locator. + * @param[in] angle angle data to be pushed. + * + * @retval SL_STATUS_FAIL - Error. + * @retval SL_STATUS_OK - Push is successful. + *****************************************************************************/ +sl_status_t angle_queue_push(aoa_id_t tag_id, + aoa_id_t locator_id, + aoa_angle_t *angle); + +/**************************************************************************//** + * Deinitializes the queue. + *****************************************************************************/ +void angle_queue_deinit(void); + +#ifdef __cplusplus +}; +#endif + +#endif /* ANGLE_QUEUE_H*/ diff --git a/app/bluetooth/common_host/aoa_corr_angles/aoa_corr_angles.c b/app/bluetooth/common_host/aoa_corr_angles/aoa_corr_angles.c deleted file mode 100644 index 279f7d3c93b..00000000000 --- a/app/bluetooth/common_host/aoa_corr_angles/aoa_corr_angles.c +++ /dev/null @@ -1,249 +0,0 @@ -/***************************************************************************//** - * @file - * @brief Correlated angle database for asset tags. - ******************************************************************************* - * # License - * Copyright 2021 Silicon Laboratories Inc. www.silabs.com - ******************************************************************************* - * - * SPDX-License-Identifier: Zlib - * - * The licensor of this software is Silicon Laboratories Inc. - * - * This software is provided 'as-is', without any express or implied - * warranty. In no event will the authors be held liable for any damages - * arising from the use of this software. - * - * Permission is granted to anyone to use this software for any purpose, - * including commercial applications, and to alter it and redistribute it - * freely, subject to the following restrictions: - * - * 1. The origin of this software must not be misrepresented; you must not - * claim that you wrote the original software. If you use this software - * in a product, an acknowledgment in the product documentation would be - * appreciated but is not required. - * 2. Altered source versions must be plainly marked as such, and must not be - * misrepresented as being the original software. - * 3. This notice may not be removed or altered from any source distribution. - * - ******************************************************************************/ - -#include "aoa_corr_angles.h" - -// ----------------------------------------------------------------------------- -// Default values of configuration parameters. - -// Maximum number of incomplete sequence ids. -#define AOA_CORR_ANGLES_MAX_NUM_SEQUENCE_IDS 6 - -// Maximum sequence range where data does not reset. -#define AOA_CORR_ANGLES_MAX_SEQUENCE_DIFF 20 - -// ----------------------------------------------------------------------------- -// Type definitions. - -// Forward declarations -typedef struct aoa_corr_angles_node aoa_corr_angles_node_t; - -// Correlated angle node -struct aoa_corr_angles_node{ - aoa_id_t id; - aoa_corr_angles_t *corr_angles; - aoa_corr_angles_node_t *next; -}; - -// ----------------------------------------------------------------------------- -// Private function declarations. -static void aoa_corr_angles_remove_old_data(aoa_corr_angles_t *corr_angles_array, - int32_t sequence); -static uint32_t aoa_corr_angles_get_slot_by_sequence(aoa_corr_angles_t *corr_angles_array, - int32_t sequence); - -// ----------------------------------------------------------------------------- -// Module variables. - -// Linked list head -static aoa_corr_angles_node_t *head_corr_angles = NULL; - -// Configuration -aoa_corr_angles_config_t aoa_corr_angles_config = { - 0, - AOA_CORR_ANGLES_MAX_NUM_SEQUENCE_IDS, - AOA_CORR_ANGLES_MAX_SEQUENCE_DIFF -}; - -// ----------------------------------------------------------------------------- -// Public function definitions. - -/**************************************************************************//** - * Adds a correlated angle to the list. - *****************************************************************************/ -sl_status_t aoa_corr_angles_new(aoa_id_t id, - aoa_corr_angles_t **corr_angles) -{ - aoa_corr_angles_node_t *new = (aoa_corr_angles_node_t *)malloc(sizeof(aoa_corr_angles_node_t)); - if (NULL == new) { - return SL_STATUS_ALLOCATION_FAILED; - } - - new->corr_angles = (aoa_corr_angles_t *)malloc(aoa_corr_angles_config.sequence_id_slots * sizeof(aoa_corr_angles_t)); - if (NULL == new->corr_angles) { - return SL_STATUS_ALLOCATION_FAILED; - } - - // Initialize the angle structures - for (uint32_t i = 0; i < aoa_corr_angles_config.sequence_id_slots; i++) { - new->corr_angles[i].angles = (aoa_angle_t *)malloc(aoa_corr_angles_config.locator_count * sizeof(aoa_angle_t)); - new->corr_angles[i].has_angle = (bool *)malloc(aoa_corr_angles_config.locator_count * sizeof(bool)); - new->corr_angles[i].sequence = -1; - new->corr_angles[i].num_angles = 0; - - if ((NULL == new->corr_angles[i].angles) || (NULL == new->corr_angles[i].has_angle)) { - return SL_STATUS_ALLOCATION_FAILED; - } - } - - aoa_id_copy(new->id, id); - new->next = head_corr_angles; - head_corr_angles = new; - *corr_angles = new->corr_angles; - - return SL_STATUS_OK; -} - -/**************************************************************************//** - * Returns an entry from the database by its ID. - *****************************************************************************/ -sl_status_t aoa_corr_angles_get_by_id(aoa_id_t id, - aoa_corr_angles_t **corr_angles) -{ - aoa_corr_angles_node_t *current = head_corr_angles; - - if (NULL == head_corr_angles) { - return SL_STATUS_NOT_FOUND; - } - - while (NULL != current) { - if (0 == aoa_id_compare(current->id, id)) { - *corr_angles = current->corr_angles; - return SL_STATUS_OK; - } - current = current->next; - } - - return SL_STATUS_NOT_FOUND; -} - -/**************************************************************************//** - * Adds data to the slot. - *****************************************************************************/ -sl_status_t aoa_corr_angles_add_data(aoa_corr_angles_t *corr_angles_array, - uint32_t locator_id, - aoa_angle_t *angle, - uint32_t *angle_slot) -{ - uint32_t slot = 0; - - // Drop stored data that are considered too old - aoa_corr_angles_remove_old_data(corr_angles_array, angle->sequence); - - // Find the correct correlated angle slot - slot = aoa_corr_angles_get_slot_by_sequence(corr_angles_array, angle->sequence); - - if (slot > aoa_corr_angles_config.sequence_id_slots) { - return SL_STATUS_FAIL; - } - - // Insert the slot if it is not present yet. - if (corr_angles_array[slot].sequence != angle->sequence) { - for (int i = aoa_corr_angles_config.sequence_id_slots - 1; i > slot; i--) { - corr_angles_array[i].sequence = corr_angles_array[i - 1].sequence; - corr_angles_array[i].num_angles = corr_angles_array[i - 1].num_angles; - memcpy(corr_angles_array[i].angles, corr_angles_array[i - 1].angles, aoa_corr_angles_config.locator_count * sizeof(aoa_angle_t)); - memcpy(corr_angles_array[i].has_angle, corr_angles_array[i - 1].has_angle, aoa_corr_angles_config.locator_count * sizeof(bool)); - } - corr_angles_array[slot].num_angles = 0; - memset(corr_angles_array[slot].has_angle, 0, aoa_corr_angles_config.locator_count); - corr_angles_array[slot].sequence = angle->sequence; - } - memcpy(&corr_angles_array[slot].angles[locator_id], angle, sizeof(aoa_angle_t)); - corr_angles_array[slot].has_angle[locator_id] = true; - corr_angles_array[slot].num_angles++; - - *angle_slot = slot; - - return SL_STATUS_OK; -} - -/**************************************************************************//** - * Cleans up already processed data. - *****************************************************************************/ -sl_status_t aoa_corr_angles_cleanup(aoa_corr_angles_t *corr_angles_array, - uint32_t cleanup_start_idx) -{ - if (cleanup_start_idx > aoa_corr_angles_config.sequence_id_slots) { - return SL_STATUS_FAIL; - } - - for (; cleanup_start_idx < aoa_corr_angles_config.sequence_id_slots; cleanup_start_idx++) { - corr_angles_array[cleanup_start_idx].num_angles = 0; - corr_angles_array[cleanup_start_idx].sequence = -1; - memset(corr_angles_array[cleanup_start_idx].has_angle, 0, aoa_corr_angles_config.locator_count); - } - - return SL_STATUS_OK; -} - -/**************************************************************************//** - * Destroys the database and all of its entries. - *****************************************************************************/ -void aoa_corr_angles_destroy(void) -{ - aoa_corr_angles_node_t *current; - aoa_corr_angles_node_t *next; - - for (current = head_corr_angles; current != NULL; current = next) { - next = current->next; - free(current->corr_angles->angles); - free(current->corr_angles->has_angle); - free(current->corr_angles); - free(current); - } - - head_corr_angles = NULL; -} - -// ----------------------------------------------------------------------------- -// Private function definitions. - -/**************************************************************************//** - * Removes old angles. - *****************************************************************************/ -static void aoa_corr_angles_remove_old_data(aoa_corr_angles_t *corr_angles_array, - int32_t sequence) -{ - for (uint32_t i = 0; i < aoa_corr_angles_config.sequence_id_slots; i++) { - if (aoa_sequence_compare(corr_angles_array[i].sequence, sequence) > aoa_corr_angles_config.max_sequence_diff) { - for (uint32_t k = i; k < aoa_corr_angles_config.sequence_id_slots; k++) { - corr_angles_array[k].num_angles = 0; - corr_angles_array[k].sequence = -1; - memset(corr_angles_array[k].has_angle, 0, aoa_corr_angles_config.locator_count); - } - return; - } - } -} - -/**************************************************************************//** - * Returns an angle slot by the sequence number. - *****************************************************************************/ -static uint32_t aoa_corr_angles_get_slot_by_sequence(aoa_corr_angles_t *corr_angles_array, - int32_t sequence) -{ - for (uint32_t i = 0; i < aoa_corr_angles_config.sequence_id_slots; i++) { - if (sequence == corr_angles_array[i].sequence) { - return i; - } - } - return 0; -} diff --git a/app/bluetooth/common_host/aoa_corr_angles/aoa_corr_angles.h b/app/bluetooth/common_host/aoa_corr_angles/aoa_corr_angles.h deleted file mode 100644 index ada900ef5c1..00000000000 --- a/app/bluetooth/common_host/aoa_corr_angles/aoa_corr_angles.h +++ /dev/null @@ -1,132 +0,0 @@ -/***************************************************************************//** - * @file - * @brief Correlated angle database for asset tags. - ******************************************************************************* - * # License - * Copyright 2021 Silicon Laboratories Inc. www.silabs.com - ******************************************************************************* - * - * SPDX-License-Identifier: Zlib - * - * The licensor of this software is Silicon Laboratories Inc. - * - * This software is provided 'as-is', without any express or implied - * warranty. In no event will the authors be held liable for any damages - * arising from the use of this software. - * - * Permission is granted to anyone to use this software for any purpose, - * including commercial applications, and to alter it and redistribute it - * freely, subject to the following restrictions: - * - * 1. The origin of this software must not be misrepresented; you must not - * claim that you wrote the original software. If you use this software - * in a product, an acknowledgment in the product documentation would be - * appreciated but is not required. - * 2. Altered source versions must be plainly marked as such, and must not be - * misrepresented as being the original software. - * 3. This notice may not be removed or altered from any source distribution. - * - ******************************************************************************/ - -#ifndef AOA_CR_H -#define AOA_CR_H - -#include -#include -#include -#include "aoa_util.h" -#include "aoa_types.h" - -#ifdef __cplusplus -extern "C" { -#endif - -// ----------------------------------------------------------------------------- -// Type definitions. - -/// Initstruct for the module. -typedef struct { - uint32_t locator_count; // Locator count in the system. - uint32_t sequence_id_slots; // Sequence id slots. - uint32_t max_sequence_diff; // Maximum difference from the new sequence id. -} aoa_corr_angles_config_t; - -/// Correlated angles structure. -typedef struct aoa_corr_angles_s{ - int32_t sequence; - int32_t num_angles; - aoa_angle_t *angles; - bool *has_angle; -} aoa_corr_angles_t; - -// ----------------------------------------------------------------------------- -// Public variables. - -/// Configuration parameters -extern aoa_corr_angles_config_t aoa_corr_angles_config; - -// ----------------------------------------------------------------------------- -// Public functions. - -/**************************************************************************//** - * Creates a new database entry - * - * @param[in] tag_id Id which connects the stored values to a tag. - * @param[in] corr_angles_array Pointer to the correlated angles array. - * - * @retval SL_STATUS_ALLOCATION_FAILED - Memory allocation failure. - * @retval SL_STATUS_OK - Entry added. - *****************************************************************************/ -sl_status_t aoa_corr_angles_new(aoa_id_t tag_id, - aoa_corr_angles_t **corr_angles_array); - -/**************************************************************************//** - * Returns an entry from the database by the id. - * - * @param[in] tag_id id which connects the stored values to a tag. - * @param[in] corr_angles Correlated angles array. - * - * @retval SL_STATUS_NOT_FOUND - Entry not found. - * @retval SL_STATUS_OK - Entry found. - *****************************************************************************/ -sl_status_t aoa_corr_angles_get_by_id(aoa_id_t tag_id, - aoa_corr_angles_t **corr_angles_array); - -/**************************************************************************//** - * Adds data to the corresponding tag id and slot number. - * - * @param[in] corr_angles_array Pointer to the correlated angles array. - * @param[in] locator_idx Locator which the data came from. - * @param[in] angle Data to be added. - * @param[in] angle_slot Slot where the data was added. - * - * @retval SL_STATUS_FAIL - Slot number exceeds the maximum that can be stored. - * @retval SL_STATUS_OK - Data added. - *****************************************************************************/ -sl_status_t aoa_corr_angles_add_data(aoa_corr_angles_t *corr_angles_array, - uint32_t locator_idx, - aoa_angle_t *angle, - uint32_t *angle_slot); - -/**************************************************************************//** - * Cleans up already processed data. - * - * @param[in] corr_angles_array Pointer to the correlated angles array. - * @param[in] cleanup_start_idx Start index for the cleanup. - * - * @retval SL_STATUS_FAIL - Start index higher than the slot count. - * @retval SL_STATUS_OK - Cleanup done. - *****************************************************************************/ -sl_status_t aoa_corr_angles_cleanup(aoa_corr_angles_t *corr_angles_array, - uint32_t cleanup_start_idx); - -/**************************************************************************//** - * Destroys the database and all of its entries. - *****************************************************************************/ -void aoa_corr_angles_destroy(void); - -#ifdef __cplusplus -}; -#endif - -#endif /* AOA_CR_H */ diff --git a/app/bluetooth/common_host/aoa_loc/aoa_loc.c b/app/bluetooth/common_host/aoa_loc/aoa_loc.c index 62160aa2dfd..09d062e453c 100644 --- a/app/bluetooth/common_host/aoa_loc/aoa_loc.c +++ b/app/bluetooth/common_host/aoa_loc/aoa_loc.c @@ -45,14 +45,15 @@ if ((x) != SL_RTL_ERROR_SUCCESS) \ return SL_STATUS_FAIL -#define ROUND_DIV(num, den) (((num) + ((den) / 2)) / (den)) - // ----------------------------------------------------------------------------- // Default values of configuration parameters. // Location estimation mode. #define AOA_LOC_ESTIMATION_MODE SL_RTL_LOC_ESTIMATION_MODE_THREE_DIM_HIGH_ACCURACY +// Max sequence diff +#define AOA_LOC_MAX_SEQUENCE_DIFF 20u + // Estimation interval in seconds. // This value should approximate the time interval between two consecutive CTEs. #define AOA_LOC_ESTIMATION_INTERVAL_SEC 0.02f @@ -75,7 +76,9 @@ typedef struct aoa_asset_tag_node aoa_asset_tag_node_t; static sl_status_t aoa_loc_init_asset_tag(aoa_asset_tag_t *tag); static sl_status_t aoa_loc_deinit_asset_tag(aoa_asset_tag_t *tag); static sl_status_t aoa_loc_run_estimation(aoa_asset_tag_t *tag, - aoa_corr_angles_t *correlated_angles); + uint32_t angle_count, + aoa_angle_t *angle_list, + aoa_id_t *locator_list); static void aoa_loc_destroy_tags(void); static void aoa_loc_destroy_locators(void); @@ -101,6 +104,7 @@ static aoa_locator_node_t *head_locator = NULL; // Configuration parameters aoa_loc_config_t aoa_loc_config = { 0, + AOA_LOC_MAX_SEQUENCE_DIFF, AOA_LOC_ESTIMATION_MODE, AOA_LOC_VALIDATION_MODE, AOA_LOC_ESTIMATION_INTERVAL_SEC, @@ -109,30 +113,48 @@ aoa_loc_config_t aoa_loc_config = { true }; -// The expected number of angles depends on the slot index. A slot with smaller -// index (i.e. with more recent sequence number) expects more angles, while a -// slot with higher index (i.e. with older sequence number) requires less -// angles. -// This module implements a linear connection, thus the first slot expects -// an angle from all locators, while the last slot needs only 2 locators. -static uint32_t *expected_angles_count; +// RTL lib location instance for tags +static sl_rtl_loc_libitem loc_libitem; // ----------------------------------------------------------------------------- // Public function definitions. /**************************************************************************//** - * Initializes the expected angle count for the module. + * Initializes the locator engine. *****************************************************************************/ -void aoa_loc_init_expected_angle_count(void) +sl_status_t aoa_loc_init(void) { - uint32_t coeff; + enum sl_rtl_error_code ec; + + ec = sl_rtl_loc_init(&loc_libitem); + CHECK_ERROR(ec); + + return SL_STATUS_OK; +} + +/**************************************************************************//** + * Finalizes the configuration. + *****************************************************************************/ +sl_status_t aoa_loc_finalize_config(void) +{ + enum sl_rtl_error_code ec; + + // Select estimation mode. + ec = sl_rtl_loc_set_mode(&loc_libitem, aoa_loc_config.estimation_mode); + CHECK_ERROR(ec); + + // Create position estimator. + ec = sl_rtl_loc_create_position_estimator(&loc_libitem); + CHECK_ERROR(ec); - // Init the expected angles - expected_angles_count = (uint32_t *)malloc(aoa_corr_angles_config.sequence_id_slots * sizeof(uint32_t)); - coeff = (aoa_loc_config.locator_count < 2) ? 0 : (aoa_loc_config.locator_count - 2); - for (uint32_t i = 0; i < aoa_corr_angles_config.sequence_id_slots; i++) { - expected_angles_count[i] = aoa_loc_config.locator_count - ROUND_DIV(i * coeff, aoa_corr_angles_config.sequence_id_slots - 1); + if (aoa_loc_config.is_feedback_enabled) { + // Turn on the bad angle detection mechanism. + ec = sl_rtl_loc_set_measurement_validation(&loc_libitem, + aoa_loc_config.validation_method); + CHECK_ERROR(ec); } + + return SL_STATUS_OK; } /**************************************************************************//** @@ -142,6 +164,8 @@ sl_status_t aoa_loc_add_locator(aoa_id_t locator_id, struct sl_rtl_loc_locator_item item, aoa_locator_t **locator) { + enum sl_rtl_error_code ec; + aoa_locator_node_t *new = (aoa_locator_node_t *)malloc(sizeof(aoa_locator_node_t)); if (NULL == new) { return SL_STATUS_ALLOCATION_FAILED; @@ -158,6 +182,9 @@ sl_status_t aoa_loc_add_locator(aoa_id_t locator_id, new->locator.item.orientation_y_axis_degrees = item.orientation_y_axis_degrees; new->locator.item.orientation_z_axis_degrees = item.orientation_z_axis_degrees; + ec = sl_rtl_loc_add_locator(&loc_libitem, &new->locator.item, &new->locator.loc_id); + CHECK_ERROR(ec); + *locator = &(new->locator); return SL_STATUS_OK; @@ -180,7 +207,9 @@ sl_status_t aoa_loc_get_locator_by_id(aoa_id_t locator_id, while (NULL != current) { if (0 == aoa_id_compare(current->locator.id, locator_id)) { *locator = &(current->locator); - *locator_idx = i; + if (NULL != locator_idx) { + *locator_idx = i; + } return SL_STATUS_OK; } i++; @@ -218,9 +247,9 @@ sl_status_t aoa_loc_get_locator_by_index(uint32_t locator_idx, /**************************************************************************//** * Returns the number of locators on the list. *****************************************************************************/ -size_t aoa_loc_get_number_of_locators(void) +uint32_t aoa_loc_get_number_of_locators(void) { - size_t i = 0; + uint32_t i = 0; aoa_locator_node_t *current = head_locator; while (NULL != current) { @@ -304,55 +333,50 @@ sl_status_t aoa_loc_get_tag_by_index(uint32_t index, /**************************************************************************//** * Calculates the asset tag position and notify the app. *****************************************************************************/ -sl_status_t aoa_loc_calc_position(aoa_asset_tag_t *tag, - int32_t start_slot, - aoa_corr_angles_t *corr_angles_array, - uint32_t *last_updated_slot) +sl_status_t aoa_loc_calc_position(aoa_id_t tag_id, + uint32_t angle_count, + aoa_angle_t *angle_list, + aoa_id_t *locator_list) { sl_status_t sc; + aoa_asset_tag_t *tag; aoa_locator_t *locator; + aoa_correction_t correction; + uint32_t locator_index = 0; - if (start_slot < 0) { - return SL_STATUS_FAIL; + sc = aoa_loc_get_tag_by_id(tag_id, &tag); + if (sc != SL_STATUS_OK) { + return sc; + } + + sc = aoa_loc_run_estimation(tag, angle_count, angle_list, locator_list); + if (sc != SL_STATUS_OK) { + return sc; } - *last_updated_slot = aoa_corr_angles_config.sequence_id_slots; - // Check start from the oldest slots to keep in order and complete as many - // slots as possible. - for (int32_t i = aoa_corr_angles_config.sequence_id_slots - 1; i >= start_slot; i--) { - if (corr_angles_array[i].num_angles >= expected_angles_count[i]) { - sc = aoa_loc_run_estimation(tag, &corr_angles_array[i]); - if (SL_STATUS_OK != sc) { - return sc; - } - // Notify the application - aoa_loc_on_position_ready(tag); - *last_updated_slot = i; - - // Check if some of the locators require correction. - if (aoa_loc_config.is_feedback_enabled && sl_rtl_loc_get_number_disabled(&tag->loc) > 0) { - aoa_correction_t correction; - - for (uint32_t j = 0; j < aoa_loc_config.locator_count; j++) { - if (corr_angles_array[i].has_angle[j]) { - sc = sl_rtl_loc_get_expected_direction(&tag->loc, - tag->loc_id[j], - &correction.direction.azimuth, - &correction.direction.elevation, - &correction.direction.distance); - if (sc == SL_RTL_ERROR_INCORRECT_MEASUREMENT) { - sl_rtl_loc_get_expected_deviation(&tag->loc, - tag->loc_id[j], - &correction.deviation.azimuth, - &correction.deviation.elevation, - &correction.deviation.distance); - correction.sequence = tag->position.sequence; - aoa_loc_get_locator_by_index(j, &locator); - // The first angle in the correlated angle list is the most recent one. - aoa_loc_on_correction_ready(tag, corr_angles_array[0].sequence, locator->id, j, &correction); - } - } - } + // Notify the application + aoa_loc_on_position_ready(tag); + + // Check if some of the locators require correction. + if (aoa_loc_config.is_feedback_enabled && sl_rtl_loc_get_number_disabled_tag(&loc_libitem, tag->tag_id) > 0) { + for (uint32_t i = 0; i < angle_count; i++) { + aoa_loc_get_locator_by_id(locator_list[i], &locator_index, &locator); + sc = sl_rtl_loc_get_expected_direction_tag(&loc_libitem, + locator->loc_id, + &correction.direction.azimuth, + &correction.direction.elevation, + &correction.direction.distance, + tag->tag_id); + if (sc == SL_RTL_ERROR_INCORRECT_MEASUREMENT) { + sl_rtl_loc_get_expected_deviation_tag(&loc_libitem, + locator->loc_id, + &correction.deviation.azimuth, + &correction.deviation.elevation, + &correction.deviation.distance, + tag->tag_id); + correction.sequence = tag->position.sequence; + // The first angle in the angle list is the most recent. + aoa_loc_on_correction_ready(tag, angle_list[0].sequence, locator->id, locator_index, &correction); } } } @@ -365,9 +389,9 @@ sl_status_t aoa_loc_calc_position(aoa_asset_tag_t *tag, *****************************************************************************/ void aoa_loc_destroy(void) { - free(expected_angles_count); aoa_loc_destroy_tags(); aoa_loc_destroy_locators(); + sl_rtl_loc_deinit(&loc_libitem); } /**************************************************************************//** @@ -418,44 +442,18 @@ SL_WEAK void aoa_loc_angle_deinit(aoa_asset_tag_t *tag, static sl_status_t aoa_loc_init_asset_tag(aoa_asset_tag_t *tag) { enum sl_rtl_error_code ec; - aoa_locator_node_t *current_locator = head_locator; // Invalid sequence tag->position.sequence = -1; tag->aoa_state = NULL; - // Initialize locator ids for the tag - tag->loc_id = (uint32_t *)malloc(aoa_loc_config.locator_count * sizeof(uint32_t)); - - // Initialize RTL library - ec = sl_rtl_loc_init(&tag->loc); - CHECK_ERROR(ec); - - // Select estimation mode. - ec = sl_rtl_loc_set_mode(&tag->loc, aoa_loc_config.estimation_mode); + ec = sl_rtl_loc_add_tag(&loc_libitem, &tag->tag_id); CHECK_ERROR(ec); - // Provide locator configurations to the position estimator. - for (size_t i = 0; i < aoa_loc_config.locator_count; i++) { - ec = sl_rtl_loc_add_locator(&tag->loc, ¤t_locator->locator.item, &tag->loc_id[i]); - current_locator = current_locator->next; - CHECK_ERROR(ec); - } - // Initialize the angle calculation. aoa_loc_angle_init(tag, aoa_loc_config.locator_count); - // Create position estimator. - ec = sl_rtl_loc_create_position_estimator(&tag->loc); - CHECK_ERROR(ec); - - if (aoa_loc_config.is_feedback_enabled) { - // Turn on the bad angle detection mechanism. - ec = sl_rtl_loc_set_measurement_validation(&tag->loc, aoa_loc_config.validation_method); - CHECK_ERROR(ec); - } - if (aoa_loc_config.filtering_enabled == true) { // Initialize util functions. for (enum axis_list i = 0; i < AXIS_COUNT; i++) { @@ -480,7 +478,7 @@ static sl_status_t aoa_loc_deinit_asset_tag(aoa_asset_tag_t *tag) enum sl_rtl_error_code ec; aoa_loc_angle_deinit(tag, aoa_loc_config.locator_count); - ec = sl_rtl_loc_deinit(&tag->loc); + ec = sl_rtl_loc_remove_tag(&loc_libitem, tag->tag_id); CHECK_ERROR(ec); if (aoa_loc_config.filtering_enabled == true) { @@ -497,74 +495,84 @@ static sl_status_t aoa_loc_deinit_asset_tag(aoa_asset_tag_t *tag) * Run position estimation algorithm for a given asset tag. *****************************************************************************/ static sl_status_t aoa_loc_run_estimation(aoa_asset_tag_t *tag, - aoa_corr_angles_t *correlated_angles) + uint32_t angle_count, + aoa_angle_t *angle_list, + aoa_id_t *locator_list) { - enum sl_rtl_error_code ec; sl_status_t sc; + enum sl_rtl_error_code ec; float time_step = aoa_loc_config.estimation_interval_sec; int32_t seq_diff; + aoa_locator_t *locator; + // Feed measurement values into RTL lib. - for (uint32_t i = 0; i < aoa_loc_config.locator_count; i++) { - if (correlated_angles->has_angle[i]) { - ec = sl_rtl_loc_set_locator_measurement(&tag->loc, - tag->loc_id[i], - SL_RTL_LOC_LOCATOR_MEASUREMENT_AZIMUTH, - correlated_angles->angles[i].azimuth); + for (uint32_t i = 0; i < angle_count; i++) { + aoa_loc_get_locator_by_id(locator_list[i], NULL, &locator); + ec = sl_rtl_loc_set_locator_measurement_tag(&loc_libitem, + locator->loc_id, + SL_RTL_LOC_LOCATOR_MEASUREMENT_AZIMUTH, + angle_list[i].azimuth, + tag->tag_id); - CHECK_ERROR(ec); + CHECK_ERROR(ec); - ec = sl_rtl_loc_set_locator_measurement(&tag->loc, - tag->loc_id[i], - SL_RTL_LOC_LOCATOR_MEASUREMENT_ELEVATION, - correlated_angles->angles[i].elevation); - CHECK_ERROR(ec); + ec = sl_rtl_loc_set_locator_measurement_tag(&loc_libitem, + locator->loc_id, + SL_RTL_LOC_LOCATOR_MEASUREMENT_ELEVATION, + angle_list[i].elevation, + tag->tag_id); + CHECK_ERROR(ec); - // Feeding RSSI distance measurement to the RTL library improves location - // accuracy when the measured distance is reasonably correct. - // If the received signal strength of the incoming signal is altered for any - // other reason than the distance between the TX and RX itself, it will lead - // to incorrect measurement and it will lead to incorrect position estimates. - // For this reason the RSSI distance usage is disabled by default in the - // multilocator case. - // Single locator mode however always requires the distance measurement in - // addition to the angle, please note the if-condition below. - // In case the distance estimation should be used in the multilocator case, - // you can enable it by commenting out the condition. - if (aoa_loc_config.locator_count == 1) { - ec = sl_rtl_loc_set_locator_measurement(&tag->loc, - tag->loc_id[i], - SL_RTL_LOC_LOCATOR_MEASUREMENT_DISTANCE, - correlated_angles->angles[i].distance); - CHECK_ERROR(ec); - } + // Feeding RSSI distance measurement to the RTL library improves location + // accuracy when the measured distance is reasonably correct. + // If the received signal strength of the incoming signal is altered for any + // other reason than the distance between the TX and RX itself, it will lead + // to incorrect measurement and it will lead to incorrect position estimates. + // For this reason the RSSI distance usage is disabled by default in the + // multilocator case. + // Single locator mode however always requires the distance measurement in + // addition to the angle, please note the if-condition below. + // In case the distance estimation should be used in the multilocator case, + // you can enable it by commenting out the condition. + if (aoa_loc_config.locator_count == 1) { + ec = sl_rtl_loc_set_locator_measurement_tag(&loc_libitem, + locator->loc_id, + SL_RTL_LOC_LOCATOR_MEASUREMENT_DISTANCE, + angle_list[i].distance, + tag->tag_id); + CHECK_ERROR(ec); } } // Estimate the time step based on the sequence number. - seq_diff = aoa_sequence_compare(correlated_angles->sequence, + seq_diff = aoa_sequence_compare(angle_list[0].sequence, tag->position.sequence); - if (seq_diff <= aoa_corr_angles_config.max_sequence_diff) { + + if (seq_diff <= aoa_loc_config.max_sequence_diff) { time_step *= (float)seq_diff; } // Process new measurements, time step given in seconds. - sc = sl_rtl_loc_process(&tag->loc, time_step); - tag->position.sequence = correlated_angles->sequence; + sc = sl_rtl_loc_process_tag(&loc_libitem, time_step, tag->tag_id); + tag->position.sequence = angle_list[0].sequence; CHECK_ERROR(sc); // Get results from the estimator. - sc = sl_rtl_loc_get_result(&tag->loc, - SL_RTL_LOC_RESULT_POSITION_X, - &tag->position.x); + sc = sl_rtl_loc_get_result_tag(&loc_libitem, + SL_RTL_LOC_RESULT_POSITION_X, + &tag->position.x, + tag->tag_id); CHECK_ERROR(sc); - sc = sl_rtl_loc_get_result(&tag->loc, - SL_RTL_LOC_RESULT_POSITION_Y, - &tag->position.y); + sc = sl_rtl_loc_get_result_tag(&loc_libitem, + SL_RTL_LOC_RESULT_POSITION_Y, + &tag->position.y, + tag->tag_id); CHECK_ERROR(sc); - sc = sl_rtl_loc_get_result(&tag->loc, - SL_RTL_LOC_RESULT_POSITION_Z, - &tag->position.z); + sc = sl_rtl_loc_get_result_tag(&loc_libitem, + SL_RTL_LOC_RESULT_POSITION_Z, + &tag->position.z, + tag->tag_id); CHECK_ERROR(sc); if (aoa_loc_config.filtering_enabled == true) { @@ -584,7 +592,7 @@ static sl_status_t aoa_loc_run_estimation(aoa_asset_tag_t *tag, } // Clear measurements. - ec = sl_rtl_loc_clear_measurements(&tag->loc); + ec = sl_rtl_loc_clear_measurements_tag(&loc_libitem, tag->tag_id); CHECK_ERROR(ec); return SL_STATUS_OK; @@ -601,7 +609,6 @@ static void aoa_loc_destroy_tags(void) for (current = head_tag; current != NULL; current = next) { next = current->next; aoa_loc_deinit_asset_tag(¤t->tag); - free(current->tag.loc_id); free(current); } diff --git a/app/bluetooth/common_host/aoa_loc/aoa_loc.h b/app/bluetooth/common_host/aoa_loc/aoa_loc.h index 0bebb53d82c..a138f02beb4 100644 --- a/app/bluetooth/common_host/aoa_loc/aoa_loc.h +++ b/app/bluetooth/common_host/aoa_loc/aoa_loc.h @@ -34,7 +34,6 @@ #include "sl_status.h" #include "aoa_types.h" #include "sl_rtl_clib_api.h" -#include "aoa_corr_angles.h" #ifdef __cplusplus extern "C" { @@ -57,14 +56,14 @@ enum axis_list{ /// Locator struct typedef struct { aoa_id_t id; + uint32_t loc_id; // assigned by RTL lib struct sl_rtl_loc_locator_item item; } aoa_locator_t; /// Asset tag struct typedef struct { aoa_id_t id; - uint32_t *loc_id; // assigned by RTL lib - sl_rtl_loc_libitem loc; + int32_t tag_id; // assigned by RTL lib sl_rtl_util_libitem filter[AXIS_COUNT]; aoa_position_t position; void *aoa_state; //Only if Angle calculation is needed from IQ report @@ -72,7 +71,8 @@ typedef struct { /// Init struct typedef struct { - size_t locator_count; + uint32_t locator_count; + uint32_t max_sequence_diff; enum sl_rtl_loc_estimation_mode estimation_mode; enum sl_rtl_loc_measurement_validation_method validation_method; float estimation_interval_sec; @@ -91,9 +91,21 @@ extern aoa_loc_config_t aoa_loc_config; // Public functions. /**************************************************************************//** - * Initializes the expected angle count. + * Initializes the locator engine. + * + * @retval SL_STATUS_FAIL - RTL lib initialization error. + * @retval SL_STATUS_OK - Initialization ok. + *****************************************************************************/ +sl_status_t aoa_loc_init(void); + +/**************************************************************************//** + * Finalizes the configuration. + * + * @retval SL_STATUS_ALLOCATION_FAILED - Memory allocation error. + * @retval SL_STATUS_FAIL - RTL lib error. + * @retval SL_STATUS_OK - Initialization ok. *****************************************************************************/ -void aoa_loc_init_expected_angle_count(void); +sl_status_t aoa_loc_finalize_config(void); /**************************************************************************//** * Adds a new locator to the database. @@ -140,7 +152,7 @@ sl_status_t aoa_loc_get_locator_by_index(uint32_t locator_idx, * * @retval Number of locators *****************************************************************************/ -size_t aoa_loc_get_number_of_locators(void); +uint32_t aoa_loc_get_number_of_locators(void); /**************************************************************************//** * Adds a new asset tag to the database. @@ -182,18 +194,18 @@ sl_status_t aoa_loc_get_tag_by_index(uint32_t index, /**************************************************************************//** * Calculates the asset tag position and notify the app. * - * @param[in] tag Pointer to the entry. - * @param[in] start_slot The correlated angle slot to start the calc from. - * @param[in] corr_angles_array Pointer to the correlated angles array. - * @param[in] last_updated_slot The slot that was last updated. + * @param[in] tag_id Tag for calculate the location. + * @param[in] angle_count Number of angles. + * @param[in] angle_list Angle list. + * @param[in] locator_list Locator list. * * @retval SL_STATUS_FAIL - Position calculation failed in the RTL lib. * @retval SL_STATUS_OK - Calculation was succesful. *****************************************************************************/ -sl_status_t aoa_loc_calc_position(aoa_asset_tag_t *tag, - int32_t start_slot, - aoa_corr_angles_t *corr_angles_array, - uint32_t *last_updated_slot); +sl_status_t aoa_loc_calc_position(aoa_id_t tag_id, + uint32_t angle_count, + aoa_angle_t *angle_list, + aoa_id_t *locator_list); /**************************************************************************//** * Destroys the module database. diff --git a/app/bluetooth/common_host/aoa_util/aoa_parse.c b/app/bluetooth/common_host/aoa_util/aoa_parse.c index 9458039e964..ebf47037fce 100644 --- a/app/bluetooth/common_host/aoa_util/aoa_parse.c +++ b/app/bluetooth/common_host/aoa_util/aoa_parse.c @@ -956,7 +956,7 @@ static sl_status_t aoa_parse_find_locator_config(cJSON **locator, cJSON *param; cJSON *array; cJSON *item; - uint8_t i = 0; + uint32_t i = 0; array = cJSON_GetObjectItem(root, "locators"); CHECK_TYPE(array, cJSON_Array); diff --git a/app/bluetooth/common_host/btmesh_conf/btmesh_conf.c b/app/bluetooth/common_host/btmesh_conf/btmesh_conf.c index f47732401c1..051b7686a67 100644 --- a/app/bluetooth/common_host/btmesh_conf/btmesh_conf.c +++ b/app/bluetooth/common_host/btmesh_conf/btmesh_conf.c @@ -182,7 +182,7 @@ sl_status_t btmesh_conf_init(void) } if (SL_STATUS_OK == sc) { - btmesh_conf_dist = btmesh_conf_distributor_create(BTMESH_CONF_EXECUTOR_COUNT); + btmesh_conf_dist = btmesh_conf_distributor_create(SL_BTMESH_CONF_EXECUTOR_COUNT_CFG_VAL); if (NULL == btmesh_conf_dist) { sc = SL_STATUS_ALLOCATION_FAILED; } else { @@ -209,7 +209,7 @@ sl_status_t btmesh_conf_submit_job(btmesh_conf_job_t *job) { bool auto_destroy_on_submit_failure = false; -#if 0 != BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE +#if 0 != SL_BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE_CFG_VAL if (false != job->auto_destroy) { auto_destroy_on_submit_failure = true; } @@ -292,8 +292,8 @@ void btmesh_conf_on_event(const sl_btmesh_msg_t *evt) sc = btmesh_conf_init(); app_assert_status_f(sc, "Failed to init configurator component." NL); - sc = sl_btmesh_config_client_set_default_timeout(BTMESH_CONF_REQUEST_TIMEOUT_MS, - BTMESH_CONF_LPN_REQUEST_TIMEOUT_MS); + sc = sl_btmesh_config_client_set_default_timeout(SL_BTMESH_CONF_REQUEST_TIMEOUT_MS_CFG_VAL, + SL_BTMESH_CONF_LPN_REQUEST_TIMEOUT_MS_CFG_VAL); app_assert_status_f(sc, "Failed to set config client default timeout."); break; } diff --git a/app/bluetooth/common_host/btmesh_conf/btmesh_conf.h b/app/bluetooth/common_host/btmesh_conf/btmesh_conf.h index e72424191fe..31db08bcfa2 100644 --- a/app/bluetooth/common_host/btmesh_conf/btmesh_conf.h +++ b/app/bluetooth/common_host/btmesh_conf/btmesh_conf.h @@ -143,7 +143,7 @@ sl_status_t btmesh_conf_deinit(void); * over the ownership of the job and consequently the application is no longer * allowed to modify the submitted job or its tasks. * If the submit operation fails and @ref btmesh_conf_job_t::auto_destroy is set - * and @ref BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE is turned on then the + * and @ref SL_BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE_CFG_VAL is turned on then the * job is deallocated automatically in the submit call and consequently the job * shall not be referenced when the submit returns with failure. * diff --git a/app/bluetooth/common_host/btmesh_conf/btmesh_conf_executor.c b/app/bluetooth/common_host/btmesh_conf/btmesh_conf_executor.c index 7293026eef2..cced80c5dd2 100644 --- a/app/bluetooth/common_host/btmesh_conf/btmesh_conf_executor.c +++ b/app/bluetooth/common_host/btmesh_conf/btmesh_conf_executor.c @@ -255,9 +255,9 @@ btmesh_conf_executor_t *btmesh_conf_executor_create(uint16_t id, self->state = BTMESH_CONF_EXEC_STATE_IDLE; self->current_job = NULL; self->local_retry_counter = 0; - self->local_retry_max = BTMESH_CONF_REQUEST_BUSY_RETRY_MAX; + self->local_retry_max = SL_BTMESH_CONF_REQUEST_BUSY_RETRY_MAX_CFG_VAL; self->communication_retry_counter = 0; - self->communication_retry_max = BTMESH_CONF_COMMUNICATION_RETRY_MAX; + self->communication_retry_max = SL_BTMESH_CONF_COMMUNICATION_RETRY_MAX_CFG_VAL; self->timer_active = false; } return self; @@ -370,8 +370,8 @@ static sl_status_t executor_conf_request(btmesh_conf_executor_t *const self, btmesh_conf_job_t *job = self->current_job; bool conf_request_required = true; bool current_task_failed = false; - char task_str[BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE]; - char node_str[BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE]; + char task_str[SL_BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE_CFG_VAL]; + char node_str[SL_BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE_CFG_VAL]; // Loop is necessary because it is possible that BT Mesh Stack configuration // request of the current task fails. If a configuration request fails with @@ -492,8 +492,8 @@ static void executor_process_task_status(btmesh_conf_executor_t *const self, bool current_task_finished = true; bool retry_required = false; btmesh_conf_job_t *job = self->current_job; - char task_str[BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE]; - char node_str[BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE]; + char task_str[SL_BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE_CFG_VAL]; + char node_str[SL_BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE_CFG_VAL]; // If any log level is enabled which is used in this function then it is // necessary to build the log message fragments. @@ -712,7 +712,7 @@ static void executor_state_transition(btmesh_conf_executor_t *const self, "request busy retry timer." NL, self->id); sc = sl_simple_timer_start(&self->timer, - BTMESH_CONF_REQUEST_BUSY_RETRY_INTERVAL_MS, + SL_BTMESH_CONF_REQUEST_BUSY_RETRY_INTERVAL_MS_CFG_VAL, executor_on_timer_elapsed, self, false); @@ -728,7 +728,7 @@ static void executor_state_transition(btmesh_conf_executor_t *const self, "waiting for event timeout timer." NL, self->id); sc = sl_simple_timer_start(&self->timer, - BTMESH_CONF_EVENT_WAIT_TIMEOUT_MS, + SL_BTMESH_CONF_EVENT_WAIT_TIMEOUT_MS_CFG_VAL, executor_on_timer_elapsed, self, false); diff --git a/app/bluetooth/common_host/btmesh_conf/btmesh_conf_job.c b/app/bluetooth/common_host/btmesh_conf/btmesh_conf_job.c index cd47250e045..f12da1a49e6 100644 --- a/app/bluetooth/common_host/btmesh_conf/btmesh_conf_job.c +++ b/app/bluetooth/common_host/btmesh_conf/btmesh_conf_job.c @@ -52,7 +52,7 @@ btmesh_conf_job_t *btmesh_conf_job_create_default(uint16_t enc_netkey_index, task_tree, on_job_notification, BTMESH_CONF_VARG_NULL, - BTMESH_CONF_JOB_AUTO_DESTROY, + SL_BTMESH_CONF_JOB_AUTO_DESTROY_CFG_VAL, NULL); } diff --git a/app/bluetooth/common_host/btmesh_conf/btmesh_conf_job.h b/app/bluetooth/common_host/btmesh_conf/btmesh_conf_job.h index 82232449c35..327f7f092fa 100644 --- a/app/bluetooth/common_host/btmesh_conf/btmesh_conf_job.h +++ b/app/bluetooth/common_host/btmesh_conf/btmesh_conf_job.h @@ -107,7 +107,7 @@ struct btmesh_conf_job_t { /// @brief Auto destroy deallocates the configuration job and its tasks /// automatically after the job status notification callback returns. /// If @ref btmesh_conf_submit_job operation fails and the definition - /// BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE is turned on + /// SL_BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE_CFG_VAL is turned on /// then the job is deallocated automatically on submit failure. bool auto_destroy; }; @@ -125,7 +125,7 @@ struct btmesh_conf_job_t { * * This function calls @ref btmesh_conf_job_create with the following parameters: * - @a job_status_param: @ref BTMESH_CONF_VARG_NULL - * - @a auto_destroy: @ref BTMESH_CONF_JOB_AUTO_DESTROY + * - @a auto_destroy: @ref SL_BTMESH_CONF_JOB_AUTO_DESTROY_CFG_VAL * - @a job_id: NULL ******************************************************************************/ btmesh_conf_job_t *btmesh_conf_job_create_default(uint16_t enc_netkey_index, @@ -147,7 +147,7 @@ btmesh_conf_job_t *btmesh_conf_job_create_default(uint16_t enc_netkey_index, * @param[in] auto_destroy Auto destroy deallocates the configuration job and * its tasks automatically after the job status notification callback returns. * If @ref btmesh_conf_submit_job operation fails and the definition - * @ref BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE is turned on then the + * @ref SL_BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE_CFG_VAL is turned on then the * job is deallocated automatically on submit failure. * @param[out] job_id Unique job ID generated by @ref btmesh_conf_job_id_generator * @returns Created configuration job. diff --git a/app/bluetooth/common_host/btmesh_conf/btmesh_conf_task.c b/app/bluetooth/common_host/btmesh_conf/btmesh_conf_task.c index 06ad1f2bb10..59feef2298f 100644 --- a/app/bluetooth/common_host/btmesh_conf/btmesh_conf_task.c +++ b/app/bluetooth/common_host/btmesh_conf/btmesh_conf_task.c @@ -3027,7 +3027,7 @@ static sl_status_t btmesh_conf_task_dcd_process(btmesh_conf_task_t *const self, } else if (false != node->dcd_available) { process_dcd_status = SL_STATUS_INVALID_STATE; } else { - char node_str[BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE]; + char node_str[SL_BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE_CFG_VAL]; uint16_t remaining_size = self->ext.dcd.raw_dcd_data_size; btmesh_conf_dcd_raw_header_t *dcd_raw_hdr = (btmesh_conf_dcd_raw_header_t*) self->ext.dcd.raw_dcd_data; @@ -3139,7 +3139,7 @@ static sl_status_t btmesh_conf_task_dcd_element_iterate(uint16_t enc_netkey_inde uint16_t remaining_size = raw_dcd_data_size; uint16_t data_idx = 0; uint16_t element_index = 0; - char node_str[BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE]; + char node_str[SL_BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE_CFG_VAL]; if (remaining_size < sizeof(btmesh_conf_dcd_raw_header_t)) { return SL_STATUS_INVALID_COUNT; diff --git a/app/bluetooth/common_host/btmesh_conf/config/btmesh_conf_config.h b/app/bluetooth/common_host/btmesh_conf/config/btmesh_conf_config.h index 35e1b05c35e..0a738351971 100644 --- a/app/bluetooth/common_host/btmesh_conf/config/btmesh_conf_config.h +++ b/app/bluetooth/common_host/btmesh_conf/config/btmesh_conf_config.h @@ -38,86 +38,86 @@ extern "C" // <<< Use Configuration Wizard in Context Menu >>> -// Log message fragment buffer size +// Log message fragment buffer size // Default: 256 // <8-1024:1> // Log message fragment buffers are allocated on stack and used to format parts of log messages. -#define BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE 256 +#define SL_BTMESH_CONF_MAX_LOG_MSG_FRAGMENT_SIZE_CFG_VAL 256 -// Configuration executor count +// Configuration executor count // Default: 1 // <1-256:1> // Specifies the maximum number of parallel active configuration jobs. // The executor count shall be less than SL_BTMESH_CONFIG_MAX_SEND_SEGS and SL_BTMESH_CONFIG_APP_TXQ_SIZE in sl_btmesh_config.h of NCP embedded code. -#define BTMESH_CONF_EXECUTOR_COUNT 1 +#define SL_BTMESH_CONF_EXECUTOR_COUNT_CFG_VAL 1 -// Configuration client request timeout (ms) +// Configuration client request timeout (ms) // Default: 5000 // <1-4294967295:1> // Default timeout in milliseconds of configuration client requests. // The BT Mesh Stack emits a configuration client event with SL_STATUS_TIMEOUT result if no reponse is received from configuration server. -#define BTMESH_CONF_REQUEST_TIMEOUT_MS 5000 +#define SL_BTMESH_CONF_REQUEST_TIMEOUT_MS_CFG_VAL 5000 -// Configuration client LPN request timeout (ms) +// Configuration client LPN request timeout (ms) // Default: 15000 // <1-4294967295:1> // Default timeout in milliseconds of configuration client requests when communicating with an LPN node. // The BT Mesh Stack emits a configuration client event with SL_STATUS_TIMEOUT result if no reponse is received from configuration server. -#define BTMESH_CONF_LPN_REQUEST_TIMEOUT_MS 15000 +#define SL_BTMESH_CONF_LPN_REQUEST_TIMEOUT_MS_CFG_VAL 15000 -// Wait for event timeout (ms) +// Wait for event timeout (ms) // Default: 30000 // <1-4294967295:1> // Timeout in milliseconds to wait for configuration client events. -// It shall be greater than BTMESH_CONF_REQUEST_TIMEOUT_MS and BTMESH_CONF_LPN_REQUEST_TIMEOUT_MS. +// It shall be greater than SL_BTMESH_CONF_REQUEST_TIMEOUT_MS_CFG_VAL and SL_BTMESH_CONF_LPN_REQUEST_TIMEOUT_MS_CFG_VAL. // The BT Mesh Stack triggers configuration events if the configuration client request timeout occurs. // Wait for event timeout handles the extremely rare case of missing events. (e.g. too many events through NCP protocol) -#define BTMESH_CONF_EVENT_WAIT_TIMEOUT_MS 30000 +#define SL_BTMESH_CONF_EVENT_WAIT_TIMEOUT_MS_CFG_VAL 30000 -// Maximum number of request retry due to communication issues +// Maximum number of request retry due to communication issues // Default: 3 // <0-1000:1> // The maximum number of configuration request retry due to communication issues (BT Mesh Stack configuration request timeout). -#define BTMESH_CONF_COMMUNICATION_RETRY_MAX 3 +#define SL_BTMESH_CONF_COMMUNICATION_RETRY_MAX_CFG_VAL 3 -// Retry interval in case of busy configuration request (ms) +// Retry interval in case of busy configuration request (ms) // Default: 1000 // <1-4294967295:1> // Retry interval in milliseconds in case of busy configuration client requests. Config requests can be busy due to unavailable resources in BT Mesh Stack. -#define BTMESH_CONF_REQUEST_BUSY_RETRY_INTERVAL_MS 1000 +#define SL_BTMESH_CONF_REQUEST_BUSY_RETRY_INTERVAL_MS_CFG_VAL 1000 -// Maximum number of configuration request retry due to busy BT Mesh Stack +// Maximum number of configuration request retry due to busy BT Mesh Stack // Default: 10 // <0-10000:1> // The maximum number of configuration request retry because of rejected configuration request due to busy BT Mesh Stack. // The BT Mesh Stack might reject configuration client requests temporarily due to lack of resources. // For example maximum number of parallel segmented message transmissions is reached. -#define BTMESH_CONF_REQUEST_BUSY_RETRY_MAX 10 +#define SL_BTMESH_CONF_REQUEST_BUSY_RETRY_MAX_CFG_VAL 10 -// Configuration Job Auto Destroy +// Configuration Job Auto Destroy // Default: 1 // The default configuration job is deallocated automatically after the job status notification. // If auto destroy feature is turned off (0) then the job deallocation shall be performed manually (btmesh_conf_job_destroy) after job execution ends. -#define BTMESH_CONF_JOB_AUTO_DESTROY 1 +#define SL_BTMESH_CONF_JOB_AUTO_DESTROY_CFG_VAL 1 -// Configuration Job Auto Destroy on Submit failure +// Configuration Job Auto Destroy on Submit failure // Default: 1 // The default configuration job is deallocated automatically if the submit job operation is failed. // If auto destroy feature is turned off (0) then the job deallocation shall be performed manually (btmesh_conf_job_destroy) after submit operation fails. -#define BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE 1 +#define SL_BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE_CFG_VAL 1 // // <<< end of configuration section >>> -#if (0 == BTMESH_CONF_JOB_AUTO_DESTROY) \ - && (0 != BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE) +#if (0 == SL_BTMESH_CONF_JOB_AUTO_DESTROY_CFG_VAL) \ + && (0 != SL_BTMESH_CONF_JOB_AUTO_DESTROY_ON_SUBMIT_FAILURE_CFG_VAL) #error "If the auto destroy feature is turned off then the auto destroy on " \ "submit failure option shall be disabled as well." #endif -#if (BTMESH_CONF_EVENT_WAIT_TIMEOUT_MS <= BTMESH_CONF_REQUEST_TIMEOUT_MS) \ - || (BTMESH_CONF_EVENT_WAIT_TIMEOUT_MS <= BTMESH_CONF_LPN_REQUEST_TIMEOUT_MS) +#if (SL_BTMESH_CONF_EVENT_WAIT_TIMEOUT_MS_CFG_VAL <= SL_BTMESH_CONF_REQUEST_TIMEOUT_MS_CFG_VAL) \ + || (SL_BTMESH_CONF_EVENT_WAIT_TIMEOUT_MS_CFG_VAL <= SL_BTMESH_CONF_LPN_REQUEST_TIMEOUT_MS_CFG_VAL) #error "Wait for event timeout shall be greater than configuration client " \ "request timeout in the BT Mesh Stack." #endif diff --git a/app/bluetooth/common_host/host_comm/config/host_comm_config.h b/app/bluetooth/common_host/host_comm/config/host_comm_config.h index 04676d45d97..9f573fe01cc 100644 --- a/app/bluetooth/common_host/host_comm/config/host_comm_config.h +++ b/app/bluetooth/common_host/host_comm/config/host_comm_config.h @@ -44,6 +44,17 @@ // End Receive Thread Configuration +// Receive / Transmit buffer configuration + +// Buffer length +// Defines the size of the receive and transmit buffer for host +// Default: 2048 +#ifndef DEFAULT_HOST_BUFLEN +#define DEFAULT_HOST_BUFLEN 2048 +#endif + +// End Receive / Transmit buffer configuration + // <<< end of configuration section >>> #endif // HOST_COMM_CONFIG_H diff --git a/app/bluetooth/common_host/host_comm/host_comm.c b/app/bluetooth/common_host/host_comm/host_comm.c index 4018bface0e..a3c5870a270 100644 --- a/app/bluetooth/common_host/host_comm/host_comm.c +++ b/app/bluetooth/common_host/host_comm/host_comm.c @@ -55,7 +55,6 @@ #define DEFAUKT_TCP_ADDRESS "" #define DEFAULT_TCP_PORT "4901" #define MAX_OPT_LEN 255 -#define DEFAULT_HOST_BUFLEN 1024 #define IS_EMPTY_STRING(s) ((s)[0] == '\0') #define HANDLE_VALUE_MIN 0 @@ -271,6 +270,12 @@ void *msg_recv_func(void *ptr) // Peek is not supported, read data one by one len = 1; } + if (len > sizeof(buf_in.buf)) { + // If readable data exceeds the buffer size then + // read it one by one to avoid overflow + len = 1; + app_log_warning("Input buffer size too low, please increase it." APP_LOG_NL); + } if (len > 0) { memset(&buf_tmp, 0, sizeof(buf_tmp)); ret = host_comm_input(handle_ptr, len, buf_tmp.buf); diff --git a/app/bluetooth/common_host/mqtt/mqtt.c b/app/bluetooth/common_host/mqtt/mqtt.c index e536e2fff8d..6d3fa931e15 100644 --- a/app/bluetooth/common_host/mqtt/mqtt.c +++ b/app/bluetooth/common_host/mqtt/mqtt.c @@ -61,7 +61,7 @@ static const char * mqtt_err2str(int rc); static sl_status_t mqtt_add_topic(mqtt_handle_t *handle, const char *topic); static sl_status_t mqtt_remove_topic(mqtt_handle_t *handle, const char *topic); static sl_status_t mqtt_get_topic_by_index(mqtt_handle_t *handle, - uint8_t index, + uint32_t index, char **topic); static void mqtt_destroy_topics(mqtt_handle_t *handle); /**************************************************************************//** @@ -276,7 +276,7 @@ sl_status_t mqtt_deinit(mqtt_handle_t *handle) static void mqtt_on_connect(struct mosquitto *mosq, void *obj, int rc) { mqtt_handle_t *handle = (mqtt_handle_t *)obj; - uint8_t i = 0; + uint32_t i = 0; char *topic; int ret = MOSQ_ERR_SUCCESS; @@ -404,9 +404,9 @@ static void mqtt_destroy_topics(mqtt_handle_t *handle) handle->head_topic = NULL; } -static sl_status_t mqtt_get_topic_by_index(mqtt_handle_t *handle, uint8_t index, char **topic) +static sl_status_t mqtt_get_topic_by_index(mqtt_handle_t *handle, uint32_t index, char **topic) { - uint8_t i = 0; + uint32_t i = 0; mqtt_topic_node_t *current = handle->head_topic; if (NULL == handle->head_topic) { diff --git a/app/bluetooth/common_host/ncp_host/ncp_host.c b/app/bluetooth/common_host/ncp_host/ncp_host.c index acfd2e0a43f..e1317deb46e 100644 --- a/app/bluetooth/common_host/ncp_host/ncp_host.c +++ b/app/bluetooth/common_host/ncp_host/ncp_host.c @@ -34,10 +34,10 @@ #include "ncp_host.h" #include "app_sleep.h" #include "ncp_host_config.h" +#include "host_comm_config.h" // Default parameter values. #define MAX_OPT_LEN 255 -#define DEFAULT_NCP_HOST_BUFLEN 1024 #if PEEK_US_SLEEP == 0 #define MSG_RECV_TIMEOUT_COUNT 10000 @@ -61,7 +61,7 @@ // RX/TX buffer typedef struct { uint16_t len; - uint8_t buf[DEFAULT_NCP_HOST_BUFLEN]; + uint8_t buf[DEFAULT_HOST_BUFLEN]; } buf_ncp_host_t; static buf_ncp_host_t buf_ncp_raw = { 0 }; @@ -221,7 +221,7 @@ int32_t ncp_host_peek(void) } msg_len = buf_ncp_raw.buf[1] + 2; // Check if length will fit to buffer - if (msg_len >= DEFAULT_NCP_HOST_BUFLEN - 2) { + if (msg_len >= DEFAULT_HOST_BUFLEN - 2) { return -1; } ret = ncp_host_peek_timeout(msg_len, MSG_RECV_TIMEOUT_COUNT); @@ -260,7 +260,7 @@ int32_t ncp_host_peek(void) #if defined(SECURITY) && SECURITY == 1 void ncp_sec_host_command_handler(buf_ncp_host_t *buf) { - uint8_t response[DEFAULT_NCP_HOST_BUFLEN]; + uint8_t response[DEFAULT_HOST_BUFLEN]; sl_bt_msg_t *command = NULL; sl_bt_msg_t *resp_cmd = NULL; int32_t ret; diff --git a/app/bluetooth/component/gatt_configuration.slcc b/app/bluetooth/component/gatt_configuration.slcc index d0082a110e1..ad3f1c69187 100644 --- a/app/bluetooth/component/gatt_configuration.slcc +++ b/app/bluetooth/component/gatt_configuration.slcc @@ -1,7 +1,8 @@ id: "gatt_configuration" label: "Configuration" package: "Bluetooth" -description: "GATT Configuration" +description: > + Adds basic GATT Configuration to the project that can be customized with the GATT Configurator tool. category: "Bluetooth|GATT" quality: "production" root_path: "app/bluetooth/common/gatt_configuration" @@ -16,5 +17,3 @@ requires: template_contribution: - name: component_catalog value: gatt_configuration -ui_hints: - visibility: never diff --git a/app/bluetooth/component/gatt_service_aio.slcc b/app/bluetooth/component/gatt_service_aio.slcc index 4ce610878ff..57594d56764 100644 --- a/app/bluetooth/component/gatt_service_aio.slcc +++ b/app/bluetooth/component/gatt_service_aio.slcc @@ -12,18 +12,23 @@ config_file: directory: btconf source: - path: sl_gatt_service_aio.c + - path: sl_gatt_service_aio_digital_in.c + condition: + - simple_button + - path: sl_gatt_service_aio_digital_out.c + condition: + - simple_led include: - path: . file_list: - path: sl_gatt_service_aio.h + - path: sli_gatt_service_aio.h provides: - name: gatt_service_aio requires: - name: bluetooth_stack - name: gatt_configuration - name: bluetooth_feature_gatt_server - - name: simple_button - - name: simple_led - name: app_assert - name: app_log template_contribution: diff --git a/app/bluetooth/component/power_supply.slcc b/app/bluetooth/component/power_supply.slcc index d8c535f1dae..a24b51b7d41 100644 --- a/app/bluetooth/component/power_supply.slcc +++ b/app/bluetooth/component/power_supply.slcc @@ -14,6 +14,8 @@ include: provides: - name: power_supply requires: + - name: app_assert + - name: app_log - name: sensor_select - name: si70xx_driver - name: i2cspm diff --git a/app/bluetooth/component/sensor_gas.slcc b/app/bluetooth/component/sensor_gas.slcc index db715f2b6f5..76b46f41105 100644 --- a/app/bluetooth/component/sensor_gas.slcc +++ b/app/bluetooth/component/sensor_gas.slcc @@ -17,6 +17,7 @@ requires: - name: sensor_select - name: ccs811_driver - name: i2cspm + - name: app_assert template_contribution: - name: component_catalog value: sensor_gas diff --git a/app/bluetooth/component/sensor_hall.slcc b/app/bluetooth/component/sensor_hall.slcc index 45c548aa12e..98905ca1092 100644 --- a/app/bluetooth/component/sensor_hall.slcc +++ b/app/bluetooth/component/sensor_hall.slcc @@ -17,6 +17,7 @@ requires: - name: sensor_select - name: si7210_driver - name: i2cspm + - name: app_assert template_contribution: - name: component_catalog value: sensor_hall diff --git a/app/bluetooth/component/sensor_imu.slcc b/app/bluetooth/component/sensor_imu.slcc index 5a0f9d564ad..77477c8f015 100644 --- a/app/bluetooth/component/sensor_imu.slcc +++ b/app/bluetooth/component/sensor_imu.slcc @@ -15,6 +15,7 @@ provides: - name: sensor_imu requires: - name: imu_driver + - name: app_assert template_contribution: - name: component_catalog value: sensor_imu diff --git a/app/bluetooth/component/sensor_light.slcc b/app/bluetooth/component/sensor_light.slcc index 57b5fb8713e..6df11156ffa 100644 --- a/app/bluetooth/component/sensor_light.slcc +++ b/app/bluetooth/component/sensor_light.slcc @@ -21,6 +21,7 @@ requires: - name: sensor_select - name: si1133_driver - name: i2cspm + - name: app_assert template_contribution: - name: component_catalog value: sensor_light diff --git a/app/bluetooth/component/sensor_lux.slcc b/app/bluetooth/component/sensor_lux.slcc index f71a02f859b..baa125d48c6 100644 --- a/app/bluetooth/component/sensor_lux.slcc +++ b/app/bluetooth/component/sensor_lux.slcc @@ -20,6 +20,7 @@ requires: - name: sensor_select - name: veml6035_driver - name: i2cspm + - name: app_assert template_contribution: - name: component_catalog value: sensor_lux diff --git a/app/bluetooth/component/sensor_pressure.slcc b/app/bluetooth/component/sensor_pressure.slcc index 07c1348f906..2f0460c361a 100644 --- a/app/bluetooth/component/sensor_pressure.slcc +++ b/app/bluetooth/component/sensor_pressure.slcc @@ -7,6 +7,7 @@ quality: production root_path: app/bluetooth/common/sensor_pressure source: - path: sl_sensor_pressure.c + include: - path: . file_list: @@ -15,8 +16,9 @@ provides: - name: sensor_pressure requires: - name: sensor_select - - name: bmp280_driver + - name: pressure_driver - name: i2cspm + - name: app_assert template_contribution: - name: component_catalog value: sensor_pressure diff --git a/app/bluetooth/component/sensor_rht.slcc b/app/bluetooth/component/sensor_rht.slcc index 98f1be54468..391620118d6 100644 --- a/app/bluetooth/component/sensor_rht.slcc +++ b/app/bluetooth/component/sensor_rht.slcc @@ -20,6 +20,7 @@ requires: - name: sensor_select - name: si70xx_driver - name: i2cspm + - name: app_assert template_contribution: - name: component_catalog value: sensor_rht diff --git a/app/bluetooth/component/sensor_sound.slcc b/app/bluetooth/component/sensor_sound.slcc index a21acfe1ba8..d2ceedd9179 100644 --- a/app/bluetooth/component/sensor_sound.slcc +++ b/app/bluetooth/component/sensor_sound.slcc @@ -15,6 +15,8 @@ provides: - name: sensor_sound requires: - name: mic_driver + - name: app_assert + - name: sleeptimer template_contribution: - name: event_handler value: diff --git a/app/bluetooth/component/simple_timer_freertos.slcc b/app/bluetooth/component/simple_timer_freertos.slcc index 5c0b66e86cb..5097dd7378d 100644 --- a/app/bluetooth/component/simple_timer_freertos.slcc +++ b/app/bluetooth/component/simple_timer_freertos.slcc @@ -19,5 +19,9 @@ requires: template_contribution: - name: component_catalog value: simple_timer_freertos +validation_library: + - path: ../../../common/validation/autonumber_common.lua + name: autonumber_common validation_helper: - path: simple_timer_freertos_validation.lua + diff --git a/app/bluetooth/component/simple_timer_freertos_static.slcc b/app/bluetooth/component/simple_timer_freertos_static.slcc index a498182d1cd..a22e908bab1 100644 --- a/app/bluetooth/component/simple_timer_freertos_static.slcc +++ b/app/bluetooth/component/simple_timer_freertos_static.slcc @@ -18,5 +18,8 @@ requires: template_contribution: - name: component_catalog value: simple_timer_freertos_static +validation_library: + - path: ../../../common/validation/autonumber_common.lua + name: autonumber_common validation_helper: - path: simple_timer_freertos_static_validation.lua diff --git a/app/bluetooth/component/throughput_central.slcc b/app/bluetooth/component/throughput_central.slcc index 51bb59d0ef6..cc3ee901b74 100644 --- a/app/bluetooth/component/throughput_central.slcc +++ b/app/bluetooth/component/throughput_central.slcc @@ -331,5 +331,8 @@ template_contribution: help: "Read allowlist table" condition: - "cli" +validation_library: + - path: ../../../common/validation/autonumber_common.lua + name: autonumber_common validation_helper: - path: throughput_central_validation.lua diff --git a/app/bluetooth/component_host/ncp_host_btmesh.mk b/app/bluetooth/component_host/ncp_host_btmesh.mk index c118560456d..2b88e409a08 100644 --- a/app/bluetooth/component_host/ncp_host_btmesh.mk +++ b/app/bluetooth/component_host/ncp_host_btmesh.mk @@ -2,7 +2,17 @@ # NCP host component with threading for Bluetooth Mesh # ################################################################################ +# Threading is enabled by default. +# In case of an example handling a lot of data over UART, threaded usage +# might incur data loss or corruption. On the other hand, threaded UART +# handling use less CPU and is adequate for less data rate. +HOST_THREADING ?= 1 + +ifeq (1, ${HOST_THREADING}) include $(SDK_DIR)/app/bluetooth/component_host/ncp_host_bt.mk +else +include $(SDK_DIR)/app/bluetooth/component_host/ncp_host_nothread.mk +endif override C_SRC += \ $(SDK_DIR)/protocol/bluetooth/src/sl_btmesh_ncp_host.c \ diff --git a/app/bluetooth/documentation/btmesh-release-highlights.txt b/app/bluetooth/documentation/btmesh-release-highlights.txt index 75caa310393..ce0060855ae 100644 --- a/app/bluetooth/documentation/btmesh-release-highlights.txt +++ b/app/bluetooth/documentation/btmesh-release-highlights.txt @@ -1,8 +1,5 @@ -Bluetooth Mesh SDK 2.2.0.0 -* New example embedded Provisioner application -* NCP Commander support for Mesh -* Multiple improvements to the Mesh BGAPI -* Support for Amazon Bluetooth Mesh Simple Setup (BSS) +Bluetooth Mesh SDK 2.2.1.0 +- Selected quality improvements and bug fixes diff --git a/app/bluetooth/documentation/example/ncp/readme.html b/app/bluetooth/documentation/example/ncp/readme.html deleted file mode 100644 index 17edd390346..00000000000 --- a/app/bluetooth/documentation/example/ncp/readme.html +++ /dev/null @@ -1,613 +0,0 @@ - - - - - -readme - -
-

NCP

This application implements the Network Co-Processor (NCP) target firmware. It runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC.

This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. Use this example together with NCP host sample applications.

 

Getting Started

To get started with Silicon Labs Bluetooth software, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

In the NCP context, the application runs on a host MCU or PC, which is called the NCP Host, while the Bluetooth stack runs on an EFR32, which is called the NCP Target.

The NCP Host and Target communicates via a serial interface (UART). The communication between the NCP Host and Target is defined in the Silicon Labs proprietary protocol called BGAPI. BGLib is the reference implementation of the BGAPI protocol in C, which is to be used on the NCP Host side.

AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode provides a detailed description how NCP works and how to configure it for your custom hardware.

The following figures show the system view of NCP mode.

System View -System Block Diagram

 

Evaluating with NCP Commander

NCP Commander, which allows you to control the target without developing your own host application, is used to test the NCP firmware. In Simplicity Studio, browse to the launcher -> Compatible Tools tab -> open up NCP Commander. A shortcut to the Compatible Tools can also be found on the top toolbar. Follow the below steps to make the NCP target advertise.

  1. Connect your board to a PC via USB and start NCP Commander from Simplicity Studio. -step 1
  2. Choose your board from the list. Then, click "Connect". -step 2
  3. The NCP host will try to get the Bluetooth address from the NCP target. If it succeeds, the connection is established.
  4. Click on "Create Set" and then on "Start" button under "Advertise Set (0)" table to start advertising. See the "Smart Console" for details. -step 3 -step 3
  5. Open the EFR Connect or any Bluetooth browser application to see your device advertising (without any name). You may also connect to the device, although it does not have a GATT database to be discovered by default.

 

Extending the GATT database

This example project does not have a GATT database. It only has the Generic Attributer Service contained. The GATT database can be built with the APIs provided by the Dynamic GATT Configurator component. See the Bluetooth API reference manual section "GATT Database" for more details.

 

Troubleshooting

Note that NO Bootloader is included in any Software Example projects. However, they are configured so that they expect a bootloader to be present on the device. To get your application work, either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick-Start Guide

AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/ncp/readme.md b/app/bluetooth/documentation/example/ncp/readme.md new file mode 100644 index 00000000000..9e377ee775a --- /dev/null +++ b/app/bluetooth/documentation/example/ncp/readme.md @@ -0,0 +1,88 @@ +# NCP + +This application implements the Network Co-Processor (NCP) target firmware. It runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. + +This example does not have a GATT database, but makes it possible to build one from the application using Dynamic GATT API. Use this example together with NCP host sample applications. + + + + +## Getting Started + +To get started with Silicon Labs Bluetooth software, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +In the NCP context, the application runs on a host MCU or PC, which is called the NCP Host, while the Bluetooth stack runs on an EFR32, which is called the NCP Target. + +The NCP Host and Target communicates via a serial interface (UART). The communication between the NCP Host and Target is defined in the Silicon Labs proprietary protocol called BGAPI. BGLib is the reference implementation of the BGAPI protocol in C, which is to be used on the NCP Host side. + +[AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) provides a detailed description how NCP works and how to configure it for your custom hardware. + +The following figures show the system view of NCP mode. + +![System View](readme_img1.png) +![System Block Diagram](readme_img2.png) + + + +## Evaluating with NCP Commander + +NCP Commander, which allows you to control the target without developing your own host application, is used to test the NCP firmware. In Simplicity Studio, browse to the launcher -> Compatible Tools tab -> open up NCP Commander. A shortcut to the Compatible Tools can also be found on the top toolbar. Follow the below steps to make the NCP target advertise. + +1. Connect your board to a PC via USB and start NCP Commander from Simplicity Studio. +![step 1](readme_img3.png) +2. Choose your board from the list. Then, click "Connect". +![step 2](readme_img4.png) +3. The NCP host will try to get the Bluetooth address from the NCP target. If it succeeds, the connection is established. +4. Click on "Create Set" and then on "Start" button under "Advertise Set (0)" table to start advertising. See the "Smart Console" for details. + ![step 3](readme_img5.png) + ![step 3](readme_img7.png) + +5. Open the EFR Connect or any Bluetooth browser application to see your device advertising (without any name). You may also connect to the device, although it does not have a GATT database to be discovered by default. + + + +## Extending the GATT database + +This example project does not have a GATT database. It only has the Generic Attributer Service contained. The GATT database can be built with the APIs provided by the Dynamic GATT Configurator component. See the Bluetooth API reference manual section "GATT Database" for more details. + + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects. However, they are configured so that they expect a bootloader to be present on the device. To get your application work, either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/ncp_aoa_locator/readme.html b/app/bluetooth/documentation/example/ncp_aoa_locator/readme.html deleted file mode 100644 index af73497c2af..00000000000 --- a/app/bluetooth/documentation/example/ncp_aoa_locator/readme.html +++ /dev/null @@ -1,608 +0,0 @@ - - - - - -readme - -
-

NCP - AoA Locator

This is an NCP (Network Co-Processor) target sample app to be used together with the aoa_locator NCP host sample app. The NCP - AoA Locator NCP target and the aoa_locator NCP host sample apps together demonstrate a locator that can receive CTEs (Constant Tone Extensions) from asset tags and estimate their directions (AoA - Angle of Arrival).

Use this sample app together with SoC - AoA Asset Tag, which can transmit CTE signals.

 

Getting Started

To learn the basics of Bluetooth direction finding technology, see UG103.18: Bluetooth® Direction Finding Fundamentals.

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick-Start Guide.

To learn how an NCP (Network Co-Processor) setup works, see AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode. You should also test the NCP - Empty example first.

To get started with Silicon Labs' Direction Finding Solution, see QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide.

In an AoA direction finding use case, the tag acts as a transmitter and the locator acts as a receiver. The locator determines the direction of the tag by sampling the signal of the tag on different antennas of an antenna array and measuring phase differences.

Locators determine the direction of the tag by sampling different antennas

To estimate the direction of the incoming signal, the AoA Locator needs to receive a special Bluetooth packet, which has a Constant Tone Extension (CTE). CTEs can be transmitted in the following ways:

  • Via a Bluetooth connections (connection oriented mode)
  • In periodic advertisements (connectionless mode)
  • Attached to extended advertisements, which is not part of the Bluetooth standard, but is a Silicon Labs proprietary solution (Silicon Labs mode).

This sample app provides support for the following:

  • Requesting and receiving CTEs on connections
  • Receiving CTEs from periodic advertisements and Silicon Labs proprietary extended advertisements
  • Taking IQ samples on the received CTEs.

This way, the NCP host sample app can locate the asset tag by estimating the Angle of Arrival from the received IQ samples.

NCP - AoA Locator target can be run on antenna array boards only. aoa_locator host is typically run on PC or Raspberry Pi.

The whole setup looks like this:

AoA measurement setup

 

Testing the NCP - AoA Locator Application

After programming your antenna array board with the NCP - AoA Locator target sample app, program another board with an SoC - AoA Asset Tag sample app, and then start the AoA Analyzer tool as described in QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide.

 

Troubleshooting

Note that, when using NCP - AoA Locator you may need to change the flow control settings of the WSTK. Follow the instructions of AN1296: Application Development with Silicon Labs’ RTL Library.

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side), as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

UG103.18: Bluetooth® Direction Finding Fundamentals

QSG169: Bluetooth® SDK v3.x Quick-Start Guide

QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide

AN1296: Application Development with Silicon Labs’ RTL Library

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/ncp_aoa_locator/readme.md b/app/bluetooth/documentation/example/ncp_aoa_locator/readme.md new file mode 100644 index 00000000000..3082f9dcbd1 --- /dev/null +++ b/app/bluetooth/documentation/example/ncp_aoa_locator/readme.md @@ -0,0 +1,94 @@ +# NCP - AoA Locator + +This is an NCP (Network Co-Processor) target sample app to be used together with the **aoa_locator** NCP host sample app. The **NCP - AoA Locator** NCP target and the **aoa_locator** NCP host sample apps together demonstrate a locator that can receive CTEs (Constant Tone Extensions) from asset tags and estimate their directions (AoA - Angle of Arrival). + +Use this sample app together with **SoC - AoA Asset Tag**, which can transmit CTE signals. + + + +## Getting Started + +To learn the basics of Bluetooth direction finding technology, see [UG103.18: Bluetooth® Direction Finding Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-18-bluetooth-direction-finding-fundamentals.pdf). + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +To learn how an NCP (Network Co-Processor) setup works, see [AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf). You should also test the **NCP - Empty** example first. + +To get started with Silicon Labs' Direction Finding Solution, see [QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg175-direction-finding-solution-quick-start-guide.pdf). + +In an AoA direction finding use case, the tag acts as a transmitter and the locator acts as a receiver. The locator determines the direction of the tag by sampling the signal of the tag on different antennas of an antenna array and measuring phase differences. + +![Locators determine the direction of the tag by sampling different antennas](readme_img1.png) + +To estimate the direction of the incoming signal, the AoA Locator needs to receive a special Bluetooth packet, which has a Constant Tone Extension (CTE). CTEs can be transmitted in the following ways: + +* Via a Bluetooth connections (connection oriented mode) +* In periodic advertisements (connectionless mode) +* Attached to extended advertisements, which is not part of the Bluetooth standard, but is a Silicon Labs proprietary solution (Silicon Labs mode). + +This sample app provides support for the following: + +* Requesting and receiving CTEs on connections +* Receiving CTEs from periodic advertisements and Silicon Labs proprietary extended advertisements +* Taking IQ samples on the received CTEs. + +This way, the NCP host sample app can locate the asset tag by estimating the Angle of Arrival from the received IQ samples. + +**NCP - AoA Locator** target can be run on antenna array boards only. **aoa_locator** host is typically run on PC or Raspberry Pi. + +The whole setup looks like this: + +![AoA measurement setup](readme_img2.png) + + + +## Testing the NCP - AoA Locator Application + +After programming your antenna array board with the **NCP - AoA Locator** target sample app, program another board with an **SoC - AoA Asset Tag** sample app, and then start the **AoA Analyzer** tool as described in [QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg175-direction-finding-solution-quick-start-guide.pdf). + + + +## Troubleshooting + +Note that, when using **NCP - AoA Locator** you may need to change the flow control settings of the WSTK. Follow the instructions of [AN1296: Application Development with Silicon Labs’ RTL Library](https://www.silabs.com/documents/public/application-notes/an1296-application-development-with-rtl-library.pdf). + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side), as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[UG103.18: Bluetooth® Direction Finding Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-18-bluetooth-direction-finding-fundamentals.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg175-direction-finding-solution-quick-start-guide.pdf) + +[AN1296: Application Development with Silicon Labs’ RTL Library](https://www.silabs.com/documents/public/application-notes/an1296-application-development-with-rtl-library.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/ncp_btmesh_empty/readme.html b/app/bluetooth/documentation/example/ncp_btmesh_empty/readme.html deleted file mode 100644 index 3772593f199..00000000000 --- a/app/bluetooth/documentation/example/ncp_btmesh_empty/readme.html +++ /dev/null @@ -1,598 +0,0 @@ - - - - - -readme - -
-

Bluetooth Mesh - NCP Empty

At times design constraints drive the need to run the application on a separated host and have the Bluetooth stack running on a dedicated target. This configuration of the stack is called the Network Co-Processor (NCP) mode. NCP mode is illustrated here with the Bluetooth Mesh - NCP Empty sample application and NCP Commander used as a host application.

Bluetooth Mesh NCP target demonstrates the bare minimum needed for a Bluetooth mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. The example requires the BGAPI UART DFU Bootloader.

Getting Started

To get started with Silicon Labs Bluetooth software, see QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide.

In the NCP model the stack processing is done in a separate coprocessor (NCP Target) that interacts with the application’s microcontroller or PC (NCP Hosts) through an external serial interface, whereas in the SoC model the entire system (stack and application) resides on a single chip.

The NCP Host and Target communicate via a serial interface (UART) or, if a mainboard is used, optionally via TCP/IP connection. The communication between the NCP Host and Target is defined in the Silicon Labs proprietary protocol called BGAPI. BGLib is the C reference implementation of the BGAPI protocol, which is to be used on the NCP Host side.

AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network CoProcessor Mode provides a detailed description how NCP works and how to configure it for your custom hardware.

The following figures show the system view of NCP mode.

System View

System Block Diagram

First, launch Simplicity Studio 5 with the Bluetooth Mesh SDK installed and then run the Bluetooth Mesh - NCP Empty demo on the target as illustrated below:

step 1

If no pre-built demo is available for your radio board, then the example has to be created, built, and flashed along with a bootloader. See QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide for more information.

Evaluating with Bluetooth NCP Commander

NCP Commander can be used to control the target and test NCP firmware without developing your own host application. In Simplicity Studio, browse to the Launcher -> Compatible Tools tab and open NCP Commander. Follow these steps to make the NCP target advertise.

  1. Connect your board to a PC via USB and start NCP Commander from Simplicity Studio.

step 1

  1. Choose the port number through which your board is connected to the PC and set the baud rate accordingly. Then, click "open".

step 2

  1. The NCP host will try to get the Bluetooth address from the NCP target. If it succeeds, the serial connection is established.

step 2

  1. Upon connection to the NCP target, you must initialize the node in order to emit unprovisioned beacons and then be provisioned. To make sure the device starts from a clean state, do the factory reset to erase the NVM information as illustrated below using the sl_btmesh_node_reset() command:

step 3

  1. Once the node has been factory reseted, you can initialize the stack as a node by calling the initializing routine sl_btmesh_node_init(). In the API help menu, select the corresponding routine, copy it in the command field and send it. You can now see the device scanning. If you want to prevent the device scanning (as the display may be flooded with the scan response messages), you can also call sl_bt_user_manage_event_filter(00 A0 00 05 01) to block all the Bluetooth LE scan reports. This can be called even before the node initialization.

step 3

  1. Once the device stack is initialized as a node, you can start sending unprovisioned beacons. This can be done by calling the routine using the value 0x3 for both advertising and GATT bearers like this sl_btmesh_node_start_unprov_beaconing(0x3):

step 3

  1. Open the Silicon Labs Bluetooth Mesh application to see your device advertising as "Silabs Example". You may also connect to the device and discover its GATT database.

NCP Host examples

In addition to Bluetooth NCP Commander, Silicon Labs also provides NCP Host examples with source code.

A C project is in the SDK folder app/bluetooth/example_host/empty_btmesh

A pyBGAPI based Python project can be found in the SiliconLabs / pybgapi-examples GitHub repository.

For more information, see AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network CoProcessor Mode

Secure NCP

Secure NCP secures communication between the NCP Host and target by encrypting the commands, events, and any data transmitted between the target and the host.

Instructions for Secure NCP using ncp_daemon and empty_btmesh examples

Components for secure BGAPI communication

  1. ncp_daemon host example

    All security logic is handled by the security component on the host side.

  2. empty_btmesh host example

    Example host application for demonstrating BGAPI communication.

  3. ncp_btmesh_empty Target sample app

    NCP Target sample app

BGAPI security is implemented by encrypting the communication between NCP target and Host. To minimize the changes needed for the host application, the security is implemented in a separate component (NCP Daemon). The host application (empty_btmesh) runs in a separate task from the security component. This allows the different applications to easily access the secure NCP. All security logic is handled by this security component.

Prerequisites for setting up secure BGAPI communication:

  • You must have a POSIX/Mac, MSYS2 or Cygwin platform
  • You must have openssl-devel package installed

Steps for setting up secure BGAPI communication

  1. NCP – ncp_btmesh_empty Target Sample app must be programmed to the EFR32 chip

    • Connect your mainboard to the PC
    • Open Simplicity Studio (with Bt Mesh SDK installed)
    • Select ncp_btmesh_empty Target sample app from Demos to flash your EFR32 device
    • Add Secure-ncp component to the example, then build the example, and flash it to the EFR32 device

  2. Compile and start ncp_daemon in a new terminal

    • Open a new terminal (on POSIX/Mac: any terminal; on Windows: Cygwin or MSYS2; Please note: Mingw32/64 won't work)

    • Navigate to app/bluetooth/example_host/ncp_daemon in the Bt Mesh SDK

    • Build the sample app by typing 'make'

    • run the sample app with appropriate parameters (eg exe/ncp_daemon.exe /dev/ttyS13 115200 encrypted unencrypted)

      • 1st parameter: serial port
      • 2nd parameter: serial port speed
      • 3rd parameter: file descriptor for encrypted domain socket (it can be any string)
      • 4th parameter: file descriptor for unencrypted domain socket (it can be any string)

  3. Compile and start empty_btmesh in a new terminal

    • Open a new terminal (cygwin/msys2 terminal in Windows)

    • Navigate to app/bluetooth/example_host/empty_btmesh in the Bt Mesh SDK

    • Build the sample app by typing 'make'

    • run the sample app with appropriate parameters (eg ./exe/empty_btmesh.exe -n ../ncp_daemon/encrypted)

      • 1st parameter: -n connect to a named socket instead of connecting the standard UART/TCP
      • 2nd parameter: file descriptor for encrypted or unencrypted domain socket (it can be any string, but must match appropriate file descriptor string used in Step 2)

    • After running mesh-secure-ncp the 'Reset event' and the 'Node Initialized event' should arrive

    • Note that message encryption will happen in the ncp_daemon automatically by connecting to the encrypted socket.

Troubleshooting

Note that NO Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image.

  • The Bluetooth Mesh - SoC Switch demo includes an OTA DFU-capable bootloader.
  • The Bluetooth Mesh - NCP Empty demo includes a UART DFU-capable bootloader.
  • For other bootloader types, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103.6: Bootloader Fundamentals and UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

Resources

Bluetooth Documentation

Bluetooth Mesh Network - An Introduction for Developers

QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide

AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network CoProcessor Mode

Bluetooth Training

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/ncp_btmesh_empty/readme.md b/app/bluetooth/documentation/example/ncp_btmesh_empty/readme.md new file mode 100644 index 00000000000..8e0b2aa5512 --- /dev/null +++ b/app/bluetooth/documentation/example/ncp_btmesh_empty/readme.md @@ -0,0 +1,157 @@ +# Bluetooth Mesh - NCP Empty + +At times design constraints drive the need to run the application on a separated host and have the Bluetooth stack running on a dedicated target. This configuration of the stack is called the Network Co-Processor (NCP) mode. NCP mode is illustrated here with the **Bluetooth Mesh - NCP Empty** sample application and NCP Commander used as a host application. + +Bluetooth Mesh NCP target demonstrates the bare minimum needed for a Bluetooth mesh NCP Target C application, that makes it possible for the NCP Host Controller to access the Bluetooth mesh stack via UART. It provides access to the host layer via BGAPI and not to the link layer via HCI. The communication between the Host Controller and the target can be secured by installing the Secure NCP component. The example requires the BGAPI UART DFU Bootloader. + +## Getting Started + +To get started with Silicon Labs Bluetooth software, see [QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf). + +In the NCP model the stack processing is done in a separate coprocessor (NCP Target) that interacts with the application’s microcontroller or PC (NCP Hosts) through an external serial interface, whereas in the SoC model the entire system (stack and application) resides on a single chip. + +The NCP Host and Target communicate via a serial interface (UART) or, if a mainboard is used, optionally via TCP/IP connection. The communication between the NCP Host and Target is defined in the Silicon Labs proprietary protocol called BGAPI. BGLib is the C reference implementation of the BGAPI protocol, which is to be used on the NCP Host side. + +[AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network CoProcessor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) provides a detailed description how NCP works and how to configure it for your custom hardware. + +The following figures show the system view of NCP mode. + +![System View](readme_img0.png) + +![System Block Diagram](readme_img1.png) + +First, launch Simplicity Studio 5 with the Bluetooth Mesh SDK installed and then run the **Bluetooth Mesh - NCP Empty** demo on the target as illustrated below: + +![step 1](readme_img2.png) + +If no pre-built demo is available for your radio board, then the example has to be created, built, and flashed along with a bootloader. See [QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) for more information. + + +## Evaluating with Bluetooth NCP Commander + +NCP Commander can be used to control the target and test NCP firmware without developing your own host application. In Simplicity Studio, browse to the Launcher -> Compatible Tools tab and open NCP Commander. Follow these steps to make the NCP target advertise. + +1. Connect your board to a PC via USB and start NCP Commander from Simplicity Studio. + +![step 1](readme_img3.png) + +2. Choose the port number through which your board is connected to the PC and set the baud rate accordingly. Then, click "open". + +![step 2](readme_img4.png) + +3. The NCP host will try to get the Bluetooth address from the NCP target. If it succeeds, the serial connection is established. + +![step 2](readme_img5.png) + +4. Upon connection to the NCP target, you must initialize the node in order to emit unprovisioned beacons and then be provisioned. To make sure the device starts from a clean state, do the factory reset to erase the NVM information as illustrated below using the `sl_btmesh_node_reset()` command: + +![step 3](readme_img6.png) + +5. Once the node has been factory reseted, you can initialize the stack as a node by calling the initializing routine `sl_btmesh_node_init()`. In the API help menu, select the corresponding routine, copy it in the command field and send it. You can now see the device scanning. If you want to prevent the device scanning (as the display may be flooded with the scan response messages), you can also call `sl_bt_user_manage_event_filter(00 A0 00 05 01)` to block all the Bluetooth LE scan reports. This can be called even before the node initialization. + +![step 3](readme_img7.png) + +6. Once the device stack is initialized as a node, you can start sending unprovisioned beacons. This can be done by calling the routine using the value 0x3 for both advertising and GATT bearers like this `sl_btmesh_node_start_unprov_beaconing(0x3)`: + +![step 3](readme_img8.png) + +7. Open the Silicon Labs Bluetooth Mesh application to see your device advertising as "Silabs Example". You may also connect to the device and discover its GATT database. + +## NCP Host examples + +In addition to **Bluetooth NCP Commander**, Silicon Labs also provides NCP Host examples with source code. + +A C project is in the SDK folder `app/bluetooth/example_host/empty_btmesh` + +A pyBGAPI based Python project can be found in the [SiliconLabs / pybgapi-examples](https://github.com/SiliconLabs/pybgapi-examples) GitHub repository. + +For more information, see *[AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network CoProcessor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf)* + +## Secure NCP + +Secure NCP secures communication between the NCP Host and target by encrypting the commands, events, and any data transmitted between the target and the host. + +### Instructions for Secure NCP using ncp_daemon and empty_btmesh examples + +Components for secure BGAPI communication + +1. ncp_daemon host example + + All security logic is handled by the security component on the host side. + +2. empty_btmesh host example + + Example host application for demonstrating BGAPI communication. + +3. ncp_btmesh_empty Target sample app + + NCP Target sample app + +BGAPI security is implemented by encrypting the communication between NCP target and Host. To minimize the changes needed for the host application, the security is implemented in a separate component (NCP Daemon). The host application (empty_btmesh) runs in a separate task from the security component. This allows the different applications to easily access the secure NCP. All security logic is handled by this security component. + +Prerequisites for setting up secure BGAPI communication: + +- You must have a POSIX/Mac, MSYS2 or Cygwin platform +- You must have openssl-devel package installed + +Steps for setting up secure BGAPI communication + +1. NCP – ncp_btmesh_empty Target Sample app must be programmed to the EFR32 chip + + - Connect your mainboard to the PC + - Open Simplicity Studio (with Bt Mesh SDK installed) + - Select ncp_btmesh_empty Target sample app from Demos to flash your EFR32 device + - Add Secure-ncp component to the example, then build the example, and flash it to the EFR32 device + +2. Compile and start ncp_daemon in a new terminal + + - Open a new terminal (on POSIX/Mac: any terminal; on Windows: Cygwin or MSYS2; Please note: Mingw32/64 won't work) + - Navigate to app/bluetooth/example_host/ncp_daemon in the Bt Mesh SDK + - Build the sample app by typing 'make' + - run the sample app with appropriate parameters (eg exe/ncp_daemon.exe /dev/ttyS13 115200 encrypted unencrypted) + - 1st parameter: serial port + - 2nd parameter: serial port speed + - 3rd parameter: file descriptor for encrypted domain socket (it can be any string) + - 4th parameter: file descriptor for unencrypted domain socket (it can be any string) + +3. Compile and start empty_btmesh in a new terminal + + - Open a new terminal (cygwin/msys2 terminal in Windows) + - Navigate to app/bluetooth/example_host/empty_btmesh in the Bt Mesh SDK + - Build the sample app by typing 'make' + - run the sample app with appropriate parameters (eg ./exe/empty_btmesh.exe -n ../ncp_daemon/encrypted) + - 1st parameter: -n connect to a named socket instead of connecting the standard UART/TCP + - 2nd parameter: file descriptor for encrypted or unencrypted domain socket (it can be any string, but must match appropriate file descriptor string used in Step 2) + - After running mesh-secure-ncp the 'Reset event' and the 'Node Initialized event' should arrive + - Note that message encryption will happen in the ncp_daemon automatically by connecting to the encrypted socket. + +## Troubleshooting + +Note that **NO** Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image. + +- The **Bluetooth Mesh - SoC Switch** demo includes an OTA DFU-capable bootloader. +- The **Bluetooth Mesh - NCP Empty** demo includes a UART DFU-capable bootloader. +- For other bootloader types, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103.6: Bootloader Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher](https://www.silabs.com/documents/public/user-guides/ug489-gecko-bootloader-user-guide-gsdk-4.pdf)*. + +Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img9.png) + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf) + +[QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) + +[AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network CoProcessor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). diff --git a/app/bluetooth/documentation/example/ncp_empty/readme.html b/app/bluetooth/documentation/example/ncp_empty/readme.html deleted file mode 100644 index a6227f24d52..00000000000 --- a/app/bluetooth/documentation/example/ncp_empty/readme.html +++ /dev/null @@ -1,613 +0,0 @@ - - - - - -readme - -
-

NCP - Empty

This is a Network Co-Processor (NCP) target application. It runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC.

Unlike the Bluetooth - NCP sample app, this example contains a minimal GATT database. It can be used with Bluetooth NCP Commander, but it cannot be used with host applications that use Dynamic GATT API. Use the Bluetooth - NCP sample app instead, when testing NCP host sample applications, or remove the GATT database initialization part from the host sample application.

 

Getting Started

To get started with Silicon Labs Bluetooth software, see QSG169: Bluetooth® SDK v3.x Quick-Start Guide.

In the NCP context, the application runs on a host MCU or PC, which is called the NCP Host, while the Bluetooth stack runs on an EFR32, which is called the NCP Target.

The NCP Host and Target communicates via a serial interface (UART). The communication between the NCP Host and Target is defined in the Silicon Labs proprietary protocol called BGAPI. BGLib is the reference implementation of the BGAPI protocol in C, which is to be used on the NCP Host side.

AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode provides a detailed description how NCP works and how to configure it for your custom hardware.

The following figures show the system view of NCP mode.

System View -System Block Diagram

 

Evaluating with NCP Commander

NCP Commander, which allows you to control the target without developing your own host application, is used to test the NCP firmware. In Simplicity Studio, browse to the launcher -> Compatible Tools tab -> open up NCP Commander. A shortcut to the Compatible Tools can also be found on the top toolbar. Follow the below steps to make the NCP target advertise.

  1. Connect your board to a PC via USB and start NCP Commander from Simplicity Studio. -step 1
  2. Choose your board from the list. Then, click "Connect". -step 2
  3. The NCP host will try to get the Bluetooth address from the NCP target. If it succeeds, the connection is established.
  4. Click on "Create Set" and then on "Start" button under "Advertise Set (0)" table to start advertising. See the "Smart Console" for details. -step 3 -step 3
  5. Open the EFR Connect or any Bluetooth browser application to see your device advertising as "Silabs Example". You may also connect to the device and discover its GATT database.

 

Extending the GATT database

The NCP-empty application implements a basic GATT database. GATT definitions can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator. To open the Project Configurator, open the .slcp file of the project.

Opening GATT Configurator

To learn how to use the GATT Configurator, see UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x.

The other NCP target example project "Bluetooth - NCP" does not have a GATT database. It uses APIs to build up the database at runtime, which is preferred for NCP projects. With the Dynamic GATT Database solution, the target application does not need to be changed and synchronized with the Host part when the GATT Database is modified. If you still insist to use the GATT configurator, please remove the GATT database initialization from the host sample application.

 

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick-Start Guide

AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/ncp_empty/readme.md b/app/bluetooth/documentation/example/ncp_empty/readme.md new file mode 100644 index 00000000000..7a6691d43f6 --- /dev/null +++ b/app/bluetooth/documentation/example/ncp_empty/readme.md @@ -0,0 +1,92 @@ +# NCP - Empty + +This is a Network Co-Processor (NCP) target application. It runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. + +Unlike the Bluetooth - NCP sample app, this example contains a minimal GATT database. It can be used with Bluetooth NCP Commander, but it cannot be used with host applications that use Dynamic GATT API. Use the Bluetooth - NCP sample app instead, when testing NCP host sample applications, or remove the GATT database initialization part from the host sample application. + + + +## Getting Started + +To get started with Silicon Labs Bluetooth software, see [QSG169: Bluetooth® SDK v3.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +In the NCP context, the application runs on a host MCU or PC, which is called the NCP Host, while the Bluetooth stack runs on an EFR32, which is called the NCP Target. + +The NCP Host and Target communicates via a serial interface (UART). The communication between the NCP Host and Target is defined in the Silicon Labs proprietary protocol called BGAPI. BGLib is the reference implementation of the BGAPI protocol in C, which is to be used on the NCP Host side. + +[AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) provides a detailed description how NCP works and how to configure it for your custom hardware. + +The following figures show the system view of NCP mode. + +![System View](readme_img1.png) +![System Block Diagram](readme_img2.png) + + + +## Evaluating with NCP Commander + +NCP Commander, which allows you to control the target without developing your own host application, is used to test the NCP firmware. In Simplicity Studio, browse to the launcher -> Compatible Tools tab -> open up NCP Commander. A shortcut to the Compatible Tools can also be found on the top toolbar. Follow the below steps to make the NCP target advertise. + +1. Connect your board to a PC via USB and start NCP Commander from Simplicity Studio. +![step 1](readme_img3.png) +2. Choose your board from the list. Then, click "Connect". +![step 2](readme_img4.png) +3. The NCP host will try to get the Bluetooth address from the NCP target. If it succeeds, the connection is established. +4. Click on "Create Set" and then on "Start" button under "Advertise Set (0)" table to start advertising. See the "Smart Console" for details. + ![step 3](readme_img5.png) + ![step 3](readme_img7.png) + +5. Open the EFR Connect or any Bluetooth browser application to see your device advertising as "Silabs Example". You may also connect to the device and discover its GATT database. + + + +## Extending the GATT database + +The NCP-empty application implements a basic GATT database. GATT definitions can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator. To open the Project Configurator, open the .slcp file of the project. + +![Opening GATT Configurator](readme_img6.png) + +To learn how to use the GATT Configurator, see [UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug438-gatt-configurator-users-guide-sdk-v3x.pdf). + +The other NCP target example project "Bluetooth - NCP" does not have a GATT database. It uses APIs to build up the database at runtime, which is preferred for NCP projects. With the Dynamic GATT Database solution, the target application does not need to be changed and synchronized with the Host part when the GATT Database is modified. If you still insist to use the GATT configurator, please remove the GATT database initialization from the host sample application. + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/ncp_host/readme.html b/app/bluetooth/documentation/example/ncp_host/readme.html deleted file mode 100644 index e6268080644..00000000000 --- a/app/bluetooth/documentation/example/ncp_host/readme.html +++ /dev/null @@ -1,608 +0,0 @@ - - - - - -readme - -
-

NCP - Host

This sample application is a reference implementation of an NCP (Network Co-Processor) host, which is typically run on a central MCU without radio. It can connect to an NCP target via UART to access the Bluetooth stack of the target and to control it using BGAPI.

This example uses the Dynamic GATT feature, and it must be used together with the Bluetooth - NCP target app.

 

Getting Started

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick-Start Guide.

In the NCP context, the application runs on a host MCU or PC, the NCP host, while the Bluetooth stack runs on an EFR32, the NCP target. This sample application demonstrates an NCP host implementation. Although it is written for an EFR32 device, it can be ported to other MCUs.

The NCP host and target communicate via a serial interface (UART). The communication between the NCP host and target is defined in the Silicon Labs proprietary protocol called BGAPI. BGLib is the reference implementation of the BGAPI protocol in C, to be used on the NCP Host side.

AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode provides a detailed description how NCP works and how to configure it for your custom hardware.

The following figure shows the system view of NCP mode:

System Block Diagram

 

Setting Up

Use this sample application with an NCP target application that is run on another WSTK.

  1. Build the NCP - Host project and flash it to the WSTK.

  2. Create the NCP target firmware for another WSTK on which you want to run the Bluetooth stack

    1. Create a new Bluetooth - NCP example project
    2. In the project configurator find the UARTDRV USART software component
    3. Add a new instance with the name 'exp'. This will root the UART pins to the EXP header of the WSTK instead of vcom
    4. Remove the 'vcom' instance
    5. Find the Board Control software component
    6. In the configuration of the Board Control software component disable Virtual COM UART
    7. Build and flash the project to the target WSTK

  3. For UART communication, the TX and RX pins of the host WSTK need to be connected to the RX and TX pins of the target WSTK, respectively. Make sure the following connections are established:

    • TX pin (number 12 on the expansion header of the WSTK) of the host is connected to the RX pin (number 14 on the expansion header of the WSTK) of the target.
    • RX pin (number 14 on the expansion header of the WSTK) of the host is connected to the TX pin (number 12 on the expansion header of the WSTK) of the target.
    • VMCU pin (number 2 on the expansion header of the WSTK) of the host is connected to the VMCU pin (number 2 on the expansion header of the WSTK) of the target.
    • GND pin (number 1 on the expansion header of the WSTK) of the host is connected to the GND pin (number 1 on the expansion header of the WSTK) of the target.

    Connecting the Host and Target WSTKs

  1. On the host, set the power supply switch into AEM position (the kit is powered via USB). On the target, set the power supply switch into BAT position. The red rectangles on the previous image show the position of the power supply switches on the host and the target. The VMCU and GND pins are used to power up the NCP target.
  2. Power your NCP host via USB. Your NCP host will receive the boot event from the NCP target. The host will send an advertiser_start command to the target. As a result, you should see your NCP target device advertising itself as a Silicon Labs Example.

 

Extending the Host Code

The Bluetooth event handler in app.c of the NCP host project works the same way as the Bluetooth event handler in app.c of any SoC project. The difference is in the background whereby the NCP host project sends the command to the target device, while SoC projects execute the command on the SoC device.

 

Extending the GATT Database

The Host can build up the GATT Database on the Target in runtime with the APIs provided by the Dynamic GATT Database component.

The Dynamic GATT Database APIs can be used for :

  • Adding / Removing services, characteristics and descriptors
  • Modifying service, characteristic and descriptor properties
  • Maintaining a polymorphic GATT, the database can be updated in any time

This example demonstrates the building of a minimal GATT database. This can be extended by adding further services using the dynamic GATT API.

See the Bluetooth API reference manual section "GATT Database" for more details.

 

Troubleshooting

Note that NO Bootloader is included in any Software Example project. However, when a precompiled demo is flashed, both bootloader and application images are loaded onto the device.

  • To flash an example which doesn't have a corresponding prebuilt demo, SoC-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.s

Radio Board Power Supply Switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick-Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/ncp_host/readme.md b/app/bluetooth/documentation/example/ncp_host/readme.md new file mode 100644 index 00000000000..33f256e0ff9 --- /dev/null +++ b/app/bluetooth/documentation/example/ncp_host/readme.md @@ -0,0 +1,114 @@ +# NCP - Host + +This sample application is a reference implementation of an NCP (Network Co-Processor) host, which is typically run on a central MCU without radio. It can connect to an NCP target via UART to access the Bluetooth stack of the target and to control it using BGAPI. + +This example uses the Dynamic GATT feature, and it must be used together with the **Bluetooth - NCP** target app. + + + +## Getting Started + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +In the NCP context, the application runs on a host MCU or PC, the **NCP host**, while the Bluetooth stack runs on an EFR32, the **NCP target**. This sample application demonstrates an NCP host implementation. Although it is written for an EFR32 device, it can be ported to other MCUs. + +The NCP host and target communicate via a serial interface (UART). The communication between the NCP host and target is defined in the Silicon Labs proprietary protocol called BGAPI. BGLib is the reference implementation of the BGAPI protocol in C, to be used on the NCP Host side. + +[AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) provides a detailed description how NCP works and how to configure it for your custom hardware. + +The following figure shows the system view of NCP mode: + +![System Block Diagram](readme_img1.png) + + + +## Setting Up + +Use this sample application with an NCP target application that is run on another WSTK. + +1. Build the NCP - Host project and flash it to the WSTK. + +2. Create the NCP target firmware for another WSTK on which you want to run the Bluetooth stack + + 1. Create a new Bluetooth - NCP example project + 2. In the project configurator find the UARTDRV USART software component + 3. Add a new instance with the name 'exp'. This will root the UART pins to the EXP header of the WSTK instead of vcom + 4. Remove the 'vcom' instance + 5. Find the Board Control software component + 6. In the configuration of the Board Control software component disable Virtual COM UART + 7. Build and flash the project to the target WSTK + +3. For UART communication, the TX and RX pins of the host WSTK need to be connected to the RX and TX pins of the target WSTK, respectively. Make sure the following connections are established: + + - *TX* pin (number 12 on the expansion header of the WSTK) of the host is connected to the *RX* pin (number 14 on the expansion header of the WSTK) of the target. + + - *RX* pin (number 14 on the expansion header of the WSTK) of the host is connected to the *TX* pin (number 12 on the expansion header of the WSTK) of the target. + + - *VMCU* pin (number 2 on the expansion header of the WSTK) of the host is connected to the *VMCU* pin (number 2 on the expansion header of the WSTK) of the target. + + - *GND* pin (number 1 on the expansion header of the WSTK) of the host is connected to the *GND* pin (number 1 on the expansion header of the WSTK) of the target. + + ![Connecting the Host and Target WSTKs](readme_img2.png) + + +4. On the host, set the power supply switch into *AEM* position (the kit is powered via USB). On the target, set the power supply switch into *BAT* position. The red rectangles on the previous image show the position of the power supply switches on the host and the target. The VMCU and GND pins are used to power up the NCP target. + +5. Power your NCP host via USB. Your NCP host will receive the boot event from the NCP target. The host will send an advertiser_start command to the target. As a result, you should see your NCP target device advertising itself as a Silicon Labs Example. + + + +## Extending the Host Code + +The Bluetooth event handler in app.c of the NCP host project works the same way as the Bluetooth event handler in app.c of any SoC project. The difference is in the background whereby the NCP host project sends the command to the target device, while SoC projects execute the command on the SoC device. + + + +## Extending the GATT Database + +The Host can build up the GATT Database on the Target in runtime with the APIs provided by the Dynamic GATT Database component. + +The Dynamic GATT Database APIs can be used for : + +- Adding / Removing services, characteristics and descriptors +- Modifying service, characteristic and descriptor properties +- Maintaining a polymorphic GATT, the database can be updated in any time + +This example demonstrates the building of a minimal GATT database. This can be extended by adding further services using the dynamic GATT API. + +See the Bluetooth API reference manual section "GATT Database" for more details. + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example project. However, when a precompiled demo is flashed, both bootloader and application images are loaded onto the device. + +- To flash an example which doesn't have a corresponding prebuilt demo, *SoC-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.s + +![Radio Board Power Supply Switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/rcp/readme.html b/app/bluetooth/documentation/example/rcp/readme.html deleted file mode 100644 index fd44579aaa8..00000000000 --- a/app/bluetooth/documentation/example/rcp/readme.html +++ /dev/null @@ -1,608 +0,0 @@ - - - - - -readme - -
-

RCP

The RCP (Radio Communication Protocol) sample application runs the Bluetooth Controller (radio + Link Layer) and implements the controller part of the HCI, as defined in the Bluetooth Core Specification, Vol 4: Host Controller Interface. The HCI is a standardized way for Bluetooth host and controller to communicate with each other. Because the interface is standard, the host and controller can be from different vendors. Currently, Silicon Labs Bluetooth Controller supports UART (Universal Asynchronous Receiver-Transmitter) as the HCI transport layer.

Getting Started

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

HCI Protocol

HCI layer provides set of commands and events and ACL data packets. The Host sends commands to the controller. The commands are used to start advertising or scanning, establish connection to another Bluetooth device, read status information from the controller, and so on.

Events are sent from the Controller side to the Host. Events are used as a response to commands or to indicate various events in the controller such as scanning reports, connection establishment or closing, and various failures.

Silicon Labs Bluetooth LE Controller runs on EFR32 Radio Co-Processors. External Bluetooth Host stacks communicates with the controller over the HCI, also called RCP mode. See the following figure.

For more details, see AN1328: Enabling a Radio Co-Processor using the Bluetooth HCI Function

Supported Modes

ACL (Asynchronous Connection Less) data packets deliver user application data between the host and the controller in both directions.

Silicon Labs Bluetooth LE Controller does not support SCO (Synchronous Connection Oriented) and ISOC (Isochronous Channels) modes. Also, the related HCI messages are not supported.

Bluetooth specification defines Low Energy (LE), BR/EDR (classic) and AMP (alternate MAC and PHY) controllers. Note that Silicon Labs only supports the LE controller.

Communication Interface

The application uses UART as the HCI Transport layer. By default, UART is configured as follows:

  • Hardware flow control: disabled
  • Speed: 115200 kbps
  • Data bits: 8
  • Parity bit: N
  • Stop bits: 1

The default configuration can be changed with the vcom component. For more details about the customization of the project, see AN1328.

Usage

Because HCI is a standardized interface, it can be used with any Host which implements the HCI via UART. For example, it can be used with the BlueZ stack included in Linux systems. Connect your device flashed with the RCP firmware to your system. Then, attach it as a HCI device with the command btattach:

Now, it can be controlled with any tool which uses HCI commands, e.g. bluetoothctl :

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but it is configured in such a way that they expect a bootloader to be on the device. To ensure your application works, either:

  • Flash a bootloader to the device or
  • Uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, flash the SoC-Thermometer demo before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, flash the NCP-Empty demo before your application to load the bootloader.
  • For a custom application, create a custom bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/rcp/readme.md b/app/bluetooth/documentation/example/rcp/readme.md new file mode 100644 index 00000000000..fcf0c16fd2e --- /dev/null +++ b/app/bluetooth/documentation/example/rcp/readme.md @@ -0,0 +1,90 @@ +# RCP + +The RCP (Radio Co-Processor)) sample application runs the Bluetooth Controller (radio + Link Layer) and implements the controller part of the HCI, as defined in the *Bluetooth Core Specification, Vol 4: Host Controller Interface*. The HCI is a standardized way for Bluetooth host and controller to communicate with each other. Because the interface is standard, the host and controller can be from different vendors. Currently, Silicon Labs Bluetooth Controller supports UART (Universal Asynchronous Receiver-Transmitter) as the HCI transport layer. + +## Getting Started + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +## HCI Protocol + +HCI layer provides set of commands and events and ACL data packets. The Host sends commands to the controller. The commands are used to start advertising or scanning, establish connection to another Bluetooth device, read status information from the controller, and so on. + +Events are sent from the Controller side to the Host. Events are used as a response to commands or to indicate various events in the controller such as scanning reports, connection establishment or closing, and various failures. + +Silicon Labs Bluetooth LE Controller runs on EFR32 Radio Co-Processors. External Bluetooth Host stacks communicates with the controller over the HCI, also called RCP mode. See the following figure. + +![](readme_img1.png) + +For more details, see [AN1328: Enabling a Radio Co-Processor using the Bluetooth HCI Function](https://www.silabs.com/documents/public/application-notes/an1328-enabling-rcp-using-bt-hci.pdf) + +## Supported Modes + +ACL (Asynchronous Connection Less) data packets deliver user application data between the host and the controller in both directions. + +Silicon Labs Bluetooth LE Controller does not support SCO (Synchronous Connection Oriented) and ISOC (Isochronous Channels) modes. Also, the related HCI messages are not supported. + +Bluetooth specification defines Low Energy (LE), BR/EDR (classic) and AMP (alternate MAC and PHY) controllers. Note that Silicon Labs only supports the LE controller. + +## Communication Interface + +The application uses UART as the HCI Transport layer. By default, UART is configured as follows: + - Hardware flow control: disabled + - Speed: 115200 kbps + - Data bits: 8 + - Parity bit: N + - Stop bits: 1 + +The default configuration can be changed with the **vcom** component. For more details about the customization of the project, see AN1328. + +## Usage + +Because HCI is a standardized interface, it can be used with any Host which implements the HCI via UART. For example, it can be used with the BlueZ stack included in Linux systems. Connect your device flashed with the RCP firmware to your system. Then, attach it as a HCI device with the command *btattach*: + +![](readme_img2.png) + +Now, it can be controlled with any tool which uses HCI commands, e.g. *bluetoothctl* : + +![](readme_img3.png) + +![](readme_img4.png) + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but it is configured in such a way that they expect a bootloader to be on the device. To ensure your application works, either: +- Flash a bootloader to the device or +- Uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, flash the *SoC-Thermometer* demo before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, flash the *NCP-Empty* demo before your application to load the bootloader. +- For a custom application, create a custom bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/rcp_cpc/readme.md b/app/bluetooth/documentation/example/rcp_cpc/readme.md new file mode 100644 index 00000000000..d6e17f4045c --- /dev/null +++ b/app/bluetooth/documentation/example/rcp_cpc/readme.md @@ -0,0 +1,84 @@ +# RCP CPC + +The RCP (Radio Co-Processor) sample application runs the Bluetooth Controller (radio + Link Layer) and implements the controller part of the HCI, as defined in the *Bluetooth Core Specification, Vol 4: Host Controller Interface*. The HCI is a standardized way for Bluetooth host and controller to communicate with each other. Because the interface is standard, the host and controller can be from different vendors. Currently, Silicon Labs Bluetooth Controller supports UART (Universal Asynchronous Receiver-Transmitter) as the HCI transport layer. In this project Silicon Labs’ proprietary CPC (Co-Processor Communication) protocol is used as the transport protocol over UART. + + + +## Getting Started + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + + + +## HCI Protocol + +HCI layer provides set of commands and events and ACL data packets. The Host sends commands to the controller. The commands are used to start advertising or scanning, establish connection to another Bluetooth device, read status information from the controller, and so on. + +Events are sent from the Controller side to the Host. Events are used as a response to commands or to indicate various events in the controller such as scanning reports, connection establishment or closing, and various failures. + +Silicon Labs Bluetooth LE Controller runs on EFR32 Radio Co-Processors. External Bluetooth Host stacks communicates with the controller over the HCI, also called RCP mode. See the following figure. + +![](readme_img1.png) + +For more details, see [AN1328: Enabling a Radio Co-Processor using the Bluetooth HCI Function](https://www.silabs.com/documents/public/application-notes/an1328-enabling-rcp-using-bt-hci.pdf) + + + +## Supported Modes + +ACL (Asynchronous Connection Less) data packets deliver user application data between the host and the controller in both directions. + +Silicon Labs Bluetooth LE Controller does not support SCO (Synchronous Connection Oriented) and ISOC (Isochronous Channels) modes. Also, the related HCI messages are not supported. + +Bluetooth specification defines Low Energy (LE), BR/EDR (classic) and AMP (alternate MAC and PHY) controllers. Note that Silicon Labs only supports the LE controller. + + + +## Communication Interface + +This project uses Silicon Labs’ proprietary CPC (Co-Processor Communication) protocol as the transport protocol over UART. This is useful in DMP (Dynamic Multi-protocol) use cases, when the host device communicates with multiple protocol stacks running on the Radio Co-Processor, but it may be also useful if you need a robust and secure transport protocol. See the following figure for an overview: + +![](readme_img2.png) + +For more information on CPC please refer to [AN1351: Using the Co-Processor Communication Daemon (CPCd)](https://www.silabs.com/documents/public/application-notes/an1351-using-co-processor-communication_daemon.pdf). To learn more about the DMP use case, see [AN1333: Running Zigbee, OpenThread, and Bluetooth Concurrently on a Linux Host with a Multiprotocol RCP](https://www.silabs.com/documents/public/application-notes/an1333-concurrent-protocols-with-802-15-4-rcp.pdf). + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but it is configured in such a way that they expect a bootloader to be on the device. To ensure your application works, either: +- Flash a bootloader to the device or +- Uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, flash the *SoC-Thermometer* demo before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, flash the *NCP-Empty* demo before your application to load the bootloader. +- For a custom application, create a custom bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/rcp_cpc/readme_img0.png b/app/bluetooth/documentation/example/rcp_cpc/readme_img0.png new file mode 100644 index 00000000000..dbbd2a8004d --- /dev/null +++ b/app/bluetooth/documentation/example/rcp_cpc/readme_img0.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:5e4d4f007d6c9dcc867f438330840be39c1be546c24123f9fab5d9533d079380 +size 44396 diff --git a/app/bluetooth/documentation/example/rcp_cpc/readme_img1.png b/app/bluetooth/documentation/example/rcp_cpc/readme_img1.png new file mode 100644 index 00000000000..7f687148990 --- /dev/null +++ b/app/bluetooth/documentation/example/rcp_cpc/readme_img1.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:93c7d87fd4185507128db05b864fcb0db64a21b9a99d79ead487b4d29dcc318d +size 57633 diff --git a/app/bluetooth/documentation/example/rcp_cpc/readme_img2.png b/app/bluetooth/documentation/example/rcp_cpc/readme_img2.png new file mode 100644 index 00000000000..4d3e102d6b8 --- /dev/null +++ b/app/bluetooth/documentation/example/rcp_cpc/readme_img2.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:8fd7c49d12bf8e7cbd5bdd6e892182a3de834090c0885005d299dc9807e4e9d2 +size 63383 diff --git a/app/bluetooth/documentation/example/soc_aoa_asset_tag/readme.html b/app/bluetooth/documentation/example/soc_aoa_asset_tag/readme.html deleted file mode 100644 index 8f2f804202f..00000000000 --- a/app/bluetooth/documentation/example/soc_aoa_asset_tag/readme.html +++ /dev/null @@ -1,553 +0,0 @@ - - - - -readme - - -

SoC - AoA Asset Tag

This sample app demonstrates a CTE (Constant Tone Extension) transmitter that can be used as an asset tag in a direction finding setup estimating Angle of Arrival (AoA). Test this sample app with NCP - AoA Locator which (used together with the aoa_locator host applications) can estimate the direction of the asset tag.

 

Getting Started

To learn the basics of Bluetooth direction finding technology , see UG103.18: Bluetooth® Direction Finding Fundamentals.

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

To get started with Silicon Labs' Direction Finding Solution, see QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide

In an AoA direction finding use case the tag acts as a transmitter and the locator acts as a receiver. The locator determines the direction of the tag by sampling the signal of the tag on different antennas of an antenna array and measuring phase differences.

Locators determine the direction of the tag by sampling different antennas

To estimate the direction of the incoming signal the AoA - Locator needs to receive a special Bluetooth packet, which has a Constant Tone Extension (CTE). CTEs can be transmitted:

  • via a Bluetooth connections (connection oriented mode),
  • in periodic advertisements (connectionless mode),
  • attached to extended advertisements, which is however not part of the Bluetooth standard, but is a Silicon Labs proprietary solution (Silabs mode).

This sample app:

  • transmits connectable advertisements, and makes it possible to enable CTE on the established connections
  • transmits Silicon Labs proprietary extended advertisements with CTE to let multiple locators receive the same signal

This makes it possible for locators to locate the asset tag.

 

Configuring the CTE Transmit Method

By default the asset tag is connectable, and CTEs can be enabled and requested via a connection. Additionally, Silicon Labs proprietary non-connectable extended advertisements with CTE are also sent out periodically, so that (multiple) locators can locate the tag without connecting to it. These features are enabled by the installed Constant Tone Extension GATT Service (Connection) and Constant Tone Extension GATT Service (Silabs proprietary) software components

CTE related software components

To transmit standard periodic advertisements instead of Silicon Labs proprietary extended advertisements, uninstall the Constant Tone Extension GATT Service (Silabs proprietary) and install the Constant Tone Extension GATT Service (Connectionless) software component in the Project Configurator.

 

Testing the SoC - AoA Asset Tag Application

AoA Asset Tag can be tested together with an AoA Locator. After programming your board with the SoC - AoA Asset Tag sample app, please attach an antenna array board, as well, create an NCP - AoA Locator sample app, and then follow the instructions documented in AN1296: Application Development with Silicon Labs’ RTL Library.

 

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side), as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

UG103.18: Bluetooth® Direction Finding Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide

AN1296: Application Development with Silicon Labs’ RTL Library

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_aoa_asset_tag/readme.md b/app/bluetooth/documentation/example/soc_aoa_asset_tag/readme.md new file mode 100644 index 00000000000..93f5775caa7 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_aoa_asset_tag/readme.md @@ -0,0 +1,91 @@ +# SoC - AoA Asset Tag + +This sample app demonstrates a CTE (Constant Tone Extension) transmitter that can be used as an asset tag in a direction finding setup estimating Angle of Arrival (AoA). Test this sample app with **NCP - AoA Locator** which (used together with the **aoa_locator host** applications) can estimate the direction of the asset tag. + + + +## Getting Started + +To learn the basics of Bluetooth direction finding technology , see [UG103.18: Bluetooth® Direction Finding Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-18-bluetooth-direction-finding-fundamentals.pdf). + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +To get started with Silicon Labs' Direction Finding Solution, see [QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg175-direction-finding-solution-quick-start-guide.pdf) + +In an AoA direction finding use case the tag acts as a transmitter and the locator acts as a receiver. The locator determines the direction of the tag by sampling the signal of the tag on different antennas of an antenna array and measuring phase differences. + +![Locators determine the direction of the tag by sampling different antennas](readme_img1.png) + +To estimate the direction of the incoming signal the AoA - Locator needs to receive a special Bluetooth packet, which has a Constant Tone Extension (CTE). CTEs can be transmitted: + +* via a Bluetooth connections (connection oriented mode), +* in periodic advertisements (connectionless mode), +* attached to extended advertisements, which is however not part of the Bluetooth standard, but is a Silicon Labs proprietary solution (Silabs mode). + +This sample app: + +* transmits connectable advertisements, and makes it possible to enable CTE on the established connections +* transmits Silicon Labs proprietary extended advertisements with CTE to let multiple locators receive the same signal + +This makes it possible for locators to locate the asset tag. + + + +## Configuring the CTE Transmit Method + +By default the asset tag is connectable, and CTEs can be enabled and requested via a connection. Additionally, Silicon Labs proprietary non-connectable extended advertisements with CTE are also sent out periodically, so that (multiple) locators can locate the tag without connecting to it. These features are enabled by the installed **Constant Tone Extension GATT Service (Connection)** and **Constant Tone Extension GATT Service (Silabs proprietary)** software components + +![CTE related software components](readme_img2.png) + +To transmit standard periodic advertisements instead of Silicon Labs proprietary extended advertisements, uninstall the **Constant Tone Extension GATT Service (Silabs proprietary)** and install the **Constant Tone Extension GATT Service (Connectionless)** software component in the Project Configurator. + + + +## Testing the SoC - AoA Asset Tag Application + +AoA Asset Tag can be tested together with an AoA Locator. After programming your board with the SoC - AoA Asset Tag sample app, please attach an antenna array board, as well, create an NCP - AoA Locator sample app, and then follow the instructions documented in [AN1296: Application Development with Silicon Labs’ RTL Library](https://www.silabs.com/documents/public/application-notes/an1296-application-development-with-rtl-library.pdf). + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side), as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[UG103.18: Bluetooth® Direction Finding Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-18-bluetooth-direction-finding-fundamentals.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg175-direction-finding-solution-quick-start-guide.pdf) + +[AN1296: Application Development with Silicon Labs’ RTL Library](https://www.silabs.com/documents/public/application-notes/an1296-application-development-with-rtl-library.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_blinky/readme.html b/app/bluetooth/documentation/example/soc_blinky/readme.html deleted file mode 100644 index c67177bf98a..00000000000 --- a/app/bluetooth/documentation/example/soc_blinky/readme.html +++ /dev/null @@ -1,608 +0,0 @@ - - - - - -readme - -
-

SoC - Blinky

This sample application is the "Hello World" of Bluetooth Low Energy (BLE). It allows a BLE central device to control the LED on the kit and receive button press notifications.

 

Getting started

To get started with Bluetooth and Simplicity Studio, please refer to QSG169: Bluetooth® SDK v3.x Quick Start Guide.

This example implements a simple custom GATT service with two characteristics. One characteristic controls the state of the LED (ON/OFF) via write operations from a GATT client, and the second characteristic will send notifications to subscribed clients when the button state changes (pressed or released).

To test this demo install EFR Connect for Android or iOS. Source code for the mobile app is available on Github.

After launching the app go to the demo view and select the Blinky demo. A pop-up will show all the devices around you which are running the SoC-Blinky firmware. Tap on the device to go into the demo view.

Demo view Pop up

Tap the light on the mobile app to toggle the LED on the kit, and when you press/release the button on the kit the state will change for the virtual button on the app as well.

Blinky all off Blinky all on

The animation below showcases the demo running on a BGM220 Explorer Kit (BGM220-EK4314A) with the mobile app running on an Android device.

Radio board power supply switch

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_blinky/readme.md b/app/bluetooth/documentation/example/soc_blinky/readme.md new file mode 100644 index 00000000000..96baa080c46 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_blinky/readme.md @@ -0,0 +1,64 @@ +# SoC - Blinky + +This sample application is the "Hello World" of Bluetooth Low Energy (BLE). It allows a BLE central device to control the LED on the kit and receive button press notifications. + + + +## Getting started + +To get started with Bluetooth and Simplicity Studio, please refer to [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +This example implements a simple custom GATT service with two characteristics. One characteristic controls the state of the LED (ON/OFF) via write operations from a GATT client, and the second characteristic will send notifications to subscribed clients when the button state changes (pressed or released). + +To test this demo install EFR Connect for [Android](https://play.google.com/store/apps/details?id=com.siliconlabs.bledemo&hl=en&gl=US) or [iOS](https://apps.apple.com/us/app/efr-connect/id1030932759). Source code for the mobile app is available on [Github](https://github.com/SiliconLabs?q=efrconnect&type=&language=&sort=). + +After launching the app go to the demo view and select the Blinky demo. A pop-up will show all the devices around you which are running the SoC-Blinky firmware. Tap on the device to go into the demo view. + +![Demo view](readme_img1.jpg) ![Pop up](readme_img2.jpg) + +Tap the light on the mobile app to toggle the LED on the kit, and when you press/release the button on the kit the state will change for the virtual button on the app as well. + +![Blinky all off](readme_img3.jpg) ![Blinky all on](readme_img4.jpg) + +The animation below showcases the demo running on a BGM220 Explorer Kit (BGM220-EK4314A) with the mobile app running on an Android device. + +![Radio board power supply switch](readme_img5.gif) + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_btmesh_empty/readme.html b/app/bluetooth/documentation/example/soc_btmesh_empty/readme.html deleted file mode 100644 index 16e736b5472..00000000000 --- a/app/bluetooth/documentation/example/soc_btmesh_empty/readme.html +++ /dev/null @@ -1,598 +0,0 @@ - - - - - -readme - -
-

Bluetooth Mesh - SoC Empty

This example demonstrates the bare minimum needed for a Bluetooth mesh C application that supports Over-the-Air Device Firmware Upgrading (OTA DFU). The application starts Unprovisioned Device Beaconing after boot, and waits to be provisioned to a Mesh Network. This example can be used as a starting point for an SoC project and it can be customized by adding new components using the Project Configurator or by modifying the application (app.c). This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory.

Getting Started

To learn Bluetooth mesh technology basics, see Bluetooth Mesh Network - An Introduction for Developers.

To get started with Bluetooth Mesh and Simplicity Studio, see QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide.

The term SoC stands for "System on Chip". In the SoC model the entire system (stack and application) resides on a single chip, whereas in the NCP model the stack processing is done in a separate coprocessor that interacts with the application’s microcontroller through an external serial interface.

The example is an (almost) empty project that has only the bare minimum with Proxy and Relay features included to make a working Bluetooth Mesh application.

To add or remove features from the example, follow this process:

  • Add model and feature components to your project
  • Optionally configure your Mesh node through the "Bluetooth Mesh Configurator". It is configured to have only one element supporting a minimal set of models.

Bluetooth Mesh Configurator

To learn more about programming an SoC application, see UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x.

  • Some components are configurable, and can be customized using the Component Editor

Bluetooth Mesh Components

  • Respond to the events raised by the Bluetooth stack
  • Implement additional application logic

UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x gives code-level information on the stack and the common pitfalls to avoid.

Responding to Bluetooth Events

Just like in the Bluetooth Low Energy SDK, a Mesh application is event-driven. The Bluetooth Mesh stack generates events when a remote device connects or disconnects, for example, or when it publishes a message. While it is not necessary to react to all events, the ones requiring action should be handled by the application in the sl_btmesh_on_event() function. The prototype of this function is implemented in app.c. To handle more events, the switch-case statement of this function is to be extended. For the list of Bluetooth Mesh events, see the HTML documentation present in the SDK installation directory:

  • SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.3/app/bluetooth/documentation/API_BLUETOOTH_MESH_HTML

Implementing Application Logic

Additional application logic has to be implemented in the app_init() and app_process_action() functions. Find the definitions of these functions in app.c. The app_init() function is called once when the device is booted, and app_process_action() is called repeatedly in a while(1) loop. For example, you can poll peripherals in this function.

Features Already Added to Bluetooth Mesh - SoC Empty Application

The Bluetooth Mesh - SoC Empty application is almost empty. It implements a basic application to demonstrate how to emit unprovisioned beacons on both the advertising and GATT bearer.

Testing the Bluetooth Mesh - SoC Empty Application

As described above, an empty example does nothing except broadcast unprovisioned beacons. To test this feature, do the following:

  1. First clear the NVM Mesh settings, for example by performing an Erase Chip with Simplicity Commander, since the example has no button control. See UG162: Simplicity Commander Reference Guide for more information.
  2. Make sure a bootloader is installed. See Troubleshooting section.
  3. Build and flash the Bluetooth Mesh - SoC Empty sample app to your device. The flashing can be done for example using the Simplicity Studio internal Flash Programmer or external Simplicity Commander -tools.
  4. Download the Silicon Labs Bluetooth Mesh smartphone application available on iOS and Android. Make sure to reset the local database by pressing the "Reset local database" button in the menu "More".

Bluetooth Mesh start screen

  1. Open the app and choose the Provision Browser and tap Scan.

Bluetooth Mesh start screen

  1. Now you should find your device advertising. Tap PROVISION.

Bluetooth Browser

Troubleshooting

Note that NO Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image.

  • The Bluetooth Mesh - SoC Switch demo includes an OTA DFU-capable bootloader.
  • The Bluetooth Mesh - NCP Empty demo includes a UART DFU-capable bootloader.
  • For other bootloader types, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103.6: Bootloader Fundamentals and UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

Resources

Bluetooth Documentation

Bluetooth Mesh Network - An Introduction for Developers

QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide

AN1315: Bluetooth Mesh Device Power Consumption Measurements

AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization

AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh

AN1318: IV Update in a Bluetooth Mesh Network

UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x

UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_btmesh_empty/readme.md b/app/bluetooth/documentation/example/soc_btmesh_empty/readme.md new file mode 100644 index 00000000000..b31935f0db1 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_btmesh_empty/readme.md @@ -0,0 +1,105 @@ +# Bluetooth Mesh - SoC Empty + +This example demonstrates the bare minimum needed for a Bluetooth mesh C application that supports Over-the-Air Device Firmware Upgrading (OTA DFU). The application starts Unprovisioned Device Beaconing after boot, and waits to be provisioned to a Mesh Network. This example can be used as a starting point for an SoC project and it can be customized by adding new components using the Project Configurator or by modifying the application (app.c). This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory. + +## Getting Started + +To learn Bluetooth mesh technology basics, see [Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf). + +To get started with Bluetooth Mesh and Simplicity Studio, see [QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf). + +The term SoC stands for "System on Chip". In the SoC model the entire system (stack and application) resides on a single chip, whereas in the NCP model the stack processing is done in a separate coprocessor that interacts with the application’s microcontroller through an external serial interface. + +The example is an (almost) empty project that has only the bare minimum with Proxy and Relay features included to make a working Bluetooth Mesh application. + +To add or remove features from the example, follow this process: + +- Add model and feature components to your project +- Optionally configure your Mesh node through the "Bluetooth Mesh Configurator". It is configured to have only one element supporting a minimal set of models. + +![Bluetooth Mesh Configurator](readme_img1.png) + +To learn more about programming an SoC application, see [UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug472-bluetooth-mesh-v2x-node-configuration-users-guide.pdf). + +- Some components are configurable, and can be customized using the Component Editor + +![Bluetooth Mesh Components](readme_img5.png) + +- Respond to the events raised by the Bluetooth stack +- Implement additional application logic + +[UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) gives code-level information on the stack and the common pitfalls to avoid. + +## Responding to Bluetooth Events + +Just like in the Bluetooth Low Energy SDK, a Mesh application is event-driven. The Bluetooth Mesh stack generates events when a remote device connects or disconnects, for example, or when it publishes a message. While it is not necessary to react to all events, the ones requiring action should be handled by the application in the *sl_btmesh_on_event()* function. The prototype of this function is implemented in *app.c*. To handle more events, the switch-case statement of this function is to be extended. For the list of Bluetooth Mesh events, see the HTML documentation present in the SDK installation directory: + +* SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.3/app/bluetooth/documentation/API_BLUETOOTH_MESH_HTML + +## Implementing Application Logic + +Additional application logic has to be implemented in the *app_init()* and *app_process_action()* functions. Find the definitions of these functions in *app.c*. The *app_init()* function is called once when the device is booted, and *app_process_action()* is called repeatedly in a while(1) loop. For example, you can poll peripherals in this function. + +## Features Already Added to Bluetooth Mesh - SoC Empty Application + +The **Bluetooth Mesh - SoC Empty** application is ***almost*** empty. It implements a basic application to demonstrate how to emit unprovisioned beacons on both the advertising and GATT bearer. + +## Testing the Bluetooth Mesh - SoC Empty Application + +As described above, an empty example does nothing except broadcast unprovisioned beacons. To test this feature, do the following: + +1. First clear the NVM Mesh settings, for example by performing an Erase Chip with Simplicity Commander, since the example has no button control. See [UG162: Simplicity Commander Reference Guide](https://www.silabs.com/documents/public/user-guides/ug162-simplicity-commander-reference-guide.pdf) for more information. +2. Make sure a bootloader is installed. See Troubleshooting section. +3. Build and flash the **Bluetooth Mesh - SoC Empty** sample app to your device. The flashing can be done for example using the Simplicity Studio internal **Flash Programmer** or external **Simplicity Commander** -tools. +4. Download the Silicon Labs **Bluetooth Mesh** smartphone application available on [iOS](https://apps.apple.com/us/app/bluetooth-mesh-by-silicon-labs/id1411352948) and [Android](https://play.google.com/store/apps/details?id=com.siliconlabs.bluetoothmesh). Make sure to reset the local database by pressing the "Reset local database" button in the menu "More". + +![Bluetooth Mesh start screen](readme_img4.png) + +5. Open the app and choose the Provision Browser and tap **Scan**. + +![Bluetooth Mesh start screen](readme_img2.png) + +6. Now you should find your device advertising. Tap **PROVISION**. + +![Bluetooth Browser](readme_img3.png) + +## Troubleshooting + +Note that **NO** Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image. + +- The **Bluetooth Mesh - SoC Switch** demo includes an OTA DFU-capable bootloader. +- The **Bluetooth Mesh - NCP Empty** demo includes a UART DFU-capable bootloader. +- For other bootloader types, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103.6: Bootloader Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher](https://www.silabs.com/documents/public/user-guides/ug489-gecko-bootloader-user-guide-gsdk-4.pdf)*. + +Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf) + +[QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) + +[AN1315: Bluetooth Mesh Device Power Consumption Measurements](https://www.silabs.com/documents/public/application-notes/an1315-bluetooth-mesh-power-consumption-measurements.pdf) + +[AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization](https://www.silabs.com/documents/public/application-notes/an1316-bluetooth-mesh-network-optimization.pdf) + +[AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh](https://www.silabs.com/documents/public/application-notes/an1317-network-analyzer-with-bluetooth-mesh-le.pdf) + +[AN1318: IV Update in a Bluetooth Mesh Network](https://www.silabs.com/documents/public/application-notes/an1318-bluetooth-mesh-iv-update.pdf) + +[UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) + +[UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). diff --git a/app/bluetooth/documentation/example/soc_btmesh_hsl/readme.html b/app/bluetooth/documentation/example/soc_btmesh_hsl/readme.html deleted file mode 100644 index 9b2b3313af4..00000000000 --- a/app/bluetooth/documentation/example/soc_btmesh_hsl/readme.html +++ /dev/null @@ -1,598 +0,0 @@ - - - - - -readme - -
-

Bluetooth Mesh - SoC Light HSL (Hue, Saturation, Lightness)

The Bluetooth Mesh - SoC Light HSL example is a working example application that you can use as a template for Bluetooth Mesh HSL Light applications.

The example is an out-of-the-box Software Demo where the LEDs of the device can be controlled by button presses on another device (for example Bluetooth Mesh - SoC Switch). The LEDs can be switched on and off, and their lighting intensity can also be set. Hue and saturation (shown only on the LCD or in UART logs, depending on the mainboard) can be set by the Light HSL Client model. The example also tries to establish friendship as a Friend node and prints its status to the LCD or UART. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, the Light HSL Server Model and the Light LC Server Model. This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory.

Note: Currently the Bluetooth Mesh - SoC Switch does not support HSL Client (i.e. cannot set hue or saturation). Only the mobile application supports HSL Client. All the other features work.

Bluetooth Mesh lighting system - Light

Getting Started

To learn Bluetooth mesh technology basics, see Bluetooth Mesh Network - An Introduction for Developers.

To get started with Bluetooth Mesh and Simplicity Studio, see QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide.

The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate.

This is an example of a Bluetooth Mesh HSL light application. It demonstrates how to control a light source, an LED mounted on a mainboard and a radio board or similar hardware, connected to a Bluetooth Mesh network. The light source lightness can be controlled with a light client, such as another radio board running the Bluetooth Mesh - SoC Switch application, or with Bluetooth Mesh smartphone application.

Note: Currently the Bluetooth Mesh - SoC Switch nor the mobile application do not support HSL Client. All the other features work.

The LED light can be controlled in many ways using different models:

  • Generic OnOff Server model can turn the light on and off
  • Generic Level Server model can control the light brightness
  • Light Lightness Server model can control the light Lightness
  • Light HSL Server model can control light Lightness, (Hue and Saturation only virtually, can be seen only in the LCD and logs)
  • Light LC Server model, i.e. Light Controller, can automatically control the switch on/&off based on the sensors
  • Scene Server model saves the light settings to recall them later
  • Scheduler Server model provides time- and date-dependent lighting operations

For more information on the HSL light model, please refer to the following Wikipedia link.

To add or remove features from the example, follow this process:

  • Add model and feature components to your project
  • Optionally configure your Mesh node through the "Bluetooth Mesh Configurator"

Bluetooth Mesh Configurator

To learn more about programming an SoC application, see UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x.

  • Some components are configurable, and can be customized using the Component Editor

Bluetooth Mesh Components

  • Respond to the events raised by the Bluetooth stack
  • Implement additional application logic

UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x gives code-level information on the stack and the common pitfalls to avoid.

Testing the Bluetooth Mesh - SoC Light HSL Application

To test the application, do the following:

  1. Make sure a bootloader is installed. See Troubleshooting section.

  2. Build and flash the Bluetooth Mesh - SoC Light HSL sample app to your device.

  3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen.

  4. Provision the device in one of three ways:

    Mobile Phone provisioning is illustrated in the following figure.

Bluetooth Mesh start screen

  1. Open the app and choose the Provision Browser and tap Scan.

Bluetooth Mesh Provision Browser

  1. Now you should find your device advertising as "light node" (iOS) or "Unknown" (Android). Tap PROVISION.

Bluetooth Mesh Provisioning Device

  1. Configure the device as Light Lightness Server and select the correct group to which the messages will be published (Demo group). If you want to test the Bluetooth Mesh Generic OnOff Model, the Light HSL Model, the Scene Model or some other Mesh Model, then select the respective client instead. You can use only one at a time in our mobile application. The Mobile application does not support Light HSL Model yet, therefore use the Light Lightness Model.

Bluetooth Mesh Device Configuration

  1. Use the slider to set the lightness of the WSKT + radio board LED.

Lightness slider

  1. The next step is to add a switch or several switches into your network, if it has not already been done. This is required to fully test the whole system, for example the friendship and other features. You can then control the light example by pressing the buttons in the Bluetooth Mesh - SoC Switch and Bluetooth Mesh - SoC Switch Low Power examples. Read the applicable example project documentation to learn more.

For more information on the example, please refer to AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration.

Troubleshooting

Note that NO Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image.

  • The Bluetooth Mesh - SoC Switch demo includes an OTA DFU-capable bootloader.
  • The Bluetooth Mesh - NCP Empty demo includes a UART DFU-capable bootloader.
  • For other bootloader types, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103.6: Bootloader Fundamentals and UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

Resources

Bluetooth Documentation

Bluetooth Mesh Network - An Introduction for Developers

QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide

AN1315: Bluetooth Mesh Device Power Consumption Measurements

AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization

AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh

AN1318: IV Update in a Bluetooth Mesh Network

AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration

UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x

UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Wikipedia link

Bluetooth Training

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_btmesh_hsl/readme.md b/app/bluetooth/documentation/example/soc_btmesh_hsl/readme.md new file mode 100644 index 00000000000..e61467656f2 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_btmesh_hsl/readme.md @@ -0,0 +1,135 @@ +# Bluetooth Mesh - SoC Light HSL (Hue, Saturation, Lightness) + +The **Bluetooth Mesh - SoC Light HSL** example is a working example application that you can use as a template for Bluetooth Mesh HSL Light applications. + +The example is an out-of-the-box Software Demo where the LEDs of the device can be controlled by button presses on another device (for example **Bluetooth Mesh - SoC Switch**). The LEDs can be switched on and off, and their **lighting intensity** can also be set. **Hue** and **saturation** (shown only on the LCD or in UART logs, depending on the mainboard) can be set by the Light HSL Client model. The example also tries to establish friendship as a Friend node and prints its status to the LCD or UART. The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, the Light HSL Server Model and the Light LC Server Model. This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory. + +*Note: Currently the* ***Bluetooth Mesh - SoC Switch*** *does not support HSL Client (i.e. cannot set hue or saturation). Only the mobile application supports HSL Client. All the other features work.* + +![Bluetooth Mesh lighting system - Light](readme_img7.png) + +## Getting Started + +To learn Bluetooth mesh technology basics, see [Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf). + +To get started with Bluetooth Mesh and Simplicity Studio, see [QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf). + +The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate. + +This is an example of a Bluetooth Mesh HSL light application. It demonstrates how to control a light source, an LED mounted on a mainboard and a radio board or similar hardware, connected to a Bluetooth Mesh network. The light source lightness can be controlled with a light client, such as another radio board running the **Bluetooth Mesh - SoC Switch** application, or with **Bluetooth Mesh** smartphone application. + +*Note: Currently the* ***Bluetooth Mesh - SoC Switch*** *nor the mobile application do not support HSL Client. All the other features work.* + +The LED light can be controlled in many ways using different models: + +- **Generic OnOff Server** model can turn the light on and off +- **Generic Level Server** model can control the light brightness +- **Light Lightness Server** model can control the light Lightness +- **Light HSL Server** model can control light Lightness, (Hue and Saturation only virtually, can be seen only in the LCD and logs) +- **Light LC Server** model, i.e. Light Controller, can automatically control the switch on/&off based on the sensors +- **Scene Server** model saves the light settings to recall them later +- **Scheduler Server** model provides time- and date-dependent lighting operations + +For more information on the HSL light model, please refer to the following [Wikipedia link](https://en.wikipedia.org/wiki/HSL_and_HSV#HSL_to_RGB_alternative). + +To add or remove features from the example, follow this process: + +- Add model and feature components to your project +- Optionally configure your Mesh node through the "Bluetooth Mesh Configurator" + +![Bluetooth Mesh Configurator](readme_img1.png) + +To learn more about programming an SoC application, see [UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug472-bluetooth-mesh-v2x-node-configuration-users-guide.pdf). + +- Some components are configurable, and can be customized using the Component Editor + +![Bluetooth Mesh Components](readme_img8.png) + +- Respond to the events raised by the Bluetooth stack +- Implement additional application logic + +[UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) gives code-level information on the stack and the common pitfalls to avoid. + +## Testing the Bluetooth Mesh - SoC Light HSL Application + +To test the application, do the following: + +1. Make sure a bootloader is installed. See Troubleshooting section. +2. Build and flash the **Bluetooth Mesh - SoC Light HSL** sample app to your device. +3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen. +4. Provision the device in one of three ways: + + - NCP Host provisioner examples, see for example an SDK folder `app/bluetooth/example_host/btmesh_provisioner` or [github](https://github.com/SiliconLabs/bluetooth_mesh_stack_features/tree/master/provisioning) + + - NCP Commander with NCP target device, see [Bluetooth NCP Commander guide](https://docs.silabs.com/simplicity-studio-5-users-guide/latest/ss-5-users-guide-tools-bluetooth-ncp-commander) or [AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) + + - For Mobile Phone use, see the [QSG176: Bluetooth® Mesh SDK v2.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) for more information how to download and use the Silicon Labs Bluetooth Mesh application. + + Mobile Phone provisioning is illustrated in the following figure. + +![Bluetooth Mesh start screen](readme_img6.png) + +5. Open the app and choose the Provision Browser and tap **Scan**. + +![Bluetooth Mesh Provision Browser](readme_img2.png) + +6. Now you should find your device advertising as "light node" (iOS) or "Unknown" (Android). Tap **PROVISION**. + +![Bluetooth Mesh Provisioning Device](readme_img3.png) + +7. Configure the device as **Light Lightness Server** and select the correct group to which the messages will be published (Demo group). If you want to test the Bluetooth Mesh Generic OnOff Model, the Light HSL Model, the Scene Model or some other Mesh Model, then select the respective client instead. You can use only one at a time in our mobile application. The Mobile application does not support Light HSL Model yet, therefore use the Light Lightness Model. + +![Bluetooth Mesh Device Configuration](readme_img4.png) + +8. Use the slider to set the lightness of the WSKT + radio board LED. + +![Lightness slider](readme_img5.png) + +9. The next step is to add a switch or several switches into your network, if it has not already been done. This is required to fully test the whole system, for example the friendship and other features. You can then control the light example by pressing the buttons in the **Bluetooth Mesh - SoC Switch** and **Bluetooth Mesh - SoC Switch Low Power** examples. Read the applicable example project documentation to learn more. + +For more information on the example, please refer to [AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration](https://www.silabs.com/documents/public/application-notes/an1299-understanding-bluetooth-mesh-lighting-demo-sdk-2x.pdf). + +## Troubleshooting + +Note that **NO** Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image. + +- The **Bluetooth Mesh - SoC Switch** demo includes an OTA DFU-capable bootloader. +- The **Bluetooth Mesh - NCP Empty** demo includes a UART DFU-capable bootloader. +- For other bootloader types, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103.6: Bootloader Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher](https://www.silabs.com/documents/public/user-guides/ug489-gecko-bootloader-user-guide-gsdk-4.pdf)*. + +Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf) + +[QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) + +[AN1315: Bluetooth Mesh Device Power Consumption Measurements](https://www.silabs.com/documents/public/application-notes/an1315-bluetooth-mesh-power-consumption-measurements.pdf) + +[AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization](https://www.silabs.com/documents/public/application-notes/an1316-bluetooth-mesh-network-optimization.pdf) + +[AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh](https://www.silabs.com/documents/public/application-notes/an1317-network-analyzer-with-bluetooth-mesh-le.pdf) + +[AN1318: IV Update in a Bluetooth Mesh Network](https://www.silabs.com/documents/public/application-notes/an1318-bluetooth-mesh-iv-update.pdf) + +[AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration](https://www.silabs.com/documents/public/application-notes/an1299-understanding-bluetooth-mesh-lighting-demo-sdk-2x.pdf) + +[UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) + +[UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Wikipedia link](https://en.wikipedia.org/wiki/HSL_and_HSV#HSL_to_RGB_alternative) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). diff --git a/app/bluetooth/documentation/example/soc_btmesh_light/readme.html b/app/bluetooth/documentation/example/soc_btmesh_light/readme.html deleted file mode 100644 index d36986640c1..00000000000 --- a/app/bluetooth/documentation/example/soc_btmesh_light/readme.html +++ /dev/null @@ -1,598 +0,0 @@ - - - - - -readme - -
-

Bluetooth Mesh - SoC Light

The Bluetooth Mesh - SoC Light example is a working example application that you can use as a template for Bluetooth Mesh Light applications.

The example is an out-of-the-box Software Demo where the LEDs of the device can be controlled by button presses on another device (for example Bluetooth Mesh - SoC Switch). The LEDs can be switched on and off, and the lighting intensity, color temperature, and Delta UV (on some devices shown only on the LCD or in UART logs) can also be set. The example also tries to establish friendship as a Friend node and prints its status to the LCD or UART (the target device determines if the feature is enabled and the output status). The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, the Light CTL Server Model, and the Light LC Server Model. This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory.

Bluetooth Mesh lighting system - Light

Getting Started

To learn Bluetooth mesh technology basics, see Bluetooth Mesh Network - An Introduction for Developers.

To get started with Bluetooth Mesh and Simplicity Studio, see QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide.

The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate.

This is an example of a Bluetooth Mesh light application. It demonstrates how to control a light source, an LED mounted on a mainboard and a radio board or similar hardware, connected to a Bluetooth Mesh network. The light source lightness can be controlled with a light client, e.g. another radio board running the Bluetooth Mesh - SoC Switch application, or with Bluetooth Mesh smartphone application.

The LED light can be controlled in many ways using different models:

  • Generic OnOff Server model can turn the light on and off
  • Generic Level Server model can control the light brightness
  • Light Lightness Server model can control the light Lightness
  • Light CTL Server model can control light Lightness (Color Temperature and Delta UV only virtually)
  • Light LC Server model, i.e. Light Controller, can automatically control the switch on/&off based on the sensors
  • Scene Server model saves the light settings to recall them later
  • Scheduler Server model provides time- and date-dependent lighting operations

To add or remove features from the example, follow this process:

  • Add model and feature components to your project
  • Optionally configure your Mesh node through the "Bluetooth Mesh Configurator"

Bluetooth Mesh Configurator

To learn more about programming an SoC application, see UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x.

  • Some components are configurable, and can be customized using the Component Editor

Bluetooth Mesh Components

  • Respond to the events raised by the Bluetooth stack
  • Implement additional application logic

UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x gives code-level information on the stack and the common pitfalls to avoid.

Testing the Bluetooth Mesh - SoC Light Application

To test the application, do the following:

  1. Make sure a bootloader is installed. See Troubleshooting section.

  2. Build and flash the Bluetooth Mesh - SoC Light sample app to your device.

  3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen.

  4. Provision the device in one of three ways:

    Mobile Phone provisioning is illustrated in the following figure.

Bluetooth Mesh start screen

  1. Open the app and choose the Provision Browser and tap Scan.

Bluetooth Mesh Provision Browser

  1. Now you should find your device advertising as "light node" (iOS) or "Unknown" (Android). Tap PROVISION.

Bluetooth Mesh Provisioning Device

  1. Configure the device as Light CTL Server and select the correct group to which the messages will be published (Demo group). If you want to test the Bluetooth Mesh Generic OnOff Model, the Light Lightness Model, the Scene Model or some other Mesh Model, then select the respective client instead. You can use only one at a time in our mobile application.

Bluetooth Mesh Device Configuration

  1. Use the slider to set the lightness of the WSKT + radio board LED.

Lightness slider

  1. The next step is to add a switch or several switches into your network, if it has not already been done. This is required to fully test the whole system, for example the friendship and other features. You can then control the light example by pressing the buttons in the Bluetooth Mesh - SoC Switch and Bluetooth Mesh - SoC Switch Low Power examples. Read the applicable example project documentation to learn more.

For more information on the example, please refer to AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration.

Troubleshooting

Note that NO Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image.

  • The Bluetooth Mesh - SoC Switch demo includes an OTA DFU-capable bootloader.
  • The Bluetooth Mesh - NCP Empty demo includes a UART DFU-capable bootloader.
  • For other bootloader types, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103.6: Bootloader Fundamentals and UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

Resources

Bluetooth Documentation

Bluetooth Mesh Network - An Introduction for Developers

QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide

AN1315: Bluetooth Mesh Device Power Consumption Measurements

AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization

AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh

AN1318: IV Update in a Bluetooth Mesh Network

AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration

UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x

UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_btmesh_light/readme.md b/app/bluetooth/documentation/example/soc_btmesh_light/readme.md new file mode 100644 index 00000000000..1412db1c980 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_btmesh_light/readme.md @@ -0,0 +1,127 @@ +# Bluetooth Mesh - SoC Light + +The **Bluetooth Mesh - SoC Light** example is a working example application that you can use as a template for Bluetooth Mesh Light applications. + +The example is an out-of-the-box Software Demo where the LEDs of the device can be controlled by button presses on another device (for example **Bluetooth Mesh - SoC Switch**). The LEDs can be switched on and off, and the **lighting intensity**, **color temperature**, and **Delta UV** (on some devices shown only on the LCD or in UART logs) can also be set. The example also tries to establish friendship as a Friend node and prints its status to the LCD or UART (the target device determines if the feature is enabled and the output status). The example is based on the Bluetooth Mesh Generic On/Off Model, the Light Lightness Model, the Light CTL Server Model, and the Light LC Server Model. This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory. + +![Bluetooth Mesh lighting system - Light](readme_img7.png) + +## Getting Started + +To learn Bluetooth mesh technology basics, see [Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf). + +To get started with Bluetooth Mesh and Simplicity Studio, see [QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf). + +The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate. + +This is an example of a Bluetooth Mesh light application. It demonstrates how to control a light source, an LED mounted on a mainboard and a radio board or similar hardware, connected to a Bluetooth Mesh network. The light source lightness can be controlled with a light client, e.g. another radio board running the **Bluetooth Mesh - SoC Switch** application, or with **Bluetooth Mesh** smartphone application. + +The LED light can be controlled in many ways using different models: + +- **Generic OnOff Server** model can turn the light on and off +- **Generic Level Server** model can control the light brightness +- **Light Lightness Server** model can control the light Lightness +- **Light CTL Server** model can control light Lightness (Color Temperature and Delta UV only virtually) +- **Light LC Server** model, i.e. Light Controller, can automatically control the switch on/&off based on the sensors +- **Scene Server** model saves the light settings to recall them later +- **Scheduler Server** model provides time- and date-dependent lighting operations + +To add or remove features from the example, follow this process: + +- Add model and feature components to your project +- Optionally configure your Mesh node through the "Bluetooth Mesh Configurator" + +![Bluetooth Mesh Configurator](readme_img1.png) + +To learn more about programming an SoC application, see [UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug472-bluetooth-mesh-v2x-node-configuration-users-guide.pdf). + +- Some components are configurable, and can be customized using the Component Editor + +![Bluetooth Mesh Components](readme_img8.png) + +- Respond to the events raised by the Bluetooth stack +- Implement additional application logic + +[UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) gives code-level information on the stack and the common pitfalls to avoid. + +## Testing the Bluetooth Mesh - SoC Light Application + +To test the application, do the following: + +1. Make sure a bootloader is installed. See Troubleshooting section. +2. Build and flash the **Bluetooth Mesh - SoC Light** sample app to your device. +3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen. +4. Provision the device in one of three ways: + + - NCP Host provisioner examples, see for example an SDK folder `app/bluetooth/example_host/btmesh_provisioner` or [github](https://github.com/SiliconLabs/bluetooth_mesh_stack_features/tree/master/provisioning) + + - NCP Commander with NCP target device, see [Bluetooth NCP Commander guide](https://docs.silabs.com/simplicity-studio-5-users-guide/latest/ss-5-users-guide-tools-bluetooth-ncp-commander) or [AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) + + - For Mobile Phone use, see the [QSG176: Bluetooth® Mesh SDK v2.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) for more information how to download and use the Silicon Labs Bluetooth Mesh application. + + Mobile Phone provisioning is illustrated in the following figure. + +![Bluetooth Mesh start screen](readme_img6.png) + +5. Open the app and choose the Provision Browser and tap **Scan**. + +![Bluetooth Mesh Provision Browser](readme_img2.png) + +6. Now you should find your device advertising as "light node" (iOS) or "Unknown" (Android). Tap **PROVISION**. + +![Bluetooth Mesh Provisioning Device](readme_img3.png) + +7. Configure the device as **Light CTL Server** and select the correct group to which the messages will be published (Demo group). If you want to test the Bluetooth Mesh Generic OnOff Model, the Light Lightness Model, the Scene Model or some other Mesh Model, then select the respective client instead. You can use only one at a time in our mobile application. + +![Bluetooth Mesh Device Configuration](readme_img4.png) + +8. Use the slider to set the lightness of the WSKT + radio board LED. + +![Lightness slider](readme_img5.png) + +9. The next step is to add a switch or several switches into your network, if it has not already been done. This is required to fully test the whole system, for example the friendship and other features. You can then control the light example by pressing the buttons in the **Bluetooth Mesh - SoC Switch** and **Bluetooth Mesh - SoC Switch Low Power** examples. Read the applicable example project documentation to learn more. + +For more information on the example, please refer to [AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration](https://www.silabs.com/documents/public/application-notes/an1299-understanding-bluetooth-mesh-lighting-demo-sdk-2x.pdf). + +## Troubleshooting + +Note that **NO** Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image. + +- The **Bluetooth Mesh - SoC Switch** demo includes an OTA DFU-capable bootloader. +- The **Bluetooth Mesh - NCP Empty** demo includes a UART DFU-capable bootloader. +- For other bootloader types, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103.6: Bootloader Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher](https://www.silabs.com/documents/public/user-guides/ug489-gecko-bootloader-user-guide-gsdk-4.pdf)*. + +Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf) + +[QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) + +[AN1315: Bluetooth Mesh Device Power Consumption Measurements](https://www.silabs.com/documents/public/application-notes/an1315-bluetooth-mesh-power-consumption-measurements.pdf) + +[AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization](https://www.silabs.com/documents/public/application-notes/an1316-bluetooth-mesh-network-optimization.pdf) + +[AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh](https://www.silabs.com/documents/public/application-notes/an1317-network-analyzer-with-bluetooth-mesh-le.pdf) + +[AN1318: IV Update in a Bluetooth Mesh Network](https://www.silabs.com/documents/public/application-notes/an1318-bluetooth-mesh-iv-update.pdf) + +[AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration](https://www.silabs.com/documents/public/application-notes/an1299-understanding-bluetooth-mesh-lighting-demo-sdk-2x.pdf) + +[UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) + +[UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). diff --git a/app/bluetooth/documentation/example/soc_btmesh_sensor_client/readme.html b/app/bluetooth/documentation/example/soc_btmesh_sensor_client/readme.html deleted file mode 100644 index 94eabad8ae8..00000000000 --- a/app/bluetooth/documentation/example/soc_btmesh_sensor_client/readme.html +++ /dev/null @@ -1,598 +0,0 @@ - - - - - -readme - -
-

Bluetooth Mesh - SoC Sensor Client

The Bluetooth Mesh - SoC Sensor Client example is a working example application that you can use as a template for Bluetooth Mesh Sensor Client applications.

The example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (for example Bluetooth Mesh - SoC Sensor Server). The current status is displayed on the LCD (if one is present on the mainboard) and also sent to UART. CLI commands may substitute for button presses if the mainboard has only one button available. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory.

Bluetooth Mesh sensor system - Client

Getting Started

To learn Bluetooth mesh technology basics, see Bluetooth Mesh Network - An Introduction for Developers.

To get started with Bluetooth Mesh and Simplicity Studio, see QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide.

The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate.

Bluetooth Mesh - SoC Sensor Client example collects sensor data from the sensor server. If it is used together with the soc-btmesh-sensor-server example then it will display occupancy (people count) sensor data, temperature data and illuminance (on Thunderboard Sense 2).

To add or remove features from the example, follow this process:

  • Add model and feature components to your project
  • Optionally configure your Mesh node through the "Bluetooth Mesh Configurator"

Bluetooth Mesh Configurator

To learn more about programming an SoC application, see UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x.

  • Some components are configurable, and can be customized using the Component Editor

Bluetooth Mesh Components

  • Respond to the events raised by the Bluetooth stack
  • Implement additional application logic

UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x gives code-level information on the stack and the common pitfalls to avoid.

Testing the Bluetooth Mesh - SoC Sensor Client Application

To test the application, do the following:

  1. Make sure a bootloader is installed. See Troubleshooting section.

  2. Build and flash the Bluetooth Mesh - SoC Sensor Client sample app to your device.

  3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen.

  4. Provision the device in one of three ways:

    Mobile Phone provisioning is illustrated in the following figure.

Bluetooth Mesh start screen

  1. Open the app and choose the Provision Browser and tap Scan. The device sending unprovisioned beacons should appear, tap PROVISION:

Bluetooth Mesh Provision Browser

  1. Start provisioning using the "Continue" button:

Bluetooth Mesh Provisioning Device

  1. Configure the device as "Sensor Client" and select the correct group to which the messages will subscribe (Demo group).

Bluetooth Mesh Device Configuration

  1. Once the node is provisioned and correctly configured, it is ready to function in your demo network.

Sensor client with Proxy connection

  1. The next step is to add a sensor server or several into your network, if it has not already been done. This is required to fully test the whole system. Read the applicable example project documentation to learn more.

For more information on the example, please refer to AN1300: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Sensor Model Demonstration.

The button presses in this example:

  • Short presses will update the registered devices
  • Long press of PB0 will change the current property

Troubleshooting

Note that NO Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image.

  • The Bluetooth Mesh - SoC Switch demo includes an OTA DFU-capable bootloader.
  • The Bluetooth Mesh - NCP Empty demo includes a UART DFU-capable bootloader.
  • For other bootloader types, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103.6: Bootloader Fundamentals and UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

Resources

Bluetooth Documentation

Bluetooth Mesh Network - An Introduction for Developers

QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide

AN1315: Bluetooth Mesh Device Power Consumption Measurements

AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization

AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh

AN1318: IV Update in a Bluetooth Mesh Network

AN1300: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Sensor Model Demonstration

UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x

UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_btmesh_sensor_client/readme.md b/app/bluetooth/documentation/example/soc_btmesh_sensor_client/readme.md new file mode 100644 index 00000000000..1b6d7fe69ba --- /dev/null +++ b/app/bluetooth/documentation/example/soc_btmesh_sensor_client/readme.md @@ -0,0 +1,122 @@ +# Bluetooth Mesh - SoC Sensor Client + +The **Bluetooth Mesh - SoC Sensor Client** example is a working example application that you can use as a template for Bluetooth Mesh Sensor Client applications. + +The example demonstrates the Bluetooth Mesh Sensor Client Model. It collects and displays sensor measurement data from remote device(s) (for example **Bluetooth Mesh - SoC Sensor Server**). The current status is displayed on the LCD (if one is present on the mainboard) and also sent to UART. CLI commands may substitute for button presses if the mainboard has only one button available. This example requires one of the Internal Storage Bootloader (single image) variants depending on device memory. + +![Bluetooth Mesh sensor system - Client](readme_img7.png) + +## Getting Started + +To learn Bluetooth mesh technology basics, see [Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf). + +To get started with Bluetooth Mesh and Simplicity Studio, see [QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf). + +The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate. + +**Bluetooth Mesh - SoC Sensor Client** example collects sensor data from the sensor server. If it is used together with the soc-btmesh-sensor-server example then it will display occupancy (people count) sensor data, temperature data and illuminance (on Thunderboard Sense 2). + +To add or remove features from the example, follow this process: + +- Add model and feature components to your project +- Optionally configure your Mesh node through the "Bluetooth Mesh Configurator" + +![Bluetooth Mesh Configurator](readme_img1.png) + +To learn more about programming an SoC application, see [UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug472-bluetooth-mesh-v2x-node-configuration-users-guide.pdf). + +- Some components are configurable, and can be customized using the Component Editor + +![Bluetooth Mesh Components](readme_img8.png) + +- Respond to the events raised by the Bluetooth stack +- Implement additional application logic + +[UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) gives code-level information on the stack and the common pitfalls to avoid. + +## Testing the Bluetooth Mesh - SoC Sensor Client Application + +To test the application, do the following: + +1. Make sure a bootloader is installed. See Troubleshooting section. +2. Build and flash the **Bluetooth Mesh - SoC Sensor Client** sample app to your device. +3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen. +4. Provision the device in one of three ways: + + - NCP Host provisioner examples, see for example an SDK folder `app/bluetooth/example_host/btmesh_provisioner` or [github](https://github.com/SiliconLabs/bluetooth_mesh_stack_features/tree/master/provisioning) + + - NCP Commander with NCP target device, see [Bluetooth NCP Commander guide](https://docs.silabs.com/simplicity-studio-5-users-guide/latest/ss-5-users-guide-tools-bluetooth-ncp-commander) or [AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) + + - For Mobile Phone use, see the [QSG176: Bluetooth® Mesh SDK v2.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) for more information how to download and use the Silicon Labs Bluetooth Mesh application. + + Mobile Phone provisioning is illustrated in the following figure. + +![Bluetooth Mesh start screen](readme_img6.png) + +5. Open the app and choose the Provision Browser and tap **Scan**. The device sending unprovisioned beacons should appear, tap **PROVISION**: + +![Bluetooth Mesh Provision Browser](readme_img2.png) + +6. Start provisioning using the "Continue" button: + +![Bluetooth Mesh Provisioning Device](readme_img3.png) + +7. Configure the device as "Sensor Client" and select the correct group to which the messages will subscribe (Demo group). + +![Bluetooth Mesh Device Configuration](readme_img4.png) + +8. Once the node is provisioned and correctly configured, it is ready to function in your demo network. + +![Sensor client with Proxy connection](readme_img5.png) + +9. The next step is to add a sensor server or several into your network, if it has not already been done. This is required to fully test the whole system. Read the applicable example project documentation to learn more. + +For more information on the example, please refer to [AN1300: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Sensor Model Demonstration](https://www.silabs.com/documents/public/application-notes/an1300-understanding-bluetooth-mesh-sensor-model-demo-sdk-2x.pdf). + +The button presses in this example: + +- Short presses will update the registered devices +- Long press of PB0 will change the current property + +## Troubleshooting + +Note that **NO** Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image. + +- The **Bluetooth Mesh - SoC Switch** demo includes an OTA DFU-capable bootloader. +- The **Bluetooth Mesh - NCP Empty** demo includes a UART DFU-capable bootloader. +- For other bootloader types, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103.6: Bootloader Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher](https://www.silabs.com/documents/public/user-guides/ug489-gecko-bootloader-user-guide-gsdk-4.pdf)*. + +Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf) + +[QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) + +[AN1315: Bluetooth Mesh Device Power Consumption Measurements](https://www.silabs.com/documents/public/application-notes/an1315-bluetooth-mesh-power-consumption-measurements.pdf) + +[AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization](https://www.silabs.com/documents/public/application-notes/an1316-bluetooth-mesh-network-optimization.pdf) + +[AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh](https://www.silabs.com/documents/public/application-notes/an1317-network-analyzer-with-bluetooth-mesh-le.pdf) + +[AN1318: IV Update in a Bluetooth Mesh Network](https://www.silabs.com/documents/public/application-notes/an1318-bluetooth-mesh-iv-update.pdf) + +[AN1300: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Sensor Model Demonstration](https://www.silabs.com/documents/public/application-notes/an1300-understanding-bluetooth-mesh-sensor-model-demo-sdk-2x.pdf) + +[UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) + +[UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). diff --git a/app/bluetooth/documentation/example/soc_btmesh_sensor_server/readme.html b/app/bluetooth/documentation/example/soc_btmesh_sensor_server/readme.html deleted file mode 100644 index 075b5ff8ba7..00000000000 --- a/app/bluetooth/documentation/example/soc_btmesh_sensor_server/readme.html +++ /dev/null @@ -1,598 +0,0 @@ - - - - - -readme - -
-

Bluetooth Mesh - SoC Sensor Server

The Bluetooth Mesh - SoC Sensor Server example is a working example application that you can use as a template for Bluetooth Mesh Sensor Server applications.

The example demonstrates the Bluetooth Mesh Sensor Server Model and Sensor Setup Server Model. It measures temperature and people count (and also illuminance with some parts such as Thunderboard Sense 2 and Thunderboard EFR32BG22) and sends the measurement data to a remote device (for example, Bluetooth Mesh - SoC Sensor Client). The current status is displayed on the LCD (if one is present on the mainboard) and also sent to UART. CLI commands may substitute for button presses if the mainboard has only one button available. This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory.

Bluetooth Mesh sensor system - Server

Getting Started

To learn Bluetooth mesh technology basics, see Bluetooth Mesh Network - An Introduction for Developers.

To get started with Bluetooth Mesh and Simplicity Studio, see QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide.

The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate.

Bluetooth Mesh - SoC Sensor Server example makes various sensor measurements and forwards them to another node implementing the sensor client. This example measures and displays occupancy (people count) sensor data, temperature data and illuminance (on Thunderboard Sense 2).

To add or remove features from the example, follow this process:

  • Add model and feature components to your project
  • Optionally configure your Mesh node through the "Bluetooth Mesh Configurator"

Bluetooth Mesh Configurator

To learn more about programming an SoC application, see UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x.

  • Some components are configurable, and can be customized using the Component Editor

Bluetooth Mesh Components

  • Respond to the events raised by the Bluetooth stack
  • Implement additional application logic

UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x gives code-level information on the stack and the common pitfalls to avoid.

Testing the Bluetooth Mesh - SoC Light Application

To test the application, do the following:

  1. Make sure a bootloader is installed. See Troubleshooting section.

  2. Build and flash the Bluetooth Mesh - SoC Sensor Server sample app to your device.

  3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen.

  4. Provision the device in one of three ways:

    Mobile Phone provisioning is illustrated in the following figure.

Bluetooth Mesh start screen

  1. Open the app and choose the Provision Browser and tap Scan. The device sending unprovisioned beacons should appear, tap PROVISION:

Bluetooth Mesh Provision Browser

  1. Start provisioning using the "Continue" button:

Bluetooth Mesh Provisioning Device

  1. Configure the device as "Sensor Server" (inheriting the server setup model) and select the correct group to which the messages will subscribe (Demo group).

Bluetooth Mesh Device Configuration

  1. Once the node is provisioned and correctly configured, it is ready to function in your demo network.

Sensor server with Proxy connection

  1. The next step is to add a sensor client or several into your network, if it has not already been done. This is required to fully test the whole system. Read the applicable example project documentation to learn more.

For more information on the example, please refer to AN1300: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Sensor Model Demonstration.

The button presses in this example:

  • Short presses will control the People Count value
  • Medium press will control the People Count value (only one button devices)

Troubleshooting

Note that NO Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image.

  • The Bluetooth Mesh - SoC Switch demo includes an OTA DFU-capable bootloader.
  • The Bluetooth Mesh - NCP Empty demo includes a UART DFU-capable bootloader.
  • For other bootloader types, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103.6: Bootloader Fundamentals and UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

Resources

Bluetooth Documentation

Bluetooth Mesh Network - An Introduction for Developers

QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide

AN1315: Bluetooth Mesh Device Power Consumption Measurements

AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization

AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh

AN1318: IV Update in a Bluetooth Mesh Network

AN1300: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Sensor Model Demonstration

UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x

UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_btmesh_sensor_server/readme.md b/app/bluetooth/documentation/example/soc_btmesh_sensor_server/readme.md new file mode 100644 index 00000000000..dd16571a08e --- /dev/null +++ b/app/bluetooth/documentation/example/soc_btmesh_sensor_server/readme.md @@ -0,0 +1,122 @@ +# Bluetooth Mesh - SoC Sensor Server + +The **Bluetooth Mesh - SoC Sensor Server** example is a working example application that you can use as a template for Bluetooth Mesh Sensor Server applications. + +The example demonstrates the Bluetooth Mesh **Sensor Server Model** and **Sensor Setup Server Model**. It measures temperature and people count (and also illuminance with some parts such as *Thunderboard Sense 2* and *Thunderboard EFR32BG22*) and sends the measurement data to a remote device (for example, **Bluetooth Mesh - SoC Sensor Client**). The current status is displayed on the LCD (if one is present on the mainboard) and also sent to UART. CLI commands may substitute for button presses if the mainboard has only one button available. This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory. + +![Bluetooth Mesh sensor system - Server](readme_img7.png) + +## Getting Started + +To learn Bluetooth mesh technology basics, see [Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf). + +To get started with Bluetooth Mesh and Simplicity Studio, see [QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf). + +The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate. + +**Bluetooth Mesh - SoC Sensor Server** example makes various sensor measurements and forwards them to another node implementing the sensor client. This example measures and displays occupancy (people count) sensor data, temperature data and illuminance (on Thunderboard Sense 2). + +To add or remove features from the example, follow this process: + +- Add model and feature components to your project +- Optionally configure your Mesh node through the "Bluetooth Mesh Configurator" + +![Bluetooth Mesh Configurator](readme_img1.png) + +To learn more about programming an SoC application, see [UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug472-bluetooth-mesh-v2x-node-configuration-users-guide.pdf). + +- Some components are configurable, and can be customized using the Component Editor + +![Bluetooth Mesh Components](readme_img8.png) + +- Respond to the events raised by the Bluetooth stack +- Implement additional application logic + +[UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) gives code-level information on the stack and the common pitfalls to avoid. + +## Testing the Bluetooth Mesh - SoC Light Application + +To test the application, do the following: + +1. Make sure a bootloader is installed. See Troubleshooting section. +2. Build and flash the **Bluetooth Mesh - SoC Sensor Server** sample app to your device. +3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen. +4. Provision the device in one of three ways: + + - NCP Host provisioner examples, see for example an SDK folder `app/bluetooth/example_host/btmesh_provisioner` or [github](https://github.com/SiliconLabs/bluetooth_mesh_stack_features/tree/master/provisioning) + + - NCP Commander with NCP target device, see [Bluetooth NCP Commander guide](https://docs.silabs.com/simplicity-studio-5-users-guide/latest/ss-5-users-guide-tools-bluetooth-ncp-commander) or [AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) + + - For Mobile Phone use, see the [QSG176: Bluetooth® Mesh SDK v2.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) for more information how to download and use the Silicon Labs Bluetooth Mesh application. + + Mobile Phone provisioning is illustrated in the following figure. + +![Bluetooth Mesh start screen](readme_img6.png) + +5. Open the app and choose the Provision Browser and tap **Scan**. The device sending unprovisioned beacons should appear, tap **PROVISION**: + +![Bluetooth Mesh Provision Browser](readme_img2.png) + +6. Start provisioning using the "Continue" button: + +![Bluetooth Mesh Provisioning Device](readme_img3.png) + +7. Configure the device as "Sensor Server" (inheriting the server setup model) and select the correct group to which the messages will subscribe (Demo group). + +![Bluetooth Mesh Device Configuration](readme_img4.png) + +8. Once the node is provisioned and correctly configured, it is ready to function in your demo network. + +![Sensor server with Proxy connection](readme_img5.png) + +9. The next step is to add a sensor client or several into your network, if it has not already been done. This is required to fully test the whole system. Read the applicable example project documentation to learn more. + +For more information on the example, please refer to [AN1300: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Sensor Model Demonstration](https://www.silabs.com/documents/public/application-notes/an1300-understanding-bluetooth-mesh-sensor-model-demo-sdk-2x.pdf). + +The button presses in this example: + +- Short presses will control the People Count value +- Medium press will control the People Count value (only one button devices) + +## Troubleshooting + +Note that **NO** Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image. + +- The **Bluetooth Mesh - SoC Switch** demo includes an OTA DFU-capable bootloader. +- The **Bluetooth Mesh - NCP Empty** demo includes a UART DFU-capable bootloader. +- For other bootloader types, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103.6: Bootloader Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher](https://www.silabs.com/documents/public/user-guides/ug489-gecko-bootloader-user-guide-gsdk-4.pdf)*. + +Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf) + +[QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) + +[AN1315: Bluetooth Mesh Device Power Consumption Measurements](https://www.silabs.com/documents/public/application-notes/an1315-bluetooth-mesh-power-consumption-measurements.pdf) + +[AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization](https://www.silabs.com/documents/public/application-notes/an1316-bluetooth-mesh-network-optimization.pdf) + +[AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh](https://www.silabs.com/documents/public/application-notes/an1317-network-analyzer-with-bluetooth-mesh-le.pdf) + +[AN1318: IV Update in a Bluetooth Mesh Network](https://www.silabs.com/documents/public/application-notes/an1318-bluetooth-mesh-iv-update.pdf) + +[AN1300: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Sensor Model Demonstration](https://www.silabs.com/documents/public/application-notes/an1300-understanding-bluetooth-mesh-sensor-model-demo-sdk-2x.pdf) + +[UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) + +[UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). diff --git a/app/bluetooth/documentation/example/soc_btmesh_switch/readme.html b/app/bluetooth/documentation/example/soc_btmesh_switch/readme.html deleted file mode 100644 index 73e974b6991..00000000000 --- a/app/bluetooth/documentation/example/soc_btmesh_switch/readme.html +++ /dev/null @@ -1,598 +0,0 @@ - - - - - -readme - -
-

Bluetooth Mesh - SoC Switch

The Bluetooth Mesh - SoC Switch example is a working example application that you can use as a template for Bluetooth Mesh Switch applications.

The example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Button presses on the mainboard or CLI commands can control the state, lightness, and color temperature of the LEDs as well as scenes on a remote device (for example Bluetooth Mesh - SoC Light). The example also acts as an LPN and tries to establish friendship. The status messages are displayed on the LCD (if one is present on the mainboard) and also sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, the Light CTL Client Model, and the Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory.

In typical cases use the Bluetooth Mesh - SoC Switch example as it is easier to get feedback about the state and operations. But if you want to have the optimal power consumption, use the Bluetooth Mesh - SoC Switch Low Power example which does not have LCD, CLI or logging. Use that for especially for the power consumption measurements.

The switch requires friend node to function properly.

Bluetooth Mesh lighting system - Switch

Getting Started

To learn Bluetooth mesh technology basics, see Bluetooth Mesh Network - An Introduction for Developers.

To get started with Bluetooth Mesh and Simplicity Studio, see QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide.

The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate.

This is an example of a Low Power Node enabled Bluetooth Mesh switch application. Once the node is provisioned and a light server (light node) subscribes to the client, the two buttons of the mainboard are used to publish the messages that will change the light lightness on the server.

We can use the buttons many other ways using the different models of this example:

  • Generic OnOff Client model can turn the light on and off or toggle
  • Generic Level Client model can control the light brightness
  • Light Lightness Client model can control the light Lightness
  • Light CTL Client model can control light Lightness and Color Temperature (Delta UV only virtually)
  • Scene Server model allows customer to recall the light settings

A friendship with a light node has to be established for the switch node to start the sleep/poll cycles.

To add or remove features from the example, follow this process:

  • Add model and feature components to your project
  • Optionally configure your Mesh node through the "Bluetooth Mesh Configurator"

Bluetooth Mesh Configurator

To learn more about programming an SoC application, see UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x.

  • Some components are configurable, and can be customized using the Component Editor

Bluetooth Mesh Components

  • Respond to the events raised by the Bluetooth stack
  • Implement additional application logic

UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x gives code-level information on the stack and the common pitfalls to avoid.

Testing the Bluetooth Mesh - SoC Switch Application

To test the application, do the following:

  1. Make sure a bootloader is installed. See Troubleshooting section.

  2. Build and flash the Bluetooth Mesh - SoC Switch sample app to your device.

  3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen.

  4. Provision the device in one of three ways:

    Mobile Phone provisioning is illustrated in the following figure.

Bluetooth Mesh start screen

  1. Open the app and choose the Provision Browser and tap Scan.

Bluetooth Mesh Provision Browser

  1. Tap PROVISION and continue provisioning.

Bluetooth Mesh Provisioning Device

  1. Select the right "Group" and then tap the "Functionality" menu.

Bluetooth Mesh Device Configuration

  1. Configure the device as Light CTL Client. If you want to test the Bluetooth Mesh Generic OnOff Model, the Light Lightness Model, the Scene Model or some other Mesh Model, then select the respective client instead. You can use only one at a time in our mobile application. With the SoC Light HSL demo use the Light Lightness Client.

Bluetooth Mesh Functionalities

  1. The next step is to add a light or several lights into your network, if it has not already been done. This is required to fully test the whole system, for example the friendship and other features. You can then control the Bluetooth Mesh - SoC Light and Bluetooth Mesh - SoC HSL Light examples by pressing the buttons in the device. Read the applicable example project documentation to learn more.

For more information on the example, please refer to AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration.

The button presses in this example:

  • Short press will control the Lightness (Light Lightness Client and Light CTL Client models)
  • Medium press will control the Color Temperature (Light CTL Client model)
  • Long press will control the light On/Off (all Lighting models)
  • Very long press will recall the scenes (only when Scene Server model is configured)

Troubleshooting

Note that NO Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image.

  • The Bluetooth Mesh - SoC Switch demo includes an OTA DFU-capable bootloader.
  • The Bluetooth Mesh - NCP Empty demo includes a UART DFU-capable bootloader.
  • For other bootloader types, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103.6: Bootloader Fundamentals and UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

Resources

Bluetooth Documentation

Bluetooth Mesh Network - An Introduction for Developers

QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide

AN1315: Bluetooth Mesh Device Power Consumption Measurements

AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization

AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh

AN1318: IV Update in a Bluetooth Mesh Network

AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration

UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x

UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_btmesh_switch/readme.md b/app/bluetooth/documentation/example/soc_btmesh_switch/readme.md new file mode 100644 index 00000000000..0e845d06544 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_btmesh_switch/readme.md @@ -0,0 +1,138 @@ +# Bluetooth Mesh - SoC Switch + +The **Bluetooth Mesh - SoC Switch** example is a working example application that you can use as a template for Bluetooth Mesh Switch applications. + +The example is an out-of-the-box Software Demo optimized for user experience where the device acts as a switch. Button presses on the mainboard or CLI commands can control the state, lightness, and color temperature of the LEDs as well as scenes on a remote device (for example **Bluetooth Mesh - SoC Light**). The example also acts as an LPN and tries to establish friendship. The status messages are displayed on the LCD (if one is present on the mainboard) and also sent to UART. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, the Light CTL Client Model, and the Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory. + +In typical cases use the **Bluetooth Mesh - SoC Switch** example as it is easier to get feedback about the state and operations. But if you want to have the optimal power consumption, use the **Bluetooth Mesh - SoC Switch Low Power** example which does not have LCD, CLI or logging. Use that for especially for the power consumption measurements. + +The switch requires friend node to function properly. + +![Bluetooth Mesh lighting system - Switch](readme_img7.png) + +## Getting Started + +To learn Bluetooth mesh technology basics, see [Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf). + +To get started with Bluetooth Mesh and Simplicity Studio, see [QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf). + +The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate. + +This is an example of a Low Power Node enabled Bluetooth Mesh switch application. Once the node is provisioned and a light server (light node) subscribes to the client, the two buttons of the mainboard are used to publish the messages that will change the light lightness on the server. + +We can use the buttons many other ways using the different models of this example: + +- **Generic OnOff Client** model can turn the light on and off or toggle +- **Generic Level Client** model can control the light brightness +- **Light Lightness Client** model can control the light Lightness +- **Light CTL Client** model can control light Lightness and Color Temperature (Delta UV only virtually) +- **Scene Server** model allows customer to recall the light settings + +A friendship with a light node has to be established for the switch node to start the sleep/poll cycles. + +To add or remove features from the example, follow this process: + +- Add model and feature components to your project +- Optionally configure your Mesh node through the "Bluetooth Mesh Configurator" + +![Bluetooth Mesh Configurator](readme_img1.png) + +To learn more about programming an SoC application, see [UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug472-bluetooth-mesh-v2x-node-configuration-users-guide.pdf). + +- Some components are configurable, and can be customized using the Component Editor + +![Bluetooth Mesh Components](readme_img8.png) + +- Respond to the events raised by the Bluetooth stack +- Implement additional application logic + +[UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) gives code-level information on the stack and the common pitfalls to avoid. + +## Testing the Bluetooth Mesh - SoC Switch Application + +To test the application, do the following: + +1. Make sure a bootloader is installed. See Troubleshooting section. +2. Build and flash the **Bluetooth Mesh - SoC Switch** sample app to your device. +3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen. +4. Provision the device in one of three ways: + + - NCP Host provisioner examples, see for example an SDK folder `app/bluetooth/example_host/btmesh_provisioner` or [github](https://github.com/SiliconLabs/bluetooth_mesh_stack_features/tree/master/provisioning) + + - NCP Commander with NCP target device, see [Bluetooth NCP Commander guide](https://docs.silabs.com/simplicity-studio-5-users-guide/latest/ss-5-users-guide-tools-bluetooth-ncp-commander) or [AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) + + - For Mobile Phone use, see the [QSG176: Bluetooth® Mesh SDK v2.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) for more information how to download and use the Silicon Labs Bluetooth Mesh application. + + Mobile Phone provisioning is illustrated in the following figure. + +![Bluetooth Mesh start screen](readme_img6.png) + +5. Open the app and choose the Provision Browser and tap **Scan**. + +![Bluetooth Mesh Provision Browser](readme_img2.png) + +6. Tap **PROVISION** and continue provisioning. + +![Bluetooth Mesh Provisioning Device](readme_img3.png) + +7. Select the right "Group" and then tap the "Functionality" menu. + +![Bluetooth Mesh Device Configuration](readme_img4.png) + +8. Configure the device as **Light CTL Client**. If you want to test the Bluetooth Mesh Generic OnOff Model, the Light Lightness Model, the Scene Model or some other Mesh Model, then select the respective client instead. You can use only one at a time in our mobile application. With the **SoC Light HSL** demo use the Light Lightness Client. + +![Bluetooth Mesh Functionalities](readme_img5.png) + +9. The next step is to add a light or several lights into your network, if it has not already been done. This is required to fully test the whole system, for example the friendship and other features. You can then control the **Bluetooth Mesh - SoC Light** and **Bluetooth Mesh - SoC HSL Light** examples by pressing the buttons in the device. Read the applicable example project documentation to learn more. + +For more information on the example, please refer to [AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration](https://www.silabs.com/documents/public/application-notes/an1299-understanding-bluetooth-mesh-lighting-demo-sdk-2x.pdf). + +The button presses in this example: + +- Short press will control the Lightness (**Light Lightness Client** and **Light CTL Client** models) +- Medium press will control the Color Temperature (**Light CTL Client** model) +- Long press will control the light On/Off (all Lighting models) +- Very long press will recall the scenes (only when **Scene Server** model is configured) + +## Troubleshooting + +Note that **NO** Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image. + +- The **Bluetooth Mesh - SoC Switch** demo includes an OTA DFU-capable bootloader. +- The **Bluetooth Mesh - NCP Empty** demo includes a UART DFU-capable bootloader. +- For other bootloader types, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103.6: Bootloader Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher](https://www.silabs.com/documents/public/user-guides/ug489-gecko-bootloader-user-guide-gsdk-4.pdf)*. + +Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf) + +[QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) + +[AN1315: Bluetooth Mesh Device Power Consumption Measurements](https://www.silabs.com/documents/public/application-notes/an1315-bluetooth-mesh-power-consumption-measurements.pdf) + +[AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization](https://www.silabs.com/documents/public/application-notes/an1316-bluetooth-mesh-network-optimization.pdf) + +[AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh](https://www.silabs.com/documents/public/application-notes/an1317-network-analyzer-with-bluetooth-mesh-le.pdf) + +[AN1318: IV Update in a Bluetooth Mesh Network](https://www.silabs.com/documents/public/application-notes/an1318-bluetooth-mesh-iv-update.pdf) + +[AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration](https://www.silabs.com/documents/public/application-notes/an1299-understanding-bluetooth-mesh-lighting-demo-sdk-2x.pdf) + +[UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) + +[UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). diff --git a/app/bluetooth/documentation/example/soc_btmesh_switch/readme_low_power.html b/app/bluetooth/documentation/example/soc_btmesh_switch/readme_low_power.html deleted file mode 100644 index 7d6d1adc3d8..00000000000 --- a/app/bluetooth/documentation/example/soc_btmesh_switch/readme_low_power.html +++ /dev/null @@ -1,600 +0,0 @@ - - - - - -readme_low_power - -
-

Bluetooth Mesh - SoC Switch Low Power

The Bluetooth Mesh - SoC Switch Low Power example is a working example application that you can use as a template for Bluetooth Mesh Switch Low Power applications.

The example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging, and LCD. Button presses on the mainboard can control the state, lightness, and color temperature of the LEDs as well as scenes on a remote device (Bluetooth Mesh - SoC Light). The example also acts as an LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, the Light CTL Client Model, and the Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory.

In typical cases use the Bluetooth Mesh - SoC Switch example as it is easier to get feedback about the state and operations. But if you want to have the optimal power consumption, use the Bluetooth Mesh - SoC Switch Low Power example which does not have LCD, CLI or logging. Use that for especially for the power consumption measurements.

The switch requires friend node to function properly. -Bluetooth Mesh lighting system - Switch

Getting Started

To learn Bluetooth mesh technology basics, see Bluetooth Mesh Network - An Introduction for Developers.

To get started with Bluetooth Mesh and Simplicity Studio, see QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide.

The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate.

This is an example of a Low Power Node enabled energy efficient Bluetooth Mesh switch application. The example removes LCD display and logging features. For more information on how to measure power consumption, see AN1315: Bluetooth Mesh Device Power Consumption Measurements. Once the node is provisioned and a light server (light node) subscribes to the client, the two buttons of the mainboard are used to publish the messages that will change the light lightness on the server.

We can use the buttons many other ways using the different models of this example:

  • Generic OnOff Client model can turn the light on and off or toggle
  • Generic Level Client model can control the light brightness
  • Light Lightness Client model can control the light Lightness
  • Light CTL Client model can control light Lightness and Color Temperature (Delta UV only virtually)
  • Scene Server model allows customer to recall the light settings

A friendship with a light node has to be established for the switch node to start the sleep/poll cycles.

To add or remove features from the example, follow this process:

  • Add model and feature components to your project
  • Optionally configure your Mesh node through the "Bluetooth Mesh Configurator"

Bluetooth Mesh Configurator

To learn more about programming an SoC application, see UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x.

  • Some components are configurable, and can be customized using the Component Editor

Bluetooth Mesh Components

  • Respond to the events raised by the Bluetooth stack
  • Implement additional application logic

UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x gives code-level information on the stack and the common pitfalls to avoid.

Testing the Bluetooth Mesh - SoC Switch Low Power Application

To test the application, do the following:

  1. Make sure a bootloader is installed. See Troubleshooting section.

  2. Build and flash the Bluetooth Mesh - SoC Switch Low Power sample app to your device.

  3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen.

  4. Provision the device in one of three ways:

    Mobile Phone provisioning is illustrated in the following figure.

Bluetooth Mesh start screen

  1. Open the app and choose the Provision Browser and tap Scan.

Bluetooth Mesh Provision Browser

  1. Tap PROVISION and continue provisioning.

Bluetooth Mesh Provisioning Device

  1. Select the right "Group" and then tap the "Functionality" menu.

Bluetooth Mesh Device Configuration

  1. Configure the device as Light CTL Client. If you want to test the Bluetooth Mesh Generic OnOff Model, the Light Lightness Model, the Scene Model or some other Mesh Model, then select the respective client instead. You can use only one at a time in our mobile application. With the SoC Light HSL demo use the Light Lightness Client.

Bluetooth Mesh Functionalities

  1. The next step is to add a light or several lights into your network, if it has not already been done. This is required to fully test the whole system, for example the friendship and other features. You can then control the Bluetooth Mesh - SoC Light and Bluetooth Mesh - SoC HSL Light examples by pressing the buttons in the device. Read the applicable example project documentation to learn more. -For more information on the example, please refer to AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration.

The button presses in this example:

  • Short press will control the Lightness (Light Lightness Client and Light CTL Client models)
  • Medium press will control the Color Temperature (Light CTL Client model)
  • Long press will control the light On/Off (all Lighting models)
  • Very long press will recall the scenes (only when Scene Server model is configured)

Troubleshooting

Note that NO Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image.

  • The Bluetooth Mesh - SoC Switch demo includes an OTA DFU-capable bootloader.
  • The Bluetooth Mesh - NCP Empty demo includes a UART DFU-capable bootloader.
  • For other bootloader types, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103.6: Bootloader Fundamentals and UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

Resources

Bluetooth Documentation

Bluetooth Mesh Network - An Introduction for Developers

QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide

AN1315: Bluetooth Mesh Device Power Consumption Measurements

AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization

AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh

AN1318: IV Update in a Bluetooth Mesh Network

AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration

UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x

UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_btmesh_switch/readme_low_power.md b/app/bluetooth/documentation/example/soc_btmesh_switch/readme_low_power.md new file mode 100644 index 00000000000..c0a8534a905 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_btmesh_switch/readme_low_power.md @@ -0,0 +1,136 @@ +# Bluetooth Mesh - SoC Switch Low Power + +The **Bluetooth Mesh - SoC Switch Low Power** example is a working example application that you can use as a template for Bluetooth Mesh Switch Low Power applications. + +The example is an out-of-the-box Software Demo optimized for low current consumption where the device acts as a switch. It has disabled CLI, logging, and LCD. Button presses on the mainboard can control the state, lightness, and color temperature of the LEDs as well as scenes on a remote device (Bluetooth Mesh - SoC Light). The example also acts as an LPN and tries to establish friendship. The example is based on the Bluetooth Mesh Generic On/Off Client Model, the Light Lightness Client Model, the Light CTL Client Model, and the Scene Client Model. This example requires one of the Internal Storage Bootloader (single image) variants, depending on device memory. + +In typical cases use the **Bluetooth Mesh - SoC Switch** example as it is easier to get feedback about the state and operations. But if you want to have the optimal power consumption, use the **Bluetooth Mesh - SoC Switch Low Power** example which does not have LCD, CLI or logging. Use that for especially for the power consumption measurements. + +The switch requires friend node to function properly. +![Bluetooth Mesh lighting system - Switch](readme_img7.png) + +## Getting Started + +To learn Bluetooth mesh technology basics, see [Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf). + +To get started with Bluetooth Mesh and Simplicity Studio, see [QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf). + +The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate. + +This is an example of a Low Power Node enabled energy efficient Bluetooth Mesh switch application. The example removes LCD display and logging features. For more information on how to measure power consumption, see [AN1315: Bluetooth Mesh Device Power Consumption Measurements](https://www.silabs.com/documents/public/application-notes/an1315-bluetooth-mesh-power-consumption-measurements.pdf). Once the node is provisioned and a light server (light node) subscribes to the client, the two buttons of the mainboard are used to publish the messages that will change the light lightness on the server. + +We can use the buttons many other ways using the different models of this example: + +- **Generic OnOff Client** model can turn the light on and off or toggle +- **Generic Level Client** model can control the light brightness +- **Light Lightness Client** model can control the light Lightness +- **Light CTL Client** model can control light Lightness and Color Temperature (Delta UV only virtually) +- **Scene Server** model allows customer to recall the light settings + +A friendship with a light node has to be established for the switch node to start the sleep/poll cycles. + +To add or remove features from the example, follow this process: + +- Add model and feature components to your project +- Optionally configure your Mesh node through the "Bluetooth Mesh Configurator" + +![Bluetooth Mesh Configurator](readme_img1.png) + +To learn more about programming an SoC application, see [UG472: Silicon Labs Bluetooth ® Mesh Configurator User's guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug472-bluetooth-mesh-v2x-node-configuration-users-guide.pdf). + +- Some components are configurable, and can be customized using the Component Editor + +![Bluetooth Mesh Components](readme_img8.png) + +- Respond to the events raised by the Bluetooth stack +- Implement additional application logic + +[UG295: Silicon Labs Bluetooth ® Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) gives code-level information on the stack and the common pitfalls to avoid. + +## Testing the Bluetooth Mesh - SoC Switch Low Power Application + +To test the application, do the following: + +1. Make sure a bootloader is installed. See Troubleshooting section. +2. Build and flash the Bluetooth Mesh - SoC Switch Low Power sample app to your device. +3. Reset the device by pressing and releasing the reset button on the mainboard while pressing BTN0. The message "Factory reset" should appear on the LCD screen. +4. Provision the device in one of three ways: + + - NCP Host provisioner examples, see for example an SDK folder `app/bluetooth/example_host/btmesh_provisioner` or [github](https://github.com/SiliconLabs/bluetooth_mesh_stack_features/tree/master/provisioning) + + - NCP Commander with NCP target device, see [Bluetooth NCP Commander guide](https://docs.silabs.com/simplicity-studio-5-users-guide/latest/ss-5-users-guide-tools-bluetooth-ncp-commander) or [AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) + + - For Mobile Phone use, see the [QSG176: Bluetooth® Mesh SDK v2.x Quick-Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) for more information how to download and use the Silicon Labs Bluetooth Mesh application. + + Mobile Phone provisioning is illustrated in the following figure. + +![Bluetooth Mesh start screen](readme_img6.png) + +5. Open the app and choose the Provision Browser and tap **Scan**. + +![Bluetooth Mesh Provision Browser](readme_img2.png) + +6. Tap **PROVISION** and continue provisioning. + +![Bluetooth Mesh Provisioning Device](readme_img3.png) + +7. Select the right "Group" and then tap the "Functionality" menu. + +![Bluetooth Mesh Device Configuration](readme_img4.png) + +8. Configure the device as **Light CTL Client**. If you want to test the Bluetooth Mesh Generic OnOff Model, the Light Lightness Model, the Scene Model or some other Mesh Model, then select the respective client instead. You can use only one at a time in our mobile application. With the **SoC Light HSL** demo use the Light Lightness Client. + +![Bluetooth Mesh Functionalities](readme_img5.png) + +9. The next step is to add a light or several lights into your network, if it has not already been done. This is required to fully test the whole system, for example the friendship and other features. You can then control the **Bluetooth Mesh - SoC Light** and **Bluetooth Mesh - SoC HSL Light** examples by pressing the buttons in the device. Read the applicable example project documentation to learn more. +For more information on the example, please refer to [AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration](https://www.silabs.com/documents/public/application-notes/an1299-understanding-bluetooth-mesh-lighting-demo-sdk-2x.pdf). + +The button presses in this example: + +- Short press will control the Lightness (**Light Lightness Client** and **Light CTL Client** models) +- Medium press will control the Color Temperature (**Light CTL Client** model) +- Long press will control the light On/Off (all Lighting models) +- Very long press will recall the scenes (only when **Scene Server** model is configured) + +## Troubleshooting + +Note that **NO** Bootloader is included in any example projects, but they are configured to expect a bootloader to be present on the device. To install a bootloader, from the Launcher perspective's EXAMPLE PROJECTS & DEMOS tab either build and flash one of the bootloader examples or run one of the precompiled demos. Precompiled demos flash a bootloader as well as the application image. + +- The **Bluetooth Mesh - SoC Switch** demo includes an OTA DFU-capable bootloader. +- The **Bluetooth Mesh - NCP Empty** demo includes a UART DFU-capable bootloader. +- For other bootloader types, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103.6: Bootloader Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher](https://www.silabs.com/documents/public/user-guides/ug489-gecko-bootloader-user-guide-gsdk-4.pdf)*. + +Before programming the radio board mounted on the mainboard, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[Bluetooth Mesh Network - An Introduction for Developers](https://www.bluetooth.com/wp-content/uploads/2019/03/Mesh-Technology-Overview.pdf) + +[QSG176: Bluetooth® Mesh SDK v2.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg176-bluetooth-mesh-sdk-v2x-quick-start-guide.pdf) + +[AN1315: Bluetooth Mesh Device Power Consumption Measurements](https://www.silabs.com/documents/public/application-notes/an1315-bluetooth-mesh-power-consumption-measurements.pdf) + +[AN1316: Bluetooth Mesh Parameter Tuning for Network Optimization](https://www.silabs.com/documents/public/application-notes/an1316-bluetooth-mesh-network-optimization.pdf) + +[AN1317: Using Network Analyzer with Bluetooth Low Energy ® and Mesh](https://www.silabs.com/documents/public/application-notes/an1317-network-analyzer-with-bluetooth-mesh-le.pdf) + +[AN1318: IV Update in a Bluetooth Mesh Network](https://www.silabs.com/documents/public/application-notes/an1318-bluetooth-mesh-iv-update.pdf) + +[AN1299: Understanding the Silicon Labs Bluetooth Mesh SDK v2.x Lighting Demonstration](https://www.silabs.com/documents/public/application-notes/an1299-understanding-bluetooth-mesh-lighting-demo-sdk-2x.pdf) + +[UG295: Silicon Labs Bluetooth Mesh C Application Developer's Guide for SDK v2.x](https://www.silabs.com/documents/public/user-guides/ug295-bluetooth-mesh-dev-guide.pdf) + +[UG472: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). diff --git a/app/bluetooth/documentation/example/soc_dtm/readme.html b/app/bluetooth/documentation/example/soc_dtm/readme.html deleted file mode 100644 index 9a78adaf4a4..00000000000 --- a/app/bluetooth/documentation/example/soc_dtm/readme.html +++ /dev/null @@ -1,553 +0,0 @@ - - - - -readme - - -

SoC - DTM

This sample application provides the Direct Test Mode (DTM) through a 2-wire UART interface for the RF PHY testing of a Bluetooth Low Energy device.

Direct Test Mode (DTM) Overview

DTM is typically used with a separate Bluetooth Tester device.

DTM can be used either through a 2-wire UART interface, as described in this example, or over HCI, which is currently not supported. The 2-wire UART interface uses baud rates from 1200 up to 115200 bps (the default) always with 8 data bits, no parity, 1 stop bit and without flow control (no RTS nor CTS).

Connecting the Bluetooth Tester to the WSTK

DTM can be also used without a separate Bluetooth Tester device when testing more manually with a spectrum analyzer and signal generators setup by sending the command bytes with a special terminal. For an easier usage in this setup, it is also good to consider using the BGTool desktop application instead, which uses the NCP-mode BGAPI-interface.

Although the DTM is defined for the Bluetooth Qualifications, it can be used to run most of the Regulatory Certification tests.

Typical use cases for the DTM:

  • SoCs:

    • Regulatory Certifications testing
    • RF-PHY testing for the Bluetooth Qualification if the design does not match the reference design
    • Production testing

  • Modules:

    • Regulatory Certifications testing (required for the modules in Europe)
    • Spot checks (strongly recommended by FCC)
    • RF-PHY testing for the Bluetooth Qualification if the design might affect the module operation
    • Production testing

  • Radio Boards with WSTK:

    • Mostly for getting to know the DTM overall and testing the setup
    • Typically not much practical usage

For more information about using the DTM, see the following documents:

The full DTM specification can be found here:

Getting Started

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

The instructions to create and flash the DTM example application are in the AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v3.x. The same document contains information about customizing UART pins for your own hardware and examples about using the DTM.

Detailed specifications are in the Bluetooth Specifications.

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

Note! With the WSTK and the Radio Board, the DTM example uses EXP-header UART pins by default and not the USB UART as most of the other examples. Also, the default is no flow control.

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v3.x

Bluetooth® Core Specification Adopted Version 5.2, Vol 6: Low Energy Controller, Part F: Direct Test Mode

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_dtm/readme.md b/app/bluetooth/documentation/example/soc_dtm/readme.md new file mode 100644 index 00000000000..68746e935cd --- /dev/null +++ b/app/bluetooth/documentation/example/soc_dtm/readme.md @@ -0,0 +1,87 @@ +# SoC - DTM + +This sample application provides the Direct Test Mode (DTM) through a 2-wire UART interface for the RF PHY testing of a Bluetooth Low Energy device. + +## Direct Test Mode (DTM) Overview + +DTM is typically used with a separate Bluetooth Tester device. + +DTM can be used either through a 2-wire UART interface, as described in this example, or over HCI, which is currently not supported. The 2-wire UART interface uses baud rates from 1200 up to 115200 bps (the default) always with 8 data bits, no parity, 1 stop bit and without flow control (no RTS nor CTS). + +![Connecting the Bluetooth Tester to the WSTK](readme_img1.png) + +DTM can be also used without a separate Bluetooth Tester device when testing more manually with a spectrum analyzer and signal generators setup by sending the command bytes with a special terminal. For an easier usage in this setup, it is also good to consider using the [BGTool](https://www.silabs.com/documents/public/application-notes/an1267-bt-rf-phy-evaluation-using-dtm-sdk-v3x.pdf) desktop application instead, which uses the [NCP-mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) [BGAPI](https://docs.silabs.com/bluetooth/latest)-interface. + +Although the DTM is defined for the Bluetooth Qualifications, it can be used to run most of the Regulatory Certification tests. + +Typical use cases for the DTM: +- SoCs: + - Regulatory Certifications testing + - RF-PHY testing for the Bluetooth Qualification if the design does not match the reference design + - Production testing +- Modules: + - Regulatory Certifications testing (required for the modules in Europe) + - Spot checks (strongly recommended by FCC) + - RF-PHY testing for the Bluetooth Qualification if the design might affect the module operation + - Production testing +- Radio Boards with WSTK: + - Mostly for getting to know the DTM overall and testing the setup + - Typically not much practical usage + +For more information about using the DTM, see the following documents: + +- [AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/application-notes/an1267-bt-rf-phy-evaluation-using-dtm-sdk-v3x.pdf) + +The full DTM specification can be found here: + +- [Bluetooth® Core Specification Adopted Version 5.2, Vol 6: Low Energy Controller, Part F: Direct Test Mode](https://www.bluetooth.com/specifications/bluetooth-core-specification/) + +## Getting Started + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +The instructions to create and flash the DTM example application are in the [AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/application-notes/an1267-bt-rf-phy-evaluation-using-dtm-sdk-v3x.pdf). The same document contains information about customizing UART pins for your own hardware and examples about using the DTM. + +Detailed specifications are in the Bluetooth Specifications. + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + +**Note!** With the WSTK and the Radio Board, the DTM example uses EXP-header UART pins by default and not the USB UART as most of the other examples. Also, the default is no flow control. + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +[AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/application-notes/an1267-bt-rf-phy-evaluation-using-dtm-sdk-v3x.pdf) + +[Bluetooth® Core Specification Adopted Version 5.2, Vol 6: Low Energy Controller, Part F: Direct Test Mode](https://www.bluetooth.com/specifications/bluetooth-core-specification/) + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_empty/readme.html b/app/bluetooth/documentation/example/soc_empty/readme.html deleted file mode 100644 index f5d5259aace..00000000000 --- a/app/bluetooth/documentation/example/soc_empty/readme.html +++ /dev/null @@ -1,556 +0,0 @@ - - - - -readme - - -

SoC - Empty

The Bluetooth SoC-Empty example is a project that you can use as a template for any standalone Bluetooth application.

 

Getting Started

To learn the Bluetooth technology basics, see UG103.14: Bluetooth® LE Fundamentals.

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate.

As the name implies, the example is an (almost) empty template that has only the bare minimum to make a working Bluetooth application. This skeleton can be extended with the application logic.

The development of a Bluetooth applications consist of three main steps:

  • Designing the GATT database
  • Responding to the events raised by the Bluetooth stack
  • Implementing additional application logic

These steps are covered in the following sections. To learn more about programming an SoC application, see UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x.

 

Designing the GATT Database

SOC-empty example implements a basic GATT database. GATT definitions (services/characteristics) can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator. To open the Project Configurator, open the .slcp file of the project.

Opening GATT Configurator

To learn how to use the GATT Configurator, see UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x.

 

Responding to Bluetooth Events

A Bluetooth application is event driven. The Bluetooth stack generates events e.g., when a remote device connects or disconnects or when it writes a characteristic in the local GATT database. The application has to handle these events in the sl_bt_on_event() function. The prototype of this function is implemented in app.c. To handle more events, the switch-case statement of this function is to be extended. For the list of Bluetooth events, see the online Bluetooth API Reference.

 

Implementing Application Logic

Additional application logic has to be implemented in the app_init() and app_process_action() functions. Find the definitions of these functions in app.c. The app_init() function is called once when the device is booted, and app_process_action() is called repeatedly in a while(1) loop. For example, you can poll peripherals in this function. To save energy and to have this function called at specific intervals only, for example once every second, use the services of the Sleeptimer. If you need a more sophisticated application, consider using RTOS (see AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with the Micrium RTOS).

 

Features Already Added to SOC-Empty Application

The SOC-Empty application is almost empty. It implements a basic application to demonstrate how to handle events, how to use the GATT database, and how to add software components.

  • A simple application is implemented in the event handler function that starts advertising on boot (and on connection_closed event). This makes it possible for remote devices to find the device and connect to it.
  • A simple GATT database is defined by adding Generic Access and Device Information services. This makes it possible for remote devices to read out some basic information e.g., the device name.
  • The OTA DFU software component is added, which extends both the event handlers (see sl_ota_dfu.c) and the GATT database (see ota_dfu.xml). This makes it possible to make Over-The-Air Device-Firmware-Upgrade without any additional application code.

 

Testing the SOC-Empty Application

As described above, an empty example does nothing except advertising and letting other devices connect and read its basic GATT database. To test this feature, do the following:

  1. Build and flash the SoC-Empty sample app to your device.
  2. Make sure a bootloader is installed. See Troubleshooting section.
  3. Download the EFR Connect smartphone available on iOS and Android.
  4. Open the app and choose the Bluetooth Browser. -EFR Connect start screen
  5. Now you should find your device advertising as "Empty Example". Tap on Connect. -Bluetooth Browser
  6. The connection is opened, and the GATT database is automatically discovered. Find the device name characteristic under Generic Access service and try to read out the device name. -GATT database of the device

 

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side), as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_empty/readme.md b/app/bluetooth/documentation/example/soc_empty/readme.md new file mode 100644 index 00000000000..d0b64c52f57 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_empty/readme.md @@ -0,0 +1,113 @@ +# SoC - Empty + +The Bluetooth SoC-Empty example is a project that you can use as a template for any standalone Bluetooth application. + + + +## Getting Started + +To learn the Bluetooth technology basics, see [UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf). + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +The term SoC stands for "System on Chip", meaning that this is a standalone application that runs on the EFR32/BGM and does not require any external MCU or other active components to operate. + +As the name implies, the example is an (almost) empty template that has only the bare minimum to make a working Bluetooth application. This skeleton can be extended with the application logic. + +The development of a Bluetooth applications consist of three main steps: + +* Designing the GATT database +* Responding to the events raised by the Bluetooth stack +* Implementing additional application logic + +These steps are covered in the following sections. To learn more about programming an SoC application, see [UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf). + + + +## Designing the GATT Database + +SOC-empty example implements a basic GATT database. GATT definitions (services/characteristics) can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator. To open the Project Configurator, open the .slcp file of the project. + +![Opening GATT Configurator](readme_img1.png) + +To learn how to use the GATT Configurator, see [UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug438-gatt-configurator-users-guide-sdk-v3x.pdf). + + + +## Responding to Bluetooth Events + +A Bluetooth application is event driven. The Bluetooth stack generates events e.g., when a remote device connects or disconnects or when it writes a characteristic in the local GATT database. The application has to handle these events in the *sl_bt_on_event()* function. The prototype of this function is implemented in *app.c*. To handle more events, the switch-case statement of this function is to be extended. For the list of Bluetooth events, see the online [Bluetooth API Reference](https://docs.silabs.com/bluetooth/latest/). + + + +## Implementing Application Logic + +Additional application logic has to be implemented in the *app_init()* and *app_process_action()* functions. Find the definitions of these functions in *app.c*. The *app_init()* function is called once when the device is booted, and *app_process_action()* is called repeatedly in a while(1) loop. For example, you can poll peripherals in this function. To save energy and to have this function called at specific intervals only, for example once every second, use the services of the [Sleeptimer](https://docs.silabs.com/gecko-platform/latest/service/api/group-sleeptimer). If you need a more sophisticated application, consider using RTOS (see [AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with the Micrium RTOS](https://www.silabs.com/documents/public/application-notes/an1260-integrating-v3x-bluetooth-applications-with-rtos.pdf)). + + + +## Features Already Added to SOC-Empty Application + +The SOC-Empty application is ***almost*** empty. It implements a basic application to demonstrate how to handle events, how to use the GATT database, and how to add software components. + +* A simple application is implemented in the event handler function that starts advertising on boot (and on connection_closed event). This makes it possible for remote devices to find the device and connect to it. + +* A simple GATT database is defined by adding Generic Access and Device Information services. This makes it possible for remote devices to read out some basic information e.g., the device name. +* The OTA DFU software component is added, which extends both the event handlers (see sl_ota_dfu.c) and the GATT database (see ota_dfu.xml). This makes it possible to make Over-The-Air Device-Firmware-Upgrade without any additional application code. + + + +## Testing the SOC-Empty Application + +As described above, an empty example does nothing except advertising and letting other devices connect and read its basic GATT database. To test this feature, do the following: + +1. Build and flash the SoC-Empty sample app to your device. +2. Make sure a bootloader is installed. See Troubleshooting section. +3. Download the **EFR Connect** smartphone available on [iOS](https://apps.apple.com/us/app/efr-connect/id1030932759) and [Android](https://play.google.com/store/apps/details?id=com.siliconlabs.bledemo). +4. Open the app and choose the Bluetooth Browser. + ![EFR Connect start screen](readme_img2.png) +5. Now you should find your device advertising as "Empty Example". Tap on Connect. + ![Bluetooth Browser](readme_img3.png) +6. The connection is opened, and the GATT database is automatically discovered. Find the device name characteristic under Generic Access service and try to read out the device name. + ![GATT database of the device](readme_img4.png) + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side), as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme.html b/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme.html deleted file mode 100644 index c2d84fd65d8..00000000000 --- a/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme.html +++ /dev/null @@ -1,558 +0,0 @@ - - - - -readme - - -

SoC - Empty RAIL DMP

This sample application contains a basic implementation of a Bluetooth and proprietary dynamic multiprotocol application.

Getting Started

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

This example implements a basic project with Bluetooth Low energy and proprietary protocol running parallel on the device. The project is based on the Micrium RTOS. For more information about using the Micrium RTOS with Bluetooth, see AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with the Micrium RTOS

For more details about the Bluetooth and proprietary DMP applications, see AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x and UG305: Dynamic Multiprotocol User’s Guide

Example project setup: -

The setup shown in the figure is a light and switch example, but the principle is the same for all the DMP applications. The device is able to communicate via Bluetooth and via Proprietary protocol at the same time, making it possible to control it from different sources, or it can also act as a gateway between the different protocols.

Project Structure

The following image shows the overview of the software Architecture of the project.

The event handing for the different protocols can be found in their respective tasks.

Bluetooth

The projects contains a basic GATT database. GATT definitions can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator.

To learn how to use the GATT Configurator, see UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x.

The Bluetooth task creation and the stack initialization is already implemented in the init function, called from the main function. -The Bluetooth event handler function, sl_bt_on_event, can be found in the file bluetooth_app.c. This contains a basic event handler, which can be extended according to the applications needs. -The default implementation starts advertising with the device name defined in the GATT Configurator. After flashing it to the device, it will be visible in the EFR connect app, as follows:

Proprietary

The radio configurator can be found under Advanced Configurators in the Software Components tab of the Project Configurator. - -To learn how to use the Radio Configurator, see AN1253: EFR32 Radio Configurator Guide for Simplicity Studio 5.

The task creation is implemented in the app_proprietary.c. A basic event handler is implemented there, which can be extended according to the application needs.

Application

You can implement additional application-specific tasks in the app.c. You can create and handle any RTOS task here according to your functionality.

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme.md b/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme.md new file mode 100644 index 00000000000..81e6e0bde27 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme.md @@ -0,0 +1,113 @@ +# SoC - Empty RAIL DMP + +This sample application contains basic implementation of a Bluetooth and proprietary dynamic multiprotocol (DMP) application. It serves as a starting point for any DMP application development. + + + +## Getting Started + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +This example implements a basic project with Bluetooth Low energy and proprietary protocol running parallel on the device. The project is based on a Real Time Operating System (Micrium OS or FreeRTOS according to your choice). For more information about using Real Time Operating Systems with Bluetooth, see [AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with Real-Time Operating Systems](https://www.silabs.com/documents/public/application-notes/an1260-integrating-v3x-bluetooth-applications-with-rtos.pdf). + +For more details about the Bluetooth and proprietary DMP applications, see [AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x](https://www.silabs.com/documents/public/application-notes/an1269-bluetooth-rail-dynamic-multiprotocol-gsdk-v3x.pdf) and [UG305: Dynamic Multiprotocol User’s Guide](https://www.silabs.com/documents/public/user-guides/ug305-dynamic-multiprotocol-users-guide.pdf). + + + +## Project Setup + +![](readme_img1.png) + +The principle is the same for all Bluetooth DMP (Dynamic Multi-Protocol) applications: the device is able to communicate via Bluetooth and via a secondary protocol (either a standard one, like Zigbee, or a proprietary one) at the same time, making it possible to control the DMP device with different type of devices, or the DMP device can also act as a gateway between the different protocols. The physical layer of the proprietary protocol may be a standard one (like IEEE 802.15.4) or entirely proprietary if your device provides support for it (see datasheet). + +This project implements the skeleton of such a solution using Bluetooth and a proprietary protocol with a proprietary physical layer. Callbacks for Bluetooth and proprietary event handling are added, but not implemented (except a very basic Bluetooth functionality that starts advertising after the boot event). The developer can add any functionality. + + + +## Project Structure +The following image shows the overview of the software Architecture of the project. + +![](readme_img2.png) + +The Bluetooth stack, and RAIL is running in the background, using several tasks that should not be modified by the developer. Instead, sl_bt_on_event() and sl_rail_util_on_event() should be populated with Bluetooth and proprietary event handlers. Note: sl_rail_util_on_event() is called from interrupt context, hence it must implement time-critical event handlers only! Non-time-critical event handling must be implemented in the app_proprietary_task(). sl_bt_on_event() is not called from interrupt context, hence it can implement any type of event handlers. To add further, non-event-driven functionality, the developer is free to create new custom tasks. + + + +### Bluetooth Configuration +The Bluetooth stack can be configured via the Bluetooth Software Components (see Software Components tab in the .slcp file). + +The project also contains a basic GATT database. GATT definitions can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator. + +![](readme_img3.png) + +To learn how to use the GATT Configurator, see [UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug438-gatt-configurator-users-guide-sdk-v3x.pdf). + +The Bluetooth task creation and the stack initialization is already implemented in the sl_system_init function, called from the *main* function. The Bluetooth event handler function, *sl_bt_on_event*, can be found in the file *bluetooth_app.c*. This contains a basic event handler, which can be extended according to the applications needs. The default implementation starts advertising with the device name defined in the GATT Configurator. After flashing it to the device, it will be visible in the EFR connect app, as follows: + +![](readme_img4.png) + + + +### Proprietary Configuration + +RAIL (Radio Abstraction and Integration Layer) can be configured via the RAIL Software Components. + +The proprietary protocol also needs a radio configuration. This example applies a default configuration, which works out-of-the-box, based on the radio board you use. The radio configuration can be viewed and altered in the Radio Configurator. The Radio Configurator can be found under Advanced Configurators in the Software Components tab of the Project Configurator, as shown below: + +![](readme_img5.png) + +To learn how to use the Radio Configurator, see [AN1253: EFR32 Radio Configurator Guide for Simplicity Studio 5](https://www.silabs.com/documents/public/application-notes/an1253-efr32-radio-configurator-guide-for-ssv5.pdf). + +sl_rail_util_on_event() and app_proprietary_task() are implemented in *app_proprietary.c*. Extend these functions to implement your proprietary events handlers. + + + +### Application Tasks +You can implement additional application-specific tasks in *app.c*. You can create and handle any RTOS task here according to your functionality. + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with Real-Time Operating Systems](https://www.silabs.com/documents/public/application-notes/an1260-integrating-v3x-bluetooth-applications-with-rtos.pdf) + +[AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x](https://www.silabs.com/documents/public/application-notes/an1269-bluetooth-rail-dynamic-multiprotocol-gsdk-v3x.pdf) + + [UG305: Dynamic Multiprotocol User’s Guide](https://www.silabs.com/documents/public/user-guides/ug305-dynamic-multiprotocol-users-guide.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme_img1.png b/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme_img1.png index f42fa844beb..001d9fcf1df 100644 --- a/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme_img1.png +++ b/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme_img1.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:5c7ef1d8805da461e31d82a9a28c18ae86e092fa74b27f632a4d0011fbddbb90 -size 439460 +oid sha256:c52c7ea80b7d177212a8c4e60a5834ae7e5e55e8a455fddd38c3f3cc27ebbc6a +size 240826 diff --git a/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme_img2.png b/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme_img2.png index bbe2d20aebc..c53408c5e0e 100644 --- a/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme_img2.png +++ b/app/bluetooth/documentation/example/soc_empty_rail_dmp/readme_img2.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:7d46b51fc75bf1a6b6e1230396555a82d4893562a4f2e3f1ba7f11f1599797cb -size 124345 +oid sha256:aca18652a769d009fece17b5e9ddc441d09c80317b877930ddfede7bcb764138 +size 39074 diff --git a/app/bluetooth/documentation/example/soc_empty_std_dmp/readme.md b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme.md new file mode 100644 index 00000000000..487c8fb0880 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme.md @@ -0,0 +1,111 @@ +# SoC - Empty Standard DMP + +This sample application contains basic implementation of a Bluetooth and proprietary dynamic multiprotocol (DMP) application. It serves as a starting point for any DMP application development. + +Note: This DMP application uses a standard physical layer for the proprietary protocol, defined by the IEEE 802.15.4 standard, which cannot be changed. + + + +## Getting Started + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +This example implements a basic project with Bluetooth Low energy and proprietary protocol running parallel on the device. The project is based on a Real Time Operating System (Micrium OS or FreeRTOS according to your choice). For more information about using Real Time Operating Systems with Bluetooth, see [AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with Real-Time Operating Systems](https://www.silabs.com/documents/public/application-notes/an1260-integrating-v3x-bluetooth-applications-with-rtos.pdf). + +For more details about the Bluetooth and proprietary DMP applications, see [AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x](https://www.silabs.com/documents/public/application-notes/an1269-bluetooth-rail-dynamic-multiprotocol-gsdk-v3x.pdf) and [UG305: Dynamic Multiprotocol User’s Guide](https://www.silabs.com/documents/public/user-guides/ug305-dynamic-multiprotocol-users-guide.pdf). + + + +## Project Setup + +![](readme_img1.png) + +The principle is the same for all Bluetooth DMP (Dynamic Multi-Protocol) applications: the device is able to communicate via Bluetooth and via a secondary protocol (either a standard one, like Zigbee, or a proprietary one) at the same time, making it possible to control the DMP device with different type of devices, or the DMP device can also act as a gateway between the different protocols. The physical layer of the proprietary protocol may be a standard one (like IEEE 802.15.4) or entirely proprietary if your device provides support for it (see datasheet). + +This project implements the skeleton of such a solution using Bluetooth and a proprietary protocol with a standard physical layer. Callbacks for Bluetooth and proprietary event handling are added, but not implemented (except a very basic Bluetooth functionality that starts advertising after the boot event). The developer can add any functionality. + + + +## Project Structure +The following image shows the overview of the software Architecture of the project. + +![](readme_img2.png) + +The Bluetooth stack, and RAIL is running in the background, using several tasks that should not be modified by the developer. Instead, sl_bt_on_event() and sl_rail_util_on_event() should be populated with Bluetooth and proprietary event handlers. Note: sl_rail_util_on_event() is called from interrupt context, hence it must implement time-critical event handlers only! Non-time-critical event handling must be implemented in the app_proprietary_task(). sl_bt_on_event() is not called from interrupt context, hence it can implement any type of event handlers. To add further, non-event-driven functionality, the developer is free to create new custom tasks. + + + +### Bluetooth Configuration +The Bluetooth stack can be configured via the Bluetooth Software Components (see Software Components tab in the .slcp file). + +The project also contains a basic GATT database. GATT definitions can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator. + +![](readme_img3.png) + +To learn how to use the GATT Configurator, see [UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug438-gatt-configurator-users-guide-sdk-v3x.pdf). + +The Bluetooth task creation and the stack initialization is already implemented in the sl_system_init function, called from the *main* function. The Bluetooth event handler function, *sl_bt_on_event*, can be found in the file *bluetooth_app.c*. This contains a basic event handler, which can be extended according to the applications needs. The default implementation starts advertising with the device name defined in the GATT Configurator. After flashing it to the device, it will be visible in the EFR connect app, as follows: + +![](readme_img4.png) + + + +### Proprietary Configuration + +RAIL (Radio Abstraction and Integration Layer) can be configured via the RAIL Software Components. + +This DMP application uses a standard physical layer for the proprietary protocol, defined by the IEEE 802.15.4 standard, which cannot be changed. As a consequence, Radio Configurator cannot be used in this project. + +sl_rail_util_on_event() and app_proprietary_task() are implemented in *app_proprietary.c*. Extend these functions to implement your proprietary event handlers. + + + +### Application Tasks +You can implement additional application-specific tasks in *app.c*. You can create and handle any RTOS task here according to your functionality. + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with Real-Time Operating Systems](https://www.silabs.com/documents/public/application-notes/an1260-integrating-v3x-bluetooth-applications-with-rtos.pdf) + +[AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x](https://www.silabs.com/documents/public/application-notes/an1269-bluetooth-rail-dynamic-multiprotocol-gsdk-v3x.pdf) + + [UG305: Dynamic Multiprotocol User’s Guide](https://www.silabs.com/documents/public/user-guides/ug305-dynamic-multiprotocol-users-guide.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img0.png b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img0.png new file mode 100644 index 00000000000..dbbd2a8004d --- /dev/null +++ b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img0.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:5e4d4f007d6c9dcc867f438330840be39c1be546c24123f9fab5d9533d079380 +size 44396 diff --git a/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img1.png b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img1.png new file mode 100644 index 00000000000..4d75035fe68 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img1.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:4c2949003861a65e76a0948bb6456271c071d2f4ddd3a52b7d55aa9c2a24b267 +size 241755 diff --git a/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img2.png b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img2.png new file mode 100644 index 00000000000..c53408c5e0e --- /dev/null +++ b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img2.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:aca18652a769d009fece17b5e9ddc441d09c80317b877930ddfede7bcb764138 +size 39074 diff --git a/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img3.png b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img3.png new file mode 100644 index 00000000000..4edd1619ccf --- /dev/null +++ b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img3.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:11b511206c19ddfc2ee23d04962ebfe11be4a57a8a7a0cb2b02632c59dbe74c5 +size 32817 diff --git a/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img4.png b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img4.png new file mode 100644 index 00000000000..cf6ac7ff816 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_empty_std_dmp/readme_img4.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:d4eebfd87b4683788a1dc10d72441a6417ba2aac894cd680e8e0cf36b5c0e37f +size 94689 diff --git a/app/bluetooth/documentation/example/soc_ibeacon/readme.html b/app/bluetooth/documentation/example/soc_ibeacon/readme.html deleted file mode 100644 index 63690c55077..00000000000 --- a/app/bluetooth/documentation/example/soc_ibeacon/readme.html +++ /dev/null @@ -1,553 +0,0 @@ - - - - -readme - - -

SoC - iBeacon

An iBeacon device is an implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacon to smartphones. This example can be tested together with the EFR Connect mobile app.

 

Getting Started

Introduced in iOS 7, iBeacon enables new location awareness possibilities for apps. Leveraging Bluetooth Low Energy (BLE), a device with iBeacon technology can be used to establish a region around an object. This allows an iOS device to determine when it has entered or left the region, along with an estimation of proximity to a beacon.

For more beacon information, see Apple iBeacon

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

To run this example, you will need:

  • A WSTK with Bluetooth Low Energy compatible radio board.
  • An iOS smartphone with EFR Connect app installed.

The following picture shows the system view of how it works.

SoC-iBeacon-Overview

Follow the below steps to set up the project:

  1. Create the SoC-iBeacon project based on your hardware, then build and flash the image to your board. Alternatively, you could flash the pre-built demo image.

    create-project

  2. Open the EFR Connect app on your smartphone and allow the permission request the first time it's opened.

  3. Click [Develop] -> [Browser]. You will see a list of nearby devices which are sending Bluetooth advertisement. Find the one named "iBeacon" .

    create-project

    You can also see the Minor, Major and UUID number, and the EFR app will estimate the distance.

 

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

Getting-Started-with-iBeacon

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_ibeacon/readme.md b/app/bluetooth/documentation/example/soc_ibeacon/readme.md new file mode 100644 index 00000000000..360c2aeaecb --- /dev/null +++ b/app/bluetooth/documentation/example/soc_ibeacon/readme.md @@ -0,0 +1,78 @@ +# SoC - iBeacon + +An iBeacon device is an implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacon to smartphones. This example can be tested together with the EFR Connect mobile app. + + + +## Getting Started + +Introduced in iOS 7, iBeacon enables new location awareness possibilities for apps. Leveraging Bluetooth Low Energy (BLE), a device with iBeacon technology can be used to establish a region around an object. This allows an iOS device to determine when it has entered or left the region, along with an estimation of proximity to a beacon. + +For more beacon information, see [Apple iBeacon](https://developer.apple.com/ibeacon/) + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +To run this example, you will need: + +- Any Bluetooth Low Energy compatible [radio board](https://www.silabs.com/wireless/bluetooth), +- A smartphone with [EFR Connect app](https://www.silabs.com/developers/efr-connect-mobile-app) installed. (Note: On Android, the distance will not be calculated.) + +The following picture shows the system view of how it works. + +![SoC-iBeacon-Overview](readme_img1.png) + +Follow the below steps to set up the project: + +1. Create the SoC-iBeacon project based on your hardware, then build and flash the image to your board. Alternatively, you could flash the pre-built demo image. + + ![create-project](readme_img2.png) + +2. Open the *EFR Connect* app on your smartphone and allow the permission request the first time it's opened. + +3. Click [Develop] -> [Browser]. You will see a list of nearby devices which are sending Bluetooth advertisement. Find the one named "iBeacon" . + + ![create-project](readme_img3.png) + + You can also see the Minor, Major and UUID number, and the EFR app will estimate the distance. (Note: On Android, the distance will not be calculated.) + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +[Getting-Started-with-iBeacon](https://developer.apple.com/ibeacon/Getting-Started-with-iBeacon.pdf) + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). diff --git a/app/bluetooth/documentation/example/soc_iop_test/readme.html b/app/bluetooth/documentation/example/soc_iop_test/readme.html deleted file mode 100644 index fd51723684d..00000000000 --- a/app/bluetooth/documentation/example/soc_iop_test/readme.html +++ /dev/null @@ -1,598 +0,0 @@ - - - - - -readme - -
-

Interoperability Example

Interoperability (IOP) is one of the key value propositions of Bluetooth Low Energy and something that consumers have come to expect from Bluetooth-enabled end products.

This readme describes the Silicon Labs IOP test framework, composed of hardware kits, embedded software, and a mobile app. It also explains the requirements for building the IOP test setup, running the test, and collecting data for further analysis.

Because some optional steps need to be taken before the IOP test starts, read this document before running the IOP test.

Introduction

IOP is a cornerstone of Bluetooth and one of the key reasons why this wireless technology has become ubiquitous. It enables end users to mix and match devices between different vendors without fearing connectivity issues, for example, whether a heart rate monitor from company A will connect to a smart watch from company B.

It is therefore essential that Bluetooth solution suppliers can offer their customers a means to test IOP between the customer's Bluetooth solution and third-party devices

One of the most common use cases for Bluetooth-enabled devices is interaction with smartphones, where a mobile app is used for command and control of the Bluetooth device. This use case places IOP in the spotlight because of the large number of permutations between smartphone hardware (namely Bluetooth chipset), low-level firmware (typically the Bluetooth LE (BLE) link layer), mobile OS (typically the BLE host stack), and mobile OS version.

Silicon Labs provides a framework to test IOP between the EFR32 family of SoCs and a large number of smartphones currently on the market. This framework is used to run IOP testing periodically against a large list of devices. AN1309 contains both IOP test results and the IOP test plan.

Subsequent sections describe:

  • Requirements for the IOP test framework
  • Bringing up the test environment
  • Running the IOP test
  • Collecting data for further analysis

Requirements for the IOP Test Framework

Hardware Requirements

The IOP embedded software is available for virtually any Silicon Labs kit that supports Bluetooth technology.

Software Requirements

The IOP sample application is available beginning with Bluetooth SDK 3.3.0. Install Simplicity Studio 5 and the Bluetooth SDK that is part of the GSDK. For more information about installing Simplicity Studio 5, see the Simplicity Studio 5 documentation.

Mobile App Requirements

To enable IOP testing framework on a smartphone, install the EFR Connect mobile app, version 2.4 or newer. The app is available for both Android and iOS and the source is available on GitHub.

Ensure that there is no existing bond with the embedded device before initiating the IOP test sequence, which you can check from the phone Bluetooth settings. If the device is already bonded, the bond must be removed before proceeding with IOP testing.

Minimum Mobile Operating System Versions

The minimum OS versions supported by the EFR Connect mobile app are Android™ 9 and iOS®12.

Bringing up the Test Environment

The IOP test consists of a sequence of BLE operations executed between a mobile device and an EFR32 SoC running the interoperability test embedded software (the embedded device).

To flash the embedded software into one of the supported boards, create the sample app Bluetooth - SoC Interoperability Test, build it, and flash it to the target.

Then run the script iop_create_bl_files.sh (for MacOS/Linux) or iop_create_bl_files.ps1 (for Windows powershell). The script generates two files into the output_gbl folder that is inside the project folder: ota-dfu_ack.gbl and ota-dfu_non_ack.gbl.

These files must be provided to the IOP Test on EFR Connect mobile app when prompted to do so. Copy them to the mobile phone's local storage or a cloud drive that is accessible from the mobile phone. The file ota-dfu_ack.gbl is used for the first OTA test and ota-dfu_non_ack.gbl for the second OTA test.

Note that you need to have a bootloader flashed into the board as well, otherwise the firmware will not run. The easiest way is to run one of the pre-compiled demos (e.g., Bluetooth - SoC Blinky), which will flash both application and bootloader. If demos are not available for the board you are using then you must create the bootloader project Bluetooth in-place OTA DFU Bootloader, build it and flash to the board separately.

Once the sample app and bootloader are flashed into the target you should see the following information on the kit display, as shown below. If you are using a kit without display (e.g. Explorer Kit) then you will see information being sent out through the UART which can be captured by a terminal on the PC (more information here).

On your mobile phone launch the EFR Connect mobile app, which automatically opens in Develop view. Tap the Interoperability Test tile to bring up a list of all the nearby boards running the IOP Test firmware. Tap the board that you want to test against. The app automatically goes to the IOP view, where you can tap “Run Tests” to get started.

Running the IOP Test

After the IOP test sequence starts running, the mobile app scrolls through the test cases and indicates Pass/Fail when the test is completed, as shown below.

Most tests do not require user intervention, except for the OTA and security tests.

During OTA tests you are prompted to upload the gbl file. The file can be retrieved from local or cloud storage, using OS standard methods. For the first OTA test the ota-dfu_ack.gbl must be used, and for the second OTA test ota-dfu_non_ack.gbl.

During the security tests, you are prompted several times to bond with the device on the mobile app side. Some of those prompts require simple confirmation (Just Works pairing) while other prompts require entering a PIN (authenticated pairing), which can be read from the kit display or from the UART logs, if you are using a kit without display.

Logging and Sharing data

After the test is finalized on the mobile app, you can rerun the test or share the results.

To rerun the tests, first reset the embedded device by pressing the reset button on the lower right side of the mainboard. Additionally, remove the bond from the phone’s Bluetooth settings.

The Share option allows sharing the test log through OS-standard mediums, such as cloud storage (e.g., Dropbox, Google Drive, iCloud, and so on), email, or saving it locally. The log is in xml format and contains information about the phone model, OS version, Bluetooth connection parameters, and the result of each test. Below is an example of a test log from running IOP test on a Pixel 2 with Android 11.

Collecting Additional Data from the Embedded Device

The IOP embedded software also sends logging data over UART, which can be captured by a terminal emulator on the PC. Furthermore, the Packet Trace Interface (PTI) is enabled, which means that the radio traffic can be captured using the Network Analyzer.

For a more comprehensive data set around an individual IOP test sequence, capture both UART logs and radio traces using Simplicity Studio. Radio trace capture must be initiated before starting the IOP test.

To start the radio capture, right-click the debug adapter and select "Connect". Then, right-click the debug adapter once again and select "Start Capture".

This automatically opens the Network Analyzer perspective, where the traffic is logged and every packet can be decoded for further analysis if required. At the end of the IOP test, the trace can be saved through File -> Save as, as shown below.

While UART logs have multiple COMPort emulators such as tera term, you can also capture in Simplicity Studio’s terminal. Right-click the debug adapter and select "Launch Console". In the console view, click the "Serial 1" tab. Enter any character at the prompt at the bottom of the screen. The connection symbol should change, indicating that the connection is successful. Then logging should start, depending at which phase of the IOP test this is initialized. Otherwise, reset the board to ensure that the log is being received.

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured to expect a bootloader to be present on the device. For your application to work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you can either create and flash a bootloader project or run a precompiled Demo on your device from the Launcher perspective. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, flash SoC-Thermometer demo before flashing your application.
  • To flash a UART DFU capable bootloader to your device, flash NCP-Empty demo before flashing your application.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done in one step by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and either UG266: Silicon Labs Gecko Bootloader User's Guide or UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_iop_test/readme.md b/app/bluetooth/documentation/example/soc_iop_test/readme.md new file mode 100644 index 00000000000..116bbda7386 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_iop_test/readme.md @@ -0,0 +1,151 @@ +# Interoperability Example + +Interoperability (IOP) is one of the key value propositions of Bluetooth Low Energy and something that consumers have come to expect from Bluetooth-enabled end products. + +This readme describes the Silicon Labs IOP test framework, composed of hardware kits, embedded software, and a mobile app. It also explains the requirements for building the IOP test setup, running the test, and collecting data for further analysis. + +**Because some optional steps need to be taken before the IOP test starts, read this document before running the IOP test.** + +## Introduction + +IOP is a cornerstone of Bluetooth and one of the key reasons why this wireless technology has become ubiquitous. It enables end users to mix and match devices between different vendors without fearing connectivity issues, for example, whether a heart rate monitor from company A will connect to a smart watch from company B. + +It is therefore essential that Bluetooth solution suppliers can offer their customers a means to test IOP between the customer's Bluetooth solution and third-party devices + +One of the most common use cases for Bluetooth-enabled devices is interaction with smartphones, where a mobile app is used for command and control of the Bluetooth device. This use case places IOP in the spotlight because of the large number of permutations between smartphone hardware (namely Bluetooth chipset), low-level firmware (typically the Bluetooth LE (BLE) link layer), mobile OS (typically the BLE host stack), and mobile OS version. + +Silicon Labs provides a framework to test IOP between the EFR32 family of SoCs and a large number of smartphones currently on the market. This framework is used to run IOP testing periodically against a large list of devices. [AN1309](https://www.silabs.com/documents/public/application-notes/an1309-ble-interop-testing-report.pdf) contains both IOP test results and the IOP test plan. + +Subsequent sections describe: + +- Requirements for the IOP test framework +- Bringing up the test environment +- Running the IOP test +- Collecting data for further analysis + +## Requirements for the IOP Test Framework + +### Hardware Requirements + +The IOP embedded software is available for virtually any Silicon Labs kit that supports Bluetooth technology. + +### Software Requirements + +The IOP sample application is available beginning with Bluetooth SDK 3.3.0. Install Simplicity Studio 5 and the Bluetooth SDK that is part of the GSDK. For more information about installing Simplicity Studio 5, see the [Simplicity Studio 5 documentation](https://docs.silabs.com/simplicity-studio-5-users-guide/5.2.1/ss-5-users-guide-getting-started/install-ss-5-and-software). + +### Mobile App Requirements + +To enable IOP testing framework on a smartphone, install the EFR Connect mobile app, version 2.4 or newer. The app is available for both [Android](https://play.google.com/store/apps/details?id=com.siliconlabs.bledemo&hl=en&gl=US) and [iOS](https://apps.apple.com/us/app/efr-connect/id1030932759) and the source is available on [GitHub](https://github.com/SiliconLabs?q=efrconnect&type=&language=&sort=). + +Ensure that there is **no existing bond** with the embedded device before initiating the IOP test sequence, which you can check from the phone Bluetooth settings. If the device is already bonded, the bond must be removed before proceeding with IOP testing. + +### Minimum Mobile Operating System Versions + +The minimum OS versions supported by the EFR Connect mobile app are Android™ 9 and iOS®12. + +## Bringing up the Test Environment + +The IOP test consists of a sequence of BLE operations executed between a mobile device and an EFR32 SoC running the interoperability test embedded software (the embedded device). + +To flash the embedded software into one of the supported boards, create the sample app *Bluetooth - SoC Interoperability Test*, build it, and flash it to the target. + +Then run the script *iop_create_bl_files.sh* (for MacOS/Linux) or *iop_create_bl_files.ps1* (for Windows powershell). The script generates two files into the **output_gbl** folder that is inside the project folder: *ota-dfu_ack.gbl* and *ota-dfu_non_ack.gbl*. + +These files must be provided to the IOP Test on EFR Connect mobile app when prompted to do so. Copy them to the mobile phone's local storage or a cloud drive that is accessible from the mobile phone. The file *ota-dfu_ack.gbl* is used for the first OTA test and *ota-dfu_non_ack.gbl* for the second OTA test. + +Note that you need to have a bootloader flashed into the board as well, otherwise the firmware will not run. The easiest way is to run one of the pre-compiled demos (e.g., Bluetooth - SoC Blinky), which will flash both application and bootloader. If demos are not available for the board you are using then you must create the bootloader project *Bluetooth in-place OTA DFU Bootloader*, build it and flash to the board separately. + +Once the sample app and bootloader are flashed into the target you should see the following information on the kit display, as shown below. If you are using a kit without display (e.g. Explorer Kit) then you will see information being sent out through the UART which can be captured by a terminal on the PC (more information [here](#collecting-additional-data-from-the-embedded-device)). + +![](readme_img1.png) + +On your mobile phone launch the EFR Connect mobile app, which automatically opens in Develop view. Tap the Interoperability Test tile to bring up a list of all the nearby boards running the IOP Test firmware. Tap the board that you want to test against. The app automatically goes to the IOP view, where you can tap “Run Tests” to get started. + +![](readme_img2.png) + +## Running the IOP Test + +After the IOP test sequence starts running, the mobile app scrolls through the test cases and indicates Pass/Fail when the test is completed, as shown below. + +![](readme_img3.png) + +Most tests do not require user intervention, except for the OTA and security tests. + +During OTA tests you are prompted to upload the gbl file. The file can be retrieved from local or cloud storage, using OS standard methods. For the first OTA test the *ota-dfu_ack.gbl* must be used, and for the second OTA test *ota-dfu_non_ack.gbl*. + +![](readme_img11.png) + +During the security tests, you are prompted several times to bond with the device on the mobile app side. Some of those prompts require simple confirmation (Just Works pairing) while other prompts require entering a PIN (authenticated pairing), which can be read from the kit display or from the UART logs, if you are using a kit without display. + +![](readme_img4.png) + +![](readme_img5.png) + +## Logging and Sharing data + +After the test is finalized on the mobile app, you can rerun the test or share the results. + +![](readme_img6.png) + +To rerun the tests, first reset the embedded device by pressing the reset button on the lower right side of the mainboard. Additionally, remove the bond from the phone’s Bluetooth settings. + +The *Share* option allows sharing the test log through OS-standard mediums, such as cloud storage (e.g., Dropbox, Google Drive, iCloud, and so on), email, or saving it locally. The log is in xml format and contains information about the phone model, OS version, Bluetooth connection parameters, and the result of each test. Below is an example of a test log from running IOP test on a Pixel 2 with Android 11. + +![](readme_img7.png) + +### Collecting Additional Data from the Embedded Device + +The IOP embedded software also sends logging data over UART, which can be captured by a terminal emulator on the PC. Furthermore, the Packet Trace Interface (PTI) is enabled, which means that the radio traffic can be captured using the Network Analyzer. + +For a more comprehensive data set around an individual IOP test sequence, capture both UART logs and radio traces using Simplicity Studio. Radio trace capture must be initiated before starting the IOP test. + +To start the radio capture, right-click the debug adapter and select "Connect". Then, right-click the debug adapter once again and select "Start Capture". + +![](readme_img8.png) + +This automatically opens the Network Analyzer perspective, where the traffic is logged and every packet can be decoded for further analysis if required. At the end of the IOP test, the trace can be saved through File -> Save as, as shown below. + +![](readme_img9.png) + +While UART logs have multiple COMPort emulators such as tera term, you can also capture in Simplicity Studio’s terminal. Right-click the debug adapter and select "Launch Console". In the console view, click the "Serial 1" tab. Enter any character at the prompt at the bottom of the screen. The connection symbol should change, indicating that the connection is successful. Then logging should start, depending at which phase of the IOP test this is initialized. Otherwise, reset the board to ensure that the log is being received. + +![](readme_img10.png) + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured to expect a bootloader to be present on the device. For your application to work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you can either create and flash a bootloader project or run a precompiled **Demo** on your device from the Launcher perspective. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, flash *SoC-Thermometer* demo before flashing your application. +- To flash a UART DFU capable bootloader to your device, flash *NCP-Empty* demo before flashing your application. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done in one step by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and either *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)* or *[UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher](https://www.silabs.com/documents/public/user-guides/ug489-gecko-bootloader-user-guide-gsdk-4.pdf).* + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_light_rail_dmp/readme.md b/app/bluetooth/documentation/example/soc_light_rail_dmp/readme.md new file mode 100644 index 00000000000..079d8dc631f --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_rail_dmp/readme.md @@ -0,0 +1,157 @@ +# SoC - Light RAIL DMP + +This is a Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a Proprietary protocol. To switch it via Bluetooth, use the EFR Connect smartphone app. To switch it via Proprietary protocol, use the Flex (RAIL) - Switch sample app. + + + +## Getting Started + +This example implements a sample project with Bluetooth Low energy and proprietary protocol running parallel on the device. The project is based on a Real Time Operating System (Micrium OS or FreeRTOS according to your choice). For more information about using Real Time Operating Systems with Bluetooth, see [AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with Real-Time Operating Systems](https://www.silabs.com/documents/public/application-notes/an1260-integrating-v3x-bluetooth-applications-with-rtos.pdf). + +For more details about the Bluetooth and proprietary DMP applications, see [AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x](https://www.silabs.com/documents/public/application-notes/an1269-bluetooth-rail-dynamic-multiprotocol-gsdk-v3x.pdf) and [UG305: Dynamic Multiprotocol User’s Guide](https://www.silabs.com/documents/public/user-guides/ug305-dynamic-multiprotocol-users-guide.pdf) + + + +## Project Setup + +The sample project implements the functionality of a remote controlled lightbulb, which can be controlled via Bluetooth and via a Proprietary protocol. After startup, the lightbulb advertises itself on BLE and Proprietary, and, when connected, it can be controlled by both. It will send a notification when the state has been changed, with the MAC address of the device which initiated the change. The project setup consists of two WSTKs and a mobile phone, as follows: + +![](readme_img1.png) + + + +### Controlling via Bluetooth + +After flashing the Light demo on a board, it will be visible in the EFR Connect app (available on iOS and Android). Open the app on your phone, go to the Demo tab, and tap the Connected Lighting tile. Now you can connect to your device, as follows: +![](readme_img2.png) + +Both the app display and the Bluetooth icon on the light’s LCD change, which indicates a connection: + +![](readme_img3.png) + +Tap the bulb icon on the smartphone app to toggle the light. The app display, the LCD display, and the LEDs all turn on. The app shows Last Event: Light On. Source is the MAC address of the device sending the command, in this case the smartphone: + +![](readme_img4.png) + +Note that the light demo has two modes, Advertise (ADVERT) and READY. These are for operation by the switch device, as described next. The smartphone app toggles the light regardless of the mode. + + + +### Controlling with the Switch + +For using this example, flash the Flex (RAIL) - Switch example project (available in the Flex SDK) to another board. To operate the light from the RAIL Switch application, first link the two devices. The RAIL switch starts in SCAN mode to look for lights in the vicinity. The light starts in ADVERTISE mode and broadcasts its address to nearby RAIL Switches, as follows: + +![](readme_img5.png) + +After a RAIL switch receives a light’s advertisement packet, it displays its short ID in the bottom left corner. If more lights are advertising at the same time, the switch displays the ID of the Light with the strongest signal, as shown in the image below: + +![](readme_img6.png) + +Press PB1 on the RAIL switch to store the light’s ID and put the device into LINK mode, as shown in the image below: + +![](readme_img7.png) + +Finally, press PB1 on the Light to place it to READY mode, in which it sends out the status of the light periodically and accepts toggle commands from the linked Switch, as shown in the image below: + +![](readme_img8.png) + +You should now be able to toggle the light using the linked switch. Note that more than one switch can be linked to a single light, but one switch cannot control more than one light. The app shows the source as the MAC address of the switch, as shown in the image below: + +![](readme_img9.png) + +Again, a briefly-displayed arrow shows the source of the command on the Light LCD, as follows: + +![](readme_img10.png) + +If you press the bulb icon on the app, both the light and the switch displays change, as follows: + +![](readme_img11.png) + + + +## Project Structure + +Overview of the software Architecture of the project is shown below. + +![](readme_img12.png) +The event handling for the different protocols can be found in their respective tasks. sl_rail_util_on_event() is used to handle time-critical RAIL events, and it can signal the changes to proprietary_app_task() which handles non-time-critical events, and also executes scheduled proprietary radio tasks. sl_bt_on_event() is used to handle Bluetooth events, while demo_app_task() is responsible for implementing the state machine of the whole application. + + + +### Bluetooth Configuration + +The Bluetooth stack is configured via the Bluetooth Software Components (see Software Components tab in the .slcp file). + +The projects also contains the Silabs DMP Light service in the GATT database. GATT definitions can be viewed (and extended) using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator, as shown below: + +![](readme_img13.png) + +To learn how to use the GATT Configurator, see [UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug438-gatt-configurator-users-guide-sdk-v3x.pdf). + +The Bluetooth task creation and the stack initialization is implemented in the *sl_system_init()* function, which is called from the *main* function. The Bluetooth event handler function, *sl_bt_on_event*, can be found in the file *bluetooth_app.c*. This contains the Bluetooth implementation. + + + +### Proprietary Configuration + +RAIL (Radio Abstraction and Integration Layer) can be configured via the RAIL Software Components. + +The proprietary protocol also needs a radio configuration. This example applies a default configuration, which works out-of-the-box, based on the radio board you use. The radio configuration can be viewed and altered in the Radio Configurator. The Radio Configurator can be found under Advanced Configurators in the Software Components tab of the Project Configurator, as shown below: + +![](readme_img14.png) + +To learn how to use the Radio Configurator, see [AN1253: EFR32 Radio Configurator Guide for Simplicity Studio 5](https://www.silabs.com/documents/public/application-notes/an1253-efr32-radio-configurator-guide-for-ssv5.pdf). + +The proprietary task and the event handling is implemented in the *app_proprietary.c*. + + + +### Application + +The main logic of the demo application is implemented in *demo_app_task()* that can be found in *app_bluetooth.c*. You can implement additional application-specific tasks in *app.c*. + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x](https://www.silabs.com/documents/public/application-notes/an1269-bluetooth-rail-dynamic-multiprotocol-gsdk-v3x.pdf) + +[UG305: Dynamic Multiprotocol User’s Guide](https://www.silabs.com/documents/public/user-guides/ug305-dynamic-multiprotocol-users-guide.pdf) + +[AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with Real-Time Operating Systems](https://www.silabs.com/documents/public/application-notes/an1260-integrating-v3x-bluetooth-applications-with-rtos.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_light_rail_dmp/readme_img12.png b/app/bluetooth/documentation/example/soc_light_rail_dmp/readme_img12.png index bbe2d20aebc..6b680fe3570 100644 --- a/app/bluetooth/documentation/example/soc_light_rail_dmp/readme_img12.png +++ b/app/bluetooth/documentation/example/soc_light_rail_dmp/readme_img12.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:7d46b51fc75bf1a6b6e1230396555a82d4893562a4f2e3f1ba7f11f1599797cb -size 124345 +oid sha256:ded98ad8a83cf87b205774ba94f13b6a8d5e717cfd68faedd93b74edaaf4c11f +size 42106 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme.md b/app/bluetooth/documentation/example/soc_light_std_dmp/readme.md new file mode 100644 index 00000000000..93344c639ac --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme.md @@ -0,0 +1,155 @@ +# SoC - Light Standard DMP + +This is a Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a Proprietary protocol. To switch it via Bluetooth, use the EFR Connect smartphone app. To switch it via Proprietary protocol, use the Flex (RAIL) - Switch sample app. + +Note: This DMP application uses a standard physical layer for the proprietary protocol, defined by the IEEE 802.15.4 standard, which cannot be changed. + + + +## Getting Started + +This example implements a sample project with Bluetooth Low energy and proprietary protocol running parallel on the device. The project is based on a Real Time Operating System (Micrium OS or FreeRTOS according to your choice). For more information about using Real Time Operating Systems with Bluetooth, see [AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with Real-Time Operating Systems](https://www.silabs.com/documents/public/application-notes/an1260-integrating-v3x-bluetooth-applications-with-rtos.pdf). + +For more details about the Bluetooth and proprietary DMP applications, see [AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x](https://www.silabs.com/documents/public/application-notes/an1269-bluetooth-rail-dynamic-multiprotocol-gsdk-v3x.pdf) and [UG305: Dynamic Multiprotocol User’s Guide](https://www.silabs.com/documents/public/user-guides/ug305-dynamic-multiprotocol-users-guide.pdf) + + + +## Project Setup + +The sample project implements the functionality of a remote controlled lightbulb, which can be controlled via Bluetooth and via a Proprietary protocol. After startup, the lightbulb advertises itself on BLE and Proprietary, and, when connected, it can be controlled by both. It will send a notification when the state has been changed, with the MAC address of the device which initiated the change. The project setup consists of two WSTKs and a mobile phone, as follows: + +![](readme_img1.png) + + + +### Controlling via Bluetooth + +After flashing the Light demo on a board, it will be visible in the EFR Connect app (available on iOS and Android). Open the app on your phone, go to the Demo tab, and tap the Connected Lighting tile. Now you can connect to your device, as follows: +![](readme_img2.png) + +Both the app display and the Bluetooth icon on the light’s LCD change, which indicates a connection: + +![](readme_img3.png) + +Tap the bulb icon on the smartphone app to toggle the light. The app display, the LCD display, and the LEDs all turn on. The app shows Last Event: Light On. Source is the MAC address of the device sending the command, in this case the smartphone: + +![](readme_img4.png) + +Note that the light demo has two modes, Advertise (ADVERT) and READY. These are for operation by the switch device, as described next. The smartphone app toggles the light regardless of the mode. + + + +### Controlling with the Switch + +For using this example, flash the Flex (RAIL) - Switch example project (available in the Flex SDK) to another board. To operate the light from the RAIL Switch application, first link the two devices. The RAIL switch starts in SCAN mode to look for lights in the vicinity. The light starts in ADVERTISE mode and broadcasts its address to nearby RAIL Switches, as follows: + +![](readme_img5.png) + +After a RAIL switch receives a light’s advertisement packet, it displays its short ID in the bottom left corner. If more lights are advertising at the same time, the switch displays the ID of the Light with the strongest signal, as shown in the image below: + +![](readme_img6.png) + +Press PB1 on the RAIL switch to store the light’s ID and put the device into LINK mode, as shown in the image below: + +![](readme_img7.png) + +Finally, press PB1 on the Light to place it to READY mode, in which it sends out the status of the light periodically and accepts toggle commands from the linked Switch, as shown in the image below: + +![](readme_img8.png) + +You should now be able to toggle the light using the linked switch. Note that more than one switch can be linked to a single light, but one switch cannot control more than one light. The app shows the source as the MAC address of the switch, as shown in the image below: + +![](readme_img9.png) + +Again, a briefly-displayed arrow shows the source of the command on the Light LCD, as follows: + +![](readme_img10.png) + +If you press the bulb icon on the app, both the light and the switch displays change, as follows: + +![](readme_img11.png) + + + +## Project Structure + +Overview of the software Architecture of the project is shown below. + +![](readme_img12.png) +The event handling for the different protocols can be found in their respective tasks. sl_rail_util_on_event() is used to handle time-critical RAIL events, and it can signal the changes to proprietary_app_task() which handles non-time-critical events, and also executes scheduled proprietary radio tasks. sl_bt_on_event() is used to handle Bluetooth events, while demo_app_task() is responsible for implementing the state machine of the whole application. + + + +### Bluetooth Configuration + +The Bluetooth stack is configured via the Bluetooth Software Components (see Software Components tab in the .slcp file). + +The projects also contains the Silabs DMP Light service in the GATT database. GATT definitions can be viewed (and extended) using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator, as shown below: + +![](readme_img13.png) + +To learn how to use the GATT Configurator, see [UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug438-gatt-configurator-users-guide-sdk-v3x.pdf). + +The Bluetooth task creation and the stack initialization is implemented in the *sl_system_init()* function, which is called from the *main* function. The Bluetooth event handler function, *sl_bt_on_event*, can be found in the file *bluetooth_app.c*. This contains the Bluetooth implementation. + + + +### Proprietary Configuration + +RAIL (Radio Abstraction and Integration Layer) can be configured via the RAIL Software Components. + +This DMP application uses a standard physical layer for the proprietary protocol, defined by the IEEE 802.15.4 standard, which cannot be changed. As a consequence, Radio Configurator cannot be used in this project. + +The proprietary task and the event handling is implemented in the *app_proprietary.c*. + + + +### Application + +The main logic of the demo application is implemented in *demo_app_task()* that can be found in *app_bluetooth.c*. You can implement additional application-specific tasks in *app.c*. + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x](https://www.silabs.com/documents/public/application-notes/an1269-bluetooth-rail-dynamic-multiprotocol-gsdk-v3x.pdf) + +[UG305: Dynamic Multiprotocol User’s Guide](https://www.silabs.com/documents/public/user-guides/ug305-dynamic-multiprotocol-users-guide.pdf) + +[AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with Real-Time Operating Systems](https://www.silabs.com/documents/public/application-notes/an1260-integrating-v3x-bluetooth-applications-with-rtos.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img0.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img0.png new file mode 100644 index 00000000000..dbbd2a8004d --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img0.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:5e4d4f007d6c9dcc867f438330840be39c1be546c24123f9fab5d9533d079380 +size 44396 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img1.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img1.png new file mode 100644 index 00000000000..f78e5db901f --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img1.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:e5c8f41760eb011bb70b996230c33aa656bf6c7cef90dcece32d912282b231c0 +size 367462 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img10.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img10.png new file mode 100644 index 00000000000..2d22ea64f9b --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img10.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:4ce1d937a33ac37a36ed808ef8bc66022a82286416f6809ebce7197e56fac1d2 +size 66967 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img11.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img11.png new file mode 100644 index 00000000000..9bb52f2ab84 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img11.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:5797a3a0ffbf67497082b6b6c7cdbc0462dade34194f0bb00f369330cc06cf29 +size 156416 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img12.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img12.png new file mode 100644 index 00000000000..6b680fe3570 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img12.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:ded98ad8a83cf87b205774ba94f13b6a8d5e717cfd68faedd93b74edaaf4c11f +size 42106 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img13.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img13.png new file mode 100644 index 00000000000..4edd1619ccf --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img13.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:11b511206c19ddfc2ee23d04962ebfe11be4a57a8a7a0cb2b02632c59dbe74c5 +size 32817 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img2.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img2.png new file mode 100644 index 00000000000..94ab3e916bf --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img2.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:d7ea4d2becb3d33f6dafe303f216e320609ff2cfd284e3d14be7566f334b9076 +size 161753 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img3.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img3.png new file mode 100644 index 00000000000..5b50a94e19a --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img3.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:2e1c3e542da8cd0c63e283ee2c88a26dcf8de75f56a4b0af0db3fec9d4b753a7 +size 128179 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img4.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img4.png new file mode 100644 index 00000000000..c98ee5c226a --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img4.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:efc42967e32703dd12dea2caa8bf1e69f1510817388b1d8cea620ac5563746bb +size 215974 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img5.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img5.png new file mode 100644 index 00000000000..03bbc7b5781 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img5.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:7b8ad8163b38f31eee9a9db00fd00b2c980a54d72d98b71ae9162c10311cdb93 +size 198809 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img6.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img6.png new file mode 100644 index 00000000000..d82dd96ace5 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img6.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:bf29b726382e0dd5f7cb536bfddeda26664e0a8f5595c1b6d69499b8e1c6fceb +size 89369 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img7.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img7.png new file mode 100644 index 00000000000..4f66c66e4be --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img7.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:9ce840dd7473acbb436a97e50ba7fdbaad248be8fbfed8444e380cba3f4ffff0 +size 88347 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img8.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img8.png new file mode 100644 index 00000000000..b156974e08c --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img8.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:13af1d01e74d7469b4a0f59ee88f97ba2a296daad40b54f9a816a9295dd2eff2 +size 100044 diff --git a/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img9.png b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img9.png new file mode 100644 index 00000000000..28ecff9900e --- /dev/null +++ b/app/bluetooth/documentation/example/soc_light_std_dmp/readme_img9.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:5bad4dccfc5ea8fb8197ccb4653254b17a04dc6d1e1200b7cbb296f073663c11 +size 27200 diff --git a/app/bluetooth/documentation/example/soc_thermometer/readme.html b/app/bluetooth/documentation/example/soc_thermometer/readme.html deleted file mode 100644 index 1f2ec09fdf7..00000000000 --- a/app/bluetooth/documentation/example/soc_thermometer/readme.html +++ /dev/null @@ -1,560 +0,0 @@ - - - - -readme - - -

SoC - Thermometer

This example implements the Health Thermometer service. It enables a peer device to connect and receive temperature values via Bluetooth. The reported values are measured by a temperature sensor located on the WSTK.

 

Getting Started

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

This example implements the predefined Thermometer Service. To run this example, you will need the following:

  • A WSTK with Bluetooth Low Energy compatible radio board.
  • An iOS or Android smartphone with EFR Connect app installed.

The following image shows the system view of how it works.

System View

Follow the below steps to get the temperature value on your smartphone.

  1. Create the soc-thermometer project based on your hardware, then build and flash the image to your board. Alternatively, you could flash the pre-built demo image. -step 1
  2. Open the EFR Connect app on your smartphone and allow the permission request when opened for the first time.
  3. Click [Develop] -> [Browser] and you will see a list of nearby devices which are sending Bluetooth advertisement. Find the one named "Thermometer Example" and click the connect button on the right side. -step 3
  4. Wait for the connection to establish and GATT database to be loaded, then find the Health Thermometer service, and click More Info. -step 4
  5. Four characteristics will show up. Find the Temperature Measurement and press the indicate button. Then, you will see the temperature value getting updated periodically. You should also see the temperature displayed change as you press your the top of the sensor with your finger, as shown below. If your board is not connected to a temperature sensor (e.g. because of limited number of available pins), a generated value will be shown which changes 1 degree Celsius every second. -step 5 -Finger on sensor

Alternatively, you can follow the below steps instead of the above step 3-5 to use the Health Thermometer feature in the app. This will automatically scan and list devices advertising the Health Thermometer service and, upon connection, will automatically enable notifications and display the temperature data. -Alternative 1 -Alternative 2

 

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

When starting your project, set the power supply switch to the AEM position (right side), as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

Bluetooth SIG thermometer profile specification

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_thermometer/readme.md b/app/bluetooth/documentation/example/soc_thermometer/readme.md new file mode 100644 index 00000000000..0d7d979db2d --- /dev/null +++ b/app/bluetooth/documentation/example/soc_thermometer/readme.md @@ -0,0 +1,78 @@ +# SoC - Thermometer + +This example implements the Health Thermometer service. It enables a peer device to connect and receive temperature values via Bluetooth. The reported values are measured by a temperature sensor located on the WSTK. + + + +## Getting Started + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +This example implements the predefined [Thermometer Service](https://www.bluetooth.com/xml-viewer/?src=https://www.bluetooth.com/wp-content/uploads/Sitecore-Media-Library/Gatt/Xml/Services/org.bluetooth.service.health_thermometer.xml). To run this example, you will need the following: + +- A WSTK with Bluetooth Low Energy compatible [radio board](https://www.silabs.com/wireless/bluetooth). +- An *[iOS](https://itunes.apple.com/us/app/silicon-labs-blue-gecko-wstk/id1030932759?mt=8)* or *[Android](https://play.google.com/store/apps/details?id=com.siliconlabs.bledemo)* smartphone with EFR Connect app installed. + +The following image shows the system view of how it works. + +![System View](readme_img1.png) + +Follow the below steps to get the temperature value on your smartphone. + +1. Create the soc-thermometer project based on your hardware, then build and flash the image to your board. Alternatively, you could flash the pre-built demo image. +![step 1](readme_img2.png) +2. Open the *EFR Connect* app on your smartphone and allow the permission request when opened for the first time. +3. Click [Develop] -> [Browser] and you will see a list of nearby devices which are sending Bluetooth advertisement. Find the one named "Thermometer Example" and click the `connect` button on the right side. +![step 3](readme_img3.png) +4. Wait for the connection to establish and GATT database to be loaded, then find the *Health Thermometer* service, and click `More Info`. +![step 4](readme_img4.png) +5. Four characteristics will show up. Find the *Temperature Measurement* and press the `indicate` button. Then, you will see the temperature value getting updated periodically. You should also see the temperature displayed change as you press your the top of the sensor with your finger, as shown below. If your board is not connected to a temperature sensor (e.g. because of limited number of available pins), a generated value will be shown which changes 1 degree Celsius every second. +![step 5](readme_img5.png) +![Finger on sensor](readme_img6.PNG) + +Alternatively, you can follow the below steps instead of the above step 3-5 to use the Health Thermometer feature in the app. This will automatically scan and list devices advertising the Health Thermometer service and, upon connection, will automatically enable notifications and display the temperature data. +![Alternative 1](readme_img7.PNG) +![Alternative 2](readme_img8.PNG) + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +When starting your project, set the power supply switch to the AEM position (right side), as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + +[Bluetooth SIG thermometer profile specification](https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=238687&_ga=2.28821308.120082263.1538382903-201228904.1529395147) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_thermometer_client/readme.html b/app/bluetooth/documentation/example/soc_thermometer_client/readme.html deleted file mode 100644 index 4f938c1cdee..00000000000 --- a/app/bluetooth/documentation/example/soc_thermometer_client/readme.html +++ /dev/null @@ -1,553 +0,0 @@ - - - - -readme - - -

SoC - Thermometer Client

This sample application demonstrates the operation of a client device in a multi-slave BLE topology. Silicon Labs Bluetooth stack supports simultaneous connection for up to eight slave devices at one time. This sample application illustrates how to handle simultaneous connection to four thermometer peripheral devices.

Getting Started

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

To get familiar with client and server roles, see GATT Server and Client Roles.

To learn more about master and slave roles, see Master and Slave Roles.

To learn more about multi-slave BLE topology, see Multi-Slave Topology.

You may also like to read Bluetooth Connection Flowcharts to understand the BLE connection procedures.

Evaluating the Application

To evaluate this application, you need one EFR32/BGM device running the SoC Thermometer Client sample application, and at least one (but no more than four) peripheral devices running the SoC Thermometer application. The following figure shows the topological setup for testing this sample app.

Network Topology

When the client boots, it starts Sanning/Discovering advertising devices. It initiates a connection with those devices that contain the Health Thermometer service in their advertising packets.

After a connection is established, the client discovers the Health Thermometer service from the remote GATT database. After the service discovery is completed, the client discovers the thermometer characteristics and enables indications sent from a remote GATT server. The main GATT procedures are represented in the following state diagram.

State diagram for the GATT procedures

After programming the devices, open your terminal emulator and connect to your client device over its serial port. Set baud rate to 115200. Power on the slave thermometer devices and observe the output readings on your terminal.

Temperature readings from four peripheral devices

 

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_thermometer_client/readme.md b/app/bluetooth/documentation/example/soc_thermometer_client/readme.md new file mode 100644 index 00000000000..95cf680d848 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_thermometer_client/readme.md @@ -0,0 +1,73 @@ +# SoC - Thermometer Client + +This sample application demonstrates the operation of a client device in a multi-slave BLE topology. Silicon Labs Bluetooth stack supports simultaneous connection for up to eight slave devices at one time. This sample application illustrates how to handle simultaneous connection to four thermometer peripheral devices. + +## Getting Started + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +To get familiar with client and server roles, see [GATT Server and Client Roles](https://docs.silabs.com/bluetooth/latest/general/gatt-protocol/gatt-server-and-client-roles). + +To learn more about master and slave roles, see [Master and Slave Roles](https://docs.silabs.com/bluetooth/latest/general/connections/master-and-slave-roles). + +To learn more about multi-slave BLE topology, see [Multi-Slave Topology](https://docs.silabs.com/bluetooth/latest/general/connections/multislave-topology). + +You may also like to read [Bluetooth Connection Flowcharts](https://docs.silabs.com/bluetooth/latest/general/connections/bluetooth-connection-flowcharts) to understand the BLE connection procedures. + + +## Evaluating the Application + +To evaluate this application, you need one EFR32/BGM device running the `SoC Thermometer Client` sample application, and at least one (but no more than four) peripheral devices running the `SoC Thermometer` application. The following figure shows the topological setup for testing this sample app. + +![Network Topology](readme_img1.png) + +When the client boots, it starts `Sanning`/`Discovering` advertising devices. It initiates a connection with those devices that contain the `Health Thermometer` service in their advertising packets. + +After a connection is established, the client discovers the Health Thermometer service from the remote GATT database. After the service discovery is completed, the client discovers the thermometer characteristics and enables indications sent from a remote GATT server. The main GATT procedures are represented in the following state diagram. + +![State diagram for the GATT procedures](readme_img2.png) + +After programming the devices, open your terminal emulator and connect to your client device over its serial port. Set baud rate to 115200. Power on the slave thermometer devices and observe the output readings on your terminal. + +![Temperature readings from four peripheral devices](readme_img3.png) + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). diff --git a/app/bluetooth/documentation/example/soc_thermometer_rtos/readme.html b/app/bluetooth/documentation/example/soc_thermometer_rtos/readme.html deleted file mode 100644 index 54a47bd009d..00000000000 --- a/app/bluetooth/documentation/example/soc_thermometer_rtos/readme.html +++ /dev/null @@ -1,554 +0,0 @@ - - - - -readme - - -

SoC - Thermometer Micrium RTOS

This sample application demonstrates the integration of Micrium RTOS into Bluetooth applications. RTOS is added to the Bluetooth - SoC Thermometer sample app.

 

Getting Started

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

To learn more about how the thermometer sample application works, create a SoC - Thermometer example project (without RTOS).

The following image shows the system architecture of a Micrium RTOS application. The Bluetooth stack is run in multiple tasks:

  • Link Layer Task signals Bluetooth Host Task when the Bluetooth stack needs an update.
  • Bluetooth Host Task updates the Bluetooth stack, issues stack events to Event Handler Task and handles commands from application tasks.
  • Event Handler Task handles and dispatches stack events to sl_bt_on_event() that needs to be integrated in the application. -Micrium RTOS system architecture

To learn more about Micrium RTOS integration into Bluetooth projects, see AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with the Micrium RTOS.

 

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_thermometer_rtos/readme.md b/app/bluetooth/documentation/example/soc_thermometer_rtos/readme.md new file mode 100644 index 00000000000..cf8eaf277a2 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_thermometer_rtos/readme.md @@ -0,0 +1,60 @@ +# SoC - Thermometer Micrium RTOS + +This sample application demonstrates the integration of Micrium RTOS into Bluetooth applications. RTOS is added to the Bluetooth - SoC Thermometer sample app. + + + +## Getting Started + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +To learn more about how the thermometer sample application works, create a SoC - Thermometer example project (without RTOS). + +The following image shows the system architecture of a Micrium RTOS application. The Bluetooth stack is run in multiple tasks: +- Link Layer Task signals Bluetooth Host Task when the Bluetooth stack needs an update. +- Bluetooth Host Task updates the Bluetooth stack, issues stack events to Event Handler Task and handles commands from application tasks. +- Event Handler Task handles and dispatches stack events to _sl_bt_on_event()_ that needs to be integrated in the application. +![Micrium RTOS system architecture](readme_img1.png) + +To learn more about Micrium RTOS integration into Bluetooth projects, see [AN1260: Integrating v3.x Silicon Labs Bluetooth® Applications with the Micrium RTOS](https://www.silabs.com/documents/public/application-notes/an1260-integrating-v3x-bluetooth-applications-with-rtos.pdf). + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_throughput/readme.html b/app/bluetooth/documentation/example/soc_throughput/readme.html deleted file mode 100644 index a5aec2b2938..00000000000 --- a/app/bluetooth/documentation/example/soc_throughput/readme.html +++ /dev/null @@ -1,609 +0,0 @@ - - - - - -readme - -
-

SoC - Throughput

This sample application allows measuring data throughput between EFR32 devices as well as between an EFR32 and a smartphone running the EFR Connect mobile app.

 

Getting started

To get started with Bluetooth and Simplicity Studio, please refer to QSG169: Bluetooth® SDK v3.x Quick Start Guide.

This example implements a GATT service that can be used to measure application data throughput using acknowledged or unacknowledged transactions, namely indications or notifications.

There are 3 use cases for this throughput measurement setup:

  1. EFR32 (SoC) <-> Mobile phone + EFR Connect
  2. EFR32 (SoC) <-> EFR32 (SoC)
  3. EFR32 (SoC) <-> EFR32 (NCP) + Host (typically PC)

The two last use cases require two Silicon Labs kits, such as SLWSTK6021A, SLTB010A or BGM220-EK4314A.

To test throughput against a mobile phone please install EFR Connect for Android or iOS. Source code for the mobile app is available on Github.

 

EFR32 (SoC) <-> Mobile phone + EFR Connect

For this use case only one kit is required. After flashing the sample app the firmware will boot as a peripheral by default, and the mobile phone acts as a central.

Open EFR Connect, go to the demo view and select the Throughput demo. A pop-up will show all the devices around you which are running the Bluetooth - SoC Throughput firmware. Tap on the device to go into the Throughput demo view.

Demo view Pop up

Data can be pushed to the mobile phone by pressing PB0 (notifications) or PB1 (indications) on the kit. From the mobile app side data can be pushed to the EFR32 by tapping the Start button at the bottom. The data transfer type (notifications/indications) can be selected at the top of the connection parameters window.

Throughput demo

The animation below showcases the demo running on a BGM220 Explorer Kit (BGM220-EK4314A) with the mobile app running on an Android device.

Throughput demo animation

 

EFR (SoC) <-> EFR32 (SoC)

For this use case the Bluetooth - SoC Throughput sample app must be flashed on both kits. By default the firmware boots in peripheral mode but it can boot in central mode by keeping PB0 pressed while resetting the device. The role can be read from the first line on the display.

Kits booted

Throughput testing can start as soon as the devices establish a connection and subscribe to indications/notifications on each other's GATT database. The status is indicated on the second line of the display, when both side show "ST: Subscribed" then testing is ready to start.

Notifications can be pushed by pressing PB0 and indications can be pushed by pressing PB1. The data can be pushed from either kit since both have the throughput service on their GATT database and they subscribe to notifications/indications on the remote device's GATT.

Data will be sent for as long as the button is pressed on the device and the status will be "ST: Testing" during that time.

Kits booted

Once the button is released the average throughput will be calculated and shown on the display as well as how many packets were sent. This information is on the two last lines of the display.

Kits booted

 

EFR32 (SoC) <-> EFR32 (NCP) + Host (typically PC)

The final use case consists of one kit flashed with Bluetooth - SoC Throughput sample app and a second kit flashed with Bluetooth - NCP Empty. The NCP device will be controlled by a dedicated host application which is located in C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite\v3.1\app\bluetooth\example_host\throughput.

To learn more about NCP firmware and how to build the host applications please refer to AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode.

In this setup data can only be sent from the SoC to the NCP device because the NCP firmware does not contain the Throughput service in its GATT server.

 

Additional Notes

These next sections describe some more details about the sample app.

Operation on 1-button boards

The Bluetooth - SoC Throughput also runs on boards which only have 1 user button, such as SLTB010A or BGM220-EK4314A. The behavior is determined by the button press duration:

  • Short press will switch between sending notifications or indications. The default out of boot is sending notifications.
  • Long press will send data.

CLI (Command Line Interface)

The Bluetooth - SoC Throughput sample app has a CLI which is used to report activity as well as modify parameters in runtime. You can easily access the CLI with a terminal emulator such as Tera Term or from within Simplicity Studio by right-click on the debug adapter -> Launch Console -> Serial 1 tab -> type 'help' on the command prompt.

CLI

The available command set allows multiple options such as changing connection parameters, MTU size, TX power, amongst others.

On devices without display the CLI is used for printing a virtual display which mimics the -physical display on the mainboard.

CLI

 

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_throughput/readme.md b/app/bluetooth/documentation/example/soc_throughput/readme.md new file mode 100644 index 00000000000..91f15a72c17 --- /dev/null +++ b/app/bluetooth/documentation/example/soc_throughput/readme.md @@ -0,0 +1,137 @@ +# SoC - Throughput + +This sample application allows measuring data throughput between EFR32 devices as well as between an EFR32 and a smartphone running the EFR Connect mobile app. + + + +## Getting started + +To get started with Bluetooth and Simplicity Studio, please refer to [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +This example implements a GATT service that can be used to measure application data throughput using acknowledged or unacknowledged transactions, namely indications or notifications. + +There are 3 use cases for this throughput measurement setup: + +1. EFR32 (SoC) <-> Mobile phone + EFR Connect +2. EFR32 (SoC) <-> EFR32 (SoC) +3. EFR32 (SoC) <-> EFR32 (NCP) + Host (typically PC) + + +The two last use cases require two Silicon Labs kits, such as [SLWSTK6021A](https://www.silabs.com/development-tools/wireless/efr32xg22-wireless-starter-kit), [SLTB010A](https://www.silabs.com/development-tools/thunderboard/thunderboard-bg22-kit) or [BGM220-EK4314A](https://www.silabs.com/development-tools/wireless/bluetooth/bgm220-explorer-kit). + +To test throughput against a mobile phone please install EFR Connect for [Android](https://play.google.com/store/apps/details?id=com.siliconlabs.bledemo&hl=en&gl=US) or [iOS](https://apps.apple.com/us/app/efr-connect/id1030932759). Source code for the mobile app is available on [Github](https://github.com/SiliconLabs?q=efrconnect&type=&language=&sort=). + + + +### EFR32 (SoC) <-> Mobile phone + EFR Connect + +For this use case only one kit is required. After flashing the sample app the firmware will boot as a peripheral by default, and the mobile phone acts as a central. + +Open EFR Connect, go to the demo view and select the Throughput demo. A pop-up will show all the devices around you which are running the _Bluetooth - SoC Throughput_ firmware. Tap on the device to go into the Throughput demo view. + +![Demo view](readme_img1.jpg) ![Pop up](readme_img2.jpg) + +Data can be pushed to the mobile phone by pressing PB0 (notifications) or PB1 (indications) on the kit. From the mobile app side data can be pushed to the EFR32 by tapping the Start button at the bottom. The data transfer type (notifications/indications) can be selected at the top of the connection parameters window. + +![Throughput demo](readme_img3.jpg) + +The animation below showcases the demo running on a BGM220 Explorer Kit (BGM220-EK4314A) with the mobile app running on an Android device. + +![Throughput demo animation](readme_img4.gif) + + + +### EFR (SoC) <-> EFR32 (SoC) + +For this use case the _Bluetooth - SoC Throughput_ sample app must be flashed on both kits. By default the firmware boots in peripheral mode but it can boot in central mode by keeping PB0 pressed while resetting the device. The role can be read from the first line on the display. + +![Kits booted](readme_img5.jpg) + +Throughput testing can start as soon as the devices establish a connection and subscribe to indications/notifications on each other's GATT database. The status is indicated on the second line of the display, when both side show "ST: Subscribed" then testing is ready to start. + +Notifications can be pushed by pressing PB0 and indications can be pushed by pressing PB1. The data can be pushed from either kit since both have the throughput service on their GATT database and they subscribe to notifications/indications on the remote device's GATT. + +Data will be sent for as long as the button is pressed on the device and the status will be "ST: Testing" during that time. + +![Kits booted](readme_img6.jpg) + +Once the button is released the average throughput will be calculated and shown on the display as well as how many packets were sent. This information is on the two last lines of the display. + +![Kits booted](readme_img7.jpg) + + + +### EFR32 (SoC) <-> EFR32 (NCP) + Host (typically PC) + +The final use case consists of one kit flashed with _Bluetooth - SoC Throughput_ sample app and a second kit flashed with _Bluetooth - NCP Empty_. The NCP device will be controlled by a dedicated host application which is located in _C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite\v3.1\app\bluetooth\example_host\throughput_. + +> To learn more about NCP firmware and how to build the host applications please refer to [AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network Co-Processor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf). + +In this setup data can only be sent from the SoC to the NCP device because the NCP firmware does not contain the Throughput service in its GATT server. + + + +## Additional Notes + +These next sections describe some more details about the sample app. + +### Operation on 1-button boards + +The _Bluetooth - SoC Throughput_ also runs on boards which only have 1 user button, such as [SLTB010A](https://www.silabs.com/development-tools/thunderboard/thunderboard-bg22-kit) or [BGM220-EK4314A](https://www.silabs.com/development-tools/wireless/bluetooth/bgm220-explorer-kit). The behavior is determined by the button press duration: +* Short press will switch between sending notifications or indications. The default out of boot is sending notifications. +* Long press will send data. +* To boot into central mode instead of periperal, keep the button pressed while resetting the device. + +### CLI (Command Line Interface) + +The _Bluetooth - SoC Throughput_ sample app has a CLI which is used to report activity as well as modify parameters in runtime. You can easily access the CLI with a terminal emulator such as Tera Term or from within [Simplicity Studio](https://www.silabs.com/developers/simplicity-studio) by right-click on the debug adapter -> Launch Console -> Serial 1 tab -> type 'help' on the command prompt. + + ![CLI](readme_img8.png) + +The available command set allows multiple options such as changing connection parameters, MTU size, TX power, amongst others. + +On devices without display the CLI is used for printing a virtual display which mimics the +physical display on the mainboard. + + ![CLI](readme_img9.png) + + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_thunderboard/readme.html b/app/bluetooth/documentation/example/soc_thunderboard/readme.html deleted file mode 100644 index ad334a32c96..00000000000 --- a/app/bluetooth/documentation/example/soc_thunderboard/readme.html +++ /dev/null @@ -1,557 +0,0 @@ - - - - -readme - - -

SoC - Thunderboard

This sample application collects and processes sensor data from the Thunderboard Sense 2 or the Thunderboard EFR32BG22 board, and gives immediate graphical feedback to the user through the Thunderboard iOS/Android application.

Getting Started

To get started with Bluetooth and Simplicity Studio, see QSG169: Bluetooth® SDK v3.x Quick Start Guide.

To run this demo application, you need either a Thunderboard Sense 2 or a Thunderboard EFR32BG22 board, a mobile device, and the Thunderboard mobile application, available for iOS and Android.

Project Setup

The available sensors are different based on the board you use. For a list of the available features, see the User's Guide for the respective boards:

UG415:Thunderboard EFR32BG22 User's guide

UG309: Thunderboard Sense 2 User's Guide

After flashing the demo, the board will start to advertise, and after a 30 seconds timeout it will go to sleep mode. It will wake up when the left button (BTN0) is pressed. The state diagram of the firmware is shown below.

You can connect the device by tapping on the name of it in the Thunderboard app. After the connection is established, you will see the dashboard. There, you can select the categories of the different sensor types and the controls to see. -The screenshots are taken with the Thunderboard Sense 2, for the EFR32BG22 the same categories apply, but with a reduced set of sensors and LEDs. -By selecting the environment data, you can see the values of the different sensors mounted on the board, as shown below:

Within the I/O you can control the LEDs on the board and see the state of the push buttons. Inside the Motion part, you will see a 3D image of the board. Note that the orientation is changing when you move the board. See the image below. -

Project Structure

The project code is the same for both boards. The different sensor configurations are set in the automatically generated sl_component_catalog.h. The main application file, the app.c configures the project accordingly.

The Bluetooth-related event handling is implemented in the function sl_bt_on_event. -The projects contain the needed services in the GATT database. GATT definitions can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator:

To learn how to use the GATT Configurator, see UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x.

The sensors and I/O are also handled in this file by overriding the default weak implementation of the service handling functions.

Additional functionality can be added to the empty app_process_action function.

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_thunderboard/readme.md b/app/bluetooth/documentation/example/soc_thunderboard/readme.md new file mode 100644 index 00000000000..236d397c29c --- /dev/null +++ b/app/bluetooth/documentation/example/soc_thunderboard/readme.md @@ -0,0 +1,83 @@ +# SoC - Thunderboard + +This sample application collects and processes sensor data from the Thunderboard Sense 2 or the Thunderboard EFR32BG22 board, and gives immediate graphical feedback to the user through the Thunderboard iOS/Android application. + +## Getting Started + +To get started with Bluetooth and Simplicity Studio, see [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +To run this demo application, you need either a Thunderboard Sense 2 or a Thunderboard EFR32BG22 board, a mobile device, and the Thunderboard mobile application, available for [iOS](https://apps.apple.com/us/app/thunderboard/id1097181650) and [Android](https://play.google.com/store/apps/details?id=com.silabs.thunderboard). + +### Project Setup +The available sensors are different based on the board you use. For a list of the available features, see the User's Guide for the respective boards: + +[UG415:Thunderboard EFR32BG22 User's guide](https://www.silabs.com/documents/public/user-guides/ug415-sltb010a-user-guide.pdf) + +[UG309: Thunderboard Sense 2 User's Guide](https://www.silabs.com/documents/public/user-guides/ug309-sltb004a-user-guide.pdf) + +After flashing the demo, the board will start to advertise, and after a 30 seconds timeout it will go to sleep mode. It will wake up when the left button (BTN0) is pressed. The state diagram of the firmware is shown below. + +![](readme_img1.png) + +You can connect the device by tapping on the name of it in the Thunderboard app. After the connection is established, you will see the dashboard. There, you can select the categories of the different sensor types and the controls to see. +The screenshots are taken with the Thunderboard Sense 2, for the EFR32BG22 the same categories apply, but with a reduced set of sensors and LEDs. +By selecting the environment data, you can see the values of the different sensors mounted on the board, as shown below: + +![](readme_img2.png) ![](readme_img3.png) + +Within the I/O you can control the LEDs on the board and see the state of the push buttons. Inside the Motion part, you will see a 3D image of the board. Note that the orientation is changing when you move the board. See the image below. +![](readme_img4.png) ![](readme_img5.png) + +## Project Structure + +The project code is the same for both boards. The different sensor configurations are set in the automatically generated *sl_component_catalog.h*. The main application file, the *app.c* configures the project accordingly. + +The Bluetooth-related event handling is implemented in the function *sl_bt_on_event*. +The projects contain the needed services in the GATT database. GATT definitions can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator: + +![](readme_img6.png) + +To learn how to use the GATT Configurator, see [UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug438-gatt-configurator-users-guide-sdk-v3x.pdf). + +The sensors and I/O are also handled in this file by overriding the default weak implementation of the service handling functions. + +Additional functionality can be added to the empty *app_process_action* function. + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_voice/readme.html b/app/bluetooth/documentation/example/soc_voice/readme.html deleted file mode 100644 index 44aee48b6c4..00000000000 --- a/app/bluetooth/documentation/example/soc_voice/readme.html +++ /dev/null @@ -1,560 +0,0 @@ - - - - -readme - - -

SoC - Voice

This is a Voice over Bluetooth Low Energy sample application. It is supported by Thunderboard Sense 2 board and demonstrates how to send voice data over GATT, which is acquired from the on-board microphone.

 

Getting started

To get started with Bluetooth and Simplicity Studio, please refer to QSG169: Bluetooth® SDK v3.x Quick Start Guide.

For running the example you need a Thunderboard Sense 2 and another board, capable of running an NCP application. AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network CoProcessor Mode provides a detailed description of how NCP works and how to configure it.

One part of the example, the SoC Voice will run on the Thunderboard Sense, it provides the Voice Over Bluetooth Low Energy GATT service. It uses the microphone of the board to record and transmit voice.

The other part of the project runs on a PC. It connects to a board which is running the NCP empty example project. The program on the PC will use the NCP target to scan for the Thunderboard, connect to it, and saves the received audio data to the file system of the PC.

Project Setup

The whole project setup: -

Thunderboard part

Build and flash the provided code example. The device will advertise itself after startup with the name "VoBLE Ex". If you have multiple devices, you need to find out the Bluetooth address of the device, it can be done either with e.g. the EFR Connect app, or via the Simplicity Commander.

The EFR32 on the TB Sense samples the analog microphone using the ADC with the sampling rate and resolution configured by the GATT client. The sampled data is then run through a digital filter (if the filter usage is enabled) and coded using ADPCM codec before being sent via the Bluetooth link to the GATT client using notifications.

NCP Host part

The PC part of the example can be found under C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite\ version \app\bluetooth\example_host\voice, where "version" stands for you current SDK version, e.g. v3.0. -To build the project into an executable you will also need to use a make-tool, which is part of GNU developer tools. On Windows it is recommended to use MinGW. More details can be found in the AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network CoProcessor Mode, chapter 3.2. -To compile the NCP application:

  1. Open your terminal and navigate to the above mentioned folder.
  2. Run mingw32-make
  3. The build output is created in a new "exe" folder

Running the exe without any parameters will give you this help response: - -The program can be configured using the flags show in the above image. When giving the parameters to the program, all units must be omitted.

Few notes about the parameters:

  1. COM Port: This is the serial port to be used. It should point to the port used by the NCP-target. You can check the correct port number with BGTool or Device Manager, the WSTK lists as a “JLink CDC UART Port”. (If you are having problems identifying the port, you should unplug all WSTKs except the one you wish to use as the NCP.)
  2. Baud Rate: the baud rate used for the communication, default: 115200
  3. Output file name: Filename for the audio data output (without the file extension).
  4. Bluetooth address: Bluetooth address of the TB Sense board that you want to connect to. If left out, the application tries to search devices that match the default UUID of the TB Sense application.
  5. Enable/Disable filtering: Toggle whether filtering is used, see filter types in previous section for options. The filter is disabled by default.
  6. Enable/Disable encoding: Toggle whether the audio data should be encoded, enabled by default. If encoding is disabled the output filetype will be either “.s8” or “.s16” depending on the sample rate. Encoded filetype is always “.ima” (Dialogic ADPCM -format).
  7. Verbose: If this switch is added the application prints out status messages.

Saving the audio to a file

To record audio into an audio file using this ncp-host-application, you will have to provide at least the following parameters (examples in parenthesis):

  • Serial port for the ncp-target ( -p COM6 )
  • output filename ( -o my_audio_file )

In the example below, we are using the verbose mode with the default settings for both sampling rate and resolution (16kHz and 12 bits respectively) and saving the audio data in a file called audio_file.

If you have activated the verbose mode, as in the above image, you will get status messages from the GATT client application. The application will stop printing status messages after is has written all the configurations, which in the above image happens after transfer status has successfully been enabled. When the initialization is done, the GATT client (ncp-host) is ready to receive data from the TB Sense.

To start recording and streaming audio data over the BLE link, press and hold TB Sense BTN0 (left button). Once the button is pressed, you should see activity on the terminal window, summarizing the transmission progress. All the audio data will be saved to a file defined by the output filename -parameter ( audio_file.ima in this example ). If a file with a same name already exists, the audio data is appended to the end of that file.

To end the transmission in progress, send a interrupt signal to the application. On windows keyboard interrupt signal can be sent with CTRL+C key combination.

SoC project structure

The example project contains the GATT database with the necessary Voice over Bluetooth Low Energy Service. GATT definitions can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator. To open the Project Configurator open the .slcp file of the project.

To learn how to use the GATT Configurator please refer to UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x.

The Bluetooth event handling is implemented in the app.c file, in the function sl_bt_on_event. This handles the advertising, accepting the configuration parameters, and sending out the data. -The button handling logic is also implemented in this file. -The handling of the microphone, the encoding, buffering and filtering can be found in their respective files:

  • adpcm.c
  • filter.c
  • voice.c
  • circular_buffer.c

Troubleshooting

Note that NO Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either

  • flash a bootloader to the device or
  • uninstall the OTA DFU and Bootloader Application Interface software components.

To flash a bootloader, you should either create a bootloader project or run a precompiled Demo on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device.

  • To flash an OTA DFU capable bootloader to your device, SoC-Thermometer demo can be flashed before your application to load the bootloader.
  • To flash a UART DFU capable bootloader to your device, NCP-Empty demo can be flashed before your application to load the bootloader.
  • For your custom application, create your own bootloader project and flash it to your device before flashing your application.
  • When you flash your application image to the device, use the .hex or .s37 output file. Flashing .bin files may overwrite (erase) the bootloader.
  • On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the *-combined.s37 file found in your bootloader project after building the project.
  • For more information, see UG103: Bootloading fundamentals and UG266: Silicon Labs Gecko Bootloader User's Guide.

Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below.

Radio board power supply switch

 

Resources

Bluetooth Documentation

UG103.14: Bluetooth® LE Fundamentals

QSG169: Bluetooth® SDK v3.x Quick Start Guide

UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x

Bluetooth Training

 

Report Bugs & Get Support

You are always encouraged and welcome to report any issues you found to us via Silicon Labs Community.

- - \ No newline at end of file diff --git a/app/bluetooth/documentation/example/soc_voice/readme.md b/app/bluetooth/documentation/example/soc_voice/readme.md new file mode 100644 index 00000000000..969a29666ae --- /dev/null +++ b/app/bluetooth/documentation/example/soc_voice/readme.md @@ -0,0 +1,122 @@ +# SoC - Voice + +This is a Voice over Bluetooth Low Energy sample application. It is supported by Thunderboard Sense 2 board and demonstrates how to send voice data over GATT, which is acquired from the on-board microphone. + + + +## Getting started + +To get started with Bluetooth and Simplicity Studio, please refer to [QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf). + +For running the example you need a Thunderboard Sense 2 and another board, capable of running an NCP application. [AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network CoProcessor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf) provides a detailed description of how NCP works and how to configure it. + +One part of the example, the SoC Voice will run on the Thunderboard Sense, it provides the Voice Over Bluetooth Low Energy GATT service. It uses the microphone of the board to record and transmit voice. + +The other part of the project runs on a PC. It connects to a board which is running the NCP empty example project. The program on the PC will use the NCP target to scan for the Thunderboard, connect to it, and saves the received audio data to the file system of the PC. + + +## Project Setup +The whole project setup: +![](readme_img1.png) + +### Thunderboard part +Build and flash the provided code example. The device will advertise itself after startup with the name "VoBLE Ex". If you have multiple devices, you need to find out the Bluetooth address of the device, it can be done either with e.g. the EFR Connect app, or via the Simplicity Commander. + +The EFR32 on the TB Sense samples the analog microphone using the ADC with the sampling rate and resolution configured by the GATT client. The sampled data is then run through a digital filter (if the filter usage is enabled) and coded using ADPCM codec before being sent via the Bluetooth link to the GATT client using notifications. + +![](readme_img2.png) + + +### NCP Host part +The PC part of the example can be found under C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite\ *version* \app\bluetooth\example_host\voice, where "version" stands for you current SDK version, e.g. v3.0. +To build the project into an executable you will also need to use a make-tool, which is part of GNU developer tools. On Windows it is recommended to use MinGW. More details can be found in the [AN1259: Using the v3.x Silicon Labs Bluetooth® Stack in Network CoProcessor Mode](https://www.silabs.com/documents/public/application-notes/an1259-bt-ncp-mode-sdk-v3x.pdf), chapter 3.2. +To compile the NCP application: + +1. Open your terminal and navigate to the above mentioned folder. +2. Run mingw32-make +3. The build output is created in a new "exe" folder + +Running the exe without any parameters will give you this help response: +![](readme_img3.png) +The program can be configured using the flags show in the above image. When giving the parameters to the program, all units must be omitted. + +Few notes about the parameters: +1. **COM Port**: This is the serial port to be used. It should point to the port used by the NCP-target. You can check the correct port number with BGTool or Device Manager, the WSTK lists as a “JLink CDC UART Port”. (If you are having problems identifying the port, you should unplug all WSTKs except the one you wish to use as the NCP.) +2. **Baud Rate**: the baud rate used for the communication, default: 115200 +3. **Output file name**: Filename for the audio data output (without the file extension). +4. **Bluetooth address**: Bluetooth address of the TB Sense board that you want to connect to. If left out, the application tries to search devices that match the default UUID of the TB Sense application. +5. **Enable/Disable filtering**: Toggle whether filtering is used, see filter types in previous section for options. The filter is disabled by default. +6. **Enable/Disable encoding**: Toggle whether the audio data should be encoded, enabled by default. If encoding is disabled the output filetype will be either “.s8” or “.s16” depending on the sample rate. Encoded filetype is always “.ima” (Dialogic ADPCM -format). +7. **Verbose**: If this switch is added the application prints out status messages. + +#### Saving the audio to a file +To record audio into an audio file using this ncp-host-application, you will have to provide at least the following parameters (examples in parenthesis): + +* Serial port for the ncp-target ( -p COM6 ) +* output filename ( -o my_audio_file ) + +In the example below, we are using the verbose mode with the default settings for both sampling rate and resolution (16kHz and 12 bits respectively) and saving the audio data in a file called audio_file. + +![](readme_img4.png) + +If you have activated the verbose mode, as in the above image, you will get status messages from the GATT client application. The application will stop printing status messages after is has written all the configurations, which in the above image happens after transfer status has successfully been enabled. When the initialization is done, the GATT client (ncp-host) is ready to receive data from the TB Sense. + +To start recording and streaming audio data over the BLE link, press and hold TB Sense BTN0 (left button). Once the button is pressed, you should see activity on the terminal window, summarizing the transmission progress. All the audio data will be saved to a file defined by the output filename -parameter ( audio_file.ima in this example ). If a file with a same name already exists, the audio data is appended to the end of that file. + +To end the transmission in progress, send a interrupt signal to the application. On windows keyboard interrupt signal can be sent with CTRL+C key combination. + + +## SoC project structure +The example project contains the GATT database with the necessary Voice over Bluetooth Low Energy Service. GATT definitions can be extended using the GATT Configurator, which can be found under Advanced Configurators in the Software Components tab of the Project Configurator. To open the Project Configurator open the .slcp file of the project. + +![](readme_img5.png) + +To learn how to use the GATT Configurator please refer to [UG438: GATT Configurator User’s Guide for Bluetooth® SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug438-gatt-configurator-users-guide-sdk-v3x.pdf). + +The Bluetooth event handling is implemented in the *app.c* file, in the function *sl_bt_on_event*. This handles the advertising, accepting the configuration parameters, and sending out the data. +The button handling logic is also implemented in this file. +The handling of the microphone, the encoding, buffering and filtering can be found in their respective files: +* adpcm.c +* filter.c +* voice.c +* circular_buffer.c + + +## Troubleshooting + +Note that __NO__ Bootloader is included in any Software Example projects, but they are configured so, that they expect a bootloader to be present on the device. To get your application work, you should either +- flash a bootloader to the device or +- uninstall the **OTA DFU** and **Bootloader Application Interface** software components. + +To flash a bootloader, you should either create a bootloader project or run a precompiled **Demo** on your device from the Launcher view. Precompiled Demos flash both bootloader and application images to your device. + +- To flash an OTA DFU capable bootloader to your device, *SoC-Thermometer* demo can be flashed before your application to load the bootloader. +- To flash a UART DFU capable bootloader to your device, *NCP-Empty* demo can be flashed before your application to load the bootloader. +- For your custom application, create your own bootloader project and flash it to your device before flashing your application. +- When you flash your application image to the device, use the *.hex* or *.s37* output file. Flashing *.bin* files may overwrite (erase) the bootloader. +- On Series 1 devices (EFR32xG1x), both first stage and second stage bootloaders have to be flashed. This can be done at once by flashing the **-combined.s37* file found in your bootloader project after building the project. +- For more information, see *[UG103: Bootloading fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf)* and *[UG266: Silicon Labs Gecko Bootloader User's Guide](https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf)*. + +Before programming the radio board mounted on the WSTK, make sure the power supply switch the AEM position (right side) as shown below. + +![Radio board power supply switch](readme_img0.png) + + + +## Resources + +[Bluetooth Documentation](https://docs.silabs.com/bluetooth/latest/) + +[UG103.14: Bluetooth® LE Fundamentals](https://www.silabs.com/documents/public/user-guides/ug103-14-fundamentals-ble.pdf) + +[QSG169: Bluetooth® SDK v3.x Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg169-bluetooth-sdk-v3x-quick-start-guide.pdf) + +[UG434: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v3.x](https://www.silabs.com/documents/public/user-guides/ug434-bluetooth-c-soc-dev-guide-sdk-v3x.pdf) + +[Bluetooth Training](https://www.silabs.com/support/training/bluetooth) + + + +## Report Bugs & Get Support + +You are always encouraged and welcome to report any issues you found to us via [Silicon Labs Community](https://www.silabs.com/community). \ No newline at end of file diff --git a/app/bluetooth/documentation/release-highlights.txt b/app/bluetooth/documentation/release-highlights.txt index 3b2751eb124..8a6dfb31bd6 100644 --- a/app/bluetooth/documentation/release-highlights.txt +++ b/app/bluetooth/documentation/release-highlights.txt @@ -1,9 +1,5 @@ -Bluetooth SDK 3.3.0.0 -* Bluetooth v5.3 qualified -* New Co-Processor Communication (CPC) transport for RCP/HCI -* RTOS support in RCP mode -* Improved tools for Angle-of-Arrival evaluation and development -* Interoperability testing example added to the SDK +Bluetooth SDK 3.3.1.0 +- Selected quality improvements and bug fixes diff --git a/app/bluetooth/documentation/slBluetooth_docContent.xml b/app/bluetooth/documentation/slBluetooth_docContent.xml index d841b012f87..e8ee793f309 100644 --- a/app/bluetooth/documentation/slBluetooth_docContent.xml +++ b/app/bluetooth/documentation/slBluetooth_docContent.xml @@ -1,6 +1,6 @@ - + @@ -8,7 +8,7 @@ Includes detailed information on using the Gecko Bootloader with Silicon Labs Bluetooth applications. It supplements the general Gecko Bootloader implementation information provided in UG489: Silicon Labs Gecko Bootloader User's Guide. - + @@ -16,7 +16,7 @@ Describes the Wi-Fi impact on Bluetooth and methods to improve Bluetooth coexistence with Wi-Fi. Explains design considerations to improve coexistence without direct interaction between Bluetooth and Wi-Fi radios. These techniques are applicable to the EFR32MGx and EFR32BGx series. Discusses the Silicon Labs Packet Traffic Arbitration (PTA) support to coordinate 2.4GHz RF traffic for co-located Bluetooth and Wi-Fi radios. - + @@ -24,7 +24,7 @@ Explains how NVM3 can be used as non-volatile data storage in various protocol implementations. - + @@ -32,7 +32,7 @@ Describes how to lock and unlock the debug access of EFR32 Gecko Series 2 devices. Many aspects of the debug access, including the secure debug unlock are described. The Debug Challenge Interface (DCI) and Secure Engine (SE) Mailbox Interface for locking and unlocking debug access are also included. - + @@ -40,7 +40,7 @@ Contains detailed information on configuring and using the Secure Boot with hardware Root of Trust and Secure Loader on Series 2 devices, including how to provision the signing key. This is a companion document to UG489: Silicon Labs Gecko Bootloader User's Guide. - + @@ -48,14 +48,14 @@ Details on programming, provisioning, and configuring Series 2 devices in production environments. Covers Secure Engine Subsystem of Series 2 devices, which runs easily upgradeable Secure Engine (SE) or Virtual Secure Engine (VSE) firmware. - + Describes how to measure the power consumption of EFR32BG devices running the Bluetooth i-Beacon example. For general instructions, see AN969: Measuring Power Consumption in Wireless Gecko Devices, available on silabs.com. - + @@ -63,21 +63,22 @@ How to program, provision, and configure the anti-tamper module on EFR32 Series 2 devices with Secure Vault. - + + Describes how to configure the NCP target and how to program the NCP host when using the Bluetooth Stack in Network Co-Processor mode - + Describes how to integrate a v3.x Silicon Labs Bluetooth application with an RTOS, and demonstrate how a time- and event-driven application can be run in parallel with the Bluetooth stack. - + @@ -85,7 +86,7 @@ Reviews performing radio frequency physical layer evaluation with EFR32BG SoCs and BGM modules using the Direct Test Mode protocol in Bluetooth SDK v3.x. - + @@ -93,14 +94,14 @@ How to authenticate an EFR32 Series 2 device with Secure Vault, using secure device certificates and signatures. - + Provides details on how to develop a dynamic multiprotocol application running Bluetooth and a proprietary protocol on RAIL in GSDK v3.x. - + @@ -108,28 +109,28 @@ How to securely "wrap" keys in EFR32 Series 2 devices with Secure Vault, so they can be stored in non-volatile storage. - + Describes the sample applications provided to demonstrate the directing finding capabilities of Bluetooth 5.1. Angle of Arrival (AoA) estimation is demonstrated with the use of Silicon Labs' Real Time Locating (RTL) library. These techniques are applicable to the EFR32MGx and EFR32BGx series. - + Bluetooth 5.1 makes it possible to send Constant Tone Extensions (CTEs) in Bluetooth packets on which phase measurements can be done. This guide is for those implementing custom applications that take advantage of phase measurement and antenna switching capabilites. - + Provides details on designing Bluetooth Low Energy applications with security and privacy in mind. - + @@ -137,14 +138,14 @@ Describes how to provision and configure Series 2 devices through the DCI and SWD. - + Includes the results of the interoperability testing of Silicon Labs' ICs and Bluetooth Low Energy stack with Android and iOS smart phones. - + @@ -152,7 +153,7 @@ Describes how to integrate crypto functionality into applications using PSA Crypto compared to Mbed TLS. - + @@ -160,7 +161,7 @@ Describes using Simplicity Studio 5's Network Analyzer to debug Bluetooth Mesh and Low Energy applications. It can be read jointly with AN958: Debugging and Programming Interfaces for Customer Designs for more information on using Packet Trace Interface with custom hardware. - + @@ -168,84 +169,84 @@ Gecko Bootloader v2.x, introduced in GSDK 4.0, contains a number of changes compared to Gecko Bootloader v1.x. This document describes the differences between the versions, including how to configure the new Gecko Bootloader in Simplicity Studio 5. - + Gives a short overview of the standard Host Controller Interface (HCI) and how to use it with a Silicon Labs Bluetooth LE controller. - + Summarizes Amazon FreeRTOS components and sample applications, and explains how to use the examples to communicate with the Amazon Web Services (AWS) cloud with a smart phone app. - + Describes how to exploit the different features of Bluetooth technology to achieve the minimum possible energy consumption for a given use case. - + Provides an overview and hyperlinks to all packaged documentation. - + Describes the differences between using Bluetooth SDK v2.x in Simplicity Studio 4 and using Bluetooth SDK v3.x in Simplicity Studio 5. Outlines the steps needed to migrate a v2.x project to v3.x. - + Describes using the Simplicity Studio 5 IDE and tools for application development with Bluetooth SDK v3.x. - + Describes the software components provided by Silicon Labs to support Direction Finding (DF) and provides instructions on how to start developing your own application. - + Contains a comprehensive list of APIs used to interface to the Silicon Labs Bluetooth Real-Time Locating Library. - + Contains a comprehensive list of APIs used to interface to the Silicon Labs Bluetooth stack. - + Lists compatibility requirements and sources for all software components in the development environment. Discusses the latest changes to the Silicon Labs Bluetooth SDK and associated utilities, including added/deleted/deprecated features/API, and lists fixed and known issues. - + Discusses the latest changes to the The Real-Time Locating (RTL) library, including added/deleted/deprecated APIs, and lists fixed and known issues. - + @@ -253,7 +254,7 @@ A detailed overview of the changes, additions, and fixes in the Gecko Platform components. The Gecko Platform includes EMLIB, EMDRV, RAIL Library, NVM3, and the component-based infrastructure. - + @@ -261,7 +262,7 @@ Introduces the security concepts that must be considered when implementing an Internet of Things (IoT) system. Using the ioXt Alliance's eight security principles as a structure, it clearly delineates the solutions Silicon Labs provides to support endpoint security and what you must do outside of the Silicon Labs framework. - + @@ -269,7 +270,7 @@ Introduces bootloading for Silicon Labs networking devices. Discusses the Gecko Bootloader as well as legacy Ember and Bluetooth bootloaders, and describes the file formats used by each. - + @@ -277,14 +278,14 @@ Introduces non-volatile data storage using flash and the three different storage implementations offered for Silicon Labs microcontrollers and SoCs: Simulated EEPROM, PS Store, and NVM3. - + Offers an overview for those new to the Bluetooth low energy technology. - + @@ -292,7 +293,7 @@ Describes the four multiprotocol modes, discusses considerations when selecting protocols for multiprotocol implementations, and reviews the Radio Scheduler, a required component of a dynamic multiprotocol solution. - + @@ -300,14 +301,14 @@ Describes methods to improve the coexistence of 2.4 GHz IEEE 802.11b/g/n Wi-Fi and other 2.4 GHz radios such as Bluetooth, Bluetooth Mesh, Bluetooth Low Energy, and IEEE 802.15.4-based radios such as Zigbee and OpenThread. - + Explains the basics of Bluetooth Angle of Arrival (AoA) and Angle of Departure (AoD) direction finding technologies and provides the theory behind estimating angle of arrival. - + @@ -315,7 +316,7 @@ Reviews using this XML-based mark-up language to describe the Bluetooth GATT database, configure access and security properties, and include the GATT database as part of the firmware. - + @@ -323,7 +324,7 @@ Describes how and when to use Simplicity Commander's Command-Line Interface. - + @@ -331,14 +332,14 @@ Describes how to implement a dynamic multiprotocol solution. - + Covers the Bluetooth stack v3.x architecture, application development flow, using the MCU core and peripherals, stack configuration options, and stack resource usage. - + @@ -346,7 +347,7 @@ Describes how to use the Simplicity Studio 5 GATT Configurator, an intuitive interface providing access to all the Profiles, Services, Characteristics, and Descriptors as defined in the Bluetooth specification. - + @@ -354,4 +355,11 @@ Describes the high-level implementation of the Silicon Labs Gecko Bootloader for EFR32 SoCs and NCPs, and provides information on how to get started using the Gecko Bootloader with Silicon Labs wireless protocol stacks in GSDK 4.0 and higher. + + + + + + The Bluetooth Direction Finding Tool Suite is meant to ease development with the Silicon Labs' RTL library. It provides multiple tools to configure the system, and also helps the development with analyzer tools that calculate many output parameters from the observed IQ samples. + diff --git a/app/bluetooth/documentation/slBtMesh_docContent.xml b/app/bluetooth/documentation/slBtMesh_docContent.xml index 0dc3e8d791e..4a3d041b242 100644 --- a/app/bluetooth/documentation/slBtMesh_docContent.xml +++ b/app/bluetooth/documentation/slBtMesh_docContent.xml @@ -1,6 +1,6 @@ - + @@ -8,7 +8,7 @@ Includes detailed information on using the Gecko Bootloader with Silicon Labs Bluetooth applications. It supplements the general Gecko Bootloader implementation information provided in UG489: Silicon Labs Gecko Bootloader User's Guide. - + @@ -16,7 +16,7 @@ Describes the Wi-Fi impact on Bluetooth and methods to improve Bluetooth coexistence with Wi-Fi. Explains design considerations to improve coexistence without direct interaction between Bluetooth and Wi-Fi radios. These techniques are applicable to the EFR32MGx and EFR32BGx series. Discusses the Silicon Labs Packet Traffic Arbitration (PTA) support to coordinate 2.4GHz RF traffic for co-located Bluetooth and Wi-Fi radios. - + @@ -24,14 +24,14 @@ Explains how NVM3 can be used as non-volatile data storage in various protocol implementations. - + Details methods for testing Bluetooth mesh network performance; results are intended to provide guidance on design practices and principles as well as expected field performance results. - + @@ -39,7 +39,7 @@ Reviews the Zigbee, Thread, and Bluetooth mesh networks to evaluate their differences in performance and behavior. - + @@ -47,7 +47,7 @@ Describes how to lock and unlock the debug access of EFR32 Gecko Series 2 devices. Many aspects of the debug access, including the secure debug unlock are described. The Debug Challenge Interface (DCI) and Secure Engine (SE) Mailbox Interface for locking and unlocking debug access are also included. - + @@ -55,7 +55,7 @@ Contains detailed information on configuring and using the Secure Boot with hardware Root of Trust and Secure Loader on Series 2 devices, including how to provision the signing key. This is a companion document to UG489: Silicon Labs Gecko Bootloader User's Guide. - + @@ -63,7 +63,7 @@ Details on programming, provisioning, and configuring Series 2 devices in production environments. Covers Secure Engine Subsystem of Series 2 devices, which runs easily upgradeable Secure Engine (SE) or Virtual Secure Engine (VSE) firmware. - + @@ -71,7 +71,15 @@ How to program, provision, and configure the anti-tamper module on EFR32 Series 2 devices with Secure Vault. - + + + + + + + Describes how to configure the NCP target and how to program the NCP host when using the Bluetooth Stack in Network Co-Processor mode + + @@ -79,7 +87,7 @@ Reviews performing radio frequency physical layer evaluation with EFR32BG SoCs and BGM modules using the Direct Test Mode protocol in Bluetooth SDK v3.x. - + @@ -87,7 +95,7 @@ How to authenticate an EFR32 Series 2 device with Secure Vault, using secure device certificates and signatures. - + @@ -95,28 +103,28 @@ How to securely "wrap" keys in EFR32 Series 2 devices with Secure Vault, so they can be stored in non-volatile storage. - + Describes the differences between using Bluetooth mesh SDK v1.x in Simplicity Studio 4 and using Bluetooth mesh SDK v2.x in Simplicity Studio 5. Outlines the steps needed to migrate a v1.x project to v2.x. - + Discusses the basics of Bluetooth mesh required to understand the Bluetooth mesh lighting example, and walks through key aspects of the application source code. - + Discusses the basics of sensor models and describe the related sample applications in the SDK that create a wireless network of sensors and sensor clients using Bluetooth mesh technology. - + @@ -124,14 +132,14 @@ Describes how to provision and configure Series 2 devices through the DCI and SWD. - + Includes the results of the interoperability testing of Silicon Labs' ICs and Bluetooth Mesh stack with Android and iOS smart phones. - + @@ -139,21 +147,21 @@ Describes how to integrate crypto functionality into applications using PSA Crypto compared to Mbed TLS. - + Describes Low Power Node (LPN) and Friend operation and the parameters related to power consumption. It also describes how to measure the power consumption of EFR32BG devices acting as Bluetooth mesh LPNs using the setup and procedures recommended in AN969: Measuring Power Consumption in Wireless Gecko Devices. - + Describes in detail how the Bluetooth mesh toplogy can influence network operation. Provides tips on how to tune your network and its nodes to achieve best performance. - + @@ -161,14 +169,14 @@ Describes using Simplicity Studio 5's Network Analyzer to debug Bluetooth Mesh and Low Energy applications. It can be read jointly with AN958: Debugging and Programming Interfaces for Customer Designs for more information on using Packet Trace Interface with custom hardware. - + Provides background information on the sequence number and IV index in a Bluetooth mesh network and the IV Update and IV Index Recovery procedures. It also discusses how to implement IV Update functionality in a Bluetooth mesh application. - + @@ -176,49 +184,49 @@ Gecko Bootloader v2.x, introduced in GSDK 4.0, contains a number of changes compared to Gecko Bootloader v1.x. This document describes the differences between the versions, including how to configure the new Gecko Bootloader in Simplicity Studio 5. - + The NCP Host Provisioner example demonstrates how to run a provisioner on a computer with a NCP node connected. The user can provision, configure, and reset other nodes through the NCP node. - + Provides an overview and hyperlinks to all packaged documentation. - + Describes using the Simplicity Studio 5 IDE and tools for application development with Bluetooth Mesh SDK v2.x. - + Contains a comprehensive list of APIs used to interface to the Silicon Labs Bluetooth Mesh stack. - + A reference for those developing C-based applications for the Silicon Labs EFR32 products using the Silicon Labs Bluetooth mesh stack. A companion to UG434: Silicon Labs Bluetooth C Application Developers Guide for SDK v3.x containing content specific to Bluetooth mesh application development. Covers Bluetooth mesh stack architecture, application development flow, use and limitations of the MCU core and peripherals, stack configuration options, and stack resource usage. - + Lists compatibility requirements and sources for all software components in the development environment. Discusses the latest changes to the Silicon Labs Bluetooth mesh SDK and associated utilities, including added/deleted/deprecated features/API, and lists fixed and known issues. - + @@ -226,7 +234,7 @@ A detailed overview of the changes, additions, and fixes in the Gecko Platform components. The Gecko Platform includes EMLIB, EMDRV, RAIL Library, NVM3, and the component-based infrastructure. - + @@ -234,7 +242,7 @@ Introduces the security concepts that must be considered when implementing an Internet of Things (IoT) system. Using the ioXt Alliance's eight security principles as a structure, it clearly delineates the solutions Silicon Labs provides to support endpoint security and what you must do outside of the Silicon Labs framework. - + @@ -242,7 +250,7 @@ Introduces bootloading for Silicon Labs networking devices. Discusses the Gecko Bootloader as well as legacy Ember and Bluetooth bootloaders, and describes the file formats used by each. - + @@ -250,7 +258,7 @@ Introduces non-volatile data storage using flash and the three different storage implementations offered for Silicon Labs microcontrollers and SoCs: Simulated EEPROM, PS Store, and NVM3. - + @@ -258,7 +266,7 @@ Describes methods to improve the coexistence of 2.4 GHz IEEE 802.11b/g/n Wi-Fi and other 2.4 GHz radios such as Bluetooth, Bluetooth Mesh, Bluetooth Low Energy, and IEEE 802.15.4-based radios such as Zigbee and OpenThread. - + @@ -266,7 +274,7 @@ Reviews using this XML-based mark-up language to describe the Bluetooth GATT database, configure access and security properties, and include the GATT database as part of the firmware. - + @@ -274,7 +282,7 @@ Describes how and when to use Simplicity Commander's Command-Line Interface. - + @@ -282,14 +290,14 @@ Describes how to use the Simplicity Studio 5 GATT Configurator, an intuitive interface providing access to all the Profiles, Services, Characteristics, and Descriptors as defined in the Bluetooth specification. - + Describes the components, stack, and DCD (Device Composition Data) configuration options for the Bluetooth Mesh v2.x SDK. - + diff --git a/app/bluetooth/esf.properties b/app/bluetooth/esf.properties index ea410535771..36ceb41680d 100644 --- a/app/bluetooth/esf.properties +++ b/app/bluetooth/esf.properties @@ -2,9 +2,8 @@ id=com.silabs.stack.ble label=Bluetooth SDK description=Bluetooth Software Development Kit -version=3.3.0.0 -dependantSdkVersion=3.3.0 -prop.subLabel=Bluetooth\\ 3.3.0 +version=3.3.1.0 +prop.subLabel=Bluetooth\\ 3.3.1 # Default compatibility of the BLE SDK prop.boardCompatibility=.* diff --git a/app/bluetooth/example/ncp/ncp.slcp b/app/bluetooth/example/ncp/ncp.slcp index 52813be5825..29776f829c3 100644 --- a/app/bluetooth/example/ncp/ncp.slcp +++ b/app/bluetooth/example/ncp/ncp.slcp @@ -45,7 +45,7 @@ include: - path: app.h readme: - - path: ../../documentation/example/ncp/readme.html + - path: ../../documentation/example/ncp/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -87,5 +87,5 @@ tag: ui_hints: highlight: - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/ncp_aoa_locator/ncp_aoa_locator.slcp b/app/bluetooth/example/ncp_aoa_locator/ncp_aoa_locator.slcp index 6dcec036618..f4e089bc823 100644 --- a/app/bluetooth/example/ncp_aoa_locator/ncp_aoa_locator.slcp +++ b/app/bluetooth/example/ncp_aoa_locator/ncp_aoa_locator.slcp @@ -42,7 +42,7 @@ include: - path: app.h readme: - - path: ../../documentation/example/ncp_aoa_locator/readme.html + - path: ../../documentation/example/ncp_aoa_locator/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -78,5 +78,5 @@ tag: ui_hints: highlight: - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/ncp_btmesh_empty/dcd_config.btmeshconf b/app/bluetooth/example/ncp_btmesh_empty/dcd_config.btmeshconf index 195a364f0d4..e65b64dd01e 100644 --- a/app/bluetooth/example/ncp_btmesh_empty/dcd_config.btmeshconf +++ b/app/bluetooth/example/ncp_btmesh_empty/dcd_config.btmeshconf @@ -2,7 +2,7 @@ "composition_data": { "cid": "0x02ff", "pid": "0x0000", - "vid": "0x0220", + "vid": "0x0221", "elements": [ { "name": "Primary Element", diff --git a/app/bluetooth/example/ncp_btmesh_empty/dcd_config_xg22.btmeshconf b/app/bluetooth/example/ncp_btmesh_empty/dcd_config_xg22.btmeshconf index 46cfdc508d4..a433516756d 100644 --- a/app/bluetooth/example/ncp_btmesh_empty/dcd_config_xg22.btmeshconf +++ b/app/bluetooth/example/ncp_btmesh_empty/dcd_config_xg22.btmeshconf @@ -2,7 +2,7 @@ "composition_data": { "cid": "0x02ff", "pid": "0x0000", - "vid": "0x0220", + "vid": "0x0221", "elements": [ { "name": "Main", diff --git a/app/bluetooth/example/ncp_btmesh_empty/ncp_btmesh_empty.slcp b/app/bluetooth/example/ncp_btmesh_empty/ncp_btmesh_empty.slcp index 4ff990c8eb7..e5613e4a856 100644 --- a/app/bluetooth/example/ncp_btmesh_empty/ncp_btmesh_empty.slcp +++ b/app/bluetooth/example/ncp_btmesh_empty/ncp_btmesh_empty.slcp @@ -79,7 +79,7 @@ config_file: directory: "btmeshconf" readme: - - path: ../../documentation/example/ncp_btmesh_empty/readme.html + - path: ../../documentation/example/ncp_btmesh_empty/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -143,5 +143,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/ncp_btmesh_empty/ncp_btmesh_empty_xg22.slcp b/app/bluetooth/example/ncp_btmesh_empty/ncp_btmesh_empty_xg22.slcp index eb71dfde383..ce691f5f0eb 100644 --- a/app/bluetooth/example/ncp_btmesh_empty/ncp_btmesh_empty_xg22.slcp +++ b/app/bluetooth/example/ncp_btmesh_empty/ncp_btmesh_empty_xg22.slcp @@ -55,7 +55,7 @@ config_file: directory: "btmeshconf" readme: - - path: ../../documentation/example/ncp_btmesh_empty/readme.html + - path: ../../documentation/example/ncp_btmesh_empty/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -153,5 +153,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/ncp_empty/ncp_empty.slcp b/app/bluetooth/example/ncp_empty/ncp_empty.slcp index 1505fae8aa4..d2543b4ad66 100644 --- a/app/bluetooth/example/ncp_empty/ncp_empty.slcp +++ b/app/bluetooth/example/ncp_empty/ncp_empty.slcp @@ -45,7 +45,7 @@ include: - path: app.h readme: - - path: ../../documentation/example/ncp_empty/readme.html + - path: ../../documentation/example/ncp_empty/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -90,5 +90,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/ncp_host/ncp_host.slcp b/app/bluetooth/example/ncp_host/ncp_host.slcp index 0eefa3ef77b..482e36317e5 100644 --- a/app/bluetooth/example/ncp_host/ncp_host.slcp +++ b/app/bluetooth/example/ncp_host/ncp_host.slcp @@ -38,7 +38,7 @@ config_file: directory: btconf readme: - - path: ../../documentation/example/ncp_host/readme.html + - path: ../../documentation/example/ncp_host/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -73,5 +73,5 @@ configuration: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/rcp/rcp.slcp b/app/bluetooth/example/rcp/rcp.slcp index 8ee4c79e364..b5d2ccbc980 100644 --- a/app/bluetooth/example/rcp/rcp.slcp +++ b/app/bluetooth/example/rcp/rcp.slcp @@ -33,7 +33,7 @@ include: - path: app.h readme: - - path: ../../documentation/example/rcp/readme.html + - path: ../../documentation/example/rcp/readme.md other_file: - path: ../../documentation/example/rcp/readme_img0.png @@ -48,13 +48,15 @@ other_file: configuration: - name: SL_HEAP_SIZE - value: "9700" + value: "11000" + - name: SL_BT_CONTROLLER_BUFFER_MEMORY + value: 7168 - name: SL_BT_CONFIG_USER_ADVERTISERS value: 2 - name: SL_BOARD_ENABLE_VCOM value: 1 - name: SL_UARTDRV_USART_VCOM_FLOW_CONTROL_TYPE - value: uartdrvFlowControlHw + value: uartdrvFlowControlNone - name: SL_PSA_KEY_USER_SLOT_COUNT value: "0" condition: @@ -65,5 +67,5 @@ tag: ui_hints: highlight: - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/rcp/rcp_cpc.slcp b/app/bluetooth/example/rcp/rcp_cpc.slcp index e9e89c47b30..32fd5d017d2 100644 --- a/app/bluetooth/example/rcp/rcp_cpc.slcp +++ b/app/bluetooth/example/rcp/rcp_cpc.slcp @@ -35,24 +35,21 @@ include: - path: app.h readme: - - path: ../../documentation/example/rcp/readme.html + - path: ../../documentation/example/rcp_cpc/readme.md other_file: - - path: ../../documentation/example/rcp/readme_img0.png + - path: ../../documentation/example/rcp_cpc/readme_img0.png folder: images - - path: ../../documentation/example/rcp/readme_img1.png + - path: ../../documentation/example/rcp_cpc/readme_img1.png folder: images - - path: ../../documentation/example/rcp/readme_img2.png + - path: ../../documentation/example/rcp_cpc/readme_img2.png folder: images - - path: ../../documentation/example/rcp/readme_img3.png - folder: images - - path: ../../documentation/example/rcp/readme_img4.png configuration: - name: SL_STACK_SIZE value: 2752 - name: SL_HEAP_SIZE - value: "10700" + value: "16000" - name: SL_BOARD_ENABLE_VCOM value: 1 - name: SL_BT_CONFIG_USER_ADVERTISERS @@ -84,5 +81,5 @@ tag: ui_hints: highlight: - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_aoa_asset_tag/soc_aoa_asset_tag.slcp b/app/bluetooth/example/soc_aoa_asset_tag/soc_aoa_asset_tag.slcp index e2ef3668f84..b68d0c80783 100644 --- a/app/bluetooth/example/soc_aoa_asset_tag/soc_aoa_asset_tag.slcp +++ b/app/bluetooth/example/soc_aoa_asset_tag/soc_aoa_asset_tag.slcp @@ -49,7 +49,7 @@ config_file: directory: btconf readme: - - path: ../../documentation/example/soc_aoa_asset_tag/readme.html + - path: ../../documentation/example/soc_aoa_asset_tag/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -82,5 +82,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_blinky/soc_blinky.slcp b/app/bluetooth/example/soc_blinky/soc_blinky.slcp index 5f3ea9efbcb..5959261de59 100644 --- a/app/bluetooth/example/soc_blinky/soc_blinky.slcp +++ b/app/bluetooth/example/soc_blinky/soc_blinky.slcp @@ -50,7 +50,7 @@ config_file: directory: btconf readme: - - path: ../../documentation/example/soc_blinky/readme.html + - path: ../../documentation/example/soc_blinky/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -88,5 +88,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_blinky/soc_blinky_shared.slcp b/app/bluetooth/example/soc_blinky/soc_blinky_shared.slcp index 2ae192c77d5..96af604c257 100644 --- a/app/bluetooth/example/soc_blinky/soc_blinky_shared.slcp +++ b/app/bluetooth/example/soc_blinky/soc_blinky_shared.slcp @@ -50,7 +50,7 @@ config_file: directory: btconf readme: - - path: ../../documentation/example/soc_blinky/readme.html + - path: ../../documentation/example/soc_blinky/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -88,5 +88,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_btmesh_empty/dcd_config.btmeshconf b/app/bluetooth/example/soc_btmesh_empty/dcd_config.btmeshconf index 35a8141c464..04e6bcf0e8a 100644 --- a/app/bluetooth/example/soc_btmesh_empty/dcd_config.btmeshconf +++ b/app/bluetooth/example/soc_btmesh_empty/dcd_config.btmeshconf @@ -2,7 +2,7 @@ "composition_data": { "cid": "0x02ff", "pid": "0x0001", - "vid": "0x0220", + "vid": "0x0221", "elements": [ { "name": "Main", diff --git a/app/bluetooth/example/soc_btmesh_empty/soc_btmesh_empty.slcp b/app/bluetooth/example/soc_btmesh_empty/soc_btmesh_empty.slcp index f120f5bb65d..56dfa074c94 100644 --- a/app/bluetooth/example/soc_btmesh_empty/soc_btmesh_empty.slcp +++ b/app/bluetooth/example/soc_btmesh_empty/soc_btmesh_empty.slcp @@ -46,7 +46,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_empty/readme.html + - path: ../../documentation/example/soc_btmesh_empty/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -94,5 +94,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_hsl/app.c b/app/bluetooth/example/soc_btmesh_hsl/app.c index 856bef3c3ef..7f130061837 100644 --- a/app/bluetooth/example/soc_btmesh_hsl/app.c +++ b/app/bluetooth/example/soc_btmesh_hsl/app.c @@ -142,7 +142,7 @@ static void set_device_name(bd_addr *addr) result); } // Show device name on the LCD - lcd_print(name, BTMESH_WSTK_LCD_ROW_NAME); + lcd_print(name, SL_BTMESH_WSTK_LCD_ROW_NAME_CFG_VAL); } /***************************************************************************//** @@ -192,7 +192,7 @@ static void handle_boot_event(void) sc = sl_btmesh_node_init(); if (sc) { snprintf(buf, BOOT_ERR_MSG_BUF_LEN, "init failed (0x%lx)", sc); - lcd_print(buf, BTMESH_WSTK_LCD_ROW_STATUS); + lcd_print(buf, SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log("Initialization failed (0x%x)\r\n", sc); } } @@ -212,14 +212,14 @@ static void handle_le_connection_events(sl_bt_msg_t *evt) switch (SL_BT_MSG_ID(evt->header)) { case sl_bt_evt_connection_opened_id: num_connections++; - lcd_print("connected", BTMESH_WSTK_LCD_ROW_CONNECTION); + lcd_print("connected", SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL); app_log("Connected\r\n"); break; case sl_bt_evt_connection_closed_id: if (num_connections > 0) { if (--num_connections == 0) { - lcd_print("", BTMESH_WSTK_LCD_ROW_CONNECTION); + lcd_print("", SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL); app_log("Disconnected\r\n"); } } @@ -352,8 +352,8 @@ SL_WEAK void sl_btmesh_hsl_saturation_cb(uint16_t saturation) void sl_btmesh_factory_reset_on_node_reset(void) { app_show_btmesh_node_reset(); - sl_bt_nvm_erase(LIGHTING_SERVER_PS_KEY); - sl_bt_nvm_erase(HSL_SERVER_PS_KEY); - sl_bt_nvm_erase(LC_SERVER_PS_KEY); - sl_bt_nvm_erase(LC_SERVER_PROPERTY_PS_KEY); + sl_bt_nvm_erase(SL_BTMESH_LIGHTING_SERVER_PS_KEY_CFG_VAL); + sl_bt_nvm_erase(SL_BTMESH_HSL_SERVER_PS_KEY_CFG_VAL); + sl_bt_nvm_erase(SL_BTMESH_LC_SERVER_PS_KEY_CFG_VAL); + sl_bt_nvm_erase(SL_BTMESH_LC_SERVER_PROPERTY_PS_KEY_CFG_VAL); } diff --git a/app/bluetooth/example/soc_btmesh_hsl/app_led.c b/app/bluetooth/example/soc_btmesh_hsl/app_led.c index 97002716dfd..6ce6b7f2ace 100644 --- a/app/bluetooth/example/soc_btmesh_hsl/app_led.c +++ b/app/bluetooth/example/soc_btmesh_hsl/app_led.c @@ -45,7 +45,7 @@ void app_led_set_level(uint16_t level) { uint16_t pwm_duty_cycle = (uint16_t)((uint32_t)level * PWM_MAX_DUTY_CYCLE - / LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS); + / SL_BTMESH_LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS_CFG_VAL); if (pwm_duty_cycle > PWM_MAX_DUTY_CYCLE) { pwm_duty_cycle = PWM_MAX_DUTY_CYCLE; @@ -83,7 +83,7 @@ void app_led_set_saturation(uint16_t saturation) ******************************************************************************/ uint16_t app_led_get_max(void) { - return LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS; + return SL_BTMESH_LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS_CFG_VAL; } /******************************************************************************* diff --git a/app/bluetooth/example/soc_btmesh_hsl/app_led_rgb.c b/app/bluetooth/example/soc_btmesh_hsl/app_led_rgb.c index 1a95ed0b4ab..2aebfb341b9 100644 --- a/app/bluetooth/example/soc_btmesh_hsl/app_led_rgb.c +++ b/app/bluetooth/example/soc_btmesh_hsl/app_led_rgb.c @@ -80,7 +80,7 @@ void app_led_set_saturation(uint16_t saturation) ******************************************************************************/ uint16_t app_led_get_max(void) { - return LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS; + return SL_BTMESH_LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS_CFG_VAL; } /******************************************************************************* diff --git a/app/bluetooth/example/soc_btmesh_hsl/app_out_lcd.c b/app/bluetooth/example/soc_btmesh_hsl/app_out_lcd.c index 42137e5735a..b18db687b8b 100644 --- a/app/bluetooth/example/soc_btmesh_hsl/app_out_lcd.c +++ b/app/bluetooth/example/soc_btmesh_hsl/app_out_lcd.c @@ -51,7 +51,7 @@ void sl_btmesh_friend_on_friendship_established(uint16_t netkey_index, netkey_index, lpn_address); sl_status_t status = sl_btmesh_LCD_write("FRIEND", - BTMESH_WSTK_LCD_ROW_FRIEND); + SL_BTMESH_WSTK_LCD_ROW_FRIEND_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)netkey_index; (void)lpn_address; @@ -75,7 +75,7 @@ void sl_btmesh_friend_on_friendship_terminated(uint16_t netkey_index, lpn_address, reason); sl_status_t status = sl_btmesh_LCD_write("NO LPN", - BTMESH_WSTK_LCD_ROW_FRIEND); + SL_BTMESH_WSTK_LCD_ROW_FRIEND_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)netkey_index; (void)lpn_address; @@ -88,7 +88,7 @@ void sl_btmesh_friend_on_friendship_terminated(uint16_t netkey_index, /******************************************************************************* * Called when the UI shall be updated with the changed HSL Model state during * a transition. The rate of this callback can be controlled by changing the - * HSL_SERVER_HUE_UI_UPDATE_PERIOD macro. + * SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL macro. * * @param[in] hue Hue value. ******************************************************************************/ @@ -101,14 +101,14 @@ void sl_btmesh_hsl_hue_on_ui_update(uint16_t hue) app_log("BT mesh HSL Hue: %4udeg\r\n", hue_degree); snprintf(tmp_str, LCD_ROW_LEN, "Hue: %4udeg", hue_degree); sl_status_t status = sl_btmesh_LCD_write(tmp_str, - BTMESH_WSTK_LCD_ROW_HUE); + SL_BTMESH_WSTK_LCD_ROW_HUE_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } /******************************************************************************* * Called when the UI shall be updated with the changed HSL Model state during * a transition. The rate of this callback can be controlled by changing the - * HSL_SERVER_SATURATION_UI_UPDATE_PERIOD macro. + * SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL macro. * * @param[in] saturation Saturation value. ******************************************************************************/ @@ -121,7 +121,7 @@ void sl_btmesh_hsl_saturation_on_ui_update(uint16_t saturation) app_log("BT mesh HSL Saturation: %4u%%\r\n", saturation_percent); snprintf(tmp_str, LCD_ROW_LEN, "Saturation: %4u%%", saturation_percent); sl_status_t status = sl_btmesh_LCD_write(tmp_str, - BTMESH_WSTK_LCD_ROW_SATURATION); + SL_BTMESH_WSTK_LCD_ROW_SATURATION_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -131,7 +131,7 @@ void sl_btmesh_hsl_saturation_on_ui_update(uint16_t saturation) /******************************************************************************* * Called when the UI shall be updated with the changed state of * lightning server during a transition. The rate of this callback can be - * controlled by changing the LIGHTING_SERVER_UI_UPDATE_PERIOD macro. + * controlled by changing the SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL macro. * * @param[in] lightness_level lightness level (0x0001 - FFFE) ******************************************************************************/ @@ -144,7 +144,7 @@ void sl_btmesh_lighting_server_on_ui_update(uint16_t lightness_level) app_log("BT mesh Lightness: %5u%%\r\n", lightness_percent); snprintf(tmp_str, LCD_ROW_LEN, "Lightness: %5u%%", lightness_percent); sl_status_t status = sl_btmesh_LCD_write(tmp_str, - BTMESH_WSTK_LCD_ROW_LIGHTNESS); + SL_BTMESH_WSTK_LCD_ROW_LIGHTNESS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -170,7 +170,7 @@ void sl_btmesh_on_provision_init_status(bool provisioned, app_log("BT mesh node is unprovisioned, " "started unprovisioned beaconing...\r\n"); sl_status_t status = sl_btmesh_LCD_write("unprovisioned", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } } @@ -185,7 +185,7 @@ void app_show_btmesh_node_provisioning_started(uint16_t result) app_log("BT mesh node provisioning is started (result: 0x%04x)\r\n", result); sl_status_t status = sl_btmesh_LCD_write("provisioning...", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)result; } @@ -205,7 +205,7 @@ void app_show_btmesh_node_provisioned(uint16_t address, address, iv_index); sl_status_t status = sl_btmesh_LCD_write("provisioned", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)address; (void)iv_index; @@ -220,7 +220,7 @@ void sl_btmesh_on_node_provisioning_failed(uint16_t result) { app_log("BT mesh node provisioning failed (result: 0x%04x)\r\n", result); sl_status_t status = sl_btmesh_LCD_write("prov failed...", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)result; } @@ -235,7 +235,7 @@ void app_show_btmesh_node_reset(void) { app_log("Node reset\r\n"); sl_status_t status = sl_btmesh_LCD_write("Node reset", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -246,6 +246,6 @@ void sl_btmesh_factory_reset_on_full_reset(void) { app_log("Factory reset\r\n"); sl_status_t status = sl_btmesh_LCD_write("Factory reset", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } diff --git a/app/bluetooth/example/soc_btmesh_hsl/app_out_log.c b/app/bluetooth/example/soc_btmesh_hsl/app_out_log.c index 45f01629685..969bff27e50 100644 --- a/app/bluetooth/example/soc_btmesh_hsl/app_out_log.c +++ b/app/bluetooth/example/soc_btmesh_hsl/app_out_log.c @@ -82,7 +82,7 @@ void sl_btmesh_friend_on_friendship_terminated(uint16_t netkey_index, /******************************************************************************* * Called when the UI shall be updated with the changed HSL Model state during * a transition. The rate of this callback can be controlled by changing the - * HSL_SERVER_HUE_UI_UPDATE_PERIOD macro. + * SL_BTMESH_HSL_SERVER_HUE_UI_UPDATE_PERIOD_CFG_VAL macro. * * @param[in] hue Hue value. ******************************************************************************/ @@ -95,7 +95,7 @@ void sl_btmesh_hsl_hue_on_ui_update(uint16_t hue) /******************************************************************************* * Called when the UI shall be updated with the changed HSL Model state during * a transition. The rate of this callback can be controlled by changing the - * HSL_SERVER_SATURATION_UI_UPDATE_PERIOD macro. + * SL_BTMESH_HSL_SERVER_SATURATION_UI_UPDATE_PERIOD_CFG_VAL macro. * * @param[in] saturation Saturation value. ******************************************************************************/ @@ -112,7 +112,7 @@ void sl_btmesh_hsl_saturation_on_ui_update(uint16_t saturation) /******************************************************************************* * Called when the UI shall be updated with the changed state of * lightning server during a transition. The rate of this callback can be - * controlled by changing the LIGHTING_SERVER_UI_UPDATE_PERIOD macro. + * controlled by changing the SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL macro. * * @param[in] lightness_level lightness level (0x0001 - FFFE) * diff --git a/app/bluetooth/example/soc_btmesh_hsl/dcd_config.btmeshconf b/app/bluetooth/example/soc_btmesh_hsl/dcd_config.btmeshconf index f16e80219cc..3e5122bc5ae 100644 --- a/app/bluetooth/example/soc_btmesh_hsl/dcd_config.btmeshconf +++ b/app/bluetooth/example/soc_btmesh_hsl/dcd_config.btmeshconf @@ -2,7 +2,7 @@ "composition_data": { "cid": "0x02ff", "pid": "0x0002", - "vid": "0x0220", + "vid": "0x0221", "elements": [ { "name": "Main", diff --git a/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_brd4166a.slcp b/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_brd4166a.slcp index b1450b42ef0..acecbc001ae 100644 --- a/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_brd4166a.slcp +++ b/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_brd4166a.slcp @@ -85,7 +85,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_hsl/readme.html + - path: ../../documentation/example/soc_btmesh_hsl/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -112,23 +112,23 @@ other_file: configuration: - name: APP_LOG_LEVEL value: "APP_LOG_LEVEL_INFO" - - name: LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE + - name: SL_BTMESH_LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE_CFG_VAL value: "1" - - name: LC_SERVER_TIME_RUN_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_RUN_ON_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_TIME_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_LIGHTNESS_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_ON_DEFAULT_CFG_VAL value: "65535" - - name: LC_SERVER_LIGHTNESS_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_PROLONG_DEFAULT_CFG_VAL value: "32767" - - name: LC_SERVER_LIGHTNESS_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_STANDBY_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT_CFG_VAL value: "1000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT_CFG_VAL value: "20" - name: SL_BOARD_ENABLE_DISPLAY value: "1" @@ -169,5 +169,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_display.slcp b/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_display.slcp index 3032d3e265f..5c281c0a4c5 100644 --- a/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_display.slcp +++ b/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_display.slcp @@ -79,7 +79,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_hsl/readme.html + - path: ../../documentation/example/soc_btmesh_hsl/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -106,23 +106,23 @@ other_file: configuration: - name: APP_LOG_LEVEL value: "APP_LOG_LEVEL_INFO" - - name: LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE + - name: SL_BTMESH_LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE_CFG_VAL value: "1" - - name: LC_SERVER_TIME_RUN_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_RUN_ON_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_TIME_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_LIGHTNESS_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_ON_DEFAULT_CFG_VAL value: "65535" - - name: LC_SERVER_LIGHTNESS_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_PROLONG_DEFAULT_CFG_VAL value: "32767" - - name: LC_SERVER_LIGHTNESS_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_STANDBY_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT_CFG_VAL value: "1000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT_CFG_VAL value: "20" - name: SL_BOARD_ENABLE_DISPLAY value: "1" @@ -164,5 +164,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_log.slcp b/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_log.slcp index 8e2afad4849..29e4d96e92b 100644 --- a/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_log.slcp +++ b/app/bluetooth/example/soc_btmesh_hsl/soc_btmesh_hsl_log.slcp @@ -78,7 +78,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_hsl/readme.html + - path: ../../documentation/example/soc_btmesh_hsl/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -105,23 +105,23 @@ other_file: configuration: - name: APP_LOG_LEVEL value: "APP_LOG_LEVEL_INFO" - - name: LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE + - name: SL_BTMESH_LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE_CFG_VAL value: "1" - - name: LC_SERVER_TIME_RUN_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_RUN_ON_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_TIME_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_LIGHTNESS_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_ON_DEFAULT_CFG_VAL value: "65535" - - name: LC_SERVER_LIGHTNESS_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_PROLONG_DEFAULT_CFG_VAL value: "32767" - - name: LC_SERVER_LIGHTNESS_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_STANDBY_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT_CFG_VAL value: "1000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT_CFG_VAL value: "20" - name: SL_BOARD_ENABLE_DISPLAY value: "1" @@ -163,5 +163,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_light/app.c b/app/bluetooth/example/soc_btmesh_light/app.c index 4218ae49a59..50451db3b54 100644 --- a/app/bluetooth/example/soc_btmesh_light/app.c +++ b/app/bluetooth/example/soc_btmesh_light/app.c @@ -155,7 +155,7 @@ static void set_device_name(bd_addr *addr) result); } // Show device name on the LCD - lcd_print(name, BTMESH_WSTK_LCD_ROW_NAME); + lcd_print(name, SL_BTMESH_WSTK_LCD_ROW_NAME_CFG_VAL); } /***************************************************************************//** @@ -205,7 +205,7 @@ static void handle_boot_event(void) sc = sl_btmesh_node_init(); if (sc) { snprintf(buf, BOOT_ERR_MSG_BUF_LEN, "init failed (0x%lx)", sc); - lcd_print(buf, BTMESH_WSTK_LCD_ROW_STATUS); + lcd_print(buf, SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log("Initialization failed (0x%x)\r\n", sc); } } @@ -225,14 +225,14 @@ static void handle_le_connection_events(sl_bt_msg_t *evt) switch (SL_BT_MSG_ID(evt->header)) { case sl_bt_evt_connection_opened_id: num_connections++; - lcd_print("connected", BTMESH_WSTK_LCD_ROW_CONNECTION); + lcd_print("connected", SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL); app_log("Connected\r\n"); break; case sl_bt_evt_connection_closed_id: if (num_connections > 0) { if (--num_connections == 0) { - lcd_print("", BTMESH_WSTK_LCD_ROW_CONNECTION); + lcd_print("", SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL); app_log("Disconnected\r\n"); } } @@ -360,8 +360,8 @@ void sl_btmesh_lighting_color_pwm_cb(uint16_t color) void sl_btmesh_factory_reset_on_node_reset(void) { app_show_btmesh_node_reset(); - sl_bt_nvm_erase(LIGHTING_SERVER_PS_KEY); - sl_bt_nvm_erase(CTL_SERVER_PS_KEY); - sl_bt_nvm_erase(LC_SERVER_PS_KEY); - sl_bt_nvm_erase(LC_SERVER_PROPERTY_PS_KEY); + sl_bt_nvm_erase(SL_BTMESH_LIGHTING_SERVER_PS_KEY_CFG_VAL); + sl_bt_nvm_erase(SL_BTMESH_CTL_SERVER_PS_KEY_CFG_VAL); + sl_bt_nvm_erase(SL_BTMESH_LC_SERVER_PS_KEY_CFG_VAL); + sl_bt_nvm_erase(SL_BTMESH_LC_SERVER_PROPERTY_PS_KEY_CFG_VAL); } diff --git a/app/bluetooth/example/soc_btmesh_light/app_led.c b/app/bluetooth/example/soc_btmesh_light/app_led.c index 8d34fbbf910..4bdcee69543 100644 --- a/app/bluetooth/example/soc_btmesh_light/app_led.c +++ b/app/bluetooth/example/soc_btmesh_light/app_led.c @@ -58,7 +58,7 @@ void app_led_set_level(uint16_t level) { uint16_t pwm_duty_cycle = (uint16_t)((uint32_t)level * PWM_MAX_DUTY_CYCLE - / LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS); + / SL_BTMESH_LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS_CFG_VAL); if (pwm_duty_cycle > PWM_MAX_DUTY_CYCLE) { pwm_duty_cycle = PWM_MAX_DUTY_CYCLE; @@ -85,7 +85,7 @@ void app_led_set_color(uint16_t color) ******************************************************************************/ uint16_t app_led_get_max(void) { - return LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS; + return SL_BTMESH_LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS_CFG_VAL; } /******************************************************************************* diff --git a/app/bluetooth/example/soc_btmesh_light/app_led_rgb.c b/app/bluetooth/example/soc_btmesh_light/app_led_rgb.c index 4010bc8ca74..e6205c0dbfc 100644 --- a/app/bluetooth/example/soc_btmesh_light/app_led_rgb.c +++ b/app/bluetooth/example/soc_btmesh_light/app_led_rgb.c @@ -80,7 +80,7 @@ void app_led_set_color(uint16_t color) ******************************************************************************/ uint16_t app_led_get_max(void) { - return LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS; + return SL_BTMESH_LIGHTING_SERVER_PWM_MAXIMUM_BRIGHTNESS_CFG_VAL; } /******************************************************************************* diff --git a/app/bluetooth/example/soc_btmesh_light/app_out_lcd.c b/app/bluetooth/example/soc_btmesh_light/app_out_lcd.c index 6d89b8c815a..b2ac25a612f 100644 --- a/app/bluetooth/example/soc_btmesh_light/app_out_lcd.c +++ b/app/bluetooth/example/soc_btmesh_light/app_out_lcd.c @@ -62,7 +62,7 @@ void sl_btmesh_friend_on_friendship_established(uint16_t netkey_index, netkey_index, lpn_address); sl_status_t status = sl_btmesh_LCD_write("FRIEND", - BTMESH_WSTK_LCD_ROW_FRIEND); + SL_BTMESH_WSTK_LCD_ROW_FRIEND_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)netkey_index; (void)lpn_address; @@ -86,7 +86,7 @@ void sl_btmesh_friend_on_friendship_terminated(uint16_t netkey_index, lpn_address, reason); sl_status_t status = sl_btmesh_LCD_write("NO LPN", - BTMESH_WSTK_LCD_ROW_FRIEND); + SL_BTMESH_WSTK_LCD_ROW_FRIEND_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)netkey_index; (void)lpn_address; @@ -99,7 +99,7 @@ void sl_btmesh_friend_on_friendship_terminated(uint16_t netkey_index, /******************************************************************************* * Called when the UI shall be updated with the changed CTL Model state during * a transition. The rate of this callback can be controlled by changing the - * CTL_SERVER_UI_UPDATE_PERIOD macro. + * SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL macro. * * @param[in] temperature Temperature of color. * @param[in] deltauv Delta UV value. @@ -118,12 +118,12 @@ void sl_btmesh_ctl_on_ui_update(uint16_t temperature, snprintf(tmp_str, LCD_ROW_LEN, "ColorTemp: %5uK", temperature); app_log("BT mesh CTL Color temperature: %5uK\r\n", temperature); sl_status_t status = sl_btmesh_LCD_write(tmp_str, - BTMESH_WSTK_LCD_ROW_TEMPERATURE); + SL_BTMESH_WSTK_LCD_ROW_TEMPERATURE_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); snprintf(tmp_str, LCD_ROW_LEN, "Delta UV: %6s ", deltauv_str); app_log("BT mesh CTL Delta UV: %6s\r\n", deltauv_str); - status = sl_btmesh_LCD_write(tmp_str, BTMESH_WSTK_LCD_ROW_DELTAUV); + status = sl_btmesh_LCD_write(tmp_str, SL_BTMESH_WSTK_LCD_ROW_DELTAUV_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -133,7 +133,7 @@ void sl_btmesh_ctl_on_ui_update(uint16_t temperature, /******************************************************************************* * Called when the UI shall be updated with the changed state of * lightning server during a transition. The rate of this callback can be - * controlled by changing the LIGHTING_SERVER_UI_UPDATE_PERIOD macro. + * controlled by changing the SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL macro. * * @param[in] lightness_level lightness level (0x0001 - FFFE) ******************************************************************************/ @@ -146,7 +146,7 @@ void sl_btmesh_lighting_server_on_ui_update(uint16_t lightness_level) app_log("BT mesh Lightness: %5u%%\r\n", lightness_percent); snprintf(tmp_str, LCD_ROW_LEN, "Lightness: %5u%%", lightness_percent); sl_status_t status = sl_btmesh_LCD_write(tmp_str, - BTMESH_WSTK_LCD_ROW_LIGHTNESS); + SL_BTMESH_WSTK_LCD_ROW_LIGHTNESS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -172,7 +172,7 @@ void sl_btmesh_on_provision_init_status(bool provisioned, app_log("BT mesh node is unprovisioned, " "started unprovisioned beaconing...\r\n"); sl_status_t status = sl_btmesh_LCD_write("unprovisioned", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } } @@ -187,7 +187,7 @@ void app_show_btmesh_node_provisioning_started(uint16_t result) app_log("BT mesh node provisioning is started (result: 0x%04x)\r\n", result); sl_status_t status = sl_btmesh_LCD_write("provisioning...", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)result; } @@ -207,7 +207,7 @@ void app_show_btmesh_node_provisioned(uint16_t address, address, iv_index); sl_status_t status = sl_btmesh_LCD_write("provisioned", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)address; (void)iv_index; @@ -222,7 +222,7 @@ void sl_btmesh_on_node_provisioning_failed(uint16_t result) { app_log("BT mesh node provisioning failed (result: 0x%04x)\r\n", result); sl_status_t status = sl_btmesh_LCD_write("prov failed...", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)result; } @@ -237,7 +237,7 @@ void app_show_btmesh_node_reset(void) { app_log("Node reset\r\n"); sl_status_t status = sl_btmesh_LCD_write("Node reset", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -248,6 +248,6 @@ void sl_btmesh_factory_reset_on_full_reset(void) { app_log("Factory reset\r\n"); sl_status_t status = sl_btmesh_LCD_write("Factory reset", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } diff --git a/app/bluetooth/example/soc_btmesh_light/app_out_log.c b/app/bluetooth/example/soc_btmesh_light/app_out_log.c index 49c20d6d09f..a47e9936f28 100644 --- a/app/bluetooth/example/soc_btmesh_light/app_out_log.c +++ b/app/bluetooth/example/soc_btmesh_light/app_out_log.c @@ -95,7 +95,7 @@ void sl_btmesh_friend_on_friendship_terminated(uint16_t netkey_index, /******************************************************************************* * Called when the UI shall be updated with the changed CTL Model state during * a transition. The rate of this callback can be controlled by changing the - * CTL_SERVER_UI_UPDATE_PERIOD macro. + * SL_BTMESH_CTL_SERVER_UI_UPDATE_PERIOD_CFG_VAL macro. * * @param[in] temperature Temperature of color. * @param[in] deltauv Delta UV value. @@ -120,7 +120,7 @@ void sl_btmesh_ctl_on_ui_update(uint16_t temperature, /******************************************************************************* * Called when the UI shall be updated with the changed state of * lightning server during a transition. The rate of this callback can be - * controlled by changing the LIGHTING_SERVER_UI_UPDATE_PERIOD macro. + * controlled by changing the SL_BTMESH_LIGHTING_SERVER_UI_UPDATE_PERIOD_CFG_VAL macro. * * @param[in] lightness_level lightness level (0x0001 - FFFE) * diff --git a/app/bluetooth/example/soc_btmesh_light/dcd_config.btmeshconf b/app/bluetooth/example/soc_btmesh_light/dcd_config.btmeshconf index 163f0f9361d..ec759d0fbd7 100644 --- a/app/bluetooth/example/soc_btmesh_light/dcd_config.btmeshconf +++ b/app/bluetooth/example/soc_btmesh_light/dcd_config.btmeshconf @@ -2,7 +2,7 @@ "composition_data": { "cid": "0x02ff", "pid": "0x0003", - "vid": "0x0220", + "vid": "0x0221", "elements": [ { "name": "Main", diff --git a/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_brd4166a.slcp b/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_brd4166a.slcp index b01c833436e..ff4bd6bdac6 100644 --- a/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_brd4166a.slcp +++ b/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_brd4166a.slcp @@ -83,7 +83,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_light/readme.html + - path: ../../documentation/example/soc_btmesh_light/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -110,23 +110,23 @@ other_file: configuration: - name: APP_LOG_LEVEL value: "APP_LOG_LEVEL_INFO" - - name: LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE + - name: SL_BTMESH_LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE_CFG_VAL value: "1" - - name: LC_SERVER_TIME_RUN_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_RUN_ON_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_TIME_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_LIGHTNESS_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_ON_DEFAULT_CFG_VAL value: "65535" - - name: LC_SERVER_LIGHTNESS_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_PROLONG_DEFAULT_CFG_VAL value: "32767" - - name: LC_SERVER_LIGHTNESS_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_STANDBY_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT_CFG_VAL value: "1000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT_CFG_VAL value: "20" - name: SL_BOARD_ENABLE_DISPLAY value: "1" @@ -167,5 +167,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_display.slcp b/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_display.slcp index fbd77c5b5cc..8fbcac2c14f 100644 --- a/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_display.slcp +++ b/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_display.slcp @@ -79,7 +79,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_light/readme.html + - path: ../../documentation/example/soc_btmesh_light/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -106,23 +106,23 @@ other_file: configuration: - name: APP_LOG_LEVEL value: "APP_LOG_LEVEL_INFO" - - name: LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE + - name: SL_BTMESH_LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE_CFG_VAL value: "1" - - name: LC_SERVER_TIME_RUN_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_RUN_ON_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_TIME_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_LIGHTNESS_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_ON_DEFAULT_CFG_VAL value: "65535" - - name: LC_SERVER_LIGHTNESS_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_PROLONG_DEFAULT_CFG_VAL value: "32767" - - name: LC_SERVER_LIGHTNESS_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_STANDBY_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT_CFG_VAL value: "1000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT_CFG_VAL value: "20" - name: SL_BOARD_ENABLE_DISPLAY value: "1" @@ -164,5 +164,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_log.slcp b/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_log.slcp index f564e3d6610..7a98643aa56 100644 --- a/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_log.slcp +++ b/app/bluetooth/example/soc_btmesh_light/soc_btmesh_light_log.slcp @@ -78,7 +78,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_light/readme.html + - path: ../../documentation/example/soc_btmesh_light/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -105,23 +105,23 @@ other_file: configuration: - name: APP_LOG_LEVEL value: "APP_LOG_LEVEL_INFO" - - name: LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE + - name: SL_BTMESH_LC_SERVER_PROPERTY_STATE_DEFAULT_ENABLE_CFG_VAL value: "1" - - name: LC_SERVER_TIME_RUN_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_RUN_ON_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_TIME_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_TIME_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_LIGHTNESS_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_ON_DEFAULT_CFG_VAL value: "65535" - - name: LC_SERVER_LIGHTNESS_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_PROLONG_DEFAULT_CFG_VAL value: "32767" - - name: LC_SERVER_LIGHTNESS_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_LIGHTNESS_STANDBY_DEFAULT_CFG_VAL value: "2000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_ON_DEFAULT_CFG_VAL value: "1000" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_PROLONG_DEFAULT_CFG_VAL value: "500" - - name: LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT + - name: SL_BTMESH_LC_SERVER_AMBIENT_LUX_LEVEL_STANDBY_DEFAULT_CFG_VAL value: "20" - name: SL_BOARD_ENABLE_DISPLAY value: "1" @@ -163,5 +163,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_sensor_client/app.c b/app/bluetooth/example/soc_btmesh_sensor_client/app.c index e1e6e1d2874..5bd35bf74ce 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_client/app.c +++ b/app/bluetooth/example/soc_btmesh_sensor_client/app.c @@ -223,7 +223,7 @@ static void set_device_name(bd_addr *addr) } // Show device name on the LCD - lcd_print(name, BTMESH_WSTK_LCD_ROW_NAME); + lcd_print(name, SL_BTMESH_WSTK_LCD_ROW_NAME_CFG_VAL); } /***************************************************************************//** @@ -277,7 +277,7 @@ static void handle_boot_event(void) sc = sl_btmesh_node_init(); if (sc != SL_STATUS_OK) { snprintf(buf, BOOT_ERR_MSG_BUF_LEN, "init failed (0x%lx)", sc); - lcd_print(buf, BTMESH_WSTK_LCD_ROW_STATUS); + lcd_print(buf, SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); } } } @@ -350,14 +350,14 @@ static void handle_le_connection_events(sl_bt_msg_t *evt) switch (SL_BT_MSG_ID(evt->header)) { case sl_bt_evt_connection_opened_id: num_connections++; - lcd_print("connected", BTMESH_WSTK_LCD_ROW_CONNECTION); + lcd_print("connected", SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL); app_log("Connected\r\n"); break; case sl_bt_evt_connection_closed_id: if (num_connections > 0) { if (--num_connections == 0) { - lcd_print("", BTMESH_WSTK_LCD_ROW_CONNECTION); + lcd_print("", SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL); app_log("Disconnected\r\n"); } } diff --git a/app/bluetooth/example/soc_btmesh_sensor_client/app_out_lcd.c b/app/bluetooth/example/soc_btmesh_sensor_client/app_out_lcd.c index fe3d9715bbb..046c15e7338 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_client/app_out_lcd.c +++ b/app/bluetooth/example/soc_btmesh_sensor_client/app_out_lcd.c @@ -62,7 +62,7 @@ void sl_btmesh_sensor_client_on_discovery_started(uint16_t property_id) app_log("BT mesh Sensor Device discovery is started. (property_id: 0x%04x)\r\n", property_id); // Clear the previous sensor measurement values - for (uint8_t row = BTMESH_WSTK_LCD_ROW_SENSOR_DATA; row <= LCD_ROW_MAX; row++) { + for (uint8_t row = SL_BTMESH_WSTK_LCD_ROW_SENSOR_DATA_CFG_VAL; row <= LCD_ROW_MAX; row++) { sl_status_t lcd_status = sl_btmesh_LCD_write("", row); app_log_status_level_f(APP_LOG_LEVEL_ERROR, lcd_status, "LCD write failed"); } @@ -124,7 +124,7 @@ void sl_btmesh_sensor_client_on_new_temperature_data(uint8_t sensor_idx, } sl_status_t lcd_status = sl_btmesh_LCD_write(tmp_str, - BTMESH_WSTK_LCD_ROW_SENSOR_DATA + sensor_idx); + SL_BTMESH_WSTK_LCD_ROW_SENSOR_DATA_CFG_VAL + sensor_idx); app_log_status_level_f(APP_LOG_LEVEL_ERROR, lcd_status, "LCD write failed"); } @@ -161,7 +161,7 @@ void sl_btmesh_sensor_client_on_new_people_count_data(uint8_t sensor_idx, } sl_status_t lcd_status = sl_btmesh_LCD_write(tmp_str, - BTMESH_WSTK_LCD_ROW_SENSOR_DATA + sensor_idx); + SL_BTMESH_WSTK_LCD_ROW_SENSOR_DATA_CFG_VAL + sensor_idx); app_log_status_level_f(APP_LOG_LEVEL_ERROR, lcd_status, "LCD write failed"); } @@ -204,7 +204,7 @@ void sl_btmesh_sensor_client_on_new_illuminance_data(uint8_t sensor_idx, } sl_status_t lcd_status = sl_btmesh_LCD_write(tmp_str, - BTMESH_WSTK_LCD_ROW_SENSOR_DATA + sensor_idx); + SL_BTMESH_WSTK_LCD_ROW_SENSOR_DATA_CFG_VAL + sensor_idx); app_log_status_level_f(APP_LOG_LEVEL_ERROR, lcd_status, "LCD write failed"); } @@ -224,7 +224,7 @@ void sl_btmesh_on_provision_init_status(bool provisioned, } else { app_log("BT mesh node is unprovisioned, started unprovisioned beaconing...\r\n"); sl_status_t lcd_status = sl_btmesh_LCD_write("unprovisioned", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, lcd_status, "LCD write failed"); } } @@ -237,7 +237,7 @@ void app_show_btmesh_node_provisioning_started(uint16_t result) { app_log("BT mesh node provisioning is started (result: 0x%04x)\r\n", result); sl_status_t lcd_status = sl_btmesh_LCD_write("provisioning...", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, lcd_status, "LCD write failed"); (void)result; } @@ -253,7 +253,7 @@ void app_show_btmesh_node_provisioned(uint16_t address, address, iv_index); sl_status_t lcd_status = sl_btmesh_LCD_write("provisioned", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, lcd_status, "LCD write failed"); (void)address; (void)iv_index; @@ -267,7 +267,7 @@ void sl_btmesh_on_node_provisioning_failed(uint16_t result) { app_log("BT mesh node provisioning failed (result: 0x%04x)\r\n", result); sl_status_t lcd_status = sl_btmesh_LCD_write("prov failed...", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, lcd_status, "LCD write failed"); (void)result; } @@ -282,7 +282,7 @@ void sl_btmesh_factory_reset_on_full_reset(void) { app_log("Factory reset\r\n"); sl_status_t status = sl_btmesh_LCD_write("Factory reset", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -293,6 +293,6 @@ void sl_btmesh_factory_reset_on_node_reset(void) { app_log("Node reset\r\n"); sl_status_t status = sl_btmesh_LCD_write("Node reset", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } diff --git a/app/bluetooth/example/soc_btmesh_sensor_client/dcd_config.btmeshconf b/app/bluetooth/example/soc_btmesh_sensor_client/dcd_config.btmeshconf index 9645ca0fb08..bef3b1fdf1a 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_client/dcd_config.btmeshconf +++ b/app/bluetooth/example/soc_btmesh_sensor_client/dcd_config.btmeshconf @@ -2,7 +2,7 @@ "composition_data": { "cid": "0x02ff", "pid": "0x0004", - "vid": "0x0220", + "vid": "0x0221", "elements": [ { "name": "Main", diff --git a/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_display.slcp b/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_display.slcp index 07576e8b90e..11f6f89f2f2 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_display.slcp +++ b/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_display.slcp @@ -67,7 +67,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_sensor_client/readme.html + - path: ../../documentation/example/soc_btmesh_sensor_client/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -155,5 +155,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_log.slcp b/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_log.slcp index 03cfcffbaaa..da040922490 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_log.slcp +++ b/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_log.slcp @@ -66,7 +66,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_sensor_client/readme.html + - path: ../../documentation/example/soc_btmesh_sensor_client/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -109,6 +109,8 @@ configuration: value: "0" condition: - psa_crypto + - name: SL_SIMPLE_BUTTON_ALLOW_LED_CONFLICT + value: "1" - name: SL_STACK_SIZE value: "0x1000" @@ -138,5 +140,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_log_single.slcp b/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_log_single.slcp index 04bb365b846..d408bf2ab80 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_log_single.slcp +++ b/app/bluetooth/example/soc_btmesh_sensor_client/soc_btmesh_sensor_client_log_single.slcp @@ -66,7 +66,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_sensor_client/readme.html + - path: ../../documentation/example/soc_btmesh_sensor_client/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -144,5 +144,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_sensor_server/app.c b/app/bluetooth/example/soc_btmesh_sensor_server/app.c index 259384aae5a..9ac7fffdda2 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_server/app.c +++ b/app/bluetooth/example/soc_btmesh_sensor_server/app.c @@ -209,7 +209,7 @@ static void set_device_name(bd_addr *addr) } // Show device name on the LCD - lcd_print(name, BTMESH_WSTK_LCD_ROW_NAME); + lcd_print(name, SL_BTMESH_WSTK_LCD_ROW_NAME_CFG_VAL); } /***************************************************************************//** @@ -263,7 +263,7 @@ static void handle_boot_event(void) sc = sl_btmesh_node_init(); if (sc != SL_STATUS_OK) { snprintf(buf, sizeof(buf), "init failed (0x%lx)", sc); - lcd_print(buf, BTMESH_WSTK_LCD_ROW_STATUS); + lcd_print(buf, SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); } } } @@ -299,14 +299,14 @@ static void handle_le_connection_events(sl_bt_msg_t *evt) switch (SL_BT_MSG_ID(evt->header)) { case sl_bt_evt_connection_opened_id: num_connections++; - lcd_print("connected", BTMESH_WSTK_LCD_ROW_CONNECTION); + lcd_print("connected", SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL); app_log("Connected\r\n"); break; case sl_bt_evt_connection_closed_id: if (num_connections > 0) { if (--num_connections == 0) { - lcd_print("", BTMESH_WSTK_LCD_ROW_CONNECTION); + lcd_print("", SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL); app_log("Disconnected\r\n"); } } diff --git a/app/bluetooth/example/soc_btmesh_sensor_server/app_out_lcd.c b/app/bluetooth/example/soc_btmesh_sensor_server/app_out_lcd.c index 9e15f3e65ac..1864aea35bb 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_server/app_out_lcd.c +++ b/app/bluetooth/example/soc_btmesh_sensor_server/app_out_lcd.c @@ -63,7 +63,7 @@ void sl_btmesh_factory_reset_on_full_reset(void) { app_log("Factory reset\r\n"); sl_status_t status = sl_btmesh_LCD_write("Factory reset", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -74,7 +74,7 @@ void sl_btmesh_factory_reset_on_node_reset(void) { app_log("Node reset\r\n"); sl_status_t status = sl_btmesh_LCD_write("Node reset", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -91,7 +91,7 @@ void sl_btmesh_sensor_server_on_temperature_measurement(temperature_8_t temperat == temperature) { app_log("Temperature: UNKNOWN\r\n"); status = sl_btmesh_LCD_write("Temperature: N/K ", - BTMESH_WSTK_LCD_ROW_TEMPERATURE); + SL_BTMESH_WSTK_LCD_ROW_TEMPERATURE_CFG_VAL); } else { char str[LCD_ROW_LEN]; app_log("Temperature: %3d.%1d °C\r\n", @@ -102,7 +102,7 @@ void sl_btmesh_sensor_server_on_temperature_measurement(temperature_8_t temperat "Temperature: %3d.%1d C", INT_TEMP(temperature), FRAC_TEMP(temperature)); - status = sl_btmesh_LCD_write(str, BTMESH_WSTK_LCD_ROW_TEMPERATURE); + status = sl_btmesh_LCD_write(str, SL_BTMESH_WSTK_LCD_ROW_TEMPERATURE_CFG_VAL); } app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -115,7 +115,7 @@ void sl_btmesh_sensor_server_on_light_measurement(illuminance_t light) if ((illuminance_t)SL_BTMESH_SENSOR_LIGHT_VALUE_IS_NOT_KNOWN == light) { app_log("Illuminance: UNKNOWN\r\n"); status = sl_btmesh_LCD_write("Illuminance: N/K", - BTMESH_WSTK_LCD_ROW_ILLUMINANCE); + SL_BTMESH_WSTK_LCD_ROW_ILLUMINANCE_CFG_VAL); } else { app_log("Illuminance: %4lu.%02lu lx\r\n", INT_ILLUM(light), @@ -127,7 +127,7 @@ void sl_btmesh_sensor_server_on_light_measurement(illuminance_t light) INT_ILLUM(light), FRAC_ILLUM(light)); app_log(str); - status = sl_btmesh_LCD_write(str, BTMESH_WSTK_LCD_ROW_ILLUMINANCE); + status = sl_btmesh_LCD_write(str, SL_BTMESH_WSTK_LCD_ROW_ILLUMINANCE_CFG_VAL); } app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -142,7 +142,7 @@ void sl_btmesh_sensor_server_on_people_count_measurement(count16_t people) == people) { app_log("People count: UNKNOWN\r\n"); status = sl_btmesh_LCD_write("People count: N/K", - BTMESH_WSTK_LCD_ROW_PEOPLE_COUNT); + SL_BTMESH_WSTK_LCD_ROW_PEOPLE_COUNT_CFG_VAL); } else { app_log("People count: %5u\r\n", people); char str[LCD_ROW_LEN]; @@ -150,7 +150,7 @@ void sl_btmesh_sensor_server_on_people_count_measurement(count16_t people) LCD_ROW_LEN, "People count: %5u", people); - status = sl_btmesh_LCD_write(str, BTMESH_WSTK_LCD_ROW_PEOPLE_COUNT); + status = sl_btmesh_LCD_write(str, SL_BTMESH_WSTK_LCD_ROW_PEOPLE_COUNT_CFG_VAL); } app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -170,7 +170,7 @@ void sl_btmesh_on_provision_init_status(bool provisioned, } else { app_log("BT mesh node is unprovisioned, started unprovisioned beaconing...\r\n"); sl_status_t status = sl_btmesh_LCD_write("unprovisioned", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } } @@ -182,7 +182,7 @@ void app_show_btmesh_node_provisioning_started(uint16_t result) { app_log("BT mesh node provisioning is started (result: 0x%04x)\r\n", result); sl_status_t status = sl_btmesh_LCD_write("provisioning...", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)result; } @@ -197,7 +197,7 @@ void app_show_btmesh_node_provisioned(uint16_t address, address, iv_index); sl_status_t status = sl_btmesh_LCD_write("provisioned", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)address; (void)iv_index; @@ -210,7 +210,7 @@ void sl_btmesh_on_node_provisioning_failed(uint16_t result) { app_log("BT mesh node provisioning failed (result: 0x%04x)\r\n", result); sl_status_t status = sl_btmesh_LCD_write("prov failed...", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); (void)result; } diff --git a/app/bluetooth/example/soc_btmesh_sensor_server/dcd_config.btmeshconf b/app/bluetooth/example/soc_btmesh_sensor_server/dcd_config.btmeshconf index 873468c89c8..2b799ae5330 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_server/dcd_config.btmeshconf +++ b/app/bluetooth/example/soc_btmesh_sensor_server/dcd_config.btmeshconf @@ -2,7 +2,7 @@ "composition_data": { "cid": "0x02ff", "pid": "0x0005", - "vid": "0x0220", + "vid": "0x0221", "elements": [ { "name": "Main", diff --git a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_display.slcp b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_display.slcp index a30dcd87384..9127f536b4d 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_display.slcp +++ b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_display.slcp @@ -73,7 +73,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_sensor_server/readme.html + - path: ../../documentation/example/soc_btmesh_sensor_server/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -168,5 +168,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_display.slcp b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_display.slcp index dde85416737..96d71e611c7 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_display.slcp +++ b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_display.slcp @@ -70,7 +70,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_sensor_server/readme.html + - path: ../../documentation/example/soc_btmesh_sensor_server/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -147,5 +147,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_log.slcp b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_log.slcp index 73a26b5a659..31ab25354c5 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_log.slcp +++ b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_log.slcp @@ -69,7 +69,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_sensor_server/readme.html + - path: ../../documentation/example/soc_btmesh_sensor_server/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -112,6 +112,8 @@ configuration: value: "0" condition: - psa_crypto + - name: SL_SIMPLE_BUTTON_ALLOW_LED_CONFLICT + value: "1" - name: SL_STACK_SIZE value: "0x1000" @@ -142,5 +144,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_log_single.slcp b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_log_single.slcp index 83c3e8dbd29..5d7a0732821 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_log_single.slcp +++ b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_mock_log_single.slcp @@ -68,7 +68,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_sensor_server/readme.html + - path: ../../documentation/example/soc_btmesh_sensor_server/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -147,5 +147,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbbg22a.slcp b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbbg22a.slcp index 31614defb4f..8a3c2c5449e 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbbg22a.slcp +++ b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbbg22a.slcp @@ -72,7 +72,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_sensor_server/readme.html + - path: ../../documentation/example/soc_btmesh_sensor_server/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -160,5 +160,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbbg22b.slcp b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbbg22b.slcp index eb3fe7cdb1b..712d344a5ad 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbbg22b.slcp +++ b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbbg22b.slcp @@ -72,7 +72,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_sensor_server/readme.html + - path: ../../documentation/example/soc_btmesh_sensor_server/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -158,5 +158,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbsense.slcp b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbsense.slcp index 3e9db6d664a..5d2485536de 100644 --- a/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbsense.slcp +++ b/app/bluetooth/example/soc_btmesh_sensor_server/soc_btmesh_sensor_server_tbsense.slcp @@ -73,7 +73,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_sensor_server/readme.html + - path: ../../documentation/example/soc_btmesh_sensor_server/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -153,5 +153,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_switch/app.c b/app/bluetooth/example/soc_btmesh_switch/app.c index d26849750df..a7181523099 100644 --- a/app/bluetooth/example/soc_btmesh_switch/app.c +++ b/app/bluetooth/example/soc_btmesh_switch/app.c @@ -215,7 +215,7 @@ static void set_device_name(bd_addr *addr) } // Show device name on the LCD - lcd_print(name, BTMESH_WSTK_LCD_ROW_NAME); + lcd_print(name, SL_BTMESH_WSTK_LCD_ROW_NAME_CFG_VAL); } /***************************************************************************//** @@ -269,7 +269,7 @@ static void handle_boot_event(void) sc = sl_btmesh_node_init(); if (sc) { snprintf(buf, BOOT_ERR_MSG_BUF_LEN, "init failed (0x%lx)", sc); - lcd_print(buf, BTMESH_WSTK_LCD_ROW_STATUS); + lcd_print(buf, SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); } } } @@ -288,14 +288,14 @@ static void handle_le_connection_events(sl_bt_msg_t *evt) switch (SL_BT_MSG_ID(evt->header)) { case sl_bt_evt_connection_opened_id: num_connections++; - lcd_print("connected", BTMESH_WSTK_LCD_ROW_CONNECTION); + lcd_print("connected", SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL); app_log("Connected\r\n"); break; case sl_bt_evt_connection_closed_id: if (num_connections > 0) { if (--num_connections == 0) { - lcd_print("", BTMESH_WSTK_LCD_ROW_CONNECTION); + lcd_print("", SL_BTMESH_WSTK_LCD_ROW_CONNECTION_CFG_VAL); app_log("Disconnected\r\n"); } } diff --git a/app/bluetooth/example/soc_btmesh_switch/app_out_lcd.c b/app/bluetooth/example/soc_btmesh_switch/app_out_lcd.c index 042f0fc09bd..2390896486e 100644 --- a/app/bluetooth/example/soc_btmesh_switch/app_out_lcd.c +++ b/app/bluetooth/example/soc_btmesh_switch/app_out_lcd.c @@ -52,7 +52,7 @@ void sl_btmesh_lpn_on_init(void) { app_log("BT mesh LPN on\r\n"); - sl_status_t status = sl_btmesh_LCD_write("LPN on", BTMESH_WSTK_LCD_ROW_LPN); + sl_status_t status = sl_btmesh_LCD_write("LPN on", SL_BTMESH_WSTK_LCD_ROW_LPN_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -62,7 +62,7 @@ void sl_btmesh_lpn_on_init(void) void sl_btmesh_lpn_on_deinit(void) { app_log("BT mesh LPN off\r\n"); - sl_status_t status = sl_btmesh_LCD_write("LPN off", BTMESH_WSTK_LCD_ROW_LPN); + sl_status_t status = sl_btmesh_LCD_write("LPN off", SL_BTMESH_WSTK_LCD_ROW_LPN_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -73,7 +73,7 @@ void sl_btmesh_lpn_on_friendship_established(uint16_t node_address) { app_log("BT mesh LPN with friend (node address: 0x%04x)\r\n", node_address); sl_status_t status = sl_btmesh_LCD_write("LPN with friend", - BTMESH_WSTK_LCD_ROW_LPN); + SL_BTMESH_WSTK_LCD_ROW_LPN_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -84,7 +84,7 @@ void sl_btmesh_lpn_on_friendship_failed(uint16_t reason) { app_log("BT mesh No friend (reason: 0x%04x)\r\n", reason); sl_status_t status = sl_btmesh_LCD_write("No friend", - BTMESH_WSTK_LCD_ROW_LPN); + SL_BTMESH_WSTK_LCD_ROW_LPN_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -95,7 +95,7 @@ void sl_btmesh_lpn_on_friendship_terminated(uint16_t reason) { app_log("BT mesh Friend lost (reason: 0x%04x)\r\n", reason); sl_status_t status = sl_btmesh_LCD_write("Friend lost", - BTMESH_WSTK_LCD_ROW_LPN); + SL_BTMESH_WSTK_LCD_ROW_LPN_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -118,7 +118,7 @@ void sl_btmesh_on_provision_init_status(bool provisioned, } else { app_log("BT mesh node is unprovisioned, started unprovisioned beaconing...\r\n"); sl_status_t status = sl_btmesh_LCD_write("unprovisioned", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } } @@ -130,7 +130,7 @@ void app_show_btmesh_node_provisioning_started(uint16_t result) { app_log("BT mesh node provisioning is started (result: 0x%04x)\r\n", result); sl_status_t status = sl_btmesh_LCD_write("provisioning...", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -144,7 +144,7 @@ void app_show_btmesh_node_provisioned(uint16_t address, address, iv_index); sl_status_t status = sl_btmesh_LCD_write("provisioned", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -155,7 +155,7 @@ void sl_btmesh_on_node_provisioning_failed(uint16_t result) { app_log("BT mesh node provisioning failed (result: 0x%04x)\r\n", result); sl_status_t status = sl_btmesh_LCD_write("prov failed...", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -174,7 +174,7 @@ void sl_btmesh_factory_reset_on_full_reset(void) { app_log("Factory reset\r\n"); sl_status_t status = sl_btmesh_LCD_write("Factory reset", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } @@ -185,7 +185,7 @@ void sl_btmesh_factory_reset_on_node_reset(void) { app_log("Node reset\r\n"); sl_status_t status = sl_btmesh_LCD_write("Node reset", - BTMESH_WSTK_LCD_ROW_STATUS); + SL_BTMESH_WSTK_LCD_ROW_STATUS_CFG_VAL); app_log_status_level_f(APP_LOG_LEVEL_ERROR, status, "LCD write failed"); } diff --git a/app/bluetooth/example/soc_btmesh_switch/dcd_config.btmeshconf b/app/bluetooth/example/soc_btmesh_switch/dcd_config.btmeshconf index d9f6c965d88..6cfbca345c8 100644 --- a/app/bluetooth/example/soc_btmesh_switch/dcd_config.btmeshconf +++ b/app/bluetooth/example/soc_btmesh_switch/dcd_config.btmeshconf @@ -2,7 +2,7 @@ "composition_data": { "cid": "0x02ff", "pid": "0x0006", - "vid": "0x0220", + "vid": "0x0221", "elements": [ { "name": "Main", diff --git a/app/bluetooth/example/soc_btmesh_switch/dcd_config_low_power.btmeshconf b/app/bluetooth/example/soc_btmesh_switch/dcd_config_low_power.btmeshconf index adaeaaa3832..670db312147 100644 --- a/app/bluetooth/example/soc_btmesh_switch/dcd_config_low_power.btmeshconf +++ b/app/bluetooth/example/soc_btmesh_switch/dcd_config_low_power.btmeshconf @@ -2,7 +2,7 @@ "composition_data": { "cid": "0x02ff", "pid": "0x0007", - "vid": "0x0220", + "vid": "0x0221", "elements": [ { "name": "Main", diff --git a/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_display.slcp b/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_display.slcp index 6a526a7dd1d..67efb196186 100644 --- a/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_display.slcp +++ b/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_display.slcp @@ -74,7 +74,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_switch/readme.html + - path: ../../documentation/example/soc_btmesh_switch/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -128,7 +128,7 @@ configuration: - name: SL_SIMPLE_BUTTON_ALLOW_LED_CONFLICT value: "1" - name: SL_STACK_SIZE - value: "0xD00" + value: "0xE00" condition: - "device_sdid_205" - name: SL_STACK_SIZE @@ -162,5 +162,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_log.slcp b/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_log.slcp index abbbc174cc0..1d7ec9be509 100644 --- a/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_log.slcp +++ b/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_log.slcp @@ -73,7 +73,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_switch/readme.html + - path: ../../documentation/example/soc_btmesh_switch/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -116,6 +116,8 @@ configuration: value: "0" condition: - psa_crypto + - name: SL_SIMPLE_BUTTON_ALLOW_LED_CONFLICT + value: "1" - name: SL_STACK_SIZE value: "0x1000" @@ -145,5 +147,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_log_single.slcp b/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_log_single.slcp index 2414739a1f9..39dfd7086ce 100644 --- a/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_log_single.slcp +++ b/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_log_single.slcp @@ -71,7 +71,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_switch/readme.html + - path: ../../documentation/example/soc_btmesh_switch/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -98,11 +98,11 @@ other_file: configuration: - name: APP_LOG_LEVEL value: "APP_LOG_LEVEL_INFO" - - name: CTL_CLIENT_TEMPERATURE_WRAP_ENABLED + - name: SL_BTMESH_CTL_CLIENT_TEMPERATURE_WRAP_ENABLED_CFG_VAL value: "1" - name: NVM3_DEFAULT_CACHE_SIZE value: 100 - - name: LIGHT_LIGHTNESS_WRAP_ENABLED + - name: SL_BTMESH_LIGHT_LIGHTNESS_WRAP_ENABLED_CFG_VAL value: "1" - name: SL_BOARD_ENABLE_VCOM value: "1" @@ -153,5 +153,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme.html + - path: readme.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_low_power.slcp b/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_low_power.slcp index bb5fa359ea2..d4972558917 100644 --- a/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_low_power.slcp +++ b/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_low_power.slcp @@ -62,7 +62,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_switch/readme_low_power.html + - path: ../../documentation/example/soc_btmesh_switch/readme_low_power.md other_file: - path: ../../script/create_bl_files.bat @@ -87,7 +87,7 @@ other_file: folder: images configuration: - - name: LPN_POLL_TIMEOUT + - name: SL_BTMESH_LPN_POLL_TIMEOUT_CFG_VAL value: 120000 - name: NVM3_DEFAULT_CACHE_SIZE value: 100 @@ -118,5 +118,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme_low_power.html + - path: readme_low_power.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_low_power_single.slcp b/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_low_power_single.slcp index ba3561dc6bf..56e13b2797e 100644 --- a/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_low_power_single.slcp +++ b/app/bluetooth/example/soc_btmesh_switch/soc_btmesh_switch_low_power_single.slcp @@ -60,7 +60,7 @@ config_file: directory: btmeshconf readme: - - path: ../../documentation/example/soc_btmesh_switch/readme_low_power.html + - path: ../../documentation/example/soc_btmesh_switch/readme_low_power.md other_file: - path: ../../script/create_bl_files.bat @@ -85,13 +85,13 @@ other_file: folder: images configuration: - - name: CTL_CLIENT_TEMPERATURE_WRAP_ENABLED + - name: SL_BTMESH_CTL_CLIENT_TEMPERATURE_WRAP_ENABLED_CFG_VAL value: "1" - - name: LPN_POLL_TIMEOUT + - name: SL_BTMESH_LPN_POLL_TIMEOUT_CFG_VAL value: 120000 - name: NVM3_DEFAULT_CACHE_SIZE value: 100 - - name: LIGHT_LIGHTNESS_WRAP_ENABLED + - name: SL_BTMESH_LIGHT_LIGHTNESS_WRAP_ENABLED_CFG_VAL value: "1" - name: SL_HEAP_SIZE value: "0x4000" @@ -124,5 +124,5 @@ ui_hints: focus: false - path: config/btmeshconf/dcd_config.btmeshconf focus: false - - path: readme_low_power.html + - path: readme_low_power.md focus: true \ No newline at end of file diff --git a/app/bluetooth/example/soc_dtm/config/dtm_config.h b/app/bluetooth/example/soc_dtm/config/dtm_config.h new file mode 100644 index 00000000000..68188318e9e --- /dev/null +++ b/app/bluetooth/example/soc_dtm/config/dtm_config.h @@ -0,0 +1,19 @@ +#ifndef DTM_CONFIG_H +#define DTM_CONFIG_H + +// <<< Use Configuration Wizard in Context Menu >>> + +// Specify maximum radiated TX power +// Specify maximum TX power. +// If this config is not set, the maximum available is used. +#define DTM_CONFIG_SPECIFY_TX_POWER 0 + +// Maximum radiated TX power level in dBm unit +// Default: 8 +#define DTM_CONFIG_DEFAULT_MAX_TX_POWER (8) + +// + +// <<< end of configuration section >>> + +#endif // DTM_CONFIG_H diff --git a/app/bluetooth/example/soc_dtm/dtm.c b/app/bluetooth/example/soc_dtm/dtm.c index 65a3ef86a73..454d6a3e690 100644 --- a/app/bluetooth/example/soc_dtm/dtm.c +++ b/app/bluetooth/example/soc_dtm/dtm.c @@ -32,6 +32,13 @@ #include "rail_features.h" #include "sl_bt_api.h" #include "app_assert.h" +#include "dtm_config.h" + +#if DTM_CONFIG_SPECIFY_TX_POWER == 1 +#define DTM_DEFAULT_TX_POWER DTM_CONFIG_DEFAULT_MAX_TX_POWER +#else +#define DTM_DEFAULT_TX_POWER MAX_POW_LEVEL_REQ +#endif #define MAX_PDU_OCTETS 255 @@ -104,7 +111,7 @@ typedef struct { uint8_t switch_pat; uint8_t *ant_array; uint8_t slot_duration; - int16_t transmitter_power_level; + int16_t transmitter_power_level_dbm; } setup_t; typedef enum { @@ -198,7 +205,7 @@ static const setup_t default_setup = { .switch_pat = 0, .ant_array = 0, .slot_duration = 1, - .transmitter_power_level = 0, + .transmitter_power_level_dbm = 0, }; static cmd_buffer_t cmd_buffer; @@ -227,6 +234,10 @@ static void process_transceiver_command(cmd_type_t cmd_type, transceiver_cmd_packet_t *cmd); static void process_command(void); static void handle_dtm_completed(sl_bt_msg_t *evt); +static void tx_power_set(int8_t tx_power_dbm, + int16_t *tx_power_out_dbm, + uint16_t *response, + uint8_t *status); /**************************************************************************//** * Initialize testmode library. @@ -271,6 +282,13 @@ void testmode_process_command_byte(uint8_t byte) void testmode_handle_gecko_event(sl_bt_msg_t *evt) { switch (SL_BT_MSG_ID(evt->header)) { + case sl_bt_evt_system_boot_id: + // Set TX power to default, ignore output + tx_power_set(DTM_DEFAULT_TX_POWER, + &setup.transmitter_power_level_dbm, + NULL, + NULL); + break; case sl_bt_evt_system_external_signal_id: if (evt->data.evt_system_external_signal.extsignals & cfg.command_ready_signal) { process_command(); @@ -288,7 +306,9 @@ void testmode_handle_gecko_event(sl_bt_msg_t *evt) static void reset_setup(void) { + int16_t tx_power_dbm_save = setup.transmitter_power_level_dbm; setup = default_setup; + setup.transmitter_power_level_dbm = tx_power_dbm_save; } static void reset_cmd_buffer(void) @@ -357,6 +377,76 @@ static void parse_cmd_buffer(cmd_packet_t *result) } } +/**************************************************************************//** + * Set TX power in dBm + *****************************************************************************/ +static void tx_power_set(int8_t tx_power_dbm, + int16_t *tx_power_out_dbm, + uint16_t *response, + uint8_t *status) +{ + int16_t support_min; + int16_t support_max; + int16_t support_min_dbm; + int16_t support_max_dbm; + int16_t set_min; + int16_t set_max; + int16_t rf_path_gain; + sl_status_t sc; + int16_t tx_power_to_set_dbm = 0; + + *response = 0; + + sc = sl_bt_system_get_tx_power_setting(&support_min, + &support_max, + &set_min, + &set_max, + &rf_path_gain); + + app_assert_status(sc); + + support_min_dbm = (support_min) > 0 ? ((support_min) + 5) / 10 : ((support_min) - 5) / 10; + support_max_dbm = (support_max) > 0 ? ((support_max) + 5) / 10 : ((support_max) - 5) / 10; + + if (tx_power_dbm == MIN_POW_LEVEL_REQ) { + tx_power_to_set_dbm = support_min_dbm; + if (response != NULL) { + *response |= MIN_POW_INDICATE_BIT; + } + } else if (tx_power_dbm == MAX_POW_LEVEL_REQ) { + tx_power_to_set_dbm = support_max_dbm; + if (response != NULL) { + *response |= MAX_POW_INDICATE_BIT; + } + } else if (tx_power_dbm > support_max_dbm) { + if (status != NULL) { + *status = TEST_STATUS_ERROR; + } + return; + } else if (tx_power_dbm < support_min_dbm) { + if (status != NULL) { + *status = TEST_STATUS_ERROR; + } + return; + } else { + tx_power_to_set_dbm = (int16_t)tx_power_dbm; + } + + sc = sl_bt_system_set_tx_power(support_min, + tx_power_to_set_dbm * 10, + &set_min, + &set_max); + app_assert_status(sc); + + // Set outputs + if (response != NULL) { + *response |= (uint8_t)(tx_power_to_set_dbm); + } + if (tx_power_out_dbm != NULL) { + *tx_power_out_dbm = tx_power_to_set_dbm; + } +} + static void process_setup_command(setup_cmd_packet_t *cmd) { uint8_t n = 0; @@ -365,11 +455,6 @@ static void process_setup_command(setup_cmd_packet_t *cmd) sl_status_t sc; int8_t tx_power = 0; uint8_t cte_time = 0; - int16_t support_min; - int16_t support_max; - int16_t set_min; - int16_t set_max; - int16_t rf_path_gain; if (cmd->control == SETUP_CMD_RESET) { cmd->parameter = cmd->parameter >> 2; @@ -487,7 +572,8 @@ static void process_setup_command(setup_cmd_packet_t *cmd) } else { if (setup.switch_pat) { setup.ant_array_length = (setup.num_ant * 2) - 1; - setup.ant_array = (uint8_t *)calloc(setup.ant_array_length, sizeof(uint8_t)); + setup.ant_array = (uint8_t *)calloc(setup.ant_array_length, + sizeof(uint8_t)); for (i = 0; i < setup.num_ant; i++) { setup.ant_array[i] = i; @@ -497,7 +583,8 @@ static void process_setup_command(setup_cmd_packet_t *cmd) } } else { setup.ant_array_length = setup.num_ant; - setup.ant_array = (uint8_t *)calloc(setup.ant_array_length, sizeof(uint8_t)); + setup.ant_array = (uint8_t *)calloc(setup.ant_array_length, + sizeof(uint8_t)); for (i = 0; i < n; i++) { setup.ant_array[i] = i; @@ -509,61 +596,10 @@ static void process_setup_command(setup_cmd_packet_t *cmd) case SETUP_CMD_TRANSMITTER_POWER_LEVEL: tx_power = cmd->parameter; - - sc = sl_bt_system_get_tx_power_setting(&support_min, - &support_max, - &set_min, - &set_max, - &rf_path_gain); - - app_assert_status(sc); - - support_min = (support_min) > 0 ? ((support_min) + 5) / 10 : ((support_min) - 5) / 10; - support_max = (support_max) > 0 ? ((support_max) + 5) / 10 : ((support_max) - 5) / 10; - - if (tx_power == MIN_POW_LEVEL_REQ) { - setup.transmitter_power_level = support_min; - response |= MIN_POW_INDICATE_BIT; - } else if (tx_power == MAX_POW_LEVEL_REQ) { - setup.transmitter_power_level = support_max; - response |= MAX_POW_INDICATE_BIT; - } else if (tx_power > MAX_POW_LEVEL) { - status = TEST_STATUS_ERROR; - break; - } else if (tx_power < MIN_POW_LEVEL) { - status = TEST_STATUS_ERROR; - break; - } else { - // Requested is real TX power in (-127, 20) range - setup.transmitter_power_level = (int16_t)tx_power; - } - - if ((setup.transmitter_power_level * 10) < set_min) { - set_min = setup.transmitter_power_level * 10; - sc = sl_bt_system_set_tx_power(set_min, - set_max, - &set_min, - &set_max); - - app_assert_status(sc); - - set_min = (set_min) > 0 ? ((set_min) + 5) / 10 : ((set_min) - 5) / 10; - setup.transmitter_power_level = set_min; - } else if ((setup.transmitter_power_level * 10) > set_max) { - set_max = setup.transmitter_power_level * 10; - sc = sl_bt_system_set_tx_power(set_min, - set_max, - &set_min, - &set_max); - - app_assert_status(sc); - - set_max = (set_max) > 0 ? ((set_max) + 5) / 10 : ((set_max) - 5) / 10; - setup.transmitter_power_level = set_max; - } - - response |= (uint8_t)setup.transmitter_power_level; - + tx_power_set(tx_power, + &setup.transmitter_power_level_dbm, + &response, + &status); break; default: @@ -587,9 +623,11 @@ static void process_transceiver_command(cmd_type_t cmd_type, if (setup.cte_present) { if (setup.ant_array != 0) { - sc = sl_bt_cte_receiver_set_dtm_parameters(setup.cte_time, setup.cte_type, + sc = sl_bt_cte_receiver_set_dtm_parameters(setup.cte_time, + setup.cte_type, setup.slot_duration, - setup.ant_array_length, setup.ant_array); + setup.ant_array_length, + setup.ant_array); app_assert_status(sc); } } else { @@ -599,10 +637,18 @@ static void process_transceiver_command(cmd_type_t cmd_type, break; case CMD_TYPE_TXTEST: + + tx_power_set(setup.transmitter_power_level_dbm, + NULL, + NULL, + NULL); + if (setup.cte_present) { if (setup.ant_array != 0) { - sc = sl_bt_cte_transmitter_set_dtm_parameters(setup.cte_time, setup.cte_type, - setup.ant_array_length, setup.ant_array); + sc = sl_bt_cte_transmitter_set_dtm_parameters(setup.cte_time, + setup.cte_type, + setup.ant_array_length, + setup.ant_array); app_assert_status(sc); } } else { @@ -611,7 +657,11 @@ static void process_transceiver_command(cmd_type_t cmd_type, // Do the test only if UART Test Interface command packet type is valid if (PACKET_TYPE_MAX > cmd->pkt) { - sc = sl_bt_test_dtm_tx_v4(std_to_bgapi_pkt_types[cmd->pkt], length, cmd->frequency, setup.phy, setup.transmitter_power_level * 10); + sc = sl_bt_test_dtm_tx_v4(std_to_bgapi_pkt_types[cmd->pkt], + length, + cmd->frequency, + setup.phy, + setup.transmitter_power_level_dbm); app_assert_status(sc); } break; @@ -633,7 +683,8 @@ static void process_command(void) case CMD_TYPE_RXTEST: case CMD_TYPE_TXTEST: - process_transceiver_command(cmd_packet.cmd_type, &cmd_packet.cmd.transceiver); + process_transceiver_command(cmd_packet.cmd_type, + &cmd_packet.cmd.transceiver); set_transceiver_test_state(cmd_packet.cmd_type); break; diff --git a/app/bluetooth/example/soc_dtm/soc_dtm.slcp b/app/bluetooth/example/soc_dtm/soc_dtm.slcp index 4d8dcc9609d..400cde207b5 100644 --- a/app/bluetooth/example/soc_dtm/soc_dtm.slcp +++ b/app/bluetooth/example/soc_dtm/soc_dtm.slcp @@ -18,6 +18,7 @@ component: - id: bluetooth_feature_sm - id: bluetooth_feature_system - id: bluetooth_feature_test + - id: bluetooth_feature_afh - id: bt_fp_aoa - id: ota_dfu - id: bootloader_interface @@ -42,8 +43,11 @@ include: - path: app.h - path: dtm.h +config_file: + - path: config/dtm_config.h + readme: - - path: ../../documentation/example/soc_dtm/readme.html + - path: ../../documentation/example/soc_dtm/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -69,5 +73,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_empty/soc_empty.slcp b/app/bluetooth/example/soc_empty/soc_empty.slcp index 7a2a82eba20..450ee25b090 100644 --- a/app/bluetooth/example/soc_empty/soc_empty.slcp +++ b/app/bluetooth/example/soc_empty/soc_empty.slcp @@ -44,7 +44,7 @@ config_file: directory: btconf readme: - - path: ../../documentation/example/soc_empty/readme.html + - path: ../../documentation/example/soc_empty/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -76,5 +76,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_empty_rail_dmp/soc_empty_rail_dmp_freertos.slcp b/app/bluetooth/example/soc_empty_rail_dmp/soc_empty_rail_dmp_freertos.slcp index d636923773c..90d23982e04 100644 --- a/app/bluetooth/example/soc_empty_rail_dmp/soc_empty_rail_dmp_freertos.slcp +++ b/app/bluetooth/example/soc_empty_rail_dmp/soc_empty_rail_dmp_freertos.slcp @@ -56,6 +56,9 @@ include: file_list: - path: app_proprietary.h +readme: + - path: ../../documentation/example/soc_empty_rail_dmp/readme.md + config_file: - override: component: gatt_configuration @@ -66,6 +69,18 @@ config_file: other_file: - path: ../../script/create_bl_files.bat - path: ../../script/create_bl_files.sh + - path: ../../documentation/example/soc_empty_rail_dmp/readme_img0.png + folder: images + - path: ../../documentation/example/soc_empty_rail_dmp/readme_img1.png + folder: images + - path: ../../documentation/example/soc_empty_rail_dmp/readme_img2.png + folder: images + - path: ../../documentation/example/soc_empty_rail_dmp/readme_img3.png + folder: images + - path: ../../documentation/example/soc_empty_rail_dmp/readme_img4.png + folder: images + - path: ../../documentation/example/soc_empty_rail_dmp/readme_img5.png + folder: images configuration: - name: SL_STACK_SIZE @@ -224,4 +239,5 @@ ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - path: config/rail/radio_settings.radioconf + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_empty_rail_dmp/soc_empty_rail_dmp_micriumos.slcp b/app/bluetooth/example/soc_empty_rail_dmp/soc_empty_rail_dmp_micriumos.slcp index 6bdf8ad6579..de63f78f050 100644 --- a/app/bluetooth/example/soc_empty_rail_dmp/soc_empty_rail_dmp_micriumos.slcp +++ b/app/bluetooth/example/soc_empty_rail_dmp/soc_empty_rail_dmp_micriumos.slcp @@ -57,7 +57,7 @@ include: - path: app_proprietary.h readme: - - path: ../../documentation/example/soc_empty_rail_dmp/readme.html + - path: ../../documentation/example/soc_empty_rail_dmp/readme.md config_file: - override: @@ -262,5 +262,5 @@ ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - path: config/rail/radio_settings.radioconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_empty_std_dmp/soc_empty_std_dmp_freertos.slcp b/app/bluetooth/example/soc_empty_std_dmp/soc_empty_std_dmp_freertos.slcp index c7658e6ed2d..c8b4498cb36 100644 --- a/app/bluetooth/example/soc_empty_std_dmp/soc_empty_std_dmp_freertos.slcp +++ b/app/bluetooth/example/soc_empty_std_dmp/soc_empty_std_dmp_freertos.slcp @@ -52,6 +52,9 @@ include: file_list: - path: app_proprietary.h +readme: + - path: ../../documentation/example/soc_empty_std_dmp/readme.md + config_file: - override: component: gatt_configuration @@ -62,6 +65,16 @@ config_file: other_file: - path: ../../script/create_bl_files.bat - path: ../../script/create_bl_files.sh + - path: ../../documentation/example/soc_empty_std_dmp/readme_img0.png + folder: images + - path: ../../documentation/example/soc_empty_std_dmp/readme_img1.png + folder: images + - path: ../../documentation/example/soc_empty_std_dmp/readme_img2.png + folder: images + - path: ../../documentation/example/soc_empty_std_dmp/readme_img3.png + folder: images + - path: ../../documentation/example/soc_empty_std_dmp/readme_img4.png + folder: images configuration: - name: SL_STACK_SIZE @@ -330,4 +343,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_empty_std_dmp/soc_empty_std_dmp_micriumos.slcp b/app/bluetooth/example/soc_empty_std_dmp/soc_empty_std_dmp_micriumos.slcp index 1c8e44f37e0..5d9f2a5f240 100644 --- a/app/bluetooth/example/soc_empty_std_dmp/soc_empty_std_dmp_micriumos.slcp +++ b/app/bluetooth/example/soc_empty_std_dmp/soc_empty_std_dmp_micriumos.slcp @@ -52,6 +52,9 @@ include: file_list: - path: app_proprietary.h +readme: + - path: ../../documentation/example/soc_empty_std_dmp/readme.md + config_file: - override: component: gatt_configuration @@ -62,6 +65,16 @@ config_file: other_file: - path: ../../script/create_bl_files.bat - path: ../../script/create_bl_files.sh + - path: ../../documentation/example/soc_empty_std_dmp/readme_img0.png + folder: images + - path: ../../documentation/example/soc_empty_std_dmp/readme_img1.png + folder: images + - path: ../../documentation/example/soc_empty_std_dmp/readme_img2.png + folder: images + - path: ../../documentation/example/soc_empty_std_dmp/readme_img3.png + folder: images + - path: ../../documentation/example/soc_empty_std_dmp/readme_img4.png + folder: images configuration: - name: SL_STACK_SIZE @@ -346,4 +359,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_ibeacon/soc_ibeacon.slcp b/app/bluetooth/example/soc_ibeacon/soc_ibeacon.slcp index 691c79f85f4..77e8da7e6d6 100644 --- a/app/bluetooth/example/soc_ibeacon/soc_ibeacon.slcp +++ b/app/bluetooth/example/soc_ibeacon/soc_ibeacon.slcp @@ -32,7 +32,7 @@ include: - path: app.h readme: - - path: ../../documentation/example/soc_ibeacon/readme.html + - path: ../../documentation/example/soc_ibeacon/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -63,5 +63,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_iop_test/iop_create_bl_files.ps1 b/app/bluetooth/example/soc_iop_test/iop_create_bl_files.ps1 index e07a713ef4b..42aba5fc0d9 100644 --- a/app/bluetooth/example/soc_iop_test/iop_create_bl_files.ps1 +++ b/app/bluetooth/example/soc_iop_test/iop_create_bl_files.ps1 @@ -6,7 +6,7 @@ # # Prerequisites # - Windows PowerShell. -# - PATH_SCMD and PATH_GCCARM environment variables to be set. See readme.html +# - PATH_SCMD and PATH_GCCARM environment variables to be set. See readme.md # for more information. # - The Bluetooth - SoC Interoperability Test example generated either with # the "Link SDK and copy project sources" or the "Copy contents" option. @@ -19,7 +19,7 @@ # - Start the test. When prompted to choose a gbl file for OTA-DFU, select the # ota-dfu_ack.gbl file. When prompted again, select ota-dfu_non_ack.gbl. # -# For a more detailed guide see the readme.html file of the example. +# For a more detailed guide see the readme.md file of the example. ################################################################################ $App1 = "ota-dfu_non_ack" diff --git a/app/bluetooth/example/soc_iop_test/iop_create_bl_files.sh b/app/bluetooth/example/soc_iop_test/iop_create_bl_files.sh index cfbcde4132b..081a9972071 100644 --- a/app/bluetooth/example/soc_iop_test/iop_create_bl_files.sh +++ b/app/bluetooth/example/soc_iop_test/iop_create_bl_files.sh @@ -9,7 +9,7 @@ # Prerequisites # - Linux or Mac environment. # - The presence of the sed (stream editor) package. -# - PATH_SCMD and PATH_GCCARM environment variables to be set. See readme.html +# - PATH_SCMD and PATH_GCCARM environment variables to be set. See readme.md # for more information. # - The Bluetooth - SoC Interoperability Test example generated either with # the "Link SDK and copy project sources" or the "Copy contents" option. @@ -22,7 +22,7 @@ # - Start the test. When prompted to choose a gbl file for OTA-DFU, select the # ota-dfu_ack.gbl file. When prompted again, select ota-dfu_non_ack.gbl. # -# For a more detailed guide see the readme.html file of the example. +# For a more detailed guide see the readme.md file of the example. ################################################################################ APP_1="ota-dfu_non_ack" diff --git a/app/bluetooth/example/soc_iop_test/soc_iop_test_display.slcp b/app/bluetooth/example/soc_iop_test/soc_iop_test_display.slcp index b638e147889..8b5acfe23bf 100644 --- a/app/bluetooth/example/soc_iop_test/soc_iop_test_display.slcp +++ b/app/bluetooth/example/soc_iop_test/soc_iop_test_display.slcp @@ -52,7 +52,7 @@ config_file: directory: btconf readme: - - path: ../../documentation/example/soc_iop_test/readme.html + - path: ../../documentation/example/soc_iop_test/readme.md other_file: - path: iop_create_bl_files.sh @@ -108,5 +108,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_iop_test/soc_iop_test_log.slcp b/app/bluetooth/example/soc_iop_test/soc_iop_test_log.slcp index d5855a76e2d..d4fdb923eb5 100644 --- a/app/bluetooth/example/soc_iop_test/soc_iop_test_log.slcp +++ b/app/bluetooth/example/soc_iop_test/soc_iop_test_log.slcp @@ -49,7 +49,7 @@ config_file: directory: btconf readme: - - path: ../../documentation/example/soc_iop_test/readme.html + - path: ../../documentation/example/soc_iop_test/readme.md other_file: - path: iop_create_bl_files.sh @@ -98,5 +98,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_light_rail_dmp/freertos/app_proprietary.c b/app/bluetooth/example/soc_light_rail_dmp/freertos/app_proprietary.c index 951412fef2d..92b6b9b6bb0 100644 --- a/app/bluetooth/example/soc_light_rail_dmp/freertos/app_proprietary.c +++ b/app/bluetooth/example/soc_light_rail_dmp/freertos/app_proprietary.c @@ -110,7 +110,7 @@ static uint8_t data_packet[] = }; /// Receive FIFO -static uint8_t rx_fifo[RAIL_FIFO_SIZE]; +static __ALIGNED(RAIL_FIFO_ALIGNMENT) uint8_t rx_fifo[RAIL_FIFO_SIZE]; static uint8_t proprietary_rx_buf[PROP_RX_BUF_SIZE]; @@ -436,7 +436,7 @@ static void proprietary_app_task(void *p_arg) RAIL_Status_t RAILCb_SetupRxFifo(RAIL_Handle_t railHandle) { uint16_t rxFifoSize = RAIL_FIFO_SIZE; - RAIL_Status_t status = RAIL_SetRxFifo(railHandle, &rx_fifo[0], &rxFifoSize); + RAIL_Status_t status = RAIL_SetRxFifo(railHandle, rx_fifo, &rxFifoSize); if (rxFifoSize != RAIL_FIFO_SIZE) { // We set up an incorrect FIFO size return RAIL_STATUS_INVALID_PARAMETER; diff --git a/app/bluetooth/example/soc_light_rail_dmp/micriumos/app_proprietary.c b/app/bluetooth/example/soc_light_rail_dmp/micriumos/app_proprietary.c index 99e961d29da..355d874f278 100644 --- a/app/bluetooth/example/soc_light_rail_dmp/micriumos/app_proprietary.c +++ b/app/bluetooth/example/soc_light_rail_dmp/micriumos/app_proprietary.c @@ -100,7 +100,7 @@ static uint8_t data_packet[] = }; /// Receive FIFO -static uint8_t rx_fifo[RAIL_FIFO_SIZE]; +static __ALIGNED(RAIL_FIFO_ALIGNMENT) uint8_t rx_fifo[RAIL_FIFO_SIZE]; static uint8_t proprietary_rx_buf[PROP_RX_BUF_SIZE]; @@ -458,7 +458,7 @@ static void proprietary_app_task(void *p_arg) RAIL_Status_t RAILCb_SetupRxFifo(RAIL_Handle_t railHandle) { uint16_t rxFifoSize = RAIL_FIFO_SIZE; - RAIL_Status_t status = RAIL_SetRxFifo(railHandle, &rx_fifo[0], &rxFifoSize); + RAIL_Status_t status = RAIL_SetRxFifo(railHandle, rx_fifo, &rxFifoSize); if (rxFifoSize != RAIL_FIFO_SIZE) { // We set up an incorrect FIFO size return RAIL_STATUS_INVALID_PARAMETER; diff --git a/app/bluetooth/example/soc_light_rail_dmp/soc_light_rail_dmp_freertos.slcp b/app/bluetooth/example/soc_light_rail_dmp/soc_light_rail_dmp_freertos.slcp index 24efcaa1a6a..3287e7a3b6c 100644 --- a/app/bluetooth/example/soc_light_rail_dmp/soc_light_rail_dmp_freertos.slcp +++ b/app/bluetooth/example/soc_light_rail_dmp/soc_light_rail_dmp_freertos.slcp @@ -77,9 +77,42 @@ config_file: path: gatt_configuration.btconf directory: btconf +readme: + - path: ../../documentation/example/soc_light_rail_dmp/readme.md + other_file: - path: ../../script/create_bl_files.bat - path: ../../script/create_bl_files.sh + - path: ../../documentation/example/soc_light_rail_dmp/readme_img0.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img1.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img2.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img3.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img4.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img5.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img6.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img7.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img8.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img9.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img10.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img11.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img12.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img13.png + folder: images + - path: ../../documentation/example/soc_light_rail_dmp/readme_img14.png + folder: images configuration: - name: SL_STACK_SIZE @@ -263,4 +296,5 @@ ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - path: config/rail/radio_settings.radioconf + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_light_rail_dmp/soc_light_rail_dmp_micriumos.slcp b/app/bluetooth/example/soc_light_rail_dmp/soc_light_rail_dmp_micriumos.slcp index 67081c94461..7b818e7a571 100644 --- a/app/bluetooth/example/soc_light_rail_dmp/soc_light_rail_dmp_micriumos.slcp +++ b/app/bluetooth/example/soc_light_rail_dmp/soc_light_rail_dmp_micriumos.slcp @@ -77,6 +77,9 @@ config_file: path: gatt_configuration.btconf directory: btconf +readme: + - path: ../../documentation/example/soc_light_rail_dmp/readme.md + other_file: - path: ../../script/create_bl_files.bat - path: ../../script/create_bl_files.sh @@ -310,5 +313,5 @@ ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - path: config/rail/radio_settings.radioconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_light_std_dmp/freertos/app_proprietary.c b/app/bluetooth/example/soc_light_std_dmp/freertos/app_proprietary.c index be90187ce6b..c80ac9b54a5 100644 --- a/app/bluetooth/example/soc_light_std_dmp/freertos/app_proprietary.c +++ b/app/bluetooth/example/soc_light_std_dmp/freertos/app_proprietary.c @@ -122,20 +122,12 @@ static prop_msg_t proprietary_queue_storage[PROPRIETARY_QUEUE_SIZE]; static StaticQueue_t proprietary_queue_buffer; /// Transmit FIFO -static union { - // Used to align this buffer as needed - RAIL_FIFO_ALIGNMENT_TYPE align[TX_PAYLOAD_LENGTH / RAIL_FIFO_ALIGNMENT]; - uint8_t fifo[TX_PAYLOAD_LENGTH]; -} tx_payload = { .fifo = { - 0x0F, 0x16, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, - 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xFF, 0x00, - } }; - -static union { - // Used to align this buffer as needed - RAIL_FIFO_ALIGNMENT_TYPE align[RAIL_FIFO_SIZE / RAIL_FIFO_ALIGNMENT]; - uint8_t fifo[RAIL_FIFO_SIZE]; -} tx_fifo; +static __ALIGNED(RAIL_FIFO_ALIGNMENT) uint8_t tx_payload[TX_PAYLOAD_LENGTH] = { + 0x0F, 0x16, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, + 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xFF, 0x00 +}; + +static __ALIGNED(RAIL_FIFO_ALIGNMENT) uint8_t tx_fifo[RAIL_FIFO_SIZE]; /// Transmit app buffer static uint8_t tx_frame_buff[RAIL_FIFO_SIZE]; @@ -143,7 +135,7 @@ static uint8_t tx_frame_buff[RAIL_FIFO_SIZE]; static volatile bool re_start_rx = false; /// Receive FIFO -static uint8_t rx_fifo[RAIL_FIFO_SIZE]; +static __ALIGNED(RAIL_FIFO_ALIGNMENT) uint8_t rx_fifo[RAIL_FIFO_SIZE]; static uint8_t standard_rx_buf[PROP_RX_BUF_SIZE]; @@ -259,7 +251,7 @@ int16_t app_set_rail_tx_fifo(RAIL_Handle_t rail_handle) // RAIL FIFO size allocated by RAIL_SetTxFifo() call uint16_t allocated_tx_fifo_size = 0; - allocated_tx_fifo_size = RAIL_SetTxFifo(rail_handle, tx_fifo.fifo, + allocated_tx_fifo_size = RAIL_SetTxFifo(rail_handle, tx_fifo, 0u, RAIL_FIFO_SIZE); app_assert(allocated_tx_fifo_size == RAIL_FIFO_SIZE, "RAIL_SetTxFifo() failed to allocate a large enough fifo" @@ -394,38 +386,38 @@ static void standardTxPacket(prop_pkt pktType) .transactionTime = 200 }; // address of light - memcpy((void *)&tx_payload.fifo[PACKET_HEADER_LEN], + memcpy((void *)&tx_payload[PACKET_HEADER_LEN], (void *)demo.own_addr.addr, sizeof(demo.own_addr.addr)); // light role - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_SRC_ROLE_BIT; - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] |= + tx_payload[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_SRC_ROLE_BIT; + tx_payload[LIGHT_CONTROL_DATA_BYTE] |= (DEMO_CONTROL_ROLE_LIGHT << DEMO_CONTROL_PAYLOAD_SRC_ROLE_BIT_SHIFT) & DEMO_CONTROL_PAYLOAD_SRC_ROLE_BIT; // advertisement packet if (PROP_PKT_ADVERTISE == pktType) { - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_CMD_MASK; - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] |= + tx_payload[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_CMD_MASK; + tx_payload[LIGHT_CONTROL_DATA_BYTE] |= ((uint8_t)DEMO_CONTROL_CMD_ADVERTISE << DEMO_CONTROL_PAYLOAD_CMD_MASK_SHIFT) & DEMO_CONTROL_PAYLOAD_CMD_MASK; // status packet } else if (PROP_PKT_STATUS == pktType) { - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_CMD_MASK; - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] |= + tx_payload[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_CMD_MASK; + tx_payload[LIGHT_CONTROL_DATA_BYTE] |= ((uint8_t)DEMO_CONTROL_CMD_LIGHT_STATE_REPORT << DEMO_CONTROL_PAYLOAD_CMD_MASK_SHIFT) & DEMO_CONTROL_PAYLOAD_CMD_MASK; - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] &= ~0x01; - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] |= (uint8_t)demo.light; + tx_payload[LIGHT_CONTROL_DATA_BYTE] &= ~0x01; + tx_payload[LIGHT_CONTROL_DATA_BYTE] |= (uint8_t)demo.light; } else { } #ifdef SL_CATALOG_FLEX_IEEE802154_SUPPORT_PRESENT // Prepare packet sl_flex_ieee802154_prepare_sending(&tx_frame, - (uint8_t *)tx_payload.fifo, - sizeof(tx_payload.fifo)); + tx_payload, + sizeof(tx_payload)); // packs the data frame using the parameter information and the packed // frame is copied into the fifo (void)sl_flex_ieee802154_pack_data_frame(sl_flex_ieee802154_get_std(), @@ -445,7 +437,7 @@ static void standardTxPacket(prop_pkt pktType) // Prepare packet // set ble_send_packet pointer to tx app buff ble_send_packet = sl_flex_ble_get_packet(tx_frame_buff); - sl_flex_ble_prepare_packet(ble_send_packet, tx_payload.fifo, sizeof(tx_payload.fifo)); + sl_flex_ble_prepare_packet(ble_send_packet, tx_payload, sizeof(tx_payload)); packet_size = sl_flex_ble_get_packet_size(ble_send_packet); // Send Packet rail_status = RAIL_WriteTxFifo(rail_handle, tx_frame_buff, packet_size, true); @@ -623,7 +615,7 @@ void sl_rail_util_on_rf_ready(RAIL_Handle_t rail_handle) RAIL_Status_t RAILCb_SetupRxFifo(RAIL_Handle_t railHandle) { uint16_t rxFifoSize = RAIL_FIFO_SIZE; - RAIL_Status_t status = RAIL_SetRxFifo(railHandle, &rx_fifo[0], &rxFifoSize); + RAIL_Status_t status = RAIL_SetRxFifo(railHandle, rx_fifo, &rxFifoSize); if (rxFifoSize != RAIL_FIFO_SIZE) { // We set up an incorrect FIFO size return RAIL_STATUS_INVALID_PARAMETER; diff --git a/app/bluetooth/example/soc_light_std_dmp/micriumos/app_proprietary.c b/app/bluetooth/example/soc_light_std_dmp/micriumos/app_proprietary.c index 3925654f590..abd10cfea0b 100644 --- a/app/bluetooth/example/soc_light_std_dmp/micriumos/app_proprietary.c +++ b/app/bluetooth/example/soc_light_std_dmp/micriumos/app_proprietary.c @@ -111,20 +111,12 @@ static OS_TMR proprietary_timer; static OS_Q proprietary_queue; /// Transmit FIFO -static union { - // Used to align this buffer as needed - RAIL_FIFO_ALIGNMENT_TYPE align[TX_PAYLOAD_LENGTH / RAIL_FIFO_ALIGNMENT]; - uint8_t fifo[TX_PAYLOAD_LENGTH]; -} tx_payload = { .fifo = { - 0x0F, 0x16, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, - 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xFF, 0x00, - } }; - -static union { - // Used to align this buffer as needed - RAIL_FIFO_ALIGNMENT_TYPE align[RAIL_FIFO_SIZE / RAIL_FIFO_ALIGNMENT]; - uint8_t fifo[RAIL_FIFO_SIZE]; -} tx_fifo; +static __ALIGNED(RAIL_FIFO_ALIGNMENT) uint8_t tx_payload[TX_PAYLOAD_LENGTH] = { + 0x0F, 0x16, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, + 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xFF, 0x00 +}; + +static __ALIGNED(RAIL_FIFO_ALIGNMENT) uint8_t tx_fifo[RAIL_FIFO_SIZE]; /// Transmit app buffer static uint8_t tx_frame_buff[RAIL_FIFO_SIZE]; @@ -132,7 +124,7 @@ static uint8_t tx_frame_buff[RAIL_FIFO_SIZE]; static volatile bool re_start_rx = false; /// Receive FIFO -static uint8_t rx_fifo[RAIL_FIFO_SIZE]; +static __ALIGNED(RAIL_FIFO_ALIGNMENT) uint8_t rx_fifo[RAIL_FIFO_SIZE]; static uint8_t standard_rx_buf[PROP_RX_BUF_SIZE]; @@ -248,7 +240,7 @@ int16_t app_set_rail_tx_fifo(RAIL_Handle_t rail_handle) // RAIL FIFO size allocated by RAIL_SetTxFifo() call uint16_t allocated_tx_fifo_size = 0; - allocated_tx_fifo_size = RAIL_SetTxFifo(rail_handle, tx_fifo.fifo, + allocated_tx_fifo_size = RAIL_SetTxFifo(rail_handle, tx_fifo, 0u, RAIL_FIFO_SIZE); app_assert(allocated_tx_fifo_size == RAIL_FIFO_SIZE, "RAIL_SetTxFifo() failed to allocate a large enough fifo" @@ -411,39 +403,39 @@ static void standardTxPacket(prop_pkt pktType) .transactionTime = 200 }; // address of light - Mem_Copy((void *)&tx_payload.fifo[PACKET_HEADER_LEN], + Mem_Copy((void *)&tx_payload[PACKET_HEADER_LEN], (void *)demo.own_addr.addr, sizeof(demo.own_addr.addr)); // light role - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] &= + tx_payload[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_SRC_ROLE_BIT; - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] |= + tx_payload[LIGHT_CONTROL_DATA_BYTE] |= (DEMO_CONTROL_ROLE_LIGHT << DEMO_CONTROL_PAYLOAD_SRC_ROLE_BIT_SHIFT) & DEMO_CONTROL_PAYLOAD_SRC_ROLE_BIT; // advertisement packet if (PROP_PKT_ADVERTISE == pktType) { - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_CMD_MASK; - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] |= + tx_payload[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_CMD_MASK; + tx_payload[LIGHT_CONTROL_DATA_BYTE] |= ((uint8_t)DEMO_CONTROL_CMD_ADVERTISE << DEMO_CONTROL_PAYLOAD_CMD_MASK_SHIFT) & DEMO_CONTROL_PAYLOAD_CMD_MASK; // status packet } else if (PROP_PKT_STATUS == pktType) { - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_CMD_MASK; - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] |= + tx_payload[LIGHT_CONTROL_DATA_BYTE] &= ~DEMO_CONTROL_PAYLOAD_CMD_MASK; + tx_payload[LIGHT_CONTROL_DATA_BYTE] |= ((uint8_t)DEMO_CONTROL_CMD_LIGHT_STATE_REPORT << DEMO_CONTROL_PAYLOAD_CMD_MASK_SHIFT) & DEMO_CONTROL_PAYLOAD_CMD_MASK; - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] &= ~0x01; - tx_payload.fifo[LIGHT_CONTROL_DATA_BYTE] |= (uint8_t)demo.light; + tx_payload[LIGHT_CONTROL_DATA_BYTE] &= ~0x01; + tx_payload[LIGHT_CONTROL_DATA_BYTE] |= (uint8_t)demo.light; } else { } #ifdef SL_CATALOG_FLEX_IEEE802154_SUPPORT_PRESENT // Prepare packet sl_flex_ieee802154_prepare_sending(&tx_frame, - (uint8_t *)tx_payload.fifo, - sizeof(tx_payload.fifo)); + tx_payload, + sizeof(tx_payload)); // packs the data frame using the parameter information and the packed // frame is copied into the fifo (void)sl_flex_ieee802154_pack_data_frame(sl_flex_ieee802154_get_std(), @@ -463,7 +455,7 @@ static void standardTxPacket(prop_pkt pktType) // Prepare packet // set ble_send_packet pointer to tx app buff ble_send_packet = sl_flex_ble_get_packet(tx_frame_buff); - sl_flex_ble_prepare_packet(ble_send_packet, tx_payload.fifo, sizeof(tx_payload.fifo)); + sl_flex_ble_prepare_packet(ble_send_packet, tx_payload, sizeof(tx_payload)); packet_size = sl_flex_ble_get_packet_size(ble_send_packet); // Send Packet rail_status = RAIL_WriteTxFifo(rail_handle, tx_frame_buff, packet_size, true); @@ -646,7 +638,7 @@ void sl_rail_util_on_rf_ready(RAIL_Handle_t rail_handle) RAIL_Status_t RAILCb_SetupRxFifo(RAIL_Handle_t railHandle) { uint16_t rxFifoSize = RAIL_FIFO_SIZE; - RAIL_Status_t status = RAIL_SetRxFifo(railHandle, &rx_fifo[0], &rxFifoSize); + RAIL_Status_t status = RAIL_SetRxFifo(railHandle, rx_fifo, &rxFifoSize); if (rxFifoSize != RAIL_FIFO_SIZE) { // We set up an incorrect FIFO size return RAIL_STATUS_INVALID_PARAMETER; diff --git a/app/bluetooth/example/soc_light_std_dmp/soc_light_std_dmp_freertos.slcp b/app/bluetooth/example/soc_light_std_dmp/soc_light_std_dmp_freertos.slcp index 1a8d0b422be..a270c8fca81 100644 --- a/app/bluetooth/example/soc_light_std_dmp/soc_light_std_dmp_freertos.slcp +++ b/app/bluetooth/example/soc_light_std_dmp/soc_light_std_dmp_freertos.slcp @@ -73,9 +73,40 @@ config_file: path: gatt_configuration.btconf directory: btconf +readme: + - path: ../../documentation/example/soc_light_std_dmp/readme.md + other_file: - path: ../../script/create_bl_files.bat - path: ../../script/create_bl_files.sh + - path: ../../documentation/example/soc_light_std_dmp/readme_img0.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img1.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img2.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img3.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img4.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img5.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img6.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img7.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img8.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img9.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img10.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img11.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img12.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img13.png + folder: images configuration: - name: SL_STACK_SIZE @@ -371,4 +402,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_light_std_dmp/soc_light_std_dmp_micriumos.slcp b/app/bluetooth/example/soc_light_std_dmp/soc_light_std_dmp_micriumos.slcp index 1670d6cce19..cbfbbe3b1e1 100644 --- a/app/bluetooth/example/soc_light_std_dmp/soc_light_std_dmp_micriumos.slcp +++ b/app/bluetooth/example/soc_light_std_dmp/soc_light_std_dmp_micriumos.slcp @@ -73,9 +73,40 @@ config_file: path: gatt_configuration.btconf directory: btconf +readme: + - path: ../../documentation/example/soc_light_std_dmp/readme.md + other_file: - path: ../../script/create_bl_files.bat - path: ../../script/create_bl_files.sh + - path: ../../documentation/example/soc_light_std_dmp/readme_img0.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img1.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img2.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img3.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img4.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img5.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img6.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img7.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img8.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img9.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img10.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img11.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img12.png + folder: images + - path: ../../documentation/example/soc_light_std_dmp/readme_img13.png + folder: images configuration: - name: SL_STACK_SIZE @@ -387,4 +418,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_thermometer/soc_thermometer.slcp b/app/bluetooth/example/soc_thermometer/soc_thermometer.slcp index 656e4914050..8dd58f75281 100644 --- a/app/bluetooth/example/soc_thermometer/soc_thermometer.slcp +++ b/app/bluetooth/example/soc_thermometer/soc_thermometer.slcp @@ -52,7 +52,7 @@ include: - path: app.h readme: - - path: ../../documentation/example/soc_thermometer/readme.html + - path: ../../documentation/example/soc_thermometer/readme.md config_file: - override: @@ -123,5 +123,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_thermometer/soc_thermometer_micriumos.slcp b/app/bluetooth/example/soc_thermometer/soc_thermometer_micriumos.slcp index 38db92d1d8b..ec3336b95be 100644 --- a/app/bluetooth/example/soc_thermometer/soc_thermometer_micriumos.slcp +++ b/app/bluetooth/example/soc_thermometer/soc_thermometer_micriumos.slcp @@ -51,7 +51,7 @@ include: - path: app.h readme: - - path: ../../documentation/example/soc_thermometer_rtos/readme.html + - path: ../../documentation/example/soc_thermometer_rtos/readme.md config_file: - override: @@ -134,5 +134,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_thermometer/soc_thermometer_micriumos_mock.slcp b/app/bluetooth/example/soc_thermometer/soc_thermometer_micriumos_mock.slcp index cafa2da6525..17a1cbd40b8 100644 --- a/app/bluetooth/example/soc_thermometer/soc_thermometer_micriumos_mock.slcp +++ b/app/bluetooth/example/soc_thermometer/soc_thermometer_micriumos_mock.slcp @@ -48,7 +48,7 @@ include: - path: app.h readme: - - path: ../../documentation/example/soc_thermometer_rtos/readme.html + - path: ../../documentation/example/soc_thermometer_rtos/readme.md config_file: - override: @@ -126,5 +126,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_thermometer/soc_thermometer_mock.slcp b/app/bluetooth/example/soc_thermometer/soc_thermometer_mock.slcp index cd81288b28e..334c8581626 100644 --- a/app/bluetooth/example/soc_thermometer/soc_thermometer_mock.slcp +++ b/app/bluetooth/example/soc_thermometer/soc_thermometer_mock.slcp @@ -55,7 +55,7 @@ include: - path: app.h readme: - - path: ../../documentation/example/soc_thermometer/readme.html + - path: ../../documentation/example/soc_thermometer/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -113,5 +113,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_thermometer_client/soc_thermometer_client.slcp b/app/bluetooth/example/soc_thermometer_client/soc_thermometer_client.slcp index f9a48fd89a0..3db1f3ef12e 100644 --- a/app/bluetooth/example/soc_thermometer_client/soc_thermometer_client.slcp +++ b/app/bluetooth/example/soc_thermometer_client/soc_thermometer_client.slcp @@ -44,7 +44,7 @@ include: - path: app.h readme: - - path: ../../documentation/example/soc_thermometer_client/readme.html + - path: ../../documentation/example/soc_thermometer_client/readme.md config_file: - override: @@ -100,5 +100,5 @@ tag: ui_hints: highlight: - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_throughput/app.c b/app/bluetooth/example/soc_throughput/app.c index 0490909b65f..8ba33a35c1c 100644 --- a/app/bluetooth/example/soc_throughput/app.c +++ b/app/bluetooth/example/soc_throughput/app.c @@ -170,6 +170,9 @@ void app_test(bool start) sc = throughput_peripheral_start(type); if (sc != SL_STATUS_OK) { app_log_warning("Failed to start test." APP_LOG_NEW_LINE); + if (sc == SL_STATUS_INVALID_STATE) { + app_log_warning("Not in subscribed state!" APP_LOG_NEW_LINE); + } } } else { sc = throughput_central_set_type(type); @@ -179,6 +182,9 @@ void app_test(bool start) sc = throughput_central_start(); if (sc != SL_STATUS_OK) { app_log_warning("Failed to start test." APP_LOG_NEW_LINE); + if (sc == SL_STATUS_INVALID_STATE) { + app_log_warning("Not in subscribed state!" APP_LOG_NEW_LINE); + } } } } diff --git a/app/bluetooth/example/soc_throughput/soc_throughput_display.slcp b/app/bluetooth/example/soc_throughput/soc_throughput_display.slcp index ba201d2a88a..f20027b5e01 100644 --- a/app/bluetooth/example/soc_throughput/soc_throughput_display.slcp +++ b/app/bluetooth/example/soc_throughput/soc_throughput_display.slcp @@ -48,7 +48,7 @@ config_file: directory: btconf readme: - - path: ../../documentation/example/soc_throughput/readme.html + - path: ../../documentation/example/soc_throughput/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -97,5 +97,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_throughput/soc_throughput_log.slcp b/app/bluetooth/example/soc_throughput/soc_throughput_log.slcp index f0825204962..744c503294e 100644 --- a/app/bluetooth/example/soc_throughput/soc_throughput_log.slcp +++ b/app/bluetooth/example/soc_throughput/soc_throughput_log.slcp @@ -48,7 +48,7 @@ config_file: directory: btconf readme: - - path: ../../documentation/example/soc_throughput/readme.html + - path: ../../documentation/example/soc_throughput/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -95,5 +95,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_throughput/soc_throughput_log_single.slcp b/app/bluetooth/example/soc_throughput/soc_throughput_log_single.slcp index b6aef40695d..a6cadbbb3ff 100644 --- a/app/bluetooth/example/soc_throughput/soc_throughput_log_single.slcp +++ b/app/bluetooth/example/soc_throughput/soc_throughput_log_single.slcp @@ -51,7 +51,7 @@ config_file: directory: btconf readme: - - path: ../../documentation/example/soc_throughput/readme.html + - path: ../../documentation/example/soc_throughput/readme.md other_file: - path: ../../script/create_bl_files.bat @@ -99,5 +99,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_thunderboard/advertise.c b/app/bluetooth/example/soc_thunderboard/advertise.c index b66ed47afb8..6b1dafebda7 100644 --- a/app/bluetooth/example/soc_thunderboard/advertise.c +++ b/app/bluetooth/example/soc_thunderboard/advertise.c @@ -3,7 +3,7 @@ * @brief Thunderboard advertising ******************************************************************************* * # License - * Copyright 2020 Silicon Laboratories Inc. www.silabs.com + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com ******************************************************************************* * * SPDX-License-Identifier: Zlib @@ -28,10 +28,12 @@ * ******************************************************************************/ +#include #include "sl_bluetooth.h" +#include "gatt_db.h" #include "sl_simple_timer.h" -#include "sl_simple_led_instances.h" #include "app_assert.h" +#include "board.h" #include "advertise.h" typedef enum { @@ -43,7 +45,6 @@ typedef enum { // Configuration #define ADV_ALTERNATE_TIME_MS 1000 -#define ADV_LED SL_SIMPLE_LED_INSTANCE(0) #define ADV_TYPE_DEFAULT ADV_TYPE_SCAN_RESPONSE // ----------------------------------------------------------------------------- @@ -71,11 +72,10 @@ typedef enum { /** Complete local name. */ #define ADVERTISE_TYPE_LOCAL_NAME 0x09 - -#define ADVERTISE_DEVICE_NAME_LENGTH 19 - -#define ADVERTISE_DEVICE_NAME_DEFAULT "Thunderboard #00000" -#define ADVERTISE_DEVICE_NAME_FORMAT_STRING "Thunderboard #%05d" +#define ADVERTISE_DEVICE_NAME_LEN_MAX 20 +#define ADVERTISE_DEVICE_NAME_DEFAULT_PREFIX "Thunderboard " +#define ADVERTISE_DEVICE_NAME_DEFAULT_SUFFIX "#00000" +#define ADVERTISE_DEVICE_NAME_FORMAT_STRING "#%05d" // ------------------------------- // iBeacon @@ -146,7 +146,7 @@ typedef struct { uint8_t firmware_id[2]; /**< Firmware ID */ uint8_t local_name_length; /**< Length of the local name field. */ uint8_t local_name_type; /**< Type of the local name field. */ - uint8_t local_name[ADVERTISE_DEVICE_NAME_LENGTH]; /**< Local name field. */ + uint8_t local_name[ADVERTISE_DEVICE_NAME_LEN_MAX]; /**< Local name field. */ } advertise_scan_response_t; #define ADVERTISE_SCAN_RESPONSE_DEFAULT \ @@ -159,9 +159,10 @@ typedef struct { .mandatory_data_type = ADVERTISE_MANDATORY_DATA_TYPE_MANUFACTURER, \ .company_id = UINT16_TO_BYTES(ADVERTISE_COMPANY_ID), \ .firmware_id = UINT16_TO_BYTES(ADVERTISE_FIRMWARE_ID), \ - .local_name_length = ADVERTISE_DEVICE_NAME_LENGTH + 1, \ + .local_name_length = ADVERTISE_DEVICE_NAME_LEN_MAX + 1, \ .local_name_type = ADVERTISE_TYPE_LOCAL_NAME, \ - .local_name = ADVERTISE_DEVICE_NAME_DEFAULT \ + .local_name = ADVERTISE_DEVICE_NAME_DEFAULT_PREFIX \ + ADVERTISE_DEVICE_NAME_DEFAULT_SUFFIX \ } // ----------------------------------------------------------------------------- @@ -212,7 +213,7 @@ static void adv_timer_cb(sl_simple_timer_t *timer, void *data) : ADV_TYPE_IBEACON; adv_set_data(advType); // Toggle advertising LED state - sl_led_toggle(ADV_LED); + adv_led_toggle(); } // ----------------------------------------------------------------------------- @@ -221,27 +222,39 @@ static void adv_timer_cb(sl_simple_timer_t *timer, void *data) void advertise_init(uint32_t unique_id) { sl_status_t sc; - int local_name_length; - // Helper buffer to hold device name + string terminating null character - char local_name[ADVERTISE_DEVICE_NAME_LENGTH + 1]; + + // Read device name from the local GATT table + size_t local_name_length; + // Helper buffer to hold device name string and the terminating null character + uint8_t local_name[ADVERTISE_DEVICE_NAME_LEN_MAX + 1]; + sc = sl_bt_gatt_server_read_attribute_value(gattdb_device_name, + 0, + sizeof(local_name) - 1, + &local_name_length, + local_name); + app_log_status_error(sc); // Update iBeacon data adv_ibeacon.minor[1] = (uint8_t)unique_id; adv_ibeacon.minor[0] = (uint8_t)(unique_id >> 8); adv_ibeacon.major[1] = (uint8_t)(unique_id >> 16); + // Search for device name suffix + char *suffix; + suffix = strstr((char *)local_name, ADVERTISE_DEVICE_NAME_DEFAULT_SUFFIX); + app_assert(suffix != NULL, + "Device name substring cannot be found: %s\n", + (char *)local_name); + // Update Scan Response data - local_name_length = snprintf(local_name, - ADVERTISE_DEVICE_NAME_LENGTH + 1, - ADVERTISE_DEVICE_NAME_FORMAT_STRING, - (int)(unique_id & 0xFFFF)); - app_assert(local_name_length == ADVERTISE_DEVICE_NAME_LENGTH, - "Local name length mismatch: %d != %d\n", - local_name_length, - ADVERTISE_DEVICE_NAME_LENGTH); + (void)snprintf(suffix, + strlen(ADVERTISE_DEVICE_NAME_DEFAULT_SUFFIX) + 1, + ADVERTISE_DEVICE_NAME_FORMAT_STRING, + (int)(unique_id & 0xFFFF)); (void)memcpy(adv_scan_response.local_name, local_name, - ADVERTISE_DEVICE_NAME_LENGTH); + local_name_length + 1); + adv_scan_response.local_name_length = local_name_length + 1; // Create an advertising set sc = sl_bt_advertiser_create_set(&adv_set_handle); @@ -267,7 +280,7 @@ void advertise_start(void) adv_set_data(ADV_TYPE_DEFAULT); // Turn on advertising LED - sl_led_turn_on(ADV_LED); + adv_led_turn_on(); // Start user defined advertising and enable connections sc = sl_bt_advertiser_start(adv_set_handle, @@ -295,5 +308,5 @@ void advertise_stop(void) app_assert_status(sc); // Turn off advertising LED - sl_led_turn_off(ADV_LED); + adv_led_turn_off(); } diff --git a/app/bluetooth/example/soc_thunderboard/app.c b/app/bluetooth/example/soc_thunderboard/app.c index 2557f811847..fd8fed56dee 100644 --- a/app/bluetooth/example/soc_thunderboard/app.c +++ b/app/bluetooth/example/soc_thunderboard/app.c @@ -3,7 +3,7 @@ * @brief Core application logic. ******************************************************************************* * # License - * Copyright 2020 Silicon Laboratories Inc. www.silabs.com + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com ******************************************************************************* * * SPDX-License-Identifier: Zlib @@ -29,6 +29,7 @@ ******************************************************************************/ #include +#include #include "em_common.h" #include "em_emu.h" #include "em_gpio.h" @@ -105,9 +106,10 @@ #endif // SL_CATALOG_SENSOR_SOUND_PRESENT // ----------------------------------------------------------------------------- -// Configuration +// Macros #define SHUTDOWN_TIMEOUT_MS 60000 +#define FW_REV_STR_LEN 6 // ----------------------------------------------------------------------------- // Private variables @@ -132,9 +134,9 @@ void app_init(void) app_log_nl(); sl_power_supply_probe(); shutdown_start_timer(); -#ifdef BOARD_RGBLED_PRESENT +#if defined(BOARD_RGBLED_COUNT) && (BOARD_RGBLED_COUNT > 0) rgb_led_init(); -#endif // BOARD_RGBLED_PRESENT +#endif // BOARD_RGBLED_COUNT } SL_WEAK void app_process_action(void) @@ -159,7 +161,20 @@ void sl_bt_on_event(sl_bt_msg_t *evt) switch (SL_BT_MSG_ID(evt->header)) { // ------------------------------- - case sl_bt_evt_system_boot_id: + case sl_bt_evt_system_boot_id: { + // Set Firmware Revision string. Use the BLE stack version. + char fw_rev[FW_REV_STR_LEN]; + snprintf(fw_rev, + FW_REV_STR_LEN, + "%1d.%1d.%1d", + evt->data.evt_system_boot.major, + evt->data.evt_system_boot.minor, + evt->data.evt_system_boot.patch); + sc = sl_bt_gatt_server_write_attribute_value(gattdb_firmware_rev, + 0, + FW_REV_STR_LEN - 1, + (uint8_t *)fw_rev); + app_log_status_error(sc); // Print boot message. app_log_info("Bluetooth stack booted: v%d.%d.%d-b%d", evt->data.evt_system_boot.major, @@ -197,6 +212,7 @@ void sl_bt_on_event(sl_bt_msg_t *evt) app_assert_status(sc); advertise_init(unique_id); break; + } // ------------------------------- case sl_bt_evt_connection_opened_id: @@ -211,9 +227,9 @@ void sl_bt_on_event(sl_bt_msg_t *evt) case sl_bt_evt_connection_closed_id: app_log_info("Connection closed"); app_log_nl(); - advertise_start(); shutdown_start_timer(); sensor_deinit(); + advertise_start(); break; // ------------------------------- @@ -243,10 +259,11 @@ static void shutdown(sl_simple_timer_t *timer, void *data) EMU_EM4Init_TypeDef em4_init = EMU_EM4INIT_DEFAULT; em4_init.pinRetentionMode = emuPinRetentionEm4Exit; EMU_EM4Init(&em4_init); - // Set up for EM4 wakeup from button 0. Need to enable glitch filter - sl_simple_button_context_t *button = sl_button_btn0.context; + + // Set up EM4 wake-up for the chosen button. Need to enable glitch filter. + sl_simple_button_context_t *button = BOARD_EM4WUEN_BTN.context; GPIO_PinModeSet(button->port, button->pin, gpioModeInputPullFilter, 1); - GPIO_EM4EnablePinWakeup( (BOARD_BUTTON0_EM4WUEN_MASK << _GPIO_EM4WUEN_EM4WUEN_SHIFT), 0); + GPIO_EM4EnablePinWakeup((BOARD_EM4WUEN_MASK << _GPIO_EM4WUEN_EM4WUEN_SHIFT), 0); advertise_stop(); @@ -319,11 +336,11 @@ static void sensor_deinit(void) #ifdef SL_CATALOG_SENSOR_IMU_PRESENT sl_sensor_imu_deinit(); #endif // SL_CATALOG_SENSOR_IMU_PRESENT -#ifdef BOARD_RGBLED_PRESENT +#if defined(BOARD_RGBLED_COUNT) && (BOARD_RGBLED_COUNT > 0) rgb_led_deinit(); -#endif // BOARD_RGBLED_PRESENT +#endif // BOARD_RGBLED_COUNT #ifdef SL_CATALOG_SENSOR_PRESSURE_PRESENT - sl_pressure_deinit(); + sl_sensor_pressure_deinit(); #endif // SL_CATALOG_SENSOR_PRESSURE_PRESENT #ifdef SL_CATALOG_SENSOR_GAS_PRESENT if (!sl_power_supply_is_low_power()) { @@ -451,7 +468,7 @@ void sl_gatt_service_imu_enable(bool enable) } #endif -#if defined(SL_CATALOG_GATT_SERVICE_RGB_PRESENT) && defined(BOARD_RGBLED_PRESENT) +#if defined(SL_CATALOG_GATT_SERVICE_RGB_PRESENT) && defined(BOARD_RGBLED_COUNT) && (BOARD_RGBLED_COUNT > 0) void sl_gatt_service_rgb_set_led(uint8_t m, uint8_t r, uint8_t g, uint8_t b) { if (!sl_power_supply_is_low_power()) { @@ -460,13 +477,18 @@ void sl_gatt_service_rgb_set_led(uint8_t m, uint8_t r, uint8_t g, uint8_t b) app_log_nl(); } } + +uint8_t sl_gatt_service_rgb_get_led_mask(void) +{ + return BOARD_RGBLED_MASK; +} #endif #if defined(SL_CATALOG_GATT_SERVICE_PRESSURE_PRESENT) && defined(SL_CATALOG_SENSOR_PRESSURE_PRESENT) sl_status_t sl_gatt_service_pressure_get(float *pressure) { sl_status_t sc; - sc = sl_pressure_get(pressure); + sc = sl_sensor_pressure_get(pressure); if (SL_STATUS_OK == sc) { app_log_info("Pressure = %0.3f mbar", *pressure); app_log_nl(); diff --git a/app/bluetooth/example/soc_thunderboard/brd2601b/board.h b/app/bluetooth/example/soc_thunderboard/brd2601b/board.h new file mode 100644 index 00000000000..2aa20a54a6a --- /dev/null +++ b/app/bluetooth/example/soc_thunderboard/brd2601b/board.h @@ -0,0 +1,50 @@ +/***************************************************************************//** + * @file + * @brief Board HW abstraction header for BRD2601B + ******************************************************************************* + * # License + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com + ******************************************************************************* + * + * SPDX-License-Identifier: Zlib + * + * The licensor of this software is Silicon Laboratories Inc. + * + * This software is provided 'as-is', without any express or implied + * warranty. In no event will the authors be held liable for any damages + * arising from the use of this software. + * + * Permission is granted to anyone to use this software for any purpose, + * including commercial applications, and to alter it and redistribute it + * freely, subject to the following restrictions: + * + * 1. The origin of this software must not be misrepresented; you must not + * claim that you wrote the original software. If you use this software + * in a product, an acknowledgment in the product documentation would be + * appreciated but is not required. + * 2. Altered source versions must be plainly marked as such, and must not be + * misrepresented as being the original software. + * 3. This notice may not be removed or altered from any source distribution. + * + ******************************************************************************/ + +#ifndef BOARD_H +#define BOARD_H + +//-------------------------------- +#define BOARD_EM4WUEN_BTN sl_button_btn1 // The button to use for EM4 wake-up +#define BOARD_EM4WUEN_NUM 4 // The EM4WU interrupt number of the chosen button. (See the Reference Manual.) +#define BOARD_EM4WUEN_MASK (1 << BOARD_EM4WUEN_NUM) // GPIO pinmask for EM4 wake-up + +//-------------------------------- +#define BOARD_RGBLED_COUNT 1 // Number of RGB LEDs on the board +#define BOARD_RGBLED_MASK 0x01 // Bitmask corresponding to the only RGB LED the board has + +void rgb_led_init(void); +void rgb_led_deinit(void); +void rgb_led_set(uint8_t m, uint8_t r, uint8_t g, uint8_t b); +void adv_led_turn_on(void); +void adv_led_turn_off(void); +void adv_led_toggle(void); + +#endif // BOARD_H diff --git a/app/bluetooth/example/soc_thunderboard/brd2601b/rgbled.c b/app/bluetooth/example/soc_thunderboard/brd2601b/rgbled.c new file mode 100644 index 00000000000..35d838956c9 --- /dev/null +++ b/app/bluetooth/example/soc_thunderboard/brd2601b/rgbled.c @@ -0,0 +1,110 @@ +/***************************************************************************//** + * @file + * @brief RGB LED driver for BRD2601B + ******************************************************************************* + * # License + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com + ******************************************************************************* + * + * SPDX-License-Identifier: Zlib + * + * The licensor of this software is Silicon Laboratories Inc. + * + * This software is provided 'as-is', without any express or implied + * warranty. In no event will the authors be held liable for any damages + * arising from the use of this software. + * + * Permission is granted to anyone to use this software for any purpose, + * including commercial applications, and to alter it and redistribute it + * freely, subject to the following restrictions: + * + * 1. The origin of this software must not be misrepresented; you must not + * claim that you wrote the original software. If you use this software + * in a product, an acknowledgment in the product documentation would be + * appreciated but is not required. + * 2. Altered source versions must be plainly marked as such, and must not be + * misrepresented as being the original software. + * 3. This notice may not be removed or altered from any source distribution. + * + ******************************************************************************/ + +#include "em_gpio.h" +#include "sl_simple_rgb_pwm_led_instances.h" +#include "sl_simple_rgb_pwm_led.h" +#include "app_log.h" +#include "board.h" + +#define ADV_LED_RED_INTENSITY 127 +#define ADV_LED_GREEN_INTENSITY 0 +#define ADV_LED_BLUE_INTENSITY 0 + +// ----------------------------------------------------------------------------- +// Private variables + +// Array to linearize the light level of the RGB LEDs +static const uint8_t light_levels[] = { + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, + 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, + 0x02, 0x02, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x04, 0x04, 0x04, 0x04, 0x04, 0x05, 0x05, 0x05, + 0x05, 0x06, 0x06, 0x06, 0x07, 0x07, 0x07, 0x08, 0x08, 0x08, 0x09, 0x09, 0x0A, 0x0A, 0x0B, 0x0B, + 0x0C, 0x0C, 0x0D, 0x0D, 0x0E, 0x0F, 0x0F, 0x10, 0x11, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, + 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1F, 0x20, 0x21, 0x23, 0x24, 0x26, 0x27, 0x29, 0x2B, 0x2C, + 0x2E, 0x30, 0x32, 0x34, 0x36, 0x38, 0x3A, 0x3C, 0x3E, 0x40, 0x43, 0x45, 0x47, 0x4A, 0x4C, 0x4F, + 0x51, 0x54, 0x57, 0x59, 0x5C, 0x5F, 0x62, 0x64, 0x67, 0x6A, 0x6D, 0x70, 0x73, 0x76, 0x79, 0x7C, + 0x7F, 0x82, 0x85, 0x88, 0x8B, 0x8E, 0x91, 0x94, 0x97, 0x9A, 0x9C, 0x9F, 0xA2, 0xA5, 0xA7, 0xAA, + 0xAD, 0xAF, 0xB2, 0xB4, 0xB7, 0xB9, 0xBB, 0xBE, 0xC0, 0xC2, 0xC4, 0xC6, 0xC8, 0xCA, 0xCC, 0xCE, + 0xD0, 0xD2, 0xD3, 0xD5, 0xD7, 0xD8, 0xDA, 0xDB, 0xDD, 0xDE, 0xDF, 0xE1, 0xE2, 0xE3, 0xE4, 0xE5, + 0xE6, 0xE7, 0xE8, 0xE9, 0xEA, 0xEB, 0xEC, 0xED, 0xED, 0xEE, 0xEF, 0xEF, 0xF0, 0xF1, 0xF1, 0xF2, + 0xF2, 0xF3, 0xF3, 0xF4, 0xF4, 0xF5, 0xF5, 0xF6, 0xF6, 0xF6, 0xF7, 0xF7, 0xF7, 0xF8, 0xF8, 0xF8, + 0xF9, 0xF9, 0xF9, 0xF9, 0xFA, 0xFA, 0xFA, 0xFA, 0xFA, 0xFB, 0xFB, 0xFB, 0xFB, 0xFB, 0xFB, 0xFC, + 0xFC, 0xFC, 0xFC, 0xFC, 0xFC, 0xFC, 0xFC, 0xFC, 0xFD, 0xFD, 0xFD, 0xFD, 0xFD, 0xFD, 0xFD, 0xFD, + 0xFD, 0xFD, 0xFD, 0xFD, 0xFD, 0xFD, 0xFD, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFE, 0xFF, 0xFF +}; + +// ----------------------------------------------------------------------------- +// Public function definitions + +void rgb_led_init(void) +{ +} + +void rgb_led_deinit(void) +{ + sl_simple_rgb_pwm_led_turn_off(sl_led_rgb.led_common.context); +} + +void rgb_led_set(uint8_t m, uint8_t r, uint8_t g, uint8_t b) +{ + // Make sure the mask corresponds to the RGB LEDs of the board. + if (m != (m & BOARD_RGBLED_MASK)) { + m = m & BOARD_RGBLED_MASK; + app_log_error("Undefined RGB LED is trying to be set." APP_LOG_NL); + } + + if (m != 0) { + sl_simple_rgb_pwm_led_set_color(sl_led_rgb.led_common.context, + light_levels[r], + light_levels[g], + light_levels[b]); + } else { + sl_simple_rgb_pwm_led_turn_off(sl_led_rgb.led_common.context); + } +} + +void adv_led_turn_on(void) +{ + sl_simple_rgb_pwm_led_set_color(sl_led_rgb.led_common.context, + light_levels[ADV_LED_RED_INTENSITY], + light_levels[ADV_LED_GREEN_INTENSITY], + light_levels[ADV_LED_BLUE_INTENSITY]); +} + +void adv_led_turn_off(void) +{ + sl_simple_rgb_pwm_led_turn_off(sl_led_rgb.led_common.context); +} + +void adv_led_toggle(void) +{ + sl_simple_rgb_pwm_led_toggle(sl_led_rgb.led_common.context); +} diff --git a/app/bluetooth/example/soc_thunderboard/brd2601b/sl_simple_rgb_pwm_led_led_rgb_config.h b/app/bluetooth/example/soc_thunderboard/brd2601b/sl_simple_rgb_pwm_led_led_rgb_config.h new file mode 100644 index 00000000000..4de4470ec61 --- /dev/null +++ b/app/bluetooth/example/soc_thunderboard/brd2601b/sl_simple_rgb_pwm_led_led_rgb_config.h @@ -0,0 +1,95 @@ +/***************************************************************************//** + * @file + * @brief Simple RGB PWM Led Driver Configuration + ******************************************************************************* + * # License + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com + ******************************************************************************* + * + * SPDX-License-Identifier: Zlib + * + * The licensor of this software is Silicon Laboratories Inc. + * + * This software is provided 'as-is', without any express or implied + * warranty. In no event will the authors be held liable for any damages + * arising from the use of this software. + * + * Permission is granted to anyone to use this software for any purpose, + * including commercial applications, and to alter it and redistribute it + * freely, subject to the following restrictions: + * + * 1. The origin of this software must not be misrepresented; you must not + * claim that you wrote the original software. If you use this software + * in a product, an acknowledgment in the product documentation would be + * appreciated but is not required. + * 2. Altered source versions must be plainly marked as such, and must not be + * misrepresented as being the original software. + * 3. This notice may not be removed or altered from any source distribution. + * + ******************************************************************************/ + +#ifndef SL_SIMPLE_RGB_PWM_LED_LED_RGB_CONFIG_H +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_CONFIG_H + +// <<< Use Configuration Wizard in Context Menu >>> + +// Simple RGB PWM LED Configuration +// PWM frequency [Hz] +// Sets the frequency of the PWM signal +// 0 = Don't care +// Default: 10000 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_FREQUENCY 10000 + +// PWM resolution <2-65536> +// Specifies the PWM (dimming) resolution. I.e. if you want a +// dimming resolution that takes the input values from 0 to 99, +// set this value to 100 +// Default: 256 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RESOLUTION 256 + +// Red LED Polarity +// Active low +// Active high +// Default: SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_LOW +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RED_POLARITY SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_LOW +// Green LED Polarity +// Active low +// Active high +// Default: SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_LOW +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_GREEN_POLARITY SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_LOW + +// Blue LED Polarity +// Active low +// Active high +// Default: SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_LOW +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_BLUE_POLARITY SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_LOW +// end led configuration + +// <<< end of configuration section >>> + +// <<< sl:start pin_tool >>> + +// SL_SIMPLE_RGB_PWM_LED_LED_RGB +// $[TIMER_SL_SIMPLE_RGB_PWM_LED_LED_RGB] +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_PERIPHERAL TIMER1 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_PERIPHERAL_NO 1 + +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RED_CHANNEL 0 +// TIMER1 CC0 on PD02 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RED_PORT gpioPortD +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RED_PIN 2 + +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_GREEN_CHANNEL 1 +// TIMER1 CC1 on PA04 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_GREEN_PORT gpioPortA +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_GREEN_PIN 4 + +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_BLUE_CHANNEL 2 +// TIMER1 CC2 on PB00 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_BLUE_PORT gpioPortB +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_BLUE_PIN 0 +// [TIMER_SL_SIMPLE_RGB_PWM_LED_LED_RGB]$ + +// <<< sl:end pin_tool >>> + +#endif // SL_SIMPLE_RGB_PWM_LED_LED_RGB_CONFIG_H diff --git a/app/bluetooth/example/soc_thunderboard/brd4166a/board.h b/app/bluetooth/example/soc_thunderboard/brd4166a/board.h index c89f0fbb838..54dd6e223e1 100644 --- a/app/bluetooth/example/soc_thunderboard/brd4166a/board.h +++ b/app/bluetooth/example/soc_thunderboard/brd4166a/board.h @@ -3,7 +3,7 @@ * @brief Board HW abstraction header for BRD4166A ******************************************************************************* * # License - * Copyright 2020 Silicon Laboratories Inc. www.silabs.com + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com ******************************************************************************* * * SPDX-License-Identifier: Zlib @@ -31,20 +31,33 @@ #ifndef BOARD_H #define BOARD_H -#define BOARD_BUTTON0_EM4WUEN_MASK 0x10 /**< Mask to enable EM4 wake-up BTN0 */ +//-------------------------------- +#include "sl_simple_led_instances.h" -#define BOARD_RGBLED_PRESENT 1 /**< RGB LED present on board */ -#define BOARD_RGBLED_PWR_EN_PORT gpioPortJ /**< RGB LED Power Enable port */ -#define BOARD_RGBLED_PWR_EN_PIN 14 /**< RGB LED Power Enable pin */ -#define BOARD_RGBLED_COM_PORT gpioPortI /**< RGB LED COM port */ -#define BOARD_RGBLED_COM0_PORT gpioPortI /**< RGB LED COM0 port */ -#define BOARD_RGBLED_COM0_PIN 0 /**< RGB LED COM0 pin */ -#define BOARD_RGBLED_COM1_PORT gpioPortI /**< RGB LED COM1 port */ -#define BOARD_RGBLED_COM1_PIN 1 /**< RGB LED COM1 pin */ -#define BOARD_RGBLED_COM2_PORT gpioPortI /**< RGB LED COM2 port */ -#define BOARD_RGBLED_COM2_PIN 2 /**< RGB LED COM2 pin */ -#define BOARD_RGBLED_COM3_PORT gpioPortI /**< RGB LED COM3 port */ -#define BOARD_RGBLED_COM3_PIN 3 /**< RGB LED COM3 pin */ +#define ADV_LED SL_SIMPLE_LED_INSTANCE(0) +#define adv_led_turn_on() sl_led_turn_on(ADV_LED) +#define adv_led_turn_off() sl_led_turn_off(ADV_LED) +#define adv_led_toggle() sl_led_toggle(ADV_LED) + +//-------------------------------- +#define BOARD_EM4WUEN_BTN sl_button_btn0 // The button to use for EM4 wake-up +#define BOARD_EM4WUEN_NUM 4 // The EM4WU interrupt number of the chosen button. (See the Reference Manual.) +#define BOARD_EM4WUEN_MASK (1 << BOARD_EM4WUEN_NUM) // GPIO pinmask for EM4 wake-up + +//-------------------------------- +#define BOARD_RGBLED_COUNT 4 // Number of RGB LEDs on the board +#define BOARD_RGBLED_MASK 0x0F // Bitmask corresponding to the 4 RGB LEDs +#define BOARD_RGBLED_PWR_EN_PORT gpioPortJ // RGB LED Power Enable port +#define BOARD_RGBLED_PWR_EN_PIN 14 // RGB LED Power Enable pin +#define BOARD_RGBLED_COM_PORT gpioPortI // RGB LED COM port +#define BOARD_RGBLED_COM0_PORT gpioPortI // RGB LED COM0 port +#define BOARD_RGBLED_COM0_PIN 0 // RGB LED COM0 pin +#define BOARD_RGBLED_COM1_PORT gpioPortI // RGB LED COM1 port +#define BOARD_RGBLED_COM1_PIN 1 // RGB LED COM1 pin +#define BOARD_RGBLED_COM2_PORT gpioPortI // RGB LED COM2 port +#define BOARD_RGBLED_COM2_PIN 2 // RGB LED COM2 pin +#define BOARD_RGBLED_COM3_PORT gpioPortI // RGB LED COM3 port +#define BOARD_RGBLED_COM3_PIN 3 // RGB LED COM3 pin void rgb_led_init(void); void rgb_led_deinit(void); diff --git a/app/bluetooth/example/soc_thunderboard/brd4166a/rgbled.c b/app/bluetooth/example/soc_thunderboard/brd4166a/rgbled.c index 00b40a97f54..f15961def3f 100644 --- a/app/bluetooth/example/soc_thunderboard/brd4166a/rgbled.c +++ b/app/bluetooth/example/soc_thunderboard/brd4166a/rgbled.c @@ -3,7 +3,7 @@ * @brief RGB LED driver for BRD4166A ******************************************************************************* * # License - * Copyright 2020 Silicon Laboratories Inc. www.silabs.com + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com ******************************************************************************* * * SPDX-License-Identifier: Zlib @@ -28,9 +28,10 @@ * ******************************************************************************/ -#include "sl_simple_rgbw_pwm_led_instances.h" -#include "sl_simple_rgbw_pwm_led.h" #include "em_gpio.h" +#include "sl_simple_rgb_pwm_led_instances.h" +#include "sl_simple_rgb_pwm_led.h" +#include "app_log.h" #include "board.h" // ----------------------------------------------------------------------------- @@ -61,26 +62,31 @@ static const uint8_t light_levels[] = { static void rgb_led_enable(bool enable, uint8_t mask) { - if ( ( (mask != 0) && (enable == true) ) || ( ( (mask & 0xf) == 0xf) && (enable == false) ) ) { - if ( enable ) { - GPIO_PinOutSet(BOARD_RGBLED_PWR_EN_PORT, BOARD_RGBLED_PWR_EN_PIN); - } else { - GPIO_PinOutClear(BOARD_RGBLED_PWR_EN_PORT, BOARD_RGBLED_PWR_EN_PIN); - } + // Make sure the mask corresponds to the RGB LEDs of the board. + if (mask != (mask & BOARD_RGBLED_MASK)) { + mask = mask & BOARD_RGBLED_MASK; + app_log_error("Undefined RGB LED is trying to be set." APP_LOG_NL); + } + + if ((mask != 0) && enable) { + // Enable RGB LED power if any of the LEDs are enabled. + GPIO_PinOutSet(BOARD_RGBLED_PWR_EN_PORT, BOARD_RGBLED_PWR_EN_PIN); + } else if ((mask == BOARD_RGBLED_MASK) && !enable) { + // Disable RGB LED power if all of the LEDs are disabled. + GPIO_PinOutClear(BOARD_RGBLED_PWR_EN_PORT, BOARD_RGBLED_PWR_EN_PIN); } - int i; - uint8_t pins[4] = { BOARD_RGBLED_COM0_PIN, - BOARD_RGBLED_COM1_PIN, - BOARD_RGBLED_COM2_PIN, - BOARD_RGBLED_COM3_PIN }; + uint8_t pins[BOARD_RGBLED_COUNT] = { BOARD_RGBLED_COM0_PIN, + BOARD_RGBLED_COM1_PIN, + BOARD_RGBLED_COM2_PIN, + BOARD_RGBLED_COM3_PIN }; - for ( i = 0; i < 4; i++ ) { - if ( ( (mask >> i) & 1) == 1 ) { - if ( enable ) { - GPIO_PinOutSet(BOARD_RGBLED_COM_PORT, pins[3 - i]); + for (int i = 0; i < BOARD_RGBLED_COUNT; i++) { + if (((1 << i) & mask) != 0) { + if (enable) { + GPIO_PinOutSet(BOARD_RGBLED_COM_PORT, pins[i]); } else { - GPIO_PinOutClear(BOARD_RGBLED_COM_PORT, pins[3 - i]); + GPIO_PinOutClear(BOARD_RGBLED_COM_PORT, pins[i]); } } } @@ -93,21 +99,39 @@ static void rgb_led_enable(bool enable, uint8_t mask) void rgb_led_init(void) { - GPIO_PinModeSet(BOARD_RGBLED_PWR_EN_PORT, BOARD_RGBLED_PWR_EN_PIN, gpioModePushPull, 0); - GPIO_PinModeSet(BOARD_RGBLED_COM0_PORT, BOARD_RGBLED_COM0_PIN, gpioModePushPull, 0); - GPIO_PinModeSet(BOARD_RGBLED_COM1_PORT, BOARD_RGBLED_COM1_PIN, gpioModePushPull, 0); - GPIO_PinModeSet(BOARD_RGBLED_COM2_PORT, BOARD_RGBLED_COM2_PIN, gpioModePushPull, 0); - GPIO_PinModeSet(BOARD_RGBLED_COM3_PORT, BOARD_RGBLED_COM3_PIN, gpioModePushPull, 0); + GPIO_PinModeSet(BOARD_RGBLED_PWR_EN_PORT, + BOARD_RGBLED_PWR_EN_PIN, + gpioModePushPull, + 0); + GPIO_PinModeSet(BOARD_RGBLED_COM0_PORT, + BOARD_RGBLED_COM0_PIN, + gpioModePushPull, + 0); + GPIO_PinModeSet(BOARD_RGBLED_COM1_PORT, + BOARD_RGBLED_COM1_PIN, + gpioModePushPull, + 0); + GPIO_PinModeSet(BOARD_RGBLED_COM2_PORT, + BOARD_RGBLED_COM2_PIN, + gpioModePushPull, + 0); + GPIO_PinModeSet(BOARD_RGBLED_COM3_PORT, + BOARD_RGBLED_COM3_PIN, + gpioModePushPull, + 0); } void rgb_led_deinit(void) { - rgb_led_enable(false, 0xf); + rgb_led_enable(false, BOARD_RGBLED_MASK); } void rgb_led_set(uint8_t m, uint8_t r, uint8_t g, uint8_t b) { - rgb_led_enable(false, ~m); + rgb_led_enable(false, (~m & BOARD_RGBLED_MASK)); rgb_led_enable(true, m); - sl_led_set_rgbw_color(&sl_led_rgb, light_levels[r], light_levels[g], light_levels[b], 0); + sl_led_set_rgb_color(&sl_led_rgb, + light_levels[r], + light_levels[g], + light_levels[b]); } diff --git a/app/bluetooth/example/soc_thunderboard/brd4166a/sl_simple_rgb_pwm_led_led_rgb_config.h b/app/bluetooth/example/soc_thunderboard/brd4166a/sl_simple_rgb_pwm_led_led_rgb_config.h new file mode 100644 index 00000000000..ef7bc740604 --- /dev/null +++ b/app/bluetooth/example/soc_thunderboard/brd4166a/sl_simple_rgb_pwm_led_led_rgb_config.h @@ -0,0 +1,99 @@ +/***************************************************************************//** + * @file + * @brief Simple RGB PWM Led Driver Configuration + ******************************************************************************* + * # License + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com + ******************************************************************************* + * + * SPDX-License-Identifier: Zlib + * + * The licensor of this software is Silicon Laboratories Inc. + * + * This software is provided 'as-is', without any express or implied + * warranty. In no event will the authors be held liable for any damages + * arising from the use of this software. + * + * Permission is granted to anyone to use this software for any purpose, + * including commercial applications, and to alter it and redistribute it + * freely, subject to the following restrictions: + * + * 1. The origin of this software must not be misrepresented; you must not + * claim that you wrote the original software. If you use this software + * in a product, an acknowledgment in the product documentation would be + * appreciated but is not required. + * 2. Altered source versions must be plainly marked as such, and must not be + * misrepresented as being the original software. + * 3. This notice may not be removed or altered from any source distribution. + * + ******************************************************************************/ + +#ifndef SL_SIMPLE_RGB_PWM_LED_LED_RGB_CONFIG_H +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_CONFIG_H + +// <<< Use Configuration Wizard in Context Menu >>> + +// Simple RGB PWM LED Configuration +// PWM frequency [Hz] +// Sets the frequency of the PWM signal +// 0 = Don't care +// Default: 10000 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_FREQUENCY 10000 + +// PWM resolution <2-65536> +// Specifies the PWM (dimming) resolution. I.e. if you want a +// dimming resolution that takes the input values from 0 to 99, +// set this value to 100 +// Default: 256 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RESOLUTION 256 + +// Red LED Polarity +// Active low +// Active high +// Default: SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_HIGH +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RED_POLARITY SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_HIGH + +// Green LED Polarity +// Active low +// Active high +// Default: SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_HIGH +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_GREEN_POLARITY SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_HIGH + +// Blue LED Polarity +// Active low +// Active high +// Default: SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_HIGH +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_BLUE_POLARITY SL_SIMPLE_RGB_PWM_LED_POLARITY_ACTIVE_HIGH +// end led configuration + +// <<< end of configuration section >>> + +// <<< sl:start pin_tool >>> + +// SL_SIMPLE_RGB_PWM_LED_LED_RGB +// $[TIMER_SL_SIMPLE_RGB_PWM_LED_LED_RGB] +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_PERIPHERAL TIMER1 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_PERIPHERAL_NO 1 + +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RED_CHANNEL 0 +// TIMER0 CC0 on PD11 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RED_PORT gpioPortD +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RED_PIN 11 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_RED_LOC 19 + +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_GREEN_CHANNEL 1 +// TIMER0 CC1 on PD12 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_GREEN_PORT gpioPortD +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_GREEN_PIN 12 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_GREEN_LOC 19 + +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_BLUE_CHANNEL 2 +// TIMER0 CC2 on PD13 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_BLUE_PORT gpioPortD +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_BLUE_PIN 13 +#define SL_SIMPLE_RGB_PWM_LED_LED_RGB_BLUE_LOC 19 +// [TIMER_SL_SIMPLE_RGB_PWM_LED_LED_RGB]$ + +// <<< sl:end pin_tool >>> + +#endif // SL_SIMPLE_RGB_PWM_LED_LED_RGB_CONFIG_H diff --git a/app/bluetooth/example/soc_thunderboard/brd4166a/sl_simple_rgbw_pwm_led_led_rgb_config.h b/app/bluetooth/example/soc_thunderboard/brd4166a/sl_simple_rgbw_pwm_led_led_rgb_config.h deleted file mode 100644 index d056e6d31c2..00000000000 --- a/app/bluetooth/example/soc_thunderboard/brd4166a/sl_simple_rgbw_pwm_led_led_rgb_config.h +++ /dev/null @@ -1,111 +0,0 @@ -/***************************************************************************//** - * @file - * @brief Simple RGBW PWM Led Driver Configuration - ******************************************************************************* - * # License - * Copyright 2020 Silicon Laboratories Inc. www.silabs.com - ******************************************************************************* - * - * SPDX-License-Identifier: Zlib - * - * The licensor of this software is Silicon Laboratories Inc. - * - * This software is provided 'as-is', without any express or implied - * warranty. In no event will the authors be held liable for any damages - * arising from the use of this software. - * - * Permission is granted to anyone to use this software for any purpose, - * including commercial applications, and to alter it and redistribute it - * freely, subject to the following restrictions: - * - * 1. The origin of this software must not be misrepresented; you must not - * claim that you wrote the original software. If you use this software - * in a product, an acknowledgment in the product documentation would be - * appreciated but is not required. - * 2. Altered source versions must be plainly marked as such, and must not be - * misrepresented as being the original software. - * 3. This notice may not be removed or altered from any source distribution. - * - ******************************************************************************/ - -#ifndef SL_SIMPLE_RGBW_PWM_LED_LED_RGB_CONFIG_H -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_CONFIG_H - -// <<< Use Configuration Wizard in Context Menu >>> - -// Simple RGBW PWM LED Configuration -// PWM frequency [Hz] -// Sets the frequency of the PWM signal -// 0 = Don't care -// Default: 10000 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_FREQUENCY 10000 - -// PWM resolution <2-65536> -// Specifies the PWM (dimming) resolution. I.e. if you want a -// dimming resolution that takes the input values from 0 to 99, -// set this value to 100 -// Default: 256 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_RESOLUTION 256 - -// Red LED Polarity -// Active low -// Active high -// Default: SL_SIMPLE_RGBW_PWM_LED_POLARITY_ACTIVE_LOW -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_RED_POLARITY SL_SIMPLE_RGBW_PWM_LED_POLARITY_ACTIVE_HIGH - -// Green LED Polarity -// Active low -// Active high -// Default: SL_SIMPLE_RGBW_PWM_LED_POLARITY_ACTIVE_LOW -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_GREEN_POLARITY SL_SIMPLE_RGBW_PWM_LED_POLARITY_ACTIVE_HIGH - -// Blue LED Polarity -// Active low -// Active high -// Default: SL_SIMPLE_RGBW_PWM_LED_POLARITY_ACTIVE_LOW -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_BLUE_POLARITY SL_SIMPLE_RGBW_PWM_LED_POLARITY_ACTIVE_HIGH - -// White LED Polarity -// Active low -// Active high -// Default: SL_SIMPLE_RGBW_PWM_LED_POLARITY_ACTIVE_HIGH -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_WHITE_POLARITY SL_SIMPLE_RGBW_PWM_LED_POLARITY_ACTIVE_HIGH -// end led configuration - -// <<< end of configuration section >>> - -// <<< sl:start pin_tool >>> - -// SL_SIMPLE_RGBW_PWM_LED_LED_RGB -// $[TIMER_SL_SIMPLE_RGBW_PWM_LED_LED_RGB] -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_PERIPHERAL TIMER1 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_PERIPHERAL_NO 1 - -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_RED_CHANNEL 0 -// TIMER1 CC0 on PD11 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_RED_PORT gpioPortD -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_RED_PIN 11 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_RED_LOC 19 - -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_GREEN_CHANNEL 1 -// TIMER1 CC1 on PD12 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_GREEN_PORT gpioPortD -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_GREEN_PIN 12 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_GREEN_LOC 19 - -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_BLUE_CHANNEL 2 -// TIMER1 CC2 on PD13 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_BLUE_PORT gpioPortD -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_BLUE_PIN 13 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_BLUE_LOC 19 - -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_WHITE_CHANNEL 3 -// TIMER1 CC3 on PC6 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_WHITE_PORT gpioPortC -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_WHITE_PIN 6 -#define SL_SIMPLE_RGBW_PWM_LED_LED_RGB_WHITE_LOC 8 -// [TIMER_SL_SIMPLE_RGBW_PWM_LED_LED_RGB]$ - -// <<< sl:end pin_tool >>> - -#endif // SL_SIMPLE_RGBW_PWM_LED_LED_RGB_CONFIG_H diff --git a/app/bluetooth/example/soc_thunderboard/brd4184a/board.h b/app/bluetooth/example/soc_thunderboard/brd4184a/board.h index af547226816..d7fc65e5de5 100644 --- a/app/bluetooth/example/soc_thunderboard/brd4184a/board.h +++ b/app/bluetooth/example/soc_thunderboard/brd4184a/board.h @@ -3,7 +3,7 @@ * @brief Board HW abstraction header for BRD4184A ******************************************************************************* * # License - * Copyright 2020 Silicon Laboratories Inc. www.silabs.com + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com ******************************************************************************* * * SPDX-License-Identifier: Zlib @@ -31,6 +31,17 @@ #ifndef BOARD_H #define BOARD_H -#define BOARD_BUTTON0_EM4WUEN_MASK 0x08 /**< Mask to enable EM4 wake-up BTN0 */ +//-------------------------------- +#include "sl_simple_led_instances.h" + +#define ADV_LED SL_SIMPLE_LED_INSTANCE(0) +#define adv_led_turn_on() sl_led_turn_on(ADV_LED) +#define adv_led_turn_off() sl_led_turn_off(ADV_LED) +#define adv_led_toggle() sl_led_toggle(ADV_LED) + +//-------------------------------- +#define BOARD_EM4WUEN_BTN sl_button_btn0 // The button to use for EM4 wake-up +#define BOARD_EM4WUEN_NUM 3 // The EM4WU interrupt number of the chosen button. (See the Reference Manual.) +#define BOARD_EM4WUEN_MASK (1 << BOARD_EM4WUEN_NUM) // GPIO pinmask for EM4 wake-up #endif // BOARD_H diff --git a/app/bluetooth/example/soc_thunderboard/brd4184b/board.h b/app/bluetooth/example/soc_thunderboard/brd4184b/board.h index 5929f68f548..d94370243a8 100644 --- a/app/bluetooth/example/soc_thunderboard/brd4184b/board.h +++ b/app/bluetooth/example/soc_thunderboard/brd4184b/board.h @@ -3,7 +3,7 @@ * @brief Board HW abstraction header for BRD4184B ******************************************************************************* * # License - * Copyright 2020 Silicon Laboratories Inc. www.silabs.com + * Copyright 2022 Silicon Laboratories Inc. www.silabs.com ******************************************************************************* * * SPDX-License-Identifier: Zlib @@ -31,6 +31,17 @@ #ifndef BOARD_H #define BOARD_H -#define BOARD_BUTTON0_EM4WUEN_MASK 0x10 /**< Mask to enable EM4 wake-up BTN0 */ +//-------------------------------- +#include "sl_simple_led_instances.h" + +#define ADV_LED SL_SIMPLE_LED_INSTANCE(0) +#define adv_led_turn_on() sl_led_turn_on(ADV_LED) +#define adv_led_turn_off() sl_led_turn_off(ADV_LED) +#define adv_led_toggle() sl_led_toggle(ADV_LED) + +//-------------------------------- +#define BOARD_EM4WUEN_BTN sl_button_btn0 // The button to use for EM4 wake-up +#define BOARD_EM4WUEN_NUM 4 // The EM4WU interrupt number of the chosen button. (See the Reference Manual.) +#define BOARD_EM4WUEN_MASK (1 << BOARD_EM4WUEN_NUM) // GPIO pinmask for EM4 wake-up #endif // BOARD_H diff --git a/app/bluetooth/example/soc_thunderboard/gatt_configuration_brd2601b.btconf b/app/bluetooth/example/soc_thunderboard/gatt_configuration_brd2601b.btconf new file mode 100644 index 00000000000..a5ee81fa666 --- /dev/null +++ b/app/bluetooth/example/soc_thunderboard/gatt_configuration_brd2601b.btconf @@ -0,0 +1,70 @@ + + + + + + Abstract: The generic_access service contains generic information about the device. All available Characteristics are readonly. + + + + + Dev Kit #00000 + + + + + + Abstract: The external appearance of this device. The values are composed of a category (10-bits) and sub-categories (6-bits). + 0000 + + + + + + + Abstract: The Device Information Service exposes manufacturer and/or vendor information about a device. Summary: This service exposes manufacturer information about a device. The Device Information Service is instantiated as a Primary Service. Only one instance of the Device Information Service is exposed on a device. + + + + Abstract: The value of this characteristic is a UTF-8 string representing the name of the manufacturer of the device. + Silicon Laboratories + + + + + + Abstract: The value of this characteristic is a UTF-8 string representing the model number assigned by the device vendor. + BRD2601B + + + + + + Abstract: The value of this characteristic is a variable-length UTF-8 string representing the serial number for a particular instance of the device. + 1234 + + + + + + Summary: The value of this characteristic is a UTF-8 string representing the hardware revision for the hardware within the device. + A00 + + + + + + Summary: The value of this characteristic is a UTF-8 string representing the firmware revision for the firmware within the device. + 3.1.0 + + + + + + Abstract: The SYSTEM ID characteristic consists of a structure with two fields. The first field are the LSOs and the second field contains the MSOs. This is a 64-bit structure which consists of a 40-bit manufacturer-defined identifier concatenated with a 24 bit unique Organizationally Unique Identifier (OUI). The OUI is issued by the IEEE Registration Authority (http://standards.ieee.org/regauth/index.html) and is required to be used in accordance with IEEE Standard 802-2001.6 while the least significant 40 bits are manufacturer defined. If System ID generated based on a Bluetooth Device Address, it is required to be done as follows. System ID and the Bluetooth Device Address have a very similar structure: a Bluetooth Device Address is 48 bits in length and consists of a 24 bit Company Assigned Identifier (manufacturer defined identifier) concatenated with a 24 bit Company Identifier (OUI). In order to encapsulate a Bluetooth Device Address as System ID, the Company Identifier is concatenated with 0xFFFE followed by the Company Assigned Identifier of the Bluetooth Address. For more guidelines related to EUI-64, refer to http://standards.ieee.org/develop/regauth/tut/eui64.pdf. Examples: If the system ID is based of a Bluetooth Device Address with a Company Identifier (OUI) is 0x123456 and the Company Assigned Identifier is 0x9ABCDE, then the System Identifier is required to be 0x123456FFFE9ABCDE. + ffffffffffffffff + + + + + diff --git a/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4166a.slcp b/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4166a.slcp index fbdd0c29818..1a2cea3b74c 100644 --- a/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4166a.slcp +++ b/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4166a.slcp @@ -3,7 +3,7 @@ package: Bluetooth label: Bluetooth - SoC Thunderboard Sense 2 description: > Demonstrates the features of the Thunderboard Sense 2 Kit. - This can be tested with the Thunderboard mobile app. + This can be tested with the EFR Connect mobile app. category: Bluetooth Examples quality: production @@ -62,7 +62,7 @@ component: instance: - btn0 - btn1 - - id: simple_rgbw_pwm_led + - id: simple_rgb_pwm_led instance: - led_rgb @@ -75,14 +75,14 @@ source: include: - path: . file_list: - - path: advertise.h - - path: app.h + - path: advertise.h + - path: app.h - path: brd4166a file_list: - - path: board.h + - path: board.h readme: - - path: ../../documentation/example/soc_thunderboard/readme.html + - path: ../../documentation/example/soc_thunderboard/readme.md config_file: - override: @@ -91,10 +91,10 @@ config_file: path: gatt_configuration_brd4166a.btconf directory: btconf - override: - component: simple_rgbw_pwm_led - file_id: simple_rgbw_pwm_led_config + component: simple_rgb_pwm_led + file_id: simple_rgb_pwm_led_config instance: led_rgb - path: brd4166a/sl_simple_rgbw_pwm_led_led_rgb_config.h + path: brd4166a/sl_simple_rgb_pwm_led_led_rgb_config.h other_file: - path: ../../script/create_bl_files.bat @@ -137,5 +137,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration_brd4166a.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4184a.slcp b/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4184a.slcp index b59407c7b75..d4790952a7c 100644 --- a/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4184a.slcp +++ b/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4184a.slcp @@ -3,7 +3,7 @@ package: Bluetooth label: Bluetooth - SoC Thunderboard EFR32BG22 (BRD4184A) description: > Demonstrates the features of the Thunderboard EFR32BG22 Kit. - This can be tested with the Thunderboard mobile app. + This can be tested with the EFR Connect mobile app. category: Bluetooth Examples quality: production @@ -62,14 +62,14 @@ source: include: - path: . file_list: - - path: advertise.h - - path: app.h + - path: advertise.h + - path: app.h - path: brd4184a file_list: - - path: board.h + - path: board.h readme: - - path: ../../documentation/example/soc_thunderboard/readme.html + - path: ../../documentation/example/soc_thunderboard/readme.md config_file: - override: @@ -119,5 +119,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration_brd4184a.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4184b.slcp b/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4184b.slcp index e3e1f73ab6b..a62474dd024 100644 --- a/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4184b.slcp +++ b/app/bluetooth/example/soc_thunderboard/soc_thunderboard_brd4184b.slcp @@ -3,7 +3,7 @@ package: Bluetooth label: Bluetooth - SoC Thunderboard EFR32BG22 (BRD4184B) description: > Demonstrates the features of the Thunderboard EFR32BG22 Kit. - This can be tested with the Thunderboard mobile app. + This can be tested with the EFR Connect mobile app. category: Bluetooth Examples quality: production @@ -64,14 +64,14 @@ source: include: - path: . file_list: - - path: advertise.h - - path: app.h + - path: advertise.h + - path: app.h - path: brd4184b file_list: - - path: board.h + - path: board.h readme: - - path: ../../documentation/example/soc_thunderboard/readme.html + - path: ../../documentation/example/soc_thunderboard/readme.md config_file: - override: @@ -121,5 +121,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration_brd4184b.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example/soc_thunderboard/soc_xg24_dev_kit_brd2601b.slcp b/app/bluetooth/example/soc_thunderboard/soc_xg24_dev_kit_brd2601b.slcp new file mode 100644 index 00000000000..6344661d9f7 --- /dev/null +++ b/app/bluetooth/example/soc_thunderboard/soc_xg24_dev_kit_brd2601b.slcp @@ -0,0 +1,133 @@ +project_name: soc_xg24_dev_kit_brd2601b +package: Bluetooth +label: Bluetooth - SoC EFR32xG24 Dev Kit (BRD2601B) +description: > + Demonstrates the features of the EFR32xG24 Dev Kit Board. + This can be tested with the EFR Connect mobile app. +category: Bluetooth Examples +quality: production + +component: + - id: brd2601b + - id: bluetooth_stack + - id: gatt_configuration + - id: bluetooth_feature_advertiser + - id: bluetooth_feature_connection + - id: bluetooth_feature_gatt + - id: bluetooth_feature_gatt_server + - id: bluetooth_feature_scanner + - id: bluetooth_feature_sm + - id: bluetooth_feature_system + - id: ota_dfu + - id: bootloader_interface + - id: rail_util_pti + - id: app_log + - id: app_assert + - id: component_catalog + - id: iostream_recommended_stream + - id: iostream_retarget_stdio + - id: printf + - id: simple_timer + - id: mpu + - id: power_supply + + - id: gatt_service_aio + - id: gatt_service_battery + - id: gatt_service_hall + - id: gatt_service_imu + - id: gatt_service_lux + - id: gatt_service_pressure + - id: gatt_service_rgb + - id: gatt_service_rht + - id: gatt_service_sound + - id: sensor_hall + - id: sensor_imu + - id: sensor_lux + - id: sensor_pressure + - id: sensor_rht + - id: sensor_sound + + - id: i2cspm + instance: + - sensor + - id: simple_button + instance: + - btn0 + - btn1 + - id: simple_rgb_pwm_led + instance: + - led_rgb + +source: + - path: advertise.c + - path: app.c + - path: main.c + - path: brd2601b/rgbled.c + +include: + - path: . + file_list: + - path: advertise.h + - path: app.h + - path: brd2601b + file_list: + - path: board.h + +readme: + - path: ../../documentation/example/soc_thunderboard/readme.md + +config_file: + - override: + component: gatt_configuration + file_id: gatt_configuration_file_id + path: gatt_configuration_brd2601b.btconf + directory: btconf + - override: + component: simple_rgb_pwm_led + file_id: simple_rgb_pwm_led_config + instance: led_rgb + path: brd2601b/sl_simple_rgb_pwm_led_led_rgb_config.h + +other_file: + - path: ../../script/create_bl_files.bat + - path: ../../script/create_bl_files.sh + - path: ../../documentation/example/soc_thunderboard/readme_img0.png + folder: images + - path: ../../documentation/example/soc_thunderboard/readme_img1.png + folder: images + - path: ../../documentation/example/soc_thunderboard/readme_img2.png + folder: images + - path: ../../documentation/example/soc_thunderboard/readme_img3.png + folder: images + - path: ../../documentation/example/soc_thunderboard/readme_img4.png + folder: images + - path: ../../documentation/example/soc_thunderboard/readme_img5.png + folder: images + - path: ../../documentation/example/soc_thunderboard/readme_img6.png + folder: images + +configuration: + - name: SL_STACK_SIZE + value: "2752" + - name: SL_HEAP_SIZE + value: "9200" + - name: SL_BOARD_ENABLE_VCOM + value: "1" + - name: SL_BOARD_ENABLE_SENSOR_RHT + value: "1" + - name: SL_PSA_KEY_USER_SLOT_COUNT + value: "0" + condition: + - psa_crypto + - name: APP_LOG_NEW_LINE + value: "APP_LOG_NEW_LINE_RN" + +tag: + - prebuilt_demo + - hardware:board_only + +ui_hints: + highlight: + - path: config/btconf/gatt_configuration_brd2601b.btconf + - path: readme.md + focus: true diff --git a/app/bluetooth/example/soc_voice/soc_voice.slcp b/app/bluetooth/example/soc_voice/soc_voice.slcp index 57159f05d2f..837ab89de09 100644 --- a/app/bluetooth/example/soc_voice/soc_voice.slcp +++ b/app/bluetooth/example/soc_voice/soc_voice.slcp @@ -57,7 +57,7 @@ include: - path: voice.h readme: - - path: ../../documentation/example/soc_voice/readme.html + - path: ../../documentation/example/soc_voice/readme.md config_file: - override: @@ -161,5 +161,5 @@ tag: ui_hints: highlight: - path: config/btconf/gatt_configuration.btconf - - path: readme.html + - path: readme.md focus: true diff --git a/app/bluetooth/example_host/aoa_locator/config/locator_config.json b/app/bluetooth/example_host/aoa_locator/config/locator_config.json index 22ac8340fd2..2cde7e09987 100644 --- a/app/bluetooth/example_host/aoa_locator/config/locator_config.json +++ b/app/bluetooth/example_host/aoa_locator/config/locator_config.json @@ -30,7 +30,7 @@ "cteLength":20, "slotDuration":1, "reportMode":"ANGLE", - "allowlist":[ + "allowList":[ "ble-pd-AAAAAAAAAAAA", "ble-pd-BBBBBBBBBBBB" ], diff --git a/app/bluetooth/example_host/btmesh_provisioner/makefile b/app/bluetooth/example_host/btmesh_provisioner/makefile index 21afdc3e0b0..e9f0fdb639e 100644 --- a/app/bluetooth/example_host/btmesh_provisioner/makefile +++ b/app/bluetooth/example_host/btmesh_provisioner/makefile @@ -5,6 +5,8 @@ PROJECTNAME = btmesh_provisioner SDK_DIR = ../../../.. +# Disable threading as handling more than a few mesh devices can cause data loss +HOST_THREADING = 0 ################################################################################ # Components # diff --git a/app/bluetooth/example_host/positioning/app.c b/app/bluetooth/example_host/positioning/app.c index c014010e2d4..d5280282fd0 100644 --- a/app/bluetooth/example_host/positioning/app.c +++ b/app/bluetooth/example_host/positioning/app.c @@ -45,15 +45,10 @@ #include "aoa_parse.h" #include "aoa_serdes.h" #include "aoa_loc.h" -#include "aoa_corr_angles.h" +#include "angle_queue.h" #include "aoa_angle.h" #include "aoa_angle_config.h" -// Check if the configuration is valid -#if MAX_NUM_SEQUENCE_IDS > MAX_SEQUENCE_DIFF -#warning MAX_NUM_SEQUENCE_IDS > MAX_SEQUENCE_DIFF, please check the configuration. -#endif - // ----------------------------------------------------------------------------- // Private macros @@ -127,17 +122,18 @@ static const char *antenna_type_string[] = { // Private function declarations static void parse_config_file(const char *filename); static void parse_config(const char *payload); - static void on_message(mqtt_handle_t *handle, const char *topic, const char *payload); - static void subscribe_topic(char *topic_template, size_t topic_size, aoa_locator_t *loc); static void subscribe_config(void); - static sl_status_t check_config_topic(const char* topic); +static void angle_queue_on_angles_ready(aoa_id_t tag_id, + uint32_t angle_count, + aoa_angle_t *angle_list, + aoa_id_t *locator_list); /**************************************************************************//** * Application Init. @@ -192,16 +188,8 @@ void app_init(int argc, char *argv[]) app_log(USAGE, argv[0]); exit(EXIT_FAILURE); } - parse_config_file(config_file); - // Initialize correlated angle database - aoa_corr_angles_config.locator_count = aoa_loc_get_number_of_locators(); - - // Initialize locator engine - aoa_loc_config.locator_count = aoa_loc_get_number_of_locators(); - aoa_loc_init_expected_angle_count(); - app_log("Press Crtl+C to quit" APP_LOG_NL APP_LOG_NL); } @@ -225,7 +213,7 @@ void app_deinit(void) app_assert_status(sc); aoa_loc_destroy(); - aoa_corr_angles_destroy(); + angle_queue_deinit(); } /**************************************************************************//** @@ -250,6 +238,7 @@ static void parse_config(const char *payload) aoa_id_t locator_id; struct sl_rtl_loc_locator_item item; aoa_angle_config_t *angle_config; + angle_queue_config_t angle_queue_config = ANGLE_QUEUE_DEFAULT_CONFIG; float mask_min = 0; float mask_max = 0; @@ -270,8 +259,13 @@ static void parse_config(const char *payload) subscribe_config(); aoa_loc_destroy(); - aoa_corr_angles_destroy(); aoa_angle_reset_configs(); + angle_queue_deinit(); + + sc = aoa_loc_init(); + app_assert_status(sc); + + angle_queue_config.on_angles_ready = &angle_queue_on_angles_ready; app_log_info("Parsing positioning configuration:" APP_LOG_NL); app_log_nl(); @@ -308,24 +302,22 @@ static void parse_config(const char *payload) aoa_loc_config.filtering_amount); } - sc = aoa_parse_uint32_config(&aoa_corr_angles_config.sequence_id_slots, + sc = aoa_parse_uint32_config(&angle_queue_config.sequence_ids, "numberOfSequenceIds"); if (sc == SL_STATUS_OK) { - if (aoa_corr_angles_config.sequence_id_slots < 2) { - aoa_corr_angles_config.sequence_id_slots = 2; - app_log_info("Sequence id slots must be 2 or more!" APP_LOG_NL); - } app_log_info("Sequence id slots set to: %d" APP_LOG_NL, - aoa_corr_angles_config.sequence_id_slots); + angle_queue_config.sequence_ids); } - sc = aoa_parse_uint32_config(&aoa_corr_angles_config.max_sequence_diff, + sc = aoa_parse_uint32_config(&angle_queue_config.max_sequence_diff, "maximumSequenceIdDiffs"); if (sc == SL_STATUS_OK) { app_log_info("Maximum sequence id difference set to: %d" APP_LOG_NL, - aoa_corr_angles_config.max_sequence_diff); + angle_queue_config.max_sequence_diff); } + aoa_loc_config.max_sequence_diff = angle_queue_config.max_sequence_diff; + app_log_nl(); app_log_info("Parsing locator configurations:" APP_LOG_NL); while (aoa_parse_locator(locator_id, &item) == SL_STATUS_OK) { @@ -454,29 +446,35 @@ static void parse_config(const char *payload) app_assert_status(sc); } app_log_nl(); - aoa_loc_config.locator_count = aoa_loc_get_number_of_locators(); - aoa_corr_angles_config.locator_count = aoa_loc_config.locator_count; - loc_report_mode = (aoa_report_mode_t *)realloc(loc_report_mode, - aoa_loc_config.locator_count - * sizeof(aoa_report_mode_t)); - aoa_loc_init_expected_angle_count(); - - for (uint8_t i = 0; i < aoa_loc_config.locator_count; i++) { - aoa_loc_get_locator_by_index(i, &loc); - sc = aoa_parse_report_mode(&loc_report_mode[i], loc->id); - - subscribe_topic(AOA_TOPIC_ANGLE_PRINT, - sizeof(AOA_TOPIC_ANGLE_PRINT), - loc); - - subscribe_topic(AOA_TOPIC_IQ_REPORT_PRINT, - sizeof(AOA_TOPIC_IQ_REPORT_PRINT), - loc); + + // If no locator configured, just wait for MQTT config + if (0 != aoa_loc_config.locator_count) { + angle_queue_config.locator_count = aoa_loc_config.locator_count; + loc_report_mode = (aoa_report_mode_t *)realloc(loc_report_mode, + aoa_loc_config.locator_count + * sizeof(aoa_report_mode_t)); + sc = aoa_loc_finalize_config(); + app_assert_status(sc); + + for (uint32_t i = 0; i < aoa_loc_config.locator_count; i++) { + aoa_loc_get_locator_by_index(i, &loc); + sc = aoa_parse_report_mode(&loc_report_mode[i], loc->id); + + subscribe_topic(AOA_TOPIC_ANGLE_PRINT, + sizeof(AOA_TOPIC_ANGLE_PRINT), + loc); + + subscribe_topic(AOA_TOPIC_IQ_REPORT_PRINT, + sizeof(AOA_TOPIC_IQ_REPORT_PRINT), + loc); + } + sc = angle_queue_init(&angle_queue_config); + app_assert_status(sc); } app_log_nl(); - app_log_info("Locator count: %zu" APP_LOG_NL, aoa_loc_config.locator_count); + app_log_info("Locator count: %d" APP_LOG_NL, aoa_loc_config.locator_count); sc = aoa_parse_deinit(); app_assert_status(sc); @@ -554,9 +552,6 @@ static void on_message(mqtt_handle_t *handle, aoa_locator_t *locator; aoa_angle_t angle; sl_status_t sc; - aoa_corr_angles_t *correlated_angles_array; - uint32_t angle_slot = 0; - uint32_t last_updated_angle_slot; aoa_iq_report_t iq_report; int8_t samples[256]; aoa_report_mode_t report_mode = ANGLE; @@ -598,21 +593,7 @@ static void on_message(mqtt_handle_t *handle, sc, tag_id); - // Create correlated angle database for the tag - sc = aoa_corr_angles_new(tag_id, &correlated_angles_array); - app_assert_status_f(sc, - "[E: 0x%04x] Allocating memory \ - for correlated angles failed %s." APP_LOG_NL, - sc, - tag_id); app_log_info("New tag added : %s \n", tag_id); - } else { - sc = aoa_corr_angles_get_by_id(tag_id, &correlated_angles_array); - app_assert_status_f(sc, - "[E: 0x%04x] Syncronization lost \ - between correlated angles and tags %s." APP_LOG_NL, - sc, - tag_id); } if (IQ_REPORT == loc_report_mode[locator_idx]) { @@ -639,36 +620,34 @@ static void on_message(mqtt_handle_t *handle, app_assert_status(sc); } - // Add new data to the slot - sc = aoa_corr_angles_add_data(correlated_angles_array, - locator_idx, - &angle, - &angle_slot); + // Add new data to the angle queue + sc = angle_queue_push(tag->id, + locator->id, + &angle); + app_assert_status_f(sc, "[E: 0x%04x] Failed to add data \ - to the angle database %s." APP_LOG_NL, + to the angle queue %s." APP_LOG_NL, sc, tag_id); +} - // Calculate and publish position - sc = aoa_loc_calc_position(tag, - angle_slot, - correlated_angles_array, - &last_updated_angle_slot); - app_assert_status_f(sc, - "[E: 0x%04x] Failed to \ - calculate position %s." APP_LOG_NL, - sc, - tag_id); +/**************************************************************************//** + * Angles ready callback for angle queue. + *****************************************************************************/ +static void angle_queue_on_angles_ready(aoa_id_t tag_id, + uint32_t angle_count, + aoa_angle_t *angle_list, + aoa_id_t *locator_list) +{ + sl_status_t sc; - // Cleanup processed data from the angle database - sc = aoa_corr_angles_cleanup(correlated_angles_array, - last_updated_angle_slot); - app_assert_status_f(sc, - "[E: 0x%04x] Failed to cleanup \ - processed angle data %s." APP_LOG_NL, - sc, - tag_id); + sc = aoa_loc_calc_position(tag_id, + angle_count, + angle_list, + locator_list); + + app_assert_status(sc); } /**************************************************************************//** diff --git a/app/bluetooth/example_host/positioning/config/positioning_config.json b/app/bluetooth/example_host/positioning/config/positioning_config.json index c3d12b25916..2ab3e8ea71b 100644 --- a/app/bluetooth/example_host/positioning/config/positioning_config.json +++ b/app/bluetooth/example_host/positioning/config/positioning_config.json @@ -42,7 +42,7 @@ "cteLength":20, "slotDuration":1, "reportMode":"IQ", - "allowlist":[ + "allowList":[ "ble-pd-AAAAAAAAAAAA", "ble-pd-BBBBBBBBBBBB" ], @@ -118,7 +118,7 @@ "cteLength":20, "slotDuration":2, "reportMode":"ANGLE", - "allowlist":[ + "allowList":[ "ble-pd-AAAAAAAAAAAA", "ble-pd-BBBBBBBBBBBB" ], @@ -163,4 +163,4 @@ } } ] -} \ No newline at end of file +} diff --git a/app/bluetooth/example_host/positioning/makefile b/app/bluetooth/example_host/positioning/makefile index 55f5804ad20..45f09e299f7 100644 --- a/app/bluetooth/example_host/positioning/makefile +++ b/app/bluetooth/example_host/positioning/makefile @@ -27,7 +27,7 @@ include $(SDK_DIR)/app/bluetooth/component_host/aoa_angle.mk override INCLUDEPATHS += . \ $(SDK_DIR)/app/bluetooth/common_host/aoa_util \ -$(SDK_DIR)/app/bluetooth/common_host/aoa_corr_angles \ +$(SDK_DIR)/app/bluetooth/common_host/angle_queue \ $(SDK_DIR)/app/bluetooth/common_host/aoa_loc \ $(SDK_DIR)/platform/common/inc @@ -40,7 +40,7 @@ override C_SRC += \ $(SDK_DIR)/app/bluetooth/common_host/aoa_util/aoa_parse.c \ $(SDK_DIR)/app/bluetooth/common_host/aoa_util/aoa_serdes.c \ $(SDK_DIR)/app/bluetooth/common_host/aoa_util/aoa_util.c \ -$(SDK_DIR)/app/bluetooth/common_host/aoa_corr_angles/aoa_corr_angles.c \ +$(SDK_DIR)/app/bluetooth/common_host/angle_queue/angle_queue.c \ $(SDK_DIR)/app/bluetooth/common_host/aoa_loc/aoa_loc.c \ app.c \ main.c diff --git a/app/common/app_common.properties b/app/common/app_common.properties index cb2aaf608dc..25917152895 100644 --- a/app/common/app_common.properties +++ b/app/common/app_common.properties @@ -2,9 +2,9 @@ id=com.silabs.sdk.platform label=Platform description=Platform -version=4.0.0.0 +version=4.0.1.0 dependantSdkVersion=3.3.0 -prop.subLabel=Platform\\ 4.0.0.0 +prop.subLabel=Platform\\ 4.0.1.0 # General properties are prepended with "prop." prop.file.templatesFile=platform_test_templates.xml platform_alpha_templates.xml builtin_templates.xml platform_production_templates.xml platform_internal_templates.xml diff --git a/app/common/component/app_log.slcc b/app/common/component/app_log.slcc index feac3f1c290..52535bd0b4c 100644 --- a/app/common/component/app_log.slcc +++ b/app/common/component/app_log.slcc @@ -29,5 +29,8 @@ template_contribution: event: internal_app_init include: app_log.h handler: app_log_init +validation_library: + - path: ../../validation/autonumber_common.lua + name: autonumber_common validation_helper: - path: app_log_validation.lua \ No newline at end of file diff --git a/app/common/example/dci_swd_programming/app_process.c b/app/common/example/dci_swd_programming/app_process.c index 444d3d29d36..f3ee8e03eb8 100644 --- a/app/common/example/dci_swd_programming/app_process.c +++ b/app/common/example/dci_swd_programming/app_process.c @@ -1041,6 +1041,13 @@ static void print_otp_conf(void) } else { printf(" + Digital glitch detector always on: Disabled\n"); } + if (device_name[DEVICE_INDEX] > DEVICE_XG22) { + if (cmd_resp_buf[6] & SLEEP_ALIVE_MASK) { + printf(" + Keep tamper alive during sleep: Enabled\n"); + } else { + printf(" + Keep tamper alive during sleep: Disabled\n"); + } + } printf(" + Tamper reset threshold: %lu\n", cmd_resp_buf[6] >> TAMPER_RESET_SHIFT); #endif } diff --git a/app/common/example/dci_swd_programming/app_process.h b/app/common/example/dci_swd_programming/app_process.h index dccbbf577ab..40e45e0affe 100644 --- a/app/common/example/dci_swd_programming/app_process.h +++ b/app/common/example/dci_swd_programming/app_process.h @@ -190,6 +190,9 @@ typedef enum { /// Glitch detector mask #define GLITCH_DETECTOR_MASK (0x00020000) +/// Keep tamper alive during sleep mask +#define SLEEP_ALIVE_MASK (0x00040000) + /// Tamper reset threshold shift #define TAMPER_RESET_SHIFT (24) diff --git a/app/common/example/memlcd_baremetal/memlcd_baremetal.slcp b/app/common/example/memlcd_baremetal/memlcd_baremetal.slcp index cfcf37ca054..53238591ffe 100644 --- a/app/common/example/memlcd_baremetal/memlcd_baremetal.slcp +++ b/app/common/example/memlcd_baremetal/memlcd_baremetal.slcp @@ -19,7 +19,6 @@ component: - id: sl_system - id: device_init - id: board_control - - id: memlcd - id: dmd_memlcd - id: glib - id: simple_button diff --git a/app/common/example/psa_crypto_x509/app_mbedtls_x509.c b/app/common/example/psa_crypto_x509/app_mbedtls_x509.c index da2dab71fa9..0473470d929 100644 --- a/app/common/example/psa_crypto_x509/app_mbedtls_x509.c +++ b/app/common/example/psa_crypto_x509/app_mbedtls_x509.c @@ -28,7 +28,7 @@ // Static Function Declarations // ----------------------------------------------------------------------------- /***************************************************************************//** - * Callback function for mbedtls_x509_crt_verify(). + * Callback function for mbedtls_x509_crt_verify_with_profile(). * * @param data Pointer to parameter. * @param crt Certificate in the chain. @@ -467,7 +467,7 @@ void free_cert_ctx(void) // Static Function Definitions // ----------------------------------------------------------------------------- /***************************************************************************//** - * Callback function for mbedtls_x509_crt_verify(). + * Callback function for mbedtls_x509_crt_verify_with_profile(). ******************************************************************************/ static int verify_callback(void *data, mbedtls_x509_crt *crt, diff --git a/app/common/example/psa_crypto_x509/readme.html b/app/common/example/psa_crypto_x509/readme.html index 80e0d6d55e4..142452651d3 100644 --- a/app/common/example/psa_crypto_x509/readme.html +++ b/app/common/example/psa_crypto_x509/readme.html @@ -100,7 +100,7 @@

mbedtls_x509write_crt_pem
  • mbedtls_x509_crt_init
  • mbedtls_x509_crt_parse
    • -
  • mbedtls_x509_crt_verify
    • +
  • mbedtls_x509_crt_verify_with_profile
  • mbedtls_x509write_csr_free
  • mbedtls_x509_csr_free
  • mbedtls_x509write_crt_free
    • diff --git a/app/common/example/se_manager_asymmetric_key_handling/se_manager_asymmetric_key_handling.slcp b/app/common/example/se_manager_asymmetric_key_handling/se_manager_asymmetric_key_handling.slcp index 1fb87576674..62a16a985ec 100644 --- a/app/common/example/se_manager_asymmetric_key_handling/se_manager_asymmetric_key_handling.slcp +++ b/app/common/example/se_manager_asymmetric_key_handling/se_manager_asymmetric_key_handling.slcp @@ -33,6 +33,8 @@ component: - id: printf - id: iostream_retarget_stdio - id: iostream_recommended_stream +requires: + - name: device_has_semailbox configuration: - name: SL_STATUS_STRING_ENABLE_BLUETOOTH value: 0 diff --git a/app/common/example/se_manager_block_cipher/se_manager_block_cipher.slcp b/app/common/example/se_manager_block_cipher/se_manager_block_cipher.slcp index e78e5bdc681..6440df6d26c 100644 --- a/app/common/example/se_manager_block_cipher/se_manager_block_cipher.slcp +++ b/app/common/example/se_manager_block_cipher/se_manager_block_cipher.slcp @@ -33,6 +33,8 @@ component: - id: printf - id: iostream_retarget_stdio - id: iostream_recommended_stream +requires: + - name: device_has_semailbox configuration: - name: SL_STATUS_STRING_ENABLE_BLUETOOTH value: 0 diff --git a/app/common/example/se_manager_ecdh/se_manager_ecdh.slcp b/app/common/example/se_manager_ecdh/se_manager_ecdh.slcp index 2a95a2b097c..b4c972e4fc6 100644 --- a/app/common/example/se_manager_ecdh/se_manager_ecdh.slcp +++ b/app/common/example/se_manager_ecdh/se_manager_ecdh.slcp @@ -33,6 +33,8 @@ component: - id: printf - id: iostream_retarget_stdio - id: iostream_recommended_stream +requires: + - name: device_has_semailbox configuration: - name: SL_STATUS_STRING_ENABLE_BLUETOOTH value: 0 diff --git a/app/common/example/se_manager_ecjpake/se_manager_ecjpake.slcp b/app/common/example/se_manager_ecjpake/se_manager_ecjpake.slcp index c53fa9a14e0..91a03f1f8e9 100644 --- a/app/common/example/se_manager_ecjpake/se_manager_ecjpake.slcp +++ b/app/common/example/se_manager_ecjpake/se_manager_ecjpake.slcp @@ -33,6 +33,8 @@ component: - id: printf - id: iostream_retarget_stdio - id: iostream_recommended_stream +requires: + - name: device_has_semailbox configuration: - name: SL_STATUS_STRING_ENABLE_BLUETOOTH value: 0 diff --git a/app/common/example/se_manager_hash/se_manager_hash.slcp b/app/common/example/se_manager_hash/se_manager_hash.slcp index 90596d1dc7c..a98433eb7da 100644 --- a/app/common/example/se_manager_hash/se_manager_hash.slcp +++ b/app/common/example/se_manager_hash/se_manager_hash.slcp @@ -33,6 +33,8 @@ component: - id: printf - id: iostream_retarget_stdio - id: iostream_recommended_stream +requires: + - name: device_has_semailbox configuration: - name: SL_STATUS_STRING_ENABLE_BLUETOOTH value: 0 diff --git a/app/common/example/se_manager_key_provisioning/app_process.c b/app/common/example/se_manager_key_provisioning/app_process.c index d412410f18c..68ca8b6a593 100644 --- a/app/common/example/se_manager_key_provisioning/app_process.c +++ b/app/common/example/se_manager_key_provisioning/app_process.c @@ -634,11 +634,19 @@ static void print_tamper_conf(void) 1 << get_se_otp_conf_buf_ptr()->tamper_filter_period); printf(" + Activation threshold for the tamper filter: %d\n", 256 / (1 << get_se_otp_conf_buf_ptr()->tamper_filter_threshold)); - if (get_se_otp_conf_buf_ptr()->tamper_flags) { + if (get_se_otp_conf_buf_ptr()->tamper_flags + & SL_SE_TAMPER_FLAG_DGLITCH_ALWAYS_ON) { printf(" + Digital glitch detector always on: Enabled\n"); } else { printf(" + Digital glitch detector always on: Disabled\n"); } +#if (_SILICON_LABS_32B_SERIES_2_CONFIG > 2) + if (get_se_otp_conf_buf_ptr()->tamper_flags & (1UL << 2)) { + printf(" + Keep tamper alive during sleep: Enabled\n"); + } else { + printf(" + Keep tamper alive during sleep: Disabled\n"); + } +#endif printf(" + Tamper reset threshold: %d\n", get_se_otp_conf_buf_ptr()->tamper_reset_threshold); } diff --git a/app/common/example/se_manager_se_firmware_upgrade/readme.html b/app/common/example/se_manager_se_firmware_upgrade/readme.html index 447bc52fa68..2ad4b0af2cd 100644 --- a/app/common/example/se_manager_se_firmware_upgrade/readme.html +++ b/app/common/example/se_manager_se_firmware_upgrade/readme.html @@ -1,43 +1,46 @@ readme.html

    SE Manager SE Firmware Upgrade

    This example uses the SE Manager API to upgrade the SE firmware on the supported Series 2 device.

    -

    The SE upgrade firmware image must be stored to the device’s internal flash in .seu format. The latest SE firmware image (.sec and .hex) and release notes can be found in the Windows folders below (version should be v3.1 or above).

    -

    C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite<version>\util\se_release\public

    -

    The SE firmware image (.sec) can be converted to a C source file by SEGGER free utility Bin2C.exe. Copy the SE firmware image data array (discard the last NULL-0x00 character) in converted C file to se_firmware_image[] array in app_se_firmware_image.c.

    -

    The SE firmware image validation will fail if the image version is equal to or less than the current SE firmware version.

    -

    The example redirects standard I/O to the virtual serial port (VCOM) of the kit. By default, the serial port setting is 115200 bps and 8-N-1 configuration.

    -

    The example has been instrumented with code to count the number of clock cycles spent in different operations. The results are printed on the VCOM serial port console. This feature can be disabled by defining SE_MANAGER_PRINT=0 (default is 1) in the IDE setting (Preprocessor->Defined symbols).

    -

    SE Manager API

    -

    The following SE Manager APIs are used in this example:

    +

    The SE upgrade firmware image must be stored to the device’s internal flash in .seu format. The latest SE firmware image (.sec and .hex) and release notes can be found in the Windows folder below.

    +

    For GSDK v3.2 and lower:
    +C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\GSDK VERSION\util\se_release\public

    +

    For GSDK v4.0 and higher:
    +C:\Users\PC USER NAME\SimplicityStudio\SDKs\gecko_sdk\util\se_release\public

    +

    The SE firmware image (.sec) can be converted to a C source file by SEGGER free utility Bin2C.exe. Copy the SE firmware image data array (discard the last NULL-0x00 character) in converted C file to se_firmware_image[] array in app_se_firmware_image.c.

    +

    The SE firmware image validation will fail if the image version is equal to or less than the current SE firmware version.

    +

    The example redirects standard I/O to the virtual serial port (VCOM) of the kit. By default, the serial port setting is 115200 bps and 8-N-1 configuration.

    +

    The example has been instrumented with code to count the number of clock cycles spent in different operations. The results are printed on the VCOM serial port console. This feature can be disabled by defining SE_MANAGER_PRINT=0 (default is 1) in the IDE setting (Preprocessor->Defined symbols).

    +

    SE Manager API

    +

    The following SE Manager APIs are used in this example:

      -
    • sl_se_init
      • -
    • sl_se_deinit
      • -
    • sl_se_init_command_context
      • -
    • sl_se_deinit_command_context
      • -
    • sl_se_get_se_version
      • -
    • sl_se_get_upgrade_status_se_image
      • -
    • sl_se_check_se_image
      • -
    • sl_se_apply_se_image
      • -
    • sl_se_read_executed_command (VSE only)
      • -
    • sl_se_ack_command (VSE only)
      • +
    • sl_se_init
      • +
    • sl_se_deinit
      • +
    • sl_se_init_command_context
      • +
    • sl_se_deinit_command_context
      • +
    • sl_se_get_se_version
      • +
    • sl_se_get_upgrade_status_se_image
      • +
    • sl_se_check_se_image
      • +
    • sl_se_apply_se_image
      • +
    • sl_se_read_executed_command (VSE only)
      • +
    • sl_se_ack_command (VSE only)
    -

    Getting Started

    +

    Getting Started

      -
    1. Upgrade the kit’s firmware to the latest version (see Adapter Firmware under General Device Information in Simplicity Studio 5 Users Guide).
      2. -
    2. Upgrade the device’s SE firmware to the latest version (see Secure Firmware under General Device Information in Simplicity Studio 5 Users Guide).
      3. -
    3. Open any terminal program and connect to the kit’s VCOM port (if using Device Console in Simplicity Studio 5, Line terminator: must be set to None).
      4. -
    4. Create this platform example project in the Simplicity IDE (see Examples in Simplicity Studio 5 Users Guide, check Platform() checkbox to browse the platform examples).
      5. -
    5. Build the example and download it to the kit (see Simple Build and Flash Programmer in Simplicity Studio 5 Users Guide).
      6. -
    6. Run the example and follow the instructions shown on the console.
      7. +
    7. Upgrade the kit’s firmware to the latest version (see Adapter Firmware under General Device Information in Simplicity Studio 5 Users Guide).
      8. +
    8. Upgrade the device’s SE firmware to the latest version (see Secure Firmware under General Device Information in Simplicity Studio 5 Users Guide).
      9. +
    9. Open any terminal program and connect to the kit’s VCOM port (if using Device Console in Simplicity Studio 5, Line terminator: must be set to None).
      10. +
    10. Create this platform example project in the Simplicity IDE (see Examples in Simplicity Studio 5 Users Guide, check Platform() checkbox to browse the platform examples).
      11. +
    11. Build the example and download it to the kit (see Simple Build and Flash Programmer in Simplicity Studio 5 Users Guide).
      12. +
    12. Run the example and follow the instructions shown on the console.
    -

    Additional Information

    +

    Additional Information

      -
    1. The current version for HSE or VSE firmware upgrade can be found in the app_se_firmware_image.c.
      2. -
    2. For a device with VSE, a reset will be issued when running specified SE Manager APIs.
      3. -
    3. The device should disconnect from the debugger when upgrading the HSE or VSE firmware.
      4. -
    4. The default optimization level is Optimize for debugging (-Og) on Simplicity IDE and None on IAR Embedded Workbench.
      5. +
    5. The current version for HSE or VSE firmware upgrade can be found in the app_se_firmware_image.c.
      6. +
    6. For a device with VSE, a reset will be issued when running specified SE Manager APIs.
      7. +
    7. The device should disconnect from the debugger when upgrading the HSE or VSE firmware.
      8. +
    8. The default optimization level is Optimize for debugging (-Og) on Simplicity IDE and None on IAR Embedded Workbench.
    -

    Resources

    -

    SE Manager API

    -

    AN1222: Production Programming of Series 2 Devices

    +

    Resources

    +

    SE Manager API

    +

    AN1222: Production Programming of Series 2 Devices

    \ No newline at end of file diff --git a/app/common/example/se_manager_secure_debug/se_manager_secure_debug.slcp b/app/common/example/se_manager_secure_debug/se_manager_secure_debug.slcp index 9ba2d67325e..9bffcaf9b46 100644 --- a/app/common/example/se_manager_secure_debug/se_manager_secure_debug.slcp +++ b/app/common/example/se_manager_secure_debug/se_manager_secure_debug.slcp @@ -33,6 +33,8 @@ component: - id: printf - id: iostream_retarget_stdio - id: iostream_recommended_stream +requires: + - name: device_has_semailbox configuration: - name: SL_STATUS_STRING_ENABLE_BLUETOOTH value: 0 diff --git a/app/common/example/se_manager_signature/se_manager_signature.slcp b/app/common/example/se_manager_signature/se_manager_signature.slcp index 127c681c90b..4c34150e692 100644 --- a/app/common/example/se_manager_signature/se_manager_signature.slcp +++ b/app/common/example/se_manager_signature/se_manager_signature.slcp @@ -33,6 +33,8 @@ component: - id: printf - id: iostream_retarget_stdio - id: iostream_recommended_stream +requires: + - name: device_has_semailbox configuration: - name: SL_STATUS_STRING_ENABLE_BLUETOOTH value: 0 diff --git a/app/common/example/se_manager_stream_cipher/se_manager_stream_cipher.slcp b/app/common/example/se_manager_stream_cipher/se_manager_stream_cipher.slcp index 30c56571668..489b8fc7d3a 100644 --- a/app/common/example/se_manager_stream_cipher/se_manager_stream_cipher.slcp +++ b/app/common/example/se_manager_stream_cipher/se_manager_stream_cipher.slcp @@ -33,6 +33,8 @@ component: - id: printf - id: iostream_retarget_stdio - id: iostream_recommended_stream +requires: + - name: device_has_semailbox configuration: - name: SL_STATUS_STRING_ENABLE_BLUETOOTH value: 0 diff --git a/app/common/example/se_manager_symmetric_key_handling/se_manager_symmetric_key_handling.slcp b/app/common/example/se_manager_symmetric_key_handling/se_manager_symmetric_key_handling.slcp index 3039df3f72c..75fad633bd3 100644 --- a/app/common/example/se_manager_symmetric_key_handling/se_manager_symmetric_key_handling.slcp +++ b/app/common/example/se_manager_symmetric_key_handling/se_manager_symmetric_key_handling.slcp @@ -33,6 +33,8 @@ component: - id: printf - id: iostream_retarget_stdio - id: iostream_recommended_stream +requires: + - name: device_has_semailbox configuration: - name: SL_STATUS_STRING_ENABLE_BLUETOOTH value: 0 diff --git a/app/common/example/se_manager_tamper/app_process.c b/app/common/example/se_manager_tamper/app_process.c index cd7e3087f8e..2cb4e8c1075 100644 --- a/app/common/example/se_manager_tamper/app_process.c +++ b/app/common/example/se_manager_tamper/app_process.c @@ -496,16 +496,24 @@ static void print_tamper_conf(void) 1 << conf->tamper_filter_period); printf(" + Activation threshold for the tamper filter: %d\n", 256 / (1 << conf->tamper_filter_threshold)); - if (conf->tamper_flags) { + if (conf->tamper_flags & SL_SE_TAMPER_FLAG_DGLITCH_ALWAYS_ON) { printf(" + Digital glitch detector always on: Enabled\n"); } else { printf(" + Digital glitch detector always on: Disabled\n"); } +#if (_SILICON_LABS_32B_SERIES_2_CONFIG > 2) + if (get_se_otp_conf_buf_ptr()->tamper_flags & (1UL << 2)) { + printf(" + Keep tamper alive during sleep: Enabled\n"); + } else { + printf(" + Keep tamper alive during sleep: Disabled\n"); + } +#endif printf(" + Tamper reset threshold: %d\n", conf->tamper_reset_threshold); // Check tamper configuration can run on this example or not if (conf->tamper_levels[SL_SE_TAMPER_SIGNAL_FILTER_COUNTER] == SL_SE_TAMPER_LEVEL_INTERRUPT && conf->tamper_levels[SL_SE_TAMPER_SIGNAL_PRS0] == SL_SE_TAMPER_LEVEL_INTERRUPT + && conf->tamper_levels[SL_SE_TAMPER_SIGNAL_PRS1] == SL_SE_TAMPER_LEVEL_INTERRUPT && conf->tamper_levels[SL_SE_TAMPER_SIGNAL_PRS2] == SL_SE_TAMPER_LEVEL_FILTER && conf->tamper_levels[SL_SE_TAMPER_SIGNAL_PRS4] == SL_SE_TAMPER_LEVEL_RESET && conf->tamper_levels[SL_SE_TAMPER_SIGNAL_PRS5] == SL_SE_TAMPER_LEVEL_RESET diff --git a/app/common/example/se_manager_tamper/app_se_manager_tamper.c b/app/common/example/se_manager_tamper/app_se_manager_tamper.c index 13d0ccd1fe5..f4b37be528a 100644 --- a/app/common/example/se_manager_tamper/app_se_manager_tamper.c +++ b/app/common/example/se_manager_tamper/app_se_manager_tamper.c @@ -151,13 +151,8 @@ void init_tamper_prs(void) PRS_ConnectConsumer(SW_RST_TAMPER_PRS_CH, prsTypeAsync, offsetof(PRS_TypeDef, CONSUMER_SE_TAMPERSRC5)); #else -#if defined(_SILICON_LABS_32B_SERIES_2_CONFIG_5) PRS_ConnectConsumer(TAMPER_INT_PRS_CH, prsTypeAsync, offsetof(PRS_TypeDef, CONSUMER_SETAMPER_TAMPERSRC26)); -#else - PRS_ConnectConsumer(TAMPER_INT_PRS_CH, prsTypeAsync, - offsetof(PRS_TypeDef, CONSUMER_SETAMPER_TAMPERSRC25)); -#endif PRS_ConnectConsumer(TAMPER_CNT_PRS_CH, prsTypeAsync, offsetof(PRS_TypeDef, CONSUMER_SETAMPER_TAMPERSRC27)); PRS_ConnectConsumer(HW_RST_TAMPER_PRS_CH, prsTypeAsync, diff --git a/app/common/example/se_manager_tamper/app_se_manager_tamper_disable.h b/app/common/example/se_manager_tamper/app_se_manager_tamper_disable.h index fd6ed774879..c96bd9af1cc 100644 --- a/app/common/example/se_manager_tamper/app_se_manager_tamper_disable.h +++ b/app/common/example/se_manager_tamper/app_se_manager_tamper_disable.h @@ -49,10 +49,8 @@ /// Mask to disable tamper signals #if defined(_SILICON_LABS_32B_SERIES_2_CONFIG_1) #define TAMPER_DISABLE_MASK (0x00fa0000) -#elif defined(_SILICON_LABS_32B_SERIES_2_CONFIG_5) -#define TAMPER_DISABLE_MASK (0xf2000000) #else -#define TAMPER_DISABLE_MASK (0xf4000000) +#define TAMPER_DISABLE_MASK (0xf2000000) #endif /// Tamper disable ECC curve diff --git a/app/common/example/se_manager_tamper/readme.html b/app/common/example/se_manager_tamper/readme.html index 1009404a952..ac003787f64 100644 --- a/app/common/example/se_manager_tamper/readme.html +++ b/app/common/example/se_manager_tamper/readme.html @@ -418,13 +418,13 @@

    The disable tamper command simply reverts all masked tamper sources (TAMPER_DISABLE_MASK in app_se_manager_tamper_disable.h) to the hardcoded configuration (default levels in table above).

    For EFR32xG21B devices, the default value of TAMPER_DISABLE_MASK is 0x00fa0000. It restores PRS7, PRS6, PRS5, PRS4, PRS3, and PRS1 to the default level 0 (Ignore) after running the disable tamper command.

    -

    For other Series 2 Secure Vault High devices, the default value of TAMPER_DISABLE_MASK is 0xf4000000. It restores PRS6, PRS5, PRS4, PRS3, and PRS1 to the default level 0 (Ignore) after running the disable tamper command.

    +

    For other Series 2 Secure Vault High devices, the default value of TAMPER_DISABLE_MASK is 0xf2000000. It restores PRS6, PRS5, PRS4, PRS3, and PRS0 to the default level 0 (Ignore) after running the disable tamper command.

    Tamper Settings

    @@ -479,56 +479,60 @@

    SE Manager API

    -

    The following SE Manager APIs are used in this example:

    +

    SE Manager API

    +

    The following SE Manager APIs are used in this example:

      -
    • sl_se_init
      • -
    • sl_se_deinit
      • -
    • sl_se_init_command_context
      • -
    • sl_se_deinit_command_context
      • -
    • sl_se_get_reset_cause
      • -
    • sl_se_get_status
      • -
    • sl_se_read_otp
      • -
    • sl_se_init_otp
      • -
    • sl_se_validate_key
      • -
    • sl_se_get_storage_size
      • -
    • sl_se_generate_key
      • -
    • sl_se_export_public_key
      • -
    • sl_se_read_pubkey
      • -
    • sl_se_init_otp_key
      • -
    • sl_se_get_serialnumber
      • -
    • sl_se_get_challenge
      • -
    • sl_se_ecc_sign
      • -
    • sl_se_disable_tamper
      • -
    • sl_se_roll_challenge
      • +
    • sl_se_init
      • +
    • sl_se_deinit
      • +
    • sl_se_init_command_context
      • +
    • sl_se_deinit_command_context
      • +
    • sl_se_get_reset_cause
      • +
    • sl_se_get_status
      • +
    • sl_se_read_otp
      • +
    • sl_se_init_otp
      • +
    • sl_se_validate_key
      • +
    • sl_se_get_storage_size
      • +
    • sl_se_generate_key
      • +
    • sl_se_export_public_key
      • +
    • sl_se_read_pubkey
      • +
    • sl_se_init_otp_key
      • +
    • sl_se_get_serialnumber
      • +
    • sl_se_get_challenge
      • +
    • sl_se_ecc_sign
      • +
    • sl_se_disable_tamper
      • +
    • sl_se_roll_challenge
    -

    Getting Started

    +

    Getting Started

      -
    1. Upgrade the kit’s firmware to the latest version (see Adapter Firmware under General Device Information in Simplicity Studio 5 Users Guide).
      2. -
    2. Upgrade the device’s SE firmware to the latest version (see Secure Firmware under General Device Information in Simplicity Studio 5 Users Guide).
      3. -
    3. Open any terminal program and connect to the kit’s VCOM port (if using Device Console in Simplicity Studio 5, Line terminator: must be set to None).
      4. -
    4. Create this platform example project in the Simplicity IDE (see Examples in Simplicity Studio 5 Users Guide, check Platform() checkbox to browse the platform examples).
      5. -
    5. Build the example and download it to the kit (see Simple Build and Flash Programmer in Simplicity Studio 5 Users Guide).
      6. -
    6. Run the example and follow the instructions shown on the console.
      7. +
    7. Upgrade the kit’s firmware to the latest version (see Adapter Firmware under General Device Information in Simplicity Studio 5 Users Guide).
      8. +
    8. Upgrade the device’s SE firmware to the latest version (see Secure Firmware under General Device Information in Simplicity Studio 5 Users Guide).
      9. +
    9. Open any terminal program and connect to the kit’s VCOM port (if using Device Console in Simplicity Studio 5, Line terminator: must be set to None).
      10. +
    10. Create this platform example project in the Simplicity IDE (see Examples in Simplicity Studio 5 Users Guide, check Platform() checkbox to browse the platform examples).
      11. +
    11. Build the example and download it to the kit (see Simple Build and Flash Programmer in Simplicity Studio 5 Users Guide).
      12. +
    12. Run the example and follow the instructions shown on the console.
    -

    Additional Information

    +

    Additional Information

      -
    1. The hard-coded private command key is an insecure method so the user should find a way to import the signed access certificate for tamper disable.
      2. -
    2. This example does not enable the secure boot when provisioning the tamper configuration in app_se_manager_tamper.c.
      3. -
    3. The device should disconnect from the debugger when running this example.
      4. -
    4. Warning: Loading the tamper configuration and a public command key into the SE are a ONE-TIME-ONLY process. Both of these assignment operations are irrevocable and persist for the life of the device.
      5. -
    5. The default optimization level is Optimize for debugging (-Og) on Simplicity IDE and None on IAR Embedded Workbench.
      6. +
    6. The hard-coded private command key is an insecure method so the user should find a way to import the signed access certificate for tamper disable.
      7. +
    7. This example does not enable the secure boot when provisioning the tamper configuration in app_se_manager_tamper.c.
      8. +
    8. The device should disconnect from the debugger when running this example.
      9. +
    9. Warning: Loading the tamper configuration and a public command key into the SE are a ONE-TIME-ONLY process. Both of these assignment operations are irrevocable and persist for the life of the device.
      10. +
    10. The default optimization level is Optimize for debugging (-Og) on Simplicity IDE and None on IAR Embedded Workbench.
    -

    Resources

    -

    SE Manager API
    -AN1247: Anti-Tamper Protection Configuration and Use

    +

    Resources

    +

    SE Manager API<br>

    +

    AN1247: Anti-Tamper Protection Configuration and Use

    \ No newline at end of file diff --git a/app/common/example/tensorflow_model_profiler/model_profiler.cc b/app/common/example/tensorflow_model_profiler/model_profiler.cc index 72986837993..1dffcd6898c 100644 --- a/app/common/example/tensorflow_model_profiler/model_profiler.cc +++ b/app/common/example/tensorflow_model_profiler/model_profiler.cc @@ -189,7 +189,8 @@ void harvest_output_matrix(int operation_index) class SlProfiler : public tflite::MicroProfiler { public: SlProfiler() : total_cpu_cycles_(0), total_mvp_instructions_(0), - total_mvp_stall_cycles_(0), operation_index_(0) {} + total_mvp_programs_(0), total_mvp_stall_cycles_(0), + operation_index_(0) {} ~SlProfiler() override = default; @@ -202,6 +203,7 @@ class SlProfiler : public tflite::MicroProfiler { #endif #if defined(SL_CATALOG_MVP_PRESENT) sli_mvp_perfcnt_reset_all(); + sli_mvp_progcnt_reset(); #endif cpu_cycles = DWT->CYCCNT; return 0; @@ -212,23 +214,27 @@ class SlProfiler : public tflite::MicroProfiler { #if defined(SL_CATALOG_MVP_PRESENT) uint32_t mvp_instructions; uint32_t mvp_stall_cycles; + uint32_t mvp_programs; #endif cpu_cycles = DWT->CYCCNT - cpu_cycles; total_cpu_cycles_ += cpu_cycles; - sli_print_time("Execution time: ", cpu_cycles); - sli_print_ui32("CPU cycle count: ", cpu_cycles, "\n"); + sli_print_time("Execution time: ", cpu_cycles); + sli_print_ui32("CPU cycle count: ", cpu_cycles, "\n"); #if defined(SL_CATALOG_MVP_PRESENT) mvp_instructions = sli_mvp_perfcnt_get(0); if (mvp_instructions > 0) { mvp_stall_cycles = sli_mvp_perfcnt_get(1); + mvp_programs = sli_mvp_progcnt_get(); total_mvp_instructions_ += mvp_instructions; total_mvp_stall_cycles_ += mvp_stall_cycles; + total_mvp_programs_ += mvp_programs; - sli_print_ui32("MVP instructions: ", mvp_instructions, "\n"); - sli_print_ui32("MVP stall cycles: ", mvp_stall_cycles, "\n"); + sli_print_ui32("MVP instructions: ", mvp_instructions, "\n"); + sli_print_ui32("MVP stall cycles: ", mvp_stall_cycles, "\n"); + sli_print_ui32("MVP program count: ", mvp_programs, "\n"); } #endif #if defined(SL_PRINT_MATRIX_DATA) @@ -239,6 +245,7 @@ class SlProfiler : public tflite::MicroProfiler { uint32_t total_cpu_cycles(void) { return total_cpu_cycles_; } uint32_t total_mvp_instructions(void) { return total_mvp_instructions_; } + uint32_t total_mvp_programs(void) { return total_mvp_programs_; } uint32_t total_mvp_stall_cycles(void) { return total_mvp_stall_cycles_; } uint32_t operation_index(void) { return operation_index_; } @@ -246,6 +253,7 @@ class SlProfiler : public tflite::MicroProfiler { uint32_t cpu_cycles; uint32_t total_cpu_cycles_; uint32_t total_mvp_instructions_; + uint32_t total_mvp_programs_; uint32_t total_mvp_stall_cycles_; int operation_index_; TF_LITE_REMOVE_VIRTUAL_DELETE @@ -373,6 +381,7 @@ void model_profiler_process_action(void) if (total_mvp_instructions > 0) { sli_print_ui32("Total MVP instructions: ", total_mvp_instructions, "\n"); sli_print_ui32("Total MVP stall cycles: ", profiler.total_mvp_stall_cycles(), "\n"); + sli_print_ui32("Total MVP programs: ", profiler.total_mvp_programs(), "\n"); } #endif printf("--------------------------------------------\n"); diff --git a/app/common/example/usb_device_hid_micriumos/usb_device_hid_micriumos.slcp b/app/common/example/usb_device_hid_micriumos/usb_device_hid_micriumos.slcp index 3c1165e9db5..4cd43602bbb 100644 --- a/app/common/example/usb_device_hid_micriumos/usb_device_hid_micriumos.slcp +++ b/app/common/example/usb_device_hid_micriumos/usb_device_hid_micriumos.slcp @@ -25,7 +25,10 @@ component: instance: [mouse0] define: - name: DEBUG_EFM +configuration: + - name: SL_HEAP_SIZE + value: 4096 readme: - path: "readme.html" tag: - - hardware:component:usb \ No newline at end of file + - hardware:component:usb diff --git a/app/common/platform_production_demos.xml b/app/common/platform_production_demos.xml index 5e2d9817a43..f4c5ba2c93e 100644 --- a/app/common/platform_production_demos.xml +++ b/app/common/platform_production_demos.xml @@ -4,7 +4,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -13,7 +13,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -22,7 +22,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -31,7 +31,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -40,7 +40,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -49,7 +49,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -58,7 +58,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -67,7 +67,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -76,7 +76,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -85,7 +85,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -94,7 +94,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -103,7 +103,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -112,7 +112,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -121,7 +121,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -130,7 +130,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -139,7 +139,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -148,7 +148,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -157,7 +157,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -166,7 +166,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -175,7 +175,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -184,7 +184,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -193,7 +193,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -202,7 +202,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -211,7 +211,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -220,7 +220,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -229,7 +229,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -238,7 +238,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -247,7 +247,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -256,7 +256,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -265,7 +265,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -274,7 +274,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -283,7 +283,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -292,7 +292,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -301,7 +301,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -310,7 +310,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -319,7 +319,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -328,7 +328,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -337,7 +337,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -346,7 +346,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -355,7 +355,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -364,7 +364,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -373,7 +373,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -382,7 +382,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -391,7 +391,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -400,7 +400,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -409,7 +409,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -418,7 +418,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -427,7 +427,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -436,7 +436,16 @@ - + + + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). + + + + + + + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -445,7 +454,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -454,7 +463,16 @@ - + + + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). + + + + + + + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -463,7 +481,16 @@ - + + + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). + + + + + + + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -472,7 +499,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -481,7 +508,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -490,7 +517,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -499,7 +526,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -508,7 +535,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -517,7 +544,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -526,7 +553,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -535,7 +562,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -544,7 +571,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -553,7 +580,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -562,7 +589,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -571,7 +598,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -580,7 +607,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -589,7 +616,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -598,7 +625,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -607,7 +634,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -616,7 +643,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -625,7 +652,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -634,7 +661,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -643,7 +670,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -652,7 +679,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -661,7 +688,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -670,7 +697,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -679,7 +706,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -688,7 +715,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -697,7 +724,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -706,7 +733,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -715,7 +742,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -724,7 +751,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -733,7 +760,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -742,7 +769,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -751,7 +778,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -760,7 +787,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -769,7 +796,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -778,7 +805,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -787,7 +814,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -796,7 +823,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -805,7 +832,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -814,7 +841,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -823,7 +850,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -832,7 +859,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -841,7 +868,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -850,7 +877,16 @@ - + + + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). + + + + + + + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -859,7 +895,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -868,7 +904,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -877,7 +913,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -886,7 +922,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -895,7 +931,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -904,7 +940,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -913,7 +949,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -922,7 +958,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -931,7 +967,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -940,7 +976,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -949,7 +985,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -958,7 +994,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -967,7 +1003,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -976,7 +1012,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -985,7 +1021,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -994,7 +1030,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -1003,7 +1039,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -1012,7 +1048,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -1021,7 +1057,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -1030,7 +1066,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -1039,7 +1075,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -1048,7 +1084,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -1057,7 +1093,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -1066,7 +1102,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -1075,7 +1111,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). @@ -1084,7 +1120,7 @@ - + This example project demonstrates use of the Memory Liquid Crystal Display (LCD) module in a baremetal application, using Silicon Labs Graphics Library (glib). diff --git a/app/common/platform_production_templates.xml b/app/common/platform_production_templates.xml index 3a39b1ad560..9cf0e403474 100644 --- a/app/common/platform_production_templates.xml +++ b/app/common/platform_production_templates.xml @@ -5,8 +5,8 @@ - - + + @@ -18,8 +18,8 @@ - - + + @@ -31,8 +31,8 @@ - - + + @@ -44,8 +44,8 @@ - - + + @@ -57,7 +57,7 @@ - + @@ -70,7 +70,7 @@ - + @@ -83,7 +83,7 @@ - + @@ -122,8 +122,8 @@ - - + + @@ -135,8 +135,8 @@ - - + + @@ -148,7 +148,7 @@ - + @@ -161,7 +161,7 @@ - + @@ -174,7 +174,7 @@ - + @@ -187,7 +187,7 @@ - + @@ -200,7 +200,7 @@ - + @@ -213,8 +213,8 @@ - - + + @@ -226,8 +226,8 @@ - - + + @@ -239,7 +239,7 @@ - + @@ -252,7 +252,7 @@ - + @@ -265,7 +265,7 @@ - + @@ -278,7 +278,7 @@ - + @@ -291,7 +291,7 @@ - + @@ -304,7 +304,7 @@ - + @@ -317,7 +317,7 @@ - + @@ -330,8 +330,8 @@ - - + + @@ -343,8 +343,8 @@ - - + + @@ -356,8 +356,8 @@ - - + + @@ -369,8 +369,8 @@ - - + + @@ -382,8 +382,8 @@ - - + + @@ -395,8 +395,8 @@ - - + + @@ -408,8 +408,8 @@ - - + + @@ -421,8 +421,8 @@ - - + + @@ -434,8 +434,8 @@ - - + + @@ -447,8 +447,8 @@ - - + + @@ -460,8 +460,8 @@ - - + + @@ -473,8 +473,8 @@ - - + + @@ -486,8 +486,8 @@ - - + + @@ -499,7 +499,7 @@ - + @@ -512,8 +512,8 @@ - - + + @@ -525,8 +525,8 @@ - - + + @@ -538,8 +538,8 @@ - - + + @@ -551,8 +551,8 @@ - - + + @@ -564,7 +564,7 @@ - + @@ -577,7 +577,7 @@ - + @@ -590,7 +590,7 @@ - + @@ -603,7 +603,7 @@ - + @@ -616,8 +616,8 @@ - - + + @@ -629,7 +629,7 @@ - + @@ -642,8 +642,8 @@ - - + + @@ -655,8 +655,8 @@ - - + + @@ -668,8 +668,8 @@ - - + + @@ -681,7 +681,7 @@ - + @@ -707,8 +707,8 @@ - - + + @@ -720,8 +720,8 @@ - - + + @@ -733,7 +733,7 @@ - + @@ -746,7 +746,7 @@ - + @@ -759,7 +759,7 @@ - + @@ -772,7 +772,7 @@ - + @@ -785,7 +785,7 @@ - + @@ -798,7 +798,7 @@ - + @@ -811,7 +811,7 @@ - + @@ -824,8 +824,8 @@ - - + + @@ -837,7 +837,7 @@ - + @@ -850,7 +850,7 @@ - + @@ -863,8 +863,8 @@ - - + + @@ -876,8 +876,8 @@ - - + + @@ -889,8 +889,8 @@ - - + + @@ -902,8 +902,8 @@ - - + + @@ -915,8 +915,8 @@ - - + + @@ -928,8 +928,8 @@ - - + + @@ -941,8 +941,8 @@ - - + + @@ -954,8 +954,8 @@ - - + + @@ -968,7 +968,7 @@ - + @@ -980,8 +980,8 @@ - - + + @@ -994,7 +994,7 @@ - + diff --git a/app/common/util/app_log/app_log.h b/app/common/util/app_log/app_log.h index 06df586029f..d9e3ddc8210 100644 --- a/app/common/util/app_log/app_log.h +++ b/app/common/util/app_log/app_log.h @@ -38,6 +38,10 @@ #include "app_log_config.h" #include "sl_status.h" +#ifdef __cplusplus +extern "C" { +#endif + #define APP_LOG_LEVEL_CRITICAL 0 #define APP_LOG_LEVEL_ERROR 1 #define APP_LOG_LEVEL_WARNING 2 @@ -494,4 +498,8 @@ uint8_t app_log_filter_mask_get(void); #define app_log_hexdump_critical_s(separator, p_data, len) \ app_log_hexdump_level_s(APP_LOG_LEVEL_CRITICAL, separator, p_data, len) +#ifdef __cplusplus +} +#endif + #endif // APP_LOG_H diff --git a/app/common/util/app_log/app_log_validation.lua b/app/common/util/app_log/app_log_validation.lua index b50ee385193..07d2685c28b 100644 --- a/app/common/util/app_log/app_log_validation.lua +++ b/app/common/util/app_log/app_log_validation.lua @@ -5,36 +5,6 @@ component_table = { SL_IOSTREAM_TYPE_VUART = 'iostream_vuart', } --- automatic conversion of input parameters -function autonumber(input) - local base = 10 - local orig_input = input - if (type(input) == "string") then - input = input:gsub("[\(\)\"uUlL]", "") - if string.find(input,"[bxhBXH]") ~= nil then - if string.find(string.lower(input), "0b") == 1 then - input = input:gsub("[bB]","") - base = 2 - elseif string.find(string.lower(input), "0x") == 1 then - input = input:gsub("[xXhH]","") - base = 16 - end - elseif string.find(input, "0") == 1 then - base = 8 - end - elseif (type(input) == "number") then - return input - else - logit("autonumber() expects either a string or a number!") - return nil - end - local result = tonumber(input, base) - if result == nil then - logit("Configured value is not valid: \"" .. tostring(orig_input) .. "\" - modify it to a numeric value!") - end - return result - end - -- check if the choosen key is part of a set or not (no "in" operator in lua) function table_contains(set, key) if (type(set) == "table") then @@ -129,7 +99,7 @@ function check_name(project, stream_type, stream_name) end -- app_log validation script for checking IO stream validity. -local override_enabled = autonumber(slc.config('APP_LOG_OVERRIDE_DEFAULT_STREAM').value) +local override_enabled = autonumber_common.autonumber(slc.config('APP_LOG_OVERRIDE_DEFAULT_STREAM').value) if override_enabled ~= nil and override_enabled == 1 then local stream_type = slc.config('APP_LOG_STREAM_TYPE') if stream_type ~= nil then diff --git a/app/common/util/app_scheduler/app_scheduler.c b/app/common/util/app_scheduler/app_scheduler.c index 98e0a9f85a1..0977af294e2 100644 --- a/app/common/util/app_scheduler/app_scheduler.c +++ b/app/common/util/app_scheduler/app_scheduler.c @@ -148,7 +148,7 @@ sl_status_t app_scheduler_remove(app_scheduler_task_handle_t handle) * Add a periodic task to be scheduled with optional data parameter ******************************************************************************/ sl_status_t app_scheduler_add_periodic(app_scheduler_task_t task, - uint16_t period_ms, + uint32_t period_ms, void *data, size_t size, app_scheduler_task_handle_t *handle) @@ -171,6 +171,10 @@ sl_status_t app_scheduler_add_periodic(app_scheduler_task_t task, if (task == NULL) { sc = SL_STATUS_NULL_POINTER; } + // Check period + if (period_ms > sl_sleeptimer_get_max_ms32_conversion()) { + sc = SL_STATUS_INVALID_PARAMETER; + } if (sc == SL_STATUS_OK) { CORE_ENTER_CRITICAL(); @@ -208,7 +212,7 @@ sl_status_t app_scheduler_add_periodic(app_scheduler_task_t task, * Add a task to be scheduled with optional data parameter and a delay ******************************************************************************/ sl_status_t app_scheduler_add_delayed(app_scheduler_task_t task, - uint16_t delay_ms, + uint32_t delay_ms, void *data, size_t size, app_scheduler_task_handle_t *handle) @@ -228,6 +232,9 @@ sl_status_t app_scheduler_add_delayed(app_scheduler_task_t task, if (size > APP_SCHEDULER_MAX_DATA_SIZE) { sc = SL_STATUS_INVALID_PARAMETER; } + if (delay_ms > sl_sleeptimer_get_max_ms32_conversion()) { + sc = SL_STATUS_INVALID_PARAMETER; + } if (task == NULL) { sc = SL_STATUS_NULL_POINTER; } diff --git a/app/common/util/app_scheduler/app_scheduler.h b/app/common/util/app_scheduler/app_scheduler.h index 4f9180fde0e..8e725a7a237 100644 --- a/app/common/util/app_scheduler/app_scheduler.h +++ b/app/common/util/app_scheduler/app_scheduler.h @@ -98,7 +98,9 @@ sl_status_t app_scheduler_add(app_scheduler_task_t task, * Add a task to be scheduled with optional data parameter * * @param[in] task Task function to be scheduled - * @param[in] delay_ms Initial delay in ms. + * @param[in] delay_ms Initial delay in ms. The maximum value is limited by + * the value returned by + * sl_sleeptimer_get_max_ms32_conversion * @param[in] data The data that is passed to the task. * @param[in] size The size of the data. * @param[out] handle Handle of the task. NULL can be specified if @@ -111,7 +113,7 @@ sl_status_t app_scheduler_add(app_scheduler_task_t task, * @return Status of the operation. ******************************************************************************/ sl_status_t app_scheduler_add_delayed(app_scheduler_task_t task, - uint16_t delay_ms, + uint32_t delay_ms, void *data, size_t size, app_scheduler_task_handle_t *handle); @@ -120,7 +122,8 @@ sl_status_t app_scheduler_add_delayed(app_scheduler_task_t task, * Add a periodic task to be scheduled with optional data parameter * * @param[in] task Task function to be scheduled - * @param[in] period_ms Period in ms. + * @param[in] period_ms Period in ms. The maximum value is limited by the + * value returned by sl_sleeptimer_get_max_ms32_conversion * @param[in] data The data that is passed to the task. * @param[in] size The size of the data. * @param[out] handle Handle of the task @@ -133,7 +136,7 @@ sl_status_t app_scheduler_add_delayed(app_scheduler_task_t task, * @return Status of the operation. ******************************************************************************/ sl_status_t app_scheduler_add_periodic(app_scheduler_task_t task, - uint16_t period_ms, + uint32_t period_ms, void *data, size_t size, app_scheduler_task_handle_t *handle); diff --git a/app/common/validation/autonumber_common.lua b/app/common/validation/autonumber_common.lua new file mode 100644 index 00000000000..0df59325c6b --- /dev/null +++ b/app/common/validation/autonumber_common.lua @@ -0,0 +1,34 @@ +-- automatic conversion of input parameters to number +local autonumber_common = {} + +function autonumber_common.autonumber(input) + logit("Autonumber function.") + local base = 10 + local orig_input = input + if (type(input) == "string") then + input = input:gsub("[\(\)\"uUlL]", "") + if string.find(input,"[bxhBXH]") ~= nil then + if string.find(string.lower(input), "0b") == 1 then + input = input:gsub("[bB]","") + base = 2 + elseif string.find(string.lower(input), "0x") == 1 then + input = input:gsub("[xXhH]","") + base = 16 + end + elseif string.find(input, "0") == 1 then + base = 8 + end + elseif (type(input) == "number") then + return input + else + logit("autonumber() expects either a string or a number!") + return nil + end + local result = tonumber(input, base) + if result == nil then + logit("Configured value is not valid: \"" .. tostring(orig_input) .. "\" - modify it to a numeric value!") + end + return result +end + +return autonumber_common \ No newline at end of file diff --git a/app/flex/component/connect/sl_connect_sdk_ota_bootloader_test_common/sl_connect_sdk_ota_bootloader_test_common.c b/app/flex/component/connect/sl_connect_sdk_ota_bootloader_test_common/sl_connect_sdk_ota_bootloader_test_common.c index f7a7870aa04..09ef9e78ca2 100644 --- a/app/flex/component/connect/sl_connect_sdk_ota_bootloader_test_common/sl_connect_sdk_ota_bootloader_test_common.c +++ b/app/flex/component/connect/sl_connect_sdk_ota_bootloader_test_common/sl_connect_sdk_ota_bootloader_test_common.c @@ -116,9 +116,16 @@ void cli_bootloader_validate_image(sl_cli_command_arg_t *arguments) *****************************************************************************/ void cli_bootloader_flash_erase_slot(sl_cli_command_arg_t *arguments) { + if ((arguments == NULL) + || (arguments->argv == NULL) + || (arguments->argv[arguments->arg_ofs + 0] == NULL)) { + app_log_error("argument error\n"); + return; + } + uint32_t slot = sl_cli_get_argument_uint32(arguments, 0); - app_log_info("flash erasing slot %lu started\n", slot); + app_log_info("flash erasing slot %lu started\n", (long unsigned int) slot); if ( emberAfPluginBootloaderInterfaceChipEraseSlot(slot) ) { app_log_info("flash erase successful!\n"); @@ -141,6 +148,14 @@ void cli_bootloader_flash_image(sl_cli_command_arg_t *arguments) *****************************************************************************/ void cli_bootloader_flash_read(sl_cli_command_arg_t *arguments) { + if ((arguments == NULL) + || (arguments->argv == NULL) + || (arguments->argv[arguments->arg_ofs + 0] == NULL) + || (arguments->argv[arguments->arg_ofs + 1] == NULL)) { + app_log_error("argument error\n"); + return; + } + uint32_t address = sl_cli_get_argument_uint32(arguments, 0); uint8_t length = sl_cli_get_argument_uint8(arguments, 1); uint8_t buff[255]; @@ -148,7 +163,7 @@ void cli_bootloader_flash_read(sl_cli_command_arg_t *arguments) if (emberAfPluginBootloaderInterfaceRead(address, length, buff)) { app_log_info("flash read succeeded!\n"); - app_log_info("address: %lu, length: %d, data:\n", address, length); + app_log_info("address: %lu, length: %d, data:\n", (long unsigned int) address, length); for (i = 0; i < length; i++) { app_log_info("0x%x ", buff[i]); } @@ -163,6 +178,14 @@ void cli_bootloader_flash_read(sl_cli_command_arg_t *arguments) *****************************************************************************/ void cli_bootloader_flash_write(sl_cli_command_arg_t *arguments) { + if ((arguments == NULL) + || (arguments->argv == NULL) + || (arguments->argv[arguments->arg_ofs + 0] == NULL) + || (arguments->argv[arguments->arg_ofs + 1] == NULL)) { + app_log_error("argument error\n"); + return; + } + uint32_t address = sl_cli_get_argument_uint32(arguments, 0); size_t length; @@ -180,6 +203,13 @@ void cli_bootloader_flash_write(sl_cli_command_arg_t *arguments) *****************************************************************************/ void cli_bootloader_set_tag(sl_cli_command_arg_t *arguments) { + if ((arguments == NULL) + || (arguments->argv == NULL) + || (arguments->argv[arguments->arg_ofs + 0] == NULL)) { + app_log_error("argument error\n"); + return; + } + uint8_t new_image_tag = 0; new_image_tag = sl_cli_get_argument_uint8(arguments, 0); if (new_image_tag != ota_bootloader_test_image_tag) { diff --git a/app/flex/component/rail/sl_range_test_std_component/app_measurement_standard.c b/app/flex/component/rail/sl_range_test_std_component/app_measurement_standard.c index ce794b932fa..8ba230e23cc 100644 --- a/app/flex/component/rail/sl_range_test_std_component/app_measurement_standard.c +++ b/app/flex/component/rail/sl_range_test_std_component/app_measurement_standard.c @@ -48,7 +48,9 @@ #include "sl_rail_util_pa_config.h" #include "pa_curve_types_efr32.h" #include "pa_conversions_efr32.h" - +#ifdef SL_CATALOG_RAIL_UTIL_ANT_DIV_PRESENT +#include "sl_rail_util_ant_div.h" +#endif // ----------------------------------------------------------------------------- // Macros and Typedefs // ----------------------------------------------------------------------------- @@ -61,7 +63,9 @@ static void range_test_generate_remainder(uint8_t *remainder); // ----------------------------------------------------------------------------- // Global Variables // ----------------------------------------------------------------------------- - +#ifdef SL_CATALOG_RAIL_UTIL_ANT_DIV_PRESENT +RAIL_Handle_t emPhyRailHandle; +#endif // ----------------------------------------------------------------------------- // Static Variables // ----------------------------------------------------------------------------- @@ -105,6 +109,15 @@ static range_test_std_phys_t range_test_std_phys[NUM_OF_PREDEFINED_PHYS] = { .is_supported = true #else .is_supported = false +#endif + }, + { + .phy = IEEE802154_250KBPS_ANTDIV, + .protocol = PROT_IEEE802154, +#if RAIL_SUPPORTS_PROTOCOL_IEEE802154 && defined(SL_CATALOG_RAIL_UTIL_ANT_DIV_PRESENT) + .is_supported = true +#else + .is_supported = false #endif }, { @@ -278,6 +291,12 @@ void init_ranget_test_standard_phys(uint8_t* number_of_phys) if (PROT_IEEE802154 == i) { // Configure RAIL instance to run in IEEE 802.15.4 mode status = RAIL_IEEE802154_Init(rail_handles[i], &rail_ieee802154_config); +#ifdef SL_CATALOG_RAIL_UTIL_ANT_DIV_PRESENT + emPhyRailHandle = rail_handles[i]; + sl_rail_util_ant_div_init(); + sl_rail_util_ant_div_set_rx_antenna_mode(SL_RAIL_UTIL_ANTENNA_MODE_DISABLED); + sl_rail_util_ant_div_update_antenna_config(); +#endif if (status != RAIL_STATUS_NO_ERROR) { app_log_error("RAIL_IEEE802154_Init failed"); } @@ -441,7 +460,7 @@ void set_ieee_handler_to_idle(void) ******************************************************************************/ bool is_current_phy_ble(void) { - if (current_phy_standard_value() > IEEE802154_250KBPS) { + if (current_phy_standard_value() > IEEE802154_250KBPS_ANTDIV) { return true; } else { return false; @@ -485,7 +504,7 @@ void reset_payload_length_for_standard(void) ******************************************************************************/ void handle_payload_length_for_standard(void) { - if (current_phy_standard_value() == IEEE802154_250KBPS) { + if (current_phy_standard_value() == IEEE802154_250KBPS || current_phy_standard_value() == IEEE802154_250KBPS_ANTDIV) { if (range_test_settings.payload_length > IEEE802154_PAYLOAD_LEN_MAX) { reset_payload_length_for_standard(); } @@ -511,7 +530,10 @@ void print_standard_name(char *print_buffer) sprintf(print_buffer, "IEEE 802.15.4"); range_test_settings.channel = IEEE802154_CHANNEL; #endif - } else { + } else if(current_phy_standard_value() == IEEE802154_250KBPS_ANTDIV){ + sprintf(print_buffer, "IEEE 802.ANTDIV"); + range_test_settings.channel = IEEE802154_CHANNEL; + }else { switch (current_phy_standard_value()) { #if RAIL_BLE_SUPPORTS_CODED_PHY case BLE_125KBPS: @@ -545,7 +567,7 @@ void print_standard_name(char *print_buffer) ******************************************************************************/ void set_standard_phy_channel(void) { - if (current_phy_standard_value() == IEEE802154_250KBPS) { + if (current_phy_standard_value() == IEEE802154_250KBPS || current_phy_standard_value() == IEEE802154_250KBPS_ANTDIV) { range_test_settings.channel = IEEE802154_CHANNEL; } else { range_test_settings.channel = BLE_PHYSICAL_CH; @@ -564,7 +586,7 @@ range_test_packet_t* get_start_of_payload_for_standard(uint8_t* received_buffer) { range_test_packet_t* payload = NULL; uint8_t current_std_phy = current_phy_standard_value(); - if (current_std_phy == IEEE802154_250KBPS) { + if (current_std_phy == IEEE802154_250KBPS || current_std_phy == IEEE802154_250KBPS_ANTDIV) { // 1st byte is the length field (PHR) data_frame_format_t* data_frame = (data_frame_format_t *) &received_buffer[1]; payload = &data_frame->payload; @@ -699,7 +721,22 @@ void prepare_ble_advertising_channel_pdu(uint16_t packet_number, uint8_t *tx_buf void menu_set_std_phy(bool init) { if (is_current_phy_standard()) { - if (current_phy_standard_value() != IEEE802154_250KBPS) { + if (current_phy_standard_value() == IEEE802154_250KBPS ) { +#ifdef SL_CATALOG_RAIL_UTIL_ANT_DIV_PRESENT + sl_rail_util_ant_div_set_rx_antenna_mode(SL_RAIL_UTIL_ANTENNA_MODE_DISABLED); + sl_rail_util_ant_div_update_antenna_config(); +#endif + RAIL_IEEE802154_Config2p4GHzRadio(rail_handles[PROT_IEEE802154]); + }else if(current_phy_standard_value() == IEEE802154_250KBPS_ANTDIV){ +#ifdef SL_CATALOG_RAIL_UTIL_ANT_DIV_PRESENT + sl_rail_util_ant_div_set_rx_antenna_mode(SL_RAIL_UTIL_ANTENNA_MODE_DIVERSITY); + sl_rail_util_ant_div_update_antenna_config(); + RAIL_IEEE802154_Config2p4GHzRadioAntDiv(rail_handles[PROT_IEEE802154]); +#else + range_test_settings.current_phy++; + menu_set_std_phy(false); +#endif + }else{ while (true) { if (!ble_protocol_change()) { range_test_settings.current_phy++; @@ -792,7 +829,7 @@ void get_rail_standard_config_data(uint32_t *base_frequency, uint32_t *channel_s ******************************************************************************/ void get_rail_standard_channel_range(uint16_t *min, uint16_t *max) { - if (current_phy_standard_value() == IEEE802154_250KBPS) { + if (current_phy_standard_value() == IEEE802154_250KBPS || current_phy_standard_value() == IEEE802154_250KBPS_ANTDIV) { *min = IEEE802154_CHANNEL; *max = IEEE802154_CHANNEL; } else { @@ -819,6 +856,9 @@ void std_phy_list_generation(uint8_t phy_index, uint8_t *buffer, uint8_t *length case IEEE802154_250KBPS: sprintf((char*)(&buffer[*length]), "%u:IEEE 802.15.4,", phy_index); break; + case IEEE802154_250KBPS_ANTDIV: + sprintf((char*)(&buffer[*length]), "%u:IEEE 802.15.4 ANTDIV,", phy_index); + break; #endif #if RAIL_BLE_SUPPORTS_CODED_PHY case BLE_125KBPS: @@ -853,7 +893,7 @@ void std_phy_list_generation(uint8_t phy_index, uint8_t *buffer, uint8_t *length ******************************************************************************/ void get_rail_standard_payload_range(uint8_t *payload_min, uint8_t *payload_max) { - if (current_phy_standard_value() == IEEE802154_250KBPS) { + if (current_phy_standard_value() == IEEE802154_250KBPS || current_phy_standard_value() == IEEE802154_250KBPS_ANTDIV) { *payload_min = PAYLOAD_LEN_MIN; *payload_max = IEEE802154_PAYLOAD_LEN_MAX; } else { diff --git a/app/flex/component/rail/sl_range_test_std_component/app_measurement_standard.h b/app/flex/component/rail/sl_range_test_std_component/app_measurement_standard.h index fb19e5f668f..9f9a97ef35b 100644 --- a/app/flex/component/rail/sl_range_test_std_component/app_measurement_standard.h +++ b/app/flex/component/rail/sl_range_test_std_component/app_measurement_standard.h @@ -145,6 +145,7 @@ typedef struct { /// Enumeration of the Predefined PHYs. Newly added predefined PHY shall be placed before _NUM_OF_PREDEFINED_PHYS typedef enum { IEEE802154_250KBPS, ///> IEEE80215.4, 250kbps + IEEE802154_250KBPS_ANTDIV, ///> IEEE80215.4, 250kbps with ANT DIV BLE_125KBPS, ///> BLE 125kbps BLE_500KBPS, ///> BLE 500kbps BLE_1MBPS, ///> BLE 1Mbps diff --git a/app/flex/documentation/release-highlights.txt b/app/flex/documentation/release-highlights.txt index 7e671dcbbbe..8741d3ada52 100644 --- a/app/flex/documentation/release-highlights.txt +++ b/app/flex/documentation/release-highlights.txt @@ -1,6 +1,4 @@ Flex SDK 3.3.0.0 -* Added support for Z-Wave on EFR32xG23 parts -* Added support for new ZGM230 modules -* Updated the default PA curves for EFR32xG23 parts to be more accurate on Silicon Labs radio boards +- Selected quality improvements and bug fixes diff --git a/app/flex/documentation/slFlex_docContent.xml b/app/flex/documentation/slFlex_docContent.xml index 5d322159c95..1334b1b6050 100644 --- a/app/flex/documentation/slFlex_docContent.xml +++ b/app/flex/documentation/slFlex_docContent.xml @@ -1,27 +1,27 @@ - + Includes detailed information on using the Silicon Labs Gecko Bootloader with Connect. It supplements the general Gecko Bootloader implementation information provided in UG489: Silicon Labs Gecko Bootloader User's Guide. - + Describes using the Flex SDK for Wireless M-Bus development on EFR32 Wireless Geckos. Includes features and limitations as well as examples. - + Outlines how to account for the variation in output characteristics across custom boards and applications for the Silicon Labs EFR32 family of chips. - + @@ -29,7 +29,7 @@ Explains how NVM3 can be used as non-volatile data storage in various protocol implementations. - + @@ -37,7 +37,7 @@ Describes tokens and shows how to use them for non-volatile data storage in EmberZNet PRO and Silicon Labs Flex applications. - + @@ -45,7 +45,7 @@ Describes how to lock and unlock the debug access of EFR32 Gecko Series 2 devices. Many aspects of the debug access, including the secure debug unlock are described. The Debug Challenge Interface (DCI) and Secure Engine (SE) Mailbox Interface for locking and unlocking debug access are also included. - + @@ -53,7 +53,7 @@ Contains detailed information on configuring and using the Secure Boot with hardware Root of Trust and Secure Loader on Series 2 devices, including how to provision the signing key. This is a companion document to UG489: Silicon Labs Gecko Bootloader User's Guide. - + @@ -61,14 +61,14 @@ Details on programming, provisioning, and configuring Series 2 devices in production environments. Covers Secure Engine Subsystem of Series 2 devices, which runs easily upgradeable Secure Engine (SE) or Virtual Secure Engine (VSE) firmware. - + Describes the distinguishing features of different EFR32 families that are most relevant to porting proprietary wireless applications between them. Provides insight that is also helpful when selecting an initial target platform for proprietary wireless solutions. - + @@ -76,21 +76,21 @@ How to program, provision, and configure the anti-tamper module on EFR32 Series 2 devices with Secure Vault. - + Illustrates reducing power consumption in a Connect v3.x application using the sensor example. - + Describes the radio configurator GUI for RAIL framework applications in Simplicity Studio 5. With it, you can create standard or custom radio configurations on which to run your RAIL-based applications. The role of each GUI item is explained. - + @@ -98,7 +98,7 @@ How to authenticate an EFR32 Series 2 device with Secure Vault, using secure device certificates and signatures. - + @@ -106,7 +106,7 @@ How to securely "wrap" keys in EFR32 Series 2 devices with Secure Vault, so they can be stored in non-volatile storage. - + @@ -114,7 +114,7 @@ Describes how to provision and configure Series 2 devices through the DCI and SWD. - + @@ -122,7 +122,7 @@ Describes how to integrate crypto functionality into applications using PSA Crypto compared to Mbed TLS. - + @@ -130,7 +130,7 @@ Gecko Bootloader v2.x, introduced in GSDK 4.0, contains a number of changes compared to Gecko Bootloader v1.x. This document describes the differences between the versions, including how to configure the new Gecko Bootloader in Simplicity Studio 5. - + @@ -138,56 +138,56 @@ Describes how to use the simulated EEPROM in Silicon Labs' EM35x and EFR32 Series 1 platforms, gives an overview of the internal design, and discusses design considerations. You should already be familiar with the token system in the HAL. For more information on HAL and the token system, see the online HAL API documentation. - + Describes using RAILTest to evaluate radio functionality, as well as peripherals, deep sleep states, etc. With it you can fully evaluate the receiving and transmitting performance and test RF functionality of development kit hardware or custom hardware. - + Provides an overview and hyperlinks to all packaged documentation. - + Describes the differences between using Proprietary Flex SDK v2.x in Simplicity Studio 4 and using Proprietary Flex SDK v3.x in Simplicity Studio 5. - + Provides basic information on configuring, building, and installing applications using Silicon Labs Connect and RAIL, the two development paths in the Silicon Labs Proprietary Flex SDK v3.x. - + Contains a comprehensive list of APIs used to interface to the Silicon Labs Connect stack. - + Contains a comprehensive list of APIs used to interface to the Silicon Labs RAIL library. - + Lists compatibility requirements and sources for all software components in the development environment. Discusses the latest changes to the SiliconLabs Flex SDK, including added/deleted/deprecated features/API. Reviews fixed and known issues. - + @@ -195,7 +195,7 @@ A detailed overview of the changes, additions, and fixes in the Gecko Platform components. The Gecko Platform includes EMLIB, EMDRV, RAIL Library, NVM3, and the component-based infrastructure. - + @@ -203,7 +203,7 @@ Introduces some fundamental concepts of wireless networking. These concepts are referred to in other Fundamentals documents. If you are new to wireless networking, you should read this document first. - + @@ -211,7 +211,7 @@ Introduces the security concepts that must be considered when implementing an Internet of Things (IoT) system. Using the ioXt Alliance's eight security principles as a structure, it clearly delineates the solutions Silicon Labs provides to support endpoint security and what you must do outside of the Silicon Labs framework. - + @@ -219,7 +219,7 @@ Introduces bootloading for Silicon Labs networking devices. Discusses the Gecko Bootloader as well as legacy Ember and Bluetooth bootloaders, and describes the file formats used by each. - + @@ -227,21 +227,21 @@ Introduces non-volatile data storage using flash and the three different storage implementations offered for Silicon Labs microcontrollers and SoCs: Simulated EEPROM, PS Store, and NVM3. - + Describes the features and functions of the Silicon Labs Connect stack, including its device types, network topologies, and its 'building block' development methodology using plugins. - + Describes the features and functions of Silicon Labs RAIL (Radio Abstraction Interface Layer). RAIL provides an intuitive, easily-customizable radio interface layer that is designed to support proprietary or standards-based wireless protocols. - + @@ -249,7 +249,7 @@ Describes the four multiprotocol modes, discusses considerations when selecting protocols for multiprotocol implementations, and reviews the Radio Scheduler, a required component of a dynamic multiprotocol solution. - + @@ -257,7 +257,7 @@ Describes how and when to use Simplicity Commander's Command-Line Interface. - + @@ -265,77 +265,77 @@ Describes how to implement a dynamic multiprotocol solution. - + Describes the functionality available in the RAILtest application. - + Introduces the Connect User's Guide for the Flex SDK v3.x. - + Introduces the IEEE 802.15.4 standard on which Connect v3.x is based. - + Describes the architecture of the Silicon Labs Connect stack v3.x an how it implements IEEE 802.15.4. - + Describes how to use components, callbacks, and events on top of the Gecko Platform application framework to configure features and application behavior. - + Describes the process to implement a Connect-based application on top of one of the supported Real Time Operating Systems (RTOS). - + Explains standalone (serial) and application (OTA) bootloader options available for use within Connect v3.x -based applications - + Describes the features available in Connect v3.x to reduce power consumption. Using those features is described in AN1252: Building Low Power Networks with the Silicon Labs Connect Stack v3.x. - + Introduces the long-range radio profile, escribes its development, and examines underlying details that enable it to realize extended range. Instructions for using example applications are included. - + Provides an easy way to evaluate the link budget of the Wireless Gecko EFR32 devices using Silicon Labs RAIL (RAIL) by performing a range test between two nodes using Range Test, a standalone test application. The range test demo implements Packet Error Rate (PER) measurement. - + diff --git a/app/flex/esf.properties b/app/flex/esf.properties index 36c7a3c4b22..81d80cc1886 100644 --- a/app/flex/esf.properties +++ b/app/flex/esf.properties @@ -2,9 +2,8 @@ id=com.silabs.stack.flex label=Flex SDK description=Flex Software Development Kit -version=3.3.0.0 -dependantSdkVersion=3.3.0 -prop.subLabel=Flex\\ 3.3.0.0 +version=3.3.1.0 +prop.subLabel=Flex\\ 3.3.1.0 # General properties are prepended with "prop." prop.file.templatesFile=flex_production_templates.xml flex_internal_templates.xml diff --git a/app/flex/example/connect/light_switch/light_dmp/light_dmp.slcp b/app/flex/example/connect/light_switch/light_dmp/light_dmp.slcp index d15d011f7c4..fb0aa8fdb6e 100644 --- a/app/flex/example/connect/light_switch/light_dmp/light_dmp.slcp +++ b/app/flex/example/connect/light_switch/light_dmp/light_dmp.slcp @@ -34,9 +34,6 @@ component: - id: micriumos_kernel - id: sl_light_switch_core -#-------------- Restriction rules ------------------- - - id: sl_flex_restrictions - #------------Memory Protection Unit------------------- - id: mpu #---------------------- I/O -------------------------- diff --git a/app/flex/example/connect/light_switch/switch/switch.slcp b/app/flex/example/connect/light_switch/switch/switch.slcp index a4ea98674e8..8392b7ec3f8 100644 --- a/app/flex/example/connect/light_switch/switch/switch.slcp +++ b/app/flex/example/connect/light_switch/switch/switch.slcp @@ -40,8 +40,6 @@ component: - id: printf - id: iostream_recommended_stream - id: iostream_retarget_stdio -#-------------- Restriction rules ------------------- - - id: sl_flex_restrictions #------------Memory Protection Unit------------------- - id: mpu #-------------- Restriction rules ------------------- diff --git a/app/flex/example/rail/railtest/railtest.slcp b/app/flex/example/rail/railtest/railtest.slcp index 9c12902770a..f20ea5dd6fc 100644 --- a/app/flex/example/rail/railtest/railtest.slcp +++ b/app/flex/example/rail/railtest/railtest.slcp @@ -61,9 +61,16 @@ configuration: # RX Buffer Size - name: BUFFER_POOL_ALLOCATOR_POOL_SIZE value: "5" + - name: BUFFER_POOL_ALLOCATOR_BUFFER_SIZE_MAX + value: "2098" # SL_RAIL_TEST_MAX_PACKET_LENGTH==2058 + # + sizeof(RailAppEvent_t)==40 + condition: + - device_sdid_220 - name: BUFFER_POOL_ALLOCATOR_BUFFER_SIZE_MAX value: "1064" # SL_RAIL_TEST_MAX_PACKET_LENGTH==1024 # + sizeof(RailAppEvent_t)==40 + unless: + - device_sdid_220 # stdio # for all diff --git a/app/flex/example/rail/range_test/range_test.slcp b/app/flex/example/rail/range_test/range_test.slcp index 115e30ee6da..aec7b6d5b59 100644 --- a/app/flex/example/rail/range_test/range_test.slcp +++ b/app/flex/example/rail/range_test/range_test.slcp @@ -216,7 +216,7 @@ tag: - hardware: device: memory: - flash: 125 + flash: 126 ram: 19 board: rf_bands: diff --git a/app/flex/example/rail/range_test_std/range_test_std.slcp b/app/flex/example/rail/range_test_std/range_test_std.slcp index f3613676609..1ba2821fed8 100644 --- a/app/flex/example/rail/range_test_std/range_test_std.slcp +++ b/app/flex/example/rail/range_test_std/range_test_std.slcp @@ -61,6 +61,9 @@ requires: - name: sl_simple_rail_os condition: - "kernel" + - name: rail_util_ant_div + condition: + - "hardware_board_has_rfswitch" #----------------- Project files --------------------- source: @@ -134,6 +137,13 @@ configuration: value: "1" - name: SL_RAIL_UTIL_INIT_EVENT_CAL_NEEDED_INST0_ENABLE value: "1" +#------------- ANT_DIV_CONFIG settings ---------------- + - name: SL_RAIL_UTIL_ANT_DIV_RX_MODE + value: "SL_RAIL_UTIL_ANT_DIV_DIVERSITY" + - name: SL_RAIL_UTIL_ANT_DIV_TX_MODE + value: "SL_RAIL_UTIL_ANT_DIV_DISABLED" + - name: SL_RAIL_UTIL_ANT_DIV_RX_RUNTIME_PHY_SELECT + value: "0" #------------- USART settings ---------------- - name: SL_BOARD_ENABLE_VCOM value: "1" @@ -174,7 +184,7 @@ tag: - hardware: device: memory: - flash: 125 + flash: 126 ram: 20 board: rf_bands: diff --git a/app/flex/example/rail/range_test_std_dmp/range_test_std_dmp.slcp b/app/flex/example/rail/range_test_std_dmp/range_test_std_dmp.slcp index fa352bb2af8..0f7ffe2430e 100644 --- a/app/flex/example/rail/range_test_std_dmp/range_test_std_dmp.slcp +++ b/app/flex/example/rail/range_test_std_dmp/range_test_std_dmp.slcp @@ -66,6 +66,9 @@ component: #----------------- Require list ---------------------- requires: - name: kernel + - name: rail_util_ant_div + condition: + - "hardware_board_has_rfswitch" #----------------- Project files --------------------- source: @@ -145,6 +148,13 @@ configuration: value: "1" - name: SL_RAIL_UTIL_INIT_EVENT_CAL_NEEDED_INST0_ENABLE value: "1" +#------------- ANT_DIV_CONFIG settings ---------------- + - name: SL_RAIL_UTIL_ANT_DIV_RX_MODE + value: "SL_RAIL_UTIL_ANT_DIV_DIVERSITY" + - name: SL_RAIL_UTIL_ANT_DIV_TX_MODE + value: "SL_RAIL_UTIL_ANT_DIV_DISABLED" + - name: SL_RAIL_UTIL_ANT_DIV_RX_RUNTIME_PHY_SELECT + value: "0" #------------- USART settings ---------------- - name: SL_BOARD_ENABLE_VCOM value: "1" @@ -187,7 +197,7 @@ tag: - hardware: device: memory: - flash: 302 + flash: 303 ram: 53 board: rf_bands: diff --git a/app/flex/example/rail/simple_trx_std/simple_trx_std.slcp b/app/flex/example/rail/simple_trx_std/simple_trx_std.slcp index bea96caf3ed..2a1a62195b9 100644 --- a/app/flex/example/rail/simple_trx_std/simple_trx_std.slcp +++ b/app/flex/example/rail/simple_trx_std/simple_trx_std.slcp @@ -399,7 +399,7 @@ tag: - hardware: device: memory: - flash: 100 + flash: 101 ram: 8 board: rf_bands: diff --git a/app/flex/example/rail/wmbus_collector/wmbus_collector.slcp b/app/flex/example/rail/wmbus_collector/wmbus_collector.slcp index 4a1b464954b..406b3879e8c 100644 --- a/app/flex/example/rail/wmbus_collector/wmbus_collector.slcp +++ b/app/flex/example/rail/wmbus_collector/wmbus_collector.slcp @@ -184,7 +184,7 @@ tag: - hardware: device: memory: - flash: 94 + flash: 95 ram: 10 board: rf_bands: diff --git a/app/flex/flex_production_demos.xml b/app/flex/flex_production_demos.xml index 4f43e3c09f4..c630b6c8f7b 100644 --- a/app/flex/flex_production_demos.xml +++ b/app/flex/flex_production_demos.xml @@ -4,7 +4,7 @@ - + Range Test BLE and IEEE802.15.4 with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This application demonstrates over the air range of the Silicon Labs boards. 5 predefined PHYs can be used for this: BLE: 125kbps, BLE: 500kbps, BLE: 1Mbps, BLE: 2Mbps, IEEE80215.4: 250kbps. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length defined by the PHY and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given predefined PHY and inspects the packets received. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. Radio related events can be logged on UART on demand. CLI can be used to set and get configuration of the app, and to start and stop it. To get started with CLI please send 'help' with a terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -12,7 +12,7 @@ - + Range Test BLE and IEEE802.15.4 with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This application demonstrates over the air range of the Silicon Labs boards. 5 predefined PHYs can be used for this: BLE: 125kbps, BLE: 500kbps, BLE: 1Mbps, BLE: 2Mbps, IEEE80215.4: 250kbps. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length defined by the PHY and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given predefined PHY and inspects the packets received. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. Radio related events can be logged on UART on demand. CLI can be used to set and get configuration of the app, and to start and stop it. To get started with CLI please send 'help' with a terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -20,7 +20,7 @@ - + Range Test BLE and IEEE802.15.4 with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This application demonstrates over the air range of the Silicon Labs boards. 5 predefined PHYs can be used for this: BLE: 125kbps, BLE: 500kbps, BLE: 1Mbps, BLE: 2Mbps, IEEE80215.4: 250kbps. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length defined by the PHY and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given predefined PHY and inspects the packets received. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. Radio related events can be logged on UART on demand. CLI can be used to set and get configuration of the app, and to start and stop it. To get started with CLI please send 'help' with a terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -28,7 +28,7 @@ - + Range Test BLE and IEEE802.15.4 with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This application demonstrates over the air range of the Silicon Labs boards. 5 predefined PHYs can be used for this: BLE: 125kbps, BLE: 500kbps, BLE: 1Mbps, BLE: 2Mbps, IEEE80215.4: 250kbps. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length defined by the PHY and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given predefined PHY and inspects the packets received. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. Radio related events can be logged on UART on demand. CLI can be used to set and get configuration of the app, and to start and stop it. To get started with CLI please send 'help' with a terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -36,7 +36,7 @@ - + Range Test BLE and IEEE802.15.4 with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This application demonstrates over the air range of the Silicon Labs boards. 5 predefined PHYs can be used for this: BLE: 125kbps, BLE: 500kbps, BLE: 1Mbps, BLE: 2Mbps, IEEE80215.4: 250kbps. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length defined by the PHY and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given predefined PHY and inspects the packets received. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. Radio related events can be logged on UART on demand. CLI can be used to set and get configuration of the app, and to start and stop it. To get started with CLI please send 'help' with a terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -44,7 +44,7 @@ - + Range Test BLE and IEEE802.15.4 with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This application demonstrates over the air range of the Silicon Labs boards. 5 predefined PHYs can be used for this: BLE: 125kbps, BLE: 500kbps, BLE: 1Mbps, BLE: 2Mbps, IEEE80215.4: 250kbps. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length defined by the PHY and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given predefined PHY and inspects the packets received. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. Radio related events can be logged on UART on demand. CLI can be used to set and get configuration of the app, and to start and stop it. To get started with CLI please send 'help' with a terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -52,7 +52,7 @@ - + Range Test BLE and IEEE802.15.4 with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This application demonstrates over the air range of the Silicon Labs boards. 5 predefined PHYs can be used for this: BLE: 125kbps, BLE: 500kbps, BLE: 1Mbps, BLE: 2Mbps, IEEE80215.4: 250kbps. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length defined by the PHY and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given predefined PHY and inspects the packets received. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. Radio related events can be logged on UART on demand. CLI can be used to set and get configuration of the app, and to start and stop it. To get started with CLI please send 'help' with a terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -60,7 +60,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -68,7 +68,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -76,7 +76,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -84,7 +84,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -92,7 +92,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -100,7 +100,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -108,7 +108,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -116,7 +116,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -124,7 +124,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -132,7 +132,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -140,7 +140,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -148,7 +148,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -156,7 +156,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -164,7 +164,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -172,7 +172,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -180,7 +180,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -188,7 +188,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -196,7 +196,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -204,7 +204,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -212,7 +212,15 @@ - + + + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. + + + + + + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -220,7 +228,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -228,7 +236,15 @@ - + + + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. + + + + + + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -236,7 +252,15 @@ - + + + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. + + + + + + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -244,7 +268,7 @@ - + Range Test with Bluetooth connectivity. It runs on top of Micrium OS RTOS and multiprotocol RAIL. This is a customizable application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. Wireless Gecko mobile app can also be used to control this application over Bluetooth. Currently MicriumOS and FreeRTOS is supported by this sample app. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -252,7 +276,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -260,7 +284,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -268,7 +292,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -276,7 +300,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -284,7 +308,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -292,7 +316,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -300,7 +324,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -308,7 +332,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -316,7 +340,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -324,7 +348,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -332,7 +356,7 @@ - + This is a customizable Range Test Sample Application that demonstrates over the air range of the EFR32. This sample app can act as a Transmitter and a Receiver. The role can be selected in the LCD menu. Flashing this app into two separate boards makes it possible to test the features and specification of the radio. The sample also provides an example how the RAIL API can be used. A menu is displayed in the LCD, which allows the user to see the most important information about the settings and also change some of them. The left button navigates in the menu and the right button selects or changes options. The bottom line always shows what the buttons do in the particular context. In Tx Mode, the user can send packets. Packet length (7..64 bytes) and the number of packets to transmit (from 500 up to continuous) can be set. Output power can be set in the LCD menu, in 0.5dBm steps (power setpoint), between -15..+20dBm. Actual minimum and maximum power may vary in different frequencies as well as the power that is actually set by RAIL. The LCD menu informs the user about the setpoint and the actual power. In the LCD menu, the Power item displays the setpoint first, then actual value. In Rx Mode, the radio listens on the given channel and inspects the packets received. Only packets that are sent with the expected device ID, will be processed. Packet Error Rate, Bit Error Rate and RSSI of the packets is displayed to inform about the quality of the transmission. For both modes, the channel on which the Tx/Rx radio will operate and the device IDs of the transmitters and receiver radio, can be set. Radio related events can be logged on UART on demand. CLI can be used for setting and starting/stoping the application as well, to start with CLI interface send 'help' over terminal. NOTE: Due to the higher current consumption of the continuous radio usage (especially in Rx Mode), it is not recommended to power the boards from a coin cell. Instead, an USB power bank can be used if portability is needed. @@ -340,9 +364,9 @@ - + - + The purpose of the application is to demonstrate a simple wireless communication between two or more boards. In combination with the Light sample application it creates a basic switch functionality, where the light can be toggled in the Light node. After power up, the node is in SCAN state. It means the broadcast messages of the light modules can be captured. After pushing PB1 button, the closest Light module will be connected. This is called the LINK state. If the Light module has done the same procedure, light can be toggled from all the boards with pushing BP0 button diff --git a/app/flex/flex_production_templates.xml b/app/flex/flex_production_templates.xml index 76a8b117f97..3c879fd8b62 100644 --- a/app/flex/flex_production_templates.xml +++ b/app/flex/flex_production_templates.xml @@ -1,53 +1,64 @@ - + - + + + - + - + - + + + - + - + - + + + - + - + - + + + - + + - + + + @@ -55,105 +66,129 @@ + - + + + - + - + - + + + - + - + - + + + - + - + - + + + - + - + - + + + - + - + - + + + - + + - + + + - + + - + + + - + - + - + + + - + + - + + + @@ -161,97 +196,116 @@ - + - + + + - + - + - + + + - + - + - + + + - + - + - + + + - + - + - + + + - + - + - + + + - + - + - + + + - + - + - + + + - + + - + + + @@ -259,41 +313,51 @@ - + - + + + - + + - + + + - + + - + + + - + - + - + + + @@ -301,10 +365,12 @@ - + - + + + diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/XncpLedHost b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/XncpLedHost index 618abe7229d..2b4ecccef48 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/XncpLedHost and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/XncpLedHost differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/Z3Gateway b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/Z3Gateway index 1ff29e1ef17..12ffcf74b88 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/Z3Gateway and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/Z3Gateway differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/cpc-hci-bridge b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/cpc-hci-bridge index fc3cef6f53a..3bc867e941e 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/cpc-hci-bridge and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/cpc-hci-bridge differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/cpcd b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/cpcd index f6cb81df8b3..def069567ff 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/cpcd and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/cpcd differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/ot-cli b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/ot-cli index 45e6b18616f..856029b394e 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/ot-cli and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/ot-cli differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/zigbeed b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/zigbeed index 843c84bec0c..1680492e0b1 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/zigbeed and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm32v7/zigbeed differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/XncpLedHost b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/XncpLedHost index d908d03693c..1430d09b7b2 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/XncpLedHost and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/XncpLedHost differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/Z3Gateway b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/Z3Gateway index ffd841a8a96..0dc5de565d2 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/Z3Gateway and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/Z3Gateway differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/cpc-hci-bridge b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/cpc-hci-bridge index b92b5ea1d99..53f4869ef08 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/cpc-hci-bridge and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/cpc-hci-bridge differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/cpcd b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/cpcd index f1f46c61274..66ff1604f24 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/cpcd and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/cpcd differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/ot-cli b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/ot-cli index d9f9e9fa8fc..4bdb10ccead 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/ot-cli and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/ot-cli differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/zigbeed b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/zigbeed index 39e5a9cced9..7c62f50af24 100644 Binary files a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/zigbeed and b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/bin_arm64v8/zigbeed differ diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4158a-rcp-spi-802154.s37 b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4158a-rcp-spi-802154.s37 index 83242736d38..4e2ed3ec378 100644 --- a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4158a-rcp-spi-802154.s37 +++ b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4158a-rcp-spi-802154.s37 @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:113ace0afaa1746df97af48e844531ea1aaec0932721b8790cd66c24f256f8c5 -size 598336 +oid sha256:b44b2ba245e70067f022820e01459e9acee69f049f300a6e1ca0d8b87d7d0b1e +size 598614 diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4158a-rcp-uart-802154.s37 b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4158a-rcp-uart-802154.s37 index 227e7d42de3..e3a236c3c7e 100644 --- a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4158a-rcp-uart-802154.s37 +++ b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4158a-rcp-uart-802154.s37 @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:1515ccd3884a97244ada52ac3861bc432af7073e8d9fda11862c1a136b765523 -size 572878 +oid sha256:fac593054f8277d6c0675318d545e8d69c4a362fd02cbc36849eea87da6a7107 +size 573506 diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4161a-rcp-spi-802154.s37 b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4161a-rcp-spi-802154.s37 index ed36940727f..5ffff224d9c 100644 --- a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4161a-rcp-spi-802154.s37 +++ b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4161a-rcp-spi-802154.s37 @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:a58c7581bc239561d0a8a855463b0ad5c522fd9204e0fe9788c228f5517f8e1f -size 604432 +oid sha256:690c3a08971d4bd353b4f536e9bc3a2a5809d8962b4bf5ed7372e3df1ce49d4e +size 604724 diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4161a-rcp-uart-802154.s37 b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4161a-rcp-uart-802154.s37 index 6eba2d01da7..1affcd1d240 100644 --- a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4161a-rcp-uart-802154.s37 +++ b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4161a-rcp-uart-802154.s37 @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:75e3faccda6a2b185479b890ab5ed87073bb34c5dc418d6dea6e1d96bc91e6f8 -size 567764 +oid sha256:5b850b8329ce99a82e59b14fd9e4bc5d363d03feccb4b843183b3a2e2bed9208 +size 568424 diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4166a-rcp-spi-802154.s37 b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4166a-rcp-spi-802154.s37 index 8abf361e9f1..95a594f82d7 100644 --- a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4166a-rcp-spi-802154.s37 +++ b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4166a-rcp-spi-802154.s37 @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:837c0adc8b22264a53ec1bf4d1521b16af6b7042fd974e45dcda865e93ff0633 -size 604248 +oid sha256:d50324f8ddc40bcce80492e94e74c7a054309e414fdafdcb89a4665283626d88 +size 604540 diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4166a-rcp-uart-802154.s37 b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4166a-rcp-uart-802154.s37 index 3d1a712c8bf..e190a8ff8e6 100644 --- a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4166a-rcp-uart-802154.s37 +++ b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/firmware/brd4166a-rcp-uart-802154.s37 @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:902cc0be7f32eb9c468dc4e74cc303aa4d36efe67c6d1c10ce9a47a876519ffa -size 567672 +oid sha256:d6a1ae2cf0181013140bda324b50048c9a8e3357f613bf1b4f6b6f52157b17bf +size 568286 diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/systemd/zigbeed-socat.service b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/systemd/zigbeed-socat.service index 8a8000e5683..9ff107ba002 100644 --- a/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/systemd/zigbeed-socat.service +++ b/app/host/multiprotocol/zigbeed/multiprotocol-container/_artifacts/systemd/zigbeed-socat.service @@ -7,7 +7,7 @@ Type=simple Restart=always RestartSec=1 User=root -ExecStart=/usr/bin/socat -x -v pty,link=/dev/ttyZigbeeNCP pty,link=/tmp/ttyZigbeeNCP +ExecStart=/usr/bin/socat -v pty,link=/dev/ttyZigbeeNCP pty,link=/tmp/ttyZigbeeNCP ExecStop=/bin/kill -WINCH ${MAINPID} PIDFile=/run/zigbeed-socat.pid StandardOutput=syslog diff --git a/app/host/multiprotocol/zigbeed/multiprotocol-container/run.sh b/app/host/multiprotocol/zigbeed/multiprotocol-container/run.sh index 42f2acbc3b4..d5b14490b83 100644 --- a/app/host/multiprotocol/zigbeed/multiprotocol-container/run.sh +++ b/app/host/multiprotocol/zigbeed/multiprotocol-container/run.sh @@ -40,17 +40,18 @@ while [[ $# -gt 0 ]]; do exit ;; -T|--ot-ctl) - docker exec -it multiprotocol service otbr start - sleep 3 - docker exec -it multiprotocol ot-ctl + docker exec -it multiprotocol systemctl start otbr + echo "OTBR started. Attempting to run ot-ctl..." + while + docker exec -it multiprotocol ot-ctl + [[ $? -eq 1 ]] + do + sleep 1 + done exit ;; -Z|--zigbee-host) - # >>>>>> Workaround for Systemd issue - docker exec -it multiprotocol service zigbeed-socat start - sleep 2 - # <<<<<< - docker exec -it multiprotocol service zigbeed start + docker exec -it multiprotocol systemctl start zigbeed sleep 3 docker exec -it multiprotocol /usr/local/bin/Z3Gateway -p ttyZigbeeNCP exit @@ -60,13 +61,7 @@ while [[ $# -gt 0 ]]; do sudo service bluetooth stop # disable bluetoothd on the host sudo systemctl mask bluetooth.service - # >>>>>> Workaround for Systemd issue - docker exec -it multiprotocol service cpc-hci-bridge start - sleep 2 - docker exec -it multiprotocol service bluetooth start - sleep 2 - # <<<<<< - docker exec -it multiprotocol service hciattach start + docker exec -it multiprotocol systemctl start hciattach docker exec -it multiprotocol bluetoothctl exit ;; @@ -105,7 +100,7 @@ if [ -e "$CPCD_CONFIG_FILE" ]; then echo "Using host's cpcd config file: $CPCD_CONFIG_FILE" RUN_ARGS+=" -v $CPCD_CONFIG_FILE:/usr/local/etc/cpcd.conf:ro" fi -RUN_ARGS+=" -v $(pwd)/log:/var/log/" # Add in logging folder +RUN_ARGS+=" -v /tmp/multiprotocol-container/log:/var/log/" # Add in logging folder RUN_ARGS+=" -v /accept_silabs_msla" # Accept the MSLA for Zigbeed RUN_ARGS+=" --privileged --cap-add SYS_ADMIN" # Add in security permissions RUN_ARGS+=" --cap-add=SYS_ADMIN --cap-add=NET_ADMIN --net=host" # Add bluetooth diff --git a/app/mcu_example/app_mcu.properties b/app/mcu_example/app_mcu.properties index 3614a99cd03..1d0c67c3999 100644 --- a/app/mcu_example/app_mcu.properties +++ b/app/mcu_example/app_mcu.properties @@ -2,10 +2,9 @@ id=com.silabs.sdk.mcu label=32-bit MCU SDK description=Silicon Labs 32-bit MCU SDK for EFM32 and EZR32 -version=6.2.0.0 -dependantSdkVersion=3.3.0 +version=6.2.1.0 supportedParts=mcu.arm.efm32.* mcu.arm.ezr32.* .*wgm16.* -prop.subLabel=MCU\\ 6.2.0.0 +prop.subLabel=MCU\\ 6.2.1.0 # General properties are prepended with "prop." prop.file.templatesFile=mcu_production_templates.xml diff --git a/app/mcu_example/documentation/release-highlights.txt b/app/mcu_example/documentation/release-highlights.txt index 2913e5499fa..51499fda09c 100644 --- a/app/mcu_example/documentation/release-highlights.txt +++ b/app/mcu_example/documentation/release-highlights.txt @@ -1,4 +1,4 @@ -32-Bit MCU SDK 6.2.0.0 -* Gecko USB has been deprecated +32-Bit MCU SDK 6.2.1.0 +- Underlying platform changes only diff --git a/app/mcu_example/mcu_production_demos.xml b/app/mcu_example/mcu_production_demos.xml index cc2cbc6315f..32d9f1f58b0 100644 --- a/app/mcu_example/mcu_production_demos.xml +++ b/app/mcu_example/mcu_production_demos.xml @@ -4,7 +4,7 @@ - + This example project demonstrates a wide range of features of the EFM32TG11 MCU and the SLSTK3301A Starter Kit. @@ -12,7 +12,7 @@ - + This example project demonstrates a wide range of features of the EFM32GG11 MCU and the SLSTK3701A Starter Kit. @@ -21,7 +21,7 @@ - + This example shows how to use the Micrium OS CANopen stack. It uses the EFM32GG11B starter kit's two CAN peripherals in external loopback mode. It requires CAN expansion board ISO-CAN-EXP REV 1.0 or REV 2.0. This example will, upon the user pressing either push buttons (BTN0, BTN1), update one entry in the CANopen object dictionary of node 1 on the 'can0' bus with a predefined value for each button. Upon changing the value, a PDO message will be triggered, which will be caught by node 2 on the 'can1' bus. Node 2 will in turn update its object dictionary with the received value. The value of the object of both nodes is continuously displayed on the LCD. @@ -30,7 +30,7 @@ - + MicriumOS Network example. This example shows how to use the Micrium OS network stack with the ETH peripheral on the EFM32GG11B starter kit. This example will initialize the RMII interface to the external PHY and setup a 100 Mbit connection. @@ -42,7 +42,7 @@ Micrium OS Support SEGGER SystemView to view the runtime behavior or a system. S - + Example usage of microphones and MicriumOS HTTP server This example shows how to sample data from the microphone and also how to stream that data on a web server using uC/HTTPs. @@ -56,7 +56,7 @@ Micrium OS Support SEGGER SystemView to view the runtime behavior or a system. S - + Hall effect demo code for the Si72xx-WD-Kit using a Silicon Labs SLSTK3400A-EFM32HG Starter Kit. You must have the Hall Effect Evaluation kit, Si72xx-WD-Kit, to make use of this demo. The Si72xx-WD-Kit includes two Si7210 sensors mounted on an expansion board (Si72xx-EXP) plus each of the six base part types mounted on small postage-stamp-sized (PS) boards. You must use the Silicon Labs SLSTK3400A-EFM32HG Starter Kit which is included in the Si72xx-WD-Kit. diff --git a/app/wisun/component/cli_util/sl_wisun_cli_util.c b/app/wisun/component/cli_util/sl_wisun_cli_util.c index 6fa2181b41f..527081f2de1 100644 --- a/app/wisun/component/cli_util/sl_wisun_cli_util.c +++ b/app/wisun/component/cli_util/sl_wisun_cli_util.c @@ -109,7 +109,7 @@ sl_status_t app_util_get_string(char *const value_str, if (is_value_hex) { // Hex value strcat(value_format_str, "lx"); - sprintf(value_temp, value_format_str, (uint32_t)value); + sprintf(value_temp, value_format_str, value); } else if (is_value_signed) { // Signed integer value strcat(value_format_str, "ld"); @@ -117,7 +117,7 @@ sl_status_t app_util_get_string(char *const value_str, } else { // Unsigned integer value strcat(value_format_str, "lu"); - sprintf(value_temp, value_format_str, (uint32_t)value); + sprintf(value_temp, value_format_str, value); } // String starts with an enumeration @@ -322,10 +322,6 @@ char *app_util_printable_data_next(app_printable_data_ctx_t *const ctx) ctx->data_left, ctx->line_length); } - if (!ret) { - // All done - return NULL; - } // Prepare for the next line ctx->data += ret; diff --git a/app/wisun/component/coap/sl_wisun_coap_mem.c b/app/wisun/component/coap/sl_wisun_coap_mem.c index 74026ab088f..329a4675a54 100644 --- a/app/wisun/component/coap/sl_wisun_coap_mem.c +++ b/app/wisun/component/coap/sl_wisun_coap_mem.c @@ -230,7 +230,6 @@ void _wisun_coap_mem_free(void *addr) for (uint8_t i = 0; i < WISUN_COAP_MEMORY_OPTION_COUNT; ++i) { if (sl_mempool_is_addr_in_buff(&_mem[i].mempool, addr)) { sl_mempool_free(&_mem[i].mempool, addr); - addr = NULL; } } diff --git a/app/wisun/component/led_driver/sl_wisun_led_driver.c b/app/wisun/component/led_driver/sl_wisun_led_driver.c index 39282d88bf1..2220aaad010 100644 --- a/app/wisun/component/led_driver/sl_wisun_led_driver.c +++ b/app/wisun/component/led_driver/sl_wisun_led_driver.c @@ -230,7 +230,7 @@ sl_status_t sl_wisun_led_get_signal(const sl_wisun_led_id_t led_id, led = _get_led_signal_ptr(led_id); - if (led == NULL) { + if (led == NULL || dest == NULL) { return SL_STATUS_FAIL; } @@ -324,16 +324,16 @@ static void _led_task(void *arg) sl_wisun_led_signal_t led_msg = { 0 }; // incomming led message sl_wisun_led_signal_t led0_ref = { 0 }; // LED0 reference storage sl_wisun_led_signal_t led1_ref = { 0 }; // LED1 reference storage - - bool led0_state = false; // led0 state - bool led1_state = false; // led1 state + uint8_t msg_prio = 0; + bool led0_state = false; // led0 state + bool led1_state = false; // led1 state osStatus_t stat; (void) arg; SL_WISUN_THREAD_LOOP { // check msg queue - stat = osMessageQueueGet(_led_msg_queue, &led_msg, NULL, 0U); + stat = osMessageQueueGet(_led_msg_queue, &led_msg, &msg_prio, 0U); _led_mutex_acquire(); diff --git a/app/wisun/component/led_driver/sl_wisun_led_driver.h b/app/wisun/component/led_driver/sl_wisun_led_driver.h index 43c5756f483..9b70c6ce342 100644 --- a/app/wisun/component/led_driver/sl_wisun_led_driver.h +++ b/app/wisun/component/led_driver/sl_wisun_led_driver.h @@ -34,7 +34,7 @@ // ----------------------------------------------------------------------------- // Includes // ----------------------------------------------------------------------------- - +#include "sl_status.h" #include // ----------------------------------------------------------------------------- diff --git a/app/wisun/component/meter_collector_common/sl_wisun_collector.c b/app/wisun/component/meter_collector_common/sl_wisun_collector.c index 6918c9db3af..956dc74fcdc 100644 --- a/app/wisun/component/meter_collector_common/sl_wisun_collector.c +++ b/app/wisun/component/meter_collector_common/sl_wisun_collector.c @@ -40,6 +40,7 @@ #include "sl_cmsis_os2_common.h" #include "sl_sleeptimer.h" #include "sl_component_catalog.h" +#include "sl_wisun_trace_util.h" // ----------------------------------------------------------------------------- // Macros and Typedefs @@ -356,7 +357,7 @@ static void _collector_recv_thread_fnc(void * args) sizeof(struct sockaddr_in6)); assert(res != RETVAL_ERROR); - while (1) { + SL_WISUN_THREAD_LOOP { if (!app_wisun_network_is_connected()) { msleep(100); continue; diff --git a/app/wisun/component/ping/sl_wisun_ping.c b/app/wisun/component/ping/sl_wisun_ping.c index c93a6857cc3..3d0604069ab 100644 --- a/app/wisun/component/ping/sl_wisun_ping.c +++ b/app/wisun/component/ping/sl_wisun_ping.c @@ -414,7 +414,7 @@ static void _ping_task_fnc(void *args) // reset previous response memset(&_icmp_resp, 0, sizeof(_icmp_resp)); _icmp_req.identifier = htons(req.identifier); - _icmp_req.sequence_number = htons(req.sequence_number); + _icmp_req.sequence_number = app_wisun_trace_swap_u16(req.sequence_number); // send request r = sendto(_sockid, (const void *) &_icmp_req, req.packet_length, 0, diff --git a/app/wisun/component/sl_wisun_socket.slcc b/app/wisun/component/sl_wisun_socket.slcc index d4f4f6bc702..2664c14e80f 100644 --- a/app/wisun/component/sl_wisun_socket.slcc +++ b/app/wisun/component/sl_wisun_socket.slcc @@ -13,7 +13,6 @@ source: - path: "socket.c" - path: "socket_event.c" - path: "socket_hnd.c" - - path: "errno.c" include: - path: "." @@ -21,14 +20,15 @@ include: - "path": "external_socket.h" - "path": "socket.h" - "path": "socket_hnd.h" - - "path": "errno.h" requires: + - name: "errno" - name: "sl_wisun_event_mgr" # for handling socket events config_file: - path: "config/socket_config.h" + #-------------- Template Contribution ---------------- template_contribution: #---------------- Component Catalog ------------------ socket_handler_init diff --git a/app/wisun/component/socket/errno.c b/app/wisun/component/socket/errno.c deleted file mode 100644 index de502a30166..00000000000 --- a/app/wisun/component/socket/errno.c +++ /dev/null @@ -1,112 +0,0 @@ -/***************************************************************************//** - * @file - * @brief Errno implementation - ******************************************************************************* - * # License - * Copyright 2021 Silicon Laboratories Inc. www.silabs.com - ******************************************************************************* - * - * SPDX-License-Identifier: Zlib - * - * The licensor of this software is Silicon Laboratories Inc. - * - * This software is provided 'as-is', without any express or implied - * warranty. In no event will the authors be held liable for any damages - * arising from the use of this software. - * - * Permission is granted to anyone to use this software for any purpose, - * including commercial applications, and to alter it and redistribute it - * freely, subject to the following restrictions: - * - * 1. The origin of this software must not be misrepresented; you must not - * claim that you wrote the original software. If you use this software - * in a product, an acknowledgment in the product documentation would be - * appreciated but is not required. - * 2. Altered source versions must be plainly marked as such, and must not be - * misrepresented as being the original software. - * 3. This notice may not be removed or altered from any source distribution. - * - ******************************************************************************/ - -// ----------------------------------------------------------------------------- -// Includes -// ----------------------------------------------------------------------------- - -#include "errno.h" -#include "cmsis_os2.h" -#include "sl_cmsis_os2_common.h" -#include - -// ----------------------------------------------------------------------------- -// Macros and Typedefs -// ----------------------------------------------------------------------------- - -// ----------------------------------------------------------------------------- -// Static Function Declarations -// ----------------------------------------------------------------------------- - -// ----------------------------------------------------------------------------- -// Global Variables -// ----------------------------------------------------------------------------- - -// ----------------------------------------------------------------------------- -// Static Variables -// ----------------------------------------------------------------------------- - -/**************************************************************************//** - * @brief Static errno variable - *****************************************************************************/ -static errno_t __errno = ENOERROR; - -/**************************************************************************//** - * @brief Mutex for errno access - *****************************************************************************/ -static osMutexId_t __errno_mtx = NULL; - -/**************************************************************************//** - * @brief Mutex control block for errno - *****************************************************************************/ -__ALIGNED(8) static uint8_t __errno_mtx_mtx_cb[osMutexCbSize] = { 0 }; - -/**************************************************************************//** - * @brief Mutex attributes for errno - *****************************************************************************/ -static const osMutexAttr_t __errno_mtx_attr = { - .name = "ErrnoMutex", - .attr_bits = osMutexRecursive, - .cb_mem = __errno_mtx_mtx_cb, - .cb_size = sizeof(__errno_mtx_mtx_cb) -}; - -// ----------------------------------------------------------------------------- -// Public Function Definitions -// ----------------------------------------------------------------------------- -/* init errno */ -void __init_errno(void) -{ - /*Init with zero*/ - __errno = ENOERROR; - __errno_mtx = osMutexNew(&__errno_mtx_attr); -} - -/*get errno*/ -errno_t __get_errno(void) -{ - errno_t rval; - assert(osMutexAcquire(__errno_mtx, osWaitForever) == osOK); - rval = __errno; - assert(osMutexRelease(__errno_mtx) == osOK); - return rval; -} - -/*set errno*/ -void __set_errno(const errno_t errcode) -{ - assert(osMutexAcquire(__errno_mtx, osWaitForever) == osOK); - __errno = errcode; - assert(osMutexRelease(__errno_mtx) == osOK); -} - -// ----------------------------------------------------------------------------- -// Static Function Definitions -// ----------------------------------------------------------------------------- diff --git a/app/wisun/component/socket/errno.h b/app/wisun/component/socket/errno.h deleted file mode 100644 index e234cc451c9..00000000000 --- a/app/wisun/component/socket/errno.h +++ /dev/null @@ -1,355 +0,0 @@ -/***************************************************************************//** - * @file - * @brief Errno implementation - ******************************************************************************* - * # License - * Copyright 2021 Silicon Laboratories Inc. www.silabs.com - ******************************************************************************* - * - * SPDX-License-Identifier: Zlib - * - * The licensor of this software is Silicon Laboratories Inc. - * - * This software is provided 'as-is', without any express or implied - * warranty. In no event will the authors be held liable for any damages - * arising from the use of this software. - * - * Permission is granted to anyone to use this software for any purpose, - * including commercial applications, and to alter it and redistribute it - * freely, subject to the following restrictions: - * - * 1. The origin of this software must not be misrepresented; you must not - * claim that you wrote the original software. If you use this software - * in a product, an acknowledgment in the product documentation would be - * appreciated but is not required. - * 2. Altered source versions must be plainly marked as such, and must not be - * misrepresented as being the original software. - * 3. This notice may not be removed or altered from any source distribution. - * - ******************************************************************************/ -#ifndef _ERRNO_H_ -#define _ERRNO_H_ -#ifdef __cplusplus -extern "C" { -#endif - -// ----------------------------------------------------------------------------- -// Includes -// ----------------------------------------------------------------------------- - -// ----------------------------------------------------------------------------- -// Macros and Typedefs -// ----------------------------------------------------------------------------- - -/**************************************************************************//** - * @defgroup SL_WISUN_SOCKET_ERRNO Errno - * @ingroup SL_WISUN_SOCKET - * @{ - *****************************************************************************/ - -/**************************************************************************//** - * @brief Public get errno value - *****************************************************************************/ -#define errno (__get_errno()) - -/**************************************************************************//** - * @defgroup SL_WISUN_SOCKET_ERRNO_TYPES Errno type definitions - * @ingroup SL_WISUN_SOCKET_ERRNO - * @{ - *****************************************************************************/ -/**************************************************************************//** - * @brief Errno type implementation (POSIX) - *****************************************************************************/ -typedef enum { - /// ENOERROR (not standard errno value) - ENOERROR = 0, - /// Argument list too long (POSIX.1-2001). - E2BIG, - /// Permission denied (POSIX.1-2001). - EACCES, - /// Address already in use (POSIX.1-2001). - EADDRINUSE, - /// Address not available (POSIX.1-2001). - EADDRNOTAVAIL, - /// Address family not supported (POSIX.1-2001). - EAFNOSUPPORT, - /// Resource temporarily unavailable - EAGAIN, - /// Connection already in progress (POSIX.1-2001). - EALREADY, - /// Invalid exchange. - EBADE, - /// Bad file descriptor (POSIX.1-2001). - EBADF, - /// File descriptor in bad state. - EBADFD, - /// Bad message (POSIX.1-2001). - EBADMSG, - /// Invalid request descriptor. - EBADR, - /// Invalid request code. - EBADRQC, - /// Invalid slot. - EBADSLT, - /// Device or resource busy (POSIX.1-2001). - EBUSY, - /// Operation canceled (POSIX.1-2001). - ECANCELED, - /// No child processes (POSIX.1-2001). - ECHILD, - /// Channel number out of range. - ECHRNG, - /// Communication error on send. - ECOMM, - /// Connection aborted (POSIX.1-2001). - ECONNABORTED, - /// Connection refused (POSIX.1-2001). - ECONNREFUSED, - /// Connection reset (POSIX.1-2001). - ECONNRESET, - /// Resource deadlock avoided (POSIX.1-2001). - EDEADLK, - /// On most architectures, a synonym for EDEADLK. - EDEADLOCK, - /// Destination address required (POSIX.1-2001). - EDESTADDRREQ, - /// Mathematics argument out of domain of function - EDOM, - /// Disk quota exceeded (POSIX.1-2001). - EDQUOT, - /// File exists (POSIX.1-2001). - EEXIST, - /// Bad address (POSIX.1-2001). - EFAULT, - /// File too large (POSIX.1-2001). - EFBIG, - /// Host is down. - EHOSTDOWN, - /// Host is unreachable (POSIX.1-2001). - EHOSTUNREACH, - /// Memory page has hardware error. - EHWPOISON, - /// Identifier removed (POSIX.1-2001). - EIDRM, - /// Invalid or incomplete multibyte or wide character - EILSEQ, - /// Operation in progress (POSIX.1-2001). - EINPROGRESS, - /// Interrupted function call (POSIX.1-2001); see signal(7). - EINTR, - /// Invalid argument (POSIX.1-2001). - EINVAL, - /// Input/output error (POSIX.1-2001). - EIO, - /// Socket is connected (POSIX.1-2001). - EISCONN, - /// Is a directory (POSIX.1-2001). - EISDIR, - /// Is a named type file. - EISNAM, - /// Key has expired. - EKEYEXPIRED, - /// Key was rejected by service. - EKEYREJECTED, - /// Key has been revoked. - EKEYREVOKED, - /// Level 2 halted. - EL2HLT, - /// Level 2 not synchronized. - EL2NSYNC, - /// Level 3 halted. - EL3HLT, - /// Level 3 reset. - EL3RST, - /// Cannot access a needed shared library. - ELIBACC, - /// Accessing a corrupted shared library. - ELIBBAD, - /// Attempting to link in too many shared libraries. - ELIBMAX, - /// .lib section in a.out corrupted - ELIBSCN, - /// Cannot exec a shared library directly. - ELIBEXEC, - /// Link number out of range. - ELNRANGE, - /// Too many levels of symbolic links (POSIX.1-2001). - ELOOP, - /// Wrong medium type. - EMEDIUMTYPE, - /// Too many open files (POSIX.1-2001). - EMFILE, - /// Too many links (POSIX.1-2001). - EMLINK, - /// Message too long (POSIX.1-2001). - EMSGSIZE, - /// Multihop attempted (POSIX.1-2001). - EMULTIHOP, - /// Filename too long (POSIX.1-2001). - ENAMETOOLONG, - /// Network is down (POSIX.1-2001). - ENETDOWN, - /// Connection aborted by network (POSIX.1-2001). - ENETRESET, - /// Network unreachable (POSIX.1-2001). - ENETUNREACH, - /// Too many open files in system (POSIX.1-2001). - ENFILE, - /// No anode. - ENOANO, - /// No buffer space available (POSIX.1 (XSI STREAMS option)). - ENOBUFS, - /// No message is available on the STREAM head read queue - ENODATA, - /// No such device (POSIX.1-2001). - ENODEV, - /// No such file or directory (POSIX.1-2001). - ENOENT, - /// Exec format error (POSIX.1-2001). - ENOEXEC, - /// Required key not available. - ENOKEY, - /// No locks available (POSIX.1-2001). - ENOLCK, - /// Link has been severed (POSIX.1-2001). - ENOLINK, - /// No medium found. - ENOMEDIUM, - /// Not enough space/cannot allocate memory (POSIX.1-2001). - ENOMEM, - /// No message of the desired type (POSIX.1-2001). - ENOMSG, - /// Machine is not on the network. - ENONET, - /// Package not installed. - ENOPKG, - /// Protocol not available (POSIX.1-2001). - ENOPROTOOPT, - /// No space left on device (POSIX.1-2001). - ENOSPC, - /// No STREAM resources (POSIX.1 (XSI STREAMS option)). - ENOSR, - /// Not a STREAM (POSIX.1 (XSI STREAMS option)). - ENOSTR, - /// Function not implemented (POSIX.1-2001). - ENOSYS, - /// Block device required. - ENOTBLK, - /// The socket is not connected (POSIX.1-2001). - ENOTCONN, - /// Not a directory (POSIX.1-2001). - ENOTDIR, - /// Directory not empty (POSIX.1-2001). - ENOTEMPTY, - /// State not recoverable (POSIX.1-2008). - ENOTRECOVERABLE, - /// Not a socket (POSIX.1-2001). - ENOTSOCK, - /// Operation not supported (POSIX.1-2001). - ENOTSUP, - /// Inappropriate I/O control operation (POSIX.1-2001). - ENOTTY, - /// Name not unique on network. - ENOTUNIQ, - /// No such device or address (POSIX.1-2001). - ENXIO, - /// Operation not supported on socket (POSIX.1-2001). - EOPNOTSUPP, - /// Value too large to be stored in data type (POSIX.1-2001). - EOVERFLOW, - /// Owner died (POSIX.1-2008). - EOWNERDEAD, - /// Operation not permitted (POSIX.1-2001). - EPERM, - /// Protocol family not supported. - EPFNOSUPPORT, - /// Broken pipe (POSIX.1-2001). - EPIPE, - /// Protocol error (POSIX.1-2001). - EPROTO, - /// Protocol not supported (POSIX.1-2001). - EPROTONOSUPPORT, - /// Protocol wrong type for socket (POSIX.1-2001). - EPROTOTYPE, - /// Result too large (POSIX.1, C99). - ERANGE, - /// Remote address changed. - EREMCHG, - /// Object is remote. - EREMOTE, - /// Remote I/O error. - EREMOTEIO, - /// Interrupted system call should be restarted. - ERESTART, - /// Operation not possible due to RF-kill. - ERFKILL, - /// Read-only file system (POSIX.1-2001). - EROFS, - /// Cannot send after transport endpoint shutdown. - ESHUTDOWN, - /// Invalid seek (POSIX.1-2001). - ESPIPE, - /// Socket type not supported. - ESOCKTNOSUPPORT, - /// No such process (POSIX.1-2001). - ESRCH, - /// Stale file handle (POSIX.1-2001). - ESTALE, - /// Streams pipe error. - ESTRPIPE, - /// Timer expired (POSIX.1 (XSI STREAMS option)). - ETIME, - /// Connection timed out (POSIX.1-2001). - ETIMEDOUT, - /// Too many references: cannot splice. - ETOOMANYREFS, - /// Text file busy (POSIX.1-2001). - ETXTBSY, - /// Structure needs cleaning. - EUCLEAN, - /// Protocol driver not attached. - EUNATCH, - /// Too many users. - EUSERS, - /// Operation would block (may be same value as EAGAIN) - EWOULDBLOCK, - /// Improper link (POSIX.1-2001). - EXDEV, - /// Exchange full. - EXFULL -} errno_t; -/** @} (end SL_WISUN_SOCKET_ERRNO_TYPES) */ -// ----------------------------------------------------------------------------- -// Global Variables -// ----------------------------------------------------------------------------- - -// ----------------------------------------------------------------------------- -// Public Function Declarations -// ----------------------------------------------------------------------------- - -/**************************************************************************//** - * @brief Init errno - * @details For internal usage in socket modules - *****************************************************************************/ -void __init_errno(void); - -/**************************************************************************//** - * @brief Get errno number - * @details Thread safe get errno. For internal usage in socket modules - * @return errno current value - *****************************************************************************/ -errno_t __get_errno(void); - -/**************************************************************************//** - * @brief Set errno - * @details For internal usage in socket modules - * @param[in] errcode errno value to set - *****************************************************************************/ -void __set_errno(const errno_t errcode); - -/** @}*/ - -#ifdef __cplusplus -} -#endif -#endif /*EOF*/ diff --git a/app/wisun/component/socket/socket.c b/app/wisun/component/socket/socket.c index e6528efa0a6..4c77991b33c 100644 --- a/app/wisun/component/socket/socket.c +++ b/app/wisun/component/socket/socket.c @@ -55,7 +55,7 @@ * @param errno_val errno number value if there is any error * @return return value by status check *****************************************************************************/ -static inline int32_t _check_status(sl_status_t status, int32_t retval, errno_t errno_val); +static inline int32_t _check_status(sl_status_t status, int32_t retval, int32_t errno_val); /**************************************************************************//** * @brief Convert POSIX protocol ID to Wi-SUN eqvivalent @@ -583,7 +583,7 @@ const char *inet_ntop(sock_domain_t af, const void *src, char *dst, socklen_t si // Static Function Definitions // ----------------------------------------------------------------------------- -static inline int32_t _check_status(sl_status_t status, int32_t retval, errno_t errno_val) +static inline int32_t _check_status(sl_status_t status, int32_t retval, int32_t errno_val) { if (status == SL_STATUS_OK) { return retval; diff --git a/app/wisun/component/socket/socket_hnd.c b/app/wisun/component/socket/socket_hnd.c index 8afb48ff21e..2d93715ca0c 100644 --- a/app/wisun/component/socket/socket_hnd.c +++ b/app/wisun/component/socket/socket_hnd.c @@ -276,8 +276,6 @@ void socket_handler_init(void) // get kernel status to avoid mutex assert failure kernel_state = osKernelGetState(); - __init_errno(); - // Create socket handler mutex _socket_hnd_mtx = osMutexNew(&_socket_hnd_mtx_attr); diff --git a/app/wisun/component/socket/socket_hnd.h b/app/wisun/component/socket/socket_hnd.h index 05e2816b37e..cf8fd967728 100644 --- a/app/wisun/component/socket/socket_hnd.h +++ b/app/wisun/component/socket/socket_hnd.h @@ -104,7 +104,7 @@ extern "C" { *****************************************************************************/ #define _set_errno(err) \ do { \ - __set_errno(err); \ + errno = (err); \ } while (0) /**************************************************************************//** diff --git a/app/wisun/component/trace_util/sl_wisun_trace_util.h b/app/wisun/component/trace_util/sl_wisun_trace_util.h index 7930f35a401..27a60a0f9ce 100644 --- a/app/wisun/component/trace_util/sl_wisun_trace_util.h +++ b/app/wisun/component/trace_util/sl_wisun_trace_util.h @@ -106,6 +106,16 @@ const char * app_wisun_trace_util_reg_domain_to_str(const uint32_t val); *****************************************************************************/ const char * app_wisun_trace_util_nw_size_to_str(const uint32_t val); +/**************************************************************************//** + * @brief Swapping short unsigned integer endianess + * @details It swaps the value pointed. + * @param[in] num The swappng number + * @return uint16_t integer + *****************************************************************************/ +inline uint16_t app_wisun_trace_swap_u16(uint16_t num) { + return (((num & 0xFF) << 8) | ((num & 0xFF00) >> 8)); +} + /**************************************************************************//** * @brief Macro to check a status and print a message if the state is not OK * @details Use this print a short message on any location where unhandled state diff --git a/app/wisun/documentation/example/wisun_cli/readme.html b/app/wisun/documentation/example/wisun_cli/readme.html deleted file mode 100644 index 755894ef863..00000000000 --- a/app/wisun/documentation/example/wisun_cli/readme.html +++ /dev/null @@ -1,679 +0,0 @@ - - - - - -readme - -
    -

    Wi-SUN - SoC CLI

    The Wi-SUN CLI (Command-Line Interface) sample application allows developers to easily evaluate the Wi-SUN stack APIs. The Wi-SUN command line interface provides a serial interface to a number of the Wi-SUN stack functions. For example, it can be used to connect the Wi-SUN device to a Wi-SUN border router and exchange IP packets.

    Getting Started

    To get started with Wi-SUN and Simplicity Studio, see QSG181: Wi-SUN SDK Quick Start Guide.

    This example exposes a command-line interface to interact with the Wi-SUN stack. To get started with the example, follow the steps below:

    • Flash the "Wi-SUN Border Router" demonstration to a device and start the Border Router.
    • Create and build the Wi-SUN CLI project.
    • Flash the Wi-SUN CLI project to a second device.
    • Using Simplicity Studio, open a console on the device running the Wi-SUN CLI project.

    Refer to the associated sections in QSG181: Wi-SUN SDK Quick Start Guide if you want step-by-step guidelines for each operation. To fully evaluate the Wi-SUN CLI features, another device running the Wi-SUN CLI application might be required. The Wi-SUN CLI application can also interact with the other Wi-SUN examples (Wi-SUN Ping, Wi-SUN TCP/UDP Server/Client...).

    The Wi-SUN CLI example can be used to evaluate and test the Wi-SUN stack but should not be used to create productized applications. Developers should implement their own C application running in the EFR32 and using the Wi-SUN stack API.

    Wi-SUN Commands

    To see the available commands, enter the following command in the console.

    The list of available commands is output on the console with the associated help. Following is an extended description and examples of how to use each command.

    CommandDescriptionExample
    wisun connectConnect to the predefined Wi-SUN network 'Wi-SUN Network'> wisun connect
    wisun disconnectDisconnect from the Wi-SUN network> wisun disconnect
    wisun get <section>.[setting]Get a setting variable. Specifying only the section retrieves all settings of the section.> wisun get wisun.ip_addresses
    > wisun get wisun
    > wisun get statistics
    > wisun get app
    wisun mac_allow <mac address>Add an allowed MAC address to the access list
    broadcast address: allow all MAC addresses
    unique address: allow the given MAC address    		> wisun mac_allow ff:ff:ff:ff:ff:ff:ff:ff
    > wisun mac_allow ffffffffffffffff
    wisun mac_deny <mac address>Add a denied MAC address to the access list
    broadcast address: deny all MAC addresses
    unique address: deny the given MAC address    		> wisun mac_deny 00:01:02:03:04:05:06:07
    > wisun mac_deny 0001020304050607
    wisun ping <remote address>Ping a remote host> wisun ping fd00:7283:7e00:0:fd6f:d00:a8c0:20fe
    wisun resetReset variables to default values> wisun reset
    wisun saveSave variables to NVM> wisun save
    wisun set <section>.<setting> <value>Set a setting variable> wisun set wisun.network_size small
    wisun socket_close <socket>Close an open socket> wisun socket_close 3
    wisun socket_listList open sockets> wisun socket_list
    wisun socket_read <socket> <amount of bytes>Read buffered data from a socket> wisun socket_read 3 14
    wisun socket_set_option <socket> <option> <option data>Configure a socket> wisun socket_set_option 3 event_mode indication
    wisun socket_write <socket> <string>Write a string to a socket> wisun socket_write 3 "hello world"
    wisun socket_writeto <socket> <remote address> <remote port> <string>Write a string to an unconnected socket, i.e. UDP server socket> wisun socket_writeto 3 fc00::1 5001 "hello world"
    wisun tcp_client <remote address> <remote port>Open a TCP connection to a remote host> wisun tcp_client fd24:120b:802c:0001:705d:9179:8607:fd21 5001
    wisun tcp_server <local port>Open a TCP server port> wisun tcp_server 5001
    wisun udp_client <remote address> <remote port>Open a UDP connection to a remote host> wisun udp_client fd00:6172:6d00:0:3038:5115:26:27 7
    wisun udp_server <local port>Open a UDP server port> wisun udp_server 5001

    Wi-SUN Settings

    The command-line interface maintains a number of settings. The Wi-SUN settings are distributed in three sections: wisun, statistics, and app. They can be listed by entering:

    The Wi-SUN stack settings are listed with their current state/value. Some of them can be modified by using the following command prototype:

    To modify the network name the Wi-SUN device should connect to, enter:

    Next time you issue the wisun connect command, the device starts a connection process with the Wi-SUN network named "My Network".

    wisun Section Settings

    The settings in the wisun section are directly related to the Wi-SUN stack behavior. A detailed setting list can be found below.

    VariableR/WTypeValuesDescription
    wisun.network_nameR/Wstringup to 31 ASCII charactersName of the Wi-SUN network
    wisun.regulatory_domainR/WintegerWW (0): Worldwide
    NA (1): North America
    JP (2): Japan
    EU (3): Europe
    CN (4): China
    IN (5): India
    MX (6): Mexico
    BZ (7): Brazil
    AZ (8): Australia/New Zealand
    KR (9): South Korea
    PH (10): Philippines
    MY (11): Malaysia
    HK (12): Hong Kong
    SG (13): Singapore
    TH (14): Thailand
    VN (15): Vietnam
    application (255): application specific    		Regulatory domain of the Wi-SUN network
    wisun.operating_classR/Winteger1 to 4
    application (255): application specific    		Operating class of the Wi-SUN network to use
    wisun.operating_modeR/Winteger0x1a: 1a
    0x1b: 1b
    0x2a: 2a
    0x2b: 2b
    0x3: 3
    0x4a: 4a
    0x4b: 4b
    0x5: 5    		Operating mode of the Wi-SUN network to use
    wisun.network_sizeR/Winteger0: automatic
    1: small
    2: medium
    3: large
    4: test
    5: certification    		Estimated size of the Wi-SUN network
    wisun.tx_powerR/Winteger-45 to 20Maximum TX power in dBm
    wisun.unicast_dwell_intervalR/Winteger10 to 255Unicast dwell interval in milliseconds
    wisun.ip_addressesRlist of IPv6 addresses List of all IP addresses assigned to the device
    wisun.border_routerRlist of IPv6 addresses List of known IPv6 addresses of the border router
    wisun.parentsRlist of IPv6 addresses List of known IPv6 addresses of the parents
    wisun.neighborsRlist of IPv6 addresses List of known IPv6 addresses of the RPL neighbors
    wisun.phy.ch0_frequencyR/Winteger Central frequency of the first channel in kHz
    (available only when application-specific channel plan is selected)
    wisun.phy.number_of_channelsR/Winteger Number of channels
    (available only when application-specific channel plan is selected)
    wisun.phy.channel_spacingR/Winteger0: 100 kHz
    1: 200 kHz
    2: 400 kHz
    3: 600 kHz    		Channel spacing
    (available only when application-specific channel plan is selected)
    wisun.unicast_channel_mask.XXX-XXXR/Whexadecimal Application-specific channel mask
    wisun.join_stateRinteger0: Idle
    1: Select PAN
    2: Authenticate
    3: Acquire PAN Config
    4: Configure Routing
    5: Operational    		Current join state in the connection process
    wisun.macR/WMAC address MAC address to use

    statistics Section Settings

    The settings part of the statistics section are counters maintained by the Wi-SUN stack. A detailed setting list can be found below.

    VariableRead/WriteDescription
    statistics.phyRPHY statistics
    statistics.macRMAC statistics
    statistics.fhssRFrequency hopping statistics
    statistics.wisunRWi-SUN layer statistics
    statistics.networkR6LoWPAN/IP stack statistics

    app Section Settings

    The settings in the app section relate to the application options. A detailed setting list follows.

    VariableR/WTypeValuesDescription
    app.printable_data_lengthR/Winteger0: received socket data is not printed
    1 - 64: amount of characters per line    		If enabled, received socket data is printed
    app.printable_data_as_hexR/Winteger0: print received socket data as ASCII
    1: print received socket data as hex    		Output type for received socket data

    Troubleshooting

    Before programming the radio board mounted on the WSTK, ensure the power supply switch is in the AEM position (right side), as shown.

    Radio Board Power Supply Switch

    Resources

    Report Bugs & Get Support

    You are always encouraged and welcome to ask any questions or report any issues you found to us via Silicon Labs Community.

    - - \ No newline at end of file diff --git a/app/wisun/documentation/example/wisun_cli/readme.md b/app/wisun/documentation/example/wisun_cli/readme.md new file mode 100644 index 00000000000..6b7357259a4 --- /dev/null +++ b/app/wisun/documentation/example/wisun_cli/readme.md @@ -0,0 +1,128 @@ +# Wi-SUN - SoC CLI + +The Wi-SUN CLI (Command-Line Interface) sample application allows developers to easily evaluate the Wi-SUN stack APIs. The Wi-SUN command line interface provides a serial interface to a number of the Wi-SUN stack functions. For example, it can be used to connect the Wi-SUN device to a Wi-SUN border router and exchange IP packets. + +## Getting Started + +To get started with Wi-SUN and Simplicity Studio, see [QSG181: Wi-SUN SDK Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg181-wi-sun-sdk-quick-start-guide.pdf). + +This example exposes a command-line interface to interact with the Wi-SUN stack. To get started with the example, follow the steps below: + +* Flash the "Wi-SUN Border Router" demonstration to a device and start the Border Router. +* Create and build the Wi-SUN CLI project. +* Flash the Wi-SUN CLI project to a second device. +* Using Simplicity Studio, open a console on the device running the Wi-SUN CLI project. + +Refer to the associated sections in [QSG181: Wi-SUN SDK Quick Start Guide](https://www.silabs.com/documents/public/quick-start-guides/qsg181-wi-sun-sdk-quick-start-guide.pdf) if you want step-by-step guidelines for each operation. To fully evaluate the Wi-SUN CLI features, another device running the Wi-SUN CLI application might be required. The Wi-SUN CLI application can also interact with the other Wi-SUN examples (Wi-SUN Ping, Wi-SUN TCP/UDP Server/Client...). + +> The Wi-SUN CLI example can be used to evaluate and test the Wi-SUN stack but should not be used to create productized applications. Developers should implement their own C application running in the EFR32 and using the Wi-SUN stack API. + +## Wi-SUN Commands + +To see the available commands, enter the following command in the console. + + wisun help + +The list of available commands is output on the console with the associated help. Following is an extended description and examples of how to use each command. + +| Command | Description | Example | +|---|---|---| +| wisun connect | Connect to the predefined Wi-SUN network 'Wi-SUN Network' | > wisun connect | +| wisun disconnect | Disconnect from the Wi-SUN network | > wisun disconnect | +| wisun get \
    .[setting] | Get a setting variable. Specifying only the section retrieves all settings of the section. | > wisun get wisun.ip_addresses
    > wisun get wisun
    > wisun get statistics
    > wisun get app | +| wisun mac_allow \ | Add an allowed MAC address to the access list
    broadcast address: allow all MAC addresses
    unique address: allow the given MAC address | > wisun mac_allow ff:ff:ff:ff:ff:ff:ff:ff
    > wisun mac_allow ffffffffffffffff | +| wisun mac_deny \ | Add a denied MAC address to the access list
    broadcast address: deny all MAC addresses
    unique address: deny the given MAC address | > wisun mac_deny 00:01:02:03:04:05:06:07
    > wisun mac_deny 0001020304050607 | +| wisun ping \ | Ping a remote host | > wisun ping fd00:7283:7e00:0:fd6f:d00:a8c0:20fe | +| wisun reset | Reset variables to default values | > wisun reset | +| wisun save | Save variables to NVM | > wisun save | +| wisun set \
    .\ \ | Set a setting variable | > wisun set wisun.network_size small | +| wisun socket_close \ | Close an open socket | > wisun socket_close 3 | +| wisun socket_list | List open sockets | > wisun socket_list | +| wisun socket_read \ \ | Read buffered data from a socket | > wisun socket_read 3 14 | +| wisun socket_set_option \ \