Hierarchical state machine based insufflator single bus sensor drive method

Abstract

The application provides a laparoscope single bus sensor driving method based on a hierarchical state machine, which finely decomposes a complex communication process by defining four-level state variables and cycle flags of a flow layer, an operation layer, a byte layer and a bit timing layer in a controller memory. The method configures a hardware timer, calls a scheduling function in an interrupt service, and the function performs pin atomic operations according to the state variables. The key scheduling logic is: if the current operation needs to wait, the timer is started and the CPU is released; if no waiting is needed, the cycle flag is set, and the next step is continuously executed in the same interrupt. Through multiple timer interrupts, the state machine successively experiences the stages of reset, command sending and data reading, and the sensor data interaction is completed in a completely non-blocking manner. The scheme aims to solve the problems of CPU resource waste and timing interference caused by traditional blocking delay, thereby improving the real-time performance and operation stability of the laparoscope system.

Description

Technical Field

[0001] This application belongs to the field of medical device control and embedded driver development technology, and in particular relates to a single-bus sensor driving method, system, device and computer-readable storage medium for an insufflator based on a hierarchical state machine. Background Technology

[0002] During laparoscopic surgery, the insufflator needs to continuously inflate the patient's abdominal cavity with gas to maintain the surgical space, and the gas temperature needs to be monitored and controlled in real time to prevent the patient's body temperature from dropping due to low-temperature gas. Therefore, the insufflator tubing is typically equipped with a temperature sensor (e.g., DS18B20) based on a single-bus communication protocol to achieve continuous acquisition of gas temperature.

[0003] Single-bus communication protocols have strict requirements for microsecond-level operation timing. In existing insufflator control systems, the drivers for single-bus temperature sensors typically use blocking delay functions (such as delay_us) based on instruction cycles to meet communication timing requirements. During this delay, the insufflator's main control chip (central processing unit, CPU) remains in a busy-waiting state, unable to respond promptly to or execute other critical tasks of the insufflator, such as pipeline pressure monitoring, gas flow regulation, and abnormal alarm responses.

[0004] This blocking drive method significantly consumes the processing resources of the insufflator's main control chip, leading to increased response delays for critical tasks and reducing the overall real-time performance and operational reliability of the insufflator system. Furthermore, in the complex operating environment of the insufflator, the system experiences multiple interrupt sources or multi-task scheduling. The blocking delay process is easily interrupted by high-priority events, causing the actual delay time to exceed the timing tolerance range specified by the sensor single-bus communication protocol. This can result in sensor reset failures, data reading errors, or complete communication interruptions, ultimately affecting the accuracy and safety of the insufflator's gas temperature control.

[0005] Therefore, how to solve the problems of CPU resource waste and timing interference caused by blocking delay in order to improve the real-time performance and stability of the pneumoperitoneum system is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0006] This application provides a single-bus sensor driving method, system, device, and computer-readable storage medium for an insufflator based on a hierarchical state machine. It can solve the problems of CPU resource waste and timing interference caused by blocking delay, thereby improving the real-time performance and stability of the insufflator system.

[0007] In a first aspect, embodiments of this application provide a single-bus sensor driving method for an insufflator based on a hierarchical state machine, comprising: Define state variables and loop flags in the memory of the insufflator controller, including the process layer, operation layer, byte layer, and bit timing layer; Configure the hardware timer and call the scheduling function in its interrupt service routine; The scheduling function calls the corresponding hierarchical processing function according to the value of the process layer state variable. The hierarchical processing function performs atomic operations on a single bus pin based on the operation layer, byte layer and bit timing layer state variables. When the current atomic operation needs to wait for a preset period of time, the hardware timer is started based on the preset period of time, the loop flag is set to invalid, and the scheduling function is exited; when there is no need to wait, the loop flag is set to valid, and the next level processing function is called again within the same interrupt. By driving the process layer state variables through multiple timer interrupts to sequentially go through the reset, command sending and data reading stages, the complete data interaction with the single bus sensor is completed in a non-blocking manner. Based on the read original byte sequence, the final physical quantity detection result is obtained by calculating based on the preset conversion logic.

[0008] Optionally, the process layer state variables are used to manage the macro-level phases of a complete data interaction, and the macro-level phases include at least a reset phase, a command sending phase, and a data reading phase. The operation layer state variables are used to manage the sequence of sub-steps within each of the macroscopic stages; The byte-level state variables are used to manage the bit-by-bit sending or receiving count of individual byte data; The bit timing layer state variables are used to manage the timing of micro-operations in a single bit operation.

[0009] Optionally, during the reset phase, the scheduling function executes the following sub-steps sequentially based on the values ​​of the operation layer state variables: Set the single-bus pin low and start the first timer; Release the single-bus pin and start the second timing; Read the single-bus pin level to determine if the sensor response pulse exists, and start the third timing. The single-bus pin is restored to a high level, and the process layer state variable is advanced based on the presence or absence of the sensor response pulse.

[0010] Optionally, during the command sending phase or the data reading phase, the scheduling function determines whether the current byte has been sent or received completely based on the value of the byte layer state variable. If not completed, the corresponding write bit micro-operation or read bit micro-operation is executed based on the value of the bit timing layer state variable.

[0011] Optionally, the write bit micro-operation includes: Set the single-bus pin low and start the fourth timer; Based on the bit value to be written, after the fourth timing ends, the single-bus pin is set to the corresponding level and the fifth timing is started; After the fifth timing period ends, the single-bus pin is set to high and the byte layer state variable is updated.

[0012] Optionally, the read bit micro-operation includes: Set the single-bus pin low and start the sixth timer; Release the single-bus pin and start the seventh timer; Read the single-bus pin level and store it in a temporary variable, and start the eighth timer at the same time; After the eighth timing period ends, the single-bus pin is set to high level, and the byte-level state variable is updated based on the bit value in the temporary variable.

[0013] Optionally, during the command sending phase, the scheduling function sends a skip ROM command and a start conversion command to the single-bus sensor in sequence based on the current value of the process layer state variable, and then starts a long timer and updates the process layer state variable to the waiting conversion phase; During the waiting transition phase, the scheduling function stops operating on the single-bus sensor until the long timer overflow interrupt occurs, after which the process layer state variable is advanced to the reset phase.

[0014] Optionally, defining state variables and loop flags in the insufflator controller memory, including process layer, operation layer, byte layer, and bit timing layer, further includes: Define a pulse presence flag to record whether a sensor response pulse is detected during the reset phase; Define a data buffer to store the raw byte sequence read from the single-bus sensor; Define a bit index counter and a byte index counter to record the number of bits and bytes that have been read or sent, respectively.

[0015] Optionally, after calculating the final physical quantity detection result based on the read raw byte sequence and a preset conversion logic, the method further includes: Perform cyclic redundancy check on the original byte sequence; If the verification passes, the first byte and the second byte representing the temperature are extracted from the original byte sequence. The first byte is combined with the second byte after shifting it eight bits to the left to obtain a signed integer value. The signed integer value is then multiplied by a preset temperature resolution coefficient to obtain the final temperature value. If the verification fails, the final physical quantity detection result will be marked as invalid.

[0016] Optionally, configuring the hardware timer and calling the scheduling function in its interrupt service includes: Configure the hardware timer to single-use mode, dynamically setting the automatic reload value and starting it each time only according to the preset waiting period of the current atomic operation; In the interrupt service routine of the hardware timer, the hardware timer is stopped, the interrupt flag is cleared, and then the scheduling function is called.

[0017] Secondly, embodiments of this application provide a single-bus sensor driving system for an insufflator based on a hierarchical state machine, comprising: The definition module is used to define state variables and loop flags, including process layer, operation layer, byte layer, and bit timing layer, in the memory of the insufflator controller; The configuration module is used to configure hardware timers and call scheduling functions in their interrupt services; The calling module is used by the scheduling function to call the corresponding hierarchical processing function according to the value of the process layer state variable. The hierarchical processing function performs atomic operations on a single bus pin based on the operation layer, byte layer and bit timing layer state variables. The judgment module is used to start the hardware timer and set the loop flag to invalid after the current atomic operation needs to wait for a preset period of time, and then exit the scheduling function; when no waiting is required, the loop flag is set to valid and the next level processing function is called in the same interrupt. The interaction module is used to drive the process layer state variables through multiple timer interrupts to sequentially go through the reset, command sending and data reading stages, so as to complete the complete data interaction with the single bus sensor in a non-blocking manner. The calculation module is used to calculate the final physical quantity detection result based on the read raw byte sequence and a preset conversion logic.

[0018] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the above-described single-bus sensor driving method for insufflator based on hierarchical state machine.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the above-described method for driving single-bus sensors of an insufflator based on a hierarchical state machine.

[0020] The single-bus sensor driving method, system, device, and computer-readable storage medium for insufflator based on hierarchical state machine in this application can solve the problems of CPU resource waste and timing susceptibility to interference caused by blocking delay, thereby improving the real-time performance and stability of the insufflator system.

[0021] This invention decouples and hierarchically manages the complex single-bus communication protocol by constructing a four-level state variable system: a process layer, an operation layer, a byte layer, and a bit timing layer. The process layer is responsible for macro-level task scheduling, the operation layer is responsible for sub-task management within a stage, and the byte layer and bit timing layer are responsible for the underlying bit operations with the strictest timing requirements. This hierarchical design makes the program logic clear and easy to develop and maintain. More importantly, by combining hardware timers and loop flags, this invention achieves a non-blocking scheduling strategy that "immediately releases the CPU when a delay is needed, and executes continuously and efficiently when no delay is needed." This ensures that during the temperature conversion wait period of hundreds of milliseconds, the main control chip of the insufflator can process higher-priority tasks such as pressure control and flow regulation at full speed, fundamentally solving the system real-time problem caused by blocking drives. Attached Figure Description

[0022] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a flowchart illustrating a single-bus sensor driving method for an insufflator based on a hierarchical state machine, provided in one embodiment of this application. Figure 2 This is a schematic diagram of the structure of a single-bus sensor driving system for an insufflator based on a hierarchical state machine, provided in one embodiment of this application. Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0024] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0025] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0026] To address the problems of existing technologies, embodiments of this application provide a method, system, device, and computer-readable storage medium for driving single-bus sensors of an insufflator based on a hierarchical state machine. The method for driving single-bus sensors of an insufflator based on a hierarchical state machine, as provided in this application, will be described first below.

[0027] Figure 1 A flowchart illustrating a single-bus sensor driving method for an insufflator based on a hierarchical state machine, according to an embodiment of this application, is shown. Figure 1 As shown, the single-bus sensor driving method for an insufflator based on a hierarchical state machine includes: S101. Define state variables and loop flags in the memory of the insufflator controller, including the process layer, operation layer, byte layer, and bit timing layer. In this invention, to address the issues of strict timing requirements and complex processes in single-bus communication protocols, a novel four-layer state machine model is proposed to manage and drive the entire communication process. These four state variables are all defined and stored in the memory of the pneumoperitoneum machine's main control chip, in the form of data structures (e.g., structs in C language).

[0028] Specifically, in the memory of the pneumoperitoneum machine's main control chip (such as the STM32 series), a data structure is defined for the DS18B20 driver object. This data structure contains at least the following four levels of state variables, as well as several auxiliary flags and data buffers.

[0029] 1. Process layer state variables (deep_lvl0_step): This variable manages the macroscopic phase of a complete temperature acquisition. Its value range and the corresponding phase definition are as follows: Phase 0: First Reset – A reset pulse is sent to the DS18B20, and the presence of the sensor is checked. If the sensor is present, its presence is recorded; otherwise, the process jumps directly to the error handling phase.

[0030] Phase 1: Sending Temperature Conversion Commands – The “Skip ROM Command” (0xCC) and the “Start Temperature Conversion Command” (0x44) are written to the sensor sequentially, and then a long timer (typically 750ms) is started to wait for the temperature conversion to complete. During this period, the state machine is paused, and the CPU performs other tasks.

[0031] Phase 2: Waiting for the transition to complete – triggered by a timer timeout event. This phase is merely a placeholder; during actual execution, the process proceeds directly to the next phase.

[0032] Phase 3: Second Reset – Send the reset pulse again to ensure the sensor is ready for data reading.

[0033] Phase 4: Send Read Register Command - Write "Skip ROM Command" (0xCC) and "Read Register Command" (0xBE) in sequence to prepare to read 9 bytes of data (8 bytes of temperature register + 1 byte of CRC check code).

[0034] Phase 5: Read data – Read 9 bytes continuously and store them into the buffer in sequence.

[0035] Phase 6: Data Processing and Termination – Perform CRC check on the read 9 bytes of data. If the check succeeds, convert the original temperature value (two bytes) to the actual temperature (multiplied by a coefficient of 0.0625); if the check fails, mark the temperature as invalid (e.g., set to a specific error value, such as 998.0). Finally, reset the process layer state variable to 0 and report the temperature data to the insufflation machine main control system via a task notification mechanism (such as a message queue, semaphore, or callback function).

[0036] 2. Operational layer state variables (deep_lvl1_step): This variable manages the sub-steps within each macro-level stage. Different macro-level stages reuse the same set of operational-level state variables, but each defines its own sequence of sub-steps. Typical examples include: Sub-steps under reset operation: Sub-step 0: Set the data pin to output mode, pull it low, and start the 480μs timer.

[0037] Sub-step 1: Release the bus (set to input mode) and start the 70μs timer.

[0038] Sub-step 2: Read the pin level to determine if a pulse exists (low level indicates presence), and start the 410μs timer.

[0039] Sub-step 3: Restore the pin to the output high level, and determine whether to advance the process layer state based on the presence of the pulse flag.

[0040] Sub-steps under byte write operations (actually implemented by the byte layer and bit timing layer, with the operation layer responsible for counting control): Sub-step 0: Prepare to write one byte, initialize the bit counter to 0.

[0041] Sub-step 1: Call the bit write function to write the current bit.

[0042] Sub-step 2: Increment the bit counter by 1. If it is less than 8, repeat sub-step 1. If it is already 8, proceed to the next macroscopic stage.

[0043] Sub-steps under byte read operation: Similar to byte write, but call the bit read function, combine the read bits into a byte, and store it in the buffer.

[0044] 3. Byte-level state variables (deep_lvl2_step): This variable is used to manage the bit-by-bit transmission or reception count of a byte (8 bits) of data. Its value ranges from 0 to 8. When the byte layer state is 0, it indicates that transmission has not yet started; the variable is incremented by 1 for each successfully transmitted or received bit; when it reaches 8, it indicates that a byte transmission is complete, at which point the byte layer state is reset to 0, and the operation layer is notified to proceed with its sub-step.

[0045] 4. Bit-sequence layer state variables (deep_lvl3_step): This variable is used to manage the timing of micro-operations in individual bit communication. Different bit operations (write 1, write 0, read bit) share the same set of status variables, but the specific timing parameters are different.

[0046] Taking the write operation as an example, its micro-operation sequence includes: Microstep 0: Set the data pin to output mode, pull it low, and start the 7μs timer.

[0047] Microstep 1: Determine whether to pull the pin high based on the value of the bit to be written (pull high if writing 1, keep low if writing 0), and then start the 80μs timer.

[0048] Microstep 2: Pull the pin high to end the writing of this bit, increment the byte layer status by 1, and notify the operation layer.

[0049] Taking the read bit as an example, its micro-operation sequence includes: Microstep 0: Pull the pin low to start the 5μs timer.

[0050] Microstep 1: Release the bus (set to input mode) and start the 10μs timer.

[0051] Micro-step 2: Read the pin level, temporarily store the read value (0 or 1) in a temporary variable, and then start the 70μs timer.

[0052] Microstep 3: Restore the pin to output high level, store the bit value in the buffer, increment the byte layer status by 1, and notify the operation layer.

[0053] Auxiliary variables: In addition to the four levels of state variables mentioned above, the data structure also needs to include the following auxiliary members: Loop flag: A Boolean value indicating whether the current state machine needs to continue to the next step immediately (without waiting for the timer).

[0054] Presence flag: Records whether a sensor response was detected during reset.

[0055] Bit temporary buffer (bit_tmp): Stores the bit value most recently read.

[0056] Bit index counter (bit_index): Records the number of bits (0-7) that have been read / sent.

[0057] Byte temporary buffer (byte_tmp): Used to combine 8 bits into a complete byte.

[0058] Byte index counter (byte_index): Records the number of bytes read (0~8).

[0059] Data buffer (data_buf[9]): Stores the 9 bytes of data read.

[0060] Final temperature value: Floating-point or integer, storing the actual temperature after conversion.

[0061] By defining these four layers of state variables and a loop flag, this invention decomposes the complex single-bus communication process into a series of manageable, fine-grained states, laying the foundation for subsequent precise non-blocking scheduling. This solves the problem of traditional methods where program logic is tightly coupled with hardware timing, making it difficult to achieve non-blocking operations.

[0062] S102. Configure the hardware timer and call the scheduling function in its interrupt service routine; In this invention, the hardware timer is the core engine for implementing non-blocking drive, replacing the blocking software delay in traditional methods.

[0063] First, configure a hardware timer. This timer needs to meet the following requirements: Supports microsecond-level counting: The clock frequency of the timer is typically configured to 1MHz or higher to ensure that its counting accuracy can meet the delay requirements of 5μs to 480μs in single-bus protocols.

[0064] Supports dynamic modification of the Automatic Reload (ARR) register: This allows the program to dynamically set different delay times each time the timer is started, based on the needs of the current step.

[0065] Overflow interrupt support: When the timer count reaches the preset auto-reload value, an interrupt request signal will be generated.

[0066] The timer is configured for single-shot mode, not periodic mode. That is, it generates only one overflow interrupt each time it starts, and then stops counting.

[0067] Next, write the interrupt service routine for this hardware timer. The logic of this interrupt service routine is very simple, performing only the following three core operations: Stop Timer: Clears the timer's count enable bit, stopping it from counting.

[0068] Clear timer interrupt flag: Clears the interrupt pending flag of the timer, preparing for the next interrupt.

[0069] Call the unified state machine scheduling function: Call the scheduling function named DS18B20_TimerCallback() or a similar name.

[0070] This design minimizes the execution time of interrupt service routines, avoids executing complex logic within the interrupt context, and improves system responsiveness and stability. The interrupt service routine acts merely as a "trigger," its true purpose being to wake up the state machine scheduler to execute the next operation.

[0071] S103. The scheduling function calls the corresponding layer processing function based on the value of the process layer state variable. The layer processing function performs atomic operations on the single bus pin based on the operation layer, byte layer and bit timing layer state variables. The state machine scheduling function is the core driver of this invention. Its internal logic implements the non-blocking scheduling strategy described above: "exit interrupt if a delay is needed, and execute continuously if no delay is needed."

[0072] Specifically, the execution flow of the scheduling function DS18B20_TimerCallback() is as follows: 1. Clear loop flag: Set the loop flag of the data structure to 0.

[0073] 2. Enter the do-while loop: This loop is conditional on the loop flag.

[0074] 3. Based on the value of deep_lvl0_step, the corresponding level processing function is called via switch-case or function pointer jump table. For example, if deep_lvl0_step is 0, Reset_Handler() (reset processing function) is called; if it is 1, Send_Conversion_Cmd_Handler() (send conversion command processing function) is called, etc.

[0075] 4. Inside the hierarchical processing function, it executes an atomic operation based on the state variable of its next level (such as deep_lvl1_step). An atomic operation can be: Operating GPIO pins: Set the pin to output mode and pull it low / high, or set it to input mode to read the level.

[0076] Read / write temporary variables: Store the logic level read from the pin into bit_tmp, or retrieve the bit to be sent from the buffer.

[0077] Update state variable: Increment the state variable of the current level by 1 to indicate the next substep or microstep.

[0078] 5. Determine if waiting is necessary: If the atomic operation requires waiting for a preset time (e.g., holding the pin low for 480 μs), then: Call the timer start function to write the preset delay time (e.g., 480μs) into the auto-reload register and start the timer.

[0079] Keep the loop flag at 0.

[0080] The system immediately returns to the scheduler. The scheduler detects that `loop` is 0, exits the `do-while` loop, terminates the current interrupt service routine, and releases the CPU.

[0081] If the atomic operation does not require waiting (e.g., simply updating the value of a variable in memory), then: Set the loop flag to 1.

[0082] Return from the hierarchical processing function to the scheduling function.

[0083] 6. The scheduling function checks the loop flag. Since loop is 1, the do-while loop will continue to execute, and within the same interrupt service routine, the handler function will be called again according to deep_lvl0_step to execute the next atomic operation.

[0084] Through this mechanism, the present invention cleverly links a series of logically continuous operations, but with timing gaps, together using a state machine and timer interrupts. The CPU only intervenes briefly when precise timing operations and state judgments are required (i.e., during the execution of interrupt service routines and scheduling functions), while during long waiting gaps (such as the 750ms temperature conversion time), the CPU is completely released and can focus on core tasks such as pressure closed-loop control of the insufflator, flow PID regulation, and human-machine interface refresh.

[0085] S104. When the current atomic operation needs to wait for a preset period of time, start a hardware timer based on the preset period of time, set the loop flag to invalid, and exit the scheduling function; when there is no need to wait, set the loop flag to valid, and continue to call the next level processing function in the same interrupt. This step further clarifies the core scheduling logic in step S103. It defines the rules for the drive engine to switch between "time-driven" and "logic-driven" modes.

[0086] Time-Driven Mode: When encountering an atomic operation that requires waiting, the system enters "time-driven" mode. The preset time period required by the atomic operation (e.g., 480μs, 70μs, 7μs, etc.) is quantized into a hardware timer count. After the timer is started, CPU control is immediately returned. When the preset time period arrives, the hardware timer generates an interrupt, triggering the scheduling function again and driving the state machine to proceed to the next step. In this mode, the system's operating rhythm is precisely controlled by the hardware timer, ensuring the accuracy of communication timing and overcoming the vulnerability of software delays to interrupt interference.

[0087] Logic-Driven Mode: When encountering atomic operations that do not require waiting, the system enters "logic-driven" mode. By enabling the loop flag, the scheduler executes multiple logically related atomic operations consecutively within the same interrupt context. For example, after completing a bit read, the read bit value is immediately stored in the buffer and the bit counter is updated. This series of operations does not require waiting for physical timing and can therefore be completed efficiently within a single interrupt. This mode minimizes the number of interrupt entries and exits, reduces interrupt overhead, and improves program execution efficiency.

[0088] The organic combination of these two modes is the key technical means for achieving efficient and accurate non-blocking drive in this invention.

[0089] S105. By driving the process layer state variables through multiple timer interrupts, the reset, command sending and data reading stages are sequentially performed to complete the complete data interaction with the single bus sensor in a non-blocking manner. This step describes the macroscopic process of completing a full temperature acquisition using the mechanism described above. The process includes: Start-up reading: The pneumoperitoneum machine master control task calls the start function DS18B20_StartMeasurement(), which clears all state variables to zero and starts a very short timer (e.g., 1ms) to trigger the first interrupt, thereby starting the entire state machine.

[0090] First reset phase: The scheduling function is called during the first interrupt, with deep_lvl0_step set to 0. It calls the reset handler function, which, based on deep_lvl1_step, goes through sub-steps such as pulling the bus low, releasing the bus, reading the acknowledge pulse, and restoring the bus. Delays between each sub-step (e.g., 480μs, 70μs) are implemented by starting a hardware timer, during which the CPU is released. If a sensor is detected (presence = 1), the process layer state deep_lvl0_step is advanced to 1 (temperature conversion command sending phase), and loop is set to 1 so that the next phase can be immediately entered within the same interrupt.

[0091] During the temperature conversion command sending phase: the scheduling function calls the corresponding processing function based on deep_lvl0_step = 1. This processing function sequentially sends the "Skip ROM command" (0xCC) and the "Start Temperature Conversion Command" (0x44). The transmission of each byte is controlled by the byte-level and bit-timing-level state machines, undergoing multiple interrupts. After transmission is complete, a 750ms long timer is started, and deep_lvl0_step is updated to 2 (waiting for conversion completion phase), then the interrupt exit is completed.

[0092] Specifically, 0xCC and 0x44 are sent sequentially. The transmission of each byte is further broken down into the transmission of 8 bits, and each bit is further broken down into 2 to 3 micro-steps. Since there is a timer delay between each micro-step, the entire process will enter and exit interrupts multiple times. However, because the bits and bytes are continuously scheduled through the loop flag (steps that do not need to wait will be executed immediately), the actual number of interrupts is far less than the theoretical maximum number.

[0093] Waiting for conversion phase: During the next 750ms, no interrupts related to this sensor are generated. The CPU of the pneumoperitoneum machine's main control chip is fully released and can execute other tasks at full speed.

[0094] Specifically, after sending the conversion command, a 750ms timer is started, and then the interrupt is exited. During the next 750ms, the CPU is completely free, and the insufflator can perform tasks such as pressure sampling, PID control, and user interface refresh.

[0095] The second reset, read command sending, and data reading phase: After the 750ms long timer times out, an interrupt is generated, and the scheduling function is called again. At this time, deep_lvl0_step is 2, and the scheduling function directly advances it to 3 (second reset phase). Subsequently, the state machine sequentially goes through the second reset (phase 3), sending the read register command (phase 4, sending 0xCC and 0xBE), and reading 9 bytes of data (phase 5). Each bit and each byte of data read is precisely completed through the bit timing layer and byte layer state machine, combined with hardware timer interrupts.

[0096] Specifically, after 750ms, the timer interrupts, the scheduling function finds the process layer state is 2 (waiting for transition to complete), and directly advances it to 3 (second reset). Then, the second reset is executed (also going through 4 interrupt steps), and immediately after completion, it enters stage 4 (sending read command).

[0097] Send 0xCC and 0xBE, then read 9 bytes consecutively. Each byte read requires 8 bit cycles, and each bit cycle requires 4 microsteps, but through loop optimization, the total number of interrupts is significantly reduced.

[0098] Data processing and termination phase: After all 9 bytes have been read, deep_lvl0_step enters phase 6. In this phase, the program performs CRC checks and temperature calculations, then resets the state machine and notifies the pneumoperitoneum machine's main control system that the data acquisition is complete via a message queue or callback function.

[0099] Specifically, after reading 9 bytes, a CRC check and temperature conversion are performed, and then the temperature value is reported to the insufflator's main control system via a task notification. Finally, the process layer state is reset to 0, preparing for the next data acquisition. After reading 9 bytes of data (8 bytes of temperature buffer + 1 byte of CRC), a CRC check is performed. If the check passes, the raw data is converted to the actual temperature according to the DS18B20 resolution (default 12 bits): Actual temperature = (int16_t)((high 8 bits << 8) | low 8 bits) * 0.0625℃. If the check fails or no pulse is detected from the sensor during reset, the temperature is marked as invalid and a fault is reported to the upper layer. The insufflator can trigger an alarm and stop heating or take protective measures.

[0100] Throughout the process, the CPU's usage time is only the cumulative time of each interrupt service routine and scheduling function execution (typically in the microsecond range), while the majority of the waiting time in the entire acquisition cycle (750ms conversion time plus the waiting time between all bus operations) is used by the CPU to handle other tasks of the pneumoperitoneum machine. This perfectly achieves non-blocking data interaction.

[0101] In some embodiments, process layer state variables in this application The complete state transition, where the state variable manages the macroscopic process of a single temperature acquisition, extends far beyond the simple "read data" loop described in the comparative documents. The specific state sequence is as follows: S0 (IDLE): Idle, waiting for the start command.

[0102] S1 (RST1): First reset phase, send reset pulse and detect response.

[0103] S2 (SEND_CVT): Sends the command to skip ROM (0xCC) and temperature conversion (0x44).

[0104] S3 (WAIT_CVT): Long-term state (e.g., 750ms) waiting for the temperature transition to complete.

[0105] S4 (RST2): Second reset phase, preparing for data reading.

[0106] S5 (SEND_RD): Send the command to skip ROM (0xCC) and read temporary register (0xBE).

[0107] S6 (READ): Reads 9 bytes of raw data consecutively.

[0108] S7 (PROC): Data processing and completion, performing CRC check and temperature conversion.

[0109] State transition condition equations:

[0110] in: Indicates the current process layer status.

[0111] Indicates the state of the next process layer.

[0112] It is a start flag from the upper-level task.

[0113] It is a response pulse flag detected during the reset phase; 1 indicates the presence of a sensor.

[0114] It is a reset failure retry counter.

[0115] This is the preset maximum number of retries.

[0116] It is a command byte transmission completion flag.

[0117] It is a long timer overflow event flag.

[0118] It is a public error handling state.

[0119] This state transition equation fully demonstrates the scheme's ability to manage complex processes, including abnormal retries, with precision.

[0120] S106. Based on the read original byte sequence, calculate the final physical quantity detection result according to the preset conversion logic.

[0121] After the data reading phase is complete, the scheduling function obtains the raw byte sequence read from the sensor. For the DS18B20 sensor, this sequence is 9 bytes long and includes: Byte 0: The lower 8 bits (LSB) of the temperature value.

[0122] Byte 1: The high 8 bits (MSB) of the temperature value.

[0123] Bytes 2 through 8: TH register, TL register, configuration register, and reserved bytes, etc.

[0124] Byte 8: Cyclic Redundancy Check (CRC) value of the first 8 bytes.

[0125] In this step, the following operations will be performed: Perform Cyclic Redundancy Check (CRC): Calculate the CRC-8-Dallas / Maxim algorithm according to the DS18B20 datasheet for the first 8 bytes of data, and compare the calculation result with the CRC value of the 9th byte of data.

[0126] Data Extraction and Conversion: If the CRC check passes, the first byte (LSB) and second byte (MSB) representing the temperature are extracted from the original byte sequence. The second byte (MSB) is left-shifted by 8 bits and then bitwise ORed with the first byte (LSB) to form a 16-bit signed integer value. Based on the characteristics of the DS18B20 sensor, its default resolution is 12 bits, and each least significant bit (LSB) represents a temperature value of 0.0625°C. Therefore, multiplying the aforementioned 16-bit signed integer value by the preset temperature resolution coefficient 0.0625 yields the final actual temperature value (in degrees Celsius, °C). That is: Actual Temperature = (int16_t)((MSB << 8) | LSB) * 0.0625.

[0127] Anomaly Handling: If the CRC check fails, or if no response pulse from the sensor is detected during the previous reset phase, the final physical quantity detection result will be marked as a predefined invalid value (e.g., 998.0 or 999.0) to inform the insufflator's main control system that the current temperature data is invalid. The insufflator can then trigger an alarm and take corresponding safety protection measures (such as stopping heating).

[0128] This step ensures the integrity and accuracy of the temperature data, providing reliable feedback data for the closed-loop temperature control of the insufflator.

[0129] In some embodiments, process layer state variables are used to manage the macro-level phases of a complete data interaction, which include at least a reset phase, a command sending phase, and a data reading phase. Operational state variables are used to manage the sequence of sub-steps within each macroscopic stage; Byte-level state variables are used to manage the bit-by-bit sending or receiving count of individual byte data; Bit-sequence layer state variables are used to manage the timing of micro-operations in a single bit operation.

[0130] This embodiment provides a more specific definition of the functionality of the four-level state variables.

[0131] Process layer state variables: As mentioned earlier, their role is to manage the macro-level phases of a complete data interaction. They can be understood as a task scheduler, determining whether a higher-level task such as "reset," "send command," or "read data" should be performed.

[0132] Operational layer state variables: Their role is to manage the sequence of sub-steps within each macro-level stage. For example, under the macro-level task of "reset stage", it manages specific sub-tasks such as "pull low", "release", and "read".

[0133] Byte-level state variables: Their function is to manage the bit-by-bit sending or receiving count of a single byte. It breaks down the task of "sending a byte" into the process of "sending bit 0, bit 1... bit 7".

[0134] Bit timing layer state variables: Their function is to manage the timing of micro-operations in a single bit operation. It further decomposes the task of "sending a bit" into finer-grained micro-operations that directly manipulate hardware pins, such as "pulling the bus low, delaying, setting the level, delaying again, etc."

[0135] These four layers of state variables, arranged from top to bottom, progressively decompose a complex, time-sensitive communication task into a well-defined and logically clear state machine network. The technical benefits of this layered design are significant: 1) Improved code readability and maintainability. Each layer focuses only on its own logic, reducing code coupling. 2) Enhanced system scalability. If support for other single-bus devices or modification of a timing parameter is required, only the processing logic at the corresponding layer needs to be modified, without affecting the entire driver framework.

[0136] In some embodiments, during the reset phase, the scheduling function executes the following sub-steps sequentially based on the values ​​of the operation layer state variables: Set the single-bus pin low and start the first timer; Release the single-bus pin and start the second timing; Read the single-bus pin level to determine if the sensor response pulse exists, and start the third timing. The single-bus pin is restored to a high level, and the process layer state variable is advanced based on the presence or absence of a sensor response pulse.

[0137] This embodiment specifically defines the sub-steps executed based on the operation layer state variables during the reset phase.

[0138] Sub-step 0: Set the single-bus pin low and initiate the first timing (e.g., 480μs). This operation marks the start of sending a reset pulse; the low level must be maintained for at least 480μs to notify the sensor host to prepare for a reset.

[0139] Sub-step 1: Release the single-bus pin (i.e., configure it to input mode, pulled high by the pull-up resistor) and start the second timing (e.g., 70μs). This operation prepares for waiting for the sensor to send an acknowledgment pulse.

[0140] Sub-step 2: Read the single-bus pin level to determine if the sensor response pulse exists, and start the third timing (e.g., 410μs). If a low level is read, it indicates that the sensor exists and has responded. The subsequent 410μs timing is to meet the integrity requirements of the reset timing.

[0141] Sub-step 3: Restore the single-bus pin to a high output level and determine whether to advance the process layer state variable based on the presence of a sensor response pulse. If a response is present, increment deep_lvl0_step by 1 and proceed to the next macroscopic stage; otherwise, jump directly to error handling or report a fault.

[0142] Through this fine-grained state division and timer-driven approach, every timing critical point in the reset process is precisely controlled, and the CPU is released during multiple delay periods (such as 480μs, 70μs, and 410μs). This effectively solves the reset timing deviation problem caused by CPU occupancy and improves the communication success rate.

[0143] In some embodiments, during the command sending phase or data reading phase, the scheduling function determines whether the current byte has been sent or received completely based on the value of the byte-level state variable. If not completed, the corresponding write bit micro-operation or read bit micro-operation is executed based on the value of the bit timing layer state variable.

[0144] This embodiment clarifies the collaborative working method between the byte layer and the bit timing layer during the command sending or data reading phase. When sending or reading a byte, the scheduling function first checks the byte layer state variable deep_lvl2_step. If deep_lvl2_step is less than 8, it indicates that a byte has not yet been completely transmitted. At this point, program control is further delegated to the bit timing layer, which executes the corresponding write or read bit micro-operation based on the value of deep_lvl3_step. This layer-by-layer decomposition and invocation method is a concrete manifestation of the layered state machine architecture.

[0145] In some embodiments, the write bit micro-operation includes: Set the single-bus pin low and start the fourth timer; Based on the bit value to be written, after the fourth timing ends, the single-bus pin is set to the corresponding level and the fifth timing is started; After the fifth timing period ends, the single-bus pin is set to high and the byte-level state variables are updated.

[0146] This embodiment specifically defines the steps of the write bit micro-operation. The timing and state transition process of the write bit micro-operation (taking writing "1" as an example) is as follows: Microstep 0: Set the single-bus pin low and start the fourth timing (e.g., 7μs). Whether writing a 0 or a 1, the host must first pull the bus low for a period of time as the start of the write time slot.

[0147] Microstep 1: After the fourth timing ends, set the single-bus pin to the corresponding level according to the bit value to be written and start the fifth timing (e.g., 80μs). If writing "1", pull the pin high at this time; if writing "0", keep it low.

[0148] Microstep 2: After the fifth timing ends, set the single-bus pin to high level (if it was low level before), end the writing of this bit, and update the byte layer state variable (deep_lvl2_step incremented by 1).

[0149] This process precisely replicates the timing requirements of a single-bus write time slot using a state machine. By controlling the 7μs and 80μs intervals with a hardware timer instead of a software delay, the timing accuracy can be reliably guaranteed even in systems with frequent interrupts.

[0150] In some embodiments, the read bit micro-operation includes: Set the single-bus pin low and start the sixth timer; Release the single-bus pin and start the seventh timer; Read the single-bus pin level and store it in a temporary variable, and start the eighth timer at the same time; After the eighth timing period ends, the single-bus pin is set to high level, and the byte-level state variable is updated based on the bit value in the temporary variable.

[0151] This embodiment specifically defines the steps of the read bit micro-operation. The timing and state transition flow of the read bit micro-operation is as follows: Microstep 0: Set the single-bus pin low and start the sixth timing (e.g., 5μs). The host pulls the bus low to start the read time slot.

[0152] Microstep 1: Release the single-bus pin (set to input mode) and start the seventh timing (e.g., 10μs). Releasing the bus allows the sensor to drive the bus level.

[0153] Micro-step 2: Read the single-bus pin level and store it in a temporary variable (bit_tmp), while simultaneously starting the eighth timer (e.g., 70μs). The level read at this time is the bit data sent by the sensor. After reading, you need to wait for the read time slot to end.

[0154] Microstep 3: After the eighth timing ends, restore the single bus pin to the output high level, and update the byte layer state variable based on the bit value in the temporary variable (combine the read bits into the byte variable and increment the bit counter deep_lvl2_step).

[0155] Similar to write operations, the critical timing points of read operations (low at 5μs, read after 10μs) are precisely controlled by hardware timers to ensure the reliability of read data. Read bit micro-operations are more complex than write bit micro-operations because they involve switching the input / output direction of pins, and the state machine clearly manages this process.

[0156] In some embodiments, during the command sending phase, the scheduling function sends a skip ROM command and a start conversion command to the single-bus sensor in sequence based on the current value of the process layer state variable, and then starts a long timer and updates the process layer state variable to the waiting conversion phase; During the waiting transition phase, the scheduling function stops operating on the single-bus sensor until a long timer overflow interrupt occurs, after which the process layer state variables are pushed to the reset phase.

[0157] This embodiment defines the waiting phase after sending the conversion command. After sending the start conversion command (0x44), the scheduling function starts a long timer (e.g., 750ms) and updates the process layer state deep_lvl0_step to "waiting for conversion" (e.g., phase 2). In this phase, when the scheduling function is called (e.g., triggered by another timer interrupt), it checks that it is currently in the "waiting for conversion" phase, so it stops any operation on the single-bus sensor, does not start a new short timer, and exits directly. Only when the previously started long timer overflows and the scheduling function is called again does it advance deep_lvl0_step to the next phase (e.g., the second reset phase).

[0158] The technical advantage of this feature lies in its ingenious use of the "idle" state of the state machine to achieve non-blocking processing during wait times of hundreds of milliseconds. During the 750ms wait for transitions, the state machine remains in a "silent" state, generating no additional interrupt overhead, and CPU resources are completely freed up for other real-time tasks of the pneumatic compressor. This contrasts sharply with the traditional blocking approach where the CPU is wasted for 750ms, and is the key to this invention's improved system real-time performance.

[0159] In some embodiments, during the temperature conversion waiting phase of the DS18B20, the technical advantages of the present invention can be precisely quantified by improving CPU utilization. Let a complete temperature acquisition and processing cycle of the insufflator be... This cycle consists of three parts:

[0160] in: The total active CPU time occupied by all bus communications (including reset, command sending, data reading, etc.).

[0161] : Physical time to wait for temperature transition (usually 750ms).

[0162] CPU usage time for data verification and temperature conversion.

[0163] For traditional blocking methods: the CPU is entirely... The CPU is unable to perform other tasks, and the effective CPU utilization is 100% occupied.

[0164] Regarding the method of this invention: the CPU only... and It was interrupted and awakened for a brief period of time, while occupying the majority of the time slice. During this period, the CPU is completely released. Define the CPU utilization rate under non-blocking drive mode. for:

[0165] Substitute typical values, It takes 5ms. It takes 750ms. If it is 0.1ms, then:

[0166] This means that compared to the blocking method, this invention reduces the CPU utilization for a single temperature acquisition task from 100% to less than 1%, freeing up over 99% of CPU time slices for higher-priority safety-critical tasks such as pressure detection, flow control, and overpressure alarms in the insufflator. The freed CPU time... The calculation formula is:

[0167] During this period, the insufflator's main control program executes a complete pressure PID control cycle, which is crucial for ensuring surgical safety.

[0168] In some embodiments, the insufflator controller memory defines state variables and loop flags including a process layer, an operation layer, a byte layer, and a bit timing layer, and further includes: Define a pulse presence flag to record whether a sensor response pulse is detected during the reset phase; Define a data buffer to store the raw byte sequence read from the single-bus sensor; Define a bit index counter and a byte index counter to record the number of bits and bytes that have been read or sent, respectively.

[0169] This embodiment provides additional constraints on other auxiliary variables in the data structure.

[0170] Presence flag: Used to record whether a sensor response pulse was detected during the reset phase. This is a critical status flag that determines whether subsequent processes can continue.

[0171] Data buffer (data_buf[9]): A 9-byte array used to store the raw byte sequence read from the sensor, which is the basis for subsequent data processing.

[0172] The bit index counter (bit_index) and byte index counter (byte_index) are used to record the number of bits and bytes that have been read or sent, respectively. These counters function similarly to the aforementioned byte-level state variables (deep_lvl2_step), providing finer-grained control and making the program logic clearer.

[0173] These auxiliary variables, together with the core four-layer state variables, constitute a complete data structure, providing the necessary data support for the normal operation of the state machine.

[0174] In some embodiments, after calculating the final physical quantity detection result based on a preset conversion logic according to the read original byte sequence, the method further includes: Perform cyclic redundancy check on the original byte sequence; If the verification passes, the first and second bytes representing the temperature are extracted from the original byte sequence. The first byte is combined with the second byte after shifting it eight bits to the left to obtain a signed integer value. The signed integer value is then multiplied by the preset temperature resolution coefficient to obtain the final temperature value. If the verification fails, the final physical quantity detection result will be marked as invalid.

[0175] This embodiment specifically defines the Cyclic Redundancy Check (CRC) and temperature conversion logic in the data processing stage. The CRC check and temperature conversion process has been described in detail in step S106 above. Here, it is important to emphasize its technical effect: CRC check provides an effective error detection mechanism that can identify data errors caused by interference or other reasons during communication. When the check fails, the temperature is marked as invalid, which can prevent the insufflator from making incorrect control decisions (such as overheating or not heating) due to the use of incorrect temperature data, thereby ensuring patient safety and the effectiveness of treatment.

[0176] In some embodiments, configuring a hardware timer and calling a scheduling function in its interrupt service includes: Configure the hardware timer to single-shot mode, dynamically setting the automatic reload value and starting it each time only based on the preset waiting period of the current atomic operation; In the interrupt service routine of the hardware timer, the hardware timer is stopped, the interrupt flag is cleared, and then the scheduling function is called.

[0177] This embodiment specifically defines the configuration and operating mode of the hardware timer. Configuring the hardware timer to single-shot mode (rather than periodic mode) and dynamically setting the automatic reload value based on the preset waiting period of the current atomic operation is one of the key design features of this invention. Its technical advantages are as follows: Flexibility: Different stages in a single-bus protocol require different delays (ranging from 5μs to 750ms). A one-time, dynamically configurable mode can perfectly accommodate these diverse needs.

[0178] Accuracy: Each delay is started independently, eliminating the cumulative error that may be caused by a periodic timer.

[0179] Safety: It avoids the risk of accidental interruption caused by timers continuing to run in the background when not needed.

[0180] Simplified interrupt service routines: Interrupt service routines only perform three tasks: stopping, clearing flags, and calling functions, ensuring fast interrupt response, which is crucial for real-time systems.

[0181] In addition, regarding integration with the insufflator main control system, this invention provides the following external interface functions for the insufflator main control task to call: DS18B20_Init(): Initializes GPIO pins, configures timers, and resets the state machine, but does not start temperature acquisition.

[0182] DS18B20_StartMeasurement(): Initiates a non-blocking temperature acquisition. This function clears all status variables, starts a timer, and then returns immediately. After acquisition is complete, the main control system is notified via a callback function or message queue.

[0183] DS18B20_GetTemperature(float *temp): Retrieves the most recently successfully acquired temperature value. Returns a status code if data acquisition is currently in progress or an error has occurred.

[0184] DS18B20_Reset(): Forces a reset of the entire driver state machine for exception recovery.

[0185] The main control system of the pneumoperitoneum machine can call DS18B20_StartMeasurement() at regular intervals (e.g., 1 second) in its main loop, and read the temperature value after receiving the acquisition completion notification for closed-loop control of heating power.

[0186] Figure 2 A schematic diagram of the structure of a single-bus sensor drive system for an insufflator based on a hierarchical state machine, provided in an embodiment of this application, is shown. Figure 2 As shown, the single-bus sensor drive system for an insufflator based on a hierarchical state machine includes: Define module 201, which is used to define state variables and loop flags including process layer, operation layer, byte layer and bit timing layer in the memory of the insufflator controller; Configuration module 202 is used to configure hardware timers and call scheduling functions in their interrupt services; The calling module 203 is used to schedule the function to call the corresponding layer processing function according to the value of the process layer state variable. The layer processing function performs atomic operations on the single bus pin based on the operation layer, byte layer and bit timing layer state variables. The judgment module 204 is used to start a hardware timer based on the preset time period and set the loop flag to invalid before exiting the scheduling function when the current atomic operation needs to wait for a preset time period; when there is no need to wait, the loop flag is set to valid and the next level processing function is called in the same interrupt. Interaction module 205 is used to drive the process layer state variables through multiple timer interrupts to go through the reset, command sending and data reading stages in sequence, so as to complete the complete data interaction with the single bus sensor in a non-blocking manner. The calculation module 206 is used to calculate the final physical quantity detection result based on the read original byte sequence and a preset conversion logic.

[0187] Figure 2 Each module in the system shown has the ability to implement Figure 1 The functions of each step in the process and their corresponding technical effects are described in detail here for the sake of brevity.

[0188] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown.

[0189] The electronic device may include a processor 301 and a memory 302 storing computer program instructions.

[0190] Specifically, the processor 301 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0191] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 302 may include removable or non-removable (or fixed) media. Where appropriate, memory 302 may be internal or external to an electronic device. In a particular embodiment, memory 302 may be a non-volatile solid-state memory.

[0192] In one embodiment, memory 302 may be read-only memory (ROM). In one embodiment, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0193] The processor 301 reads and executes computer program instructions stored in the memory 302 to implement any of the single-bus sensor driving methods for pneumoperitone machines based on hierarchical state machines in the above embodiments.

[0194] In one example, the electronic device may also include a communication interface 303 and a bus 310. For example, Figure 3 As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 310 and complete communication with each other.

[0195] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0196] Bus 310 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 310 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0197] Furthermore, in conjunction with the hierarchical state machine-based single-bus sensor driving method for insufflator described in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the hierarchical state machine-based single-bus sensor driving methods for insufflator described in the above embodiments.

[0198] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0199] The functional modules shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0200] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0201] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0202] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A layered state machine based insufflator single bus sensor driving method, characterized in that, include: Define state variables and loop flags in the memory of the insufflator controller, including the process layer, operation layer, byte layer, and bit timing layer; Configure the hardware timer and call the scheduling function in its interrupt service routine; The scheduling function calls the corresponding hierarchical processing function according to the value of the process layer state variable. The hierarchical processing function performs atomic operations on a single bus pin based on the operation layer, byte layer and bit timing layer state variables. When the current atomic operation needs to wait for a preset period of time, the hardware timer is started based on the preset period of time, the loop flag is set to invalid, and the scheduling function is exited; when there is no need to wait, the loop flag is set to valid, and the next level processing function is called again within the same interrupt. By driving the process layer state variables through multiple timer interrupts to sequentially go through the reset, command sending and data reading stages, the complete data interaction with the single bus sensor is completed in a non-blocking manner. Based on the read original byte sequence, the final physical quantity detection result is obtained by calculating based on the preset conversion logic.

2. The layered state machine based insufflator single bus sensor drive method of claim 1, wherein, The process layer state variables are used to manage the macro-level phases of a complete data interaction, which include at least a reset phase, a command sending phase, and a data reading phase. The operation layer state variables are used to manage the sequence of sub-steps within each of the macroscopic stages; The byte-level state variables are used to manage the bit-by-bit sending or receiving count of individual byte data; The bit timing layer state variables are used to manage the timing of micro-operations in a single bit operation.

3. The single-bus sensor driving method for an insufflator based on a hierarchical state machine according to claim 2, characterized in that, During the reset phase, the scheduling function executes the following sub-steps sequentially based on the values ​​of the operation layer state variables: Set the single-bus pin low and start the first timer; Release the single-bus pin and start the second timing; Read the single-bus pin level to determine if the sensor response pulse exists, and start the third timing. The single-bus pin is restored to a high level, and the process layer state variable is advanced based on the presence or absence of the sensor response pulse.

4. The single-bus sensor driving method for an insufflator based on a hierarchical state machine according to claim 2, characterized in that, During the command sending phase or the data reading phase, the scheduling function determines whether the current byte has been sent or received completely based on the value of the byte layer state variable. If not completed, the corresponding write bit micro-operation or read bit micro-operation is executed based on the value of the bit timing layer state variable.

5. The single-bus sensor driving method for an insufflator based on a hierarchical state machine according to claim 4, characterized in that, The write bit micro-operation includes: Set the single-bus pin low and start the fourth timer; Based on the bit value to be written, after the fourth timing ends, the single-bus pin is set to the corresponding level and the fifth timing is started; After the fifth timing period ends, the single-bus pin is set to high level, and the byte layer state variable is updated.

6. The single-bus sensor driving method for an insufflator based on a hierarchical state machine according to claim 4, characterized in that, The read position micro-operation includes: Set the single-bus pin low and start the sixth timer; Release the single-bus pin and start the seventh timer; Read the single-bus pin level and store it in a temporary variable, and start the eighth timer at the same time; After the eighth timing period ends, the single-bus pin is set to high level, and the byte-level state variable is updated based on the bit value in the temporary variable.

7. The single-bus sensor driving method for an insufflator based on a hierarchical state machine according to claim 2, characterized in that, During the command sending phase, the scheduling function sends a skip ROM command and a start conversion command to the single-bus sensor in sequence based on the current value of the process layer state variable, and then starts a long timer and updates the process layer state variable to the waiting conversion phase. During the waiting transition phase, the scheduling function stops operating on the single-bus sensor until the long timer overflow interrupt occurs, after which the process layer state variable is advanced to the reset phase.

8. The single-bus sensor driving method for an insufflator based on a hierarchical state machine according to claim 1, characterized in that, The definition of state variables and loop flags in the insufflator controller memory, including process layer, operation layer, byte layer, and bit timing layer, also includes: Define a pulse presence flag to record whether a sensor response pulse is detected during the reset phase; Define a data buffer to store the raw byte sequence read from the single-bus sensor; Define a bit index counter and a byte index counter to record the number of bits and bytes that have been read or sent, respectively.

9. The single-bus sensor driving method for an insufflator based on a hierarchical state machine according to claim 1, characterized in that, After calculating the final physical quantity detection result based on the read original byte sequence and a preset conversion logic, the method further includes: Perform cyclic redundancy check on the original byte sequence; If the verification passes, the first byte and the second byte representing the temperature are extracted from the original byte sequence. The first byte is combined with the second byte after shifting it eight bits to the left to obtain a signed integer value. The signed integer value is then multiplied by a preset temperature resolution coefficient to obtain the final temperature value. If the verification fails, the final physical quantity detection result will be marked as invalid.

10. The single-bus sensor driving method for an insufflator based on a hierarchical state machine according to claim 1, characterized in that, The configuration of the hardware timer and the invocation of the scheduling function in its interrupt service include: Configure the hardware timer to single-use mode, dynamically setting the automatic reload value and starting it each time only according to the preset waiting period of the current atomic operation; In the interrupt service routine of the hardware timer, the hardware timer is stopped, the interrupt flag is cleared, and then the scheduling function is called.

Images