System and method capable of automatically identifying different screen types and being compatible with different screens

Abstract

The invention discloses a system and method capable of automatically identifying different screen types and being compatible with different screens, and the system comprises a vehicle-mounted terminal and a screen terminal. The vehicle machine end comprises an SOC, a serializer and a crystal oscillator, video signals are transmitted between the SOC and the serializer of the vehicle machine end through an MIPI DSI interface, the SOC configures the serializer through an I2C interface, the crystal oscillator provides an external clock source for the serializer, the serializer encapsulates the video signals and I2C control signals into high-speed serial signals, and the high-speed serial signals are transmitted to the screen end through a SerDes link; the screen end comprises a deserializer, an LCD, a TP and an ADC, the deserializer of the screen end receives high-speed serial signals sent by the vehicle-mounted terminal, analyzes video signals in the high-speed serial signals into LVDS signals and inputs the LVDS signals into the LCD, the deserializer restores I2C control signals in the high-speed serial signals and is connected with the TP and the ADC, the deserializer is connected with the TP and the ADC through I2C interfaces, and the SOC of the vehicle-mounted terminal manages TP and ADC equipment of the screen end through the I2C interfaces.

Description

Technical field:

[0001] The present invention relates to a system and method capable of automatically identifying different screen types and being compatible with different screens, and belongs to the technical field of automotive electronics. Background technology:

[0002] With the development of the new energy vehicle industry, the models released by car companies are becoming more and more diversified. The screen sizes on different models are often different, and different configurations of the same model may also be equipped with screens of different specifications. In order to improve cost advantages, car companies often design car hardware as a platform, that is, the same car platform needs to be compatible with a variety of screens of different specifications. There are two main existing technical solutions: the first is to pass in the corresponding screen type for pre-setting when compiling the version, so that the screen type is selected when compiling and packaging resources. The disadvantages of this solution are: (1) Different models need to maintain a set of versions separately, and an additional version doubles the workload for testing; (2) The same version cannot be compatible with multiple screens, and the version must be upgraded again when the screen is replaced. The second method uses the configuration word method. When the vehicle is off the line, the production line worker writes the configuration word, and the software loads the corresponding screen driver, UI resources, etc. according to the configuration word. The disadvantages of this solution are: (1) It increases the production cost and the maintenance cost of the configuration word, and there is a possibility of error in manual operation; (2) The configuration word needs to be rewritten when the screen is replaced.

[0003] Therefore, it is necessary to improve the existing technology to solve the shortcomings of the existing technology. Summary of the invention:

[0004] The present invention aims to solve the above problems in the prior art and provides a system and method capable of automatically identifying different screen types and being compatible with different screens.

[0005] The present invention adopts the following technical solution: a system capable of automatically identifying different screen types and being compatible with different screens, including a vehicle terminal and a screen terminal;

[0006] The vehicle machine end includes a SOC, a serializer and a crystal oscillator. The video signal is transmitted between the SOC and the serializer of the vehicle machine end via a MIPIDSI interface. The SOC configures the serializer via an I2C interface. The crystal oscillator provides an external clock source for the serializer. The serializer encapsulates the video signal and the I2C control signal into a high-speed serial signal, which is transmitted to the screen end via a SerDes link.

[0007] The screen end includes a deserializer, an LCD, a TP and an ADC. The deserializer on the screen end receives a high-speed serial signal sent by the vehicle end, parses the video signal therein into an LVDS signal, and inputs it into the LCD. The deserializer restores the I2C control signal in the high-speed serial signal and connects to the TP and ADC. The deserializer is connected to the TP and ADC through an I2C interface, and the vehicle end SOC manages the TP and ADC devices on the screen end through the I2C interface.

[0008] Furthermore, the ADC is connected to an I2C interface of the deserializer, and ADCs of different screens use the same I2C address.

[0009] Furthermore, the product IDs of different screens in the screen terminal cannot be repeated, and the ID uniquely identifies a screen type.

[0010] Furthermore, the ADC channel number used by the vehicle computer to obtain the product ID of the screen remains consistent, so that the vehicle computer can obtain the product IDs of different screens by accessing the ADC channel with the same address.

[0011] The present invention also adopts the following technical solution: a method capable of automatically identifying different screen types and being compatible with different screens, the steps are as follows:

[0012] Step 1: When the car computer boots into the Linux kernel, load the serializer driver before loading the LCD driver. This driver enables the power pin of the serializer chip to make it work normally, and then configure the serializer through the I2C interface;

[0013] Step 2: Switch the serializer's clock source to external reference clock mode;

[0014] Step 3: Enable the I2C transparent transmission function of the serializer;

[0015] Step 4: The vehicle computer accesses the ADC device on the screen and reads the sampled value of the ADC channel corresponding to the screen product id. The sampled value is a voltage value. After quantization, the product id is obtained. The serializer driver exports the product id for use by other modules.

[0016] Step 5: After obtaining the product ID, switch the serializer clock source to DSI clock mode to prepare for LCD driver loading;

[0017] Step 6: Load LCD driver;

[0018] Step7: Load TP driver.

[0019] Furthermore, step 6 is as follows: first, query the mapping relationship in the device tree according to the product id to obtain the corresponding screen parameter configuration, including row and field signals, power-on and power-off timings, and TP driver name. The LCD driver loads the row and field signals and power-on and power-off timings, that is, the screen is lit normally. The TP driver name is opened to the application layer in the form of sysfs for use when loading the TP driver.

[0020] Further, step 7 is as follows: the TP driver is integrated into the system in the form of a kernel module (*.ko), and is loaded by the application in the init phase of Android. The application first obtains the name of the TP driver through sysfs, and then executes the insmod of the TP driver through the system() system call.

[0021] The present invention has the following beneficial effects: the present invention can automatically identify different screen types and is compatible with different screen systems and methods, and the operation of replacing the screen will be extremely convenient, eliminating the trouble of manual configuration. Since the design of the screen-side ADC is uniformly required in the implementation, the host-side management and diagnosis of the screen also become simple, reducing the complexity of the code while improving reusability. The present invention uses a strategy of switching to an external clock source when the serializer does not have a DSI clock source, rather than using an internal always-on clock mode, and has high reliability. Description of the drawings:

[0022] Figure 1 The diagram is a schematic diagram of a system capable of automatically identifying different screen types and being compatible with different screens according to the present invention.

[0023] Figure 2 The present invention is a flow chart of a method for automatically identifying different screen types and being compatible with different screens. Specific implementation method:

[0024] The present invention will be further described below in conjunction with the accompanying drawings.

[0025] The present invention can automatically identify different screen types and is compatible with different screen systems, including a vehicle side and a screen side. The SOC on the vehicle side transmits video signals to the serializer through a MIPIDSI interface. The SOC configures the serializer through an I2C interface. The crystal oscillator provides an external clock source for the serializer. The serializer encapsulates the video signal and control signals such as I2C into a high-speed serial signal, which is transmitted to the screen side through a high-speed serial link (SerDes link) based on a serializer and a deserializer. The deserializer on the screen side receives the high-speed serial signal sent by the vehicle side, parses the video signal therein into an LVDS signal, and inputs it into the display LCD. The deserializer restores the control signals such as I2C in the high-speed serial signal and connects to the touch panel (Touch Panel, referred to as TP) and ADC devices. The deserializer is connected to the TP and ADC through an I2C interface, so that the vehicle side SOC can manage the TP and ADC devices on the screen side through the I2C interface. In addition to the ADC device proposed by the present invention, other methods can also be used to store information on the screen side, such as non-volatile storage media (EEPROM, Flash, etc.). In addition to I2C, the interfaces for these devices that store screen information to communicate with the host can also use SPI or UART interfaces, and the corresponding transparent transmission mode is supported in the SerDes link.

[0026] Multiple screens on the screen side use the same ADC chip or a compatible alternative ADC chip to carry hardware information. The ADC chip is connected to the I2C interface of the deserializer, and the ADCs of different screens use the same I2C address. The product IDs of different screens on the screen side cannot be repeated, and the ID uniquely identifies a screen type. The ADC channel number used by the vehicle side to obtain the screen product ID remains consistent, so that the vehicle side can obtain the product IDs of different screens by accessing the ADC channel with the same address.

[0027] When the computer is turned on, the Linux kernel accesses the ADC on the screen side through the SerDes link to obtain the screen type, and then dynamically loads the corresponding screen configuration based on the mapping relationship. The biggest advantage of the present invention is that there is no need for manual intervention to replace the screen at a later stage. After the screen is replaced, the vehicle can be adaptively compatible after it is restarted. Secondly, the solution uses the SerDes link as a communication interface and has high stability. Third, generally speaking, large-scale vehicle-mounted screens that support basic diagnostic functions such as voltage detection, temperature detection, and hardware version number query will have built-in ADC chips, so this solution will not increase additional hardware costs.

[0028] The method of the present invention can automatically identify different screen types and is compatible with different screens, which is roughly divided into three stages: the host and the screen establish a SerDes communication link, the host obtains the screen product ID, that is, the screen type, and the host loads the screen configuration according to the screen type. The detailed steps are as follows:

[0029] Step 1: When the car computer boots into the Linux kernel, load the serializer driver before loading the LCD driver. This driver enables the power pin of the serializer chip to make it work normally, and then configure the serializer through the I2C interface;

[0030] Step 2: Switch the serializer's clock source to the external reference clock mode. Serializers generally have three common clock modes: DSI clock, external reference clock, and internal always-on clock. At this time, the LCD driver has not been loaded, so the SOC cannot provide the DSI clock for the deserializer, and the internal always-on clock is not reliable, so it is necessary to switch to the external reference clock. This is a necessary operation to establish a stable and reliable SerDes communication link before the LCD driver is loaded;

[0031] Step 3: Enable the I2C transparent transmission function of the serializer. After the configuration is completed, the host-side I2C bus can discover the deserializer device on the screen side and other peripherals connected to the deserializer I2C interface, such as ADC, TP, etc. Since all ADCs are agreed to use the same I2C address, it is clear which address corresponds to the ADC device;

[0032] Step 4: The vehicle computer accesses the ADC device on the screen and reads the sampled value of the ADC channel corresponding to the screen product id. The sampled value is a voltage value. After quantization, the product id is obtained. The serializer driver exports the product id for use by other modules.

[0033] Step 5: After obtaining the product ID, switch the serializer clock source to DSI clock mode to prepare for LCD driver loading. This step is a necessary condition for the screen to display correctly after the LCD driver is loaded;

[0034] Step 6: Load the LCD driver. First, query the mapping relationship in the device tree according to the product id to obtain the corresponding screen parameter configuration, including row and field signals, power-on and power-off timing, and TP driver name. The LCD driver loads the row and field signals and power-on and power-off timing to light up the screen normally. The TP driver name is open to the application layer in the form of sysfs for use when loading the TP driver;

[0035] Step 7: Load the TP driver. The TP driver is integrated into the system in the form of a kernel module (*.ko) and loaded by the application during the Android init phase. The application first obtains the name of the TP driver through sysfs, and then executes the insmod of the TP driver through the system() system call.

[0036] The vehicle screen of the present invention uses ADC or other equivalent devices to carry screen hardware information, and all screens adopt the same design, including the same device address, the same channel number or register address, and the product ID of all screens is globally unique. When the LCD driver is not loaded, the host adopts a strategy of switching to an external clock source first, and then switching back to the DSI clock source after the LCD driver is loaded, in order to establish a stable SerDes link with the screen.

[0037] The above description is only a preferred embodiment of the present invention. It should be pointed out that a person skilled in the art can make several improvements without departing from the principle of the present invention, and these improvements should also be regarded as within the protection scope of the present invention.

Claims

1. A system capable of automatically identifying different screen types and being compatible with different screens, characterized in that: Including the car side and the screen side; The vehicle machine end includes a SOC, a serializer and a crystal oscillator. The video signal is transmitted between the SOC and the serializer of the vehicle machine end via a MIPIDSI interface. The SOC configures the serializer via an I2C interface. The crystal oscillator provides an external clock source for the serializer. The serializer encapsulates the video signal and the I2C control signal into a high-speed serial signal, which is transmitted to the screen end via a SerDes link. The screen end includes a deserializer, an LCD, a TP and an ADC. The deserializer on the screen end receives a high-speed serial signal sent by the vehicle end, parses the video signal therein into an LVDS signal, and inputs it into the LCD. The deserializer restores the I2C control signal in the high-speed serial signal and connects to the TP and ADC. The deserializer is connected to the TP and ADC through an I2C interface, and the vehicle end SOC manages the TP and ADC devices on the screen end through the I2C interface.

2. The system capable of automatically identifying different screen types and being compatible with different screens as claimed in claim 1, characterized in that: The ADC is connected to the I2C interface of the deserializer, and the ADCs of different screens use the same I2C address.

3. The system capable of automatically identifying different screen types and being compatible with different screens as claimed in claim 2, characterized in that: The product IDs of different screens in the screen terminal cannot be repeated, and the ID uniquely identifies a screen type.

4. The system capable of automatically identifying different screen types and being compatible with different screens as claimed in claim 3, characterized in that: The ADC channel number used by the vehicle computer to obtain the screen product ID remains consistent, so that the vehicle computer can obtain the product IDs of different screens by accessing the ADC channel with the same address.

5. A method capable of automatically identifying different screen types and being compatible with different screens, characterized in that: Here are the steps: Step 1: When the car computer boots into the Linux kernel, load the serializer driver before loading the LCD driver. This driver enables the power pin of the serializer chip to make it work normally, and then configure the serializer through the I2C interface; Step 2: Switch the serializer's clock source to external reference clock mode; Step 3: Enable the I2C transparent transmission function of the serializer; Step 4: The vehicle computer accesses the ADC device on the screen and reads the sampled value of the ADC channel corresponding to the screen product id. The sampled value is a voltage value. After quantization, the product id is obtained. The serializer driver exports the product id for use by other modules. Step 5: After obtaining the product ID, switch the serializer clock source to DSI clock mode to prepare for LCD driver loading; Step 6: Load LCD driver; Step7: Load TP driver.

6. The method for automatically identifying different screen types and being compatible with different screens as claimed in claim 5, characterized in that: Step 6 is as follows: First, query the mapping relationship in the device tree according to the product id to obtain the corresponding screen parameter configuration, including row and field signals, power-on and power-off timings, and TP driver name. The LCD driver loads the row and field signals and power-on and power-off timings, that is, the screen is lit normally. The TP driver name is open to the application layer in the form of sysfs for use when loading the TP driver.

7. The method for automatically identifying different screen types and being compatible with different screens as claimed in claim 6, characterized in that: Step 7 is as follows: The TP driver is integrated into the system in the form of a kernel module (*.ko) and loaded by the application in the init phase of Android. The application first obtains the name of the TP driver through sysfs, and then executes the insmod of the TP driver through the system() system call.

Images