Communication method and system based on J-Link, electronic equipment and storage medium

Abstract

The invention provides a communication method and system based on J-Link, an electronic device and a storage medium, an upper computer assembles target data to obtain a target data frame, and the target data frame accords with a modbus-RTU protocol identification format and comprises a frame header, a mark field, a data field and a verification field; the target data frame is sent to a DCC data register of a lower computer through a J-Link debugger; a DCC state register value of the lower computer is read through a J-Link debugger at regular time; in response to the DCC state register value being a first preset value, reading a response data frame in the DCC data register through a J-Link debugger; and according to a modbus-RTU protocol, analyzing the response data frame to obtain target response data. Therefore, on an embedded device with a J-Link interface, an additional RS485 interface or a CAN interface or a USB interface does not need to be added, the communication function of the upper computer can be achieved through the user-defined communication protocol, and the hardware cost can be saved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the field of embedded technology, and in particular, to a J-Link-based communication method and system, an electronic device, and a storage medium. BACKGROUND

[0002] In embedded devices equipped with a J-Link interface, if a developer wants to implement a communication function with a host computer, these devices will usually be additionally equipped with an RS485 interface, a CAN interface, or a USB interface. However, this design choice, while providing convenience for communication, also brings additional hardware costs and complexity. SUMMARY

[0003] Embodiments of the present disclosure provide a J-Link-based communication method and system, an electronic device, and a storage medium.

[0004] In a first aspect, embodiments of the present disclosure provide a J-Link-based communication method, applied to a host computer, comprising:

[0005] Assembling target data to obtain a target data frame, the target data frame conforming to a format identified by a modbus-RTU protocol, including a frame header, a flag field, a data field, and a verification field;

[0006] Sending the target data frame to a DCC data register of a lower computer through a J-Link debugger;

[0007] Reading a DCC state register value of the lower computer through the J-Link debugger at a fixed time;

[0008] In response to the DCC state register value being a first preset value, reading a response data frame in the DCC data register through the J-Link debugger; and parsing the response data frame according to a modbus-RTU protocol to obtain target response data.

[0009] In some optional embodiments, before the target data is obtained, the method further comprises:

[0010] Loading a dynamic link library encapsulating a J-Link debugger communication interface from a cross-platform application development framework;

[0011] Calling a connection function in the dynamic link library to establish a communication connection with the lower computer;

[0012] Reading a DCC control register of the lower computer through the J-Link debugger to confirm that the DCC function of the lower computer is enabled.

[0013] In some optional embodiments, the sending, by the J-Link debugger, the target data frame to the DCC data register of the slave machine comprises:

[0014] reading the DCC status register value of the slave machine;

[0015] in response to the DCC status register value being a second preset value, writing, by the J-Link debugger, the target data frame into the DCC data register of the slave machine;

[0016] in response to the DCC status register value being a third preset value, after a preset buffering time, returning to execute the reading of the DCC status register value of the slave machine.

[0017] In some optional embodiments, after the reading, by the J-Link debugger, of the DCC status register value of the slave machine, the method further comprises:

[0018] in response to the DCC status register value being a fourth preset value, returning to execute the assembling of the target data to obtain the target data frame until the number of times of returning to execute the assembling of the target data to obtain the target data frame reaches a preset returning number threshold.

[0019] In a second aspect, embodiments of the present disclosure provide a J-Link-based communication method, which is applied to a slave machine and comprises:

[0020] reading the DCC data register at a timing to obtain a target data frame;

[0021] judging whether a check field of the target data frame is a preset check value;

[0022] if yes, based on a modbus-RTU protocol, parsing the target data frame to obtain parsed data, performing a reading or writing operation on the DCC data register according to the parsed data, and writing a first preset value into a DCC status register value;

[0023] if no, writing a fifth preset value into the DCC status register value.

[0024] In some optional embodiments, the performing of the reading or writing operation on the DCC data register according to the parsed data comprises:

[0025] assembling the parsed data into a response data frame according to the modbus-RTU protocol;

[0026] reading the DCC status register value;

[0027] In response to a buffer status bit in the DCC status register value indicating that the buffer is empty, the response data frame is written to a DCC data register.

[0028] In a third aspect, embodiments of the present disclosure provide a J-Link-based communication system, comprising:

[0029] The host computer, the slave computer and the J-Link debugger, the host computer is connected with the J-Link debugger through a USB cable, and the J-Link debugger is connected with the slave computer through a debugging interface;

[0030] The host computer is configured to assemble target data to obtain a target data frame, the target data frame conforms to a format identified by a modbus-RTU protocol, and includes a frame header, a flag field, a data field and a check field; the target data frame is sent to a DCC data register of the slave computer through the J-Link debugger; the DCC status register value of the slave computer is read through the J-Link debugger at a timing; in response to the DCC status register value being a first preset value, a response data frame in the DCC data register is read through the J-Link debugger; and the response data frame is parsed according to the modbus-RTU protocol to obtain target response data.

[0031] The slave computer is configured to read the DCC data register at a timing to obtain the target data frame; determine whether the check field of the target data frame is a preset check value; if yes, parse the target data frame based on the modbus-RTU protocol to obtain parsed data; perform a read or write operation on the DCC data register according to the parsed data; and write the first preset value to the DCC status register value; and if no, write a fifth preset value to the DCC status register value.

[0032] In a fourth aspect, embodiments of the present disclosure provide an electronic device, comprising: one or more processors; and a storage device having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation manner of the first aspect or the second aspect.

[0033] In a fifth aspect, embodiments of the present disclosure provide a computer-readable storage medium having a computer program stored thereon, when the computer program is executed by one or more processors, the one or more processors implement the method described in any implementation manner of the first aspect or the second aspect.

[0034] In order to reduce the cost of communication between an embedded device equipped with a J-Link interface and a host computer, embodiments of the present disclosure provide a J-Link-based communication method, system, electronic device, and storage medium. The host computer assembles target data to obtain a target data frame, which conforms to a format identified by a modbus-RTU protocol and includes a frame header, a flag field, a data field, and a check field. The target data frame is sent to a DCC data register of a lower computer through a J-Link debugger. The value of a DCC status register of the lower computer is read through the J-Link debugger at a predetermined time. In response to the DCC status register value being a first preset value, the response data frame in the DCC data register is read through the J-Link debugger. The response data frame is parsed according to the modbus-RTU protocol to obtain target response data.

[0035] Thus, on the embedded device with the J-Link interface, no additional RS485 interface, CAN interface, or USB interface needs to be added, and the host computer communication function can be realized through a self-defined communication protocol, thereby saving hardware costs. BRIEF DESCRIPTION OF DRAWINGS

[0036] Other features, objects, and advantages of the present disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are for purposes of illustrating the specific embodiments only and are not to be construed as limiting the present disclosure. In the drawings:

[0037] Figure 1 is a structural schematic diagram of one embodiment of a J-Link-based communication system according to the present disclosure;

[0038] Figure 2 is a flowchart of one embodiment of a J-Link-based communication method according to the present disclosure;

[0039] Figure 3 is a flowchart of one embodiment of a J-Link-based communication method according to the present disclosure;

[0040] Figure 4 is a structural schematic diagram of a computer system of an electronic device suitable for implementing embodiments of the present disclosure. DETAILED DESCRIPTION

[0041] The present disclosure will be further described in detail with reference to the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the related application and are not limiting of the application. In addition, it should be noted that, for the purpose of description, only the parts related to the application are shown in the drawings.

[0042] It should be noted that the embodiments in the present disclosure and the features in the embodiments can be combined with each other in the case of no conflict. The present disclosure will be described in detail below with reference to the drawings and in combination with the embodiments. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work belong to the scope of protection of the present application.

[0043] Reference is made to Figure 1 , Figure 1 The J-Link-based communication system provided by the embodiments of the present application comprises an upper computer, a lower computer and a J-Link debugger. The upper computer is connected with the J-Link debugger through a USB cable, and the J-Link debugger is connected with the lower computer through a debugging interface.

[0044] The upper computer is a computer or terminal device with data processing, assembling and protocol analysis capabilities, responsible for initiating a communication request and processing response data. Its core functions include: the upper computer is used to assemble target data to obtain a target data frame, the target data frame conforms to the format identified by the modbus-RTU protocol, and includes a frame header, a flag field, a data field and a check field; the target data frame is sent to a DCC data register of the lower computer through the J-Link debugger; the value of a DCC status register of the lower computer is read through the J-Link debugger at a regular time; in response to the DCC status register value being a first preset value, the response data frame in the DCC data register is read through the J-Link debugger; and the response data frame is parsed according to the modbus-RTU protocol to obtain target response data.

[0045] The J-Link debugger is a professional debugging tool supporting multiple processor architectures, which serves as a communication bridge between the upper computer and the lower computer to realize data transmission and state interaction between the two.

[0046] The lower computer is a device to be debugged or controlled (such as an embedded development board or a single-chip microcomputer), responsible for receiving and processing instructions from the upper computer. Its core functions include: the DCC data register is read at a regular time to obtain a target data frame; it is judged whether the check field of the target data frame is a preset check value; if yes, the target data frame is parsed based on the modbus-RTU protocol to obtain parsed data; a read or write operation is performed on the DCC data register according to the parsed data; the first preset value is written to the DCC status register value; and if no, the fifth preset value is written to the DCC status register value.

[0047] The system realizes cross-device communication between the host computer and the slave computer through the J-Link debugger, combines the standardized format of the modbus-RTU protocol, utilizes the high compatibility and stability of the J-Link, and guarantees the accuracy of data transmission by means of the verification mechanism of the modbus-RTU, meanwhile, realizes the separated management of data and state through the DCC register, and improves the orderliness and scalability of the communication.

[0048] Referring to Figure 2 , Figure 2 A method flowchart of the communication method based on the J-Link is applied to the host computer, and includes the following steps.

[0049] S201, target data is assembled to obtain a target data frame.

[0050] The target data is original instructions or information (such as reading sensor data, setting parameters, etc.) that the host computer needs to send to the slave computer. According to the target data to be transmitted, the host computer adds a frame header, a flag field, a data field and a verification field in turn according to the format requirements of the modbus-RTU protocol, and generates a target data frame that can be recognized by the slave computer. The target data frame conforms to the format recognized by the modbus-RTU protocol, wherein the frame header is used to identify the start of the data frame, the flag field is used to distinguish the data type or instruction type, the data field is the core instruction or information, and the verification field is used to verify the integrity of the data frame (usually a CRC check value).

[0051] S202, the target data frame is sent to the DCC data register of the slave computer through the J-Link debugger.

[0052] The DCC data register is a register in the slave computer for storing communication data, and is a “buffer area” for the host computer and the slave computer to exchange data. The DCC state register is a register in the slave computer for identifying the communication state, and its value (such as a second preset value, a third preset value) can reflect the ready state (such as “writable” “busy” etc.) of data transmission.

[0053] As a possible implementation, S201, the target data frame is sent to the DCC data register of the slave computer through the J-Link debugger, which can include the following steps.

[0054] S2011, the value of the DCC state register of the slave computer is read.

[0055] S2012, in response to the DCC state register value being the second preset value, the target data frame is written into the DCC data register of the slave computer through the J-Link debugger.

[0056] The second preset value is a state value of the DCC state register, indicating that the DCC data register is currently in an "idle writable" state.

[0057] S2013, in response to the DCC state register value being the third preset value, after a preset buffering time, returning to execute the reading of the DCC state register value of the lower machine.

[0058] The third preset value is a state value of the DCC state register, indicating that the DCC data register is currently in a "busy" state (the lower machine is processing previous data). The preset buffering time is a fixed time length for the upper machine to wait when the DCC state register is the third preset value (to avoid resource waste caused by frequent queries).

[0059] In summary, through S2011-S2013, the upper machine first reads the DCC state register value of the lower machine through the J-Link debugger; if the value is the second preset value, the target data frame is directly written into the DCC data register; if the value is the third preset value, the state register value is re-read after a preset buffering time until the writing condition is met.

[0060] S203, reading the DCC state register value of the lower machine through the J-Link debugger at a fixed time interval.

[0061] The upper machine queries the DCC state register at a fixed time interval (such as 10 ms) to grasp the processing progress of the lower machine in real time.

[0062] As a possible implementation, after S203, reading the DCC state register value of the lower machine through the J-Link debugger, it can further include:

[0063] S205, in response to the DCC state register value being the fourth preset value, returning to execute S201 until the number of times of returning to execute S201 reaches a preset return number threshold.

[0064] The fourth preset value is a state value of the DCC state register, indicating that the communication is abnormal (such as the lower machine not responding). The preset return number threshold is the maximum number of times that the upper machine allows to re-initiate data assembly (to avoid infinite loop). The upper machine periodically reads the DCC state register value; if the value is the fourth preset value, it means that the communication is abnormal, and the data assembly needs to be re-executed (S201), until the retry number reaches the preset return number threshold (if the threshold is exceeded, the current communication is terminated).

[0065] S204, in response to the DCC state register value being a first preset value, reading a response data frame in the DCC data register through the J-Link debugger; and parsing the response data frame according to a modbus-RTU protocol to obtain target response data.

[0066] The first preset value is a state value of the DCC state register, indicating that the lower machine has completed data processing and returned response data. The response data frame is feedback data frame generated by the lower machine according to the instruction of the upper machine, conforming to the modbus-RTU protocol. The target response data is valid feedback information (such as lower machine execution result, collected sensor data, etc.) obtained by the upper machine after parsing the response data frame.

[0067] When the DCC state register value is the first preset value, the upper machine reads the response data frame in the DCC data register through the J-Link debugger, and then extracts valid information according to the parsing rules of the modbus-RTU protocol to obtain the target response data.

[0068] In this way, on the embedded device with J-Link interface, without adding additional RS485 interface, or CAN interface, or USB interface, the upper machine communication function can be realized through self-defined communication protocol, which can save hardware cost. The upper machine realizes the process of "data frame standardization assembly-state check type sending-timing state query-protocol analysis", combined with the judgment mechanism of multiple state preset values, which not only guarantees the standardization of data transmission (based on modbus-RTU), but also realizes the precise control of communication rhythm through dynamic query of state register, reduces the probability of data conflict and transmission failure, and improves the fault tolerance of communication through preset retry mechanism.

[0069] As a possible implementation, before the first execution of S201, the method further comprises:

[0070] S2001, loading a dynamic link library encapsulating a J-Link debugger communication interface from a cross-platform application development framework.

[0071] The cross-platform application development framework refers to a software development environment (such as Qt, Electron, etc.) that supports running on multiple operating systems (such as Windows, Linux, macOS), which has the advantage of reducing repeated development work on different platforms and ensuring code reusability. Dynamic link library (DLL): a file containing code and data that can be shared by multiple programs, here specifically refers to a library file encapsulating the underlying communication interface (such as data transmission, state query, etc.) of the J-Link debugger. The dynamic link library encapsulates the underlying communication logic, and the developer does not need to deeply understand the hardware protocol details of J-Link, but only needs to call the functions in the library to realize communication, reducing the technical threshold.

[0072] S2002, call the connection function in the dynamic link library to establish a communication connection with the lower machine.

[0073] The function (such as JLink_Connect()) in the dynamic link library for establishing a communication link is predefined, which contains handshake, protocol negotiation, parameter configuration (such as baud rate, interface type) and other logic inside. Establishing a communication connection with the lower machine means that the upper machine ensures that the sending of subsequent target data frames and the receiving of response data can be stably carried out through the bidirectional data transmission channel established between the J-Link debugger and the lower machine.

[0074] S2003, read the DCC control register of the lower machine through the J-Link debugger to confirm that the DCC function of the lower machine is enabled.

[0075] The DCC control register is a register in the lower machine for controlling the DCC (Data Communication Controller) function switch, and its value is usually a binary flag (such as 0x01 indicating enabled, 0x00 indicating disabled), which is a key basis for judging whether the lower machine supports the current communication mode. By reading the DCC control register, it can be confirmed in advance whether the DCC function of the lower machine is enabled. If it is not enabled, the upper machine can terminate the subsequent process in time and report an error, avoiding data transmission failure due to the lower machine not supporting it.

[0076] In this way, S2001-S2003 realize universal development through cross-platform dynamic link library, establish reliable link through standardized connection function, verify the compatibility of the lower machine through the DCC control register, and finally ensure that the subsequent data transmission process (such as sending target data frames and response analysis) can be safely and efficiently executed, while providing technical support for the cost reduction goal of "communication without additional hardware interface".

[0077] Referring to Figure 3 , Figure 3 A method flowchart for a J-Link-based communication method applied to a lower machine, comprising:

[0078] S301, read the DCC data register at a fixed time interval to obtain a target data frame.

[0079] The lower machine queries the DCC data register at a fixed time interval (such as 5ms) to timely find the data sent by the upper machine. The lower machine periodically accesses the DCC data register, and when it detects that there is data in the register, it reads it as a target data frame.

[0080] S302, judge whether the check field of the target data frame is a preset check value.

[0081] The check field is a field in the target data frame for verifying data integrity (usually generated by the host computer). The preset check value is an expected check value calculated by the lower computer according to the frame header, flag field and data field of the target data frame (consistent with the check algorithm of the host computer, such as CRC16). The lower computer extracts the check field of the target data frame, and recalculates the check value according to the frame header, flag field and data field, and compares the two to determine whether the data frame has been tampered with or lost during transmission.

[0082] S303, if yes, based on the modbus-RTU protocol, the target data frame is parsed to obtain parsed data.

[0083] The effective instruction or information extracted by the lower computer from the target data frame (such as "read register address 0x0001", "write value 100", etc.). If the check field is consistent with the preset check value, the data frame is valid, and the lower computer extracts the core instruction from the frame header, flag field and data field according to the parsing rule of the modbus-RTU protocol to obtain parsed data.

[0084] S304, according to the parsed data, performing read or write operation on the DCC data register.

[0085] The response data frame is the feedback data generated by the lower computer according to the parsed data, which conforms to the modbus-RTU protocol (including frame header, flag field, response data and check field). The buffer status bit is a flag bit in the DCC status register for indicating whether the DCC data register is empty ("empty" means that new data can be written).

[0086] The lower computer generates the corresponding response data frame according to the instruction requirement of the parsed data; then reads the buffer status bit of the DCC status register, and if it indicates "empty", writes the response data frame into the DCC data register to complete the feedback preparation to the host computer.

[0087] As a possible implementation, S304, according to the parsed data, performing read or write operation on the DCC data register, comprises:

[0088] S3041, according to the modbus-RTU protocol, assembling the parsed data into a response data frame;

[0089] S3042, reading the DCC status register value;

[0090] S3043, in response to the buffer status bit in the DCC status register value indicating that the buffer is empty, writing the response data frame into the DCC data register.

[0091] S3044, writing a first preset value to the DCC status register value.

[0092] After the writing of the response data frame is completed, the lower machine updates the value of the DCC state register to a first preset value to inform the upper machine that "processing is completed and data is returned".

[0093] In summary, S3041-S3044 achieve instant feedback of data processing, improving communication efficiency.

[0094] S305, if not, write a fifth preset value to the DCC state register value.

[0095] The fifth preset value is a state value of the DCC state register, indicating that the target data frame check fails (such as data corruption, tampering). If the check field is inconsistent with the preset check value, the data frame is invalid, and the lower machine updates the value of the DCC state register to the fifth preset value to inform the upper machine that "data transmission is abnormal".

[0096] In summary, the lower machine uses the process of "timed data detection-check field verification-protocol resolution-state feedback" to ensure data integrity through the check mechanism, and to achieve state synchronization with the upper machine through accurate updating of the state register. At the same time, the consistent understanding of the instruction is ensured based on the analysis logic of the modbus-RTU protocol, and the reliability of the data processing of the lower machine and the timeliness of the response are improved.

[0097] Reference will now be made to Figure 4 , which shows a structural schematic diagram of a computer system 400 suitable for implementing the electronic device of the present disclosure. Figure 4 The computer system 400 shown is only an example and should not impose any limitations on the functions and use range of the embodiments of the present disclosure.

[0098] As shown in Figure 4 , the computer system 400 can include a processing device (such as a central processor, a graphics processor, etc.) 401, which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 402 or programs loaded from a storage device 408 into a random access memory (RAM) 403. In the RAM 403, various programs and data required for the operation of the computer system 400 are also stored. The processing device 401, the ROM 402, and the RAM 403 are connected to each other through a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0099] Generally, the following devices can be connected to the I / O interface 405: input devices 406 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, and the like; output devices 407 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, and the like; storage devices 408 including, for example, a magnetic tape, a hard disk, and the like; and communication devices 409. The communication devices 409 can allow the computer system 400 to communicate with other devices wirelessly or through wires to exchange data. Although Figure 4 The computer system 400 is shown with various devices, but it is understood that not all of the devices shown are required to be implemented or present. More or fewer devices can alternatively be implemented or present.

[0100] In particular, the processes described above with reference to the flowcharts can be implemented as a computer software program according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for executing the methods illustrated by the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network through the communication devices 409, or installed from the storage devices 408, or installed from the ROM 402. When the computer program is executed by the processing devices 401, the above-mentioned functions defined in the methods of embodiments of the present disclosure are performed.

[0101] It should be noted that the computer-readable medium described above can be a computer-readable signal medium or a computer-readable storage medium or any combination thereof. The computer-readable storage medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or any suitable combination thereof. More specific examples of the computer-readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program used by or in connection with an instruction execution system, apparatus or device. In this disclosure, the computer-readable signal medium can include a data signal propagated in baseband or propagated as a carrier wave in a propagated data signal, in which the computer-readable program code is contained. Such a propagated data signal can take many forms, including but not limited to, an electromagnetic signal, an optical signal, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium that can send, propagate or transfer a program for use by or in connection with an instruction execution system, apparatus or device. The program code contained in the computer-readable medium can be transmitted using any suitable medium, including but not limited to, wire, cable, RF (radio frequency), or the like, or any suitable combination thereof.

[0102] The computer-readable medium described above can be contained in the electronic device described above; or can exist separately and not be assembled into the electronic device.

[0103] The computer-readable medium described above carries one or more programs, when the one or more programs are executed by the electronic device, the electronic device implements the embodiments shown in the above Figure 2 or Figure 3 The J-Link-based communication method shown in the embodiments and optional implementation modes thereof.

[0104] Computer program code for carrying out operations of the present disclosure can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0105] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flow diagrams or block diagrams can represent a module, a procedure, or a part of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or in the reverse order, depending on the functionality involved. It is also noted that each block of the block diagrams and / or flow diagrams and combinations of blocks in the block diagrams and / or flow diagrams can be implemented by special-purpose hardware-based systems that perform the specified functions or operations, or combinations of special-purpose hardware and computer instructions.

[0106] The units or modules described in the embodiments of the present disclosure can be implemented by software, or by hardware. In some cases, the name of the unit or module does not constitute a limitation on the unit itself.

[0107] The above description is merely illustrative of the exemplary embodiments of the present disclosure and the principles of the technology involved. It is understood that the disclosed scope of the present disclosure is not limited to the technical solutions formed by the specific combinations of the above technical features, and also covers other technical solutions formed by any combinations of the above technical features or equivalent features, without departing from the above disclosed concept. For example, the above technical features can be replaced with the technical features disclosed in the present disclosure (but not limited to) having similar functions to form technical solutions.

Claims

1. A communication method based on a J-Link debugger, applied to an upper computer, the method comprising: assembling target data to obtain a target data frame, the target data frame conforming to a format identified by a modbus-RTU protocol, including a frame header, a flag field, a data field, and a check field; sending, by the J-Link debugger, the target data frame to a DCC data register of a lower computer; reading, by the J-Link debugger, a DCC state register value of the lower computer at a timing; in response to the DCC state register value being a first preset value, reading, by the J-Link debugger, a response data frame in the DCC data register; and parsing the response data frame according to the modbus-RTU protocol to obtain target response data.

2. The method of claim 1, wherein, Before the assembling of the target data to obtain the target data frame, the method further comprises: loading a dynamic link library encapsulating a J-Link debugger communication interface from a cross-platform application development framework; calling a connection function in the dynamic link library to establish a communication connection with the lower computer; and reading, by the J-Link debugger, a DCC control register of the lower computer to confirm that a DCC function of the lower computer is enabled.

3. The method of claim 1, wherein, The sending, by the J-Link debugger, of the target data frame to the DCC data register of the lower computer comprises: reading the DCC state register value of the lower computer; in response to the DCC state register value being a second preset value, writing, by the J-Link debugger, the target data frame into the DCC data register of the lower computer; in response to the DCC state register value being a third preset value, returning to execute the reading of the DCC state register value of the lower computer after a preset buffering time.

4. The method of claim 1, wherein, After the reading, by the J-Link debugger, of the DCC state register value of the lower computer at the timing, the method further comprises: in response to the DCC state register value being a fourth preset value, returning to execute the assembling of the target data to obtain the target data frame until a number of times of returning to execute the assembling of the target data to obtain the target data frame reaches a preset returning number threshold. 5.A communication method based on a J-Link debugger, applied to a lower computer, the method comprising: reading a DCC data register at a timing to obtain a target data frame; determining whether a check field of the target data frame is a preset check value; if yes, parsing the target data frame based on a modbus-RTU protocol to obtain parsed data; performing a reading or writing operation on the DCC data register according to the parsed data; and writing a first preset value into a DCC state register value; if no, writing a fifth preset value into the DCC state register value.

6. The method of claim 5, wherein, The performing of the reading or writing operation on the DCC data register according to the parsed data comprises: assembling the parsed data into a response data frame according to the modbus-RTU protocol; reading a DCC state register value; in response to a buffer status bit in the DCC state register value indicating that a buffer is empty, writing the response data frame into the DCC data register.

7. A J-Link based communication system, characterized in that The system comprises: a host computer, a slave computer and a J-Link debugger, the host computer is connected with the J-Link debugger through a USB cable, and the J-Link debugger is connected with the slave computer through a debugging interface; The host computer is configured to assemble target data to obtain a target data frame, the target data frame conforms to a format identified by a modbus-RTU protocol, and comprises a frame header, a flag field, a data field and a check field; the target data frame is sent to a DCC data register of the slave computer through the J-Link debugger; the value of a DCC state register of the slave computer is read through the J-Link debugger at a timing; in response to the value of the DCC state register being a first preset value, response data frames in the DCC data register are read through the J-Link debugger; the response data frames are parsed according to the modbus-RTU protocol to obtain target response data. The slave computer is configured to read the DCC data register at a timing to obtain the target data frame; it is judged whether the check field of the target data frame is a preset check value; if yes, the target data frame is parsed based on the modbus-RTU protocol to obtain parsed data; the DCC data register is executed with a read or write operation according to the parsed data; the first preset value is written into the DCC state register; if no, the fifth preset value is written into the DCC state register.

8. An electronic device, comprising: The system comprises: one or more processors; a storage device having stored thereon one or more programs, which when executed by the one or more processors, cause the one or more processors to perform the method of any one of claims 1-4 or 5-6.

9. A computer-readable storage medium, characterized in that, A computer program is stored thereon, and the computer program is executed by one or more processors to implement the method of any one of claims 1-4 or 5-6.

Images