A method and device for debugging a multi-core CPU serial port of a vehicle-mounted instrument

Abstract

The application provides a kind of vehicle-mounted instrument multi-core CPU serial port debugging method and device, the method comprises: setting the shared memory address space of different CPU cores, and setting the mutual exclusion lock of different CPU core access;When the first core obtains the shared memory access permission by taking lock, write debugging information to shared memory;When the serial port terminal corresponding to the second core starts debugging program, the second core accesses the debugging information in shared memory by regularly taking lock. Through the scheme, the production cost of product can be reduced, and hardware resources can be effectively saved.

Description

Technical Field

[0001] This invention belongs to the field of automotive instrumentation, and particularly relates to a method and device for debugging a multi-core CPU serial port in an automotive instrumentation system. Background Technology

[0002] With the advancement of technology, SOC chips in automotive electronic products are gradually becoming more multi-core. However, the automotive electronics industry has high cost requirements, and there may be a shortage of interfaces during the development process, which makes product development and debugging very inconvenient.

[0003] Currently, when debugging multi-core chips, each chip core uses an independent serial port for debugging, which undoubtedly increases the hardware cost of debugging. Moreover, in mass-produced products, the debugging function is turned off, which to some extent wastes hardware resources. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method and apparatus for debugging a multi-core CPU serial port in a vehicle instrument, which solves the problems of high cost and easy waste of hardware resources in existing serial port debugging.

[0005] In a first aspect of the present invention, a method for debugging a multi-core CPU serial port of an in-vehicle instrument panel is provided, comprising:

[0006] Configure a shared memory address space for different CPU cores and set a mutex lock for access by different CPU cores;

[0007] Once the first core acquires access to the shared memory by unlocking the lock, it writes debug information to the shared memory.

[0008] When the serial terminal corresponding to the second core starts the debugging program, the second core accesses the debugging information in the shared memory by periodically acquiring the lock.

[0009] In a second aspect of the present invention, a multi-core CPU serial port debugging device for vehicle instrument clusters is provided, comprising:

[0010] Shared memory is used to allow access from different CPU cores and to set mutexes for access from different CPU cores.

[0011] The first core is used to write debug information to the shared memory after obtaining access to the shared memory through lock acquisition;

[0012] The second core is used to access debugging information in shared memory by periodically acquiring locks when the serial terminal starts the debugging program.

[0013] In a third aspect of the present invention, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the steps of the method as described in the first aspect of the present invention.

[0014] In a fourth aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method provided in the first aspect of the present invention.

[0015] In this embodiment of the invention, by allocating shared memory space for multiple CPU cores and setting mutex locks for different cores to access the shared memory, the first core acquires access to the shared memory by acquiring the lock and writes debugging information to the shared memory. The serial port terminal corresponding to the second core starts the debugging program, and the second core accesses the debugging information in the shared memory by periodically acquiring the lock. This reduces the cost of multi-core serial port debugging and product manufacturing, avoids waste of hardware resources, and facilitates product support for developers. Attached Figure Description

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

[0017] Figure 1 A flowchart illustrating a method for debugging a multi-core CPU serial port in a vehicle instrument, provided in an embodiment of the present invention;

[0018] Figure 2 This is another flowchart illustrating a method for debugging a multi-core CPU serial port in an in-vehicle instrument, as provided in an embodiment of the present invention.

[0019] Figure 3 A schematic diagram of the logical structure for multi-core CPU serial port debugging of vehicle instrument provided in an embodiment of the present invention;

[0020] Figure 4 A schematic diagram of the structure of a multi-core CPU serial port debugging device for vehicle instrument provided in an embodiment of the present invention;

[0021] Figure 5 This is a schematic diagram of the structure of an electronic device provided as an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0023] It should be understood that the terms "comprising" and other similar expressions in the specification, claims, and accompanying drawings of this invention are intended to cover a non-exclusive inclusion, such as a process, method, system, or apparatus that includes a series of steps or units and is not limited to the listed steps or units. Furthermore, "first" and "second" are used to distinguish different objects and are not intended to describe a specific order.

[0024] Please see Figure 1 The present invention provides a flowchart illustrating a method for debugging a multi-core CPU serial port in a vehicle instrument cluster, comprising:

[0025] S101. Set up a shared memory address space for different CPU cores and set up a mutex lock for access by different CPU cores.

[0026] A typical CPU integrates multiple cores for processing multi-threaded tasks. When debugging multi-core chips in a vehicle using a serial port, to facilitate the simultaneous application of a single serial port to multiple cores, shared memory can be used to transmit debugging information between different cores.

[0027] The shared memory refers to the memory in a computer that can be accessed by different processor cores, enabling data transfer between different processes. The address space refers to the shared memory space used by different CPU cores for serial port debugging. After allocating the shared memory address space, a mutex lock can be created to prevent different threads from accessing the same object simultaneously.

[0028] Specifically, the first core is configured to have write-only access to the shared memory, while the second core is configured to have read-only access to the shared memory.

[0029] The first and second cores are only used to distinguish different cores, not to limit the number of CPU cores. Core types can be divided into write-only and read-only based on the processing tasks of the cores. When debugging information is being written, read-only threads cannot access it, and vice versa.

[0030] S102. After the first core acquires access to the shared memory by unlocking the lock, it writes debug information to the shared memory.

[0031] The first core acquires access to shared memory by acquiring a lock. Once the lock is acquired, serial port debugging information is written to the shared memory.

[0032] If the first core fails to acquire shared memory access, debug information writing is not allowed. In this case, it waits for the lock acquisition cycle to re-acquire access. Optionally, if the mutex lock is held for more than a preset duration, the lock is automatically released.

[0033] S103. When the serial terminal corresponding to the second core starts the debugging program, the second core accesses the debugging information in the shared memory by periodically unlocking the lock.

[0034] The serial port terminal is a terminal connected to a serial port. After the debugging program of the serial port terminal is started, the CPU core reads the debugging information in the shared memory by unlocking.

[0035] Optionally, the mutex lock status can be checked periodically, and the lock can be automatically released if it has been held for more than a preset time. The mutex lock only allows a single thread to access shared data; if a thread holds the lock for an extended period, a deadlock may occur, requiring automatic lock release.

[0036] The second core reads debugging information from shared memory and outputs it to the terminal via a serial port. This serial port, or serial interface, allows connection to external terminal devices.

[0037] Furthermore, the debug information is read and backed up to a log file, and the debug information printing function is enabled to display the debug information in real time through the terminal.

[0038] In this embodiment, a single serial port is used to implement multi-core serial port debugging functionality based on shared memory. Compared with previous methods, this effectively saves hardware resources and reduces product manufacturing costs.

[0039] In one embodiment, such as Figure 2 As shown, this embodiment uses two CPU cores, CR7 and A53. Address spaces are planned in shared memory and allocated to both CPU cores. Specifically, CR7 is configured for write-only access, and A53 for read-only access.

[0040] When CR7 successfully acquires the lock, it writes debug log information to the shared memory. After writing is complete, it releases the lock.

[0041] If CR7 fails to acquire the lock, it periodically checks the mutex lock's occupancy status. If the mutex lock is occupied for an extended period, it automatically releases the lock. CR7 monitors the lock to prevent deadlocks.

[0042] Correspondingly, when A53 successfully acquires the lock, it reads the debug log information written by CR7 from the shared memory. The read data is backed up to the log file, the printing function is enabled, and the debug information is displayed in real-time on the serial terminal before the lock is released.

[0043] Among them, such as Figure 3 As shown, the debugging information read by the A53 serial port can be output to the display terminal via the serial port.

[0044] If A53 fails to acquire the lock, the mutex lock occupancy status is checked periodically. If it has been occupied for a long time, the lock is automatically released.

[0045] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0046] Figure 4 This invention provides a schematic diagram of a multi-core CPU serial port debugging device for vehicle-mounted instruments, comprising:

[0047] Shared memory 410 is used to accept access from different CPU cores and set mutexes for access from different CPU cores;

[0048] Specifically, the first core is configured to have write-only access to the shared memory, while the second core is configured to have read-only access to the shared memory.

[0049] The first core 420 is used to write debug information to the shared memory after acquiring access to the shared memory through lock acquisition;

[0050] The second core, 430, is used to access debugging information in shared memory periodically by periodically acquiring locks when the serial terminal starts the debugging program.

[0051] Optionally, the mutex lock status can be checked periodically, and the lock can be automatically released if the mutex lock has been occupied for a preset time.

[0052] The second core reads debugging information from shared memory and outputs it to the terminal via serial port.

[0053] Furthermore, the debug information is read and backed up to a log file, and the debug information printing function is enabled to display the debug information in real time through the terminal.

[0054] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and modules can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0055] Figure 5This is a schematic diagram of an electronic device according to an embodiment of the present invention. The electronic device is used for serial port debugging of a multi-core CPU in an automotive instrument cluster. Figure 5 As shown, the electronic device 5 of this embodiment includes: a memory 510, a processor 520, and a system bus 530. The memory 510 includes an executable program 5101 stored thereon. As those skilled in the art will understand, Figure 5 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0056] The following is combined Figure 5 A detailed introduction to each component of the electronic device:

[0057] The memory 510 can be used to store software programs and modules. The processor 520 executes various functional applications and data processing of the electronic device by running the software programs and modules stored in the memory 510. The memory 510 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created according to the use of the electronic device (such as cached data). In addition, the memory 510 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0058] The memory 510 contains an executable program 5101, which can be divided into one or more modules / units. The one or more modules / units are stored in the memory 510 and executed by the processor 520 to perform multi-core CPU serial port debugging of the vehicle instrument. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions. The instruction segments are used to describe the execution process of the computer program 5101 in the electronic device 5.

[0059] The processor 520 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 510, and by calling data stored in the memory 510, it performs various functions and processes data, thereby controlling the overall state of the electronic device. The processor 520 includes multiple cores (at least a first core and a second core), with corresponding executable programs executed on the first core and the second core, respectively.

[0060] The system bus 530 is used to connect various functional components inside the computer, transmitting data, address, and control information. Its type can be, for example, a PC I bus, an ISA bus, or a VESA bus. Instructions from the processor 520 are transmitted to the memory 510 via the bus, and the memory 510 sends data back to the processor 520. The system bus 530 is responsible for data and instruction exchange between the processor 520 and the memory 510. Of course, the system bus 530 can also connect to other devices, such as network interfaces and display devices.

[0061] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0062] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0063] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for debugging a multi-core CPU serial port in a vehicle instrument panel, characterized in that, include: Configure a shared memory address space for different CPU cores and set a mutex lock for access by different CPU cores; Once the first core acquires access to the shared memory by unlocking the lock, it writes debug information to the shared memory. When the serial terminal corresponding to the second core starts the debugging program, the second core accesses the debugging information in the shared memory by periodically unlocking the lock. The second core's access to debug information in shared memory through periodic lock acquisition also includes: the second core reading debug information from shared memory and outputting it to the terminal via serial port; The second core reads debug information from shared memory and outputs it to the terminal via serial port, including: reading debug information, backing it up to a log file, enabling debug information printing, and displaying debug information in real time through the terminal.

2. The method according to claim 1, characterized in that, The mutex lock configured for different CPU cores to access the shared memory further includes: setting the first core to have write-only access to the shared memory and setting the second core to have read-only access to the shared memory.

3. The method according to claim 1, characterized in that, The second core accesses debugging information in shared memory by periodically acquiring locks, including periodically checking the mutex lock status and automatically releasing the lock when the mutex lock is occupied for more than a preset time.

4. A multi-core CPU serial port debugging device for vehicle-mounted instruments, characterized in that, At least including: Shared memory is used to allow access from different CPU cores and to set mutexes for access from different CPU cores. The first core is used to write debug information to the shared memory after obtaining access to the shared memory through lock acquisition; The second core is used to access debugging information in shared memory by periodically acquiring locks when the serial terminal starts the debugging program. The second core's access to debug information in shared memory through periodic lock acquisition also includes: the second core reading debug information from shared memory and outputting it to the terminal via serial port; The second core reads debug information from shared memory and outputs it to the terminal via serial port, including: reading debug information, backing it up to a log file, enabling debug information printing, and displaying debug information in real time through the terminal.

5. The apparatus according to claim 4, characterized in that, The method of accessing debugging information in shared memory by periodically acquiring locks includes: periodically checking the mutex lock status, and automatically releasing the lock when the mutex lock is occupied for more than a preset time.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the multi-core CPU serial port debugging method for vehicle instrument as described in any one of claims 1 to 3.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed, it implements the steps of the multi-core CPU serial port debugging method for vehicle instrument as described in any one of claims 1 to 3.

Images