Information communication method and system and charging device
By starting a timer during communication and updating or retransmitting data packets based on response signals, the problem of insufficient communication reliability in existing technologies is solved, resulting in a more stable and secure communication link and avoiding equipment damage and safety accidents caused by misjudgment.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- LUXSHARE PRECISION TECH(NANJING) CO LTD
- Filing Date
- 2026-03-27
- Publication Date
- 2026-05-19
AI Technical Summary
In existing technologies, there are problems with insufficient control precision and reliability during communication, especially in charging control scenarios, which can easily lead to timing errors or misjudgments, potentially causing equipment damage and safety accidents.
By responding to interrupt trigger commands, a timer is started and the target working mode is switched. If a successful verification response signal is received within a preset time, the timer is updated; otherwise, the data packet is retransmitted or the working mode is switched to a different mode. By combining the retransmission mechanism and the timer update strategy, the continuous effectiveness of the communication link is ensured.
It improves the reliability and anti-interference capability of the communication process, avoids mode switching caused by misjudgment, and ensures the stability and security of the communication link.
Smart Images

Figure CN122069013A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technology, and in particular to an information communication method, system and charging device. Background Technology
[0002] With the widespread application of intelligent devices and control systems, higher demands are placed on the stable management of data processing units. Existing technologies mainly employ two methods: one uses a multi-task coordination mechanism to manage processes through inter-task communication; the other infers process completion by monitoring the idle state of communication lines, triggering mode switching when idleness is detected. These methods generally suffer from insufficient control precision and reliability, easily leading to timing errors or misjudgments. Especially in high-voltage, high-current scenarios such as charging control, if the inferred mode switching misjudges, it may activate the charging mode at the wrong time, potentially causing equipment damage or even safety accidents. Summary of the Invention
[0003] Based on this, the present invention provides several embodiments of an information communication method, apparatus, computer equipment, computer-readable storage medium, and computer program product, wherein at least one embodiment is used to solve the problem of insufficient accuracy and reliability of mode switching control caused by communication response timeout or timing disorder in the prior art.
[0004] Firstly, this application provides an information communication method. The method includes:
[0005] Respond to the interrupt trigger command, determine the data to be processed, and start the timer;
[0006] Switch to the target first working mode, wherein the data packet formed by the encapsulated data is used to send in the first working mode;
[0007] If a first response signal is received within a first preset time, and the first response signal is a first agreed value, then the timer is updated, whereby the first agreed value indicates that at least one frame in the data packet has been successfully verified.
[0008] In one embodiment, the method further includes:
[0009] If no first response signal is received within a first preset time, or if the first response signal received within the first preset time is a second agreed value, then one of the following strategies will be executed, wherein the second agreed value indicates that at least one frame in the data packet has failed verification:
[0010] Retransmit the data packet;
[0011] Retransmit the data packet and update the timer.
[0012] In one embodiment, the method further includes:
[0013] If a second response signal is received, the system switches to a second operating mode; wherein the second response signal indicates that all data packets have been received and that each first response signal in the data packets has been verified to a first agreed value.
[0014] In one embodiment, the method further includes:
[0015] If the timer exceeds a second preset time after receiving the second response signal, the system switches to the second working mode; wherein, the second response signal indicates that the data packet has been fully received and that each first response signal in the data packet has been verified to a first agreed value.
[0016] In one embodiment, if the data packet is retransmitted and the timer is updated, the method further includes:
[0017] Calculate the number of times the data packet was retransmitted;
[0018] When the number of attempts reaches a preset threshold, a warning signal indicating communication failure is sent.
[0019] In one embodiment, the method further includes:
[0020] If a third response signal is received in the first working mode, and / or if electrical parameters are detected to meet preset conditions in the second working mode, the configuration is to terminate the first and second working modes; wherein the second working mode includes a charging mode, the first working mode includes a communication mode, and the third response signal is a third agreed value, which indicates that charging is successful in the charging mode.
[0021] In one embodiment, encapsulating the data includes:
[0022] The data is encapsulated based on the protocol layer protocol to obtain the data segments in the data packet;
[0023] The data is encapsulated based on the physical layer protocol to obtain the control segment of the data packet, and then combined with the data segment.
[0024] In one embodiment, the method further includes:
[0025] If the timer exceeds the second preset time after receiving the second response signal, and a charging indicator is present, then the system switches to the second working mode.
[0026] Secondly, this application also provides a charging device. The device includes:
[0027] The processor is configured to respond to an interrupt trigger command, determine the data to be processed, and encapsulate the data to be processed into a data packet; send a start command to a timer; send a command to the execution module to switch to the target first working mode; and if a first response signal is received within a first preset time, and the first response signal is a first agreed value, send a reset command to the timer; wherein, the first agreed value indicates that at least one frame in the data packet has been successfully verified.
[0028] A timer, connected to the processor, is used to receive start commands and reset commands sent by the processor, and to perform start and reset operations;
[0029] An execution module, connected to the processor, is configured to receive a command from the processor to switch to the target first working mode, switch to the target first working mode, receive a first response signal, and transmit the first response signal to the processor.
[0030] Thirdly, this application also provides an information communication system. The system includes:
[0031] The host computer is used to respond to interrupt trigger commands, determine the data to be processed, and start a timer; send a mode switching command to the slave device to switch the slave device to a target first working mode; when the slave device is in the first working mode, send a data packet formed by the encapsulated data to the slave device; if a first response signal is received from the slave device within a first preset time, and the first response signal is a first agreed value, then the timer time is updated, where the first agreed value indicates that at least one frame in the data packet has been successfully verified.
[0032] The slave device is used to perform the working mode conversion of the slave device according to the mode switching instruction.
[0033] Fourthly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the information communication method as described in any one of the embodiments of this disclosure.
[0034] Fifthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the information communication method as described in any one of the embodiments of this disclosure.
[0035] Sixthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the information communication method as described in any of the embodiments of this disclosure.
[0036] The aforementioned information communication methods, devices, computer equipment, storage media, and computer program products, upon responding to an interrupt, start a timer and switch to a first operating mode to send data packets; if a specific response signal indicating successful data verification is received within a preset time, the timer is reset to maintain the current mode. This timer reset mechanism refreshes the timeout window based on valid data interaction during communication, preventing premature exit from the operating mode due to fixed timeouts, which could lead to communication link interruption. This mechanism ensures the continuous effectiveness of the communication link, avoids premature switching of communication modes, and effectively improves the reliability and anti-interference capability of the communication process. Attached Figure Description
[0037] Figure 1 This is a diagram illustrating the application environment of an information communication method in one embodiment.
[0038] Figure 2 This is a flowchart illustrating an information communication method in one embodiment;
[0039] Figure 3 This is a schematic diagram of the first process of implementing an information communication method in one embodiment;
[0040] Figure 4 This is an application environment diagram illustrating the implementation of the information communication method in one embodiment;
[0041] Figure 5 This is a schematic diagram of the second process of implementing the information communication method in one embodiment;
[0042] Figure 6 This is a schematic diagram of the third process of implementing the information communication method in one embodiment;
[0043] Figure 7 This is a structural block diagram of a charging device in one embodiment;
[0044] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0045] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0046] One embodiment of this application provides an information communication method that can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. In this application environment, terminal 102 can be used to issue an interrupt trigger command; server 104 is configured to execute the method in this embodiment: in response to the command, it determines the data to be processed and starts a timer; subsequently, server 104 switches to a target first working mode, in which it encapsulates the data into data packets and sends them; if server 104 receives a first response signal within a first preset time, and the signal is a first agreed value indicating that at least one frame in the data packet has been successfully verified, then the timer time is updated to continue the subsequent process. Related status and logs can be saved to the data storage system. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.
[0047] In one embodiment, such as Figure 2 As shown, an information communication method is provided, the method comprising:
[0048] Step S200: Respond to the interrupt trigger command, determine the data to be processed, and start the timer.
[0049] The interrupt triggering command can include hardware interrupt events or software triggering events. For example, hardware interrupt events can include Pogo Pin (spring-loaded connector), USB (Universal Serial Bus), or any other interface insertion detection interrupt, UART (Abstract Management Serial Port) receive buffer full interrupt, power management chip state change interrupt, GPIO (General Purpose Input / Output) level change interrupt, etc. Software triggering events can include application layer communication request events, timer timeout events, system state switching request events, etc. The data to be processed can include communication information or control commands, etc. For example, communication information can include UART data frames, application layer messages, etc. Control commands can include mode switching commands (such as switching from UART mode to charging mode); power control commands (such as starting / stopping charging), etc. The timer can include timeout timers, heartbeat timers, or mode maintenance timers, etc. For example, CCP AO (protocol layer) is a timeout timer used to monitor communication responses; Host Converter AO (host conversion active object) is a timeout timer used to monitor UART mode maintenance; Wire AO (active object, located at the physical link layer) is a timer used to periodically send heartbeat events, etc.
[0050] In one exemplary embodiment, the response interrupt trigger command may include sending only a simple event notification in the Interrupt Service Routine (ISR), transferring all time-consuming processing logic to the thread of the Active Object (AO); for example, in a Pogo Pin insertion interrupt, the ISR sends only an "insertion event" to the Host Converter AO. The Active Object Framework then distributes the event to the corresponding AO for processing; for example, the Lux Actor Framework routes the "insertion event" to the state machine of the Host Converter AO. Determining the data to be processed may include acquiring initial data, parsing and verifying the initial data, and then encapsulating and transmitting the data. For example, the Wire AO performs CRC verification on the received UART data; the CCP AO parses the application layer protocol message; the CCP AO encapsulates the application layer data into a transport layer data frame; the Wire AO sends the data frame to the Converter AO, or the Wire AO further encapsulates the data frame and sends it to the Converter AO.
[0051] Step S202: Switch to the target first working mode, wherein the data packet formed by the encapsulated data is used to send in the first working mode.
[0052] The target first working mode may include a communication mode or a data transmission mode, etc.; in one embodiment, the first working mode may include UART serial communication mode; I2C communication mode; SPI communication mode, etc.
[0053] In one exemplary embodiment, switching to the target first operating mode may include initiating a mode switching request, state machine state transitions, and hardware configuration and enabling. For example, before preparing to transmit data, the Wire AO sends an "Enter UART Mode" event to the Converter AO. The Host Converter AO responds to the event, transitioning from the Default state to the UartMode state (a specific operating state) in its internal state machine. During the entry action to UartMode, the Converter AO configures the multiplexing function of the Pogo Pin as a UART signal line and enables the UART controller.
[0054] Step S204: If a first response signal is received within a first preset time, and the first response signal is a first agreed value, then update the timer time, whereby the first agreed value indicates that at least one frame in the data packet has been successfully verified.
[0055] The first preset time can be set based on the data packet transmission rate, the complexity of the verification algorithm, and the system's requirements for timely response. For example, for UART communication using a baud rate of 115200bps, 8 data bits, 1 stop bit, and no parity, if the data packet length is 128 bytes, considering the data transmission time, slave verification processing time, and communication latency, in one embodiment, the first preset time can be set to a value between 50ms and 200ms. The specific value can be determined through multiple tests and in conjunction with system stability requirements. The first response signal can be a response frame in a specific format returned by the slave in response to the received data packet, containing fields indicating the verification result. For example, the response frame can include a frame header, a verification status bit, a frame tail, etc. The first response signal can include protocol layer responses or physical layer responses. For example, a heartbeat event sent by Wire AO to Converter AO after successfully receiving and verifying a data frame; an application layer response message received by CCP AO from the peer; a hardware response signal triggered by a UART receive interrupt; or a charging status signal returned by the power management chip. The first agreement can include a predefined verification success identifier or a protocol agreement value.
[0056] The first agreed-upon value can be defined as a "valid data frame acknowledgment identifier," etc. In one embodiment, the first agreed-upon value can be set to 0x01, etc. Specifically, in UART communication mode, when the Wire AO receives a data frame from the peer device via the Pogo Pin, it can immediately perform a CRC calculation on the frame. If the check result matches the check value carried at the end of the frame, it indicates that at least one data frame has been successfully received and its content is complete and error-free. At this time, the Wire AO will generate a heartbeat event containing the first agreed-upon value and actively send the event to the Converter AO, etc.
[0057] In one exemplary embodiment, updating the timer may include resetting or restarting the timer. For example, upon receiving a heartbeat event, the Host Converter AO resets the UART mode timeout timer; the CCP AO resets the communication timeout timer upon receiving a response.
[0058] In one exemplary embodiment, the data to be processed can be further encapsulated after switching to the target first operating mode. Specifically, after completing the mode switch, the data to be processed is retrieved from the data buffer or a specified storage location and then encapsulated.
[0059] Encapsulating the data to be processed can include directly encapsulating the entire data packet at once, generating a communication data packet containing a complete header, data segments, trailer, and checksum information according to a predetermined data packet format. This method is simple to implement, fast, and suitable for communication scenarios with small data volumes or high real-time requirements. Alternatively, it can involve first constructing the framework structure of the data packet header, trailer, and checksum information, and then filling the middle data portion into the framework to form a complete data packet. Whether using one-time encapsulation or step-by-step encapsulation, the data encapsulation process can be separated from the mode switching logic, thus decoupling the communication protocol processing from the hardware control logic. This decoupling design allows the protocol layer to focus on data processing and session management, while the physical layer focuses on media adaptation; changes in one layer will not directly affect the other. When the system needs to be ported to different hardware platforms or the communication medium needs to be changed, only the hardware control logic needs to be reimplemented for the new physical layer, while the data encapsulation layer can be completely reused; thereby significantly improving the system's portability and code reuse value. In addition, step-by-step encapsulation makes unit testing easier. Developers can test each layer independently and verify the correctness of the upper-layer logic by simulating the lower-layer interface, without relying on the real hardware environment. This allows them to discover and fix problems early in development and improve the overall code quality.
[0060] Alternatively, the data to be processed can be encapsulated before switching to the target first working mode. By completing the data encapsulation before mode switching, the time spent waiting for data encapsulation after switching can be avoided, thereby improving processing efficiency.
[0061] Encapsulating the data to be processed can include encapsulating the entire data packet directly; or it can include encapsulating the header, trailer, and checksum information of the data packet first, and then filling in the middle data portion, etc.
[0062] In the aforementioned information communication method, after responding to an interrupt, a timer is started and the system switches to the first operating mode (such as UART mode) to send data packets. If a first acknowledgment signal indicating successful data verification is received within a preset time, the timer is reset. The core advantage of this design is that it maintains the communication state through effective protocol layer interaction rather than physical level monitoring, thereby significantly improving the reliability and security of mode switching. Traditional solutions rely on bus idle detection, which is susceptible to interference or misjudgment, leading to switching to charging mode at unsafe times. In contrast, this method only refreshes the timer upon receiving a valid protocol acknowledgment (such as successful CRC verification), ensuring mode stability during active communication periods and preventing damage to the low-voltage communication interface caused by erroneous switching due to high-voltage charging. This results in substantial improvements in hardware protection and system reliability.
[0063] In one embodiment, the method further includes:
[0064] If no first response signal is received within a first preset time, or if the first response signal received within the first preset time is a second agreed value, then one of the following strategies will be executed, wherein the second agreed value indicates that at least one frame in the data packet has failed verification:
[0065] Retransmit the data packet;
[0066] Retransmit the data packet and update the timer.
[0067] The second response signal may include a verification failure flag, a protocol layer error code, a physical layer error code, etc. Failure to receive the first response signal within the first preset time may include timeout failure to receive a response. For example, the CCP AO starts a timeout timer after sending a request, and no response data frame is received from the peer after the timer expires; the Host Converter AO starts a timer in UART mode, and no heartbeat event is received from the Wire AO after the timeout.
[0068] The first response signal received within a first preset time, which is a second agreed-upon value, may include a response indicating a failed check. For example, after receiving a data frame, Wire AO performs a CRC check. If the check fails, it generates and sends an response event carrying a second agreed-upon value to the upper layer. Similarly, if a frame error or parity error is detected at the physical layer, an interrupt notification is sent to Serial AO (Serial Interface Active Object).
[0069] The second agreed-upon value can be defined as a "data frame verification failure flag" or an "invalid data frame acknowledgment flag," etc.; in one embodiment, the second agreed-upon value can be set to 0x02, etc. Specifically, in UART communication mode, when the Wire AO receives a data frame from the peer device via the Pogo Pin, it can immediately perform a CRC calculation on the frame. If the verification result does not match the checksum carried at the end of the frame, it indicates that an error occurred during the transmission of the frame data, and the content is incomplete or has been corrupted. At this time, the Wire AO will generate an error heartbeat event containing the second agreed-upon value and actively send the event to the Converter AO and the upper-layer CCP AO, etc.
[0070] In one exemplary embodiment, retransmitting the data packet may include retransmission counting and limit judgment, retransmission data packet content processing, and retransmission triggering and execution. Specifically, the retransmission counter can be incremented after each retransmission of the data packet; if the maximum number of retransmissions is reached, retransmission is stopped and a failure flag is uploaded. The retransmitted data packet can be the same as the original data packet, or the sequence number, timestamp, and other identifiers in the data packet can be updated. After the timeout period is triggered, the CCP AO can resend the EVT_SEND_FRAME event (send data frame event) to the Wire AO. In actual use, if communication fails after the system enters low-power mode, retransmission can be temporarily suspended and retransmitted after the system wakes up.
[0071] In another exemplary embodiment, retransmitting data packets and updating the timer may further include retransmitting and resetting the timer, and employing a backoff strategy or timer adjustment. For example, doubling the timeout after each retransmission; or dynamically adjusting the timer duration based on network load.
[0072] In one exemplary embodiment, if a first response signal carrying a first agreed value is not received within a first preset time, and the preset maximum retransmission count is reached, the current data packet transmission process can be stopped, and communication failure status information can be fed back to the upper-layer module of the system or the user interface. This status information may include a failure reason code, such as "timeout and retransmission reached the limit". Simultaneously, the device can, according to a preset fault recovery strategy, select to proceed to the next stage of the communication task, or trigger a diagnostic process for the communication link, such as initiating a self-test of physical layer parameters, checking whether the baud rate, data bits, and stop bits configuration of the UART interface match the peer, or detecting the connection status of the communication line, to locate the source of the fault.
[0073] In this embodiment, by introducing a retransmission mechanism and a timer update strategy into the information communication method, abnormal situations such as verification failure and timeout failure to respond that may occur during data transmission can be effectively addressed, thereby improving the robustness and fault tolerance of data communication. When verification failure or timeout occurs, the device does not simply terminate communication, but rather takes remedial measures such as retransmitting data packets and updating the timer time to ensure that the data can be correctly received within a reasonable time.
[0074] In one embodiment, the method further includes:
[0075] If a second response signal is received, the system switches to a second operating mode; wherein the second response signal indicates that all data packets have been received and that each first response signal in the data packets has been verified to a first agreed value.
[0076] In one embodiment, the second response signal can be generated after the application layer service is completed and confirmed. For example, after a complete application layer protocol interaction is successful, the CCP AO or CommsProc AO (Communication Processing Activity Object) generates and sends an EVT_SESSION_COMPLETE event (session completion event), which carries a "charging allowed" flag. Alternatively, it can be obtained by aggregating underlying responses. For example, after sending a multi-frame request (such as segmented upgrade data), the CCP AO accumulates and verifies the "first response signals" of all fragments. When all fragments are successfully verified and the sequence is continuous, a "second response signal" is generated. In some embodiments, the second response signal can also be represented as the first response signal carried in the last frame of data when all first response signals are of a first agreed value, i.e., the final confirmation identifier of successful multi-frame interaction.
[0077] In some embodiments, the second operating mode may include a direct charging mode, a high-power mode, a safety mode, etc.
[0078] In one exemplary embodiment, upon receiving a second response signal, preparatory operations before mode switching can be performed, such as releasing the current communication link's resource occupation, saving key parameters of the current session (e.g., the amount of data transmitted, interaction status codes, etc.), and sending a mode switching notification to the system power management module. Taking direct charging mode as an example, after switching, the device can control the relay of the charging interface to engage, adjust the output voltage to a preset charging voltage range (e.g., 5V / 9V / 12V), and simultaneously start a charging status monitoring timer to collect data such as charging current and battery temperature in real time, feeding it back to the main control module via the internal bus. In high-power mode, the cooling fan can also be triggered to start, and the transmission power of the communication module can be adjusted to the maximum threshold to meet the high-bandwidth data transmission requirements. Furthermore, during the switching process of the second operating mode, synchronization with the status of the peer device can be ensured, for example, by sending a mode switching confirmation frame to the peer. Only after receiving a mode-ready response from the peer can the final mode switching action be completed, avoiding data transmission errors or device failures caused by state asynchrony.
[0079] In one exemplary embodiment, after receiving the second response signal, the integrity of the current communication session can be verified. For example, the total number of data packets and the total data length can be checked to see if they match preset values, or the data integrity verification values before and after transmission can be compared using message digest algorithms (such as MD5 or SHA-1). If the verification passes, temporary data related to the current task in the session buffer can be cleared to release memory resources. If the verification fails, an exception log can be recorded, including timestamp, session ID (address), and specific fields of the verification failure. Based on preset rules, it can be determined whether to trigger a new round of data integrity repair process, such as requesting the peer to retransmit the fragmented data that failed the verification. In addition, after switching to the second working mode, a mode maintenance heartbeat packet can be periodically sent to the peer to confirm the continuous synchronization of the working modes of both parties. If no heartbeat response is received for N consecutive times (such as 3 times), the mode rollback mechanism is automatically triggered, pausing the current working mode and switching to a safe standby state. At the same time, a "mode synchronization loss" alarm message is reported to the upper-layer module.
[0080] In this embodiment, by responding to the second response signal and switching to the second working mode, a smooth transition from the data transmission stage to the business application stage is achieved, which not only ensures the integrity and accuracy of data interaction, but also provides a stable state foundation for the efficient execution of subsequent business functions.
[0081] In one embodiment, the method further includes:
[0082] If the timer exceeds a second preset time after receiving the second response signal, the system switches to the second working mode; wherein, the second response signal indicates that the data packet has been fully received and that each first response signal in the data packet has been verified to a first agreed value.
[0083] The "second acknowledgment signal" can be a final confirmation signal used in reliable communication protocols to mark the successful completion of a complete transaction or session. In one embodiment, its generation source can include: application layer business completion confirmation: for example, after the successful completion of a complete application layer interaction process such as device authentication, firmware version verification, or user configuration synchronization, the module responsible for the business logic generates and issues this signal. Low-level data aggregation confirmation: for example, in a segmented data transmission scenario, the protocol stack's middle-layer module aggregates and generates this final confirmation signal after accumulating and verifying the successful receipt of all data fragments. The "second preset time" can include a delay time threshold preset according to system stability, hardware characteristics, or security specifications. The second preset time is used to characterize the time after data transmission is completed, ensuring that the peer device has sufficient time to complete internal data processing, state synchronization, or resource preparation, avoiding interaction anomalies caused by the peer not being ready due to immediate mode switching. For example, in a charging scenario, after receiving and verifying all charging parameter configuration data packets, the system does not immediately switch to direct charging mode, but waits for the second preset time to ensure that the peer device has completed parameter parsing, security policy evaluation, and charging interface status detection. The value of the second preset time can be dynamically adjusted according to specific application scenarios. For example, a longer time can be set in low-power device communication to adapt to the device's sleep-wake cycle, while a shorter time can be set in industrial control scenarios with high real-time requirements to reduce mode switching delay. In the judgment logic of the timer exceeding the second preset time, the device will continuously monitor the timer status. If no abnormal interrupt signal is received during the timing period, it is determined that the switching condition is met, and then subsequent mode switching preparation operations are performed, such as releasing communication link resources, saving session parameters, and sending notifications to the power management module, so as to achieve an orderly transition from the data transmission state to the second working mode.
[0084] In one exemplary embodiment, after the timer exceeds a second preset time, a mode switching preparation frame can be sent to the peer device. This frame contains identification information of the target second operating mode (e.g., mode code "0x03" represents direct charging mode), the estimated switching duration, and a status synchronization request field. After receiving the preparation frame, the peer device needs to return a response frame containing its own readiness status within a preset response window (e.g., 100ms). If the "ready" flag in the response frame is "1" and the status code is "0x00", the device starts the formal mode switching process. If no response is received within the response window or the response status is abnormal, the timer can be reset and the preparation frame can be resent. The number of retries shall not exceed, for example, 3 times. If it still fails, an alarm is triggered and the device switches to safe mode. During the formal switchover phase, hardware configuration can be executed sequentially according to preset priorities. In addition, after the second working mode switchover is completed, a switchover log containing the switchover time, mode type, and peer device ID can be generated and sent to the system log module for storage via the internal CAN bus. At the same time, the mode switchover result is reported to the main control CPU in the form of an interrupt signal so that the upper-layer application can adjust the business logic parameters according to the new working mode.
[0085] In this embodiment, the implementation logic of the second working mode switching is further refined by introducing timer timeout judgment, mode switching preparation interaction and phased hardware configuration process, so as to ensure the security, reliability and traceability of the mode switching process.
[0086] In one embodiment, if retransmission of the data packet is performed and the timer is updated, the method further includes:
[0087] Calculate the number of times the data packet was retransmitted;
[0088] When the number of attempts reaches a preset threshold, a warning signal indicating communication failure is sent.
[0089] The warning signal may include an event or message generated to notify upper-layer services, record the fault, or trigger a recovery process after it is confirmed that communication cannot be restored.
[0090] In one exemplary embodiment, the warning signal may include settings based on system architecture and application requirements, such as sending an ASCII format alarm frame to a host computer via a UART interface. The frame structure may include a frame header, an alarm type field, a data packet identifier, retransmission count, and a checksum. An onboard LED indicator may be controlled to flash red at a preset frequency, and an internal buzzer may emit intermittent alert sounds. The warning signal processing logic includes: when the retransmission count reaches a preset threshold, the protocol processing module immediately stops the current data transmission task, releases the occupied DMA channel and cache resources, writes the fault status to non-volatile memory, and records the timestamp of the fault occurrence, the MAC address of the peer device, and a summary of the last retransmitted data packet content. Furthermore, a fault recovery mechanism may be activated, such as automatically switching to a backup communication link and sending an SNMP Trap message containing fault details (SNMP traps, specifically notification messages actively sent by the managed device to the network management system to report specific events or errors) to the network management module, so that the remote monitoring system can promptly alarm and trigger manual intervention. If no recovery command is received from the upper-layer module within the preset time window after the warning signal is sent, the device will automatically perform a link reset operation, including resetting the physical layer chip, clearing the protocol stack state machine, and reinitializing the timer parameters, in an attempt to restore basic communication capabilities.
[0091] In this embodiment, an early warning system for communication link anomalies is constructed through real-time monitoring of data packet retransmission counts and a preset threshold judgment mechanism. When the cumulative number of retransmissions reaches the preset threshold, the device immediately triggers the generation and transmission of a warning signal. This enables timely response to communication failures and avoids resource waste and communication congestion caused by continuous invalid retransmissions.
[0092] In one embodiment, the method further includes:
[0093] If a third response signal is received in the first working mode, or if electrical parameters are detected to meet preset conditions in the second working mode, the configuration is to terminate the first and second working modes; wherein the second working mode includes a charging mode, the first working mode includes a communication mode, and the third response signal is a third agreed value, which indicates that charging is successful in the charging mode.
[0094] In one embodiment, the method further includes:
[0095] If a third response signal is received in the first working mode, and if electrical parameters are detected to meet preset conditions in the second working mode, then the configuration is to terminate the first and second working modes; wherein the second working mode includes a charging mode, the first working mode includes a communication mode, and the third response signal is a third agreed value, which indicates that charging is successful in the charging mode.
[0096] The third response signal may include a specific response frame actively sent by the peer device at the normal completion of the charging process. This frame typically contains key information such as a charging completion status code, cumulative charge amount, charging duration, and the current SOC (State of Charge) percentage of the battery. A third agreed-upon value can be used to indicate that the charging process has reached a predetermined completion standard. The preset conditions may include successful charging, as well as charging failure.
[0097] In one exemplary embodiment, in the first operating mode (communication mode), when the device receives a third response signal sent by the peer device through the communication interface, the frame structure of the signal can be parsed and verified. For example, the frame format of the third response signal can be defined as: frame header, signal type field, third agreed value field, cumulative charging amount, charging time, battery SOC, and CRC32 checksum. Charging is considered successful when the frame header is correct, the checksum matches, and the third response signal is the third agreed value. Simultaneously, in the second operating mode (charging mode), the electrical parameters of the charging circuit, including charging voltage, charging current, and circuit temperature, can be continuously collected in real time through the analog-to-digital conversion module. Preset conditions can be set as follows: the charging current drops below 5% of the rated current and the battery SOC reaches above 98% within 5 consecutive seconds, or the charging voltage exceeds a preset overvoltage threshold, etc.
[0098] In one exemplary embodiment, in communication mode, if a third response signal is received from the peer device and the signal value is a third agreed-upon value indicating successful charging, termination can be triggered; in one embodiment, the third agreed-upon value can be set to 0x55, etc. In charging mode, if the system detects that the electrical parameters meet preset charging completion or abnormal conditions, termination can also be triggered. In another exemplary embodiment, a valid third response signal can be received in communication mode, and the electrical parameters can be detected to meet preset conditions in charging mode; after double confirmation, the current operating mode is terminated.
[0099] In this embodiment, a two-dimensional working mode termination triggering mechanism is constructed by combining the reception and judgment of the third response signal with real-time monitoring of electrical parameters. When a third response signal containing a third agreed value is received in communication mode, or when electrical parameters are detected to meet preset conditions in charging mode, the device will initiate the mode termination process. This achieves orderly termination of the first and second working modes, ensuring a complete closed loop in the charging process and the accuracy of equipment energy management.
[0100] In one embodiment, encapsulating the data includes:
[0101] The data is encapsulated based on the protocol layer protocol to obtain the data segments in the data packet;
[0102] The data is encapsulated based on the physical layer protocol to obtain the control segment of the data packet, and then combined with the data segment.
[0103] The protocol layer can select from TCP / IP, Modbus, or proprietary communication protocols depending on the application scenario. For example, when using the Modbus protocol, the data segment can include a function code, data address, data length, and specific data content, and a CRC16 checksum calculated according to the Modbus RTU format is appended to the end of the data segment. The physical layer protocol is responsible for converting the data segment encapsulated by the protocol layer into an electrical or optical signal format suitable for transmission through the physical medium. For example, in the RS485 physical layer, the control segment can include start bits, data bits, parity bits, and stop bits. The binary information of the data segment can be converted into differential signals using Manchester encoding, and the transmission and reception switching can be achieved by controlling the transmit enable pin and receive enable pin of the driver chip. During the data encapsulation process, the device's protocol processing unit performs integrity checks on the original data, removes invalid or erroneous data, and packages it according to the field order and data type specified by the protocol layer to generate data segments. The physical layer interface module configures the corresponding baud rate and data flow control method according to the characteristics of the current communication medium, combines the data segment and control segment into a complete data packet, and sends it out through the physical interface.
[0104] In one exemplary embodiment, when using the TCP / IP protocol for data encapsulation, the protocol layer can segment the data transmitted from the application layer, with each segment encapsulated into the data field of a TCP segment. A TCP segment may include fields such as source port, destination port, sequence number, acknowledgment number, data offset, reserved bits, control bits, window size, checksum, and urgent pointer. The TCP segment can be further encapsulated into an IP datagram, which may include information such as version number, header length, type of service, total length, identifier, flags, fragment offset, time to live, protocol type, header checksum, source IP address, and destination IP address. In an Ethernet environment, the physical layer can encapsulate the IP datagram into an Ethernet frame. The control segment may include a preamble, start-of-frame delimiter, destination MAC address, source MAC address, type / length field, and a CRC checksum field at the end of the frame. Data segments can be placed within the data field of the Ethernet frame and ultimately transmitted over the twisted-pair cable as differential signals via the physical layer's RJ45 interface.
[0105] In this embodiment, a layered encapsulation mechanism is used to achieve standardized data conversion from the application layer to the physical layer. The protocol layer is responsible for the logical organization and semantic definition of the data, while the physical layer ensures the reliable transmission of data on the transmission medium. This layered encapsulation method not only improves the standardization and compatibility of data transmission, but also provides an architectural foundation for flexible adaptation to different communication protocols, ensuring accurate and efficient data transmission in complex network environments.
[0106] In one embodiment, the method further includes:
[0107] If the timer exceeds the second preset time after receiving the second response signal, and a charging indicator is present, then the system switches to the second working mode.
[0108] The charging identifier may be generated by the system when it detects the access of an external charging device or receives an upper-level control command and stored in the device's register. The identifier may be represented by a 1-byte binary bit, for example, 0x04 indicates that there is a charging demand and 0x05 indicates that there is no charging demand.
[0109] In one exemplary embodiment, a timer is started after a data packet is sent. When a second acknowledgment signal is received and the timer has exceeded a second preset time, and the charging flag in the register is 0x04, a working mode switching process can be triggered. Specifically, this may include stopping the protocol stack tasks in the current communication mode, controlling a relay to disconnect the power supply to the communication module via a GPIO pin, initializing the charging management module, activating the power path management chip of the charging interface, and switching the device from communication mode to charging mode.
[0110] In this embodiment, a mode switching mechanism based on communication status and energy demand is constructed by combining the timing of receiving the second response signal, timer timeout judgment, and the presence of a charging indicator. When the conditions of "response timeout + presence of charging indicator" are met, the device can actively switch from communication mode to charging mode, which avoids energy waste caused by invalid waiting and ensures timely replenishment of power during communication intervals, thereby improving the device's battery life and operational continuity in mobile scenarios.
[0111] In one exemplary embodiment, the information communication method may be as follows: Figure 4 The specific implementation of the schematic diagram shown may include:
[0112] S300 responds to the interrupt trigger command, determines the data to be processed, and starts the timer.
[0113] S301, the host switches to the target first working mode.
[0114] S302, the host encapsulates the data to be processed into a data packet and sends the data packet to the slave.
[0115] S303: The host determines whether it has received an acknowledgment signal within the first preset time. If so, it proceeds to S307 or S311.
[0116] S404, the slave device receives data packets and performs verification.
[0117] S305, determine whether the verification was successful. If yes, proceed to S306; otherwise, proceed to S309.
[0118] S406, the slave device returns the first agreed value to the master device.
[0119] S307, if a first response signal is received within a first preset time and is of a first agreed value, the timer time is updated.
[0120] S308, the host maintains the current working mode and continues subsequent communication.
[0121] S309, the slave device returns the second agreed value to the master device.
[0122] S310, the host receives the second agreed value.
[0123] S311, the host records the number of times the current data packet has been retransmitted.
[0124] S312, determine whether the number of retransmissions has reached the preset threshold. If yes, proceed to S314; otherwise, proceed to S313.
[0125] S313, the master resends the current data packet to the slave.
[0126] S314, send a warning message.
[0127] S315: Once the slave device confirms that all frames have been successfully verified, it sends a second response signal to the master device.
[0128] S316, the host receives the second response signal.
[0129] S317, the host determines whether a charging indicator is present.
[0130] S318, if yes, then determine whether the timer has exceeded the second preset time; if yes, then proceed to S319.
[0131] S319, the host switches to the second working mode.
[0132] In one exemplary embodiment, the information communication method can be as follows: Figure 4The framework shown can be implemented as follows: an activity object framework, an application layer, a device communication service layer, and a device abstraction layer. Specifically, the activity object framework can include the AO core runtime, event communication service, runtime health monitor, and basic tool library; the application layer can include communication processor activity objects; the device communication service layer can include CCP communication protocol activity objects and connection communication activity objects; the device abstraction layer can include converter activity objects and serial communication activity objects. Specifically, the activity object framework can include a horizontal infrastructure providing core services for all long-layer AOs; the application layer can include the system's highest-level business logic; the communication processor activity object can handle communication requests from the user interface or other business modules, manage a command queue to serialize requests, and call the lower-level device communication service layer; the device communication server can encapsulate complex communication protocols into an independent service; the CCP communication protocol activity object can implement the application layer protocol, define specific message formats, and manage request-response, timeout, and retransmission; the connection communication activity object can implement the transport / link layer protocol and is responsible for data frame encapsulation, decapsulation, and CRC verification. The device abstraction layer can select the underlying hardware driver operations as stateful AOs. The converter activity object can encapsulate and manage the operation of the power conversion chip. Its state machine manages the core working mode of the hardware (such as default, UART, direct charging) and converts hardware interrupts into AO events. The serial communication activity object can abstractly manage the transmit and receive operations of the physical serial port (UART).
[0133] In an exemplary embodiment of a timeout simulation, the information communication method can be configured as follows: Figure 5 The implementation of the schematic diagram shown may specifically include:
[0134] S1, host communication processes AO generation application requests.
[0135] S2, host CCP AO receives CCP data packets.
[0136] S3, the host cable protocol AO requests the host converter AO to enter UART mode.
[0137] S4, the host converter AO sets the host controller to UART mode.
[0138] S5, the host converter AO performs serial writing.
[0139] S6, the host UART hardware peer device sends response frames via UART.
[0140] S7, the time for the host cable protocol AO to complete UART reception.
[0141] S8, the host cable protocol AO serially reads the response frame.
[0142] S9, Host Cable Protocol AO Verification Response Wireframe, Extract CCP Load.
[0143] S10, Post-processing of the host CCP AO with the corresponding CCP load.
[0144] S11, host CCP AO processes CCP response.
[0145] S12, Host Communication Processing AO adapts and notifies the application layer of the corresponding data.
[0146] S13, host CCP AO timeout occurred.
[0147] S14, the host CCP AO retransmits the CCP data packet for retransmission.
[0148] S15, Host Cable Protocol AO retransmits Wire frames (transport layer data frames).
[0149] S16, host converter AO serial write, sends transmission frame to peer device again.
[0150] S17, Host communication processing AO notifies application layer that communication failed.
[0151] The verification response wireframe can include the Host Cable Protocol (AO) processing the UART response frame according to a preset wireframe after receiving a complete UART response frame. The wireframe can include multiple wireframe cells—frame header, address, control bits, frame tail, etc., which can check whether the wireframe cells are filled and meet expectations; filter out the data load area, thereby extracting the valid CCP load.
[0152] Specifically, the verification response wireframe can be used to perform structured parsing and validity filtering of the raw received data. When the host cable protocol (AO) receives a complete UART response frame, the response wireframe, according to a preset protocol format, performs boundary identification and field segmentation of the data, sequentially locating and extracting the frame header, address field, control field, data payload, and frame trailer. It also verifies data integrity to ensure that the extracted payload content has not been corrupted during transmission. The raw data is filtered, and only valid payloads that meet the format requirements and pass verification are submitted to the upper-layer CCP protocol layer for further processing, thereby shielding the implementation details of the physical layer and ensuring the accuracy and reliability of protocol interaction.
[0153] Specifically, S1-S2 may include the application layer sending a request to the protocol layer. After encapsulating the data packet, the protocol layer submits a transmission time to the physical link layer and starts its own timeout timer. S3-S5 may include the physical link layer further encapsulating the data frame and requesting the converter layer to enter UART mode, sending the data out through the hardware layer. S6-S12 may include the protocol layer canceling the timeout timer and notifying the application layer of the processing result after successfully receiving response data from the peer. S13-S16 may include the application layer executing retransmission logic if a timeout occurs while waiting, resubmitting the transmission event to the physical link layer until the maximum number of retransmissions is reached. S17 may include notifying the application layer of communication failure if all retransmissions fail.
[0154] In one exemplary embodiment, the information communication method can also be configured to... Figure 6 The implementation of the schematic diagram shown may specifically include:
[0155] S20, the peer device interface detected a power-on signal.
[0156] S21, the host converter AO processes the request and switches to UART mode.
[0157] S22, Host Converter AO configured with UART mode hardware.
[0158] S23, Host converter AO timed out when starting UART mode.
[0159] S24, UART timeout occurs for host converter AO.
[0160] S25, the host converter AO processing timed out, checked the direct charging intention, and switched to "Direct Charge" mode.
[0161] S26, the host converter AO configuration hardware is used to enter direct charging mode.
[0162] S27, the peer device interface provides VOUT for power supply.
[0163] S28, peer device interface manages charging path.
[0164] S29a, the host converter AO received a failure signal.
[0165] S30a, the host converter AO transitions to the "default" state.
[0166] S31a, the host converter AO configures the hardware to the default mode.
[0167] S29b, the host converter AO receives the completion signal.
[0168] S30b, the host converter AO transitions to the "default" state.
[0169] S31b, the host converter AO configures the hardware to the default mode.
[0170] Specifically, in S20, the host converter AO starts in the "default" state; this action can be captured by a hardware interrupt when the peer device is inserted via the shared Pogo Pin. In S21, the host converter AO responds to the event derived from the hardware interrupt, performing a state transition in its state machine, switching from the default state to the UART state. In S22-S23, during the entry action into the UART state, the host converter AO sends a command to the hardware to configure the physical function of the Pogo Pin to UART mode and starts a UART mode timeout timer. In UART mode, the physical link layer performs data transmission and reception. Unlike the passive bus monitoring technology of the prior art, this invention adopts an active heartbeat mechanism: whenever the physical link layer successfully receives and verifies (CRC correct) a frame of data, the physical link layer actively sends a "heartbeat" event to the host converter AO after each successful data reception. The host converter AO only refreshes (resets) its timeout timer upon receiving this valid heartbeat. This ensures that the communication mode is maintained only when valid protocol interactions are in progress. S24-S25: When communication ends and no more valid data is received, the heartbeat event stops, and the timer of the host converter AO times out. The host converter AO responds to the timeout event by checking the internal Direct Charge flag. If true, the state machine automatically transitions to the "Direct Charge" state. S26-S28: In the entry action to the "Direct Charge" state, the host converter AO atomically configures the hardware, switching the Pogo Pin's function from UART mode to direct charging mode and outputting charging power. S29a-S31b: When the host converter AO receives an external event indicating charging failure or charging completion, its state machine transitions back to the "Default" state and sends a command to the hardware to restore the Pogo Pin to a safe state and stop charging.
[0171] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0172] Based on the same inventive concept, this application also provides a charging device for implementing the information communication method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more charging device embodiments provided below can be found in the limitations of the information communication method described above, and will not be repeated here.
[0173] In one embodiment, such as Figure 7 As shown, a charging device 700 is provided, including: a processor 701, a timer 703, and an execution module 705, wherein:
[0174] The processor is configured to respond to an interrupt trigger command, determine the data to be processed, and encapsulate the data to be processed into a data packet; send a start command to a timer; send a command to the execution module to switch to the target first working mode; and if a first response signal is received within a first preset time, and the first response signal is a first agreed value, send a reset command to the timer; wherein, the first agreed value indicates that at least one frame in the data packet has been successfully verified.
[0175] A timer, connected to the processor, is used to receive start commands and reset commands sent by the processor, and to perform start and reset operations;
[0176] An execution module, connected to the processor, is configured to receive a command from the processor to switch to the target first working mode, switch to the target first working mode, receive a first response signal, and transmit the first response signal to the processor.
[0177] In one embodiment, the processor is further configured to: if a first response signal is not received within a first preset time, or if the first response signal received within the first preset time is a second agreed value, then execute one of the following strategies: retransmit the data packet; or, retransmit the data packet and send a reset command to the timer to update the timer's time; wherein the second agreed value indicates that at least one frame in the data packet has failed verification.
[0178] In one embodiment, the processor is further configured to: if a second response signal is received, send a command to the execution module to switch to a second operating mode; wherein the second response signal indicates that the data packet has been fully received and that each first response signal in the data packet is verified to a first agreed value.
[0179] In one embodiment, the processor is further configured to: if the timer exceeds a second preset time after receiving the second response signal, send a command to the execution module to switch to a second working mode; wherein the second response signal indicates that the data packet has been fully received and each first response signal in the data packet has been verified to a first agreed value.
[0180] In one embodiment, the processor is further configured to: calculate the number of times the data packet is retransmitted; and when the number of retransmissions reaches a preset threshold, send a warning signal indicating communication failure.
[0181] In one embodiment, the processor is further configured to: receive a third response signal in a first operating mode, and / or detect that electrical parameters meet preset conditions in a second operating mode, then control the termination of the first and second operating modes; wherein the second operating mode includes a charging mode, the first operating mode includes a communication mode, the third response signal is a third agreed value, and the third agreed value indicates successful charging in the charging mode.
[0182] In one embodiment, the processor is further configured to: encapsulate the data based on a protocol layer protocol to obtain a data segment in the data packet; encapsulate the data based on a physical layer protocol to obtain a control segment of the data packet, and combine it with the data segment.
[0183] In one embodiment, the processor is further configured to: if the timer exceeds a second preset time after receiving the second response signal and a charging indicator is present, send a command to the execution module to switch to the second working mode.
[0184] Each module in the aforementioned charging device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.
[0185] Based on the same inventive concept, this application also provides an information communication system for implementing the information communication method described above. The solution provided by this system is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more information communication system embodiments provided below can be found in the limitations of the information communication method described above, and will not be repeated here.
[0186] In one embodiment, an information communication system is provided, comprising: a host computer and a slave computer, wherein:
[0187] The host computer is used to respond to interrupt trigger commands, determine the data to be processed, and start a timer; send a mode switching command to the slave device to switch the slave device to a target first working mode; when the slave device is in the first working mode, send a data packet formed by the encapsulated data to the slave device; if a first response signal is received from the slave device within a first preset time, and the first response signal is a first agreed value, then the timer time is updated, where the first agreed value indicates that at least one frame in the data packet has been successfully verified.
[0188] The slave device is used to perform the working mode conversion of the slave device according to the mode switching instruction.
[0189] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 8As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements an information communication method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.
[0190] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0191] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0192] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.
[0193] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0194] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. An information communication method, characterized in that, The method includes: Respond to the interrupt trigger command, determine the data to be processed, and start the timer; Switch to the target first working mode, wherein the data packet formed by the encapsulated data is used to send in the first working mode; If a first response signal is received within a first preset time, and the first response signal is a first agreed value, then the timer is updated, whereby the first agreed value indicates that at least one frame in the data packet has been successfully verified.
2. The information communication method according to claim 1, characterized in that, The method further includes: If no first response signal is received within a first preset time, or if the first response signal received within the first preset time is a second agreed value, then one of the following strategies will be executed, wherein the second agreed value indicates that at least one frame in the data packet has failed verification: Retransmit the data packet; Retransmit the data packet and update the timer.
3. The information communication method according to claim 1, characterized in that, The method further includes: If a second response signal is received, the system switches to a second operating mode; wherein the second response signal indicates that all data packets have been received and that each first response signal in the data packets has been verified to a first agreed value.
4. The information communication method according to claim 3, characterized in that, The method further includes: If the timer exceeds a second preset time after receiving the second response signal, the system switches to the second working mode; wherein, the second response signal indicates that the data packet has been fully received and that each first response signal in the data packet has been verified to a first agreed value.
5. The information communication method according to claim 2, characterized in that, If the data packet is retransmitted and the timer is updated, the process further includes: Calculate the number of times the data packet was retransmitted; When the number of attempts reaches a preset threshold, a warning signal indicating communication failure is sent.
6. The information communication method according to claim 1, characterized in that, The method further includes: If a third response signal is received in the first working mode, and / or if electrical parameters are detected to meet preset conditions in the second working mode, the configuration is to terminate the first and second working modes; wherein the second working mode includes a charging mode, the first working mode includes a communication mode, and the third response signal is a third agreed value, which indicates that charging is successful in the charging mode.
7. The information communication method according to claim 1, characterized in that, Encapsulating the data includes: The data is encapsulated based on the protocol layer protocol to obtain the data segments in the data packet; The data is encapsulated based on the physical layer protocol to obtain the control segment of the data packet, and then combined with the data segment.
8. The information communication method according to claim 4, characterized in that, The method further includes: If the timer exceeds the second preset time after receiving the second response signal, and a charging indicator is present, then the system switches to the second working mode.
9. An information communication system, characterized in that, The system includes: The host computer is used to respond to interrupt trigger commands, determine the data to be processed, and start a timer; send a mode switching command to the slave device to switch the slave device to a target first working mode; when the slave device is in the first working mode, send a data packet formed by the encapsulated data to the slave device; if a first response signal is received from the slave device within a first preset time, and the first response signal is a first agreed value, then the timer time is updated, where the first agreed value indicates that at least one frame in the data packet has been successfully verified. The slave device is used to perform the working mode conversion of the slave device according to the mode switching instruction.
10. A charging device, characterized in that, The device includes: The processor is configured to respond to an interrupt trigger command, determine the data to be processed, and encapsulate the data to be processed into a data packet; send a start command to a timer; send a command to the execution module to switch to the target first working mode; and if a first response signal is received within a first preset time, and the first response signal is a first agreed value, send a reset command to the timer; wherein, the first agreed value indicates that at least one frame in the data packet has been successfully verified. A timer, connected to the processor, is used to receive start commands and reset commands sent by the processor, and to perform start and reset operations; An execution module, connected to the processor, is configured to receive a command from the processor to switch to the target first working mode, switch to the target first working mode, receive a first response signal, and transmit the first response signal to the processor.