Automobile alarm sound configuration method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an automobile alarm sound configuration method and device, electronic equipment and a storage medium, and relates to the field of data processing.The method comprises the steps that an alarm sound configuration table is obtained, an alarm sound code template is determined, codes of all alarm sounds are generated based on the alarm sound configuration table and the alarm sound code template, and the codes of all the alarm sounds are generated based on the codes of all the alarm sounds; and configuring the automobile alarm sound. Through the scheme of combining Excel table configuration and a code template file, based on an alarm sound configuration table and an alarm sound code template, an implementation code for alarm sound bottom layer can signal logic processing is automatically generated, and the automobile alarm sound can be configured based on the code of the alarm sound. Therefore, the generation efficiency of the automobile alarm sound code and the configuration efficiency of the automobile alarm sound are improved.

Description

Technical Field

[0001] This invention relates to the field of data processing, and more specifically, to a method, apparatus, electronic device, and storage medium for configuring car alarm sounds. Background Technology

[0002] With the rapid development of my country's economy and the rapid rise of the automotive industry, the performance of in-vehicle infotainment systems is constantly improving, and the software functions in cars are becoming increasingly complex. The development of the automotive cockpit is also gradually moving towards intelligent integrated parking infotainment systems. Intelligent integrated parking infotainment systems not only need to consider application scenarios in the cockpit but also in parking radar scenarios, resulting in a sudden surge in the R&D workload for in-vehicle infotainment systems.

[0003] Currently, in the field of smart cockpits, the principle behind most solutions for playing alarm sounds in vehicles is that the I2S Master DSP power amplifier host chip and the I2S Slave power amplifier slave chip communicate via the audio I2S transmission protocol. Finally, the I2S Slave receives the signal from the host chip, drives the internal DAC+Class-D, and drives the speaker to produce sound.

[0004] Currently, there are generally two implementation schemes. One scheme integrates the DSP amplifier driver chip and the cockpit MCU main control chip onto a single PCB motherboard. The MCU main control chip communicates with the DSP power amplifier driver chip via the I2S transmission protocol. The MCU can directly control the DSP power amplifier chip's peripherals to drive the speaker. This scheme eliminates the need for a SOC chip, using only the MCU chip to produce sound. Therefore, it is generally used as a low-cost alarm sound generation solution for single instruments. The other scheme, which is currently the mainstream solution in the market, integrates the DSP power amplifier driver chip and the SOC main control chip onto a single PCB motherboard. The SOC controls the DSP power amplifier slave chip peripherals to drive the speaker.

[0005] Since most of the signals on a car body use CAN signals, the logic for triggering alarm tones still requires the MCU chip's CAN control receiver to process the transmitted and received CAN signals. Both solutions share a common characteristic: because most automotive communication signals are primarily CAN-based, with a small portion currently using Ethernet, the logic for handling various alarm tone triggers involves the underlying MCU receiving the CAN signal and then processing it using appropriate algorithmic logic.

[0006] With the continuous development of intelligence in the current new energy vehicle market, more and more components are being installed on actual vehicles. Consequently, the number of functions requiring car alarm sounds is also gradually increasing, from the original dozens of alarm sounds to the hundreds. In current solutions, the underlying logic code for processing alarm sound CAN signals uses a single encoding strategy for each alarm sound's CAN signal processing logic, and many of the implemented CAN signal processing logic strategies have similar functions.

[0007] Therefore, the current solutions for playing alarm sounds on in-vehicle systems involve repetitive coding, leading to tedious work and low efficiency. Summary of the Invention

[0008] The purpose of this invention is to provide a method, device, electronic device, and storage medium for configuring car alarm sounds, which can improve the efficiency of configuring car alarm sounds.

[0009] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a method for configuring a car alarm sound, the method comprising: Obtain the alarm tone configuration table; Determine the alarm tone code template; Based on the alarm tone configuration table and the alarm tone code template, generate the code for each of the alarm tones; Configure the car alarm sounds based on the codes for each alarm sound.

[0010] In an optional implementation, the alarm tone code template includes an alarm tone code header file template and an alarm tone code source file template. The step of generating the code for each alarm tone based on the alarm tone configuration table and the alarm tone code template includes: Obtain the automated script corresponding to the alarm tone configuration, wherein the automated script includes a first script and a second script; Run the first script to obtain the first parameter information in the alarm tone configuration table; Configure the alarm tone header file template based on the first parameter information to obtain the target alarm tone header file; Run the second script to obtain the second parameter information from the alarm tone configuration table; Configure the alarm sound code source file template based on the second parameter information to obtain the target alarm sound code source file; Based on the target alarm tone header file and the target alarm tone source file, the code for each alarm tone is generated.

[0011] In an optional implementation, the step of configuring the alarm tone header file template based on the first parameter information to obtain the target alarm tone header file includes: Run the first script; Identify the first key character in the alarm tone code header file template; The parameter information corresponding to the first script is retrieved from the alarm tone configuration table and used as the first parameter information; Replace the first key character in the alarm tone code header file template with the first parameter information to obtain the target alarm tone code header file.

[0012] In an optional implementation, the first key character indicates a placeholder for the alarm tone code header template.

[0013] In an optional implementation, the step of configuring the alarm tone code source file template based on the second parameter information to obtain the target alarm tone code source file includes: Run the second script; Determine the second key character in the alarm tone code source file template that indicates the processing logic function corresponding to each alarm tone; Find the parameter information corresponding to the second script from the alarm tone configuration table and use it as the second parameter information; Replace the second key character in the alarm tone code source file template with the second parameter information to obtain the target alarm tone code header file.

[0014] In an optional implementation, the second key character indicates a placeholder in the alarm tone code source file template.

[0015] In an optional implementation, the method further includes: Obtain each alarm tone; For each alarm tone, determine the corresponding configuration attribute information; An alarm tone configuration table is constructed based on each alarm tone and its corresponding configuration attribute information.

[0016] Secondly, embodiments of this application provide a car alarm sound configuration device, the device comprising: The acquisition module is used to acquire the alarm tone configuration table; The determination module is used to determine the alarm tone code template; The code generation module is used to generate codes for each of the alarm tones based on the alarm tone configuration table and the alarm tone code template. The configuration module is used to configure the car alarm sounds based on the codes of each alarm sound.

[0017] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the car alarm sound configuration method.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the vehicle alarm sound configuration method.

[0019] This application has the following beneficial effects: This application obtains an alarm tone configuration table, determines an alarm tone code template, generates codes for each alarm tone based on the configuration table and code template, and configures the vehicle's alarm tones based on these codes. By combining Excel spreadsheet configuration and code template files, the application automatically generates the underlying CAN signal logic processing code for the alarm tones based on the configuration table and code template, and can configure the vehicle's alarm tones based on this code. This improves the efficiency of both alarm tone code generation and alarm tone configuration. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is one of the prior art hardware schematic diagrams provided in the embodiments of the present invention; Figure 2 This is the second prior art hardware schematic diagram provided for an embodiment of the present invention; Figure 3 The third prior art hardware schematic diagram provided for the embodiments of the present invention; Figure 4 This is a schematic diagram of the alarm tone message format that the MCU uploads to the SOC via the SPI communication protocol. Figure 5 A block diagram of an electronic device provided in an embodiment of the present invention; Figure 6 This is one of the flowcharts illustrating a method for configuring a car alarm sound according to an embodiment of the present invention; Figure 7 This is a schematic representation of the alarm tone configuration provided in the embodiments of the present invention; Figure 8This is a second schematic flowchart illustrating a method for configuring a car alarm sound according to an embodiment of the present invention. Figure 9 This is a third flowchart illustrating a method for configuring a car alarm sound according to an embodiment of the present invention. Figure 10 This is a schematic diagram of the alarm tone code header file template provided in an embodiment of the present invention; Figure 11 This is the fourth flowchart illustrating a method for configuring a car alarm sound according to an embodiment of the present invention. Figure 12 This is a schematic diagram of the alarm tone code source file template provided in an embodiment of the present invention; Figure 13 This is the fifth flowchart illustrating a method for configuring a car alarm sound according to an embodiment of the present invention. Figure 14 This is a structural block diagram of a car alarm sound configuration device provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0023] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0024] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0025] In the description of this invention, it should be noted that if terms such as "upper," "lower," "inner," or "outer" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship in which the product of this invention is usually placed, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0026] Furthermore, the terms "first" and "second" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0027] In the description of this application, it should also be noted that, unless otherwise expressly specified and limited, the terms "set up," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0028] Extensive research by the inventors revealed that there are generally two implementation schemes for playing warning alarm sounds in smart cockpits, but they are essentially the same: using the audio I2S transmission protocol to control a DSP power amplifier driver chip and external speaker peripherals to play the alarm sounds. The difference lies in the design of the DSP power amplifier driver chip. Scheme one involves integrating it directly with the cockpit MCU main control chip onto a single PCB motherboard. The MCU main control chip communicates with the DSP power amplifier driver chip via the I2S transmission protocol, allowing the MCU to directly control the DSP power amplifier chip peripherals and drive the speakers to produce sound. The hardware schematic connection is shown below. Figure 1 As shown and Figure 2 As shown.

[0029] Another mainstream solution currently on the market is to integrate the DSP power amplifier driver chip and the SOC main control chip onto a single PCB motherboard, with the SOC controlling the speaker to play the alarm tone. This solution also requires the use of the SPI communication protocol between the MCU and the SOC. The MCU receives the CAN signal from the vehicle, judges the CAN signal, executes the relevant alarm tone algorithm, and then serializes the alarm tone using an encapsulated protocol message format before sending it to the SOC. Upon receiving the alarm tone message, the SOC deserializes the received message, and the SOC middleware broadcasts the relevant alarm tone message interface to the audio module. Finally, the audio module running on the SOC parses and processes the reported alarm tone attributes, controlling the DSP power amplifier chip peripherals to drive the speaker to play the corresponding alarm tone based on the number of times different alarm tones are played, the playback interval period, the maximum playback time, and the different audio file types corresponding to the alarm tone. The hardware schematic connection method is as follows: Figure 3 As shown.

[0030] The alarm tone message format uploaded by the MCU to the SOC via the SPI communication protocol is as follows: Figure 4 As shown.

[0031] Since most of the signals on a car body use CAN signals, the logic for triggering alarm tones still requires the MCU chip's CAN control receiver to process the transmitted and received CAN signals. Both solutions share a common characteristic: because most automotive communication signals are primarily CAN-based, with a small portion currently using Ethernet, the logic for handling various alarm tone triggers involves the underlying MCU receiving the CAN signal and then processing it using appropriate algorithmic logic.

[0032] With the continuous development of intelligence in the current new energy vehicle market, more and more components are being installed on actual vehicles. Consequently, the number of functions requiring car alarm sounds is also gradually increasing, from the original dozens of alarm sounds to the hundreds. In current solutions, the underlying logic code for processing alarm sound CAN signals uses a single encoding strategy for each alarm sound's CAN signal processing logic, and many of the implemented CAN signal processing logic strategies have similar functions.

[0033] Therefore, the current solutions for playing alarm sounds on in-vehicle systems involve repetitive coding, leading to tedious work and low efficiency.

[0034] In view of the aforementioned problems, this embodiment provides a vehicle alarm tone configuration device, electronic device, and storage medium. It can obtain an alarm tone configuration table, determine an alarm tone code template, generate codes for each alarm tone based on the configuration table and code template, and configure the vehicle alarm tones based on these codes. By combining an Excel spreadsheet configuration and a code template file, it automatically generates the implementation code for the underlying CAN signal logic processing of the alarm tones based on the configuration table and code template, and can configure the vehicle alarm tones based on these codes. This improves the efficiency of generating vehicle alarm tone codes and configuring vehicle alarm tones. The solution provided in this embodiment will be described in detail below.

[0035] This embodiment provides an electronic device that can configure car alarm sounds. In one possible implementation, the electronic device can be a user terminal, such as, but not limited to, a server, smartphone, personal computer (PC), tablet computer, personal digital assistant (PDA), mobile internet device (MID), etc.

[0036] Please refer to Figure 5 , Figure 5 This is a schematic diagram of the structure of the electronic device 100 provided in the embodiments of this application. The electronic device 100 may further include... Figure 5 The more or fewer components shown, or having the same Figure 5 The different configurations shown. Figure 5 The components shown can be implemented using hardware, software, or a combination thereof.

[0037] The electronic device 100 includes a car alarm sound configuration device 110, a memory 120, and a processor 130.

[0038] The components of the memory 120 and processor 130 are electrically connected directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines. The car alarm sound configuration device 110 includes at least one software function module that can be stored in the memory 120 in the form of software or firmware or embedded in the operating system (OS) of the electronic device 100. The processor 130 is used to execute the executable modules stored in the memory 120, such as the software function modules and computer programs included in the car alarm sound configuration device 110.

[0039] The memory 120 may be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory 120 is used to store programs, and the processor 130 executes the programs after receiving execution instructions.

[0040] Please refer to Figure 6 , Figure 6 For application Figure 5 The flowchart below shows a method for configuring an electronic device 100 for a car alarm sound. The method includes detailed explanations of each step.

[0041] S201: Get the alarm tone configuration table.

[0042] S202: Determine the alarm tone code template.

[0043] S203: Generate codes for each alarm tone based on the alarm tone configuration table and alarm tone code template.

[0044] S204: Configure the car alarm sounds based on the codes of each alarm tone.

[0045] like Figure 7 The table shown is the alarm tone configuration table. This table includes configuration attribute information for different alarm tones, such as: alarm tone ID definition, alarm tone ID index number, alarm tone usage flag, whether the alarm tone supports offline configuration, alarm tone operating power mode, alarm tone operating power conditions, alarm tone primary priority, alarm tone sub-priority, whether alarm tones with the same priority have preemption functionality, alarm tone and text alarm binding synchronization flag, playback strategy after an alarm tone is interrupted, alarm tone playback direction signal, number of playbacks, periodic interval playback duration, maximum playback duration, alarm tone type, trigger signal type, and the corresponding triggering algorithm logic for the alarm tone.

[0046] Based on the needs of different projects, the configuration attribute information of different alarm sounds can be obtained and configured into the alarm sound configuration table in chimes_configure_table.xlsx.

[0047] Based on the various attribute information of each alarm tone configured in the alarm tone configuration table, the automated script file and alarm tone code template corresponding to the alarm tone are run, and the alarm tone-related code is automatically generated in the specified directory.

[0048] When configuring different alarm tones later, the system configuration management engineer only needs to configure and maintain the alarm tone table configuration table chimes_configure_table.xlsx according to the requirements to generate the implementation code for the logic processing of the alarm tone CAN signal for different projects.

[0049] Based on the alarm tone configuration table and alarm tone code template, there are multiple ways to generate the code for each alarm tone. In one implementation method, such as... Figure 8 As shown, it includes the following steps: The alarm tone code template includes an alarm tone code header file template and an alarm tone code source file template.

[0050] S301: Retrieve the automation script corresponding to the alarm tone configuration.

[0051] The automation script includes a first script and a second script.

[0052] S302: Run the first script to obtain the first parameter information in the alarm tone configuration table.

[0053] S303: Configure the alarm tone header file template based on the first parameter information to obtain the target alarm tone header file.

[0054] S304: Run the second script to obtain the second parameter information from the alarm tone configuration table.

[0055] S305: Configure the alarm tone code source file template based on the second parameter information to obtain the target alarm tone code source file.

[0056] S306: Generate the code for each alarm tone based on the target alarm tone code header file and the target alarm tone code source file.

[0057] Currently, the MCU side mainly uses C language to implement the code logic, which includes the generation and definition of some variables, the definition of enumeration structure, or the implementation and generation of algorithm logic code. Therefore, in the alarm tone code template, the underlying framework code of the alarm tone is mainly combined to generate the underlying CAN signal triggering function logic code of each alarm tone. The generation principle is based on the content in the alarm tone code template file.

[0058] The target alarm tone header file mainly implements different configuration attributes for each alarm tone, generates the configuration structure of the alarm tone according to a fixed code format, and defines the function declarations for the alarm tone function logic.

[0059] The target alarm tone code source file mainly implements the definition of variables needed for each alarm tone, the corresponding initialization function for each alarm tone, the underlying processing logic function for each alarm tone, and the generation of logic function code for custom processing of alarm tones.

[0060] The first script corresponds to the alarm tone code header file template, and the second script corresponds to the alarm tone code source file template. The first script retrieves the first parameter information from the alarm tone configuration table. This first parameter information is used to generate the alarm tone configuration structure and function declarations for the alarm tone's functional logic, according to a fixed code format, based on the different configuration attributes of each alarm tone. Based on the first parameter information, the alarm tone code header file template is configured to obtain the target alarm tone code header file, enabling it to perform the aforementioned functions. The second script retrieves the second parameter information from the alarm tone configuration table. This second parameter information is used to define the variables needed for each alarm tone, the corresponding initialization function for each alarm tone, the underlying processing logic function for each alarm tone, and the logic function code for custom processing of the alarm tone. Based on the second parameter information, the alarm tone code source file template is configured to obtain the target alarm tone code source file, enabling it to perform the aforementioned functions.

[0061] There are several ways to configure the alarm tone header file template based on the first parameter information to obtain the target alarm tone header file. In one implementation, such as... Figure 9 As shown, it includes the following steps: S401: Run the first script.

[0062] S402: Determine the first key character in the alarm tone code header file template.

[0063] S403: Search the alarm tone configuration table for the parameter information corresponding to the first script and use it as the first parameter information.

[0064] S404: Replace the first key character in the alarm tone code header file template with the first parameter information to obtain the target alarm tone code header file.

[0065] For example, by running the first script, the alarm tone code header file template is opened, and the first keyword in the alarm tone code header file template is searched, for example, such as... Figure 10 The circled area above, [!CODE “chimes_id_define]", after successfully matching the string, reads the parameter information from the first script in conjunction with the alarm tone configuration table chimes_configure_table.xlsx, and uses it as the first parameter information. The first parameter information corresponding to the first script is all the alarm tone ID attributes configured in the alarm tone configuration table. All the alarm tone ID attributes configured in the alarm tone configuration table are read and written into a dictionary array for storage. The contents of the dictionary array are then written into the alarm tone code header file template at the location matching [!CODE “chimes_id_define] . Similarly, other configured attributes are written to the specific locations in the alarm tone code header file template in the same way. Finally, after all the configuration attributes that need to be written into the header file are written, the corresponding header file chimes_mgr_cfg.h is generated and output to the specified directory to obtain the target alarm tone code header file.

[0066] There are several ways to configure the alarm tone code source file template based on the second parameter information to obtain the target alarm tone code source file. In one implementation method, such as... Figure 11 As shown, it includes the following steps: S501: Run the second script.

[0067] S502: Determine the second key character in the alarm tone code source file template that indicates the processing logic function corresponding to each alarm tone.

[0068] S503: Search the alarm tone configuration table for the parameter information corresponding to the second script and use it as the second parameter information.

[0069] S504: Replace the second key character in the alarm tone code source file template with the second parameter information to obtain the target alarm tone code header file.

[0070] For example, by running the second script, the alarm tone code source file template is opened, and the second key character is searched within the alarm tone code source file template, for example, such as... Figure 12 The circled location [!CODE “chimes_handle_function]] is used to search for and match the string. After this, the trigger signal type corresponding to the configured alarm tone is read from the chimes_configure_table.xlsx alarm tone configuration table and used as the second parameter information.

[0071] Currently, the configurable and supported methods include triggering via CAN signal, triggering via I / O port hardware level signal, triggering via internal message interface, and triggering via Ethernet SomeIP message interface.

[0072] By determining the corresponding signal trigger type, then determining the configured algorithm logic processing strategy, and finally generating the corresponding alarm tone and its own alarm tone algorithm logic processing function for the corresponding trigger signal type.

[0073] After polling all configured alarm tone logic processing strategies, the underlying signal logic processing functions for all alarm tones can be generated. Finally, the second parameter information is written into the corresponding alarm tone code source file template chimes_mgr_app.c, and then output to the specified directory to obtain the target alarm tone code header file.

[0074] There are several ways to construct an alarm tone configuration table. In one implementation, such as... Figure 13 As shown, it includes the following steps: S601: Obtain all alarm tones.

[0075] S602: For each alarm tone, determine the configuration attribute information corresponding to the alarm tone.

[0076] S603: Construct an alarm tone configuration table based on each alarm tone and its corresponding configuration attribute information.

[0077] The designed alarm tone configuration table chimes_configure_table.xlsx mainly includes the following alarm tone configuration attributes: alarm tone ID definition, alarm tone ID index number, alarm tone usage flag, alarm tone offline configuration support, alarm tone operating power mode, alarm tone operating power conditions, alarm tone primary priority, alarm tone sub-priority, whether the same priority has preemption function, alarm tone and text alarm binding synchronization flag, playback strategy after the alarm tone is interrupted, alarm tone playback direction signal, number of playbacks, periodic interval playback duration, maximum playback duration, alarm tone type, trigger signal type, and corresponding alarm tone triggering function algorithm logic, etc.

[0078] Please refer to Figure 14 This application embodiment also provides an application for Figure 1 The electronic device 100 includes a car alarm sound configuration device 110, which comprises: Module 111 is used to obtain the alarm tone configuration table; Module 112 is used to determine the alarm tone code template; The code generation module 113 is used to generate codes for each of the alarm tones based on the alarm tone configuration table and the alarm tone code template; Configuration module 114 is used to configure the car alarm sounds based on the codes of each alarm sound.

[0079] This application also provides an electronic device 100, which includes a processor 130 and a memory 120. The memory 120 stores computer-executable instructions, which, when executed by the processor 130, implement the car alarm sound configuration method.

[0080] This application embodiment also provides a computer-readable storage medium storing a computer program, which, when executed by the processor 130, implements the car alarm sound configuration method.

[0081] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0082] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. If the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0083] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0084] The above descriptions are merely various embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for configuring a car alarm sound, characterized in that, The method includes: Obtain the alarm tone configuration table; Determine the alarm tone code template; Based on the alarm tone configuration table and the alarm tone code template, generate the code for each of the alarm tones; Configure the car alarm sounds based on the codes for each alarm sound.

2. The method according to claim 1, characterized in that, The alarm tone code template includes an alarm tone code header file template and an alarm tone code source file template. The step of generating the code for each alarm tone based on the alarm tone configuration table and the alarm tone code template includes: Obtain the automated script corresponding to the alarm tone configuration, wherein the automated script includes a first script and a second script; Run the first script to obtain the first parameter information in the alarm tone configuration table; Configure the alarm tone header file template based on the first parameter information to obtain the target alarm tone header file; Run the second script to obtain the second parameter information from the alarm tone configuration table; Configure the alarm sound code source file template based on the second parameter information to obtain the target alarm sound code source file; Based on the target alarm tone header file and the target alarm tone source file, the code for each alarm tone is generated.

3. The method according to claim 2, characterized in that, The step of configuring the alarm tone header file template based on the first parameter information to obtain the target alarm tone header file includes: Run the first script; Identify the first key character in the alarm tone code header file template; The parameter information corresponding to the first script is retrieved from the alarm tone configuration table and used as the first parameter information; Replace the first key character in the alarm tone code header file template with the first parameter information to obtain the target alarm tone code header file.

4. The method according to claim 3, characterized in that, The first key character indicates a placeholder for the alarm tone code header file template.

5. The method according to claim 2, characterized in that, The step of configuring the alarm tone code source file template based on the second parameter information to obtain the target alarm tone code source file includes: Run the second script; Determine the second key character in the alarm tone code source file template that indicates the processing logic function corresponding to each alarm tone; Find the parameter information corresponding to the second script from the alarm tone configuration table and use it as the second parameter information; Replace the second key character in the alarm tone code source file template with the second parameter information to obtain the target alarm tone code header file.

6. The method according to claim 5, characterized in that, The second key character indicates a placeholder in the source file template of the alarm tone code.

7. The method according to claim 1, characterized in that, The method further includes: Obtain each alarm tone; For each alarm tone, determine the corresponding configuration attribute information; An alarm tone configuration table is constructed based on each alarm tone and its corresponding configuration attribute information.

8. A car alarm sound configuration device, characterized in that, The device includes: The acquisition module is used to acquire the alarm tone configuration table; The determination module is used to determine the alarm tone code template; The code generation module is used to generate codes for each of the alarm tones based on the alarm tone configuration table and the alarm tone code template. The configuration module is used to configure the car alarm sounds based on the codes of each alarm sound.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method according to any one of claims 1-7.

10. A storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method described in any one of claims 1-7.

Images