MCAL software architecture and driving device

Abstract

The invention discloses an MCAL software architecture, which comprises a hardware driving layer, a hardware adaptation layer and a standard layer, and is characterized in that the hardware driving layer is used for defining an interface file of at least one chip IP so as to call an MCAL module code for realizing a chip specific IP through an interface; the hardware adaptation layer is used for calling a corresponding interface in the hardware driving layer according to a hardware IP specified by the standard layer so as to realize operation on specified hardware; and the standard layer is used for specifying hardware and calling an interface of the hardware adaptation layer to realize an MCAL standard function. According to the method, the characteristics of reusability, readability, diversity and the like are considered, the interior of the MCAL is reasonably layered, so that the reusability and readability of MCAL codes are high, when different chips are replaced, only a small number of files / codes need to be modified, adaptation of the chips can be completed, and the problems that current MCAL codes are poor in reusability and readability are solved.

Description

Technical Field

[0001] The present invention belongs to the field of automotive embedded software design, and more specifically, relates to an MCAL software architecture and a driving device. Background Art

[0002] AUTOSAR (AUTomotive Open System Architecture) is an open standard in the automotive industry, which solves a series of problems such as software-hardware decoupling and software reusability in automotive ECUs, and provides a standardized and modular development framework for the automotive industry.

[0003] As Figure 1 shown, AUTOSAR abstracts software into four layers: the application layer, the run-time environment (RTE), the basic software layer (BSW), and the microcontroller. Among them, the basic software layer (Basic Software Layer, BSW) can be further divided into four layers, namely the services layer, the ECU abstraction layer, the microcontroller abstraction layer (MCAL), and the complex drivers.

[0004] The microcontroller abstraction layer (MCAL) is a special layer that realizes the unification of different hardware interfaces. The MCAL layer is strongly related to the hardware and is a key layer for abstracting the underlying hardware. Different microcontroller chips correspond to different MCAL implementations.

[0005] Although AUTOSAR unifies the software interface and solves the software reusability problem of ECU suppliers. However, due to the strong correlation between MCAL and the hardware, there is currently no good software framework to implement MCAL code and make the code have high reusability.

[0006] The general approach is to implement the code in a single file, but this method has poor reusability. If other chips are replaced, the corresponding MCAL code often needs to be redeveloped, and the reusability of the MCAL code is poor.

[0007] The Chinese patent with publication number CN102681898A discloses a method for improving the portability of AUTOSAR OSMCAL driver code on September 19, 2012. This method divides the MCAL code structure into two layers, Module_Hw.c and Module.c, which increases the code reusability to a certain extent. However, it does not consider the situation where a module is implemented by multiple hardware components. For example, the MCAL ICU module can be implemented through the IP1 module of chip A on chip A, and after changing to chip B, the ICU module can be implemented through the IP2, IP3, and IP4 of chip B. After changing the chip, even according to the method of this patent, Module_Hw.c and Module.c still need to be significantly modified, and the code reusability is not high. Moreover, this patent proposes to read and write registers by defining macros in Module_Hw.c, resulting in poor code readability.

[0008] The Chinese patent with publication number CN112650512 A discloses a hardware driver method on April 13, 2021. However, the devices controlled by its multi-hardware device layer are on the terminal and outside the device. It is equivalent to adapting multiple devices on the terminal when the device remains unchanged and cannot adapt the modules inside the chip when the device changes.

[0009] The Chinese patent with publication number CN111309291B discloses a modular embedded software architecture on September 24, 2021. By adding an operating system adaptation layer, a core module service layer, and an application function module layer, different applications are classified and managed. Although this patent ensures that the upper-layer code is as reusable as possible by adding an intermediate layer, it depends on the operating system and focuses on upper-layer applications and cannot quickly implement the underlying hardware driver when the underlying hardware changes. Summary of the Invention

[0010] To solve the problems of poor reusability and readability of current MCAL code, the present invention provides an MCAL software architecture. This software architecture takes into account characteristics such as reusability, readability, and diversity (one MCAL module is implemented by multiple hardware modules), and reasonably layers the inside of MCAL, making the MCAL code highly reusable and readable. When changing different chips, only a small number of files / codes need to be modified to complete the adaptation to the chip.

[0011] According to one aspect of the specification of the present invention, there is provided an MCAL software architecture, including: a hardware driver layer, a hardware adaptation layer, and a standard layer. The hardware driver layer is used to define interface files for at least one chip IP to implement the MCAL module code of the chip-specific IP through interface calls; the hardware adaptation layer is used to call the corresponding interfaces in the hardware driver layer according to the hardware IP specified by the standard layer to implement operations on the specified hardware; the standard layer is used to specify the hardware and call the interfaces of the hardware adaptation layer to implement the MCAL standard functions.

[0012] As a further technical solution, the interface files configured for each chip IP by the hardware driver layer include: a driver declaration file, which is used to declare the interface at the driver level corresponding to the IP; a driver implementation file, which is used to implement the interface at the driver level corresponding to the IP and contains the specific implementation of the MCAL's operations on the hardware; a register access file, which is used for register access at the IP driver level. Among them, the name of each file contains the IP name corresponding to the chip.

[0013] As a further technical solution, the interface files defined by the hardware driver layer further include: an interrupt declaration file, which is used to declare the interrupt interface at the driver level corresponding to the IP; an interrupt function file, which is used to define the interrupt entry function at the driver level.

[0014] As a further technical solution, the implementation of the driver implementation file depends on the interfaces in the register access file and implements the interfaces in the driver declaration file. The implementation of the driver declaration file also depends on the interfaces in the interrupt function file.

[0015] As a further technical solution, the register access file is defined in the form of an inline function.

[0016] As a further technical solution, the interface files defined by the hardware adaptation layer include: an adaptation declaration file, which is used to declare the interfaces of the hardware adaptation layer; an adaptation implementation file, which is used to implement the interfaces of the hardware adaptation layer and contains the adaptation of different chip IPs.

[0017] As a further technical solution, the interfaces in the adaptation declaration file are implemented in the adaptation implementation file; the implementation of the adaptation declaration file also depends on the interfaces in the driver declaration file.

[0018] As a further technical solution, the interface files defined by the standard layer include: a standard declaration file, which is used to declare the interfaces of the MCAL standard layer; a standard implementation file, which is used to implement the interfaces of the MCAL standard layer.

[0019] As a further technical solution, the implementation of the standard implementation file depends on the interfaces in the adaptation declaration file and implements the interfaces in the standard declaration file.

[0020] According to one aspect of the specification of the present invention, a driving device is further provided, which uses the hardware driving layer interface in the above-mentioned MCAL software architecture as the SDK driver.

[0021] Compared with the prior art, the beneficial effects of the present invention are as follows: The internal structure level of the MCAL architecture of the present invention is clear, the function division is clear, it has strong readability, and is easy to maintain.

[0022] The code of the present invention has high reusability. After replacing the chip, the standard layer code can be completely reused, shortening the MCAL development cycle.

[0023] The present invention can use the driving layer interface alone ( <ip>_Hw.h) is used as a general SDK driver, that is, this set of architectures can meet the MCAL requirements and can also be used as a non-MCAL driver. Brief Description of the Drawings

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings used in the description of the embodiments or the prior art. Obviously, the following drawings are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0025] Figure 1 It is a schematic diagram of the AUTOSAR architecture.

[0026] Figure 2 It is a schematic diagram of the MCAL layer structure provided by the embodiment of the present invention.

[0027] Figure 3 It is a schematic diagram of the file dependency relationship of each layer of MCAL provided by the embodiment of the present invention.

[0028] Figure 4 It is a schematic diagram of the GPT module driver layer provided by the embodiment of the present invention.

[0029] Figure 5 It is a schematic diagram of the initialization process of the hardware adaptation layer provided by the embodiment of the present invention.

[0030] Figure 6 It is a schematic diagram of the Gpt_Init initialization process provided by the embodiment of the present invention.

[0031] Figure 7 It is a schematic diagram of the relationship between each layer of the Gpt module provided by the embodiment of the present invention. Detailed Embodiments

[0032] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention. In addition, the technical features in each embodiment or individual embodiment provided by the present invention can be combined with each other arbitrarily to form a new technical solution. This combination is not restricted by the order of steps and / or the structure composition mode, but must be based on the fact that those of ordinary skill in the art can implement it. When the combination of technical solutions results in contradictions or cannot be implemented, it should be considered that this combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0033] An embodiment of the present invention provides an MCAL software architecture, including: a hardware driver layer, a hardware adaptation layer, and a standard layer. The hardware driver layer is used to define interface files for at least one chip IP to implement the MCAL module code of the chip-specific IP through interface calls; the hardware adaptation layer is used to call the corresponding interfaces in the hardware driver layer according to the hardware IP specified by the standard layer to implement operations on the specified hardware; the standard layer is used to specify the hardware and call the interfaces of the hardware adaptation layer to implement the MCAL standard functions.

[0034] Please refer to Figure 2 , which divides the inside of the MCAL module into three layers: a hardware driver layer (Hardware Driver, Hw), a hardware adaptation layer (Hardware Adapter, Hwa), and a standard layer (Standard). Among them, the standard layer provides MCAL standard driver interfaces, Ma (Module Abbreviation) module abbreviations, such as Gpt, Icu, etc. The Hwa layer is for hardware interface adaptation, and the upper layer accesses the hardware driver layer through the Hwa layer.

[0035] It should be noted that the content in <> changes with the actual module; xxx_irq.c is optional and can be specifically selected according to actual needs.

[0036] Among them, the hardware driver layer implements the MCAL module code of the chip-specific IP, and the file list of the hardware driver layer is shown in Table 1.

[0037] Table 1 File List of Hardware Driver Layer

[0038] It should be noted that: <ip>Refers to the IP name corresponding to the chip. IP0 and IP1 refer to different IPs.

[0039] <ip>_Hw.c contains the specific implementation of the MCAL's operations on the hardware, including interfaces for hardware initialization, de-initialization, function configuration, and hardware status reading, etc.

[0040] <ip>_Hw_Reg_Access.h encapsulates the operations of reading and writing registers into a readable interface and defines the interface in an inline form. <ip>_Hw.c accesses registers by calling its interfaces to complete the configuration of the hardware.

[0041] In the embodiments of the present invention, in order to implement the functions of the standard MCAL and adapt to multiple IPs, the hardware adaptation layer will call <ip>Implement the functions required by MCAL through the interfaces in _Hw.h.

[0042] If a MCAL module can be implemented by multiple IPs, the Hardware Abstraction Layer will contain <ip>_Hw.h and configure the corresponding hardware according to the IP selected by the user to implement the MCAL standard functions.

[0043] The files included in the hardware adaptation layer are shown in Table 2.

[0044] Table 2 Hardware Adaptation Layer

[0045] In Table 2, <ma>Refers to the module abbreviation defined by the AUTOSAR standard, such as: Icu, Can, Mcu, etc.

[0046] In the embodiment of the present invention, the standard layer implements the interface of the MCAL standard by calling <ma>The interfaces in _Hwa.h implement the standard functions of MCAL.

[0047] The files included in the standard layer are shown in Table 3.

[0048] Table 3 Standard layer

[0049] The standard layer only needs to implement standard-related functions, including development error tracing (Det), diagnostic event management (Dem), global variable management, MCAL module status management, etc. All hardware-related operations are implemented by calling the interfaces of the hardware adaptation layer (Hwa).

[0050] The file dependency relationships of each layer are as Figure 3 shown.

[0051] In the figure, solid arrows indicate implementation. For example: <ma>.c is the code implementation, <ma>.h is the interface declaration, and this arrow indicates that <ma>Implemented in.c <ma>Interfaces in the.h. The dashed arrows indicate dependencies, for example: <ma>.c implementation depends on <ma>Interfaces in _Hwa.h

[0052] Based on the above architecture, when replacing the chip, the MCAL code only needs to modify the driver layer and adaptation layer files, without modifying the standard layer files, making the software highly portable and reusable.

[0053] Below, the Gpt module on the IMMORTA IM94x platform will be used as an example. The IM94x hardware includes: TIMER, RTC, IPWM, SPWM, and the Gpt module that can be used to implement MCAL.

[0054] First, the Gpt module is internally divided into three layers: the hardware driver layer, the hardware adaptation layer, and the standard layer.

[0055] The hardware driver layer includes: Access files for TIMER, RTC, IPWM, and SPWM registers: Timer_Hw_Reg_Access.h, Rtc_Hw_Reg_Access.h, Ipwm_Hw_Reg_Access.h, Spwm_Hw_Reg_Access.h.

[0056] Driver files for TIMER, RTC, IPWM, and SPWM: Timer_Hw.c / h, Rtc_Hw.c / c, Ipwm_Hw.c / h, Spwm_Hw.c / h.

[0057] Xxx_Hw.c calls Xxx_Reg_Access.h to access the registers and implements specific operations of MCAL on the hardware, such as Figure 4 shown. The meaning of the arrows in the figure can be referred to Figure 3 . Among them, Xxx_Hw.h is the declaration of the interface of Xxx_Hw.c and is called by the hardware adaptation layer.

[0058] The hardware adaptation layer includes Gpt_Hwa.c / h. The hardware adaptation layer calls the interfaces in the corresponding Xxx_Hw.h according to the hardware configured by the user to implement operations on the hardware.

[0059] Define the enumeration type Gpt_Hwa_SupportModuleType in the hardware adaptation layer

[0060] The hardware adaptation layer will operate according to the hardware specified by the standard layer. Taking the initialization process of the hardware adaptation layer as an example, the specific process is as Figure 5 shown.

[0061] The standard layer includes Gpt.c / h, which is used to implement the standard logic of MCAL, including status management, error checking, etc.

[0062] For example, the Gpt_Init function, function prototype: void Gpt_Init(const Gpt_ConfigType* ConfigPtr) Define the members of the Gpt_ConfigType structure type as shown in Table 4.

[0063] Table 4 Gpt_ConfigType Members

[0064] Gpt_Init() first needs to determine whether the Gpt module is in an uninitialized state. If it is currently in an initialized state and the Det function is enabled, an error needs to be reported through Det. If it is currently in an uninitialized state, Gpt_Init() initializes global states such as ChannelMode, and needs to pass the ConfigPtr pointer to the hardware adaptation layer. The hardware adaptation layer Gpt_Hwa_Init() will initialize the corresponding hardware according to the selected hardware configuration. After the hardware adaptation layer initializes successfully, it feedbacks the result to the standard layer, and the standard layer sets the state of the Gpt module to the initialized state.

[0065] The initialization flowchart of Gpt_Init() is as Figure 6 shown. In the figure, first determine whether the passed parameter pointer ConfigPtr is null. If it is null, the initialization process ends. Otherwise, further determine whether the Gpt module is currently in an initialized state; if the Gpt module is currently in an initialized state, the initialization process ends. Otherwise, save the ConfigPtr pointer; then initialize the global variables and call Gpt_Hwa_Int; if the hardware initialization is successful, set the state of the Gpt module to initialized, otherwise end the initialization process.

[0066] The relationship between the layers of the Gpt module is as Figure 7 shown. In the figure: solid arrows represent implementation, and dashed arrows represent dependence, which can be referred to Figure 3 .

[0067] The embodiment of the present invention also provides a driving device, using the hardware driving layer interface in the MCAL software architecture as the SDK driver.

[0068] In summary of the above embodiments, the present invention mainly protects the software layering of the MCAL code and the responsibilities of each layer of software, specifically as follows: ① Divide the inside of MCAL into three layers: the standard layer, the adaptation layer (Hwa), and the hardware driving layer (Hw).

[0069] ② For each IP in the hardware, there is a corresponding Xxx_Hw.c. After being uniformly managed through the adaptation layer (Hwa), it is provided for upper-layer calls.

[0070] ③ The responsibilities of each layer and the dependency relationships between layers.

[0071] In the description and claims of the present invention and the above-mentioned drawings, the terms "comprising", "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0072] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some or all of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the technical solutions of the embodiments of the present invention.< / ma> < / ma> < / ma> < / ma> < / ma> < / ma> < / ma> < / ma> < / ip> < / ip> < / ip> < / ip> < / ip> < / ip> < / ip>

Claims

1. An MCAL software architecture, characterized in that, Including: A hardware driver layer, a hardware adaptation layer, and a standard layer. The hardware driver layer is used to define interface files for at least one chip IP to implement the MCAL module code of the specific chip IP through interface calls. The hardware adaptation layer is used to call the corresponding interfaces in the hardware driver layer according to the hardware IP specified by the standard layer to implement operations on the specified hardware. The standard layer is used to specify the hardware and call the interfaces of the hardware adaptation layer to implement the MCAL standard functions.

2. The MCAL software architecture according to claim 1, characterized in that, The interface files configured by the hardware driver layer for each chip IP include: a driver declaration file for declaring the interface at the IP driver level; a driver implementation file for implementing the interface at the IP driver level, including the specific implementation of the MCAL's operations on the hardware; and a register access file for accessing the registers at the IP driver level. Among them, the name of each file contains the IP name corresponding to the chip.

3. The MCAL software architecture according to claim 2, characterized in that, The interface files defined by the hardware driver layer also include: an interrupt declaration file for declaring the interrupt interface at the IP driver level; and an interrupt function file for defining the interrupt entry function at the driver level.

4. The MCAL software architecture according to claim 3, characterized in that, The implementation of the driver implementation file depends on the interfaces in the register access file and implements the interfaces in the driver declaration file. The implementation of the driver declaration file also depends on the interfaces in the interrupt function file.

5. The MCAL software architecture according to claim 2, characterized in that, The register access file is defined in the form of an inline function.

6. The MCAL software architecture according to claim 1, wherein The interface files defined by the hardware adaptation layer include: an adaptation declaration file for declaring the interfaces of the hardware adaptation layer; and an adaptation implementation file for implementing the interfaces of the hardware adaptation layer, including adapting different chip IPs.

7. The MCAL software architecture according to claim 6, characterized in that, The interfaces in the adaptation declaration file are implemented in the adaptation implementation file. The implementation of the adaptation declaration file also depends on the interfaces in the driver declaration file.

8. The MCAL software architecture according to claim 1, characterized in that, The interface files defined by the standard layer include: a standard declaration file for declaring the interfaces of the MCAL standard layer; and a standard implementation file for implementing the interfaces of the MCAL standard layer.

9. The MCAL software architecture according to claim 8, wherein The implementation of the standard implementation file depends on the interfaces in the adaptation declaration file and implements the interfaces in the standard declaration file.

10. A driving device, characterized in that, Using the hardware driver layer interfaces in the MCAL software architecture according to any one of claims 1 - 9 as the SDK driver.

Images