Board-level driving device and method compatible with MCAL specification, equipment and medium

Abstract

The invention relates to a board-level drive device, method, equipment and medium compatible with MCAL specification, by adopting a simple and clear board-level drive architecture design with distinct logic hierarchy, effectively meeting the ISO26262 function safety highest level requirement and being compatible with scenes using MCAL and non-MCAL, only one set of drive needs to be maintained and developed, the drive development period can be effectively shortened, and the development efficiency is improved. The code design fault rate is reduced, the drive maintenance work is reduced, and the MCU drive development and maintenance cost is saved.

Description

Technical Field

[0001] This invention belongs to the field of MCU driver technology and relates to a board-level driver device, method, apparatus and medium compatible with the MCAL specification. Background Technology

[0002] The Automotive Open System Architecture (AUTOSAR) is an open software architecture standard jointly developed by major global automakers, suppliers, and technology companies. It aims to address the increasingly complex challenges of automotive electronic systems. Its core objectives are: 1. Standardization: unifying software and hardware interfaces to reduce development complexity; 2. Modularization: supporting the reuse of software components and shortening development cycles; 3. Compatibility: ensuring seamless integration of software and hardware from different manufacturers; 4. Scalability: adapting to the evolution from traditional ECUs (Electronic Control Units) to high-performance computing platforms (such as domain controllers). The Micro-Controller Abstraction Layer (MCAL) is a layer in the AUTOSAR architecture. It primarily serves as the low-level driver for accessing MCU registers and internal peripherals, while simultaneously enabling upper-layer software (such as the ECU abstraction layer and system service layer) to be independent of the MCU hardware platform, ensuring the standardization and universality of upper-layer software.

[0003] A board-level driver package (BSP) refers to the low-level software driver package provided by an MCU vendor for its MCU products. The application layer of the AUTOSAR architecture uses this driver to access the corresponding functions of the MCU. The MCAL specification defines the required functions and interfaces for the board-level driver, ensuring compatibility with upper layers. However, not all users choose to use MCAL packages. Using MCAL packages has a high barrier to entry and is expensive. Furthermore, some application scenarios do not require an AUTOSAR OS system, so the driver package used does not need to comply with the MCAL specification. Currently, there is a lack of efficient and low-cost driver solutions that are compatible with both MCAL and non-MCAL specifications. Summary of the Invention

[0004] To address the problems existing in the above-mentioned traditional methods, this invention proposes a board-level driver device compatible with the MCAL specification, a board-level driver method for an MCU, a computer device, and a computationally readable storage medium, which can efficiently and cost-effectively support both MCAL and non-MCAL drivers.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: On the one hand, a board-level driver device compatible with the MCAL specification is provided. In the microcontroller abstraction layer of the basic software layer, the MCAL layer and the BSP layer are configured based on the AUTOSAR specification. The BSP layer is used to implement the basic functions required by the MCAL specification standard for the MCU, and the MCAL layer is used to implement the interfaces and logic required by the MCAL specification standard. The basic software layer is the BSW layer of the automotive open system architecture. The complex driver modules of the basic software layer include the CDD module developed using the BSP hierarchical architecture. The CDD module is used to implement functional modules of the MCU that do not use the MCAL specification standard.

[0006] On the other hand, a board-level driving method for an MCU is also provided, applied to the aforementioned board-level driving device compatible with the MCAL specification. This board-level driving method for the MCU includes the following steps: Obtain the software module to be driven from the MCU; When it is determined that the software module to be driven has a hardware IP for implementation, the pre-configured first board-level driver package is called to drive the software module. This first board-level driver package is configured in the microcontroller abstraction layer based on the AUTOSAR specification, including the MCAL layer and BSP layer. The BSP layer includes a hardware layer configured according to the IP and a BSP driver layer, while the MCAL layer includes the MCAL external interface layer. The software module to be driven is a standard module defined by the MCAL specification, and the difference between the functional requirements implemented by the software module in the BSP layer and the MCAL specification is less than a difference threshold. In another aspect, a computer device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the board-level driving method of the MCU described above.

[0007] Furthermore, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the aforementioned MCU board-level driving method.

[0008] One of the above technical solutions has the following advantages and beneficial effects: The aforementioned board-level driver devices, methods, equipment, and media that are compatible with the MCAL specification effectively meet the highest functional safety requirements of ISO26262 by adopting a board-level driver architecture design with clear logical hierarchy and simplicity. They are also compatible with scenarios using MCAL and non-MCAL. Only one driver needs to be maintained and developed, which can effectively shorten the driver development cycle, reduce code design failure rate, reduce driver maintenance work, and save MCU driver development and maintenance costs. Attached Figure Description

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

[0010] Figure 1 This is a schematic diagram of the driver architecture mapping for a board-level driver device that is compatible with the MCAL specification in one embodiment. Figure 2 This is a schematic diagram of a board-level driver package structure that is compatible with the MCAL specification in one embodiment; Figure 3 This is a flowchart illustrating the board-level driving method for an MCU in one embodiment; Figure 4 This is a schematic diagram of the board-level driver package design flow for a board-level driver method of an MCU in one embodiment. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention.

[0012] It should be noted that, in this document, the reference to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The presentation of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand that the embodiments described herein can be combined with other embodiments. The term "and / or" as used herein refers to any combination of one or more of the associated listed items, and all possible combinations, including such combinations.

[0013] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0014] The automotive open system architecture mainly consists of the Application Layer, the Runtime Environment (RTE) layer, and the Basic Software (BSW) layer. The Application Layer contains various automotive electronic application modules (such as engine control and body control programs), implementing specific functions in a modular manner and focusing on business logic development. The RTE layer, acting as middleware, is responsible for communication between application layer components and interaction between the application layer and the BSW layer, shielding application developers from underlying hardware differences and allowing them to focus on hardware details without needing to concern themselves with them.

[0015] The BSW layer comprises the Service Layer, ECU Abstract Layer, MCAL layer, and CDD (Complex Driver) module. The Service Layer provides various standardized service functions, such as diagnostic services (for vehicle fault detection and reporting), communication services (for handling upper-layer logic of protocols like CAN and Ethernet), and storage services (for managing data reading, writing, and persistence). These services are the core support modules of the automotive electronic system, providing standardized interfaces for upper-layer applications or other basic software components.

[0016] The ECU abstraction layer is used to abstract and encapsulate the hardware resources of the ECU, such as standardizing the drivers for microcontroller I / O ports, timers, and ADCs (analog-to-digital converters). The ECU abstraction layer shields the specific differences in hardware, allowing upper-layer service layers to call hardware functions through a unified interface without needing to concern themselves with hardware details, thus improving software portability.

[0017] The MCAL layer is the lowest layer of BSW, used to interact directly with the MCU hardware. Its core function is to encapsulate the driver logic of the MCU's internal peripherals, such as GPIO interfaces, CAN / LIN / Ethernet controllers, ADC / DAC conversion, PWM modulation, and SPI / I2C interfaces. It is strongly related to the specific MCU model and usually requires the chip manufacturer to provide an adapter. It is an "isolation layer" between the hardware and the upper-level software.

[0018] The CDD (Complex Driver) layer supplements the special hardware requirements not covered by the above three layers, handles complex hardware that cannot be fully abstracted by MCAL, and implements functions that have not yet been standardized by AUTOSAR (such as timing control of special sensors). Its interface must conform to the AUTOSAR specification, but the implementation can be customized by the user or the supplier, which is highly flexible.

[0019] Currently, there are two traditional types of MCU driver design: one is to design directly according to the MCAL specification, and the other is to implement the functionality based on the MCU hardware without considering the MCAL specification. This means that suppliers need to design two driver architectures and two sets of driver code, resulting in significant duplication of work. This leads to the need to develop and test two sets of drivers according to a process, and maintain two sets of drivers simultaneously. Furthermore, the driver packages provided by these suppliers lack hierarchical logic. For example, in MCAL driver packages, each module has only one level, consisting of only a single source code file (.c) and header file (.h). All code is integrated into a single file, lacking hierarchical structure and clear logical structure, making it prone to bugs when dealing with large amounts of code.

[0020] In one embodiment, such as Figure 1 As shown, a board-level driver device compatible with the MCAL specification is provided. In the microcontroller abstraction layer of the basic software layer, an MCAL layer and a BSP layer are configured based on the AUTOSAR specification. The BSP layer is used to implement the basic functions required by the MCU using the MCAL specification standard, while the MCAL layer is used to implement the interfaces and logic required by the MCAL specification standard. The basic software layer is the BSW layer of the automotive open system architecture. The complex driver modules of the basic software layer include CDD modules developed using the BSP layer architecture. The CDD modules are used to implement functional modules for which the MCU does not use the MCAL specification standard.

[0021] It is understood that this embodiment will provide a board-level driver architecture suitable for automotive MCU driver development. On the one hand, its driver logic is clearly hierarchical and meets the requirements of ISO26262 ASIL-D level; on the other hand, it is compatible with MCAL users and non-MCAL BSP users within a single driver architecture. The board-level driver architecture design is shown below, where ISO26262 ASIL-D is the industry standard for "Functional Safety of Road Vehicles".

[0022] To ensure compatibility with the AUTOSAR MCAL specification requirements, the mapping of the board-level driver architecture in the AUTOSAR specification is as follows: Figure 1As shown, modules required by the MCAL specification standard (such as ADC and SPI modules) can be divided into two main layers: the MCAL layer and the BSP layer. First, the basic functions are implemented in the BSP layer (such as, but not limited to, the ADC's function of initiating sampling of a specified channel, obtaining the result of a specified channel, and configuring channel cascading triggering). Then, an MCAL wrapper (i.e., MCAL Wrapper) is built on the BSP layer to implement the interfaces and logic required by the MCAL specification standard at this layer (such as, but not limited to, the ADC's function of configuring channel groups and initiating sampling, and obtaining the sampling result of channel groups). For modules that do not meet the MCAL standard requirements (i.e., non-Standard), such as UART modules (communication modules that convert between USB and serial communication protocols such as TTL / RS485), Sent modules (communication modules designed specifically for sensor data transmission, using a single-wire protocol, and supporting high-precision, low-power digital signal transmission), and Gtm modules (multi-channel timing control modules), they can be developed directly using the BSP-level architecture as CDD (Complex Driver) modules in AUTOSAR. The specific development implementation can be understood by referring to the existing CDD module development process in this field, according to the required functions. Figure 1 In this context, "Standard" refers to the MCAL specification, and "Driver" refers to the driver.

[0023] The aforementioned board-level driver device, which is compatible with the MCAL specification, adopts a board-level driver architecture design with a clear and simple logical hierarchy. It effectively meets the highest level of functional safety requirements of ISO26262 while being compatible with both MCAL and non-MCAL scenarios. Only one driver needs to be maintained and developed, which can effectively shorten the driver development cycle, reduce code design failure rate, reduce driver maintenance work, and save MCU driver development and maintenance costs.

[0024] In one embodiment, the BSP layer includes a hardware layer and a BSP driver layer. The hardware layer is used to interact with the MCU hardware and operate the hardware registers, while the BSP driver layer is the external interface layer of the BSP layer.

[0025] It is understandable that the BSP layer and MCAL layer are divided into hierarchical levels, such as... Figure 2 As shown, the BSP layer includes a hardware layer (denoted as...).<Module_Hw> Level), Hardware Abstraction Layer (hereinafter referred to as Level),<Module_Hal> Level) and BSP driver layer (denoted as Level)<Module_Drv> Level).

[0026] in,<Module_Hw> The Level layer is used to interact with the MCU hardware and operate the corresponding hardware registers at this level.

[0027] Furthermore, the BSP layer also includes a hardware abstraction layer, which is used to identify the hardware IP required to process the current task.

[0028] Understandable.<Module_Hal> The Level layer can exist or be omitted depending on the choice of hardware implementation. For example, when a software module can be implemented by two different hardware modules, the corresponding implementation logic is handled by the hardware abstraction layer. For example, the UART function can be implemented by the hardware UART IP or the hardware LIN IP. In this case, the hardware abstraction layer exists and is used to identify which hardware IP should be used to process the current task.

[0029] <Module_Drv> The Level layer is the external interface layer of the BSP layer. When users do not need to use the MCAL driver, only the BSP layer needs to be maintained, and the MCAL layer can be left unpublished to users (discarded).

[0030] In one embodiment, the MCAL layer includes an MCAL external interface layer, which is the external interface of MCAL.

[0031] like Figure 2 As shown, the MCAL layer includes the MCAL logic processing layer (denoted as...).<Module_Sar> Level) and MCAL external interface layer (denoted as Level) <module>Level).

[0032] Furthermore, the MCAL layer also includes the MCAL logic processing layer, which is used to implement the logic defined by the MCAL specification by calling the interface of the BSP driver layer.

[0033] Understandable.<Module_Sar> The Level layer is primarily used to implement the logic defined in the MCAL specification, through calling...<Module_Drv> Taking the ADC as an example again, the interface implementation at the Level layer works on a channel-group basis, while the BSP driver layer configures on a single channel-by-channel basis.<Module_Sar> The Level layer combines specified channels of a channel group according to the interface configuration. For example, if the interface defines channel group 1 as containing channels 0-1-2-3, then...<Module_Sar> The Level layer needs to be configured to cascade triggering between channels 0-1-2-3, configure interrupt enable function for channel 3, and initiate sampling for channel 0. Additionally, it may be necessary to interrupt sampling upon completion and store the sampled data in the specified data format.<Module_Sar> The level layer can also be included or omitted depending on the complexity of the module's logic. For example, it may not be necessary to implement a module with relatively simple logic.<Module_Sar> Level layer, can be accessed through <module>Level layer direct call<Module_Drv> The interface implementation for the Level layer is sufficient.

[0034] <module>Level is the external interface layer of MCAL. When a user uses the MCAL driver, they call this layer. <module>The Level layer interfaces are used for application implementation.

[0035] Thus, by adopting the aforementioned board-level driver design with its clear logical hierarchy and simple, straightforward structure, it meets the requirements of the ISO26262 ASIL-D standard while reducing the failure rate. Even with significant changes in the MCU hardware, only the lowest-level logic of the hardware layer needs to be modified, without affecting the upper-level content. The board-level driver architecture has strong reusability. A single driver can be compatible with both MCAL and non-MCAL users. For non-MCAL scenarios, only the BSP layer needs to be released to the user, without the need to develop another driver or maintain a separate driver. Only one driver needs to be developed and maintained, reducing the investment of manpower and material resources, saving costs, and effectively shortening the development cycle.

[0036] Each module in the aforementioned MCAL-compliant board-level driver device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of a device with data processing capabilities, or stored in software within the memory of the aforementioned device, so that the processor can call and execute the operations corresponding to each module. The aforementioned device can be, but is not limited to, various types of in-vehicle computer devices already existing in the art.

[0037] In one embodiment, such as Figure 3 As shown, a board-level driving method for an MCU is provided, applied to the aforementioned board-level driving device compatible with the MCAL specification. This board-level driving method for the MCU may include the following processing steps S10 to S12: S10, Obtain the software module to be driven from the MCU; S12, when it is determined that the software module to be driven has a hardware IP for implementation, the first board-level driver package is called to drive the software module to be driven.

[0038] The first board-level driver package is configured in the microcontroller abstraction layer based on the AUTOSAR specification, including the MCAL layer and BSP layer. The BSP layer includes a hardware layer and a BSP driver layer set according to the IP. The MCAL layer includes the MCAL external interface layer. The software module to be driven is a standard module defined by the MCAL specification. The functional requirements implemented by the software module to be driven in the BSP layer are less than the difference threshold compared with the MCAL specification.

[0039] The aforementioned MCU board-level driver method, by adopting a board-level driver design with clear and simple logic hierarchy, effectively meets the highest functional safety requirements of ISO26262 while being compatible with simple hardware IP implementation scenarios using MCAL. This effectively shortens the driver development cycle, reduces code design failure rate, reduces driver maintenance work for users, and saves MCU driver development and maintenance costs.

[0040] In one embodiment, such as Figure 3 As shown, after step S10 above, the MCU board-level driving method may further include the following steps: S11, when it is determined that the software module to be driven has more than two hardware IPs for implementation, the pre-set second board-level driver package is called to drive the software module to be driven.

[0041] The second board-level driver package is configured in the microcontroller abstraction layer based on the AUTOSAR specification for the MCAL layer and BSP layer. The BSP layer includes various hardware layers, hardware abstraction layer and BSP driver layer with different settings according to the IP. The MCAL layer includes the MCAL external interface layer. The software module to be driven is a standard module defined by the MCAL specification. The functional requirements implemented by the software module to be driven in the BSP layer are less than the difference threshold compared with the MCAL specification.

[0042] The MCU board-level driver method in this embodiment adopts a board-level driver design with clear and simple logic hierarchy, which effectively meets the highest level of functional safety requirements of ISO26262 and is also compatible with scenarios that use the MCAL specification and have more than two hardware IP implementations. This effectively shortens the driver development cycle, reduces the code design failure rate, reduces the driver maintenance work for users, and saves MCU driver development and maintenance costs.

[0043] In one embodiment, if the difference between the functional requirements implemented by the software module to be driven in the BSP layer and the MCAL specification is greater than the difference threshold, then the MCAL layer of the first board-level driver package and the second board-level driver package also includes an MCAL logic processing layer.

[0044] Understandable, such as Figure 4 As shown, the first step is to determine whether the software module to be driven has multiple hardware IPs that can be used for implementation. If the software module to be driven has multiple hardware IPs that can be used for implementation, then based on the existing hardware IP information (such as hardware IP manuals) for each hardware IP, or by referring to the corresponding existing IP specification information, different hardware layers (i.e., each...) are set according to the IP.<Module_Hw> Level layer<Module_Hw> The Level layer is designed to interact directly with the hardware, such as Uart_Hw / LinUart_Hw, for hardware IP processing. Next, the Hardware Abstraction Layer (HAL) is set up.<Module_Hal> Level (for its respective module)<Module_Hw> The Level layer handles processing and unifies the interface calls from the upper layers to the hardware layer. For example, the hardware abstraction layer Uart_Hal identifies which hardware IP to use based on parameters passed from the upper layer and performs the corresponding functional processing. This leads to the design of the BSP driver layer (i.e.,...).<Module_Drv> The Level layer is the external interface layer of the BSP layer. It implements the corresponding required functions by calling the Hardware Abstraction Layer (if it exists) or the hardware layer.

[0045] Next, it is determined whether the software module to be driven is a standard module defined by the MCAL specification. If the software module to be driven is a standard module defined by the MCAL specification, the differences between the functional requirements implemented by the software module to be driven at the BSP layer and the MCAL specification are evaluated. If the differences are minor (i.e., the logic defined by the specification is not complex, such as no more than two differences; taking two differences as a threshold, and other values ​​are similar, as long as efficient driving is ensured to the maximum extent while reducing the complexity of the driver package), then the MCAL external interface layer (i.e., ...) is set. <module>After the Level layer calls the BSP driver layer or MCAL logic processing layer (if it exists) to implement the corresponding interface specifications and functions of the MCAL specification, the driver process ends.

[0046] If the differences are significant (e.g., more than two differences), then an MCAL logic processing layer (i.e., ...) is set up.<Module_Sar> After the Level layer calls the BSP driver layer to implement the required functional logic corresponding to the specification, it jumps to the step of setting the MCAL external interface layer.

[0047] If the software module to be driven does not have multiple hardware IPs available for implementation, then the hardware layer should be configured according to the hardware IP manual and related content of the software module to be driven.<Module_Hw> Level, this hardware layer is designed to interact directly with the hardware (such as register configuration) and then jump directly to the steps of setting up the BSP driver layer.

[0048] If the software module to be driven is not a standard module defined by the MCAL specification, the driving process ends.

[0049] In this embodiment, the MCU board-level driving method can address situations where the functional requirements of the software module to be driven at the BSP layer differ significantly from the MCAL specification, i.e., when the software module has complex logic, by adding...<Module_Sar> The Level layer calls the BSP driver layer to implement the required functional logic corresponding to the MCAL specification, thus achieving efficient MCU driving.

[0050] It is understood that the specific limitations of the above-mentioned MCU board-level driving method can be found in the corresponding limitations of the board-level driving device compatible with the MCAL specification mentioned above, and will not be repeated here.

[0051] It should be understood that, although Figure 3 The steps are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order in which these steps are executed; they can be performed in other orders. Figure 3 At least some of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0052] In one embodiment, a computer device is also provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following processing steps: acquiring a software module to be driven by the MCU; determining that the software module to be driven has a hardware IP for implementation, and calling a pre-configured first board-level driver package to drive the software module to be driven; wherein the first board-level driver package is configured in the microcontroller abstraction layer based on the AUTOSAR specification of the MCAL layer and the BSP layer, the BSP layer includes a hardware layer configured according to the IP and a BSP driver layer, and the MCAL layer includes an MCAL external interface layer; the software module to be driven is a standard module defined by the MCAL specification, and the difference between the functional requirements implemented by the software module to be driven in the BSP layer and the MCAL specification is less than a difference threshold.

[0053] In one embodiment, when the processor executes the computer program, it can also implement the steps or sub-steps added in the various embodiments of the MCU board-level driving method described above.

[0054] In one embodiment, a computer-readable storage medium is also provided, on which a computer program is stored. When the computer program is executed by a processor, it performs the following processing steps: obtaining the software module to be driven by the MCU; when it is determined that the software module to be driven has a hardware IP for implementation, calling a pre-configured first board-level driver package to drive the software module to be driven; wherein, the first board-level driver package is configured in the microcontroller abstraction layer based on the AUTOSAR specification of the MCAL layer and the BSP layer, the BSP layer includes a hardware layer configured according to the IP and a BSP driver layer, and the MCAL layer includes an MCAL external interface layer; the software module to be driven is a standard module defined by the MCAL specification, and the difference between the functional requirements implemented by the software module to be driven in the BSP layer and the MCAL specification is less than the difference threshold.

[0055] In one embodiment, when the computer program is executed by the processor, it can also implement the steps or sub-steps added in the various embodiments of the MCU board-level driving method described above.

[0056] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus DRAM (RDRAM), and interface DRAM (DRDRAM), etc.

[0057] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0058] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of protection of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and all such modifications and improvements fall within the scope of protection of the present invention.< / module> < / module> < / module> < / module> < / module>

Claims

1. A board level driver device compatible with the MCAL specification, characterized in that, The MCAL layer and the BSP layer are configured in the microcontroller abstraction layer of the basic software layer based on the AUTOSAR specification, the BSP layer is used to implement the basic functions required by the MCU to use the MCAL specification standard, and the MCAL layer is used to implement the interfaces and logic required by the MCAL specification standard; the basic software layer is a BSW layer of an automotive open system architecture; The complex driving module of the basic software layer includes a CDD module developed using the BSP layer architecture, and the CDD module is used to implement the function modules not required by the MCU to use the MCAL specification standard.

2. The MCAL specification compatible board level driver of claim 1, wherein, The BSP layer includes a hardware layer and a BSP driving layer, the hardware layer is used to interact with the MCU hardware and operate the hardware registers, and the BSP driving layer is an external interface layer of the BSP layer.

3. The MCAL specification compatible board level driver of claim 2, wherein, The BSP layer further includes a hardware abstraction layer, and the hardware abstraction layer is used to identify the hardware IP required for processing the current task.

4. The MCAL specification compliant board level driver of any one of claims 1 to 3, wherein, The MCAL layer includes an MCAL external interface layer, and the MCAL external interface layer is an external interface of the MCAL.

5. The MCAL specification compatible board level driver of claim 4, wherein, The MCAL layer further includes an MCAL logic processing layer, and the MCAL logic processing layer is used to implement the logic defined by the MCAL specification by calling the interface of the BSP driving layer.

6. A method for board-level driving of an MCU, characterized in that The MCU board-level driving method applied to the board-level driving device compatible with the MCAL specification in any one of claims 1 to 5 comprises the steps of: obtaining a software module to be driven of the MCU; when it is determined that the software module to be driven has one hardware IP for implementation, calling a first board-level driving package to drive the software module to be driven, wherein the first board-level driving package is based on the MCAL layer and the BSP layer configured in the microcontroller abstraction layer based on the AUTOSAR specification, the BSP layer includes a hardware layer and a BSP driving layer set according to the IP, and the MCAL layer includes an MCAL external interface layer; the software module to be driven is a standard module defined by the MCAL specification, and the difference between the functional requirements of the software module to be driven implemented in the BSP layer and the MCAL specification is less than a difference threshold.

7. The board-level driving method of the MCU according to claim 6, wherein, After the step of obtaining the software module to be driven of the MCU, the following steps are further included: when it is determined that the software module to be driven has more than two hardware IPs for implementation, calling a second board-level driving package to drive the software module to be driven; wherein the second board-level driving package is based on the MCAL layer and the BSP layer configured in the microcontroller abstraction layer based on the AUTOSAR specification, the BSP layer includes different hardware layers, a hardware abstraction layer and a BSP driving layer set according to the IP, and the MCAL layer includes an MCAL external interface layer; the software module to be driven is a standard module defined by the MCAL specification, and the difference between the functional requirements of the software module to be driven implemented in the BSP layer and the MCAL specification is less than a difference threshold.

8. The board-level driving method of the MCU according to claim 6 or 7, wherein, If the difference between the functional requirements of the software module to be driven implemented in the BSP layer and the MCAL specification is greater than the difference threshold, the MCAL layer of the first board-level driving package and the second board-level driving package further includes an MCAL logic processing layer.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor implements the steps of the MCU board-level driving method of any one of claims 6 to 8 when executing the computer program.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by a processor, implements the steps of the board-level driving method of the MCU according to any one of claims 6 to 8.

Images