Tuya SDK software migrating tutorial

Tuya SDK software migrating tutorial

1. Introduction

Roadmap: Step 1: Compile the MCU basic program and migrate the SDK file. Step 2: Verify the macro definition in protocol.h. Step 3: Migrate the protocol.c file and invoke functions. Step 4: Optimize the DP data report and delivery functions.

2. Software migration details

2.1 Compile the MCU basic program and migrate the SDK file

Add the .c and .h files in the mcu_sdk folder and corresponding header file reference path to the original project. Initialize MCU-related peripherals, including the serial port, external interrupt (button), and timer (indicator blinking).

2.2 Verifying the Macro Definition in protocol.h

2.2.1 Verify the product information

PRODUCT_KEY indicates the macro definition of the product ID (PID), which is the unique identifier of a product. Ensure that the PID is the same as that displayed on the Tuya Smart platform. If the PIDs are different, download the latest SDK package. MCU_VER indicates the software version, which is 1.0.0 by default. If the MCU requires OTA upgrade, you need to update the version number after the OTA upgrade. CONFIG_MODE indicates the network configuration mode, and the typical value is DEFAULT, indicating the default network configuration mode.

2.2.2 Check whether the MCU firmware needs to be upgraded

If OTA upgrade of MCU firmware is required, enable the firmware update macro, which is disabled by default.

2.2.3 Define the transmitting and receiving buffers

Modify the buffer size based on the DP definition. The size of the serial port transmitting and receiving buffers must be larger than the maximum DP data length. The default size is 24 bytes. If MCU OTA upgrade is required, a 260-byte buffer is recommended. The receiving buffer size can be reduced if the RAM has insufficient space.

2.2.4 (Mandatory) Define the working mode of the Wi-Fi module

1)If the MCU controls network configuration triggering and indication, that is, the Wi-Fi reset button and Wi-Fi indicator are on the MCU side, enable cooperative processing by the Wi-Fi module and MCU (common mode) and ensure that #define is commented (the line of code starts with “//”).

  1. If the Wi-Fi indicator and Wi-Fi reset button are on the Wi-Fi module, execute the following statement to enable processing by the Wi-Fi module: #ifdef WIFI_CONTROL_SELF_MODE Then, add information about the GPIO pins connected to the Wi-Fi indicator and Wi-Fi reset button, as shown in the following figure.

2.2.5 Check whether the MCU needs time verification

If the time verification function is required, enable the RTC check macro. Write mcu_write_rtctime in the Protocol.c file to implement the code. After the Wi-Fi module successfully connects to the network, the MCU can invoke the mcu_get_system_time() function to initiate time verification.

2.2.6 Check whether the Wi-Fi product testing function is enabled

To ensure mass production efficiency and quality, we recommend that you enable the product testing macro. For details about implementation of the product testing function, see section 3.3.6 “Optimizing the Product Testing Function.”

2.3 Migrating the protocol.c File and Invoking Functions

  1. Use #include “wifi.h” in the files (for example, the main.c file) that require Wi-Fi–related files. . After MCU peripherals are initialized, invoke the wifi_protocol_init() function in the mcu_api.c file. . Add the single-byte sending function of the MCU serial port to the uart_transmit_output function in the protocol.c file and delete #error. The following figure shows an example.

  1. Invoke the uart_receive_input function in the mcu_api.c file in the serial port receiving interrupt service function, and use the received characters as parameter input. The following figure shows an example.

  1. Invoke the wifi_uart_service() function in the mcu_api.c file after the MCU enters the while cycle. The following shows an example of code structure in main.c.

include “wifi.h” … void main(void) { wifi_protocol_init(); … while(1) { wifi_uart_service(); … } } Note: The MCU must directly invoke the wifi_uart_service() function in the mcu_api.c file in while. After the program is successfully initialized, it is recommended that the serial port interrupt not be disabled. If the serial port interrupt must be disabled, ensure that the interrupt is disabled for only a short time to prevent serial port data loss. Do not invoke the report function in the interrupt.

2.4 Processing DP Data Report and Delivery Functions

2.4.1 Reporting data of all DPs

After the Wi-Fi module restarts or the network is reconfigured, the Wi-Fi module proactively delivers a status query command. The MCU needs to report the status of the device’s DPs to the Wi-Fi module for synchronization. (1) Open protocol.c and locate the all_data_update(void) function. (2) Enter initial values of all DPs to be reported into corresponding report functions. The values will be displayed on the app control panel. Note: Do not invoke the all_data_update() function manually. This function is automatically invoked at a specific time.

2.4.2 Reporting data of a single DP

When the status of a DP is changed, the MCU proactively reports the new DP status to the Wi-Fi module, and the DP status displayed on the app will be updated accordingly. The report data format is mcu_dp_xxxx_updata(DPID_X,n). DPID_X indicates the DP whose status has changed. Functions in all_data_update() can be independently invoked. Example: mcu_dp_bool_update(DPID_SWITCH,1); //Boolean data reporting mcu_dp_value_update(DPID_TEMPER_SET,25); //Value data reporting mcu_dp_string_update(DPID_DAY,“1234”,4); //String data reporting

2.4.3 DP data delivery

Each deliverable DP has an independent data delivery processing function in the protocol.c file. The function format is dp_download_xxx_handle(), and xxx indicates a deliverable DP. After the function parses a DP, the MCU performs logical control in the corresponding position. The following shows an example of receiving switch data. The MCU uses MCU_ON_switch1() and MCU_OFF_switch1() to turn on and off a switch, respectively. When the device status is changed under non-app control, the MCU invokes mcu_dp_bool_update(DPID_SWITCH_1,switch_1) to upload the real status of the switch. Typically, the receiving processing function automatically invokes the function.

400 Call