Screen fitting method, vehicle-mounted terminal and computer storage medium

Abstract

The application discloses a screen adaptation method, a vehicle-mounted terminal and a computer storage medium. The screen adaptation method comprises the following steps: when the vehicle-mounted terminal is started, the first screen parameter of the vehicle-mounted screen is read; if the first screen parameter does not match the second screen parameter corresponding to the currently loaded device tree, the device tree corresponding to the first screen parameter is reloaded. Through the above manner, the screen parameter of the screen can be automatically adapted, different screens of different suppliers can be dynamically compatible in the vehicle-mounted terminal, the compatibility and adaptability of the vehicle-mounted host are ensured, and the production stability of the vehicle-mounted terminal is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle-mounted equipment, and in particular to a screen adaptation method, a vehicle-mounted terminal and a computer storage medium. BACKGROUND

[0002] The vehicle-mounted terminal in the prior art will adapt the screen provided by a designated screen supplier in advance. The screen of different suppliers will have its own fixed parameters to ensure normal display. Figure 1 The prior art screen adaptation method is shown in the interaction diagram. As shown in Figure 1 Generally, when the vehicle-mounted terminal is started, the bootloader loads the screen parameters adapted in advance, writes the corresponding screen parameters into the device tree, and passes the device tree containing the screen parameters to the kernel. Then the kernel is started, and the startup of the vehicle-mounted terminal system and the startup of the application APP are performed. The kernel loads the corresponding device tree, sets the screen parameters according to the device tree, and the whole process of starting the vehicle-mounted terminal does not interact with the vehicle-mounted screen. However, due to the shortage of chips and the shortage of screens, multiple suppliers' screens appear, and the prior art cannot dynamically compatible with these screens. When the vehicle-mounted terminal is inserted into the corresponding supplier screen, it can display normally, and when it is inserted into the screen of other suppliers, it displays abnormally. SUMMARY

[0003] The purpose of the present application is to provide a screen adaptation method, a vehicle-mounted terminal and a computer storage medium, which can automatically adapt the screen parameters of the screen, dynamically compatible with the screens of different suppliers, improve the compatibility and adaptability of the vehicle-mounted host, and ensure the stability of the production capacity of the vehicle-mounted terminal.

[0004] To solve the above technical problems, the present application provides a screen adaptation method, comprising the following steps:

[0005] When the vehicle-mounted terminal is started, the first screen parameters of the vehicle-mounted screen are read;

[0006] If the first screen parameters do not match the second screen parameters corresponding to the currently loaded device tree, the device tree corresponding to the first screen parameters is reloaded.

[0007] The present application also provides a vehicle-mounted terminal, comprising:

[0008] At least one processor;

[0009] At least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, which, when executed by the at least one processor, causes the vehicle-mounted terminal to perform the screen adaptation method as described above.

[0010] The application further provides a computer storage medium, wherein computer program instructions are stored on the computer storage medium; and the computer program instructions are executed by a processor to implement the screen adaptation method.

[0011] The screen adaptation method, the vehicle-mounted terminal and the computer storage medium provided by the application, the screen adaptation method comprises the following steps: reading a first screen parameter of a vehicle-mounted screen before starting the vehicle-mounted terminal; and if the first screen parameter does not match a second screen parameter corresponding to a current device tree, then reloading a device tree corresponding to the first screen parameter. Through the above method, the screen parameter of the screen can be automatically adapted, the vehicle-mounted terminal can be dynamically compatible with screens of different suppliers, and the compatibility and adaptability of the vehicle-mounted host are improved.

[0012] The above description is only a summary of the technical solutions of the application. In order to enable the technical means of the application to be more clearly understood and implemented according to the contents of the specification, and in order to enable the above and other purposes, characteristics and advantages of the application to be more apparent and easy to understand, the following preferred embodiments are described in detail below, and the accompanying drawings are referred to. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1 It is an interaction diagram of the screen adaptation method in the prior art;

[0014] Figure 2 It is a flow diagram of the screen adaptation method according to an embodiment of the application;

[0015] Figure 3 It is an interaction diagram of the screen adaptation method according to an embodiment of the application;

[0016] Figure 4 It is a structural diagram of the vehicle-mounted terminal according to an embodiment of the application. DETAILED DESCRIPTION

[0017] The implementation of the application is described below by specific embodiments, and those skilled in the art can easily understand other advantages and effects of the application from the contents disclosed in the specification.

[0018] In the following description, reference is made to the accompanying drawings, which illustrate several embodiments of the application. It is understood that other embodiments can be used and that mechanical, structural, electrical, and operational changes can be made without departing from the spirit and scope of the application. The following detailed description is not intended to be limiting, and the scope of the embodiments of the application is defined only by the claims of the issued patent. The terminology used here is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0019] Although the terms first, second, etc. can be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another.

[0020] Also, as used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises", "comprising", "includes" and / or "including", when used herein, specify the presence of stated features, steps, operations, elements, components, items, and / or groups thereof, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, items, and / or groups thereof. As used herein, the terms "or" and "and / or" are to be interpreted as inclusive, i.e., as meaning one or any combination of the items listed. Thus, "A, B or C" or "A, B and / or C" means any of the following: A; B; C; A and B; A and C; B and C; A, B and C. Only when the combination of elements, functions, steps or actions is inherently mutually exclusive is an exception to this definition presented.

[0021] Figure 2 A flowchart of a screen adaptation method according to an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, a screen adaptation method according to an embodiment of the present application comprises the following steps. Figure 2

[0022] Step 201: When the vehicle terminal is started, read the first screen parameters of the vehicle screen.

[0023] Step 202: If the first screen parameters do not match the second screen parameters corresponding to the currently loaded device tree, reload the device tree corresponding to the first screen parameters.

[0024] ​It should be noted that in the screen adaptation method of this invention, if the first screen parameter corresponding to the vehicle screen does not match the second screen parameter corresponding to the currently loaded device tree, it indicates that the current vehicle screen does not match the screen parameters loaded in the vehicle terminal. In this case, the first screen parameter is stored and backed up, the corresponding device tree is found based on the backed-up first screen parameter, and then the vehicle terminal is restarted to reload the device tree that matches the first screen parameter. If the first screen parameter matches the second screen parameter corresponding to the current device tree, the vehicle terminal starts normally. The second screen parameter is a subset of the vehicle screen parameters corresponding to the pre-loaded device tree in the vehicle terminal. For example, two screen suppliers supply different vehicle screens: screen A and screen B. Both can be adapted to the same vehicle terminal. When the vehicle terminal starts, it defaults to loading the device tree corresponding to screen A, so that screen A can be displayed correctly when installed in the vehicle terminal. When screen A malfunctions and needs to be replaced with screen B, screen A installed in the vehicle terminal is unplugged. Then, screen B is plugged into the vehicle terminal. The vehicle terminal reads the first screen parameters corresponding to screen B. If it detects a mismatch between the second screen parameters corresponding to the device tree of the currently loaded screen A and the first screen parameters, it indicates that the vehicle screen has been replaced. Next, the first screen parameters corresponding to screen B are backed up. Based on the first screen parameters of screen B, the corresponding device tree of screen B is determined. Then, the vehicle terminal is restarted to load the device tree corresponding to screen B, ensuring that the parameters of the vehicle screen running in the vehicle terminal are consistent with those of screen B, and the vehicle terminal system can start normally. The above process achieves automatic adaptation of screen B without manual modification, dynamically adapting to different vehicle screens from different suppliers and automatically adapting the corresponding screen parameters.

[0025] In one embodiment, the following steps are included before the vehicle-mounted terminal is started:

[0026] Create multiple device trees, each corresponding to different vehicle screen parameters, including first screen parameters and second screen parameters.

[0027] It's important to note that a device tree describes various hardware information of a device in a tree-like node structure: CPU, GPIO, clock, interrupts, memory, etc., forming a text-like file. Typically, a .dts file describes the system device tree in text format. The Device Tree Compiler (dtc) then converts the .dts file into a binary devicetree blob (dtb) file. The .dtb file can be parsed by the Linux kernel. With a device tree, seamless support across different platforms can be achieved without modifying the Linux kernel; simply changing the corresponding .dts file is sufficient.

[0028] In this embodiment, the vehicle terminal pre-writes the screen parameters corresponding to vehicle screens from multiple suppliers into multiple device trees. For example, the device tree for screen A is DTS_A, and the device tree for screen B is DTS_B. When the vehicle terminal starts up, it loads device tree DTS_A by default. During startup, it communicates with the vehicle screen to determine if the current vehicle screen is screen A. If the response is screen A, it starts normally and displays the menu on the vehicle screen. If the response is screen B, it needs to reload device tree DTS_B.

[0029] In one embodiment, the first screen parameters include at least one of the following: supplier information of the vehicle screen, device information, MAC address, and serial number.

[0030] In this embodiment, the first screen parameter serves as a unique identifier for the current vehicle screen, distinguishing it from other vehicle screens. Specifically, one or more of the following can be selected as the first screen parameter: supplier information, device information, MAC address, and serial number, uniquely identifying the current vehicle screen. It should be understood that the second and third screen parameters mentioned in this invention correspond to the first screen parameter. Of course, in other embodiments, the complete parameters of the vehicle screen can also be used as the first screen parameter. Preferably, this embodiment selects only supplier information as the first screen parameter, which accurately distinguishes the type of vehicle screen, simplifies the amount of input and output data, and improves processing efficiency.

[0031] In one implementation, before reloading the device tree corresponding to the first screen parameters, the following steps are included:

[0032] Store the first screen parameters to non-volatile memory.

[0033] In this embodiment, non-volatile memory (NVM) refers to computer memory whose stored data will not disappear when the power is turned off. Using NVM to store the first screen parameters of the vehicle screen ensures that the data is not lost when the vehicle terminal restarts, guaranteeing the reliability of the read data. Non-volatile memory types, such as eMMC and NorFlash, are applicable to this application. Among them, eMMC (embedded Multi Media Card) is an embedded storage chip that encapsulates Flash memory and a control chip, offering simple interface, large storage capacity, fast transmission speed, and high integration.

[0034] In one implementation, reloading the device tree corresponding to the first screen parameters includes the following steps:

[0035] Restart the vehicle terminal;

[0036] Read the stored first screen parameters;

[0037] Load the device tree corresponding to the parameters of the first screen.

[0038] In one implementation, after reloading the device tree corresponding to the first screen parameters, the following steps are included:

[0039] When the vehicle terminal is restarted, the third screen parameters of the vehicle screen are read again.

[0040] Determine whether the parameters of the third screen are consistent with the parameters of the first screen;

[0041] If so, then start the vehicle terminal normally.

[0042] In this embodiment, if the second screen parameters corresponding to the current device tree are inconsistent with the first screen parameters, the vehicle terminal is restarted. During the restart process, the bootloader first performs an initialization process. The bootloader is a small program that runs before the operating system kernel. Through this small program, we can initialize hardware devices and establish a memory space mapping, thereby bringing the system's hardware and software environment to a suitable state so as to prepare the correct environment for the final call to the operating system kernel. The bootloader reads the first screen parameters stored in non-volatile memory and loads the corresponding device tree according to the first screen parameters. This device tree contains the vehicle screen parameters required for system operation.

[0043] Next, the bootloader starts the kernel. The kernel is the core of most operating systems. It consists of the parts of the operating system that manage memory, files, peripherals, and system resources. The operating system kernel typically runs processes and provides inter-process communication. The bootloader passes the loaded device tree to the kernel, which identifies the device tree and retrieves devices such as `platform_device`, `i2c_client`, and `spi_device` from the Linux kernel. The memory, IRQs, and other resources used by these devices are also passed to the kernel.

[0044] After the kernel boots the system, the application (APP) starts. The application communicates with the vehicle screen and retrieves the current screen parameters as the third screen parameters. The third screen parameters are compared with the first screen parameters read and backed up before the reboot. If they match, the vehicle terminal and screen can boot normally. If they don't match, it means the vehicle screen was replaced during the reboot process. Therefore, steps 201 and 202 need to be executed again until the screen parameters match those loaded by the vehicle terminal, ensuring the screen is usable. Comparing the third and first screen parameters again during the reboot effectively prevents device tree errors during reboot and avoids startup failures or display issues caused by screen replacement during the reboot process.

[0045] In one embodiment, when comparing the third screen parameters with the first screen parameters, the first screen parameters can be read from non-volatile memory by the kernel and then passed to the application (APP), or they can be parsed from the device tree by the kernel and then passed.

[0046] Figure 3 This is an interactive schematic diagram illustrating the screen adaptation method according to an embodiment of the present invention. Figure 3 As shown, assuming the default in-vehicle screen is screen A, and the current in-vehicle screen is screen B. When the in-vehicle terminal starts, the bootloader loads the default screen A parameters, which include vendor information. Then, the kernel starts, passing the device tree (DTS_A) containing the screen A parameters to the kernel. After loading DTS_A, the kernel starts the system and the application (APP) sequentially. The APP communicates with the in-vehicle LCD screen to obtain the vendor information of the current in-vehicle screen. If the vendor information obtained by the APP matches the vendor information obtained by the kernel, the startup proceeds normally.

[0047] If the supplier information obtained by the app is inconsistent with that obtained by the kernel, the app will perform a system reboot after writing the current in-vehicle screen's supplier information to the EMMC. During reboot, the bootloader reads the current in-vehicle screen's supplier information from the EMMC, loads the corresponding screen parameters, and passes the device tree DTS_B containing these screen parameters to the kernel. The kernel then restarts, reads the supplier information for screen B stored in the EMMC, and loads the device tree DTS_B based on the supplier information for screen B. The kernel then restarts the system and the app. The app communicates with the in-vehicle LCD screen to obtain the current in-vehicle screen's supplier information again. If the supplier information obtained by the app is consistent with that obtained by the kernel, the in-vehicle terminal starts normally and displays on screen B.

[0048] The screen adaptation method of this embodiment includes: before the vehicle terminal starts, reading the first screen parameters of the vehicle screen; if the first screen parameters do not match the second screen parameters corresponding to the current device tree, storing the first screen parameters; and reloading the device tree corresponding to the first screen parameters. Through the above method, the vehicle terminal of the present invention can automatically adapt the screen parameters of the screen, dynamically achieve compatibility with screens from different suppliers, and improve the user experience.

[0049] Second Embodiment

[0050] This invention also provides a vehicle-mounted terminal, comprising:

[0051] At least one processor;

[0052] At least one memory is coupled to at least one processor and stores instructions for execution by the at least one processor, which, when executed by the at least one processor, cause the vehicle terminal to perform the screen adaptation method as described above.

[0053] Figure 4 This is a schematic diagram of the structure of the vehicle-mounted terminal provided in an embodiment of the present invention. Figure 4 The vehicle-mounted terminal shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein. Figure 4As shown, this application also provides an in-vehicle terminal 600 including a processing unit 601, which can execute the methods of the embodiments of this disclosure according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to the embodiments of this disclosure.

[0054] RAM 603 stores various programs and data required for the operation of the vehicle terminal 600. The processor 601, ROM 602, and RAM 603 are interconnected via bus 604. The processor 601 executes various operations of the method flow according to embodiments of the present disclosure by executing programs stored in ROM 602 and / or RAM 603. It should be noted that the aforementioned programs may also be stored in one or more memories other than ROM 602 and RAM 603. The processor 601 may also execute various operations of the method flow according to embodiments of the present disclosure by executing programs stored in one or more memories.

[0055] According to embodiments of this disclosure, the vehicle terminal 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The vehicle terminal 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. Furthermore, drives, removable media, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., may also be connected to the input / output (I / O) interface 605 as needed, so that computer programs read from there may be installed into the storage section 608 as needed.

[0056] The method flow according to embodiments of this disclosure can be implemented as a computer software program. For example, embodiments of this disclosure include a computer program product. This includes a computer program carried on a computer-readable storage medium, the computer program containing program code for performing the methods shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from a removable medium. When the computer program is executed by processor 601, it performs the functions defined in the system of embodiments of this disclosure. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, and units described above can be implemented using computer program modules.

[0057] This application also provides a computer storage medium storing computer program instructions; when the computer program instructions are executed by a processor, they implement the screen adaptation method described in the above embodiments.

[0058] In practice, computer storage media are used in... Figure 4 The vehicle-mounted terminal shown.

[0059] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A screen adaptation method, characterized in that, Includes the following steps: When the vehicle terminal starts up, it reads the first screen parameters of the vehicle screen. If the first screen parameter does not match the second screen parameter corresponding to the currently loaded device tree, then reload the device tree corresponding to the first screen parameter. When the vehicle terminal starts up, it reads the first screen parameters of the vehicle screen, including: After the kernel starts the system, it launches the application (APP). The application communicates with the vehicle screen to obtain the supplier information of the current vehicle screen. The step of reloading the device tree corresponding to the first screen parameter if the first screen parameter does not match the second screen parameter corresponding to the currently loaded device tree includes: If the supplier information obtained by the APP is inconsistent with the supplier information obtained by the kernel, the APP will restart the system after writing the supplier information of the current vehicle screen into the EMMC. During reboot, the bootloader reads the supplier information of the current in-vehicle screen from the EMMC, loads the corresponding screen parameters, and passes the device tree DTS_B containing the screen parameters to the kernel. The kernel is restarted, and it reads the supplier information of the current in-vehicle screen stored in the EMMC, and loads the device tree DTS_B according to the supplier information; then the kernel restarts the system and application APP.

2. The screen adaptation method according to claim 1, characterized in that, Before the vehicle-mounted terminal is started, the following steps are also included: Multiple device trees are created, each corresponding to different vehicle screen parameters, including the first screen parameters and the second screen parameters.

3. The screen adaptation method according to claim 1, characterized in that, The first screen parameters include at least one of the following: device information of the vehicle screen, MAC address, and serial number.

4. The screen adaptation method according to claim 1, characterized in that, Before reloading the device tree corresponding to the first screen parameters, the following steps are included: Store the first screen parameters in non-volatile memory.

5. The screen adaptation method according to claim 4, characterized in that, The reloading of the device tree corresponding to the first screen parameters includes the following steps: Restart the vehicle terminal; Read the first screen parameters stored in the non-volatile memory; Load the device tree corresponding to the first screen parameters.

6. The screen adaptation method according to claim 5, characterized in that, After reloading the device tree corresponding to the first screen parameters, the method further includes the following steps: When the vehicle terminal is restarted, the third screen parameters of the vehicle screen are read again. If the third screen parameters match the first screen parameters, the vehicle terminal will start normally.

7. The screen adaptation method according to claim 1, characterized in that, The method further includes the following steps: If the first screen parameter matches the second screen parameter corresponding to the current device tree, the vehicle terminal will start normally.

8. A vehicle-mounted terminal, characterized in that, include: At least one processor; At least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions, when executed by the at least one processor, causing the vehicle terminal to perform the screen adaptation method according to any one of claims 1 to 7.

9. A computer storage medium, characterized in that, The computer storage medium stores computer program instructions; when the computer program instructions are executed by the processor, they implement the screen adaptation method as described in any one of claims 1 to 7.

Images