Driving method of off-chip chip and related device

Abstract

The invention discloses a driving method of an off-chip chip and a related device, and relates to the technical field of chip driving, the method comprises the following steps: after a driving program of the off-chip chip obtains a driving task of the off-chip chip, caching the driving task to a target buffer area; when it is determined that the calling moment for calling the target function in the driving program arrives according to the set function calling period, the target function is started; in the first function calling period, the driving task is obtained from the target buffer area through the target function, the obtained driving task is transmitted to a communication module, and the communication module is used for transmitting the driving task to an off-chip chip; in the second function calling period, the task transmission state of the driving task is inquired from the communication module through the target function, and the task transmission state is used for representing whether the communication module completes transmission of the driving task or not. According to the scheme provided by the invention, the resource consumption generated by driving the off-chip chip can be reduced.

Description

Technical Field

[0001] This application relates to the field of chip driver technology, and in particular to a driving method and related apparatus for an off-chip chip. Background Technology

[0002] In embedded systems of vehicles or computer equipment, chips other than the microcontroller unit (MCU) are called off-chip chips (also known as peripheral chips). For example, in an embedded system for a vehicle, in addition to the MCU chip, there are also off-chip chips such as sensor processing chips and charging control chips.

[0003] Running a driver program for an external chip on an MCU enables the external chip to function. The driver program transmits the driving task to the external chip via the MCU's communication module and only exits or continues processing the next driving task after confirming successful transmission. However, the driver program spends a considerable amount of time waiting for each driving task transmission, leaving it in a meaningless waiting state and resulting in wasted resources. Summary of the Invention

[0004] In view of the above problems, this application provides a method and related apparatus for driving off-chip chips to reduce the resource consumption generated by driving off-chip chips.

[0005] On the one hand, this application provides a method for driving an off-chip chip, including:

[0006] After the driver of the off-chip obtains the driver task of the off-chip, it caches the driver task in the target buffer. The driver includes a target function.

[0007] When the time for calling the target function is determined according to the set function call cycle, the target function is started;

[0008] In the first function call cycle, the driver task is obtained from the target buffer through the target function, and the obtained driver task is transmitted to the communication module, wherein the communication module is used to transmit the driver task to the off-chip chip;

[0009] During the second function call cycle, the target function queries the communication module for the task transmission status of the driving task. The task transmission status is used to indicate whether the communication module has completed the transmission of the driving task.

[0010] In one possible implementation, the step of retrieving the driver task from the target buffer through the target function in the first function call cycle and transmitting the retrieved driver task to the communication module includes:

[0011] If the target function is in an idle state during the current function call cycle, the target function retrieves the driving task from the target buffer, transmits the retrieved driving task to the communication module, and marks the task processing state of the target function as a task transmission waiting state.

[0012] In the second function call cycle, querying the task transmission status of the driving task from the communication module through the target function includes:

[0013] If the target function is in a task transmission waiting state during the current function call cycle, the target function queries the communication module for the task transmission status of the driving task.

[0014] In another possible implementation, after querying the task transmission status of the driving task from the communication module via the objective function, the method further includes:

[0015] If the transmission completion status of the driving task indicates that the communication module has completed the transmission of the driving task, the task processing status of the objective function is marked as idle.

[0016] In another possible implementation, after querying the task transmission status of the driving task from the communication module via the objective function, the method further includes:

[0017] If the transmission completion status of the driving task indicates that the communication module has not yet completed the transmission of the driving task, the task processing status of the objective function is maintained in the task transmission waiting state, and the execution of the objective function is terminated.

[0018] In another possible implementation, the step of obtaining the driver task from the target buffer through the target function and transmitting the obtained driver task to the communication module includes:

[0019] If the target buffer contains multiple driving tasks, the target function retrieves the target driving task that appears first in the target buffer according to the order of the multiple driving tasks, and transmits the target driving task to the communication module.

[0020] In another possible implementation, the step of retrieving the driving task from the target buffer through the target function if the target function is in an idle state during the current function call cycle includes:

[0021] If the target function is in an idle state during the current function call cycle, and there is a driver task to be processed in the target buffer, the driver task is obtained from the target buffer through the target function;

[0022] After starting the target function, the following is also included:

[0023] If the target function is in an idle state during the current function call cycle and there are no pending driver tasks in the target buffer, the fault diagnosis task or register refresh task configured in the target function is executed through the target function.

[0024] In another possible implementation, after caching the driver task into the target buffer, the method further includes: if there are no other driver tasks corresponding to the off-chip chip to be cached into the target buffer, the operation of the driver program is terminated;

[0025] After transmitting the acquired driving task to the communication module, the process also includes: ending the execution of the target function.

[0026] In another aspect, this application also provides a driving device for an off-chip, comprising:

[0027] A task caching unit is used to cache the driver task of the off-chip chip into a target buffer after the driver of the off-chip chip obtains the driver task of the off-chip chip, wherein the driver includes a target function;

[0028] A periodic startup unit is used to start the target function when the call time for calling the target function is determined according to a set function call cycle;

[0029] The task transmission unit is used to obtain the driving task from the target buffer through the target function in the first function call cycle, and transmit the obtained driving task to the communication module, wherein the communication module is used to transmit the driving task to the off-chip chip;

[0030] The status query unit is used to query the task transmission status of the driving task from the communication module through the target function in the second function call cycle. The task transmission status is used to characterize whether the communication module has completed the transmission of the driving task.

[0031] In another aspect, this application also provides an in-vehicle terminal, including: a microcontroller unit, a memory, and at least one off-chip chip;

[0032] The microcontroller unit integrates or is connected to a communication module, and the communication module has a communication connection with the off-chip chip.

[0033] The microcontroller unit is used to execute the off-chip driving method described in any of the above descriptions;

[0034] The memory is used to store the programs required for the microcontroller to perform operations.

[0035] In another aspect, this application also provides a computer-readable storage medium carrying one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the off-chip driving method as described in any of the above claims.

[0036] As can be seen from the above, in this application, after obtaining the driver task for the off-chip chip, the driver only needs to cache the driver task in the target buffer, thus eliminating the need for continuous driver execution. Furthermore, the periodically called target function can execute operations such as transmitting the driver task in the target buffer to the communication module and checking whether the driver task has been transmitted successfully within different function call cycles. This eliminates the need for the target function to continue running after transmitting the driver task to the communication module, naturally reducing the resources consumed by running functions or programs, and consequently reducing resource waste caused by meaningless waiting for the driver task to complete. Attached Figure Description

[0037] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0038] Figure 1 A schematic flowchart of the off-chip driving method provided in this application;

[0039] Figure 2 This is another flowchart illustrating the off-chip driving method provided in this application;

[0040] Figure 3 This is another flowchart illustrating the off-chip driving method provided in this application;

[0041] Figure 4 This is an example diagram illustrating the implementation framework of the solution in this application scenario;

[0042] Figure 5 A schematic diagram of the composition structure of the off-chip driving device provided in this application;

[0043] Figure 6This is a schematic diagram of one possible architecture of the vehicle-mounted terminal provided in this application. Detailed Implementation

[0044] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is only for explaining specific embodiments and is not intended to limit the application. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0045] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0046] The solution proposed in this application is applicable to embedded systems in vehicle terminals or other computer devices, thereby reducing the resources required to drive off-chip chips in embedded systems.

[0047] An embedded system consists of hardware and software and is a system capable of operating independently. The software in an embedded system includes the software runtime environment and its operating system. The hardware includes signal processors, memory, communication modules, etc. The software program in an embedded system generally follows the hardware design; therefore, once the embedded system is deployed to a corresponding device, it is very difficult to modify it.

[0048] For example, taking an embedded system in a vehicle as an example, an embedded system in a vehicle is a distributed computing system formed by interconnecting electronic control units (ECUs) through an in-vehicle network, using ECUs as the basic unit. It is used to perform specific tasks such as vehicle power control, safety monitoring, and infotainment. Based on this, the electronic control unit (ECU) can be seen as a specific application of embedded systems in the vehicle field. An ECU can consist of a microcontroller unit (MCU), memory, input / output interfaces, etc.

[0049] Of course, this is just an example of an embedded system in a vehicle; for embedded systems used in other computer devices, the MCU can be replaced by a CPU, and so on, so I will not go into details.

[0050] The following section, with reference to the flowchart, describes the driving method for the off-chip chip in this application.

[0051] like Figure 1 This illustration shows a flowchart of an off-chip driving method provided in this application. This embodiment can be applied to vehicle terminals or computer devices with embedded systems deployed. For example, taking a vehicle terminal as an example, the method of this embodiment can be executed by an MCU.

[0052] The method in this embodiment may include:

[0053] S101: After the driver of the external chip obtains the driver task of the external chip, it caches the driver task in the target buffer.

[0054] Among them, the off-chip driver task is the task used to drive the off-chip chip to start and instruct the off-chip chip to perform operations.

[0055] It is understandable that the driving tasks for different types of off-chip chips will vary. Even for the same off-chip chip, the driving tasks will differ at different times because the operations required to be performed by the chip vary.

[0056] For example, to facilitate understanding, let's take an off-chip charging control chip in the vehicle that can communicate with the charging station as an example. This charging control chip can be a physical layer chip (PHY). In this case, the driver program for the charging control chip can drive tasks such as initializing the charging control chip, upgrading firmware, charging at the charging station, or verifying the vehicle identification code.

[0057] In this application, there are no restrictions on the specific method by which the driver obtains the driving task for the off-chip chip. For example, the driver may determine the existence of the driving task for the off-chip chip through the MCU or CPU of the embedded system, or it may obtain the driving task by triggering the driver in other ways.

[0058] Let's take the embedded system in the vehicle terminal as an example:

[0059] After the MCU in the vehicle terminal detects a task requiring the activation of an external chip via the upper-layer application, it calls the driver program for that external chip and issues the driver task, thus enabling the driver program to obtain the driver task for that external chip. Additionally, the driver program actively polls for level changes on pins related to the external chip; if a level change is detected, it confirms that it has obtained the corresponding driver task.

[0060] The target buffer can be a pre-specified storage area used to cache driving tasks. For example, in an embedded system in an in-vehicle terminal, a portion of the MCU's storage area can be designated as the target buffer.

[0061] In this application, after the driver of the off-chip obtains the driver task, it only needs to store the driver task in the target buffer, without waiting for the driver task to be transmitted to the off-chip, that is, it does not need to wait for the communication of this driver task to be completed.

[0062] Furthermore, after the driver stores the driver task in the target buffer, if there are no other driver tasks corresponding to the off-chip chip to be cached in the target buffer, the driver can terminate its operation. Of course, if there are other driver tasks for the off-chip chip, there is no need to wait for the driver task to be successfully transferred to the off-chip chip before proceeding to step S102, and finally all driver tasks are stored in the target buffer.

[0063] In this application, the driver includes an objective function.

[0064] S102, when the call time of the target function in the calling driver is determined according to the set function call cycle, the target function is started.

[0065] The objective function is a function that can be called periodically. For example, the objective function could be the main function that is currently built into the driver and is used for fault diagnosis of external chips.

[0066] Understandably, since the target function can be called and started periodically, step S102 can be executed multiple times. Based on this, the MCU or CPU will periodically call and start the target function according to its corresponding function call cycle.

[0067] S103, in the first function call cycle, the target function obtains the driver task from the target buffer and transmits the obtained driver task to the communication module.

[0068] The communication module is used to transmit the driving task to the external chip. The communication module has a communication connection with the external chip. Based on this, after the objective function transmits the driving task to the communication module, the communication module will execute the operation of transmitting the driving task to the external chip.

[0069] In this application, the communication module can be a communication module integrated within the MCU or CPU of an embedded system. For example, taking the embedded system on an in-vehicle terminal as an example, the MCU can integrate a communication module that supports communication methods such as Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I2C), or Reduced Media Independent Interface (RMII). Of course, this communication module can also be a communication module connected to the MCU or CPU, and there are no specific limitations.

[0070] In this application, after the target function is called and started in the first function call cycle, the target function only needs to execute the driving task retrieved from the target buffer and transmit it to the communication module, without waiting for the communication module to completely transmit the driving task to the off-chip.

[0071] Therefore, after the objective function transmits the acquired driving task to the communication module, the execution of the objective function can be terminated.

[0072] S104, in the second function call cycle, the target function queries the communication module for the task transmission status of the driving task.

[0073] In the application, the task transmission status of the driver task is used to characterize whether the communication module has completed the transmission of the driver task. Specifically, the communication module completing the transmission of the driver task means that it has successfully transmitted the driver task to the external chip.

[0074] In this application, for ease of distinction, the function call cycle in which the target function transmits the driving task to the communication module is referred to as the first function call cycle, while the function call cycle in which the target function queries the communication module for the task transmission status of the driving task is referred to as the second function call cycle. It is evident that the second function call cycle differs from the first function call cycle; for the same driving task, the second function call cycle can be a function call cycle following the first function call cycle.

[0075] Of course, considering that the communication module may need a period of time to transmit the driving task, in this application, there may be multiple second function call cycles, and the multiple second function call cycles are multiple consecutive function call cycles located after the first function call cycle.

[0076] For example, after starting the target function, if the target buffer contains the driver task for the off-chip, and the target function confirms that there are no driver tasks yet to be completed, then the current function call cycle is determined to be the first function call cycle. The target function will then retrieve the driver task from the target buffer and transmit it to the communication module. Conversely, if the target function, after starting, confirms that there are driver tasks waiting to be completed, then the current function call cycle is determined to be the second function call cycle, and the target function can then query the task transmission status from the communication module.

[0077] As can be seen, the objective function can transmit the driving task to the communication module and query the task transmission status of the driving task in different function call cycles. Therefore, after the objective function transmits the driving task to the communication module, the objective function does not need to wait for the driving task to complete the transmission. It only needs to check whether the driving task has been transmitted when the objective function is started again. Thus, the objective function does not need to run continuously and wait for the driving task to be transmitted.

[0078] In this application, the communication module can maintain the task transmission status of the driving task in various ways, without any specific limitation. For example, if the communication module has successfully transmitted the driving task to the external chip, the communication module can set the task transmission status of the driving task to 1. Therefore, a task transmission status of 1 indicates that the transmission of the driving task has been completed. Conversely, if the driving task has not yet been successfully transmitted to the external chip, the task transmission status can be set to 0.

[0079] As can be seen from the above, in this application, after obtaining the driver task for the off-chip chip, the driver only needs to cache the driver task in the target buffer, thus eliminating the need for continuous driver execution. Furthermore, the periodically called target function can execute operations such as transmitting the driver task in the target buffer to the communication module and checking whether the driver task has been transmitted successfully within different function call cycles. This eliminates the need for the target function to continue running after transmitting the driver task to the communication module, naturally reducing the resources consumed by running functions or programs, and consequently reducing resource waste caused by meaningless waiting for the driver task to complete.

[0080] In addition, considering that there are generally detection functions in drivers for detecting whether there is a fault in the off-chip, this application can reuse the detection function as the target function, thereby reducing the number of functions that need to be started periodically and further reducing resource consumption.

[0081] Understandably, the driver for an off-chip chip may receive multiple driver tasks for that off-chip chip within a short period of time. Based on this, the driver can store each driver task sequentially into the target buffer. Accordingly, the target buffer may contain multiple drivers.

[0082] Therefore, after starting the target function, if multiple drivers exist in the target buffer, the target function can retrieve the earliest-order target driver task from the target buffer according to the order of these driver tasks and transmit that target driver task to the communication module. Correspondingly, the communication module will transmit the target driver task to the off-chip chip.

[0083] Based on this, during the second function call cycle, the target function can query the communication module for the task transmission status of the target-driven task. Similarly, the task transmission status of the target-driven task indicates whether the communication module has completed the transmission of the target-driven task.

[0084] Based on any of the above embodiments of this application, in order to make it easier to determine whether the current function call cycle is the first function call cycle or the second function call cycle after the target function starts, the target function can also maintain its own task processing state. The task processing state is used to determine whether the target function is currently in an idle state or in a state waiting for the driver task to complete transmission. The following is in conjunction with... Figure 2 Please provide an explanation.

[0085] like Figure 2 This illustrates another flowchart of the off-chip driving method provided in this application. The method in this embodiment may include:

[0086] S201: After the driver of the external chip obtains the driver task of the external chip, it caches the driver task in the target buffer.

[0087] S202, when the time for calling the target function in the calling driver is determined according to the set function call cycle, the target function is started.

[0088] The above steps S201 and S202 can be found in the relevant descriptions of the previous embodiments, and will not be repeated here.

[0089] S203, if the target function is in an idle state during the current function call cycle, the target function obtains the driving task from the target buffer, transmits the obtained driving task to the communication module, and marks the target function's task processing state as a task transmission waiting state.

[0090] The communication module is used to transmit the driving task to the off-chip chip.

[0091] The fact that the objective function is in an idle state indicates that the objective function is not waiting for the driver task to be transmitted. Therefore, the objective function can directly obtain the driver task from the target buffer and transmit it to the communication module.

[0092] Similarly, after the objective function transmits the driver task to the communication module, since the driver task needs to be transmitted to the external chip to complete the external chip driving, the objective function needs to change the task transmission status from idle to task transmission waiting state in order to continue querying the task transmission status. The task transmission waiting state indicates that the objective function is waiting for the driver task to complete.

[0093] The objective function can maintain its corresponding task processing state by storing it in a state machine in a specified area. Of course, other methods can also be used to maintain the task processing state without restriction.

[0094] It is understandable that after marking the task processing status of the target function as the task transmission waiting state, the operations that the target function needs to perform in the current function call cycle have been completed. Therefore, the execution of the target function can be terminated, such as the target function voluntarily terminating its own execution.

[0095] S204, if the task processing status of the target function in the current function call cycle is a task transmission waiting state, query the task transmission status of the driving task from the communication module through the target function.

[0096] The task transmission status is used to characterize whether the objective function has completed the transmission of the driving task.

[0097] Understandably, if the target function's task processing status is "task transmission waiting" after starting in the current function call cycle, it means that the target function has already transmitted the driver task to the communication module before the current function call cycle, and it needs to confirm whether the driver task has been transmitted to the off-chip. Therefore, when the target function is in the task transmission waiting state, it can query the communication module for the task transmission status of the driver task.

[0098] In this embodiment, by maintaining the task processing status, the objective function can efficiently determine whether the current function call cycle is a function call cycle that needs to transmit the driving task or a function call cycle that needs to query the driving task transmission status, thereby enabling more reasonable and efficient control of the transmission of the driving task to the off-chip chip.

[0099] Understandably, if the driver task has been successfully transmitted to the external chip, it indicates that the transmission of the driver task is complete. Therefore, in subsequent function call cycles, the target function does not need to continue querying whether the driver task has been transmitted successfully and can continue to execute the transmission of other driver tasks or perform other task processing. Based on this, in one possible implementation, after querying the task transmission status of the driver task from the communication module through the target function, if the transmission completion status of the driver task indicates that the communication module has completed the transmission of the driver task, the task processing status of the target function can be marked as idle.

[0100] Furthermore, after querying the task transmission status of the driving task from the communication module through the objective function, if the transmission completion status of the driving task indicates that the communication module has not yet completed the transmission of the driving task, the task processing status of the objective function can be maintained as the task transmission waiting state, and the execution of the objective function can be terminated so that the task transmission status of the driving task can be queried again after the objective function is started in the next function call cycle.

[0101] In this embodiment, if the target function is in an idle state during the current function call cycle, then the current function call cycle is the first function call cycle. If the target function is in a task transmission waiting state during the current function call cycle, then the current function call cycle is the second function call cycle.

[0102] Understandably, since the target function in the driver for an off-chip chip can reuse the function in the driver responsible for fault diagnosis of the off-chip chip, the target function itself can also be configured with one or both fault diagnosis tasks and register refresh tasks. Based on this, this application can set the priority of the driver task to the highest priority. Therefore, after the target function is started, if the target function is in an idle state, it will first check whether there is a driver task in the target buffer.

[0103] Specifically, after the target function starts, if the target function is in an idle state during the current function call cycle and there are driver tasks to be processed in the target buffer, the target function retrieves the driver tasks from the target buffer and transmits the retrieved driver tasks to the communication module.

[0104] Correspondingly, if the target function is in an idle state during the current function call cycle and there are no pending driver tasks in the target buffer, the fault diagnosis task or register refresh task configured in the target function is executed through the target function.

[0105] Among them, the fault diagnosis task is used to detect whether there is a fault in the off-chip. For example, off-chip chips all integrate fault registers, which can store fault information of the off-chip. Based on this, the target function in the driver of the off-chip can periodically access the fault register to detect whether there is a fault in the off-chip.

[0106] In addition, to prevent unexpected changes or other anomalies from the fault registers and control registers of the off-chip chip, the objective function also needs to periodically access each register to refresh the registers, i.e., to perform register refresh tasks.

[0107] To facilitate understanding of the specific implementation and benefits of this application, the following section uses an embedded system in an in-vehicle terminal as an example to introduce the driving method for off-chip chips, combining one implementation approach. For example... Figure 3 This illustrates another flowchart of the off-chip driving method provided in this application. The method of this embodiment can be applied to the MCU in the vehicle terminal, that is, the MCU in the embedded system of the vehicle terminal.

[0108] This embodiment may include the following steps:

[0109] S301: After the driver of the external chip obtains the driver task of the external chip, it caches the driver task in the target buffer.

[0110] S302: When the call time of the target function in the call driver is determined according to the set function call cycle, the MCU starts the target function.

[0111] S303: After the target function starts, if the task processing state of the target function is idle in the current function call cycle and there is a driver task to be processed in the target buffer, the target function obtains the driver task from the target buffer, transmits the obtained driver task to the communication module, marks the task processing state of the target function as the task transmission waiting state, and ends the execution of the target function.

[0112] S304: After the target function starts, if the target function is in an idle state during the current function call cycle and there are no pending driver tasks in the target buffer, the configured fault diagnosis task or register refresh task is executed through the target function.

[0113] In this application, the target function performing fault diagnosis or register refresh tasks may not require access to the external chip or its registers via the communication module. Accordingly, during the execution of any fault diagnosis or register refresh task, the target function's task processing state can be set to a non-idle state, such as fault diagnosis or register refresh, to allow for continued querying of the task execution status in subsequent function call cycles. After confirming the completion of the fault diagnosis or register refresh task, the target function can also set its task processing state to an idle state. Of course, this application does not impose restrictions on the specific implementation process for handling these two tasks.

[0114] S305: After the target function starts, if the task processing status of the target function in the current function call cycle is in the task transmission waiting state, the target function queries the communication module for the task transmission status of the driving task.

[0115] S306, if the transmission completion status of the driving task indicates that the objective function has completed the transmission of the driving task, mark the task processing status of the objective function as idle and end the execution of the objective function.

[0116] S307, if the transmission completion status of the driving task indicates that the objective function has not yet completed the transmission of the driving task, maintain the task processing status of the objective function as the task transmission waiting state and end the execution of the objective function.

[0117] Understandably, after steps S306 and S307, the MCU can continue to execute step S302 in order to periodically call the target function.

[0118] To facilitate understanding, we will use the SPI communication module of the MCU as an example:

[0119] The driver program for the off-chip chip in the MCU includes a target function, which can be called and started periodically.

[0120] like Figure 4 As shown, the tasks that the objective function can execute can include three types: event tasks for sending drive tasks, diagnostic tasks for external chips (equivalent to fault diagnosis tasks), and refresh tasks for refreshing the registers of external chips (relative to register refresh tasks).

[0121] After each call to the target function, the target function will first check whether its task processing status is idle.

[0122] If the target function is idle, it can check for any pending driver tasks, prioritizing those with the highest priority. If a pending driver task exists, an event task is executed, which retrieves the driver task and transmits it to the communication module for transmission to the external chip. If the target function is idle and no pending driver task exists, a diagnostic or refresh task can be transmitted to the SPI communication module via the communication module. This allows the SPI communication module to access the external chip for fault diagnosis or register refresh.

[0123] Understandably, after the target function transmits any of the three tasks mentioned above to the SPI communication module, it needs to switch the task processing state of the target function from the idle state to the task waiting state corresponding to the task. For example, taking the task as an event task, the target function needs to switch from the idle state to the task transmission waiting state of the driving task. Then, the target function can exit execution.

[0124] If the target function is in a task waiting to be completed state after it starts, it will query the SPI communication module to see if the corresponding task has been transmitted.

[0125] like Figure 4 As shown, after transmitting the corresponding task to the external chip, the SPI communication module also checks the transmission status of the corresponding task. If the task transmission is complete, the SPI communication module will be in an idle state, at which point the target function will also detect that the corresponding task has been transmitted. Accordingly, the target function will switch its waiting-for-task-complete state to an idle state.

[0126] Specifically, considering that the communication module may be unable to transmit the driver task to the external chip for an extended period due to external chip malfunction or other abnormalities, to reduce unnecessary resource consumption, if the communication module fails to transmit the driver task to the external chip for a set period, it will confirm that the driver task transmission has timed out and will not continue to transmit the driver task. Based on this, if the objective function detects that a driver task or other task transmission has timed out, the objective function can retransmit the driver task or other task; details will not be elaborated further.

[0127] If the SPI communication module detects that the task is still in the transmission state, the target function will end its execution first, and then continue to query the transmission completion status of the task after the next function call cycle starts.

[0128] Research revealed that if the currently common method of linear communication between the driver and the external chip is used, the driver must wait for the task to be successfully transmitted to the chip after each transmission via the communication module before confirming the completion of the current driver operation. For example, assuming a 1MHz SPI communication module is used to transmit 5 bytes of data, the time spent waiting for the SPI module to complete the transmission exceeds 40µs. During this waiting period, the MCU still needs to continuously run the driver, and this pointless waiting by the driver inevitably increases the MCU's resource consumption.

[0129] Taking a 200MHz MCU driving an Ethernet chip using a 1MHz SPI communication module as an example, if a traditional linear off-chip driver is used, the load rate during a 100ms call cycle reaches a maximum of 12.5%, meaning the code executes for a maximum of 12.5ms. The off-chip driver implemented using the scheme in this application achieves a maximum load rate of only 0.43% during a 100ms call cycle, meaning the code executes for a maximum of 43µs. This represents a 290-fold reduction in code execution time, resulting in a 29-fold reduction in load rate.

[0130] certainly, Figure 3 and Figure 4 This example only uses an embedded system on an in-vehicle terminal; it is equally applicable to other embedded systems and will not be elaborated further.

[0131] Corresponding to the off-chip driving method provided in this application, this application also provides an off-chip driving device. For example... Figure 5 This illustration shows a schematic diagram of the composition structure of an off-chip driving device provided in this application. The device in this embodiment may include:

[0132] The task caching unit 501 is used to cache the driver task of the off-chip chip into a target buffer after the driver of the off-chip chip obtains the driver task of the off-chip chip, wherein the driver includes a target function.

[0133] The periodic startup unit 502 is used to start the target function when the call time for calling the target function is determined according to the set function call cycle;

[0134] The task transmission unit 503 is used to obtain the driving task from the target buffer through the target function in the first function call cycle, and transmit the obtained driving task to the communication module, wherein the communication module is used to transmit the driving task to the off-chip chip;

[0135] The status query unit 504 is used to query the task transmission status of the driving task from the communication module through the target function in the second function call cycle. The task transmission status is used to characterize whether the communication module has completed the transmission of the driving task.

[0136] In one possible implementation, the task transmission unit includes:

[0137] The task transmission subunit is used to obtain the driving task from the target buffer through the target function if the task processing state of the target function is idle in the current function call cycle, transmit the obtained driving task to the communication module, and mark the task processing state of the target function as a task transmission waiting state.

[0138] This status query unit includes:

[0139] The status query subunit is used to query the task transmission status of the driving task from the communication module through the target function if the task processing status of the target function in the current function call cycle is a task transmission waiting state.

[0140] In yet another possible implementation, the device further includes:

[0141] The state change unit is used to mark the task processing state of the objective function as idle state after the state query subunit queries the task transmission status of the driving task from the communication module through the objective function, if the transmission completion status of the driving task indicates that the communication module has completed the transmission of the driving task.

[0142] In yet another possible implementation, the device further includes:

[0143] The state maintenance unit is used to maintain the task processing state of the objective function as a task transmission waiting state and terminate the operation of the objective function if the transmission completion state of the driving task indicates that the communication module has not yet completed the transmission of the driving task after the state query subunit queries the task transmission status of the driving task from the communication module through the objective function.

[0144] In yet another possible implementation, the task transmission unit includes:

[0145] The multi-task transmission subunit is used to, if there are multiple driving tasks in the target buffer, obtain the target driving task with the earliest order from the target buffer through the target function according to the order of the multiple driving tasks, and transmit the target driving task to the communication module.

[0146] In another possible implementation, the task transmission subunit is specifically configured to obtain the driving task from the target buffer through the target function if the target function is in an idle state during the current function call cycle and there is a driving task to be processed in the target buffer.

[0147] The device further includes a task processing unit, which, after the periodic startup unit starts the target function, if the target function is in an idle state during the current function call cycle and there are no pending driver tasks in the target buffer, executes a fault diagnosis task or a register refresh task configured in the target function through the target function.

[0148] In another possible implementation, the device further includes: a program termination unit, configured to terminate the operation of the driver program if there are no other driver tasks corresponding to the off-chip chip to be cached in the target buffer after the task mixing unit caches the driver task in the target buffer;

[0149] The function termination unit is used to terminate the execution of the target function after the task transmission unit transmits the acquired driving task to the communication module.

[0150] Furthermore, this application also provides a vehicle-mounted terminal. For example... Figure 6 The diagram shows a structural composition of the vehicle-mounted terminal provided in this application.

[0151] Depend on Figure 6 It can be seen that the vehicle terminal includes: a microcontroller unit 601, a memory 602, and at least one off-chip chip 603.

[0152] The microcontroller unit integrates or is connected to a communication module (not shown in the figure), and the communication module has a communication connection with the off-chip 603;

[0153] The microcontroller unit 601 is used to execute the off-chip driving method described in any of the above embodiments;

[0154] The memory 602 is used to store the programs required for the microcontroller to perform operations.

[0155] Of course, the vehicle-mounted terminal can also include other components, without any restrictions.

[0156] In another aspect, this application also provides a computer-readable storage medium carrying one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the off-chip driving method as described in any of the above embodiments.

[0157] In another aspect, this application also provides a computer program product, including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the off-chip driving methods provided in this application.

[0158] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0159] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0160] In the above embodiments, the implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product.

[0161] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method of driving an off-chip chip, characterized by, The application relates to a method for driving an off-chip chip, and the method comprises the following steps: after a driving program of the off-chip chip obtains a driving task of the off-chip chip, the driving task is cached to a target buffer, and the driving program comprises a target function; when an invoking moment of calling the target function is determined according to a set function calling period, the target function is started; in a first function calling period, the target function is used to acquire the driving task from the target buffer, and the acquired driving task is transmitted to a communication module, wherein the communication module is used to transmit the driving task to the off-chip chip; in a second function calling period, the target function is used to query a task transmission state of the driving task from the communication module, and the task transmission state is used to represent whether the communication module has completed transmission of the driving task.

2. The off-chip chip driving method according to claim 1, wherein in the first function calling period, the target function is used to acquire the driving task from the target buffer, and the acquired driving task is transmitted to the communication module, and the task processing state of the target function is marked as a task transmission waiting state; in the second function calling period, the target function is used to query the task transmission state of the driving task from the communication module. after the target function is used to query the task transmission state of the driving task from the communication module, the method further comprises the following steps: if the transmission completion state of the driving task represents that the communication module has completed transmission of the driving task, the task processing state of the target function is marked as an idle state.

3. The method of driving an off-chip chip according to claim 2, wherein after the target function is used to query the task transmission state of the driving task from the communication module, the method further comprises the following steps: if the transmission completion state of the driving task represents that the communication module has not completed transmission of the driving task, the task processing state of the target function is maintained as the task transmission waiting state, and the running of the target function is ended.

4. The method of driving an off-chip chip according to claim 3, wherein the target function is used to acquire the driving task from the target buffer, and the acquired driving task is transmitted to the communication module, and the method comprises the following steps: if there are multiple driving tasks in the target buffer, the target function is used to acquire a target driving task in a frontmost order from the target buffer according to the order of the multiple driving tasks, and the target driving task is transmitted to the communication module.

5. The method of driving an off-chip chip according to claim 2, wherein if the task processing state of the target function in the current function calling period is an idle state, the target function is used to acquire the driving task from the target buffer, and the method comprises the following steps: if the task processing state of the target function in the current function calling period is an idle state, and there is a driving task to be processed in the target buffer, the target function is used to acquire the driving task from the target buffer.

6. The method of driving an off-chip chip according to claim 2, wherein ​ ​ After starting the target function, further comprising: If the target function is in an idle state in a current function call period, and there is no pending drive task in the target buffer, executing a fault diagnosis task or a register refresh task configured in the target function through the target function.

7. The method of driving an off-chip chip according to claim 1, wherein After the drive task is cached to the target buffer, further comprising: if there is no other drive task corresponding to the off-chip chip to be cached to the target buffer, ending the running of the drive program. After the obtained drive task is transmitted to the communication module, further comprising: ending the running of the target function.

8. An off-chip chip driving device, characterized by comprising: Comprising: a task caching unit, configured to cache a drive task of an off-chip chip to a target buffer after a drive program of the off-chip chip obtains the drive task, the drive program comprising a target function; a period starting unit, configured to start the target function when a call time of calling the target function is determined according to a set function call period; a task transmitting unit, configured to obtain the drive task from the target buffer through the target function in a first function call period, and transmit the obtained drive task to a communication module, wherein the communication module is configured to transmit the drive task to the off-chip chip; a state querying unit, configured to query a task transmission state of the drive task from the communication module through the target function in a second function call period, wherein the task transmission state is used to indicate whether the communication module has completed the transmission of the drive task.

9. A vehicle terminal, characterized by Comprising: a micro control unit, a memory and at least one off-chip chip; wherein the micro control unit is integrated with or connected to a communication module, and the communication module has a communication connection with the off-chip chip; the micro control unit is configured to execute the drive method of the off-chip chip as claimed in any one of claims 1 to 7; the memory is configured to store programs required by the micro control unit for operation.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium carries one or more computer programs, when the one or more computer programs are executed by an electronic device, the electronic device can implement the drive method of the off-chip chip as claimed in any one of claims 1 to 7.

Images