Data acquisition board supporting multi-protocol interface dynamic switching and configuration method thereof

Abstract

The invention relates to a data acquisition board supporting multi-protocol interface dynamic switching and a configuration method thereof. The acquisition board comprises a microprocessor module, an acquisition interface module and a software system, wherein the acquisition interface module consists of a GPIO (General Purpose Input / Output) port of the microprocessor module and a peripheral circuit. A plurality of GPIO (General Purpose Input / Output) ports of the acquisition interface module can be configured into a target port group, electrical characteristics (such as level conversion and pull-up resistance) are adjusted through a peripheral circuit, and protocols such as UART (Universal Asynchronous Receiver / Transmitter), IIC (Inter-Integrated Circuit) and SPI (Serial Peripheral Interface) are A software system analyzes a configuration command, a GPIO port is dynamically recombined into a new target port group (formed by continuous / discontinuous GPIO ports), and flexible switching of the number of protocol signal lines (for example, a two-line IIC is converted into a four-line SPI) is supported. And during switching, a logic of firstly configuring a new interface and then breaking an old interface is adopted, so that the service continuity is ensured. According to the method, hardware does not need to be replaced, multi-protocol adaptation is achieved through local / remote configuration, the method is suitable for miniature intelligent weather stations, environment monitoring and other scenes, operation and maintenance cost is reduced, and data collection continuity is improved.

Description

Technical Field

[0001] This invention relates to the field of embedded systems and data acquisition technology, specifically a data acquisition board and its configuration method that support dynamic switching of multiple protocol interfaces. More particularly, it relates to a data acquisition board and its configuration method that support dynamic switching of multiple protocol interfaces for micro intelligent weather stations. Background Technology

[0002] In existing technologies, miniature intelligent weather stations, as highly integrated, modular, and intelligent automatic meteorological observation equipment, have become the mainstay of social meteorological observation. They are capable of all-weather, high-precision on-site measurements of various meteorological elements such as wind direction, wind speed, rainfall, temperature, humidity, atmospheric pressure, solar radiation, PM2.5, PM10, and TVOC. Their core component, the data acquisition board, is typically designed based on a high-performance, low-power microprocessor and connects to sensors through a pre-set fixed communication interface to achieve data acquisition, processing, and remote transmission.

[0003] However, this type of data acquisition board has a significant technical drawback: its external communication interface is fixed in both hardware and software configurations, making it impossible to dynamically modify or reconfigure it based on changes in the model, manufacturer, or protocol of the connected sensors. This fundamental limitation results in extremely poor adaptability and flexibility when facing necessary replacements, upgrades, or expansions of field sensors, leading to a series of specific technical problems.

[0004] Specifically, in practical applications, the shortcomings of this technology manifest in several ways:

[0005] 1. In regional air quality monitoring scenarios, when it is necessary to replace the original PM2.5 / PM10 sensor with a UART interface with a similar sensor from another manufacturer that has higher accuracy but uses an SPI interface, the data acquisition board interface is fixed and cannot be adjusted. The new sensor cannot establish an effective connection with it, which makes it impossible for the data acquisition board to receive and process new air quality data. This seriously affects the real-time and accurate monitoring of changes in air quality in the region and the continuity of data, making it difficult for relevant departments to obtain accurate information and make effective decisions.

[0006] 2. In highway meteorological monitoring scenarios, if the original wind sensor based on the IIC interface fails and needs to be replaced with a new sensor that only supports the RS-485 interface, the data acquisition board with the fixed interface cannot adapt to the new communication protocol, causing the wind speed data acquisition function to be interrupted. As a result, highway management departments cannot obtain timely information on wind speed changes in key road sections, and may be unable to initiate traffic control and other response measures in a timely manner during severe weather such as strong winds, thus creating potential traffic safety hazards.

[0007] 3. In airport meteorological observation scenarios, to improve flight safety, it is necessary to upgrade the existing UART interface barometric pressure sensors to high-precision models using a CAN bus interface. However, because the data acquisition board interface type cannot be dynamically switched, the new sensor cannot be recognized and connected, resulting in missing atmospheric pressure data. This makes it difficult for airport meteorological departments to accurately grasp the air pressure changes in the airport area, providing insufficient data support for aircraft takeoff and landing decisions, which may adversely affect flight safety.

[0008] In summary, existing data acquisition boards with fixed interfaces struggle to meet the interface compatibility challenges brought about by the iteration of sensor technologies and the diversification of equipment. Their inherently rigid architecture not only results in high maintenance and upgrade costs and cumbersome processes, but may also lead to the interruption of critical meteorological monitoring operations, decreased data integrity and reliability, and ultimately fail to meet the urgent needs of modern meteorological monitoring systems for high flexibility, high reliability, and intelligent operation and maintenance.

[0009] Among the various communication interfaces involved in the data acquisition board of the miniature intelligent weather station, the number of signal lines required for electrical connections differs depending on the type of interface, as detailed below:

[0010] RS-232 interface: RS-232 communication usually only requires 9 wires. In scenarios where only basic data transmission functions are needed, a three-wire connection is sufficient, namely the transmit line (TX), the receive line (RX), and the ground line (GND).

[0011] RS-485 interface: In two-wire (half-duplex) mode, plus a ground wire to reduce interference, at least three wires are generally required to complete the basic electrical connection.

[0012] UART interface: Generally, at least three wires are required: TXD (transmit), RXD (receive) and GND (ground).

[0013] IIC Interface: The IIC interface requires only two wires for communication: the serial clock line SCL and the serial data line SDA. In addition, to ensure that the SCL and SDA lines can be pulled high, pull-up resistors are usually connected to the power supply (such as +VDD). From the perspective of core electrical connection, the common connection method is two data lines plus a ground line.

[0014] SPI Interface: The SPI interface typically consists of 4 lines, including Master Output Slave Input (MOSI), Master Input Slave Output (MISO), Serial Clock (SCK), and Slave Select (SS).

[0015] The information disclosed in this background section is intended only to enhance the understanding of the general background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0016] To address the shortcomings of existing technologies, the present invention aims to provide a data acquisition board and its configuration method that support dynamic switching of multiple protocol interfaces. This addresses the problem that existing data acquisition boards have fixed and unmodifiable external communication interfaces, leading to data acquisition failures when the communication interfaces of connected sensors change. The invention improves the data acquisition board's adaptability to sensors with different interface protocols, enabling flexible configuration and dynamic switching of external communication interfaces. This meets the data acquisition needs of micro-intelligent weather stations in meteorological, environmental, power, highway, airport, and hydrological industries for different types of sensors, enhances the scalability and adaptability of the data acquisition board, and ensures the continuity and reliability of data acquisition.

[0017] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0018] A data acquisition board supporting dynamic switching of multiple protocol interfaces, characterized in that it includes:

[0019] Microprocessor module;

[0020] The acquisition interface module is connected to the microprocessor module and consists of multiple GPIO ports of the microprocessor module and peripheral circuits connected thereto; at least two of the multiple GPIO ports are configured as a target port group; the peripheral circuits are configured to adjust the electrical characteristics of the GPIO ports to adapt to different interface protocols.

[0021] It is understood that in this invention, the logical relationship between "GPIO port" and "target port group" is communication "hardware basic unit → functional collection unit," and the target port group is the smallest unit with communication capability. Each GPIO port is a hardware basic unit whose electrical characteristics can be configured independently, but at least two GPIO ports must be combined to form a "target port group" in order to be configured as a communication protocol interface and become a functional unit with complete communication capability. That is, a GPIO port is the hardware basic unit of the acquisition interface module, and its output mode can be set by software. It does not have complete communication capability on its own and only has basic hardware capabilities such as "electrical characteristic adjustment" and "pin function configuration." It cannot independently adapt to protocols and realize data transmission. The target port group consists of at least two GPIO ports and is the smallest unit "configured as a communication interface supporting the target interface protocol." It has complete communication capability, can independently adapt to protocols such as IIC / SPI / UART, and realize sensor data transmission. It is the main carrier of the "communication capability" of this invention.

[0022] The parameter configuration module, connected to the microprocessor module, is used to receive configuration commands transmitted by the command receiving module and send execution responses of the configuration commands to the host computer or the cloud.

[0023] The software system running on the microprocessor module includes:

[0024] The command receiving module is used to uniformly receive configuration commands and query commands issued by the host computer or cloud, and to verify the configuration commands. The configuration commands are passed to the parameter configuration module, and the query commands are passed to the query module.

[0025] The query module is used to receive query commands transmitted by the command receiving module and return the current configuration status of the target port group and / or the currently supported interface protocols to the host computer or cloud.

[0026] The interface configuration module is used to parse the configuration command after the configuration command passes the verification to determine the target port group and target interface protocol to be configured, and to call the corresponding interface protocol to configure the target port group as a communication interface that supports the target interface protocol.

[0027] Based on the above technical solution, the microprocessor module is configured to set the GPIO port to open-drain output or push-pull output mode via software; the peripheral circuit of the acquisition interface module is configured to adapt and adjust the electrical characteristics of the GPIO port.

[0028] It should be noted that the open-drain / push-pull output mode setting is performed on the GPIO ports in the target port group. The purpose is to ensure that the entire target port group meets the electrical timing requirements of the corresponding protocol (such as the IIC protocol, which requires all GPIO ports in the target port group to be set to open-drain output).

[0029] Based on the above technical solution, the interface configuration module parses the configuration command to determine a target port group, the target port group includes at least two GPIO ports, the GPIO ports are numbered consecutively or non-consecutively, and the target port group is configured as the corresponding communication protocol interface according to the configuration command.

[0030] It is understood that the continuous or non-continuous GPIO ports refer to whether the port numbers are continuous or non-continuous;

[0031] Alternatively, in response to a configuration command, the interface configuration module may recombine GPIO ports originally belonging to different target port groups and assign them to new target port groups to dynamically adapt to the target interface protocol's requirements for the number of physical signal lines.

[0032] Based on the above technical solution, the software system also includes an interface protocol module, which is configured to store and support multiple interface protocols, including one or more of UART, IIC, SPI, RS-232, RS-485 and CAN bus protocols.

[0033] Based on the above technical solution, the configuration command includes a port field for identifying the target port group, a target interface protocol field for identifying the target interface protocol, and a parameter field for configuring communication parameters.

[0034] It is understandable that the target port group identified by the port field consists of several GPIO ports. The port field includes the port numbers of the GPIO ports that make up the target port group, and the port numbers may be consecutive or non-consecutive.

[0035] Based on the above technical solution, it also includes a data storage module and a DMA data processing module. The DMA data processing module is connected to the acquisition interface module and the data storage module respectively. The DMA data processing module is configured to directly transmit sensor data to the data storage module without the participation of the microprocessor module.

[0036] Based on the above technical solution, a 4G communication module is also included, which is connected to the microprocessor module and is used to wirelessly transmit data with the host computer or cloud via a mobile network.

[0037] A configuration method for a data acquisition board supporting dynamic switching of multiple protocol interfaces as described above, characterized by comprising the following steps:

[0038] Receive configuration commands from the host computer or the cloud;

[0039] Verify the completeness and correctness of the configuration commands;

[0040] If the verification passes, then parse the port field and target interface protocol field in the configuration command;

[0041] Configuring the target port group specifically includes: configuring the target port group corresponding to the port field as a communication interface that supports the target interface protocol, according to the target interface protocol corresponding to the target interface protocol field;

[0042] For example, configuring the target port group specifically includes: calling a pre-stored protocol driver according to the target interface protocol; setting the software function mode (open-drain or push-pull output) and communication parameters (such as baud rate) of each GPIO port in the target port group; configuring the peripheral circuits (such as level conversion and pull-up resistors) connected to the target port group, thereby configuring the target port group as a communication interface that supports the target interface protocol.

[0043] Based on the above technical solution, after parsing the configuration command and before configuring the target port group, the following is also included:

[0044] Query the current status of the target port group corresponding to the port field;

[0045] If the current state is occupied, first find and configure an idle target port group for the new target interface protocol; after the newly configured interface passes data verification, deregulate the current configuration of the original target port group.

[0046] Based on the above technical solution, when a hardware fault is detected during the configuration of the target port group, the following fallback configuration steps are executed:

[0047] Release at least one target port group with the lowest priority that is already occupied, based on a predefined list of sensor priorities;

[0048] The released target port group is reconfigured to the target interface protocol as a backup interface;

[0049] Send fault information and downgrade configuration results to the host computer or cloud;

[0050] After the backup interface is running stably, disconnect the GPIO port in the original faulty target port group.

[0051] This invention discloses a data acquisition board and its configuration method that support dynamic switching of multiple protocol interfaces. It is used for data acquisition in a micro-intelligent weather station. Through hardware and software collaboration, it receives configuration commands from a host computer or cloud platform, enabling flexible configuration and dynamic switching of the data acquisition board's interfaces. This supports data acquisition from sensors with different interface protocols, effectively improving the compatibility and adaptability of the data acquisition board to sensors from different manufacturers and of different types. It has the following beneficial effects:

[0052] 1. The core feature of this data acquisition board lies in its flexible modification of the external communication interface, including:

[0053] In terms of hardware, the acquisition interface module consists of multiple GPIO ports of the microprocessor module (e.g., 24 ports numbered P1-P24) and peripheral circuitry. Each GPIO port can be independently configured by software to open-drain or push-pull output modes, and its electrical characteristics (such as voltage levels) can be adjusted using pull-up resistors or level conversion circuits, providing a hardware foundation for protocol adaptation.

[0054] In terms of software, the interface configuration module in the software system can receive and parse the configuration commands issued by the host computer, determine the target port group and target interface protocol to be configured, and call the corresponding protocol driver stored in the interface protocol module, so as to finally realize the reconstruction and conversion of GPIO port functions.

[0055] When the model or manufacturer of the connected sensor changes, resulting in a different external interface, there is no need to replace the data acquisition board. Simply send configuration commands through the host computer or cloud to reconfigure the specified GPIO ports into a new target port group, and configure the target port group as the corresponding communication interface, such as serial interface (RS-232, RS-485), UART interface, IIC interface, SPI interface, etc., to achieve effective connection and data acquisition of the new sensor, thereby enhancing the scalability and adaptability of the data acquisition board.

[0056] Compared to existing data acquisition boards with fixed interfaces, this invention uses dynamic software configuration to enable it to adapt to a wider range of sensor interface protocols, which are no longer limited by hardware design. Theoretically, it is only constrained by the number of microprocessor GPIO ports, thus significantly enhancing scalability and adaptability.

[0057] 2. This data acquisition board can remotely switch any interface of outdoor deployed equipment without interrupting business operations. This is thanks to the collaborative work of the command receiving task and the interface configuration task in the software system: the command receiving task is responsible for receiving remote configuration commands and verifying their integrity and correctness. After receiving the notification, the interface configuration task parses the command, first checks the port usage status, and if the port has been used, disconnects the current interface and then configures it as a new interface.

[0058] When a sensor needs to be replaced, the designated port can be configured as the interface required by the new sensor and the new sensor can be connected. After the new sensor is working normally, the original interface can be disconnected. This ensures the continuity and stability of data acquisition, reduces business interruption caused by sensor replacement, and improves the operational efficiency and reliability of the micro intelligent weather station in meteorological, environmental, power, highway, airport, hydrological and other industry applications.

[0059] 3. The hardware circuit board and embedded software of the data acquisition board are consistent for sensors with different interfaces. Hardware compatibility is achieved through the GPIO port of the microprocessor module and the peripheral circuits connected to it (including adjustable level conversion circuits, pull-up resistors, etc.). Software compatibility is achieved through the interface protocol module, which uniformly manages various interface protocols. There is no need to design dedicated hardware or software for different sensors. Adaptation can be achieved simply by configuring the interface, which reduces the cost and complexity of equipment maintenance and upgrades, and makes it better able to meet the needs of modern meteorological observation for equipment flexibility and intelligent operation and maintenance. Attached Figure Description

[0060] The present invention includes the following figures:

[0061] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0062] Figure 1 The present invention provides a structural block diagram of a data acquisition board that supports dynamic switching of multiple protocol interfaces.

[0063] Figure 2 The present invention provides a software system architecture diagram for a data acquisition board that supports dynamic switching of multiple protocol interfaces.

[0064] Figure 3 Interface configuration task flowchart.

[0065] Figure 4 Command receiving task flowchart.

[0066] Figure 5 A schematic diagram illustrating an embodiment of the configuration method for a data acquisition board that supports dynamic switching of multiple protocol interfaces as described in this invention. Detailed Implementation

[0067] The present invention will be further described in detail below with reference to the accompanying drawings. This detailed description is an illustration in conjunction with exemplary embodiments of the invention, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0068] This invention presents a data acquisition board and its configuration method that support dynamic switching of multiple protocol interfaces. Addressing the shortcomings of fixed interfaces in existing data acquisition boards, this invention combines hardware circuit boards with embedded software to enable the data acquisition board to flexibly configure specified ports according to configuration commands sent from a host computer or cloud platform. This supports multiple communication interfaces such as serial interfaces (RS-232, RS-485), UART interfaces, IIC interfaces, and SPI interfaces, thus adapting to sensors from different manufacturers and of different types. This solves the problem of data acquisition interruption caused by interface incompatibility in existing technologies, improving the overall operational efficiency of micro-intelligent weather stations. The core design goal of the data acquisition board is to achieve flexible modification and dynamic adaptation of external communication interfaces. The communication interface, as the key channel for data transmission between the sensor and the data acquisition board, covers various commonly used types such as serial interfaces (RS-232, RS-485), UART interfaces, IIC interfaces, and SPI interfaces. Because different manufacturers and types of sensors have different external communication interfaces, this invention adopts a design concept of "hardware universalization (configurable GPIO ports based on microprocessors + adjustable peripheral circuits) + software configurability" to ensure that the hardware circuit board and embedded software of the data acquisition board remain consistent when adapting to different sensors. At the hardware level, it is based on the GPIO ports (General-purpose input / output) of the microprocessor module, and relies on adjustable peripheral circuits (such as pull-up resistors, level conversion circuits, bus driver chips, etc.) to adapt to the electrical characteristics of different interface protocols, achieving basic hardware compatibility. At the software level, various interface protocols are uniformly managed through the interface protocol module. When the sensor and the current interface of the acquisition board are incompatible, the host computer only needs to issue a configuration command, and the data acquisition board can parse the target interface requirements according to the command, dynamically combine the corresponding GPIO ports into a target port group, and configure the target port group as the required communication interface, thereby completing the effective connection of the sensor and data acquisition.

[0069] Based on the electrical connection signal line requirements of the different interfaces mentioned above, in practical applications, the data acquisition board can flexibly combine and configure the 24 GPIO ports (port numbers P1-P24, led out via connectors to interface with sensors) according to the signal line requirements of the sensor interface type. For example, if it is necessary to collect data from 7 types of sensors (temperature and humidity sensor, air pressure sensor, wind sensor, optical rain sensor, solar radiation sensor, PM2.5 / PM10 air quality sensor, and TVOC sensor), the IIC interface sensors (temperature and humidity, air pressure) that require 2-wire connection can be configured with 2 ports as a group, the SPI interface sensors (wind and optical rain) that require 4-wire connection can be configured with 4 ports as a group, and the UART interface sensors (solar radiation, PM2.5 / PM10, and TVOC) that require 2-wire connection can be configured with 2 ports as a group, thereby achieving precise connection between the sensors and the acquisition board. When the sensor model or manufacturer changes, resulting in a change in the interface type (such as replacing the original UART interface optical rain sensor with an SPI interface model), the ports can be recombined according to the signal line requirements of the new interface through local or remote configuration commands. The original two ports corresponding to the UART are the GPIO ports P17-P18 of the microprocessor module, and the two newly added ports are the idle GPIO ports P19-P20. The interface configuration module will recombine these four GPIO ports P17-P20 into a new target port group and configure it as an SPI interface to ensure seamless adaptation to the new sensor.

[0070] It should be noted that in this invention, "GPIO port" and "pin" are used interchangeably in the acquisition interface module. The 24 GPIO ports (port numbers P1-P24) are brought out through various connectors and can be flexibly combined according to the signal line requirements of different interfaces to adapt to the corresponding sensors. For example, if it is necessary to collect data from 7 types of sensors (temperature and humidity sensor, air pressure sensor, wind sensor, optical rain sensor, solar radiation sensor, PM2.5 / PM10 air quality sensor, and TVOC sensor), the IIC interface sensors (temperature and humidity, air pressure) that require 2-wire connection can be configured with 2 ports as a group, the SPI interface sensors (wind and optical rain) that require 4-wire connection can be configured with 4 ports as a group, and the UART interface sensors (solar radiation, PM2.5 / PM10, and TVOC) that require 2-wire connection can be configured with 2 ports as a group, ensuring that the number of interface signal lines matches the number of ports. When the sensor model or manufacturer changes, resulting in a change in the interface type (such as replacing the optical rain sensor originally connected to the P17-P18 port and UART interface with an SPI interface model), the P17-P20 ports can be reconfigured as SPI interfaces according to the 4-wire requirement of the SPI interface through local or remote configuration commands, so as to achieve seamless connection of the new sensor.

[0071] like Figure 1 As shown, the data acquisition board of the present invention, which supports dynamic switching of multiple protocol interfaces, uses a microprocessor module as its core and coordinates with hardware and software systems to realize data acquisition with dynamic switching of multiple protocol interfaces. The specific module connections and functions are as follows:

[0072] Microprocessor module: As the "brain" of the system, it coordinates and controls the work of various modules, and is responsible for parsing instructions, scheduling data transmission, and driving interface configuration. The GPIO ports it provides are the basic resources for the acquisition interface module and are the core execution unit for data acquisition and protocol switching. As the system control core, the microprocessor module is responsible for coordinating and controlling the initialization configuration of all other functional modules. At the same time, it undertakes the task of acquiring and processing sensor data, can send control data to the sensors, and transmit all the data acquired by the sensors to the cloud through the 4G communication module.

[0073] The flexibly configurable data acquisition interface module consists of multiple GPIO ports of the microprocessor module and connected peripheral circuits (such as level conversion and protection circuits). Physical connectors serve as the carriers for connecting the GPIO ports to sensors. These GPIO ports can be configured via software to adapt to various protocols such as IIC, SPI, AD acquisition, and UART (protocol support is expandable). Ports can be grouped / combined, and protocol switching can meet the interface requirements of different sensors. The data acquisition interface module presents itself as a collection of configurable physical interfaces, which are brought out via connectors to connect to various sensor devices. Each GPIO port pin of the microprocessor can be configured via software as open-drain output or push-pull output mode. The supported voltage range can be flexibly adjusted via pull-up resistors or level conversion circuits within the module, thereby realizing the functions of multiple interfaces such as UART, IIC, and SPI. Furthermore, once each group of ports is configured as a specific interface, that interface is completely independent and will not conflict with other interfaces, ensuring the stability of parallel data acquisition from multiple sensors.

[0074] For example, the peripheral circuitry of the acquisition interface module includes, but is not limited to, level conversion circuitry (e.g., using a bidirectional level conversion chip such as TXB0104), analog switch arrays (e.g., using a multiplexer such as CD4067), and programmable pull-up / pull-down resistor networks; to achieve control of the above-mentioned configurable components, the general purpose input / output ports (GPIO) or serial communication interfaces (such as SPI, I2C) of the microprocessor module are connected to them, for example:

[0075] The channel selection address lines of the analog switch array are connected to multiple GPIO ports of the microprocessor module. The microprocessor selects different channels by outputting different binary level combinations to these address lines, thereby dynamically routing the pin signals of the microprocessor to different external physical lines.

[0076] The programmable pull-up / pull-down resistor network can be implemented by a digital potentiometer chip, which is connected to the microprocessor module via an I2C or SPI bus. The microprocessor dynamically sets the resistance value by sending instruction data packets to the bus. Alternatively, it can be implemented by a switching transistor array, where the microprocessor's GPIO port is directly connected to the control electrode of the transistor, and a specific resistor is connected to or disconnected from the circuit by outputting a high / low level.

[0077] The enable terminal of the level conversion circuit can be connected to a GPIO port of the microprocessor, and the entire group of level conversion channels can be enabled or disabled by controlling the level of the GPIO.

[0078] The microprocessor module controls its GPIO or serial interface to output the above electrical signals by running software, thereby changing the channel selection signal and resistor network connection status of the analog switch, and finally adjusting the electrical characteristics of the GPIO port group (such as level standard, output drive capability, termination matching) to adapt to the physical layer requirements of different interface protocols.

[0079] Through the above example, the microprocessor module changes the electrical characteristics (such as level standard, output drive capability, termination matching) of the GPIO port group by controlling the channel selection signal of the analog switch and the connection state of the resistor network, thereby adapting to the physical layer requirements of different interface protocols.

[0080] Parameter configuration module: As an interaction bridge between the host computer and the system, it receives configuration commands (such as interface protocol switching commands and parameter adjustment commands) issued by the host computer and passes them to the microprocessor module for execution; As the hardware circuit carrier for communication between the microprocessor module and the host computer, the parameter configuration module is specifically designed to receive query commands and configuration commands issued by the host computer to realize the interaction of local control commands.

[0081] Data storage module: Used for temporary or long-term storage of collected sensor data, relying on DMA (Direct Memory Access) technology to achieve high-speed transmission and storage of collected data; this mode does not require the full participation of the microprocessor, which can significantly improve data transmission efficiency and ensure the security of temporary or long-term storage of collected data; by directly moving data through the DMA module without the participation of the microprocessor core, the CPU computing power is freed up to handle tasks such as protocol switching more efficiently, thereby improving the overall data transmission efficiency of the system;

[0082] 4G communication module: Enables data interaction between the system and the cloud, supports wireless remote transmission, allows collected data to be uploaded to the cloud platform in real time, and can also receive configuration commands issued by the cloud; the 4G communication module is the hardware driver circuit for 4G wireless communication between the acquisition board and the host computer and the cloud, and can realize high-speed data transmission and bidirectional communication through the mobile network, supporting remote configuration command reception and data upload;

[0083] Host computer: As a local control terminal, it can directly send configuration commands, query system status, and realize local debugging and parameter setting; it can also indirectly collaborate with the cloud through the 4G communication module to complete remote management.

[0084] Technical Principle: By combining "general-purpose hardware design with dynamic software configuration," the GPIO ports of the acquisition interface module are made to break through the limitations of fixed protocols. Utilizing the software scheduling capabilities of the microprocessor module, the corresponding protocol logic (such as UART and SPI timing control code) is dynamically loaded according to instructions from the host computer / cloud, enabling the same GPIO port (as a hardware component of the target port group) to be compatible with multiple protocols and adapt to different sensors.

[0085] In a specific application example of the present invention, such as Figure 5 As shown, the data acquisition board needs to simultaneously acquire data from seven types of sensors: temperature and humidity sensor (IIC interface), barometric pressure sensor (IIC interface), wind sensor (SPI interface), optical rain gauge (SPI interface), solar radiation sensor (UART interface), PM2.5 / PM10 air quality sensor (UART interface), and TVOC sensor (UART interface). The acquisition interface module provides 24 GPIO ports, which can be brought out through connectors and flexibly combined into different interface types according to configuration commands.

[0086] For example:

[0087] Based on the IIC protocol's requirement for 2 wires, the GPIO ports P1-P2 of the acquisition interface module are combined into a target port group, and this target port group is configured as an IIC interface (SCL corresponds to P1, SDA corresponds to P2) to connect to the temperature and humidity sensor.

[0088] Combine GPIO ports P3-P4 into a target port group, configure this target port group as an IIC interface, and connect it to the barometric pressure sensor;

[0089] Based on the SPI protocol's requirement for 4 wires, GPIO ports P5-P8 (MOSI=P5, MISO=P6, SCK=P7, SS=P8) and P9-P12 (MOSI=P9, MISO=P10, SCK=P11, SS=P12) are combined into a target port group, and this target port group is configured as an SPI interface to connect the wind sensor and the optical rain sensor.

[0090] Based on the UART protocol's requirement for 2 wires, GPIO ports P13-P14 (TX=P13, RX=P14), P15-P16 (TX=P15, RX=P16), and P17-P18 (TX=P17, RX=P18) are combined into target port groups, and these target port groups are configured as UART interfaces to connect the solar radiation sensor, air quality sensor, and TVOC sensor.

[0091] The UART interface, as a protocol, requires two wires. The third wire, the ground wire, is a common loop, brought out by the connector on the data acquisition board. It does not occupy configurable GPIO port resources. See the example below. Figure 5 As shown.

[0092] When a sensor's interface protocol changes due to a change in model or manufacturer, the ports can be reconfigured by issuing configuration commands locally or remotely. For example, if an optical rain sensor with a UART interface is replaced with a new sensor with an SPI interface, GPIO ports P17-P20 can be reconfigured into a target port group via commands, and this target port group can be configured as an SPI interface to achieve seamless switching.

[0093] To achieve the above functions, the software system runs two core tasks:

[0094] Command receiving task: Responsible for receiving and verifying the integrity and correctness of configuration commands;

[0095] Interface configuration task: After receiving a valid command, parse the GPIO port and the target interface protocol, check whether the interface protocol module supports the protocol, call the corresponding protocol driver in the interface protocol module, and complete the port reconstruction.

[0096] The interface configuration command format is as follows:

[0097] Data header: 3 bytes, control bits: 1 byte (identified as configuration command), interface identifier: 2 bytes, port identifier: 4 bytes, communication parameters: 8 bytes, checksum: 1 byte.

[0098] The interface query command format is as follows:

[0099] Data header: 3 bytes, control bits: 1 byte (identifies as a query command), interface identifier: 2 bytes (identifies supported interface protocols), port identifier: 8 bytes (identifies the status of each port), checksum: 1 byte.

[0100] Through the aforementioned hardware and software collaboration mechanism, this invention can achieve local or remote dynamic switching of interfaces without interrupting existing data acquisition services, significantly improving the adaptability and maintainability of the equipment.

[0101] Detailed implementation of the downgrade configuration function:

[0102] To further enhance system reliability and address sudden hardware port failures, this data acquisition board incorporates a downgrade configuration function. The following section combines... Figure 3 (Interface configuration task flowchart) Detailed explanation of its specific implementation process. Figure 3 This process is suitable for scenarios where the original target port group needs to be reconfigured for other protocols after it has been released:

[0103] When the interface configuration task is executing the configuration command (corresponding to...) Figure 3 In the "Configure Port Properties" step, when the GPIO status of the microprocessor module is read, and a hardware fault such as a continuous low / high level, signal line to ground / power supply short circuit is detected in the target port group, the degradation configuration process is triggered.

[0104] The system first accesses the "sensor priority list" stored in the microprocessor module's FLASH memory. This list is preset by maintenance personnel according to the application scenario, defining the criticality of each sensor's data acquisition. Taking a miniature intelligent weather station as an example, its priorities from high to low are: wind sensor > barometric pressure sensor > temperature and humidity sensor > optical rainfall sensor > PM2.5 / PM10 sensor > solar radiation sensor > TVOC sensor.

[0105] The interface configuration task then uses this list to filter out the target port group that is currently occupied and has the lowest priority (e.g., the port group connected to the TVOC sensor), notifies the parameter configuration module to send a sleep command to the sensor it is connected to, and then calls the interface protocol module to unload its current protocol driver and release the port group resources.

[0106] Next, the interface configuration task reconfigures the newly released port group to the original target interface protocol, forming a backup interface. The parameter configuration module immediately sends an alarm message containing the faulty port ID, fault type, and backup port ID to the host computer or cloud via the 4G communication module.

[0107] Subsequently, the system continuously monitors the backup interface. If the data frames received through this interface are verified correctly within three consecutive data acquisition cycles, it is determined that the interface is operating stably. Then, the microprocessor module controls the I / O expansion chip or MOSFET switching circuit to disconnect the original faulty port, completing hardware isolation and ensuring that other high-priority data acquisition services are not affected.

[0108] It should be noted that the division between the "acquisition interface module" and the "microprocessor module" in this invention is primarily based on functional description rather than strict physical isolation. The physical core of the acquisition interface module is the GPIO pins of the microprocessor module. The innovation of this invention lies in dynamically configuring the functional modes of these GPIO pins through software, and combining this with adjustable peripheral circuitry within the module, thereby achieving flexible reconfiguration and dynamic switching of the external communication interface protocol.

[0109] Based on the above technical solutions, such as Figure 2 As shown, the software system relies on an embedded real-time operating system to build a layered collaborative architecture, realizing efficient scheduling of dynamic switching of multiple protocol interfaces. The following will explain the module composition, technical principles, and workflow.

[0110] The software system includes the following two core tasks for implementing dynamic configuration of the interface:

[0111] Command receiving task: Running at the application layer, it receives configuration commands issued by the host computer or cloud through the 4G communication module or local serial port, verifies the data header, control bits and checksum to ensure the integrity and legality of the command;

[0112] Interface configuration task: After the command receiving task verification passes, the command content is parsed to obtain the GPIO port and target interface protocol. It checks whether the interface protocol module supports the protocol. If supported, the corresponding protocol driver is called to complete the port configuration; otherwise, an error code is returned. The protocol driver is the software module that adapts to the target interface protocol and drives the GPIO port to complete the configuration according to the protocol specification. Its core function is to enable the hardware port (GPIO port) to recognize and follow the specifications of a specific protocol (target interface protocol), thereby completing protocol-related port configurations (such as protocol parameter initialization and data interaction logic adaptation).

[0113] These two tasks communicate and synchronize through the message queue or semaphore mechanism of the embedded operating system to ensure the real-time performance and reliability of the configuration process.

[0114] The software modules are composed (layered logic) as follows:

[0115] Application layer: Serves as the entry point for functions and contains various functional modules.

[0116] 4G communication module: responsible for establishing a 4G wireless connection with the cloud / host computer, sending and receiving configuration commands, and uploading collected data;

[0117] UART module for debugging: Provides a debugging channel for software development and data acquisition board maintenance, and supports serial port command transmission and reception, system status query (such as interface configuration status, sensor connection status);

[0118] Data statistics and quality control module: Statistical data collection frequency, interface switching count, data transmission success rate and other operational indicators to assist in operation and maintenance analysis;

[0119] SD card storage module: Enables local data caching (such as raw sensor data and configuration logs) to meet data storage needs during network interruptions;

[0120] Interface configuration module: Receives and parses configuration commands, and calls the interface protocol module to complete the protocol switching of the data acquisition interface (core function carrier).

[0121] Command receiving module: listens for commands from the host computer / cloud, verifies the completeness and validity of configuration commands, and triggers subsequent configuration processes.

[0122] Application layer support layer: Provides basic services for application layer functions.

[0123] Interface configuration command parsing: Parses configuration commands from the debug port UART and 4G communication module, extracting key information such as GPIO port and protocol type;

[0124] Interface protocol module: Implements protocols such as UART, IIC, and SPI, loads the corresponding protocol according to the configuration instructions, and reconstructs the communication logic of the acquisition interface;

[0125] DMA data processing module: Through DMA (Direct Memory Access) technology, sensor data is written directly to the memory / storage module, bypassing the CPU, thus improving data transmission efficiency.

[0126] Operating System Layer: Based on an embedded real-time operating system (such as RTOS), it provides basic capabilities such as task scheduling, memory management, and hardware driver abstraction, ensuring concurrent execution of multiple tasks (such as simultaneous processing of interface configuration, data acquisition, and 4G communication), and ensuring the real-time performance of interface switching and data transmission.

[0127] Device driver layer: interfaces with hardware resources, including:

[0128] 4G driver: Implements the initialization, network connection, and data transmission / reception driver for the 4G communication module;

[0129] SD card driver: Supports read and write operations for SD cards, adapting to storage devices of different capacities / protocols;

[0130] Serial port driver: Drives serial communication between the debug port UART and the acquisition interface, and configures parameters such as baud rate and data bits;

[0131] Other hardware drivers: These cover the driver logic for basic hardware such as power management and GPIO control, providing hardware operation interfaces for upper-layer functions.

[0132] Technical Principle: Through a "layered decoupling + real-time scheduling" design, the software system, supported by an embedded real-time operating system, achieves full-process automation of "command reception - parsing - protocol switching - data acquisition". Utilizing the "interface protocol module" of the application layer support layer, the physical port of the hardware acquisition interface is decoupled from the protocol logic, allowing the same port to dynamically adapt to multiple types of sensors by loading different protocol drivers.

[0133] The software system of this invention is an embedded software system running on a microprocessor module. Its code is stored in the on-chip FLASH of the microprocessor, and it mainly includes the following core functional modules, which work together based on a layered architecture:

[0134] Interface Protocol Module: Implements all interface protocols supported by the current system (including UART, IIC, SPI, RS-232, RS-485 and CAN bus protocols). When configuring a port via local or remote commands, this module will first check whether the interface protocol specified by the command is supported, providing protocol support for port configuration.

[0135] DMA data processing module: It is connected to the GPIO port of the acquisition interface module and the data storage module respectively. Through DMA technology, it directly captures the sensor data received by the GPIO port (such as temperature and humidity data from IIC interface GPIO ports P1-P2 and wind measurement data from SPI interface GPIO ports P5-P8) without the participation of the microprocessor module, and transmits the data to the memory or data storage module, thereby improving data transmission efficiency.

[0136] Data storage module: Responsible for saving and managing all collected data. It can store raw sensor data and processed analysis data according to actual usage needs, and also supports local caching (such as SD card storage) and data backup.

[0137] Command receiving module: Receives configuration commands and query commands through a local serial port (such as a debug port UART) or a remote 4G communication link, verifies the data header, control bits, and checksum of the command to ensure integrity and correctness, and notifies the interface configuration module to perform subsequent operations after the verification is successful;

[0138] Interface Configuration Module: Receives valid configuration commands from the receiving module, parses the GPIO port, target interface protocol, and communication parameters (such as communication rate, data bits, stop bits, etc.) specified in the command, calls the corresponding protocol driver from the interface protocol module, configures the GPIO port to the specified communication protocol, and realizes dynamic interface switching.

[0139] Operating system layer (i.e., embedded operating system module): Based on an embedded real-time operating system (such as RTOS), it performs task scheduling and resource allocation for all functional modules in the software system, realizes coordination and cooperation between modules, and ensures the real-time performance of concurrent execution of multiple tasks (such as data acquisition, interface configuration, 4G communication).

[0140] Device driver layer (i.e. hardware driver module): Completes driver adaptation for physical layer hardware circuits (such as 4G communication modules, SD cards, serial ports, GPIO ports, etc.), provides standardized hardware operation interfaces, and is the basic support for the implementation of functions of upper-layer software functional modules.

[0141] The core innovation of this invention lies in enabling flexible configuration and dynamic changes of the external acquisition interface of the data acquisition board: the acquisition interface module can be configured by software to implement several external communication interfaces, each interface corresponding to a sensor that supports the same protocol; when it is necessary to replace the sensor with a different communication interface, no hardware modification is required, and the specified port can be reconfigured to the interface type required by the new sensor simply by issuing a configuration command locally or remotely, thus adapting to the diverse application needs of the data acquisition protocol of the micro intelligent weather station.

[0142] The specific application process is as follows: After the data acquisition board is powered on, the software system automatically starts and loads the default configuration according to the preset program, initializing all GPIO ports of the acquisition interface module as several default communication interfaces. At this time, the data acquisition board can establish data interaction with the currently connected sensors through these default interfaces to carry out meteorological element collection. When the micro intelligent weather station is deployed in different regions, and the observations to be collected (such as the addition of PM2.5 monitoring in one region or the replacement of high-precision wind sensors in another region) change, that is, when the sensor manufacturer or model changes or the external communication interface is different, a configuration command can be issued through the host computer or cloud to trigger dynamic interface reconfiguration.

[0143] This reconfiguration process is completed collaboratively by two core tasks of the software system:

[0144] Command receiving task: Real-time monitoring of configuration commands transmitted from local serial port or remote 4G communication link, and verification of the integrity and correctness of command frame header, control bits, checksum, etc.; if the entire command frame is correct, immediately send a notification to the interface configuration task.

[0145] Interface configuration task: Continuously wait for the command receiving task notification, immediately parse the command upon receiving the notification, extract the target port group and target interface protocol specified by the command; then check in the interface protocol module whether the target interface protocol is supported. If the corresponding protocol driver exists, configure the target port group of the acquisition interface module specified by the command as the output port of the protocol, complete the reconstruction of the new interface, and ensure that the new sensor can be connected and transmit data normally.

[0146] like Figure 1 (Data acquisition board structure diagram) Figure 2 As shown in the software system architecture diagram, the following are some typical workflows.

[0147] Typical Workflow 1: Hardware Collaboration Process - Interface Switching and Sensor Adaptation Example

[0148] This process focuses on the physical linkage of hardware modules and signal flow. Through a closed loop of "command triggering → hardware scheduling → physical interface reconstruction → data acquisition and verification," it achieves interface protocol switching and sensor adaptation, as detailed below:

[0149] Command trigger (hardware interaction entry point)

[0150] The host computer or cloud acts as the control terminal. Through the parameter configuration module (hardware carrier, supporting local command interaction) or the 4G communication module (hardware carrier, realizing remote wireless communication), configuration commands are sent to the microprocessor module (hardware core, coordinating instruction parsing and hardware scheduling) in the form of physical electrical signals / network data packets. The configuration commands specify the target port group to be configured (consisting of several GPIO ports) and the target interface protocol (such as switching the first target port group to the SPI protocol).

[0151] Hardware scheduling (multi-module linkage control)

[0152] After receiving a command, the microprocessor module parses the command (verifying its validity and extracting configuration parameters) and generates a protocol switching control signal. This signal directly drives the GPIO port in the acquisition interface module to perform the protocol switching action. The GPIO port is set to open-drain output or push-pull output mode (e.g., open-drain output for IIC protocol and push-pull output for UART protocol) by writing to the GPIO control register of the microprocessor module via software. At the same time, the pin communication timing parameters are modified. If synchronous data acquisition is required, the microprocessor module calls the DMA control interface of the data storage module (hardware storage unit) to trigger the DMA data direct transfer mode (bypassing the CPU and writing directly to the storage area to improve transmission efficiency) and pre-allocates hardware channels for data acquisition.

[0153] Physical interface reconstruction (hardware protocol adaptation)

[0154] The acquisition interface module responds to control signals. Its GPIO ports rely on the peripheral circuit design within the module (pull-up / pull-down resistors adjust electrical characteristics, level conversion circuits adapt to different voltage domains), and are configured with microprocessor registers (defining pin function multiplexing, clock division ratio, and data bit width) to complete protocol timing reconstruction (such as switching from UART asynchronous serial timing to SPI synchronous serial clock / data link), so that the physical port electrical characteristics and communication logic match the requirements of the new sensor protocol.

[0155] Data acquisition verification (hardware link closed-loop verification)

[0156] The new sensor connects to the reconstructed physical interface and starts data acquisition: the sensor output signal is transmitted to the microprocessor module via the hardware link of the acquisition interface module (GPIO port → level conversion → microprocessor signal input); the microprocessor module parses the data according to the new protocol (or transmits it to the data storage module for temporary storage), and transmits the data back to the host computer / cloud (or outputs it to the local debugging port) through the 4G communication module to verify the hardware connectivity and functional integrity of "interface protocol switching → sensor access → data acquisition → transmission link".

[0157] The core advantages of this process are:

[0158] Hardware reusability: By combining GPIO ports with register configuration and peripheral circuit design, a single hardware set can adapt to multiple protocol sensors such as IIC, SPI, and UART, eliminating the need for customized hardware, thus reducing costs and maintenance complexity;

[0159] Business continuity: When a GPIO port is occupied, the microprocessor module needs to schedule and configure a new interface on other ports first; after the new interface achieves normal data acquisition, the original interface is then disconnected; through this operation sequence of "configuring a new interface first, verifying normal acquisition, and then disconnecting the original interface", the data acquisition of other sensors is not interrupted when the sensor is replaced.

[0160] It should be noted that the term "other sensors" refers to all sensors connected to the microprocessor module and acquiring data through other independent ports, excluding the target sensor currently being replaced. Examples include sensors in the same monitoring system that share the same microprocessor as the sensor being replaced but acquire different parameters such as temperature, pressure, and flow through different ports; or other sensors of the same type but installed in different locations, whose acquisition ports do not conflict with the original port of the sensor being replaced. These sensors' acquisition ports do not overlap with the original port or the newly configured GPIO port of the sensor being replaced, and they are independent units that perform data acquisition in parallel.

[0161] If the step of "configuring the new interface and verifying normal acquisition" is skipped and the original interface is disconnected directly, or the original interface is forcibly disconnected before the new interface is stable in acquiring data, port resource scheduling conflicts will occur in the system during the gap between "original interface disconnection and new interface taking effect" (such as temporary occupation of the data bus or abnormal switching of port drivers). This conflict will spread to the acquisition links of other sensors, causing the data acquired by other sensors to be unable to be transmitted to the microprocessor normally through the data bus, resulting in data interruption (acquisition values ​​are not updated for a long time) or data loss (values ​​of some acquisition cycles are not recorded).

[0162] If a new interface is configured on a different port instead of another port, and the configuration is forcibly overwritten on the existing port, a port conflict will be triggered, causing the microprocessor's port driver to report an error. This error may interfere with the system's scheduling logic for other normal ports (such as chaotic port resource allocation or abnormal data frame parsing rules), causing errors (such as values ​​jumping to invalid ranges or repeated uploading of the same value) or distortions (such as decreased acquisition accuracy or data delays exceeding the allowable range) in the data uploaded by other sensors, thus losing the validity of the data.

[0163] If the original interface is disconnected without first ensuring that the new interface is collecting data normally, the "port-sensor" mapping relationship of the microprocessor may be temporarily disordered (such as the system mistakenly associating the acquisition port of other sensors with the interrupt logic of the original interface). This disorder will cause the system to send acquisition commands to other sensors abnormally (such as command delay or command repetition), which will in turn cause the acquisition cycle of other sensors to be disordered, making it impossible to complete data acquisition at the preset frequency and destroying the stability of the overall monitoring system.

[0164] Remote and local collaboration: Supports local debugging on the host computer and remote management via 4G cloud, covering operation and maintenance needs in multiple scenarios such as outdoor weather stations, and allows for interface switching and adaptation to new devices without the need for on-site personnel.

[0165] It should be noted that replacing the old sensor with a new one requires a human presence, while the switchover can be done remotely without a human presence.

[0166] Typical Workflow 2: Software Scheduling Process - Interface Switching and Sensor Adaptation Example

[0167] This process focuses on software module logic parsing and task scheduling. Relying on an embedded real-time operating system, it achieves dynamic interface switching through a process of "instruction reception → software parsing → driver scheduling → data closure," as detailed below:

[0168] Command reception (software interaction entry point)

[0169] The application layer command receiving module (software functional unit) captures configuration commands sent by the host computer / cloud through a 4G communication module driver (software driver, adapted for remote communication) or a serial port driver (software driver, adapted for local debugging) and performs preliminary verification of the command format (such as data header matching and length compliance).

[0170] Software parsing and protocol scheduling

[0171] The application layer support layer command parsing module (software functional unit) performs in-depth verification of command integrity (such as checksum matching), extracts key parameters such as GPIO port identifier and target interface protocol (such as SPI protocol); and triggers the interface protocol module (software functional unit) to load the corresponding protocol driver logic (such as clock generation and data transmission and reception timing control code for SPI protocol) to prepare for driving hardware interface switching.

[0172] Driver hardware protocol switching

[0173] The interface protocol module calls the serial port driver / GPIO control driver (a collection of software drivers) of the device driver layer to write configuration parameters to the microprocessor module registers, and drives the GPIO port of the acquisition interface module to complete the protocol switching (such as configuring the pin as an SPI interface and setting the clock frequency). At the same time, the real-time operating system layer ensures that tasks such as protocol loading and hardware driver calling are executed first through task scheduling, so as to ensure the real-time switching.

[0174] Data acquisition and status feedback (software closed loop)

[0175] After a new sensor is connected, the data processing module (software functional unit) parses the collected data according to the new protocol (or directly stores it in the data storage module via the DMA data processing module); the data statistics and quality control module (software functional unit) records operating indicators such as interface switching time and data acquisition frequency; finally, the new sensor data and interface configuration status are transmitted back to the host computer / cloud via the 4G communication module / serial port driver, completing the closed loop of the "configuration → acquisition → feedback" software logic.

[0176] The core advantages of this process are:

[0177] Layered and decoupled for easy expansion: The application layer, support layer, operating system layer, and device driver layer are clearly layered. Adding a new protocol only requires supplementing the driver logic of the interface protocol module without changing the overall architecture, making it more efficient to adapt to new sensors.

[0178] Real-time scheduling ensures continuity: The embedded real-time operating system ensures concurrent execution of multiple tasks (such as simultaneous processing of interface configuration, data acquisition, and communication upload), avoiding configuration processes from blocking data transmission and ensuring business continuity in scenarios such as weather stations;

[0179] Hardware and software collaboration improves compatibility: By dynamically loading protocol drivers through software, the same hardware interface can be adapted to multiple protocol sensors, enhancing device compatibility and reducing hardware procurement and maintenance costs.

[0180] Typical Workflow 3: Multi-sensor Parallel Acquisition Scenario - Example of Simultaneous Adaptation to UART+IIC Sensors (Software and Hardware Collaborative Expansion)

[0181] This process combines hardware configurability with software task scheduling to enable parallel access and data acquisition from multiple protocol sensors, as detailed below:

[0182] Hardware collaboration

[0183] The microprocessor module receives the "parallel configuration" instruction from the host computer and obtains the command through the parameter configuration module / 4G communication module; it outputs multiple control signals to the acquisition interface module, configuring the first target port group as UART protocol (connecting to the wind speed sensor) and the second target port group as IIC protocol (connecting to the temperature and humidity sensor); the data storage module enables multi-channel DMA mode, allocating hardware channels for the data transmission of the two sensors respectively.

[0184] Software scheduling phase

[0185] Upon receiving the parallel configuration command, the command parsing module simultaneously extracts the UART and IIC protocol configuration parameters. The interface protocol module loads the two protocol drivers in parallel and drives the acquisition interface module through the device driver layer to complete the port protocol switching. When the UART and IIC sensors send data, the DMA data processing module saves the data to memory to ensure that the two data streams are processed in parallel without conflict. Finally, the data statistics and quality control module integrates the data from the two sensors and uploads it to the host computer / cloud synchronously through the 4G communication module.

[0186] The core value embodied in this process:

[0187] The solution demonstrates its ability to support complex scenarios involving parallel access to multiple protocol sensors. The hardware achieves physical channel independence through multi-port grouping configuration, while the software relies on hierarchical scheduling and multi-task parallelism to ensure data acquisition efficiency. It covers practical application needs such as weather stations that require simultaneous access to multiple types of sensors, thus enhancing the scenario adaptability of the technical solution.

[0188] Typical Workflow 4: Exception Handling Scenario - Example of Forced Switching Due to Port Conflict (Software and Hardware Collaboration for Protection)

[0189] This process focuses on handling exceptions when hardware port conflicts occur, ensuring business continuity through software and hardware collaboration, as detailed below:

[0190] Hardware collaboration

[0191] The microprocessor module receives the "forced switch" instruction through the parameter configuration module. First, it performs a configuration operation on the new target port group (such as P21-P24) to complete the new interface configuration and sensor access verification. Then, it performs a disconnect operation on the original target port group (such as P21-P22) to control the acquisition interface module to turn off the power enable and timing signals of the GPIO ports of that group and release hardware resources.

[0192] Software scheduling phase

[0193] The command receiving module verifies the legality of the forced switching command, and the status query module marks the original port as "occupied". The protocol configuration module executes the process of "new interface pre-configuration → old interface disconnection → new sensor access verification". The debugging port UART module transmits the switching status back in real time (such as "new interface configuration successful, old interface released") to ensure that the operation and maintenance personnel can control it. If a hardware failure occurs during the switching (such as register configuration error), the data statistics and quality control module records the error log (including the faulty port, target interface protocol, and error code) and transmits it back to the host computer / cloud through the 4G communication module to trigger an alarm.

[0194] The core value embodied in this process:

[0195] By employing a hardware and software collaborative "configure new first, then disconnect old" logic, the solution addresses port conflict issues in actual operations and maintenance, ensuring minimal business interruption time. Simultaneously, it incorporates anomaly logging and remote alarm mechanisms to enhance the robustness of the solution.

[0196] like Figure 1 , Figure 2 As shown, the following are some typical core logics. The core logic revolves around the "closed-loop process of remote handover," including the following key information:

[0197] Triggering mechanism (hardware channel and software capture verification)

[0198] Remote commands (from the cloud / host computer) are transmitted to the system via a 4G communication module (hardware driver circuit, supporting high-speed mobile network transmission). The physical signals are converted into data frames by this module and then sent to the microprocessor module. At the software level, the command receiving module (embedded software running on the microprocessor) captures the data frames, first verifying the match between the data header (3 bytes) and the control bits (1 byte, indicating a configuration command), and then verifying the integrity of the command through a checksum (1 byte), ensuring that the command has not been tampered with or lost.

[0199] Hardware and software collaborative operation (protocol parsing and interface reconstruction)

[0200] At the software level: After the verification is passed, the interface configuration module parses the command, extracts the target interface protocol (such as SPI) from the interface identifier (2 bytes), and determines the target port group to be configured (such as GPIO ports P21-P24 forming a target port group) from the port identifier (4 bytes). Then, the interface protocol module is called to confirm the protocol support and load the timing logic corresponding to the protocol (such as the clock signal and data transmission and reception rules of SPI).

[0201] At the hardware level: the microprocessor module converts the parsed results into configuration instructions for its own related registers, directly configures the working mode of the GPIO port in the acquisition interface module (sets it to open-drain or push-pull output, etc. via software), and configures the control registers related to peripheral circuits (such as pull-up resistors and level conversion circuits) to adapt to the electrical characteristics of the new protocol; at the same time, the software prepares for data acquisition by configuring the registers of the DMA controller and presetting the transmission path and storage address of the sensor data.

[0202] Data verification closed loop (transmission link and integrity verification)

[0203] After the new sensor is connected to the reconstructed interface, data flows from the acquisition interface module to the microprocessor module. The microprocessor parses the data according to the new protocol (such as verifying the SPI frame format) and then transmits it back to the cloud / host computer via the 4G communication module. At the same time, the local data storage module saves the original data for future reference. On the software level, the data storage module compares the data format with the target interface protocol requirements (such as frame length and checksum) to confirm that the acquisition is normal, thus completing the "configuration → acquisition → verification" closed loop.

[0204] Software is the "control center," and hardware is the "execution carrier." The two are closely connected through "control signals" and "data links," offering the following technological advantages:

[0205] No on-site operation required: Remote command transmission is achieved through the 4G communication module. With the help of software verification and hardware drivers, no human presence is required throughout the process (the reconfiguration of the data acquisition card interface does not require human presence, but the replacement of the sensor requires human intervention), making it suitable for outdoor deployment scenarios.

[0206] Uninterrupted service: The process follows the logic of “first configure the new interface (e.g., P21-P24 configured as SPI) → verify that the new interface transmits and receives data normally → disconnect the original interface (e.g., the old IIC interface)”. During this period, other sensors work normally through independent ports to ensure continuous data acquisition.

[0207] Software and hardware work together to ensure performance: The software configures tasks to be executed first through the embedded operating system module scheduling interface to ensure real-time performance; the hardware directly stores data through the DMA data processing module without microprocessor intervention, thus jointly ensuring the reliability of switching.

[0208] Figure 3 The interface configuration task flowchart is shown. Figure 1 The hardware modules (microprocessor, acquisition interface, parameter configuration, etc.) are Figure 3 The physical execution vehicle of the process, specifically corresponding to:

[0209] "Interface Configuration Module Initialization" → Figure 1The acquisition interface module + microprocessor module: The microprocessor loads the initialization program of the acquisition interface and configures the GPIO port to the default state (such as idle mode).

[0210] "Query / parse configuration command" → Figure 1 The system consists of a parameter configuration module, a 4G communication module, and a microprocessor module: the parameter configuration module (local) or the 4G communication module (remote) transmits commands, and the microprocessor module executes and parses the commands.

[0211] "Query port usage / Release port" → Figure 1 The microprocessor module and the acquisition interface module: The microprocessor queries whether the GPIO ports in the target port group are occupied. If they are occupied, it controls the acquisition interface module to release the hardware resources of the target port group (such as disabling the original protocol timing driver and clearing the GPIO control register configuration).

[0212] Configure port properties → Figure 1 The acquisition interface module + microprocessor module: The microprocessor writes register configurations to the acquisition interface module and reconstructs the electrical characteristics (protocol type, level standard) of the GPIO port.

[0213] Figure 3 yes Figure 2 The logical execution flow of a layered software architecture is visualized, corresponding to the following software modules:

[0214] "Interface Configuration Module Initialization" → Figure 2 Device driver layer (port initialization driver) + application layer support layer (protocol loading initialization): Start the hardware driver and load the default protocol logic.

[0215] "Query / parse configuration command" → Figure 2 Application layer (command receiving module) + application layer support layer (command parsing module): capture commands (application layer), verify and parse (support layer).

[0216] "Query API Support / Port Usage" → Figure 2 Application layer support layer (interface protocol module, query protocol library) + device driver layer (port status driver, query port occupancy): verify protocol support (interface protocol module), query hardware port status (driver layer).

[0217] "Stop Protocol / Release Port / Configure Properties" → Figure 2 Application layer support layer (interface protocol module, unload old protocol) + device driver layer (port driver, release / reconstruct hardware): unload old protocol logic (interface protocol module), drive hardware port switching (driver layer).

[0218] The interface configuration task specifically includes the following steps:

[0219] The process begins with the initialization of the interface configuration module, setting up the initial hardware and software states for subsequent dynamic configuration of the interface, ensuring a clean initial environment. After initialization, it continuously checks for configuration commands. If no commands are detected, it maintains polling or enters a low-power wait state to ensure real-time response to configuration requests. Once a configuration command is captured, it is parsed, verifying the 3-byte data header, 1-byte control bit (marking the configuration command), 1-byte checksum, etc., and extracting core parameters such as the target interface protocol (2 bytes), target port group (4 bytes), and communication parameters (8 bytes) to provide a basis for subsequent operations.

[0220] Next, all current interfaces are queried. The microprocessor reads the register mapping table of the acquisition interface module, and the software side traverses the protocol support library to form a bidirectional list of the actual hardware configuration interfaces and the software-supported interfaces. Based on this, it determines whether the specified interface is supported: the target interface protocol is compared with the software support list, and hardware compatibility is checked simultaneously; if it is not supported, the application layer command receiving module sends an "interface not supported" error code to the host computer / cloud (such as a remote configuration server or local debugging computer), and the process terminates; if it is supported, it continues.

[0221] Next, the port usage is checked, and the software checks the port occupancy status to determine whether the target port group is occupied. If the port is occupied, the new protocol driver is preloaded through the interface protocol module (software) of the application layer support layer. At the same time, the microprocessor module directly executes the pre-configuration operation, driving the target GPIO port by reading and writing its internal registers, and pre-initializing the electrical parameters of the new protocol (such as the SPI clock division ratio). After the new interface can work normally, the current interface protocol is stopped (the software unloads the old protocol logic, and the hardware shuts down the old port clock and disables data transmission and reception). Through the timing design of "backup before replacement", the service is not interrupted when the interface is switched, which solves the problem of service interruption caused by the fixed interface of traditional acquisition boards. This is one of the core innovations of the invention, ensuring that the services of other sensors are not interrupted.

[0222] After completing the port release, configure the current port properties: by Figure 2 The device driver layer (software) loads the new protocol driver and controls it. Figure 1 The data acquisition interface module's built-in hardware circuitry (pull-up resistor / level conversion circuit) adapts to electrical characteristics; simultaneously, the microprocessor module (hardware, Figure 1The system writes configuration parameters to the GPIO control register, setting the pin functions and communication parameters of the GPIO port, providing the hardware foundation for the target port group to have the new protocol communication capability. Finally, the specified port is configured as the new interface, the software updates the interface configuration list and reports a success status, and the hardware triggers the new protocol enable signal, enabling the port to officially enter the new working mode. This completes the entire process from command reception to interface activation, and the new sensor can then be connected to collect data.

[0223] In practical applications, this invention enables remote switching of any interface for outdoor deployed devices without interrupting operations. For example, if a temperature and humidity sensor currently connected to an IIC interface needs to be replaced with an SPI interface model, a configuration command can be remotely issued to configure the unused P21-P24 ports as SPI interfaces and connect the new sensor. Once the SPI interface is transmitting and receiving data normally, the operation of the original IIC interface is stopped. Throughout the entire process, the data acquisition services of other sensors are not affected, ensuring data continuity.

[0224] When the configuration command is sent to the data acquisition board, the system will first check the current occupancy status of the GPIO port. If the GPIO port is already in use, its current interface configuration must be deactivated (such as uninstalling the old protocol driver or disabling the old port timing) before the new interface configuration operation is executed to avoid port conflicts.

[0225] Furthermore, the fields of the interface configuration command must be used in a fixed order, as follows: ① Data header (3 bytes, fixed frame start identifier); ② Control bits (1 byte, fixed identifier for configuration command); ③ Interface identifier (2 bytes, identifies the target interface protocol according to a preset encoding); ④ Port identifier (4 bytes, identifies the target port group in a fixed order of "start port - end port"); ⑤ Communication parameters (8 bytes, configure interface parameters in a fixed order of "baud rate - data bits - stop bits - parity bits"); ⑥ Checksum (1 byte, used to verify command integrity).

[0226] The fields of the interface query command must also be used in a fixed order: ① Data header (3 bytes, consistent with the configuration command); ② Control bits (1 byte, fixedly identified as the query command); ③ Interface identifier (2 bytes, identified by a preset code for all interface types supported by the current system); ④ Port identifier (8 bytes, identified by port numbers “P1-P24” for each port’s occupied / idle status); ⑤ Checksum (1 byte, used to verify command integrity). It should be noted that this invention does not limit the number of GPIO ports. The number of ports can be flexibly determined according to project requirements (such as the number and type of sensors to be connected). For example, 24 ports can meet the requirement of connecting 6 sensors, while 48 ports can meet the requirement of connecting 12 sensors.

[0227] Figure 4The flowchart of the command receiving task is shown, relying on Figure 1 Hardware architecture and Figure 2 Software layered collaboration implementation, Figure 1 As a physical execution carrier, it specifically includes:

[0228] Command receive initialization / byte detection → Figure 1 Microprocessor module + 4G communication module / parameter configuration module: The microprocessor drives the communication module to enter the data listening state and configures the serial port / network receive buffer to the default mode.

[0229] Command Statistics and Verification → Figure 1 The microprocessor module and data storage module work together to complete the checksum calculation: the microprocessor counts the number of bytes through registers, and the data storage module temporarily stores the command frame.

[0230] Figure 2 To visualize the logical execution flow, it specifically includes:

[0231] Command reception initialization → Figure 2 Device driver layer (communication interface driver) + application layer (command receiving module initialization): Initialize the serial port / 4G communication module, and initialize the command receiving buffer and status flags.

[0232] Byte detection and statistics → Figure 2 The application layer (command receiving module) + device driver layer (data receiving driver): The application layer captures bytes using polling / interrupt mode, the driver layer provides hardware support for data reception, and the application layer support layer (such as the command parsing auxiliary module) counts the frame length.

[0233] Checksum calculation and verification → Figure 2 The application layer support layer (checksum algorithm module) + device driver layer (data verification driver): The support layer executes the checksum algorithm, and the driver layer assists in reading and storing data to complete the integrity verification.

[0234] The command receiving task specifically includes the following steps:

[0235] The process begins with the initialization of the command receiving module: by Figure 2 The device driver layer loads the hardware driver for the communication interface (such as 4G, serial port), and the application layer initializes the command receiving buffer and status flags (such as clearing the byte count to zero), clears the software-side historical state for command receiving, and ensures that the initial environment is ready.

[0236] After initialization, the system continuously monitors the currently received bytes: the device driver layer listens to physical signals through the communication module (4G / serial port) and converts them into a byte stream; the application layer command receiving module polls the buffer to determine whether a new byte has been captured. If no byte is detected, polling is maintained (or the system is woken up by a hardware interrupt) to ensure real-time response; if a byte is captured, the system enters the command frame parsing process.

[0237] After capturing bytes, it is determined whether the current byte is a command frame header: the application layer support layer calls the frame header matching algorithm (such as comparing a 3-byte fixed identifier) ​​to verify whether the byte conforms to the command frame start rule. If not, some statistical flags are reset (such as the command statistics counter only counting bytes after the frame header), and listening for new bytes continues; if yes, the command statistics counter is triggered to count, and the frame length statistics module of the application layer support layer records the number of bytes received after the frame header.

[0238] During command statistics, it is determined whether the command statistics value is greater than the frame header byte count: The application layer support layer distinguishes between the frame header and the data segment by comparing the "number of received bytes" with the "predefined frame header length (e.g., 3 bytes)". If it is greater, it indicates that the data segment has been entered, and the statistics continue until the complete frame is reached; if it is not greater, it continues to wait for subsequent bytes to ensure the accuracy of frame header identification.

[0239] When the command statistics value reaches the full frame length, the command statistics counter is cleared: the application layer support layer resets the frame length statistics flag to prepare for the next command reception and avoid historical statistics interfering with the parsing of new commands.

[0240] After the command frame is received completely, it is determined whether the current byte is a checksum: The application layer support layer calls the checksum calculation module, traverses the received command frame bytes (excluding the checksum field), and performs algorithms such as accumulation / XOR to generate a checksum value; it compares the checksum byte at the end of the frame to verify the integrity of the command. If the checksum fails, the current frame is discarded, and a "checksum failed" message is replied, and the system starts listening for new commands again; if the checksum succeeds, the command statistics counter is reset to zero, and the application layer support layer completes the checksum comparison to confirm that the command has not been tampered with.

[0241] Figure 4 Through layered verification of "frame header identification → length statistics → checksum verification," the accuracy and reliability of command reception are ensured, resolving configuration failures caused by command misinterpretation and packet loss in traditional data acquisition boards. The "hardware-software collaboration" in this process is manifested in:

[0242] On the hardware side: the 4G / serial port module is responsible for physical signal transmission and reception, and the microprocessor provides statistical support;

[0243] On the software side: the application layer implements the frame parsing logic, the support layer encapsulates the verification and statistical algorithms, and the device driver layer ensures the smooth flow of data links.

[0244] and Figure 3 The "interface configuration process" is connected through the "notification interface configuration task" to form a complete technical solution of "command reception → parsing → configuration → activation".

[0245] After successful verification, the system checks if the checksum is correct. If incorrect, the application layer command receiving module sends a "verification failed" error code to the host computer / cloud and re-receives the command. If correct, it triggers a notification interface configuration task: the application layer transmits the parsed command frame (including the target interface, parameters, etc.) to the interface configuration module via inter-process communication, initiating the task. Figure 3 The interface dynamic configuration process is now complete, thus completing the entire closed loop of "command reception → verification → trigger configuration".

[0246] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

[0247] The above description is only a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. Any equivalent modifications or changes made by those skilled in the art based on the content disclosed in the present invention should be included in the scope of protection set forth in the claims.

Claims

1. A data acquisition board that supports dynamic switching of multiple protocol interfaces, characterized in that, include: Microprocessor module; The acquisition interface module is connected to the microprocessor module and consists of multiple GPIO ports of the microprocessor module and peripheral circuits connected thereto; at least two of the multiple GPIO ports are configured as a target port group; the peripheral circuits are configured to adjust the electrical characteristics of the GPIO ports to adapt to different interface protocols. The parameter configuration module, connected to the microprocessor module, is used to receive configuration commands transmitted by the command receiving module and send execution responses of the configuration commands to the host computer or the cloud. The software system running on the microprocessor module includes: The command receiving module is used to uniformly receive configuration commands and query commands issued by the host computer or cloud, and to verify the configuration commands. The configuration commands are passed to the parameter configuration module, and the query commands are passed to the query module. The query module is used to receive query commands transmitted by the command receiving module and return the current configuration status of the target port group and / or the currently supported interface protocols to the host computer or cloud. The interface configuration module is used to parse the configuration command after the configuration command passes the verification to determine the target port group and target interface protocol to be configured, and to call the corresponding interface protocol to configure the target port group as a communication interface that supports the target interface protocol.

2. The data acquisition board supporting dynamic switching of multiple protocol interfaces as described in claim 1, characterized in that, The microprocessor module is configured to set the GPIO port to open-drain output or push-pull output mode via software; the peripheral circuit of the acquisition interface module is configured to adapt and adjust the electrical characteristics of the GPIO port.

3. A data acquisition board supporting dynamic switching of multiple protocol interfaces as described in claim 1 or 2, characterized in that, The interface configuration module parses the configuration command to determine a target port group. The target port group includes at least two GPIO ports. The GPIO ports are numbered consecutively or non-consecutively. The target port group is configured as the corresponding communication protocol interface according to the configuration command. Alternatively, in response to a configuration command, the interface configuration module may recombine GPIO ports originally belonging to different target port groups and assign them to new target port groups to dynamically adapt to the target interface protocol's requirements for the number of physical signal lines.

4. A data acquisition board supporting dynamic switching of multiple protocol interfaces as described in claim 1, characterized in that, The software system also includes an interface protocol module, which is configured to store and support multiple interface protocols, including one or more of UART, IIC, SPI, RS-232, RS-485 and CAN bus protocols.

5. A data acquisition board supporting dynamic switching of multiple protocol interfaces as described in claim 1, characterized in that, The configuration command includes a port field for identifying the target port group, a target interface protocol field for identifying the target interface protocol, and a parameter field for configuring communication parameters.

6. A data acquisition board supporting dynamic switching of multiple protocol interfaces as described in claim 2, characterized in that, It also includes a data storage module and a DMA data processing module, wherein the DMA data processing module is connected to the acquisition interface module and the data storage module respectively; the DMA data processing module is configured to directly transmit sensor data to the data storage module without the participation of the microprocessor module.

7. A data acquisition board supporting dynamic switching of multiple protocol interfaces as described in claim 2, characterized in that, It also includes a 4G communication module, which is connected to the microprocessor module and is used to wirelessly transmit data with the host computer or cloud via a mobile network.

8. A configuration method for a data acquisition board supporting dynamic switching of multiple protocol interfaces as described in any one of claims 1-7, characterized in that, Includes the following steps: Receive configuration commands from the host computer or the cloud; Verify the completeness and correctness of the configuration commands; If the verification passes, then parse the port field and target interface protocol field in the configuration command; Configuring the target port group specifically includes: configuring the target port group corresponding to the port field as a communication interface that supports the target interface protocol, based on the target interface protocol corresponding to the target interface protocol field.

9. The configuration method of a data acquisition board supporting dynamic switching of multiple protocol interfaces as described in claim 8, characterized in that, After parsing the configuration command and before configuring the target port group, the following is also included: Query the current status of the target port group corresponding to the port field; If the current state is occupied, first find and configure an idle target port group for the new target interface protocol; after the newly configured interface passes data verification, deregulate the current configuration of the original target port group.

10. The configuration method of a data acquisition board supporting dynamic switching of multiple protocol interfaces as described in claim 8, characterized in that, If a hardware failure is detected during the configuration of the target port group, the following demotion configuration steps are executed: Release at least one target port group with the lowest priority that is already occupied, based on a predefined list of sensor priorities; The released target port group is reconfigured to the target interface protocol as a backup interface; Send fault information and downgrade configuration results to the host computer or cloud; After the backup interface is running stably, disconnect the GPIO port in the original faulty target port group.

Images