Low-speed bus multi-slave management method and system based on Linux system and vehicle

Abstract

The embodiment of the present disclosure provides a low-speed bus multi-slave device management method and system based on a Linux system and a vehicle, and relates to the technical field of intelligent devices. The method comprises the following steps: determining an online base device through a device tree node, and registering a base device driver of each base device based on a bus type corresponding to the base device; when a device driver is loaded, writing device description information of a used device into a common static array; when a detection function of the base device driver is called, traversing device tree nodes of each used device, judging whether the used device is online based on the device description information in the common static array, and registering a device function interface of the base device driver according to the device description information when it is judged that the used device is online; and in response to a calling instruction of a target used device, reading device description information of the target used device through the common static array and performing a corresponding function operation. The overall framework of the present application is light and has strong versatility for multiple external devices.

Description

Technical Field

[0001] This invention relates to the field of intelligent device technology, and more specifically to a low-speed bus multi-slave device management method, system, and vehicle based on the Linux system. Background Technology

[0002] With the rapid development of smart devices and IoT technologies, the Linux system, with its significant advantages such as open source, customizability, high stability, and good hardware compatibility, has been widely used in many key areas such as embedded systems, servers, edge computing, and consumer electronics. Character devices, as the most diverse of the three types of devices in the Linux system, are widely used for information exchange between devices due to their relatively small data throughput and real-time characteristics.

[0003] Existing device driver management solutions are applicable to a single framework and lack versatility for various peripherals on multiple low-speed buses, such as temperature sensors, real-time clocks, and humidity sensors. Furthermore, the peripheral code writing process suffers from redundant implementation of framework components, leading to code redundancy. Summary of the Invention

[0004] In view of the shortcomings of the prior art, the purpose of this application is to provide a low-speed bus multi-slave device management method, system and vehicle based on Linux system. The overall framework is lightweight and has low code redundancy, and can be widely used in low-speed bus peripherals with hardware-level device addressing capabilities.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: In a first aspect, embodiments of this application provide a low-speed bus multi-slave device management method based on a Linux system. The method includes: determining online base devices through device tree nodes, and registering a base device driver for each base device based on the bus type corresponding to the base device; when a device driver is loaded, writing the device description information of the device to a public static array; when the probe function of the base device driver is called, traversing the device tree nodes of each device, determining whether the device is online based on the device description information in the public static array, and registering the device function interface of the base device driver according to the device description information when the device is determined to be online; and responding to a call instruction from the target device, reading the device description information of the target device through the public static array and performing corresponding functional operations.

[0006] Based on the aforementioned technical methods, a unified management framework is constructed for various low-speed buses by identifying base devices through a device tree and registering base drivers according to bus type. When loading a device driver, device description information is centrally written into a common static array, achieving unified management of multiple slave device information. During the base driver detection phase, device tree nodes are traversed to register functional interfaces, decoupling hardware topology identification from driver function mounting, enabling unified scheduling and execution of functional operations. This approach offers advantages such as a lightweight framework, reduced code redundancy, and strong versatility across multiple peripherals.

[0007] Furthermore, the online base devices are identified through the device tree nodes, and the base device driver for each base device is registered based on the bus type corresponding to the base device. This includes: matching and determining the corresponding base device driver based on the compatible attribute of the device tree node; obtaining the bus type of the base device, selecting the corresponding driver interface based on the bus type, and passing the driver configuration information as a parameter to the registration interface for registration; and calling the probe function of the base device driver to initialize the base device driver and register the structure content.

[0008] Based on the above technical means, the base device driver is determined by matching the compatibility attributes of the device tree nodes. Then, the corresponding driver registration interface is selected according to the bus type and the configuration information is passed in, so that different low-speed buses can be included in the same framework management, achieving accurate device identification, multi-bus compatibility and interface standardization.

[0009] Furthermore, the device description information includes the device name identifier, online status flag, and a set of function interface callback functions.

[0010] Based on the above technical means, the three types of core information are uniformly encapsulated in the device description information, which facilitates centralized management and rapid retrieval of the public array.

[0011] Furthermore, when loading using a device driver, the device description information of the device is written into a public static array, including: when loading using a device driver, setting the device name identifier and online status flag in the private static array of the device, populating the function interface callback function set in the private static array; and copying the private static array to the public static array.

[0012] By separating the private array from the public array using the aforementioned technical means, developers only need to fill in the private array and complete the registration through a unified copy, which can lower the development threshold.

[0013] Furthermore, the device tree nodes of each user device are traversed, and the online status of the user device is determined based on the device description information in the public static array. This includes: calling the probe function of the base device driver to iterate through the device tree nodes of each user device; identifying the device name identifier and online status flag from the public static array to determine whether the user device is online; and if the user device is online, setting the attribute flag of the online status flag in the public static array to 1.

[0014] Based on the above technical means, the online status is confirmed by both device tree traversal and public array verification, hardware topology identification and driver management are decoupled, and the configuration is flexible.

[0015] Furthermore, in response to the invocation command of the target device, the device description information of the target device is read through a public static array and the corresponding functional operation is executed, including: receiving the invocation command from the user-mode application, wherein the invocation command carries the target name identifier and the target operation type identifier of the target device; matching the target name identifier with the device name identifier in the public static array to determine the target device; determining whether the target device is online based on the online status flag in the public static array; when the target device is online, reading the set of function interface callback functions in the public static array and executing the corresponding function interface callback function according to the target operation type identifier.

[0016] Based on the above technical means, the user space initiates a call by carrying the device name and operation type through a unified interface. After matching with a public array and online verification, the callback is executed, thus standardizing the call process.

[0017] Furthermore, the registration of base device drivers for each base device includes both static and dynamic configuration methods. In the static configuration method, the driver is initialized through a static interface during the Linux system kernel boot process, while in the dynamic configuration method, the driver is loaded through a dynamic interface during Linux system runtime.

[0018] Based on the above technical means, this application supports both static loading at kernel startup and dynamic loading at runtime, adapting to different deployment scenarios and offering flexible configuration.

[0019] Furthermore, this low-speed bus multi-slave device management method based on the Linux system also includes: responding to the deregistration command of the base device driver, calling the deregistration function, matching and determining the corresponding base device driver through the compatible attribute of the device tree node; obtaining the bus type of the base device, selecting the corresponding deregistration interface based on the bus type, and passing the driver configuration information as a parameter to the deregistration interface; and calling the remove function of the base device driver to deregister the base device driver.

[0020] Based on the above technical means, a complete deregistration mechanism symmetrical to the registration process is provided. By matching compatibility attributes and selecting the deregistration interface based on bus type, driver safe uninstallation and resource reclamation are achieved.

[0021] Secondly, this application provides a low-speed bus multi-slave device management system for a Linux system. This system includes: a base device driver registration module, used to determine online base devices through device tree nodes and register the base device driver for each base device based on the bus type corresponding to the base device; a device driver loading module, used to write the device description information of the used device into a public static array when the device driver is loaded; a device function interface registration module, used to traverse the device tree nodes of each used device when the probe function of the base device driver is called, determine whether the used device is online based on the device description information in the public static array, and register the device function interface of the base device driver according to the device description information when the used device is determined to be online; and a device function interface calling module, used to read the device description information of the target used device through the public static array and execute the corresponding function operation in response to the calling instruction of the target used device.

[0022] Thirdly, this application provides a vehicle, including a body and a low-speed bus multi-slave device management system based on a Linux system as described in the second aspect.

[0023] The beneficial effects of this invention are as follows: This application constructs a unified multi-bus framework by registering base drivers separately according to bus type. A common static array centrally manages the device names, online status, and function callbacks of all slave devices. Device tree traversal is used to confirm hardware online status, and private array copying completes function interface registration, thus decoupling hardware topology identification from driver function mounting. User-space operations are executed through a unified interface and scheduled via the common array. The overall framework is lightweight and has low code redundancy, making it widely applicable to low-speed bus peripherals with hardware-level device addressing capabilities. Attached Figure Description

[0024] Figure 1 A flowchart illustrating a low-speed bus multi-slave device management method based on a Linux system, provided in this embodiment of the disclosure; Figure 2 A schematic flowchart of a base device driver registration method provided in an embodiment of this disclosure; Figure 3 A schematic flowchart of a base device driver deregistration method provided in an embodiment of this disclosure; Figure 4 A schematic flowchart illustrating a device function interface registration method provided in this embodiment of the disclosure; Figure 5A schematic diagram illustrating a method for invoking a user-mode application as provided in an embodiment of this disclosure; Figure 6 A schematic diagram of a low-speed bus multi-slave device management system based on Linux system provided in this disclosure embodiment; Figure 7 This is a schematic diagram of the structure of a computing device provided in an embodiment of the present disclosure. Detailed Implementation

[0025] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0026] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0027] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0028] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0029] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0030] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0031] This disclosure provides a method for managing multiple slave devices on a low-speed bus based on a Linux system. It identifies base devices through a device tree and registers base drivers according to bus type, building a unified management framework for various low-speed buses. When a device driver is loaded, device description information is centrally written into a common static array, achieving unified management of multiple slave device information. During the base driver detection phase, the device tree nodes are traversed to register functional interfaces, decoupling hardware topology identification from driver function mounting, enabling unified scheduling and execution of functional operations. This method offers advantages such as a lightweight framework, reduced code redundancy, and strong versatility across multiple peripherals.

[0032] The method will be described below with reference to specific embodiments.

[0033] Figure 1 This is a flowchart illustrating a low-speed bus multi-slave device management method based on a Linux system, provided as an embodiment of this disclosure. This method can be executed by a Linux-based low-speed bus multi-slave device management device, which can be implemented in software and / or hardware, and is generally integrated into a computing device. Figure 1 As shown, the method includes: S101: Identify the online base devices through the device tree nodes, and register the base device driver for each base device based on the bus type corresponding to the base device.

[0034] The computer device in this application registers the base device driver. Specifically, it determines the online base devices through device tree nodes and registers the base device driver for each base device based on the bus type corresponding to the base device.

[0035] After the driver entry function is loaded, the online base devices are determined by parsing the device tree nodes. The device tree is a data structure in Linux used to describe the hardware topology. Each hardware device corresponds to a device tree node, and each device tree node contains various information describing the hardware device.

[0036] Furthermore, after identifying the online base device, the bus type attribute of the base device is obtained. The bus type attribute indicates the type of bus communication protocol used by the base device, including I2C bus, SPI bus, 1-Wire bus, and Local Area Network Bus (LIN), etc. Different types of buses correspond to different physical layer protocols, communication timing, and control methods.

[0037] Furthermore, the corresponding driver registration interface is selected based on the bus type, and the driver configuration information is passed as a parameter to the registration interface to complete the registration of the base device driver. For example, the driver registration interface for I2C bus type is i2c_register_driver, the driver registration interface for SPI bus type is spi_register_driver, the driver registration interface for 1-Wire bus type is w1_register_driver, and the driver registration interface for LIN bus type is platform_driver_register.

[0038] In one possible implementation, the online base devices are determined through device tree nodes, and the base device driver for each base device is registered based on the bus type corresponding to the base device. Specifically, the corresponding base device driver is determined by matching the compatible attribute of the device tree node; the bus type of the base device is obtained, the corresponding driver interface is selected based on the bus type, and the driver configuration information is passed as a parameter to the registration interface for registration; the probe function of the base device driver is called to initialize the base device driver and register the structure content.

[0039] Specifically, please refer to Figure 2 , Figure 2 This is a schematic flowchart of a base device driver registration method provided in an embodiment of this disclosure.

[0040] like Figure 2 As shown, the device tree nodes are obtained, and each node in the device tree is traversed. The `compatible` attribute is matched with the node pointer. The `compatible` attribute is a list of strings representing device information. The `compatible` attribute is matched with the device driver to determine which device driver can manage the hardware device. Specifically, multiple device tree nodes are checked in a loop. When the `compatible` attribute of a device tree node matches a base device driver, the base device is identified as an online base device, and the base device driver performs subsequent management and operations on the hardware device.

[0041] Furthermore, the `bus_type` attribute of the base device is obtained to determine the bus type. Based on the bus type, the corresponding driver registration interface is selected, and the driver's configuration attributes are sent as parameters to complete the base device driver registration. After the base device driver registration is complete, the probe function pointer is called, pointing to the initialization function after the base device driver has been successfully loaded, and the contents of the `file_operations` structure are registered.

[0042] Based on the above technical means, the base device driver is determined by matching the compatibility attributes of the device tree nodes. Then, the corresponding driver registration interface is selected according to the bus type and the configuration information is passed in, so that different low-speed buses can be included in the same framework management, achieving accurate device identification, multi-bus compatibility and interface standardization.

[0043] Similarly, the deregistration process of a base device driver is the reverse of the registration process. In one possible implementation, the deregistration process of a base device driver is as follows: in response to the deregistration command of the base device driver, the deregistration function is called; the corresponding base device driver is determined by matching the compatible attribute of the device tree node; the bus type of the base device is obtained; the corresponding deregistration interface is selected based on the bus type, and the driver configuration information is passed as a parameter to the deregistration interface; the remove function of the base device driver is called to deregister the base device driver.

[0044] Specifically, please refer to Figure 3 , Figure 3 This is a schematic flowchart of a base device driver deregistration method provided in an embodiment of this disclosure.

[0045] like Figure 3 As shown, the `module_exit` function is called to perform the deregistration operation. This involves obtaining device tree nodes, traversing each node in the device tree, matching them with device drivers using the `compatible` attribute, and iterating through multiple device tree nodes. When the `compatible` attribute of a device tree node matches a base device driver, the base device is identified as an online base device. The `bus_type` attribute of the base device is obtained to determine the bus type. Based on the bus type, the corresponding driver registration interface is selected, and the driver's configuration attributes are sent as parameters. Finally, the `remove` function of the base device driver is called to perform the deregistration operation of the base device driver.

[0046] Based on the above technical means, a complete deregistration mechanism symmetrical to the registration process is provided. By matching compatibility attributes and selecting the deregistration interface based on bus type, driver safe uninstallation and resource reclamation are achieved.

[0047] In one possible implementation, registering the base device driver for each base device includes both static and dynamic configuration methods. Static configuration is initialized through a static interface during the Linux system kernel boot process. Static configuration is a one-way operation and does not support dynamic unloading or reverse operations; it is primarily used to load necessary core modules. Dynamic configuration is loaded through a dynamic interface during Linux system runtime, supporting flexible loading and unloading of the driver. Understandably, the above base device driver unregistration method only applies to dynamically configured base device drivers.

[0048] If the base device driver is initialized through the static configuration interface, it cannot be called repeatedly using the dynamic interface; conversely, if the driver is loaded using the dynamic interface, the static interface will not process the driver again.

[0049] Based on the above technical means, this application supports both static loading at kernel startup and dynamic loading at runtime, adapting to different deployment scenarios and offering flexible configuration.

[0050] S102: When the device driver is loaded, the device description information of the device is written into a public static array.

[0051] When a device driver is loaded, the computer device of this application writes the device description information of the device to a public static array. The device being used is an external hardware device mounted under the base device that actually performs specific business functions; that is, a slave device.

[0052] In one possible implementation, the device description information includes a device name identifier, an online status flag, and a set of function callback functions. The device name identifier is a unique identifier for the device, such as "rtc0" or "temp_sensor1". The online status flag indicates the current online status of the device, such as 1 for online and 0 for offline. The set of function callback functions contains multiple pointers to specific function implementations, such as init for initialization, start for device startup, and stop for device pause.

[0053] In one possible implementation, when the device driver is loaded, the device description information of the device is written into a public static array. Specifically, this includes: when the device driver is loaded, setting the device name identifier and online status flag in the private static array of the device, populating the private static array with a set of function interface callback functions, and copying the private static array to the public static array.

[0054] Specifically, please refer to Figure 4 , Figure 4 This is a flowchart illustrating a device function interface registration method provided in an embodiment of the present disclosure. Figure 4 The right side shows the unified external general interface registration process. For example... Figure 4 As shown in the process steps on the right, each device has a private static array pri_con. When the device driver is loaded, the device name identifier dev_name attribute and the online status flag online_dev attribute are set in the private static array pri_con. The set of function interface callback functions, such as the callback_func attribute, are filled into the private static array pri_con.

[0055] Furthermore, the attributes in the private static array `pri_con` are copied to the public static array `genera_con`. The public static array is the core data structure for globally managing the description information of all devices. For example, the public static array stores the device name identifier, online status flag, and set of function interface callback functions for all devices in a table format.

[0056] By separating the private and public arrays using the aforementioned technical methods, developers only need to fill in the private array, and registration can be completed through a unified copy, thus lowering the development threshold. Furthermore, the three types of core information are uniformly encapsulated within the device description information, facilitating centralized management and rapid retrieval of the public array.

[0057] S103: When the probe function of the base device driver is called, the device tree nodes of each user device are traversed, and the device description information in the public static array is used to determine whether the user device is online. When the user device is determined to be online, the device function interface of the base device driver is registered according to the device description information.

[0058] When the probe function of the base device driver is called, the computer device of this application traverses the device tree nodes of each user device and determines whether the user device is online based on the device description information in the public static array. When it is determined that the user device is online, the computer device of this application registers the device function interface of the base device driver according to the device description information.

[0059] Specifically, after the base device driver is registered, the kernel automatically calls the base device driver's probe function, which is the entry point for device driver initialization. During the execution of the probe function, it iterates through the device tree nodes of each user device attached to the base device. For each device node encountered, it checks whether the user device is online by combining the corresponding device description information in the public static array. If the user device is online, it registers the functional interfaces according to the device description information with the base device driver, completing the device functional interface registration. Complete registration indicates that the user device is in a callable, ready state. If the user device is offline, it is skipped, and its functional interfaces are not registered with the base device driver; the user device is invisible and cannot be called. The process continues until all user devices have been traversed, at which point the next iteration begins.

[0060] In one possible implementation, the device tree nodes of each user device are traversed, and the online status of the user device is determined based on the device description information in the public static array. Specifically, this includes: calling the probe function of the base device driver to iterate through the device tree nodes of each user device; identifying the device name identifier and online status flag from the public static array to determine whether the user device is online; and if the user device is online, setting the attribute flag of the online status flag in the public static array to 1.

[0061] Specifically, please refer to Figure 4 , Figure 4 The left side shows the process for registering device function interfaces. For example... Figure 4 As shown in the flowchart on the left, after the base device driver is registered, the probe function of the base device driver is automatically called to obtain the device tree node of the device being used. The online_dev attribute of the device tree is matched with the dev_name attribute in the public static array of type selectl_dev to determine which device is online. If the device is online, the online attribute flag of the corresponding device row in the public static array general_con will be set to 1, thus confirming the online status of the device and completing the registration and invocation of the functional interface.

[0062] Based on the above technical means, the online status is confirmed by both device tree traversal and public array verification, hardware topology identification and driver management are decoupled, and the configuration is flexible.

[0063] S104: In response to the call command of the target device, read the device description information of the target device through the public static array and perform the corresponding function operation.

[0064] In response to a call instruction from the target device, the computer device of this application reads the device description information of the target device through a public static array and performs the corresponding functional operation. The call instruction is used to instruct the target device to perform a specific function.

[0065] In one possible implementation, in response to a call instruction from the target device, the device description information of the target device is read through a public static array and corresponding functional operations are performed. This includes: receiving a call instruction from a user-mode application, wherein the call instruction carries a target name identifier and a target operation type identifier for the target device; matching the target name identifier with the device name identifier in the public static array to determine the target device; determining whether the target device is online based on the online status flag in the public static array; and when the target device is online, reading the set of function interface callback functions from the public static array and executing the corresponding function interface callback function according to the target operation type identifier.

[0066] Specifically, please refer to Figure 5 , Figure 5 This is a schematic diagram illustrating a method for invoking a user-mode application as provided in an embodiment of this disclosure. Figure 5 As shown, the user-space application initiates a call instruction to a specific base device driver through the ioctl system call. The call instruction is parsed to obtain the target device name identifier and the target operation type identifier. The target name identifier indicates the target device that the application expects to operate on, such as a real-time clock device. The target operation type identifier specifies the specific operation type that the application expects to perform, such as an initialization operation, a start operation, or a stop operation.

[0067] The target name identifier is matched one by one with the device name identifiers in the public static array to determine the target device to be operated by the user-mode application. If a device name identifier that matches the target name identifier is found in the public static array, the row of that device is located, and the online status flag stored in that row is retrieved. If the retrieved online status flag indicates that the target device is online, the set of function interface callback functions stored in that row is retrieved, and the function interface callback function corresponding to the target operation type identifier is matched from the set of function interface callback functions and executed to complete the corresponding hardware operation.

[0068] Based on the above technical means, the user space initiates a call by carrying the device name and operation type through a unified interface. After matching with a public array and online verification, the callback is executed, thus standardizing the call process.

[0069] In one specific implementation, when the SoC's peripherals only support a single Real-Time Clock (RTC) device, configuration needs to be completed in the current kernel driver. Driver-level configuration includes writing and populating a private static array `pri_con`, setting key attributes such as the device name `dev_name`, online status, and callback function pointer `callback_func`. Device tree configuration involves configuring the `online_dev` attribute for the RTC device node in the device tree to ensure consistency between hardware description and driver logic, while setting the `compatible` attribute for the base device driver to ensure correct loading and operation. The runtime flow includes: when an application needs to use RTC functionality, the system first determines whether the device is online based on the `dev_name` and `online` attributes. If the device is online, it accesses and executes the corresponding function callback functions through the public static array, such as initialization (`init`), device startup (`start`), and device stop (`stop`).

[0070] This application constructs a unified multi-bus framework by registering base drivers separately according to bus type. A common static array centrally manages the device names, online status, and function callbacks of all slave devices. Device tree traversal confirms hardware online status, and private array copying completes function interface registration, thus decoupling hardware topology identification from driver function mounting. User-space operations are executed through a unified interface and scheduled via the common array. The overall framework is lightweight and has low code redundancy, making it widely applicable to low-speed bus peripherals with hardware-level device addressing capabilities.

[0071] To implement the above embodiments, this disclosure also proposes a low-speed bus multi-slave device management system based on the Linux system.

[0072] Figure 6 This is a schematic diagram of a low-speed bus multi-slave device management system based on a Linux system, provided as an embodiment of this disclosure. This device can be implemented by software and / or hardware and is generally integrated into a computing device. Figure 6 As shown, this low-speed bus multi-slave device management system based on Linux includes: The base device driver registration module 601 is used to determine the online base devices through the device tree nodes and register the base device driver for each base device based on the bus type corresponding to the base device.

[0073] The device driver loading module 602 is used to write the device description information of the device to a public static array when the device driver is loaded.

[0074] The device function interface registration module 603 is used to traverse the device tree nodes of each user device when the probe function of the base device driver is called, determine whether the user device is online based on the device description information in the public static array, and register the device function interface of the base device driver according to the device description information when the user device is determined to be online.

[0075] The device function interface call module 604 is used to respond to the call command of the target device, read the device description information of the target device through a public static array and perform the corresponding function operation.

[0076] In one possible implementation, the base device driver registration module 601 includes: a driver matching unit, used to match and determine the corresponding base device driver based on the compatible attribute of the device tree node; a driver registration unit, used to obtain the bus type of the base device, select the corresponding driver interface based on the bus type, and pass the driver configuration information as a parameter to the registration interface for registration; and an initialization unit, used to call the probe function of the base device driver, initialize the base device driver, and register the structure content.

[0077] In one possible implementation, the device driver loading module 602 includes: device description information including device name identifier, online status flag, and a set of function interface callback functions.

[0078] In one possible implementation, the device driver loading module 602 includes: a driver loading unit, used to set the device name identifier and online status flag in the private static array of the device when loading with the device driver, and to populate the private static array with a set of function interface callback functions; and a copying unit, used to copy the private static array to the public static array.

[0079] In one possible implementation, the device function interface registration module 603 includes: a calling unit for calling the probe function of the base device driver to iterate through the device tree nodes of each user device; an online determination unit for identifying the device name identifier and online status flag from the public static array to determine whether the user device is online; and a setting unit for setting the attribute flag of the online status flag in the public static array to 1 if the user device is online.

[0080] In one possible implementation, the device function interface calling module 604 includes: a receiving unit for receiving operation instructions from a user-mode application, wherein the operation instructions carry a target name identifier and a target operation type identifier for the target device; a matching unit for matching the target name identifier with device name identifiers in a public static array to determine the target device; and an execution unit for determining whether the target device is online based on the online status flag in the public static array, and when the target device is online, reading the function interface callback function set in the public static array and executing the corresponding function interface callback function according to the target operation type identifier.

[0081] In one possible implementation, the base device driver registration module 601 includes: registering the base device driver for each base device, including static configuration and dynamic configuration. The static configuration method is initialized through a static interface during the Linux system kernel startup process, while the dynamic configuration method is loaded through a dynamic interface during Linux system runtime.

[0082] In one possible implementation, the low-speed bus multi-slave device management system based on the Linux system further includes: using a device driver deregistration module to respond to the deregistration command of the base device driver, calling the deregistration function, matching and determining the corresponding base device driver through the compatible attribute of the device tree node; obtaining the bus type of the base device, selecting the corresponding deregistration interface based on the bus type, and passing the driver configuration information as a parameter to the deregistration interface; and calling the remove function of the base device driver to deregister the base device driver.

[0083] The low-speed bus multi-slave device management system based on Linux provided in this disclosure can execute the low-speed bus multi-slave device management method based on Linux provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects of executing the method.

[0084] To implement the above embodiments, this disclosure also proposes a computer program product, including a computer program / instructions, which, when executed by a processor, implements the low-speed bus multi-slave device management method based on the Linux system in the above embodiments.

[0085] Figure 7 This is a schematic diagram of the structure of a computing device provided in an embodiment of the present disclosure.

[0086] The following is a detailed reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing the computing device 700 in the embodiments of this disclosure. The computing device 700 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The computing device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0087] like Figure 7 As shown, the computing device 700 may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 702 or a program loaded from memory 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the computing device 700. The processor 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0088] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 709. Communication device 709 allows computing device 700 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7A computing device 700 with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have instead.

[0089] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 709, or installed from memory 708, or installed from ROM 702. When the computer program is executed by processor 701, it performs the functions defined in the Linux-based low-speed bus multi-slave device management system method of embodiments of this disclosure.

[0090] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0091] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0092] The aforementioned computer-readable medium may be included in the aforementioned computing device; or it may exist independently and not assembled into the computing device.

[0093] The aforementioned computer-readable medium carries one or more programs, which, when executed by the computing device, cause the computing device to perform the aforementioned low-speed bus multi-slave device management system method based on the Linux system.

[0094] The computing device can be programmed with computer program code for performing the operations of this disclosure in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0095] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. 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 indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated 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 the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0096] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0097] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0098] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0099] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0100] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0101] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A low-speed bus multi-slave device management method based on a Linux system, characterized by, The method includes: The online base devices are identified through the device tree nodes, and the base device driver for each base device is registered based on the bus type corresponding to the base device. When a device driver is loaded, the device description information of the device being used is written into a public static array; When the detection function of the base device driver is called, the device tree nodes of each user device are traversed, and the user device is determined to be online based on the device description information in the public static array. When the user device is determined to be online, the device function interface of the base device driver is registered according to the device description information. In response to the call command of the target device, the device description information of the target device is read through the public static array and the corresponding functional operation is performed.

2. The low-speed bus multi-slave device management method based on Linux system as described in claim 1, characterized in that, The step of determining online base devices through device tree nodes and registering base device drivers for each base device based on the bus type corresponding to the base device includes: Based on the compatible attribute of the device tree node, the corresponding base device driver is determined by matching; Obtain the bus type of the base device, select the corresponding driver interface based on the bus type, and pass the driver configuration information as a parameter to the registration interface for registration; The probe function of the base device driver is called to initialize the base device driver and register the structure content.

3. The low-speed bus multi-slave device management method based on Linux system as described in claim 1, characterized in that, The device description information includes the device name identifier, online status flag, and a set of function interface callback functions.

4. The low-speed bus multi-slave device management method based on Linux system as described in claim 3, characterized in that, When a device driver is loaded, writing the device description information of the device being used into a public static array includes: When the device driver is loaded, the device name identifier and the online status flag are set in the private static array of the device, and the set of function interface callback functions is filled into the private static array; Copy the private static array to the public static array.

5. The low-speed bus multi-slave device management method based on Linux system as described in claim 3, characterized in that, The step of traversing the device tree nodes of each user device and determining whether the user device is online based on the device description information in the public static array includes: The probe function of the base device driver is called to iterate through the device tree nodes of each user device. The device name identifier and the online status flag are identified from the public static array to determine whether the device is online. If the device is online, the attribute flag of the online status flag in the public static array is set to 1.

6. The low-speed bus multi-slave device management method based on Linux system as described in claim 4, characterized in that, The step of responding to a call command from a target device by reading the device description information of the target device through the public static array and performing corresponding functional operations includes: Receive a call instruction from a user-mode application, wherein the call instruction carries a target name identifier and a target operation type identifier for the target device; The target name identifier is matched with the device name identifier in the public static array to determine the target device. Based on the online status flag in the public static array, it is determined whether the target device is online. When the target device is online, the set of function interface callback functions in the public static array is read, and the corresponding function interface callback function is executed according to the target operation type identifier.

7. The low-speed bus multi-slave device management method based on Linux system as described in claim 1, characterized in that, The registration of the base device driver for each base device includes a static configuration method and a dynamic configuration method. The static configuration method is initialized through a static interface during the Linux system kernel startup process, while the dynamic configuration method is loaded through a dynamic interface during Linux system runtime.

8. The low-speed bus multi-slave device management method based on Linux system as described in claim 2, characterized in that, The method further includes: In response to the deregistration command of the base device driver, the deregistration function is invoked, and the corresponding base device driver is determined by matching the compatible attribute of the device tree node; Obtain the bus type of the base device, select the corresponding deregistration interface based on the bus type, and pass the driver configuration information as a parameter to the deregistration interface; The base device driver is unregistered by calling its remove function.

9. A low-speed bus multi-slave device management system based on Linux, characterized in that, The system includes: The base device driver registration module is used to determine the online base devices through the device tree nodes, and register the base device driver for each base device based on the bus type corresponding to the base device. The device driver loading module is used to write the device description information of the device being used into a public static array when the device driver is loaded. The device function interface registration module is used to traverse the device tree nodes of each user device when the detection function of the base device driver is called, determine whether the user device is online based on the device description information in the public static array, and register the device function interface of the base device driver according to the device description information when the user device is determined to be online. The device function interface call module is used to respond to the call command of the target device, read the device description information of the target device through the public static array, and perform the corresponding function operation.

10. A vehicle, characterized in that, This includes the vehicle body and the low-speed bus multi-slave device management system based on the Linux system as described in claim 9.

Images