Automobile controller code automatic generation method and system

Abstract

The application discloses a kind of car controller code automatic generation method: 1) in configuration file, input the task position where the planned generation code is located;2) define the event name of planned generation code, and event processing function 3) OS abstraction layer generates function logic;4) code generation tool generates code part according to function logic;5) code generation tool is according to configuration file, the function to be executed in application is placed in the event processing function array that the task to be traversed is created by OS abstraction layer, and the interface of defined event and resource tree is generated.The application has the advantages that system task creation is realized by using OS abstraction layer, the software platform scheduling framework is agreed, and Deva Tool can automatically place the function to be run in each task according to the application scene of app into the corresponding content.The defined event and timer can also generate related interfaces, which are simple and easy to use.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence, and more particularly to automatic code generation technology. Background Technology

[0002] In automotive controller software development, system real-time performance is a frequently discussed topic. Only when the system meets real-time requirements can the processor immediately process new external inputs. When the controller has a simple function and handles little workload, we can develop the program using bare-metal methods with interrupts, which seems to meet the system requirements.

[0003] However, as the functions of automotive controllers increase, development using the bare-metal and interrupt approach becomes increasingly difficult. At this point, an embedded real-time operating system (RTOS) is needed to ensure system real-time performance.

[0004] When using an RTOS management system, users need to master its usage, such as how to create tasks, how to use event flag groups, and how to use semaphores. It's difficult to expect all development team members to master these skills. Even if everyone knows how to use it, if each person works independently to fulfill their assigned functionalities, creating different operating system tasks and defining different event flag groups, it can easily lead to excessive system overhead and reduce system robustness.

[0005] Currently, there is a lack of a method and system for automatically generating automotive controller code that can reduce operational difficulty. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to realize a method and system that can automatically generate code according to requirements.

[0007] To achieve the above objectives, the technical solution adopted by this invention is: a method for automatically generating automotive controller code.

[0008] 1) Enter the task location where the planned code will be generated in the configuration file;

[0009] 2) Define the event name for the planned code generation, and the event handling function.

[0010] 3) The OS abstraction layer generates functional logic;

[0011] 4) The code portion generated by the code generation tool based on the functional logic;

[0012] 5) The code generation tool, based on the configuration file, places the functions to be executed in the application into the array of event handling functions that the task needs to traverse, created by the OS abstraction layer, and generates defined event and resource tree interfaces.

[0013] The code generation tool parses all configuration files in the project and automatically generates the code needed for the project's OS abstraction layer to run.

[0014] The configuration files include the dssp.sdi file and the xxx.sdh file (xxx is a generic term, meaning that any name can be used, but the file extension must be .sdh);

[0015] The dssp.sdi file is used to configure the tasks to be created in the system, define the resource tree, and the dependencies between various resources;

[0016] The code generation tool creates corresponding tasks in the generated code based on the task description in the configuration file dssp.sdi.

[0017] The xxx.sdh file is used to configure which task a written function should be placed in to run, define the container and the function to be placed in the corresponding container, define some events and bind event handling functions when the events are sent;

[0018] The code generation tool parses the xxx.sdh file, places all functions set in the configuration files to run in a specific periodic task into the corresponding function calls, and then adds the corresponding functions to the function table searched by the periodic task. Which periodic tasks are available must be clearly defined in the aforementioned dssp.sdi file;

[0019] When any configuration file in the xxx.sdh file is modified, the code generation tool regenerates the relevant code to the corresponding directory based on the configuration file. The path of the generated code in the project can be specified in the dssp.sdi configuration file.

[0020] The abstraction layer includes a cshd module based on its functions. The cshd module is used to manage the relevant code of the resource tree and provides resource request and release functions to the outside world.

[0021] The cshd module pre-selects and divides into multiple states. If a certain operating condition is met, it requests the corresponding resource. The resource tree is defined in the dssp.sdi file. When the code generation tool generates code, it will first parse this file to generate a resource description table and an enumeration value of the requested resource.

[0022] Resources are divided into synchronous resources and asynchronous resources. Asynchronous resources are those described by external immediately following the type keyword, while synchronous resources are those without external description following the type keyword.

[0023] The require keyword for the synchronized resource is immediately followed by the requested ON corresponding resource;

[0024] The asynchronous resource has a timeout period for requesting the corresponding resource. If no response is received from the corresponding resource within the timeout period, the system enters an exception handling phase.

[0025] The abstraction layer includes a cam module based on its functions. The cam module is used to call the processing and distribution function within a periodic task. The function searches for the relevant execution function in the corresponding array based on the passed task ID, and then determines whether the current resources meet the resource requirements for the function to run. If they do, the function is executed.

[0026] The abstraction layer includes a `cont` module based on functionality. This `cont` module implements the relevant container code. The container can be arbitrarily defined in `xxx.sdh` as needed. Any written functionalities can be placed into a pre-defined container. Functions placed in a container are invoked together within the defined container's runtime. The generation tool automatically places the functions to be executed as sub-functions into the main function based on the functions described in the configuration file. Finally, an array is generated, with each item in the array storing the address of a container function. The `cont` module implements interface functions that can find and call the function in the array based on the enumerated values.

[0027] The abstraction layer includes an OS module based on its functions. The OS module is associated with RTOS and is used to create tasks in the system and implement the OS interfaces used by the system. The tasks to be created are specified in the configuration file. Then, an array is generated in the generated configuration code. This array describes the task stack size, the task entry function, and the OS part provides functions to parse this array and then call the RTOS interface to create the corresponding task, as well as the interface for event flag groups and semaphores.

[0028] The abstraction layer includes the evhd module according to its functions. The evhd module is used to abstract event-related content. The event represents an event. When an event is generated, the relevant event handling function will be called. The event uses the event mechanism provided by the operating system and is encapsulated in the event flag group mechanism of the operating system.

[0029] The abstraction layer includes a timer module based on its functions. The timer module is used to abstract the relevant content of timers, define timers in the configuration file, and then specify the timer processing function.

[0030] An automatic code generation system for automotive controllers includes a code generation module and an OS abstraction layer. The OS abstraction layer is encapsulated on top of an RTOS management system and is used to implement core functional logic. The code generation module is used to generate code content.

[0031] The advantage of this invention lies in its use of the OS abstraction layer to create system tasks and define a software platform scheduling framework. Deva Tool can automatically place the functions to be run in each task into the corresponding content based on the app's application scenario. Defining events and timers can also generate relevant interfaces, making it simple and easy to use.

[0032] Furthermore, this method and system utilize the concept of a resource tree, resulting in low CPU resource overhead and allowing operation on resource-constrained MCU platforms. It reduces the coupling between hardware and software modules, enhances reusability, and aligns more closely with modern software engineering development principles. This allows application developers to focus on application development without requiring in-depth understanding of system calls, making it easy to learn and use. Attached Figure Description

[0033] The following is a brief explanation of the content represented by each figure in this specification:

[0034] Figure 1 This diagram illustrates the relationship between DEVA Tool and the .sdi and .sdh configuration files.

[0035] Figure 2 Draw to define the relationships between resource trees;

[0036] Figure 3 This is a flowchart for asynchronous resource processing.

[0037] Figure 4 Flowchart for evhd module processing;

[0038] Figure 5 A schematic diagram of the implementation of Event. Detailed Implementation

[0039] The following description, with reference to the accompanying drawings, details the specific implementation of the present invention, including the shape and structure of each component, the relative positions and connections between the parts, the function and working principle of each part, the manufacturing process, and the operation and use methods, to help those skilled in the art to have a more complete, accurate, and in-depth understanding of the inventive concept and technical solution of the present invention.

[0040] A method and system for automatically generating automotive controller code encapsulates an OS abstraction layer on top of an RTOS, creating user-friendly tasks, encapsulating a more convenient event mechanism, and introducing a resource tree to reduce system load. Our OS abstraction layer code is independent of the application layer code. Users only need to describe in the configuration file which task they want to place their code in, define the event names used, and the event handling functions, and then use the tool to automatically generate this configuration code.

[0041] In summary, this solution has two components: the OS abstraction layer code and the code generation tool, Deva Tool. The OS abstraction layer code implements the core functional logic, and its operation depends on the code generated by Deva Tool. The content generated by Deva Tool is application-dependent. Based on the configuration file description, it places the functions to be executed in the application into the function array that the task created by the OS abstraction layer needs to traverse, and generates defined event and resource tree interfaces.

[0042] Deva Tool is a tool that parses all configuration files such as dssp.sdi and xxx.sdh in a project and automatically generates the code needed for the project's OS abstraction layer to run.

[0043] The dssp.sdi file configures the tasks to be created in the system, defines the resource tree, and specifies the dependencies between various resources.

[0044] The xxx.sdh file configures which system task a written function should run in, defines events and event handlers, etc.

[0045] The xxx.sdh file indicates that this file can be defined in each module. During the generation process, Deva Tool will traverse all .sdh-suffix files in all project directories and generate the relevant code based on the configuration.

[0046] The relationship between DEVA Tool and .sdi and .sdh configuration files is as follows: Figure 1 As shown, Deva creates the corresponding tasks in the generated code based on the task descriptions in the .sdi configuration file of the project.

[0047] For example, if the system creates a task that runs on a 5ms cycle, the task's processing function automatically finds a specific table (with a fixed name) it uses, and then checks the system resource status to see which 5ms cycle tasks can be executed.

[0048] The DEVA Tool's job is to parse the .sdh file, placing all functions set in the configuration file that run in the 5ms periodic task into CAM_5msC07 for calling. Then, it adds the CAM_5msC07 function to the table checked by the 5ms periodic task (note that C07 indicates a dependency on PMIC resources).

[0049] When using Deva Tool, if you change any .sdh configuration file, you need to use Deva Tool to generate the code in the dssp directory; otherwise, the configuration will not take effect.

[0050] In the OS abstraction layer, the code generated by Deva Tool is used by the OS abstraction layer to run. Essentially, during software design, the stable parts of the code that won't change depending on different applications are designed in advance, while the code that will be frequently modified during the project is separated out. This frequently modified part is automatically generated by the tool by parsing configuration files. The abstraction layer is divided into several parts according to functionality. The following will introduce the functional principles of each part and what code Deva Tool generates.

[0051] 1. cshd module

[0052] This section implements the code related to managing the resource tree, providing resource request and release functions. To reduce the system's load, the concept of a resource tree is introduced; this functionality is implemented in the cshd module. Developers can pre-define different states based on system requirements. When certain operating conditions are met, the application layer module can request a specific resource to be ON. This allows functions that depend on these resources being ON to be called in periodic tasks, thus reducing the system's load.

[0053] The resource tree is defined in the dssp.sdi file. When generating code using tools, this file is parsed first to generate a resource table describing the resources and an enumeration of requested resources. The resource definition syntax is as follows:

[0054] Define resource Hardware;

[0055] define resource Communication require Hardware;

[0056] defne resource PMIC type external require Hardware timeoutis 10000, 10000;

[0057] defne resource ICOM type external require PMIC;

[0058] defne resource Di5play type external require ICOM timeout is 5000, 10000;

[0059] define resource Active require Communication, Display;

[0060] Syntactically, each declaration begins with `define`, followed by the keyword `resource`, which tells the parser that we are defining a resource, followed by the resource name. Resources are categorized as synchronous or asynchronous. The `type` keyword followed by `external` describes an asynchronous resource; if this is omitted, the defined resource is synchronous. The `require` keyword is followed by the resource's dependencies (which must be initialized first). Asynchronous resources require a specified timeout; if no response is received within the specified timeout, the system enters exception handling.

[0061] When a synchronous resource request is made, the resource is set to ON after the cshd module calls the init and deinit functions of the dependent resource. When an asynchronous resource request is made, the cshd module will emit a corresponding notification event. The event handler function declared externally captures the event, and after receiving the event and completing the corresponding operation, it emits a Feedback event to the cshd module. At this time, the system will set the resource to ON.

[0062] like Figure 2 As shown, when a request is made for an Active resource, the cshd module first checks whether its dependent resources are ON. If not, it automatically switches between OFF and ON for the dependent resources. Only after all dependent resources are ON does it switch between OFF and ON for the Active resource.

[0063] Having defined the system resources, we also need to define what allows us to request these resources. These are also defined in the dssp.sdi file. The resource request definitions are described below:

[0064] defnemaster request Hardware by DIO;

[0065] defne master request Hardware by TLTLLED;

[0066] defne master request communication by NM;

[0067] defne request ICOM by NM;

[0068] defne master request Di5play by APP;

[0069] defne request Dispay by WRN;

[0070] defne request Dsplay by TLTLLCD;

[0071] defne request Display by GEARDISPLAY;

[0072] defne master request Active by IGN;

[0073] Similarly, the resources requested by others also begin with the `define` keyword, which makes it easier for code generation tools to perform matching. It can be seen that Hardware resources can be requested by DIO, TLTLED, etc. In fact, when generating code, these will generate an enumeration value, which is passed as a parameter to the resource request function to mark what is requesting the resource ON.

[0074] For the resource tree module, Deva Tool will specifically generate cshd_gen.c and cshd_gen.h files, which describe the dependencies of a resource when it is ON, as well as the execution functions during the synchronization of resource init and deinit processes.

[0075] Dependency table when resources are ON

[0076]

[0077] For example, if an Active resource is requested to be ON, and this resource depends on Communication, Display, Hardware, ICOM, and PMIC resources being ON, the cshd module will first initialize these resources from Off to On. Similarly, requesting Display resource ON depends on Hardware, PMIC, and ICOM resources being ON. Essentially, this describes the dependency relationships of the resource tree mentioned above.

[0078]

[0079] The above generates an enumeration value. CSHD_tenRequest describes which resources can be requested, and CSHD_ten_SM describes which resources are available. This is a conversion of the description in the dssp.sdi file. There are variables to represent the current resource status. Each bit of this status flag describes the content of each item in CSHD_tenSM. For example, if the flag is 0x0000020, it means that the current status is Hardware ON.

[0080] Resource request processing flow:

[0081] After the CSHD_enSetRequest function is called to request synchronization resources, the cshd module will set the resource to the On state after calling the init function.

[0082] Asynchronous resources: When an asynchronous resource is requested using CSHD_enSetRequest, it sends corresponding events. Only after receiving the corresponding Feedback event is the resource set to the On state. The asynchronous resource processing flow is as follows: Figure 3 As shown.

[0083] 2. CAM module

[0084] The function that handles the dispatching of calls within a periodic task is implemented. This function will look up the relevant execution function in the corresponding array based on the passed task ID, and then determine whether the current resources meet the resource requirements for the function to run. If they do, the function will be executed.

[0085] This function table is described in the configuration file, which is generated by our Deva Tool. To run a function in a periodic task, the syntax is written in the sdh file:

[0086] define activity PowerControl_D1_D2_D3_5ms_v type cyclic sequence 100require Hardware on in CAM5msTask;

[0087] Similarly, the syntax for defining functions within a periodic function also begins with the `define` keyword. `PowerControl_D1_D2_D3_5ms_v` is the function name, `type` followed by `cyclic` indicates that it runs periodically, `sequence` indicates the position in the main function where it is called as a sub-function, `require` indicates that it depends on the `Hardware` resource `ON`, and `CAM5msTask` is the task name, indicating that this function is placed in the function execution table that is traversed in the 5ms task.

[0088] The Deva Tool generates the cam module, which will automatically generate cam_gen.c and cam_gen.h (the generated files are shown here):

[0089]

[0090] This is an array containing the addresses of the function tables that each periodic task needs to iterate over. From the above, we see 100ms, 10ms, 1ms, 25ms, and 5ms periodic tasks. Let's check if the 5ms periodic task iterates over the array and includes the PowerControl_D1_D2_D3_5ms_v function.

[0091]

[0092] This array describes different items, each preceded by a number. This number represents the prerequisites, i.e., the resources that the following function depends on to run. For example, the PowerControl_D1_D2_D3_5ms_v function runs in a 5ms task and depends on Hardware resources. When the Hardware resource is ON, the CSHD module describes the resource status as 0x00000020. Therefore, we look at the fourth item in this array, the executed function CAM_5msC04, to see if PowerControl_D1_D2_D3_5ms_v is its subfunction.

[0093]

[0094] As shown above, the PowerControl_D1_D2_D3_5ms_v function was placed as a subfunction into the CAM_5msC04 function by the tool.

[0095] 3. cont module

[0096] This part implements the container-related code. A container is actually an abstraction, essentially a function. Different containers can be defined in the configuration file. For example, if the system has a power management module, a high-voltage and low-voltage container can be defined. Then, the app specifies in the configuration file that the content called during high-voltage and low-voltage operations should be placed in the high-voltage and low-voltage container. The tool will then generate this high-voltage and low-voltage function, and then place the function to be executed when entering the high-voltage and low-voltage state as a sub-function into the main function. Finally, an array is generated, where each item in the array stores the address of a container function. The `cont` object implements an interface function that can find and call the function in the array based on the enumerated value.

[0097] Define cont in the configuration file sdh

[0098] define container POWC_ENTER_LVL2;

[0099] Putting the NM_NotifyPowSts_Abnornal function into POWC_ENTER_LVL2 cont essentially generates a function, with NM_NotifyPowSts_Abnornal being called as a sub-function.

[0100] For the corresponding cont module, Deva Tool will generate cont_gen.c and cont_gen.h files, which contain a table describing the corresponding execution function for each cont module.

[0101]

[0102] Contents of the CONT_POWC_ENTER_LVL2 function:

[0103]

[0104] NM_NotifyPowSts_Abnormal is a sub-function within the CONT_POWC_ENTER_LVL2 function. It also generates an enumeration value that corresponds sequentially to a specific entry in the CONT_rastContList table. Calling the cont execution function and passing in this ID will retrieve the content of the corresponding cont entry.

[0105]

[0106] 4. OS module

[0107] This part is related to the RTOS, implementing task creation and the OS interfaces used by the system. During development, the configuration file specifies which tasks to create. The tool then generates an array in the generated configuration code, which describes the task stack size, task entry function, etc. The OS part provides functions to parse this array and then call the RTOS interface to create the corresponding task, as well as interfaces for event flag groups and semaphores.

[0108] The system has several tasks described in dssp.sdi, as follows:

[0109] @taskselectin CAM1msTask, CAM5msTask, CAM10msTask, CAM25msTask, CAM100msTask, InitDeinitTask, LowPrioEventTask, HighPrioEventTask;

[0110] @resource processed in InitDeinitTask timeout in HighPrioEventTask;

[0111] @monitor

[0112] CAM5msTask, CAM10msTask, CAM25msTask, CAM100msTask,, InitDeinitTask, LowPrioEventTas kin HighPrioEventTask;

[0113] Tasks starting with CAM are periodic tasks. InitDeinitTask, LowProEventTask, and HighProEventTask are tasks used to handle event dispatching.

[0114] The content generated by DevaTool is in os_gen.c and os_gen.h.

[0115] The task description is stored in an array, containing the specified task stack, the task's entry function, and priority. When an OS abstraction layer function is called to create a task, this table is used to invoke the OS's task creation interface to create the task.

[0116]

[0117] 5. evhd module

[0118] This abstract concept of event-related content uses `event` to represent an event. When an event occurs, the relevant event handler function is invoked. Our implemented `Event` utilizes the event mechanism provided by the operating system, encapsulated within the operating system's event flag group mechanism. An event can be defined to be received by multiple handler functions. The system has dedicated tasks for handling event dispatching, and the processing flow is as follows... Figure 4 As shown

[0119] Events are defined and used in the configuration file:

[0120] define event Display_AllPowerOnFinish; / / Define an event

[0121] Define the event `SMInit_Display` by `Display_vEventHandler` with priority 40 in `InitDeinitTask`; / / The event handler function, specifying which task the event is processed in.

[0122] The principle of Event implementation

[0123] The Event implementation is based on the operating system's event mechanism, and each task only uses 1 bit of the OS's event flag group, such as... Figure 5 As shown, the Deva Tool generates the contents of the evhd_gen.c and evhd_gen.h files. These files describe which bit is occupied by each event, which events are processed by different event handling tasks, and the corresponding processing functions after the events occur.

[0124]

[0125] The generated EVED__rastDispacher table describes which bit content is processed by which tasks. The EVHD__rastDispatchEvents table describes which entry in the EventHandlerIndex table corresponds to an Event.

[0126] The EVHD__rau16EventHandlersIndex table describes the location of the event handler function called by this item within the event handler function table.

[0127] The EVHD__rapfEventHandlers event handler table is used to find the appropriate handler function to process the emitted event through a series of mappings.

[0128]

[0129] 6. Timer module

[0130] The timer module abstracts timer-related content. We can define timers in the configuration file and then specify the timer handling function.

[0131] The syntax for defining and using timers in the sdh configuration file is as follows:

[0132] Define timer POWC_WAIT_MAX20006E_STABLIZE_1MS based on 1ms; / / Define timer

[0133] Define the timer POWC_WAIT_MAX20006E_STABLZE_1MS by PowerControl_CaptureEvents_v with priority 100 in LowPrioEventTask; / / Use a timer

[0134] When defining a timer, you need to specify the time base. It is also bound to an event. When the timer expires, it will emit a related event. You also need to specify which task will handle the timer timeout event and the event handling function.

[0135] The `Timer_vStart` function is called to start the timer to be enabled and specify the timeout period. Each execution of the 1ms task decrements the counter of the currently enabled timer by 1. When the counter reaches 0, the corresponding event is found and sent. After the event is sent, the evhd module finds the timer timeout handling function and executes the timeout processing.

[0136] The Deva Tool generates the timer_gen.c and timer_gen.h files, which correspond to the mapping between each timer ID and timer event. When a timer is found to have timed out, it is easy to find its corresponding event ID based on the ID and send out the timeout event.

[0137] The generated event ID mapping table for each timer timeout

[0138]

[0139] Each timer ID:

[0140]

[0141] It can be seen that the two are mutually mapped. When a timer times out, the corresponding timeout event can be found in the Timer__raenTimerEvents table according to the ID, and then the EVHD event sending interface is called to send the timeout event.

[0142] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution of the present invention, or the direct application of the inventive concept and technical solution of the present invention to other occasions without modification, are all within the protection scope of the present invention.

Claims

1. A method for automatically generating automotive controller code, characterized in that: 1) Enter the task location where the planned code will be generated in the configuration file; 2) Define the event name for the planned code generation and the event handling function in the configuration file; 3) The OS abstraction layer implements the core functional logic; 4) The code generation tool generates the code required for the OS abstraction layer to run based on the configuration file. Specifically, it includes: putting the functions to be executed in the application into the function array that the task created by the OS abstraction layer needs to traverse, and generating the defined event and resource tree interfaces. The configuration files include the dssp.sdi file and the xxx.sdh file; The OS abstraction layer includes the os module, evhd module, cshd module, and cont module according to their functions. Specifically: the os module is used to create tasks within the system and implement the OS interfaces used by the system; the evhd module is used to abstract event-related content; the cshd module is used to manage the resource tree and provide resource request and release functions; and the cont module is used to implement container-related code. The cshd module pre-divides multiple states. When a certain operating condition is met, it requests the corresponding resource. The resource tree is defined in the dssp.sdi file. When the code generation tool generates code, it will parse this file first to generate a resource description table and an enumeration value of the requested resource. Resources are divided into synchronous resources and asynchronous resources. Asynchronous resources are those described by external immediately following the type keyword, while synchronous resources are those without external description following the type keyword. The require keyword of the synchronized resource is immediately followed by the resource that the resource depends on; The asynchronous resource has a timeout period for requesting the corresponding resource. If no response is received from the corresponding resource within the timeout period, the system enters an exception handling phase.

2. The method for automatically generating vehicle controller code according to claim 1, characterized in that: The dssp.sdi file is used to configure the tasks to be created in the system, define the resource tree, and the dependencies between various resources; The code generation tool creates corresponding tasks in the generated code based on the task description in the configuration file dssp.sdi; The xxx.sdh file is used to configure which task a written function should be placed in to run, define the container and the function to be placed in the corresponding container, define some events and bind the handling function when the event is sent; The code generation tool parses the xxx.sdh file, places all the functions set in the configuration file that are to be run in a certain periodic task into the corresponding function calls, and then puts the corresponding functions into the function table to be searched when the periodic task runs. The available periodic tasks must be predefined in the above dssp.sdi file.

3. The method for automatically generating vehicle controller code according to claim 2, characterized in that: When any xxx.sdh configuration file is modified, the code generation tool regenerates the relevant code to the corresponding directory based on the configuration file. The path of the directory in the project is specified in the dssp.sdi configuration file.

4. The method for automatically generating vehicle controller code according to claim 3, characterized in that: The OS abstraction layer includes a cam module based on its functions. The cam module is used to call the processing and dispatching function within a periodic task. The function searches for the relevant execution function in the corresponding array based on the passed task ID, and then determines whether the current resources meet the resource requirements for the function to run. If they do, the function is executed.

5. The method for automatically generating vehicle controller code according to claim 4, characterized in that: The container can be arbitrarily defined in xxx.sdh according to actual needs. Any function written can be placed in a predefined container. Functions placed in the container will be called together within the time limit defined by the container. The function to be executed is placed as a sub-function in the main function. Finally, an array is generated, and each item in the array stores the address of a container function. The cont module implements an interface function that can find and call the corresponding container function from the array based on the enumeration value.

6. The method for automatically generating vehicle controller code according to claim 5, characterized in that: The OS module is associated with RTOS and is used to create tasks in the system and implement the OS interfaces used by the system. The tasks to be created are specified in the configuration file, and then an array is generated in the generated configuration code. This array describes the task stack size, the task entry function, and the OS part provides functions to parse this array and then call the RTOS interface to create the corresponding task, as well as the interface for event flag groups and semaphores.

7. The method for automatically generating vehicle controller code according to claim 6, characterized in that: The evhd module is used to abstract event-related content. The event represents an event. When an event is generated, the relevant event handling function will be called. The event uses the event mechanism provided by the operating system and is encapsulated in the event flag group mechanism of the operating system.

8. The method for automatically generating vehicle controller code according to claim 7, characterized in that: The OS abstraction layer includes a timer module based on its functions. The timer module is used to abstract timer-related content, define timers in the configuration file, and then specify timer processing functions.

9. An automatic vehicle controller code generation system for implementing the automatic vehicle controller code generation method according to any one of claims 1-8, characterized in that: It includes a code generation module and an OS abstraction layer. The OS abstraction layer is encapsulated on top of the RTOS management system and is used to implement core functional logic. The code generation module is used to generate code content.

Images