A dual protocol stack system for IOT wifi
By adopting a dual-protocol stack system in IoT Wifi products and utilizing the collaborative work of the main control chip and the IoT Wifi chip, the problems of high difficulty and high cost in cloud platform porting in existing technologies are solved, achieving low cost and easy development of low-power IPC products.
Patent Information
- Application Number
- CN202310821953.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-07-05
- Publication Date
- 2025-11-04
- Estimated Expiration
- 2043-07-05
AI Technical Summary
Porting existing IoT Wi-Fi products to cloud platforms is difficult and costly, and the development and porting of low-power IPC products are complex, with limited resources, making it difficult to achieve low-cost and easy-to-develop solutions.
The system employs a dual-protocol stack. The IoT Wifi chip is a traditional Wifi external chip that uses SPI or SDIO as the main control chip. The main control chip maps it to a network interface by loading a driver. The main control chip and the IoT Wifi chip are responsible for event processing and peripheral function processing in wake-up and sleep states, respectively. The system uses Linux and FreeRTOS operating systems to achieve device keep-alive and data transmission between the device and the cloud server.
It achieves low cost, easy development and easy portability of low-power IPC products, simplifies the cloud platform porting process, reduces development difficulty and improves resource utilization efficiency.
Smart Images

Figure CN119277573B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application belongs to the technical field of wireless network application, and particularly relates to a dual-protocol stack system for IOT Wifi. BACKGROUND
[0002] Wifi can be simply understood as wireless Internet access, and almost all smart phones, notebook computers and IPC cameras support Wifi Internet access, which is the most widely used wireless network transmission technology today. With the promotion of the Internet of Things (IOT), people soon get used to the state of interconnection of all things. At present, IPC cameras have become essential products for home security, old and baby care, and are increasingly recognized by the market. A low-cost, simple-to-develop and simple-to-port wifi solution is indispensable for IPC products.
[0003] At present, traditional IPC network cameras need to be powered by an external power cord, which makes the product installation inconvenient and has low value. Therefore, battery-powered IPC products are increasingly recognized by users, such as battery doorbells, door locks, cat eye cameras and other products. Due to the limited capacity of the battery, the battery-powered product operates at low power consumption, and low-power keep-alive is a necessary function of the product. The traditional low-power product scheme adopts a mode of three chip devices such as Beijing King-Right Integrated Circuit Co., Ltd. (hereinafter referred to as Beijing King-Right) T31 type chip + MCU + wifi, but this scheme increases the cost of the MCU chip. Therefore, IOT wifi with MCU module has a cost advantage, and only two chip devices of T31 type chip + IOT wifi are needed to realize the low-power product scheme.
[0004] However, most of the products currently matched with IOT Wifi run the protocol stack on the Wifi side, and the main control has no protocol stack, and the data is transmitted to the Wifi through a private protocol, and then sent out through the Wifi protocol stack. When the cloud platform needs to be transplanted, the IOT Wifi usually uses the RTOS operating system, however, there are fewer software engineers specializing in this operating system, and there are also fewer online parameter data, so the transplantation is very difficult, which leads to an increase in cost. In addition, the memory and flash storage on the Wifi side are relatively small, and the resources that can be accommodated are also limited.
[0005] In addition, the commonly used terms in the prior art include:
[0006] IOT: Internet of Things (IoT, Internet of Things) is an extension and expansion of the Internet, which combines various information sensing devices with the network to form a huge network, and realizes the interconnection of people, machines and things at any time and any place.
[0007] Wifi: wireless network.
[0008] IPC: IP Camera, network camera.
[0009] Low-power camera: generally refers to a battery-powered, low-power running, and fast start function required IPC.
[0010] MT7682: one of the IOT wifi models.
[0011] MCU: micro control unit, also known as single-chip microcomputer.
[0012] Routine: a set of function interfaces or services provided by a system to the outside. For example, the API, service, etc. of the operating system is a routine; the standard function and library function provided by Delphi or C++ Builder is also a routine. SUMMARY
[0013] In order to solve the above problems, the purpose of the present application is to use a dual protocol stack mode, IOT Wifi is virtually formed into an Ethernet port device supporting 802.3 protocol on the side of Beijing Junzheng T31 model chip, and the host control can have its own protocol stack. Since the host control uses a Linux operating system, this operating system is a conventional system for IPC products, the development difficulty is small, the reference materials on the Internet are rich, and the transplantation is simple. The cloud platform and the mobile phone APP can be seamlessly connected.
[0014] Specifically, the present application provides a dual protocol stack system used by IOT Wifi, which comprises:
[0015] The host control chip adopts a high-performance H.265 / H.264 / JPEG SoC chip, which integrates a high-performance ISP image processing module, and the resolution can reach 2592*1920@30fps. At the same time, it integrates 128MB DDR memory internally, and the highest main frequency is 1.5Ghz. It has complete peripheral interfaces required for application, including USB, SDIO and Ethernet, and can be applied to various network camera products. The IOT Wifi chip comprises a microcontroller unit MCU, a low-power 1x11n single-band Wi-Fi subsystem and a power management unit PMU. The IOT wifi internally contains an ARM Cortex-M4 processor with a floating point unit, which is integrated with 1MB of flash memory, and is a highly integrated chip set. The Wi-Fi subsystem contains 802.11b / g / n radio, baseband and MAC, which is used for low-power and high-throughput application development. It also contains a 32-bit RISC CPU, which can completely offload the application processor. It also supports UART, I2C, SPI, I2S, PWM, SDIO and ADC interfaces.
[0016] The IOT Wifi chip is a traditional Wifi external chip of the master chip through SPI or SDIO, the master chip maps the IOT Wifi chip as a network interface interface by loading the same driver as the following driver: z7682inf.ko, and the audio and video protocol stack of the master chip is bound to the wifi interface to create a network communication interface socket;
[0017] The master chip and the IOT Wifi chip transmit audio and video streams through SPI or SDIO, and the cloud server SDK is simultaneously run on the IOT Wifi chip to realize the keep-alive between the device and the cloud server, and the device has the functions of device network configuration, account binding, cloud communication and OTA upgrade;
[0018] The virtual network port on the side of the master chip and the network port of the IOT Wifi chip are the same MAC and IP address externally, and the data of the master chip side or the data of the IOT Wifi chip side is distinguished according to different ports;
[0019] The management of the master chip to the Wifi is through the API interface, using a private protocol, and the internal drive encapsulates the interface dependent on data transmission, including:
[0020] Z7682_IOTC_POWEROFF for controlling the power-off of the system,
[0021] Z7682_IOTC_FW_VERSION_READ for obtaining the IOT Wifi version information (obtaining MT7682 version information),
[0022] Z7682_IOTC_INT_MASK_READ for reading data,
[0023] Z7682_IOTC_INT_MASK_WRITE for writing data,
[0024] Z7682_IOTC_WKUP_INTF_READ for reading the interrupt wake-up event, Z7682_IOTC_GET_IP_INFO for obtaining the IOT Wifi IP information (obtaining MT7682 ip information), and the like,
[0025] and the application layer communication of the IOT Wifi chip; the IOT Wifi chip distinguishes whether it is IP network data or private protocol data according to different custom packet headers, and performs corresponding processing or forwarding;
[0026] The master chip is responsible for event processing in a running state, and the IOT Wifi chip is responsible for function processing and keep-alive processing of peripherals in a sleep state.
[0027] The event processing, low-power sleep keep-alive product, includes a doorbell, a door lock camera, and the like, after each device is started, the master control program needs to know what reason wakes up the master control, at this time, the reason for waking up can be read through API reading Event, in addition, during the running of the device, the Event needs to be monitored in real time, and the triggered event, such as a key event, is processed in time.
[0028] The function processing and keep-alive processing of the peripherals, the low-power doorbell and door lock product, in a sleep state, in order to ensure low power consumption and prolong the battery life of the product, the master control is in a power-off state and cannot work, only the wifi works.
[0029] The application layer of the master chip and the IOT Wifi chip adopts SDIO or SPI interface.
[0030] The IOT Wifi chip is responsible for peripheral function processing in a sleep state, including PIR human body infrared sensing, key wake-up, and remote wake-up packet.
[0031] The system of the IOT Wifi chip adopts a FreeRTOS system, contains network configuration, network data forwarding, and self-MCU function configuration, the peripherals including PIR human body infrared sensing and doorbell key are connected to the MCU built in the IOT Wifi chip, and the function of waking up the device by the peripherals is processed through the MCU.
[0032] The IOT Wifi chip registers the driver of an Ethernet card on the master chip, loads the driver on the master chip, generates a network port with an interface name of eth0, and uses a general socket method of Linux to perform network communication, in addition, after loading the driver, a / dev / z7682 device node is generated in the file system of the master chip, if the master control is of other models, the path is also this path, the master chip performs data interaction with the IOT Wifi chip through the ioctl command of the node.
[0033] The general socket method of Linux is used to perform network communication, including data interaction with a cloud server and data interaction with a mobile phone APP.
[0034] The application layer on the master chip side is provided with routine codes, an application program link_listen.c and ioctl_test.c operate the / dev / z7682 device node, and call ioctl to read information, including the following contents.
[0035] Network event capture: through ioctl command, represented as:
[0036] Z7682_IOTC_LISTEN_LINK_CHANGE, when the IOT Wifi chip successfully connects to WIFI, the command returns; the ioctl has a parameter, unit ms, the parameter means timeout time, if timeout, return 0, if error, return negative value;
[0037] The application program writes a while loop to continuously listen to this event, and when LINK_CHANGE is listened to, it means that the network situation has changed, and the IP, DNS, MASK, MAC, DHCP, Gateway network information is re-read, through ioctl command, represented as:
[0038] Z7682_IOTC_GET_IP_INFO obtains the above network information, and sets it to the master chip through the system interface, that is, the network configuration is completed.
[0039] The system also includes network port configuration:
[0040] The upper layer network data flow determines whether the data is processed by the IOT Wifi chip protocol stack or transmitted to the master chip according to the port number;
[0041] The port range setting of the IOT Wifi chip end can be configured in the SDK of the IOT Wifi chip, and the default port range of the IOT Wifi chip protocol stack in the SDK is 54000-60000;
[0042] The local random allocation port range is obtained on the master chip through cat / proc / sys / net / ipv4 / ip_local_port_range;
[0043] The port range can be modified to (x, y) by setting the command echo'x y'> / proc / sys / net / ipv4 / ip_local_port_range;
[0044] The master chip end will obtain the port range of the IOT Wifi chip when loading the IOT Wifi chip driver, and can also obtain this range by calling the API to read the value in the IOT Wifi chip virtual register REG_INVALID_PORT.
[0045] The master chip uses T31 model chip, T31 model chip, with excellent image processing capability, extremely high encoding quality and extremely low encoding code rate;
[0046] The IOT Wifi chip adopts an MT7682 model chip, and the MT7682 also supports UART, I2C, SPI, I2S, PWM, SDIO and ADC interfaces.
[0047] Therefore, the application has the advantages that the scheme provides an IOT Wifi solution with low cost, easy development and easy transplantation for low-power consumption IPC products. DETAILED DESCRIPTION
[0048] The accompanying drawings, which are included to provide a further understanding of the application and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application.
[0049] Figure 1 is a structural schematic diagram of the system of the application.
[0050] Figure 2 is a directory schematic diagram of the code related to the system of the application.
[0051] Figure 3 is a code part screenshot related to the creation of the z7682inf driver of the system of the application, and data interaction is performed through the z7682_misc_ioctl function.
[0052] Figure 4 is a code part screenshot related to the application of the system of the application, in which the device node of / dev / z7682 is opened, and the ioctl is called to read information.
[0053] Figure 5 is a code part screenshot related to the system of the application, in which the z7682_spi_cmd_cwr encapsulates the cmd buf format, and then transmits data to the MT7682 through the spi data bus. DETAILED DESCRIPTION
[0054] In order to make the technical content and advantages of the application more clearly understood, the application will be further described in detail in combination with the drawings.
[0055] The specific implementation of the scheme of the application is a dual-protocol stack system used in IOT Wifi, as shown in Figure 1 The implementation and use of the application are described in detail, taking the MT7682 chip as an example, and the system comprises:
[0056] The main control chip adopts a T31 model chip: a high-performance H.265 / H.264 / JPEG SoC chip. The chip integrates a high-performance ISP image processing module, the resolution of which is up to 2592*1920@30fps, has excellent image processing capability, extremely high encoding quality and extremely low encoding code rate, simultaneously internally integrates a 128MB DDR memory, has a maximum frequency of 1.5Ghz, has complete peripheral interfaces required by application, including USB, SDIO and Ethernet, etc., and can be suitable for various network camera products;
[0057] The IOT Wifi chip adopts an MT7682: including a microcontroller unit (MCU), a low-power 1x11n single-band Wi-Fi subsystem and a power management unit (PMU). The IOT Wifi internally contains an ARM Cortex-M4 processor with a floating point unit, integrated with 1MB of flash memory, and is based on a highly integrated chipset. The Wi-Fi subsystem contains an 802.11b / g / n radio, baseband and MAC for low-power and high-throughput application development. It also contains a 32-bit RISC cpu that can completely offload the application processor. The MT7682 also supports interfaces such as UART, I2C, SPI, I2S, PWM, SDIO and ADC;
[0058] The IOT Wifi chip (MT7682 model chip) is used as a traditional Wifi external chip of the main control chip (T31 model chip) through SPI or SDIO, the main control chip (T31 model chip) is loaded with a driver: z7682inf.ko, the corresponding driver is also a driver for registering an Ethernet card as described below, the driver loaded on the main control chip (T31ZX) maps the IOT Wifi chip (MT7682 model chip) as a network interface interface, and the audio and video protocol stack of the main control chip (T31 model chip) is bound to the wifi interface to create a network communication interface socket;
[0059] The main control chip (T31 model chip) and the IOT Wifi chip (MT7682 model chip) transmit audio and video streams through SPI or SDIO, the IOT Wifi chip (MT7682 model chip) simultaneously runs a cloud server SDK to realize keep-alive between the device and the cloud server, and has the functions of device network configuration, account binding, cloud communication and OTA upgrade;
[0060] The virtual network interface and the IOT wifi network interface mapped on the side of the master chip (T31 model chip) are the same MAC and IP address externally, and are distinguished as the master side data of the master chip (T31 model chip) or the IOT Wifi chip (MT7682 model chip) side data according to different ports.
[0061] The management of Wifi by the master chip (T31 model chip) is communicated with the application layer of the IOT Wifi chip (MT7682 model chip) through an API interface using a private protocol to drive the interface encapsulating data transmission, such as Z7682_IOTC_POWEROFF (controlling system power off), Z7682_IOTC_FW_VERSION_READ (acquiring MT7682 version information), Z7682_IOTC_INT_MASK_READ (reading data), Z7682_IOTC_INT_MASK_WRITE (writing data), Z7682_IOTC_WKUP_INTF_READ (reading interrupt wakeup event), Z7682_IOTC_GET_IP_INFO (acquiring MT7682 ip information), etc.
[0062] The master chip (T31 model chip) is responsible for event processing in the running state, and the low-power sleep keep-alive product, such as a doorbell, a door lock camera, etc., needs to know what reason wakes up the master after each device startup, and the API can be used to read the event wakeup reason. In addition, the event needs to be monitored in real time during the device running process, and the triggered event, such as a key event, is processed in time. The IOT Wifi chip (MT7682 model chip) is responsible for the function processing and keep-alive processing of the external device in the sleep state, and the low-power doorbell and door lock product in the sleep state needs to ensure low power consumption and delay the product battery use time. The master is in a power-off state and cannot work, and only the wifi works.
[0063] That is, in the scheme of the T31 model chip (hereinafter referred to as T31) + MT7682 model chip (hereinafter referred to as MT7682), the MT7682 is used as a traditional wifi external chip of the T31 through SPI or SDIO, the T31 maps the MT7682 as an interface through a corresponding driver, and the T31 audio and video protocol stack can be bound on the wifi interface to create a socket (network communication interface).
[0064] T31 and MT7682 transmit audio and video streams through SPI or SDIO. The cloud server SDK runs on MT7682 simultaneously to realize the keep-alive between the device and the cloud server, and to have functions such as device network configuration, account binding, cloud communication, OTA upgrade, etc.
[0065] The virtual network port mapped on the T31 side and the IOT wifi network port, the two network ports, are the same MAC and IP address externally, and are distinguished according to different ports as T31 master side data or MT7682 side data.
[0066] T31 manages wifi through API interface, uses private protocol and application layer communication of MT7682. The bottom layer SDIO and SPI interface are selected. MT7682 distinguishes IP network data or private protocol data according to different custom packet headers, and performs corresponding processing or forwarding.
[0067] T31 is mainly responsible for event processing in the running state, MT7682 is mainly responsible for keep-alive processing in the sleep state, and peripheral function processing, such as PIR human infrared sensing, key wake-up, remote wake-up packet, etc.
[0068] As shown in Figure 2 , the implementation code of the present application is as follows:
[0069] Take the MT7682 version information acquisition of Z7682_IOTC_FW_VERSION_READ as an example to illustrate the implementation code:
[0070] 1. Create z7682inf driver, data interaction is through z7682_misc_ioctl function, as shown in Figure 3 .
[0071] 2. Application program opens the ` / dev / z7682` device node, calls ioctl to read information, as shown in Figure 4 .
[0072] 3. z7682_spi_cmd_cwr encapsulates cmd buf format, and transmits data to MT7682 through the spi data bus, as shown in Figure 5 .
[0073] 4. MT7682 performs corresponding operations by analyzing the received cmd buf, and returns the corresponding data information.
[0074] MT7682_sdk This part is the MT7682 system code, using FreeRTOS system, including network configuration, network data forwarding, and code for configuring the built-in MCU function. Since the product is in low-power active state, only MT7682 is in low-power operation, so the peripheral resources such as PIR human infrared sensor and doorbell button are connected to the built-in MCU of MT7682, and the function of waking up the device through the MCU is processed.
[0075] z7682_inf_t31 This part is the driver code for registering the Ethernet card of MT7682 on T31. The secondary driver is loaded on T31, which can generate a network interface named eth0, and can use the general socket method of Linux for network communication. For example, data interaction with the cloud server and data interaction with the mobile phone APP. In addition, after loading this driver, a / dev / z7682 device node will be generated in the T31 file system, and T31 can interact with MT7682 through the ioctl command of this node.
[0076] z7682_user This part is the application layer routine code on the T31 side. Through the application program, the / dev / z7682 device node is operated, and the ioctl is called to read information, including the following contents: network event capture: through the ioctl command Z7682_IOTC_LISTEN_LINK_CHANGE, when MT7682 successfully connects to WIFI, the command returns. The ioctl has a parameter (unit: ms), and the parameter means the timeout time. If it is timed out, it returns 0, and if it is wrong, it returns a negative value. The application program can write a while loop to constantly listen to this event. When LINK_CHANGE is listened to, it means that the network situation has changed, and the IP, DNS, MASK, MAC, DHCP, Gateway, etc. information can be read again, and the above network information is obtained through the ioctl command Z7682_IOTC_GET_IP_INFO, and is set to T31 through the system interface. Network configuration can be completed.
[0077] Network port configuration: upper layer network data flow determines whether the data goes through the MT7682 protocol stack or is transmitted to T31 according to the port number. The port range of the MT7682 end can be configured in the SDK of the MT7682. The default port range of the MT7682 protocol stack in the SDK is 54000-60000. The local random allocation port range of T31 can be obtained through cat / proc / sys / net / ipv4 / ip_local_port_range. The port range can be modified to (x, y) by setting the command echo 'x y'> / proc / sys / net / ipv4 / ip_local_port_range. The T31 end will obtain the port range of the MT7682 when loading the MT7682 driver. The range can also be obtained by calling the API to read the value in the MT7682 virtual register REG_INVALID_PORT.
[0078] In summary, the IOT Wifi is registered as an Ethernet card on the T31ZX chip side, and the T31 model chip transmits data to the IOT Wifi, and the overall system of the wifi network management solves the problems of the prior art.
[0079] The above only describes the preferred embodiments of the present application and is not intended to limit the present application. Those skilled in the art can make various modifications and changes to the embodiments of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.
Claims
1. A dual-protocol stack system for IoT Wi-Fi, characterized in that, The system includes: The main control chip is a high-performance H.265 / H.264 / JPEG SoC chip, which integrates a high-performance ISP image processing module with a maximum resolution of 2592*1920@30fps. It also integrates 128MB of DDR memory, has a maximum clock speed of 1.5GHz, and has complete peripheral interfaces required for applications, including USB, SDIO, and Ethernet, making it compatible with a variety of network camera products. The IoT Wi-Fi chip includes a microcontroller unit (MCU), a low-power 1x11n single-band Wi-Fi subsystem, and a power management unit (PMU). The IoT Wi-Fi chip incorporates an ARM Cortex-M4 processor with a floating-point unit, integrated with 1MB of flash memory, forming a highly integrated chipset. The Wi-Fi subsystem includes an 802.11b / g / n radio, baseband, and MAC for low-power and high-throughput application development. The IoT Wi-Fi chip also supports UART, I2C, SPI, I2S, PWM, SDIO, and ADC interfaces. The IoT Wifi chip uses SPI or SDIO as a traditional Wifi external chip for the main control chip. The main control chip maps the IoT Wifi chip to a network interface by loading the driver z7682inf.ko. The main control chip's audio and video protocol stack is bound to this network interface to create a network communication interface socket. The main control chip and the IoT Wifi chip transmit audio and video streams via SPI or SDIO. The IoT Wifi chip also runs a cloud server SDK to achieve keep-alive between the device and the cloud server, and has functions such as device network configuration, account binding, cloud communication, and OTA upgrade. The virtual network port and the IoT Wi-Fi network port mapped on the main control chip side share the same MAC and IP address. The data is distinguished as either data from the main control chip side or data from the IoT Wi-Fi chip side based on the different ports. The main control chip manages Wi-Fi through an API interface, using a proprietary protocol. The driver internally encapsulates the interfaces required for data transmission, including: Z7682_IOTC_POWEROFF, which controls the power off of the control system. Z7682_IOTC_FW_VERSION_READ, which obtains the IoT Wi-Fi version information. Z7682_IOTC_INT_MASK_READ for reading data Z7682_IOTC_INT_MASK_WRITE for writing data Z7682_IOTC_WKUP_INTF_READ, which reads interrupt wake-up events. Z7682_IOTC_GET_IP_INFO retrieves IoT Wi-Fi IP information. It communicates with the application layer of the IoT Wifi chip; the IoT Wifi chip distinguishes between IP network data and private protocol data based on different custom packet headers, and performs corresponding processing or forwarding. The main control chip is responsible for event processing during wake-up and operation, while the IoT Wifi chip is responsible for the function processing and keep-alive processing of peripherals during sleep.
2. The dual-protocol stack system for IoT Wi-Fi according to claim 1, characterized in that, The application layer of the main control chip and the IoT Wifi chip uses either SDIO or SPI interface as the underlying layer.
3. The dual-protocol stack system for IoT Wi-Fi according to claim 1, characterized in that, The IOTWifi chip is responsible for handling peripheral functions in sleep mode, including PIR human infrared sensing, button wake-up, and remote wake-up package.
4. A dual-protocol stack system for IoT Wi-Fi according to claim 1, characterized in that, The IOTWifi chip uses the FreeRTOS system, which includes network configuration, network data forwarding, and built-in MCU function configuration.
5. A dual-protocol stack system for IoT Wi-Fi according to claim 1, characterized in that, The IOTWifi chip registers the Ethernet card driver on the main control chip, loads the driver on the main control chip, generates a network port with the interface name eth0, and uses the Linux common socket method for network communication; in addition, after loading this driver, a / dev / z7682 device node will be generated in the file system of the main control chip, and the main control chip will interact with the IOTWifi chip through the ioctl command of this node.
6. A dual-protocol stack system for IoT Wi-Fi according to claim 5, characterized in that, The network communication using the Linux common socket method includes: data interaction with the cloud server and data interaction with the mobile APP.
7. A dual-protocol stack system for IoT Wi-Fi according to claim 1, characterized in that, The application layer settings on the main control chip side use routine code. The applications link_listen.c and ioctl_test.c operate on the / dev / z7682 device node and call ioctl to read information, including the following: Network event capture: via the ioctl command, represented as: Z7682_IOTC_LISTEN_LINK_CHANGE: This command returns after the IoT Wi-Fi chip successfully connects to Wi-Fi. This ioctl command takes a parameter in milliseconds (ms), representing the timeout period. It returns 0 if a timeout occurs and a negative value if an error occurs. The application should use a while loop to continuously listen for this event. When LINK_CHANGE is detected, it indicates a change in network conditions. The application then re-reads the IP, DNS, MASK, MAC, DHCP, and Gateway network information, which is represented by the ioctl command as follows: The Z7682_IOTC_GET_IP_INFO function obtains the above network information and sets the network information to the main control chip through the system interface, thus completing the network configuration.
8. A dual-protocol stack system for IoT Wi-Fi according to claim 7, characterized in that, The system also includes: network port configuration: The upper-layer network data stream determines whether the data is passed through the IoT Wi-Fi chip protocol stack or transparently transmitted to the main control chip based on the port number; The port range setting on the IoT Wifi chip side can be configured in the SDK of the IoT Wifi chip. By default, the port range of the IoT Wifi chip protocol stack in the SDK is 54000 – 60000. The main control chip obtains the locally randomly assigned port range using the command `cat / proc / sys / net / ipv4 / ip_local_port_range`. The port range can be modified to (x, y) by setting the command `echo 'xy' > / proc / sys / net / ipv4 / ip_local_port_range`. When loading the IoT Wifi chip driver, the main control chip will obtain the port range of the IoT Wifi chip, or it can obtain this range by calling the API to read the value in the virtual register REG_INVALID_PORT of the IoT Wifi chip.
9. A dual-protocol stack system for IoT Wi-Fi according to claim 1, characterized in that, The high-performance H.265 / H.264 / JPEG SoC chip mentioned above uses the T31 model chip, that is, the main control chip uses the T31 model chip, which has image processing capabilities, high encoding quality and low encoding bit rate; The IoT Wi-Fi chip uses the MT7682 model, which also supports UART, I2C, SPI, I2S, PWM, SDIO and ADC interfaces.
10. A dual-protocol stack system for IoT Wi-Fi according to claim 1, characterized in that, The event handling refers to the low-power sleep keep-alive products, including doorbells and door lock cameras. Each time the device starts up, the main control program needs to know what caused the main control to wake up. At this time, it can read the wake-up reason through the API. In addition, during the operation of the device, the event should be monitored in real time and the events triggered by button events should be handled at any time. The peripheral device's functional processing and keep-alive processing refer to the low-power sleep keep-alive product. In sleep mode, in order to ensure low power consumption and extend the product's battery life, the main control is powered off and cannot work. Only the Wi-Fi works to maintain a connection with the cloud server.
Citation Information
Patent Citations
Method for realizing unload protocol stack based on multi-core processor and hybrid operating system
CN102571912A
Wireless protocol stack and realization method thereof
CN107172139A