CN118820120A - Peripheral device adaptation method, computer equipment and medium for product verification - Google Patents

Abstract

The present application relates to the field of computer technology and provides a peripheral adaptation method, computer equipment and medium for product verification. The method includes: generating a peripheral device parameter document associated with the product to be verified; storing and maintaining the peripheral device parameter document through the device parameter partition of the system-level chip hardware system; in response to the verification of the product to be verified based on the first product specification under the main control system, at least before the software for verifying the product to be verified is started, parsing the peripheral device parameter document, thereby determining the device type, model and device parameter field of one or more peripherals corresponding to the first product specification, and selectively determining the input and output states of the one or more peripherals with the same device type, thereby obtaining a first parsing result, and then using the first parsing result to initialize the peripheral parameters for verifying the product to be verified. This reduces the workload and duration of verification.

Description

Peripheral device adaptation method, computer equipment and medium for product verification

Technical Field

The present application relates to the field of computer technology, and in particular to a peripheral adaptation method, computer equipment and medium for product verification.

Background Art

With the development of technologies such as integrated circuits and the Internet of Things, various peripherals are integrated into an electronic product and coordinated through the main control system and chips to achieve rich functions. Common peripherals include but are not limited to display screens, cameras, external storage devices such as flash memory, etc. In order to ensure the normal function of the product, debugging is performed through software coding and the software version is burned for verification. However, there are many different main control systems on the market, such as common operating systems such as Android, Linux, Ubuntu, etc. In the prior art, the version release, verification and documentation in the product development process are designed according to different operating system versions. The final software opening, testing and delivery need to be compiled and verified in different operating systems, which leads to a large workload and a long verification time, and leads to low efficiency in peripheral replacement and product upgrades.

To this end, the present application provides a peripheral adaptation method, computer device and medium for product verification, which are used to address the technical difficulties in the prior art.

Summary of the invention

In the first aspect, the present application provides a peripheral device adaptation method for product verification. The peripheral device adaptation method includes: generating a peripheral device parameter document associated with the product to be verified, wherein the peripheral device parameter document includes the device type, model and device parameter fields of each of the multiple peripherals, and the peripherals with the same device type in the multiple peripherals each have different input and output states, and different input and output states are distinguished by different input and output state identifiers; storing and maintaining the peripheral device parameter document through device parameter partitions of a system-on-chip hardware system, the main control system of the system-on-chip hardware system is stored in the main control system partition of the system-on-chip hardware system and the operation of the main control system is through the main control system partition and the system memory partition of the system-on-chip hardware system. area to be executed, the device parameter partition is isolated from the main control system partition and also from the system memory partition; in response to the verification of the product to be verified based on the first product specification under the main control system, at least before the software used to verify the product to be verified is started, the peripheral device parameter document in the device parameter partition is parsed to determine the device type, model and device parameter field of one or more peripherals corresponding to the first product specification, and selectively determine the input and output status of each peripheral with the same device type among the one or more peripherals, thereby obtaining a first parsing result, and then using the first parsing result to initialize the peripheral parameters for verifying the product to be verified.

Through the first aspect of the present application, the management of peripheral device parameter documents is decoupled from the main control system. In various links of the product to be verified, such as peripheral import verification, R&D debugging, version release and product specification upgrade, the peripheral device parameter documents are managed independently of the main control system, which can give full play to the advantage of completing the key work of debugging and verification after hardware selection; it does not rely on a certain main control system or any peripheral type, and decouples the update and management of peripheral device parameters from specific platforms and products, effectively overcoming the drawbacks of large workload and long time consumption of product verification solutions designed around the main control system, which is conducive to adding new peripherals or replacing existing peripherals, and is also conducive to promoting and replicating products. Product verification solution; it saves the participation of multiple departments and manpower investment. By filling in peripheral parameters and burning them to the product to achieve power-on verification, it also saves the workload of software compilation version and document update. The document no longer needs to be updated for each operating system. Only an independent peripheral support list needs to be updated. Different types of operating systems share the same support list. By greatly reducing the time and manpower investment for product verification, the speed of product promotion is increased, the learning cost of downstream manufacturers switching between different products is reduced, and the risk of peripheral upgrades is reduced. Only the device parameter partition needs to be updated, which also reduces the risk of the product being completely unusable and needing to be returned to the factory for repair due to problems such as freezing or upgrade failure during the upgrade process.

In a possible implementation of the first aspect of the present application, the peripheral device parameter document is stored and maintained through the device parameter partition of the system-on-chip hardware system, including: updating the peripheral device parameter document and storing the updated peripheral device parameter document in the device parameter partition.

In a possible implementation manner of the first aspect of the present application, updating the peripheral device parameter document stored in the device parameter partition is independent of updating the main control system stored in the main control system partition.

In a possible implementation manner of the first aspect of the present application, updating the peripheral device parameter document includes: adding a new peripheral or replacing an existing peripheral.

In a possible implementation of the first aspect of the present application, the peripheral device parameter document is updated by filling in the field data in a preset form, and then, the updated peripheral device parameter document is generated based on the filled in form, and then, the updated peripheral device parameter document is burned to the product to be verified.

In a possible implementation of the first aspect of the present application, the peripheral adaptation method also includes: in response to the verification of the product to be verified based on the second product specification under the main control system, at least before the software used to verify the product to be verified is started, parsing the peripheral device parameter document in the device parameter partition to determine a second parsing result corresponding to the second product specification, and then using the second parsing result to initialize the peripheral parameters for verifying the product to be verified.

In a possible implementation of the first aspect of the present application, different input and output states are distinguished by different input and output state identifiers, including: no more than four input and output states are distinguished by a two-bit input and output state identifier, or more than four and no more than eight input and output states are distinguished by a three-bit input and output state identifier.

In a possible implementation manner of the first aspect of the present application, the peripheral device parameter document stored in the device parameter partition is encrypted to prevent parameter theft or malicious tampering.

In a possible implementation of the first aspect of the present application, the device parameter field includes one or more of the following: display screen size, whether the display screen has a mobile device processor interface, whether the display screen has a low voltage differential signal interface, operating voltage, operating frequency, operating bandwidth, peak power, and peak voltage.

In a possible implementation manner of the first aspect of the present application, the device type is a display device, a camera device, a storage device, or a network device.

In a possible implementation of the first aspect of the present application, verification of the product to be verified based on the first product specification under the main control system is applied to the development and testing phase, debugging phase, product upgrade phase or document update phase of the product to be verified.

In a possible implementation of the first aspect of the present application, there are two peripherals among the one or more peripherals that satisfy a preset logical relationship, and the device type, model and device parameter fields of each of the two peripherals in the first analysis result are determined based on the preset logical relationship, and the preset logical relationship is a master-slave relationship, a mirror relationship or a parallel relationship.

In a second aspect, an embodiment of the present application further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements a method according to any one of the implementation modes of any of the above aspects when executing the computer program.

In a third aspect, an embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed on a computer device, the computer device executes a method according to any one of the implementation methods of any of the above aspects.

In a fourth aspect, an embodiment of the present application further provides a computer program product, which includes instructions stored on a computer-readable storage medium, and when the instructions are executed on a computer device, the computer device executes a method according to any one of the implementation methods of any of the above aspects.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

FIG1 is a schematic diagram of an application scenario including multiple main control systems and multiple peripherals;

FIG2 is a flow chart of a peripheral device adaptation method for product verification provided in an embodiment of the present application;

FIG3 is a schematic diagram of a system-on-chip hardware system for a peripheral device adaptation method for product verification provided by an embodiment of the present application with reference to FIG2 ;

FIG4 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application.

DETAILED DESCRIPTION

The embodiments of the present application will be further described in detail below in conjunction with the accompanying drawings.

It should be understood that, in the description of this application, "at least one" means one or more, and "a plurality of" means two or more. In addition, unless otherwise specified, the words "first", "second", etc. are only used for the purpose of distinguishing descriptions, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying an order.

FIG. 1 is a schematic diagram of an application scenario including multiple main control systems and multiple peripherals. As shown in FIG. 1 , the three main control systems are main control system A102, main control system B104, and main control system C106. Electronic product developers may use a variety of different main control systems, such as common operating systems such as Android, Linux, Ubuntu, etc. Various peripherals can be integrated on different main control systems, and common peripherals include but are not limited to display screens, cameras, external storage devices such as flash memory, etc. In order to ensure that the main control system and various peripherals integrated in the product can operate normally, it is necessary to debug through software coding, and it may also be necessary to compile firmware through software and burn it into the product, so as to achieve the corresponding binding of software parameters and products, and ensure that various peripherals work normally. In the application scenario of multiple main control systems and multiple peripherals as shown in FIG. 1 , each main control system may have its own characteristics, so the corresponding peripheral combinations may be different. For example, one main control system may be suitable for edge computing, portable intelligent terminal devices and other scenarios, so it tends to integrate peripherals with low energy consumption and long standby time to build electronic products. Another main control system may be suitable for data centers, artificial intelligence large models and other scenarios, so it tends to integrate peripherals with good performance and large storage space to build electronic products. Therefore, a variety of main control systems may correspond to different peripheral combinations, and the final product specifications of the electronic product are determined by the main control system used and the integrated peripherals. FIG1 exemplarily shows that the peripheral combination corresponding to the main control system A102 includes display peripherals A110, camera peripherals A120 and display peripherals B112; examples of product specifications of electronic products using the main control system A102 include product specification A180 including the main control system A102, display peripherals A110, and camera peripherals A120, and product specification B181 including the main control system A102, display peripherals B112, and camera peripherals A120. The peripheral combination corresponding to the main control system B104 includes display peripheral C114, camera peripheral B122, and display peripheral D116; examples of product specifications of electronic products using the main control system B104 include product specification C182 including the main control system B104, display peripheral C114, and camera peripheral B122, and product specification D183 including the main control system B104, display peripheral D116, and camera peripheral B122. The peripheral combination corresponding to the main control system C106 includes display peripheral A110, camera peripheral B122, and display peripheral E118; examples of product specifications of electronic products using the main control system C106 include product specification E184 including the main control system C106, display peripheral A110, and camera peripheral B122, and product specification F185 including the main control system C106, display peripheral E118, and camera peripheral B122. As can be seen, in order to run different operating systems and be compatible with different main control systems at the same time, and taking into account various peripheral combinations, six product specifications are shown in Figure 1. Therefore, if the version release, verification and documentation in the product development process are designed according to different operating system versions, the final software development and testing and delivery team needs to compile and verify in three operating systems respectively, and update the product documentation. If the corresponding six versions are compiled by software coding and six software versions are burned for verification, this will result in a large workload and a long time in various links such as peripheral import verification, R&D debugging, version release and product specification upgrades.

Continuing to refer to FIG. 1, it can be seen that among the various product specifications, a considerable portion of peripherals are repeated. For example, product specification A180 includes main control system A102, display peripheral A110, and camera peripheral A120, and product specification E184 includes main control system C106, display peripheral A110, and camera peripheral B122. For example, display peripheral A110 may be a 7-inch display screen with a mobile device processor interface (MIPI), camera peripheral A120 is a camera with a 1080P resolution, and camera peripheral B122 is a camera with a 720P resolution. In addition, in the peripheral combination corresponding to the same main control system, there may be peripherals of the same peripheral type but different models. For example, the peripheral combination corresponding to main control system A102 includes display peripheral A110, camera peripheral A120, and display peripheral B112. The display peripheral A110 can be a 7-inch display screen with MPI, and the display peripheral B112 can be a 24-inch display screen with a low voltage differential signaling interface (LVDS). Therefore, from the essence of peripheral debugging, debugging and verification after hardware selection have completed the key work. However, if the software version of each link is designed according to different main control systems such as operating system versions, from peripheral import, R&D debugging, version release to product specification upgrade, this will lead to the investment of multiple departments and manpower, and lead to compilation, version release, and verification after burning on different main control systems and operating systems. This product verification method based on software compilation and debugging designed around the main control system, although it ensures that each peripheral including the newly added peripherals can work stably when the operating system running on the main control system is different, it leads to a lot of duplication of work and inefficiency in peripheral replacement and product upgrade. For example, assuming that the hardware selection determines that a certain peripheral needs to be added, after adding the new peripheral, the hardware and software are jointly debugged and verified, and the software writes code for the verified parameters respectively. If there are 6 product specifications shown in Figure 1, 6 versions need to be compiled, and the test team burns 6 software versions for verification respectively. Finally, the delivery team updates the peripheral support list of the product in different operating systems. It can be seen that if a new peripheral is added to an electronic product, such as adding a storage peripheral, the product verification scheme designed around the main control system requires the participation of departments such as software development, hardware, and delivery support, and the workload is large and time-consuming. To this end, the embodiment of the present application provides a product verification scheme decoupled from the main control system. On the basis of effectively overcoming the various drawbacks of the product verification scheme designed around the main control system, a reliable verification method is provided to ensure that the main control system, various peripherals, and software can work stably and normally together, and the workload of code compilation, debugging, and maintenance documents in various links such as peripheral import verification, research and development debugging, version release, and product specification upgrades is saved as much as possible. The following is a detailed description in conjunction with Figure 2.

Fig. 2 is a flow chart of a peripheral device adaptation method for product verification provided in an embodiment of the present application. As shown in Fig. 2, the peripheral device adaptation method includes the following steps.

Step S210: Generate a peripheral device parameter document associated with the product to be verified, wherein the peripheral device parameter document includes the device type, model and device parameter fields of each of the multiple peripherals, and the peripherals with the same device type among the multiple peripherals each have different input and output states, and different input and output states are distinguished by different input and output state identifiers.

Step S220: The peripheral device parameter document is stored and maintained through the device parameter partition of the system-on-chip hardware system. The main control system of the system-on-chip hardware system is stored in the main control system partition of the system-on-chip hardware system and the operation of the main control system is executed through the main control system partition and the system memory partition of the system-on-chip hardware system. The device parameter partition is isolated from the main control system partition and the system memory partition.

Step S230: In response to the verification of the product to be verified based on the first product specification under the main control system, at least before the software used to verify the product to be verified is started, the peripheral device parameter document in the device parameter partition is parsed to determine the device type, model and device parameter field of one or more peripherals corresponding to the first product specification, and selectively determine the input and output status of each peripheral with the same device type among the one or more peripherals, so as to obtain a first parsing result, and then use the first parsing result to initialize the peripheral parameters for verifying the product to be verified.

Referring to FIG. 2, the peripheral adaptation method for product verification shown in FIG. 2 can be applied to different links of electronic products, such as peripheral import verification, R&D debugging, version release, and product specification upgrade. An electronic product integrates various peripherals and coordinates various peripherals through the main control system and chip to achieve rich functions. Common peripherals include but are not limited to display screens, cameras, external storage devices such as flash memory, etc. In order to ensure that the main control system and various peripherals integrated in the product can operate normally, it is necessary not only to consider the requirements of the operating system adopted by the main control system, but also to consider that the product manufacturer may have formulated a specific software design scheme and main control system operation scheme for its own products, and to consider the software parameter requirements of various different peripherals (such as peripheral drive requirements, connection requirements, etc.), and it is also necessary to consider changes in product specifications such as adding new peripherals or replacing existing peripherals, etc. For this reason, reliable verification means are needed to ensure that the main control system, various peripherals, and software can work stably and normally together. In step S210, a peripheral device parameter document associated with the product to be verified is generated. Wherein, the peripheral device parameter document includes the device type, model and device parameter field of each of the plurality of peripherals, and the peripherals with the same device type in the plurality of peripherals each have different input and output states, and the different input and output states are distinguished by different input and output state identifiers. Here, the product to be verified refers to an electronic product that needs to verify the normal operation of the main control system, various peripherals and software together. The product to be verified may need to be compatible with a variety of different main control systems, a variety of different operating systems and various peripherals, such as the 6 product specifications shown in Figure 1. The product verification scheme designed around the main control system has various drawbacks. For example, the software version at each link is designed according to different main control systems such as operating system versions, from peripheral import, R&D debugging, version release to product specification upgrade, which will lead to the investment of multiple departments and manpower, and lead to compilation, version release, burning and power-on verification on different main control systems and operating systems. Here, in step S210, the peripheral information and device parameters are extracted, for example, the peripherals that often need to be debugged and replaced are classified and summarized, such as the listed peripherals are divided into three categories: MIPI display screen, camera, LVDS display screen, etc. In this way, the peripheral device parameter document associated with the product to be verified is generated, which means that the possible peripheral combinations corresponding to the product to be verified are classified and summarized, and organized into a specific data format, that is, the peripheral device parameter document includes the device type, model and device parameter field of each of the multiple peripherals. The device type is used to indicate the type of peripheral device such as display peripheral, storage peripheral, camera peripheral. The model is used to indicate the specific device model, such as a camera with a resolution of 1080P, a camera with a resolution of 720P, a 7-inch display screen with MPI, and a 24-inch display screen with LVDS. The device parameter field is used to provide customized requirements for peripheral devices, such as operating voltage, operating power, peak voltage, peak power, data bandwidth, communication protocol, etc. Here, there may be peripherals of the same device type in multiple peripherals. This is to take into account that the product specifications of electronic products in actual applications may adopt situations such as multiple display screens, multiple cameras, and multiple storage peripherals. For example, the peripheral combination corresponding to the main control system A102 shown in Figure 1 includes display peripheral A110, camera peripheral A120 and display peripheral B112. The peripherals with the same device type in the multiple peripherals each have different input and output states, and different input and output states are distinguished by different input and output state identifiers. This means that among the multiple peripherals, regardless of whether they have the same device type or different device types, each peripheral is treated separately, and each peripheral records the peripheral information of the peripheral according to a specific data structure, so as to parse the peripheral information later and use the parsed parameters for initialization. In addition, different input and output states are distinguished by different input and output state identifiers, and then peripherals with the same device type are distinguished. In this way, in the subsequent process, if there are two or more sets of the same type of peripheral parameters, the input and output states are additionally read, and the records matching the input and output states are selected for indexing to find the corresponding peripheral parameters.

Continuing to refer to FIG. 2, after step S210, execute step S220. In step S220, the peripheral device parameter document is stored and maintained through the device parameter partition of the system-on-chip hardware system, the main control system of the system-on-chip hardware system is stored in the main control system partition of the system-on-chip hardware system and the operation of the main control system is executed through the main control system partition and the system memory partition of the system-on-chip hardware system, and the device parameter partition is isolated from the main control system partition and also from the system memory partition. In this way, partition isolation helps to ensure decoupling from the main control system, and helps to ensure that the storage and maintenance of the peripheral device parameter document is independent of the operation of the main control system, for example, the burning, erasing and updating of the operating system will not affect the device parameter partition. Furthermore, the operation of the main control system is executed through the main control system partition and the system memory partition of the system-level chip hardware system. This means that while maintaining the normal operation of the main control system and data business processing, the device parameter partition can be modified without affecting the normal operation of the current business. This helps to import the peripheral information that needs to be debugged and the parameters changed into the peripheral device parameter document in the device parameter partition in advance, so that the peripheral adaptation can be performed during the business gap after the current business ends, thereby improving overall efficiency.

Continuing to refer to FIG. 2, after step S220, step S230 is executed. In step S230, in response to the verification of the product to be verified based on the first product specification under the main control system, at least before the software for verifying the product to be verified is started, the peripheral device parameter document in the device parameter partition is parsed to determine the device type, model and device parameter field of one or more peripherals corresponding to the first product specification, and selectively determine the input and output status of the peripherals with the same device type in the one or more peripherals, thereby obtaining a first parsing result, and then using the first parsing result to initialize the peripheral parameters for verifying the product to be verified. In step S210, a peripheral device parameter document associated with the product to be verified is generated, which means that the possible peripheral combinations corresponding to the product to be verified are classified and summarized, and organized into a specific data format, and different input and output statuses are distinguished by different input and output status identifiers to distinguish peripherals with the same device type. In step S220, by partition isolation, it is ensured that the storage and maintenance of the peripheral device parameter document is independent of the operation of the main control system, so that the management of the peripheral device parameter document is decoupled from the main control system. In this way, in each link of the product to be verified, such as peripheral import verification, research and development debugging, version release and product specification upgrade, by managing the peripheral device parameter document independently of the main control system, the advantage of completing the key work by debugging and verification after hardware selection can be fully utilized, and the device parameter partition of the system-level chip hardware system is reserved as a reserved storage area to store and maintain the peripheral device parameter document, so that the peripheral adaptation work can be decoupled from the main control system, the parameters that need to be debugged repeatedly can be extracted, and the hardware can be debugged independently, and the test results of a single product can be equivalent to other products. Here, in step S230, there may be multiple product specifications for the product to be verified, which are used to adapt to different user needs and design specifications. For example, the product specifications A180 and product specifications B181 shown in Figure 1 both use the main control system A102 but use different peripheral components. In response to the verification of the product to be verified based on the first product specification under the main control system, the peripheral information stored in the device parameter partition is read in advance during the software startup process, and each type of peripheral parameters is parsed separately. If there are two or more sets of the same type of peripheral parameters, the input and output status is additionally read, and the record matching the input and output status is selected for indexing to find the corresponding peripheral parameters. When the peripheral needs to be initialized, the parsed parameters are directly used for initialization. In other words, in response to the verification of the product to be verified based on the first product specification under the main control system, at least before the software for verifying the product to be verified is started, the peripheral device parameter document in the device parameter partition is parsed, so as to determine the device type, model and device parameter field of one or more peripherals corresponding to the first product specification, and selectively determine the input and output status of each peripheral with the same device type among the one or more peripherals, thereby obtaining a first parsing result, and then, the first parsing result is used to initialize the peripheral parameters for verifying the product to be verified. Here, the one or more peripherals corresponding to the first product specification are determined based on the first product specification. Other product specifications of the product to be verified may correspond to different peripheral combinations. The peripheral combinations corresponding to other product specifications can be determined by executing step S230 again and obtaining the corresponding analysis results. The analysis results corresponding to other product specifications are then used to parameterize the peripherals, thereby ensuring that the main control system, peripherals and software under other product specifications work stably together. In this way, by partitioning and isolating and ensuring that the storage and maintenance of the peripheral device parameter document are independent of the operation of the main control system, the peripheral device parameter document can be used to flexibly adapt to the different product specifications of the product to be verified. The software can only compile one product version and test and verify it. The solution can be copied to other main control systems, and each main control system selects a product version for test and verification. In this way, the peripheral device parameter document, as a peripheral support document, is not bound to the operating system, but is independently managed separately. For different main control systems, only the peripheral device parameter document needs to be updated to complete the entire product verification solution.

The peripheral device adaptation method for product verification shown in FIG2 provides a peripheral device parameter document for each main control system, and through partition isolation and ensuring that the storage and maintenance of the peripheral device parameter document are independent of the operation of the main control system, the management of the peripheral device parameter document is decoupled from the main control system. By retaining the device parameter partition of the system-level chip hardware system as a reserved storage area for storing and maintaining the peripheral device parameter document, the peripheral device adaptation work can be decoupled from the main control system, the parameters that need to be repeatedly debugged can be extracted and handed over to the hardware for independent debugging, and the test results of a single product can be equivalent to other products. In addition, different input and output status identifiers are used to distinguish different input and output states and then distinguish peripherals with the same device type. In this way, in the subsequent process, if there are two or more sets of the same type of peripheral parameters, the input and output status is additionally read, and the records matching the input and output status are selected for indexing to find the corresponding peripheral parameters. This means that among multiple peripherals, no matter whether they are of the same device type or different device types, each peripheral is treated separately, and each peripheral records the peripheral information of the peripheral according to a specific data structure, so as to parse the peripheral information and initialize it with the parsed parameters. In addition, the operation of the main control system is executed through the main control system partition and the system memory partition of the system-on-chip hardware system, which means that while maintaining the normal operation of the main control system and data service processing, the device parameter partition can be modified without affecting the normal operation of the current business. This helps to import the peripheral information that needs to be debugged and the parameters replaced into the peripheral device parameter document in the device parameter partition in advance, so that the peripheral adaptation can be performed during the business idle period after the current business ends, thereby improving the overall efficiency. In summary, the peripheral adaptation method for product verification shown in Figure 2 realizes the management of peripheral device parameter documents is decoupled from the main control system. In various links of the product to be verified, such as peripheral import verification, R&D debugging, version release and product specification upgrade, by managing peripheral device parameter documents independently of the main control system, it can give full play to the advantage of completing the key work of debugging and verification after hardware selection; it does not rely on a certain main control system or any peripheral type, and decouples the update and management of peripheral device parameters from specific platforms and products, effectively overcoming the disadvantages of large workload and long time consumption of product verification solutions designed around the main control system, which is conducive to adding new peripherals or replacing existing peripherals, and is also conducive to promoting Guanghe replicated the product verification solution; it saved the participation of multiple departments and manpower investment. By filling in the peripheral parameters and burning them to the product to achieve power-on verification, it also saved the workload of software compilation version and document update. The document no longer needs to be updated for each operating system. Only an independent peripheral support list needs to be updated. Different types of operating systems share the same support list; by greatly reducing the time and manpower investment in product verification, the speed of product promotion is increased, the learning cost of downstream manufacturers switching between different products is reduced, and the risk of peripheral upgrades is reduced. Only the device parameter partition needs to be updated, which also reduces the risk of the product being completely unusable and needing to be returned to the factory for repair due to problems such as freezing or upgrade failure during the upgrade process.

FIG3 is a schematic diagram of a system-on-chip hardware system for a peripheral adaptation method for product verification provided by an embodiment of the present application with reference to FIG2. As shown in FIG3, the system-on-chip hardware system 302 includes a main control system partition 303, a system memory partition 304, and a device parameter partition 305. The peripheral device parameter document 310 is stored and maintained through the device parameter partition 305 of the system-on-chip hardware system 302. The main control system of the system-on-chip hardware system 302 is stored in the main control system partition 303 of the system-on-chip hardware system 302, and the operation of the main control system is performed through the main control system partition 303 and the system memory partition 304 of the system-on-chip hardware system 302. The device parameter partition 305 is isolated from the main control system partition 303 and the system memory partition 304. The peripheral device parameter document 310 includes the device type, model, and device parameter fields of multiple peripherals, and the peripherals with the same device type in the multiple peripherals each have different input and output states, and different input and output states are distinguished by different input and output state identifiers. FIG3 exemplifies a diagram showing that a peripheral device parameter document 310 records possible peripheral combinations corresponding to a main control system of a system-on-chip hardware system 302, including a peripheral A330 of type A320 with an input-output status A351, a peripheral B331 of type B322, a peripheral C332 of type A320 with an input-output status B352, a peripheral D333 of type C324, a peripheral E334 of type D326, and a peripheral F335 of type E328.

Referring to Figures 2 and 3, it can be seen that the management of peripheral device parameter documents is decoupled from the main control system. In various links of the product to be verified, such as peripheral import verification, R&D debugging, version release, and product specification upgrade, the management of peripheral device parameter documents independently of the main control system can give full play to the advantage of completing the key work of debugging and verification after hardware selection; it does not rely on a certain main control system or any peripheral type, and decouples the update and management of peripheral device parameters from specific platforms and products, effectively overcoming the drawbacks of large workload and long time consumption of product verification solutions designed around the main control system, which is conducive to adding new peripherals or replacing existing peripherals, and is also conducive to promotion and replication. Product verification solution; saves the participation and manpower investment of multiple departments, realizes power-on verification by filling in peripheral parameters and burning them to the product, and also saves the workload of software compilation version and document update. The document no longer needs to be updated for each operating system. Only an independent peripheral support list needs to be updated. Different types of operating systems share the same support list; by greatly reducing the time and manpower investment of product verification, the speed of product promotion is increased, the learning cost of downstream manufacturers switching between different products is reduced, and the risk of peripheral upgrades is reduced. Only the device parameter partition needs to be updated, which also reduces the risk of freezing or upgrade failure during the upgrade process, which makes the product completely unusable and needs to be returned to the factory for repair.

Referring to FIG. 2 and FIG. 3, in a possible implementation, the device parameter partition of the system-on-chip hardware system is used to store and maintain the peripheral device parameter document, including: updating the peripheral device parameter document and storing the updated peripheral device parameter document in the device parameter partition. In this way, by partition isolation, it is ensured that the storage and maintenance of the peripheral device parameter document is independent of the operation of the main control system, thereby realizing that the management of the peripheral device parameter document is decoupled from the main control system. In this way, in each link of the product to be verified, such as peripheral import verification, R&D debugging, version release, and product specification upgrade, by managing the peripheral device parameter document independently of the main control system, the advantage of having completed the key work by debugging and verifying after hardware selection can be fully utilized, and by retaining the device parameter partition of the system-on-chip hardware system as a reserved storage area for storing and maintaining the peripheral device parameter document, the peripheral adaptation work can be decoupled from the main control system, the parameters that need to be repeatedly debugged can be extracted, and the hardware can be debugged independently, and the test results of a single product can be equivalent to other products.

In some embodiments, updating the peripheral device parameter document stored in the device parameter partition is independent of updating the main control system stored in the main control system partition. In this way, the management of the peripheral device parameter document is decoupled from the main control system. In various links of the product to be verified, such as peripheral import verification, R&D debugging, version release, and product specification upgrade, the management of the peripheral device parameter document independently of the main control system can give full play to the advantage of completing the key work of debugging and verification after hardware selection; it does not rely on a certain main control system or any peripheral type, and decouples the update and management of peripheral device parameters from specific platforms and products, effectively overcoming the drawbacks of large workload and long time consumption of product verification solutions designed around the main control system, which is conducive to adding new peripherals or replacing existing peripherals, and is also conducive to promoting and replicating product verification solutions.

In some embodiments, updating the peripheral device parameter document includes: adding new peripherals or replacing existing peripherals. In this way, the updating and management of peripheral device parameters are decoupled from specific platforms and products, effectively overcoming the drawbacks of large workload and long time consumption of product verification solutions designed around the main control system, which is conducive to adding new peripherals or replacing existing peripherals, and is also conducive to promoting and replicating product verification solutions.

In some embodiments, the peripheral device parameter document is updated by filling in the field data in a preset form, then generating the updated peripheral device parameter document based on the filled in form, and then burning the updated peripheral device parameter document to the product to be verified. This is conducive to adding new peripherals or replacing existing peripherals, and is also conducive to promoting and replicating product verification solutions; it saves the participation of multiple departments and manpower investment, and realizes power-on verification by filling in peripheral parameters and burning them to the product.

In a possible implementation, the peripheral adaptation method further includes: in response to the verification of the product to be verified based on the second product specification under the main control system, at least before the software for verifying the product to be verified is started, parsing the peripheral device parameter document in the device parameter partition, thereby determining a second parsing result corresponding to the second product specification, and then using the second parsing result to initialize the peripheral parameters for verifying the product to be verified. Other product specifications of the product to be verified may correspond to different peripheral combinations. By determining the peripheral combinations corresponding to other product specifications and obtaining the corresponding parsing results, and then using the parsing results corresponding to other product specifications to perform peripheral parameterization, it is ensured that the main control system, peripherals and software under other product specifications work stably together. In this way, the participation of multiple departments and manpower investment are saved. By filling in the peripheral parameters and burning them to the product to achieve power-on verification, the workload of software compilation version and document update is also saved. The document no longer needs to be updated for each operating system. Only an independent peripheral support list needs to be updated. Different types of operating systems share the same support list. By greatly reducing the time and manpower investment in product verification, the speed of product promotion is increased, the learning cost of downstream manufacturers switching between different products is reduced, and the risk of peripheral upgrades is reduced. Only the device parameter partition needs to be updated, which also reduces the risk of the product being completely unusable and needing to be returned to the factory for repair due to problems such as freezing or upgrade failure during the upgrade process.

In a possible implementation, different input and output states are distinguished by different input and output state identifiers, including: no more than four input and output states are distinguished by a two-bit input and output state identifier, or more than four and no more than eight input and output states are distinguished by a three-bit input and output state identifier. Different input and output states are distinguished by different input and output state identifiers, and then peripherals with the same device type are distinguished. In this way, in the subsequent process, if there are two or more sets of the same type of peripheral parameters, the input and output states are additionally read, and the records matching the input and output states are selected for indexing to find the corresponding peripheral parameters. This means that among multiple peripherals, regardless of whether they have the same device type or different device types, each peripheral is treated separately, and each peripheral records the peripheral information of the peripheral according to a specific data structure, so as to parse the peripheral information and initialize it using the parsed parameters.

In a possible implementation, the peripheral device parameter document stored in the device parameter partition is encrypted to prevent parameter theft or malicious tampering. Thus, by encrypting the peripheral device parameter document stored in the device parameter partition, system stability and security can be more effectively improved.

In a possible implementation, the device parameter field includes one or more of the following: screen size, whether the screen has a mobile device processor interface, whether the screen has a low voltage differential signal interface, operating voltage, operating frequency, operating bandwidth, peak power, and peak voltage. In this way, a rich customization option for peripheral devices is provided.

In a possible implementation, the device type is a display device, a camera device, a storage device or a network device, which is helpful for adapting to various peripheral devices.

In a possible implementation, the verification of the product to be verified based on the first product specification under the main control system is applied to the development and testing phase, debugging phase, product upgrade phase or document update phase of the product to be verified. In this way, the management of the peripheral device parameter document is decoupled from the main control system. In various links of the product to be verified, such as peripheral import verification, R&D debugging, version release and product specification upgrade, the peripheral device parameter document is managed independently of the main control system, which can give full play to the advantage of completing key work by debugging and verification after hardware selection.

In a possible implementation, there are two peripherals that meet the preset logical relationship among the one or more peripherals, and the device type, model and device parameter fields of the two peripherals in the first parsing result are determined based on the preset logical relationship, and the preset logical relationship is a master-slave relationship, a mirror relationship or a parallel relationship. Here, the master-slave relationship means that the peripheral as the main device keeps working under normal circumstances, and the peripheral as the backup device intervenes only when the main device cannot work normally, such as when it needs to be upgraded or fails. Therefore, the two peripherals that meet the master-slave relationship are generally consistent in the peripheral parameter configuration, that is, the device type, model and device parameter field of the two peripherals are determined based on the preset logical relationship. In addition, the mirror relationship also means that the two peripherals that meet the mirror relationship are generally consistent in the peripheral parameter configuration. In addition, the parallel relationship means that the two peripherals that meet the parallel relationship are consistent in some key peripheral parameters, such as data bandwidth. By determining the device type, model and device parameter field of the two peripherals that meet the preset logical relationship by the preset logical relationship, the application scenarios of various complex and changeable peripherals can be better adapted. Further, referring to FIG. 2 and FIG. 3, in some embodiments, a specially designed data structure is used to sort out the corresponding device type, model, and device parameters, and the device parameters that need to be debugged repeatedly are prepared in advance, and then the specific peripheral hardware is used to inform which device parameters should be used, so as to achieve peripheral adaptation, which can be applied to the simulation verification in the design stage, the test in the production stage, and the debugging in the application stage. The search results in the device parameter partition can be used to determine whether the debugging requirements of the current peripheral exceed the device parameter range prepared in advance. If the search does not hit, it means that the parameters are out of range. In this way, the device parameter partition can be upgraded by adding a new set of device parameters, and new input and output states can be selectively added, which reduces the difficulty of debugging and reuses the existing device parameters as much as possible to improve the debugging efficiency. In addition, on the basis that the parameters are not out of range, the peripheral adaptation can be better achieved based on the logical dependency between the devices. For example, the master-slave mode, the mirror mode, etc. generally mean that two sets of peripherals use the same device parameters, and multiple sets of peripherals in a parallel processing relationship generally use the same clock frequency to ensure synchronization, and multiple sets of peripherals in a serial pipeline processing relationship generally use the same input data bit width to ensure data throughput efficiency. In this way, the retrieval efficiency can be improved and peripheral adaptation can be better achieved.

4 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application, and the computing device 400 includes: one or more processors 410, a communication interface 420 and a memory 430. The processor 410, the communication interface 420 and the memory 430 are interconnected via a bus 440. Optionally, the computing device 400 may also include an input/output interface 450, and the input/output interface 450 is connected to an input/output device for receiving parameters set by a user, etc. The computing device 400 can be used to implement some or all of the functions of the device embodiment or system embodiment in the above-mentioned embodiment of the present application; the processor 410 can also be used to implement some or all of the operating steps of the method embodiment in the above-mentioned embodiment of the present application. For example, the specific implementation of the various operations performed by the computing device 400 can refer to the specific details in the above-mentioned embodiments, such as the processor 410 is used to perform some or all of the steps in the above-mentioned method embodiment or some or all of the operations in the above-mentioned method embodiment. For another example, in an embodiment of the present application, the computing device 400 may be used to implement part or all of the functions of one or more components in the above-mentioned apparatus embodiment. In addition, the communication interface 420 may be specifically used to perform the communication functions necessary to implement the functions of these apparatuses and components, and the processor 410 may be specifically used to perform the processing functions necessary to implement the functions of these apparatuses and components.

It should be understood that the computing device 400 of FIG. 4 may include one or more processors 410, and the multiple processors 410 may provide processing capabilities in a coordinated manner in a parallel connection mode, a serial connection mode, a serial-parallel connection mode, or an arbitrary connection mode, or the multiple processors 410 may constitute a processor sequence or a processor array, or the multiple processors 410 may be divided into a main processor and an auxiliary processor, or the multiple processors 410 may have different architectures such as a heterogeneous computing architecture. In addition, the computing device 400 shown in FIG. 4, the related structural description and functional description are exemplary and non-restrictive. In some exemplary embodiments, the computing device 400 may include more or fewer components than those shown in FIG. 4, or combine some components, or split some components, or have a different arrangement of components.

The processor 410 may have a variety of specific implementation forms. For example, the processor 410 may include a central processing unit (CPU), a graphic processing unit (GPU), a neural-network processing unit (NPU), a tensor processing unit (TPU) or a data processing unit (DPU), etc., and the embodiment of the present application does not specifically limit it. The processor 410 may also be a single-core processor or a multi-core processor. The processor 410 may be a combination of a CPU and a hardware chip. The above-mentioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The above-mentioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof. The processor 410 may also be implemented using a logic device with built-in processing logic alone, such as an FPGA or a digital signal processor (DSP). The communication interface 420 may be a wired interface or a wireless interface for communicating with other modules or devices. The wired interface may be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface may be a cellular network interface or a wireless local area network interface, etc.

The memory 430 may be a non-volatile memory, such as a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The memory 430 may also be a volatile memory, which may be a random access memory (RAM) used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM). The memory 430 can also be used to store program codes and data, so that the processor 410 calls the program codes stored in the memory 430 to execute some or all of the operation steps in the above method embodiments, or to execute the corresponding functions in the above device embodiments. In addition, the computing device 400 may include more or fewer components than those shown in FIG. 4, or have different component configurations.

The bus 440 may be a peripheral component interconnect express (PCIe) bus, or an extended industry standard architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL), a cache coherent interconnect for accelerators (CCIX), etc. The bus 440 may be divided into an address bus, a data bus, a control bus, etc. In addition to the data bus, the bus 440 may also include a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity, FIG. 4 is represented by only one thick line, but it does not mean that there is only one bus or one type of bus.

The method and device provided in the embodiments of the present application are based on the same inventive concept. Since the principles of solving the problems in the methods and devices are similar, the embodiments, implementation methods, examples or implementation methods of the methods and devices can refer to each other, and the repeated parts will not be repeated. The embodiments of the present application also provide a system, which includes multiple computing devices, and the structure of each computing device can refer to the structure of the computing device described above. The functions or operations that can be implemented by the system can refer to the specific implementation steps in the above method embodiments and/or the specific functions described in the above device embodiments, which will not be repeated here.

The present application also provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are executed on a computer device (such as one or more processors), the method steps in the above method embodiment can be implemented. The specific implementation of the processor of the computer-readable storage medium in executing the above method steps can refer to the specific operations described in the above method embodiment and/or the specific functions described in the above device embodiment, which will not be repeated here.

It should be understood by those skilled in the art that the embodiments of the present application may be provided as methods, systems, or computer program products. The present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. The embodiments of the present application may be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented using software, the above embodiments may be implemented in whole or in part in the form of a computer program product. The present application may take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program codes. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, the process or function described in the embodiments of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. Computer-readable storage media can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media. Available media can be magnetic media (such as floppy disks, hard disks, tapes), optical media, or semiconductor media. Semiconductor media can be solid-state hard disks, random access memory, flash memory, read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, or any other form of suitable storage media.

The present application is described with reference to the flowchart and/or block diagram of the method, device (system) and computer program product according to the embodiment of the present application. Each flow and/or box in the flow chart and/or block diagram, and the combination of the flow chart and/or box in the flow chart and/or block diagram can be realized by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for realizing the function specified in one flow chart or multiple flows and/or one box or multiple boxes of the block chart. These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the function specified in one flow chart or multiple flows and/or one box or multiple boxes of the block diagram. These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. Obviously, those skilled in the art can make various changes and modifications to the embodiments of the present application without departing from the spirit and scope of the embodiments of the present application. The steps in the method of the embodiment of the present application can be adjusted in order, merged or deleted according to actual needs; the modules in the system of the embodiment of the present application can be divided, merged or deleted according to actual needs. If these modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these modifications and variations.

Claims (14)

1. A peripheral device adaptation method for product verification, characterized in that the peripheral device adaptation method comprises: Generate a peripheral device parameter document associated with the product to be verified, wherein the peripheral device parameter document includes a device type, a model, and a device parameter field of each of the plurality of peripherals, and peripherals with the same device type among the plurality of peripherals each have a different input and output state, and the different input and output states are distinguished by different input and output state identifiers; The peripheral device parameter document is stored and maintained through the device parameter partition of the system-on-chip hardware system, the main control system of the system-on-chip hardware system is stored in the main control system partition of the system-on-chip hardware system and the operation of the main control system is performed through the main control system partition and the system memory partition of the system-on-chip hardware system, and the device parameter partition is isolated from the main control system partition and the system memory partition; In response to the verification of the product to be verified based on the first product specification under the main control system, at least before the software used to verify the product to be verified is started, the peripheral device parameter document in the device parameter partition is parsed to determine the device type, model and device parameter field of one or more peripherals corresponding to the first product specification, and selectively determine the input and output status of each peripheral with the same device type among the one or more peripherals, so as to obtain a first parsing result, and then use the first parsing result to initialize the peripheral parameters for verifying the product to be verified. 2. The peripheral adaptation method according to claim 1 is characterized in that the peripheral device parameter document is stored and maintained through the device parameter partition of the system-on-chip hardware system, including: updating the peripheral device parameter document and storing the updated peripheral device parameter document in the device parameter partition. 3. The peripheral device adaptation method according to claim 2, characterized in that updating the peripheral device parameter document stored in the device parameter partition is independent of updating the main control system stored in the main control system partition. 4. The peripheral adaptation method according to claim 2 is characterized in that updating the peripheral device parameter document includes: adding a new peripheral or replacing an existing peripheral. 5. The peripheral adaptation method according to claim 2 is characterized in that the peripheral device parameter document is updated by filling in the field data in a preset form, and then, the updated peripheral device parameter document is generated based on the filled in form, and then, the updated peripheral device parameter document is burned to the product to be verified. 6. The peripheral device adaptation method according to claim 1, characterized in that the peripheral device adaptation method further comprises: In response to the verification of the product to be verified based on the second product specification under the main control system, at least before the software used to verify the product to be verified is started, the peripheral device parameter document in the device parameter partition is parsed to determine a second parsing result corresponding to the second product specification, and then the second parsing result is used to initialize the peripheral parameters for verifying the product to be verified. 7. The peripheral adaptation method according to claim 1 is characterized in that different input and output states are distinguished by different input and output state identifiers, including: no more than four input and output states are distinguished by a two-bit input and output state identifier, or more than four and no more than eight input and output states are distinguished by a three-bit input and output state identifier. 8. The peripheral device adaptation method according to claim 1 is characterized in that the peripheral device parameter document stored in the device parameter partition is encrypted to prevent parameter theft or malicious tampering. 9. The peripheral adaptation method according to claim 1 is characterized in that the device parameter field includes one or more of the following: display screen size, whether the display screen has a mobile device processor interface, whether the display screen has a low voltage differential signal interface, operating voltage, operating frequency, operating bandwidth, peak power, and peak voltage. 10 . The peripheral device adaptation method according to claim 1 , wherein the device type is a display device, a camera device, a storage device or a network device. 11. The peripheral adaptation method according to claim 1 is characterized in that the verification of the product to be verified based on the first product specification under the main control system is applied to the development and testing stage, debugging stage, product upgrade stage or document update stage of the product to be verified. 12. The peripheral adaptation method according to claim 1 is characterized in that there are two peripherals among the one or more peripherals that satisfy a preset logical relationship, and the device type, model and device parameter fields of each of the two peripherals in the first analysis result are determined based on the preset logical relationship, and the preset logical relationship is a master-slave relationship, a mirror relationship or a parallel relationship. 13. A computer device, characterized in that the computer device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 12 when executing the computer program. 14. A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer instructions, and when the computer instructions are executed on a computer device, the computer device is enabled to execute the method according to any one of claims 1 to 12.