A multifunction controller based on SPI bus

Abstract

The application relates to a multifunctional controller based on an SPI bus, which comprises a core control module for packaging an SPI communication protocol frame and a register read-write instruction based on a Linux kernel subsystem; a device class registration module for registering a special device class to manage corresponding special functions through the device class registration module; a first docking module for docking standard functions with the Linux kernel subsystem to drive the standard functions based on an SPI interface and the register read-write instruction; and a second docking module for abstracting non-standard functions into virtual SPI devices and docking the virtual SPI devices with an application layer. Through an innovative modular architecture and a unified management mechanism, the application effectively solves technical problems such as complex development of a multifunctional controller driver, lack of out-of-band management, difficulty in application layer development, and chaotic driver management, and provides an efficient, flexible and easily-extended solution for the development and management of multifunctional SPI peripherals.

Description

Technical Field

[0001] This application relates to the field of multi-functional controller technology based on SPI bus, and more particularly to a multi-functional controller based on SPI bus. Background Technology

[0002] The Linux kernel provides a basic driver framework for single-function SPI peripherals, including the SPI subsystem, gpiolib subsystem, I2C subsystem, and watchdog subsystem, suitable for standalone SPI-GPIO controllers or SPI-I2C bridges. However, in the application scenarios of multi-functional SPI controllers, existing driver technologies have significant shortcomings. During development, each functional module, such as GPIO, I2C, and out-of-band management, needs to implement SPI protocol parsing, register operations, and kernel subsystem interface logic separately. This repetitive work not only consumes a lot of development resources but also requires developers to have a deep understanding of hardware details and multiple kernel subsystem interfaces, resulting in an exceptionally high development threshold. Furthermore, multi-functional out-of-band management controllers typically integrate dedicated out-of-band hardware designs, but existing drivers only focus on basic in-band functions, completely ignoring out-of-band feature adaptation, rendering out-of-band management capabilities ineffective. In addition, due to the lack of dedicated drivers for multi-functional controllers, applications are forced to bypass the kernel subsystem and directly operate the SPI bus, unable to reuse the standardized capabilities provided by the kernel. This not only significantly increases the complexity of application development but also significantly increases system maintenance costs. More notably, for functional modules such as GPIO, I2C, and Watchdog, the industry generally adopts a "split driver" approach, which means developing a separate SPI driver for each module or reusing a single-function driver. This approach causes a serious disconnect between the driver and the hardware entity, leading to resource conflicts, management chaos, and system stability issues. Summary of the Invention

[0003] The following is an overview of the subject matter described in detail herein. This overview is not intended to limit the scope of the claims.

[0004] The main objective of this disclosure is to propose a multi-functional controller based on the SPI bus, which achieves unified protocol encapsulation, SPI transmission queuing, standard function subsystemization, and non-standard function interfaceization. This not only ensures reliable collaboration among the various modules of the controller but also reduces the complexity of driver development and application calls, fully leveraging the hardware characteristics of the multi-functional controller.

[0005] A first aspect of this application provides a multi-functional controller based on an SPI bus, operating in a programmable logic device, the multi-functional controller based on the SPI bus comprising:

[0006] The core control module is used to encapsulate SPI communication protocol frames to provide a standardized SPI interface, and to encapsulate register read and write instructions based on the Linux kernel subsystem. The core control module interacts with the main system through the SPI communication protocol frames.

[0007] The device class registration module communicates with the core control module. The device class registration module is used to register a dedicated device class when the core control module is initialized, so as to manage the corresponding dedicated functions through the device class registration module.

[0008] The first docking module is communicatively connected to the core control module and the device registration module. The first docking module is used to dock the standard functions with the Linux kernel subsystem to drive the standard functions based on the corresponding SPI interface and the corresponding register read and write instructions.

[0009] The second docking module is connected to the core control module and the device class registration module. The second docking module is used to abstract non-standard functions into virtual SPI devices, set the virtual SPI devices in the dedicated device class, and dock the virtual SPI devices with the application layer.

[0010] The multi-functional controller based on the SPI bus provided in this embodiment has at least the following beneficial effects:

[0011] The multi-functional controller based on the SPI bus provided in this embodiment effectively solves a series of technical problems in the prior art, such as complex driver development, lack of out-of-band management, difficulty in application layer development, and chaotic driver management, through its innovative modular architecture and unified management mechanism. It provides an efficient, flexible, and easily expandable solution for the driver development and management of multi-functional SPI peripherals.

[0012] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

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

[0014] Figure 1 This is a schematic diagram of the structure of a multi-functional controller based on the SPI bus provided in an embodiment of this application;

[0015] Figure 2 This is a software flowchart of a multi-functional controller based on the SPI bus provided in an embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0017] In the description of this application, the use of terms such as "first," "second," etc., is for the purpose of distinguishing technical features only and should not be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated or the order of the technical features indicated.

[0018] In the description of this application, it should be understood that the orientation descriptions, such as up, down, etc., are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed or function in a specific orientation, and therefore should not be construed as a limitation of this application.

[0019] like Figure 1 As shown in one embodiment of this application, a multi-functional controller based on an SPI bus is provided, which runs in a programmable logic device. The multi-functional controller based on the SPI bus includes:

[0020] The core control module is used to encapsulate SPI communication protocol frames to provide a standardized SPI interface, and to encapsulate register read and write instructions based on the Linux kernel subsystem. The core control module also interacts with the main system through SPI communication protocol frames.

[0021] The device class registration module communicates with the core control module. The device class registration module is used to register exclusive device classes when the core control module is initialized, so that the corresponding dedicated functions can be managed through the device class registration module.

[0022] The first docking module communicates with the core control module and the device registration module. The first docking module is used to dock standard functions with the Linux kernel subsystem to drive standard functions based on the corresponding SPI interface and corresponding register read / write instructions.

[0023] The second docking module communicates with the core control module and the device class registration module. The second docking module is used to abstract non-standard functions into virtual SPI devices, set the virtual SPI devices in a dedicated device class, and dock the virtual SPI devices with the application layer.

[0024] This embodiment provides a multi-functional controller based on the SPI bus, which is designed to solve the problem of complex driver development for multi-functional controllers in the prior art.

[0025] The core control module is the foundation of the entire controller, primarily responsible for handling low-level SPI communication. The module is configured to encapsulate SPI communication protocol frames to ensure standardized and reliable data transmission. Furthermore, the core control module encapsulates register read / write operations based on the Linux kernel subsystem; this means that access to the controller's internal registers no longer requires direct application-level manipulation of the underlying hardware, but rather through a unified interface provided by the core control module. The core control module interacts with the host system via SPI communication protocol frames, thereby enabling data transmission and command execution between the controller and the host system. In one implementation, the core control module can be a firmware program running on an embedded processor.

[0026] The main function of the device class registration module is to register one or more dedicated device classes with the Linux kernel after the core control module has been initialized. These dedicated device classes are designed for functions specific to SPI bus-based multifunction controllers, allowing the system to identify and manage these functions in a structured manner. The device class registration module enables unified management of these dedicated functions.

[0027] The first docking module establishes a communication connection with the core control module and the device registration module. Its primary function is to interface the standard functions provided by the SPI bus-based multifunction controller with the corresponding subsystems in the Linux kernel. These standard functions typically refer to general-purpose hardware functions supported by mature driver frameworks in the Linux kernel, such as general-purpose input / output (GPIO) control, inter-integrated circuit (I2C) communication control, or watchdog functionality. Through the first docking module, these standard functions can be driven by the core control module.

[0028] The second docking module communicates with the core control module and the device class registration module. This module primarily handles the non-standard functions provided by the SPI bus-based multi-function controller. These non-standard functions refer to customized or special functions that do not have direct corresponding support from standard Linux kernel subsystems, such as specific power-on / off and firmware update mechanisms. The second docking module manages these non-standard functions by abstracting them into virtual SPI devices. This means that even though these functions are not independent SPI devices at the hardware level, they are simulated as SPI devices at the software level, allowing access through a unified SPI interface. Subsequently, the virtual SPI device is set in a dedicated device class, enabling these non-standard functions to be managed by the device class registration module. Finally, the second docking module interfaces with the application layer through the virtual SPI device, allowing user-space applications to directly access and control these non-standard functions.

[0029] To address the issues of repetitive development and high development barriers in existing multi-functional controller driver development, this embodiment encapsulates SPI communication protocol frames and register read / write operations through a core control module. Standard and non-standard functions are handled by a first and a second interface module, respectively. This modular design avoids the repetitive work of independently implementing SPI protocol parsing and register operations for each functional module. Secondly, existing drivers fail to adapt to out-of-band characteristics, resulting in the inability to activate out-of-band management capabilities. This embodiment abstracts non-standard functions into virtual SPI devices through the second interface module, placing them in a dedicated device class and connecting them to the application layer via an interface. This contrasts sharply with existing technologies that only focus on in-band basic functions while ignoring out-of-band characteristics, significantly improving the controller's functional completeness and usability. To address the problem of high development difficulty and maintenance costs caused by the lack of multi-functional dedicated drivers in existing technologies, which require the application layer to directly operate the SPI bus and cannot reuse kernel subsystem capabilities, this embodiment provides a first docking module that interfaces standard functions with the Linux kernel subsystem. This allows standard functions to fully utilize the mature driver framework provided by the Linux kernel. Simultaneously, a second docking module provides virtual SPI devices and application layer interfaces for non-standard functions, enabling applications to access these functions in a unified and abstract manner. This design allows the application layer to reuse the capabilities of the kernel subsystem, significantly reducing development difficulty and maintenance costs. Furthermore, this embodiment effectively avoids the management problems caused by the "split driver" scheme in existing technologies, which leads to driver disconnection from hardware entities. Through the collaborative work of the core control module, device class registration module, first docking module, and second docking module, this embodiment constructs a unified driver framework, incorporating all functions under its management. This integrated management approach ensures consistency between drivers and hardware entities, avoiding management chaos and resource conflicts caused by driver fragmentation, thereby improving system stability and maintainability.

[0030] In summary, the SPI bus-based multi-functional controller provided in this embodiment effectively solves a series of technical problems in the prior art, such as complex driver development, lack of out-of-band management, difficulty in application layer development, and chaotic driver management, through its innovative modular architecture and unified management mechanism. It provides an efficient, flexible, and easily scalable solution for driver development and management of multi-functional SPI peripherals.

[0031] In some embodiments, the core control module is also used to: control the SPI queue of the Linux kernel subsystem to implement the transmission scheduling of register read and write instructions.

[0032] To address this, this embodiment proposes that the core control module also controls the Linux kernel's SPI queue to schedule the transmission of register read / write requests. The core control module controls the Linux kernel's SPI queue to schedule the transmission of register read / write requests. The Linux kernel's SPI queue refers to the data structure or mechanism within the Linux operating system kernel used to manage SPI device communication requests. When applications or drivers in the system need to exchange data with peripherals via the SPI bus, these requests are submitted to the queue, awaiting processing by the SPI controller. The "transmission scheduling of register read / write requests" refers to the core control module performing a series of operations, including sorting, priority management, and concurrency control, on the register read / write requests entering the SPI queue to ensure that these requests can be transmitted efficiently, orderly, and without conflict through the SPI bus.

[0033] In this embodiment, the core control module can effectively control the Linux kernel's SPI queue and implement the transmission scheduling of register read / write requests. This solves the problems of resource contention, low transmission efficiency, and chaotic data processing that may occur when multiple register read / write requests are concurrent. By scheduling requests in an orderly manner, the reasonable allocation and efficient utilization of SPI bus resources are ensured, and data transmission conflicts are avoided. This significantly improves the stability and response speed of the SPI bus-based multi-functional controller when handling complex tasks, and ensures the reliability of system operation.

[0034] In some embodiments, the dedicated functions include at least power-on / off control, SPI switching of firmware flash, and version management.

[0035] Power-on / off control refers to the management and control of the power state of a device or its specific components. Its function is to ensure the sequence and stability of power supply during startup, operation, and shutdown, preventing hardware damage or system malfunctions caused by improper power operation. Possible implementation methods include: sending commands to a dedicated power management chip (PMIC) via the SPI interface to control the on / off of different power rails; or directly controlling the GPIO pins related to the power switch through the core control module to achieve fine-grained power management of the device. Firmware flash SPI switching refers to the ability to select and switch between multiple firmware storage areas or multiple firmware flash devices. Its function is to support scenarios such as multiple firmware backups, A / B partition updates, secure boot, or loading different firmware in different operating modes. Possible implementation methods include: controlling different flash chips through the Chip Select (CS) signal line on the SPI bus to achieve physical switching; or dividing a single flash chip into multiple logical areas and logically switching between these areas through specific SPI commands or address mapping mechanisms. Version management refers to the ability to identify, store, update, and trace back device firmware, configuration data, or software versions. Its function is to ensure that the system is running in the correct version state, facilitating troubleshooting, function upgrades, and compatibility maintenance. Possible implementation methods include: storing version information in a specific area of ​​the firmware flash and performing read and write operations via the SPI interface; or, at device startup, the core control module reads the version information via SPI and compares it with the preset version to determine the subsequent startup process or update strategy.

[0036] In some embodiments, the standard function is configured with dynamic reconfiguration logic and an interruption feedback mechanism.

[0037] Standard functions refer to general hardware or software functions that interface with the Linux kernel subsystem through the first interface module and are driven by the core control module, such as GPIO level control, I2C peripheral communication, and watchdog timers. Dynamic reconfiguration logic refers to a mechanism that allows changes to the configuration, behavior, or connection methods of standard functions during system runtime without stopping or restarting the entire system. For example, functional behavior can be changed by loading or unloading specific driver modules, modifying configuration files, or through specific API calls; or, in programmable logic devices (such as FPGAs), hardware logic can be changed by reloading a portion of the bitstream (partial reconfiguration). Interrupt feedback mechanisms are mechanisms that allow standard functions to proactively report their status or request processing to the core control module or upper-layer applications when specific events occur. For example, hardware interrupt signals can be captured and notified to the CPU by the interrupt controller; or, software mechanisms such as message queues, semaphores, and callback functions can be used to trigger notifications when specific conditions are met.

[0038] The standard functions in this embodiment can be dynamically configured and adjusted according to actual needs, avoiding system downtime or restarts due to function changes, and significantly improving system flexibility and maintainability. Meanwhile, the interrupt feedback mechanism ensures that the system can respond to events generated by the standard functions in a timely and efficient manner, reducing system latency and improving real-time performance. This enables the SPI bus-based multi-functional controller to exhibit stronger adaptability and stability when handling complex and dynamic application scenarios.

[0039] In some embodiments, the standard functionality includes at least GPIO control;

[0040] GPIO control includes:

[0041] Based on the Linux kernel GPIO subsystem, determine the corresponding SPI interface;

[0042] Based on the corresponding SPI interface, the corresponding register read / write instructions in the core control module are called to drive GPIO control.

[0043] GPIO control refers to operating general-purpose input / output pins to achieve digital signal interaction with external hardware devices. This can include setting pins to input or output modes, reading pin states, and setting pin outputs to high or low levels. GPIO control is one of the most basic and commonly used methods for interacting with external hardware in embedded systems, such as controlling LEDs, reading button presses, driving relays, or communicating with simple sensors. GPIO control can be implemented by directly reading and writing hardware registers, or through the Hardware Abstraction Layer (HAL) or subsystem interface provided by the operating system.

[0044] Creating an SPI-GPIO controller refers to building a dedicated software module or hardware logic unit within an SPI bus-based multi-functional controller to handle GPIO control logic. As part of the first interface module, the controller's primary responsibility is to parse GPIO-related instructions from the SPI communication protocol frames of the core control module and translate these instructions into actual operations on the underlying GPIO hardware. The controller can be a standalone software driver running on the processor hosting the SPI bus-based multi-functional controller, or a custom logic block implemented in a programmable logic device (such as an FPGA).

[0045] Based on the Linux kernel GPIO subsystem, driving GPIO control by calling the corresponding control registers refers to using the standardized GPIO management framework provided by the Linux operating system to perform GPIO operations. The Linux kernel GPIO subsystem provides a unified set of application programming interfaces (APIs) that allow kernel modules or user-space programs to manage and control GPIO pins in an abstract way without directly accessing the underlying hardware registers. By calling these APIs, the SPI-GPIO controller can request, configure, and manipulate GPIO pins. This approach encapsulates the low-level hardware details of GPIO, providing a higher level of abstraction and stronger portability.

[0046] This embodiment integrates GPIO control as a standard function into a multi-functional controller based on the SPI bus. It drives GPIO by creating an SPI-GPIO controller and using the Linux kernel GPIO subsystem to call control registers. This effectively solves the problem of how to manage and operate GPIO devices in a standardized, efficient, and flexible manner within a general-purpose SPI bus-based multi-functional controller framework. This implementation avoids the main system directly handling complex GPIO hardware details; instead, it operates through a unified SPI interface and the abstraction layer provided by the Linux kernel GPIO subsystem, greatly simplifying the integration and control of GPIO devices.

[0047] In some embodiments, the standard functionality includes at least I2C control;

[0048] The I2C control driver includes:

[0049] Based on the Linux kernel I2C subsystem, determine the corresponding SPI interface;

[0050] Based on the corresponding SPI interface, the corresponding register read / write instructions in the core control module are called to drive I2C control.

[0051] I2C control refers to the ability to perform data reading, writing, configuration, and other operations on external I2C devices via the I2C (Inter-Integrated Circuit) bus protocol. The I2C bus is a serial, half-duplex, synchronous communication bus widely used for short-distance communication between microcontrollers and various peripherals. Incorporating it as a standard function into a multi-functional controller based on the SPI bus means that the controller has the ability to indirectly control I2C devices through the SPI interface, thereby expanding the controller's application range and compatibility.

[0052] Creating an SPI-I2C controller refers to instantiating a virtual I2C controller within the Linux kernel. This virtual controller acts as a bridge between the SPI-based multifunction controller and the Linux kernel's I2C subsystem. Its function is to forward I2C operation requests from upper-layer applications or the Linux kernel's I2C subsystem to the SPI-based multifunction controller via the SPI interface, which then performs the actual I2C operations. This allows I2C devices to be managed and driven as if directly connected to the Linux system, achieving the abstraction and standardization of I2C functionality.

[0053] The Linux kernel I2C subsystem provides a unified driver model, which avoids writing low-level SPI communication logic for each I2C device, greatly simplifying driver development and management.

[0054] This embodiment effectively solves the problem of efficiently and standardizedly integrating I2C devices into SPI-based controllers. It enables the host system to transparently manage and operate various I2C devices through a unified SPI interface, eliminating the need to write complex low-level SPI communication logic for each device. This not only simplifies I2C device driver development and maintenance, reducing system integration complexity, but also fully leverages the mature and stable management framework of the Linux kernel I2C subsystem, improving system compatibility and scalability.

[0055] In some embodiments, the standard functionality includes at least Watchdog control;

[0056] The Watchdog control includes:

[0057] Based on the Linux kernel Watchdog subsystem, determine the corresponding SPI interface;

[0058] Based on the corresponding SPI interface, the corresponding register read / write instructions in the core control module are called to drive the Watchdog control.

[0059] Watchdog control refers to a mechanism used to monitor the running status of a system or application. When the system or application fails to respond as expected within a preset time, the watchdog triggers a preset action, such as a system restart, to prevent system deadlock or crash. Watchdog control can be implemented in hardware, for example, through specific hardware timers and control registers for configuration and operation; it can also be implemented in software, for example, through scheduled tasks in the operating system or application to simulate its function.

[0060] Creating an SPI-Watchdog controller refers to building a dedicated software or hardware module for managing and controlling watchdog functionality, either within or as an extension of an SPI-based multi-functional controller. The controller is responsible for converting common watchdog operation requests from the upper layer (such as feeding the watchdog, setting timeouts, etc.) into data frames conforming to the SPI communication protocol and interacting with the underlying watchdog hardware via the SPI interface. The controller can be a standalone software driver module or a functional subunit integrated into the core control module.

[0061] Based on the Linux kernel's Watchdog subsystem, calling the corresponding control registers to drive Watchdog control refers to utilizing the standardized Watchdog management framework provided by the Linux operating system. When Watchdog control is introduced as a standard function, a multi-functional controller based on the SPI bus interfaces with the Linux kernel subsystem through a first docking module. Specifically, the system creates an SPI-Watchdog controller. This controller uses the standardized interfaces and mechanisms provided by the Linux kernel's Watchdog subsystem to translate control requests from upper-layer applications or the system into operations on the Watchdog hardware control registers. These operations are transmitted to the underlying Watchdog hardware via the SPI interface through SPI communication protocol frames encapsulated in the core control module. This approach allows for unified management of Watchdog functionality and remote or modular control via the SPI interface, effectively improving system reliability and maintainability.

[0062] This embodiment integrates Watchdog control as a standard function into a multi-functional controller based on the SPI bus, and utilizes the Linux kernel Watchdog subsystem for driving it. This allows the system to uniformly manage and control the Watchdog through a standardized SPI interface. This not only simplifies the integration and maintenance of the Watchdog function, but also effectively prevents system deadlock or crashes under abnormal conditions through the Watchdog's monitoring mechanism, significantly improving the system's stability and reliability.

[0063] In some embodiments, the SPI communication protocol frame includes at least: a frame header, a valid data length, a protocol version, a register address, a frame data length, and a checksum.

[0064] The frame header is the starting part of the SPI communication protocol frame. Its main function is to identify the beginning of a new frame and may contain some basic synchronization information or frame type identifiers to ensure that the receiver can correctly identify the frame boundaries, synchronize, and quickly determine the frame type or priority. The effective data length field indicates the number of bytes or words of the actual payload (i.e., service data) in the frame. Its function is to allow the receiver to accurately parse the effective data portion, avoiding reading redundant or insufficient data, thereby improving the accuracy of data parsing. The protocol version field identifies the protocol specification version number followed by the current SPI communication protocol frame. Its function is to ensure that both communicating parties use compatible protocol versions for communication, facilitating protocol upgrades and compatibility management. The register address field is a unique identifier indicating the specific register targeted by this SPI communication operation. Its function is to enable the core control module to accurately read and write specific registers in the master or slave system, achieving fine-grained control of hardware functions and status queries. The frame data length field indicates the total length of the entire SPI communication protocol frame (e.g., excluding the frame header, or including the frame header but excluding the checksum). Its purpose is to help the receiver pre-allocate buffers and verify the integrity of the received frame, preventing data truncation or overflow. The checksum field is a data field used to verify whether errors occurred during the transmission of the SPI communication protocol frame. Its purpose is to improve the reliability of data transmission. The receiver can detect transmission errors by calculating the received data and comparing it with the checksum. The checksum can use Cyclic Redundancy Check (CRC), such as CRC8, CRC16, or CRC32; or it can use a simple XOR checksum or a Sum checksum.

[0065] This embodiment of the multi-functional controller based on the SPI bus can construct communication frames with clear structure and complete information. This standardized frame structure significantly enhances the reliability and efficiency of SPI communication, ensuring accurate data interaction between the core control module and the main system. Therefore, this solution provides a solid foundation for the core control module to encapsulate SPI communication protocol frames and perform register read / write operations based on the Linux kernel subsystem, thereby improving the stability and performance of the entire SPI bus-based multi-functional controller.

[0066] In some embodiments, interfacing the virtual SPI device with the application layer includes:

[0067] Each virtual SPI device interfaces with the application layer through a corresponding sysfs interface; the read and write commands of the sysfs interface node are mapped to the corresponding registers through the core control module, so that the application layer can call non-standard functions.

[0068] The sysfs interface is a virtual file system provided by the Linux kernel. Its main function is to expose kernel objects and their attributes to user space, allowing user-space programs to query and configure kernel status or device parameters through standard file operations (such as reading and writing). The interface provides a structured way to represent devices, drivers, and other kernel components, enabling user space to easily interact with the kernel.

[0069] This embodiment of the SPI bus-based multi-function controller provides a standardized user-space interface for the abstracted virtual SPI device, enabling application layer programs to interact with various non-standard functions in a unified and convenient manner. This sysfs interface-based approach avoids developing customized drivers for each non-standard function, reducing system development complexity and maintenance costs. Furthermore, since sysfs is a standard mechanism in the Linux kernel, it ensures the stability and compatibility of communication between the virtual SPI device and the application layer, improving the flexibility and scalability of the entire SPI bus-based multi-function controller in managing and driving non-standard functions.

[0070] In some embodiments, the programmable logic device is an FPGA.

[0071] FPGA (Field-Programmable Gate Array) is a programmable logic device that contains a large number of programmable logic units, programmable interconnect resources, and input / output blocks, allowing users to define and implement custom digital circuit functions using hardware description languages ​​such as VHDL or Verilog.

[0072] This embodiment integrates a multi-functional controller based on the SPI bus into an FPGA, significantly improving the overall controller's performance, flexibility, and real-time performance. The FPGA's hardware parallel processing capabilities and low latency enable the encapsulation of SPI communication protocol frames, register read / write operations, and the driving of various functions (such as GPIO, I2C, and Watchdog) to be executed at hardware speed, effectively solving the performance bottlenecks and insufficient real-time performance issues that may exist in pure software implementations. Furthermore, the reconfigurability of the FPGA provides the controller with great flexibility, allowing for functional updates or expansions through FPGA reprogramming without changing the hardware board, thus better adapting to different application scenarios and requirements.

[0073] like Figure 1 and Figure 2 For ease of understanding, this application provides the following embodiments:

[0074] A complete driver implementation architecture was designed for the SPI multi-function controller. Through layered encapsulation and interface with the kernel subsystem, efficient management and flexible invocation of controller functions are achieved. The specific solution is as follows:

[0075] The SPI multi-function controller uses an FPGA chip to implement the core control logic. All its functions (including GPIO, I2C, Watchdog, and out-of-band management) interact with the main system through a standardized SPI communication protocol frame. The protocol frame definition includes a frame header, valid data length, protocol version, register address, frame data length, and checksum. The communication protocol allows for read and write operations on the registers, triggering the control logic of the corresponding functional modules.

[0076] (1) Core layer (common) design: protocol encapsulation and SPI transmission control;

[0077] To achieve unified processing of the SPI communication protocol and reliable scheduling of register operations, the scheme first constructs a core layer (common):

[0078] Protocol frame encapsulation: The core layer encapsulates the construction, parsing, and verification logic of the SPI communication protocol frame and provides standardized interfaces (such as init_vspi_frame for packaging instruction frames), ensuring that the upper-layer driver does not need to pay attention to the details of the frame format and can directly pass in the register address and data to complete the instruction assembly.

[0079] SPI Transmission Queuing Management: Based on the spi_transfer mechanism of the Linux kernel SPI subsystem, the core layer encapsulates register read and write operations. For example, the vbus_write_register operation will call spi_transfer, and the kernel SPI queue will be used to schedule the transmission. All register read and write requests (whether from in-band functions or out-of-band management) will enter the queue and be executed serially according to priority, avoiding data chaos caused by parallel access by multiple modules.

[0080] (2) Integration of equipment registration and out-of-band management;

[0081] During core layer initialization, a dedicated device class is registered through the module_init mechanism, serving as a unified management carrier for the controller's dedicated functional modules. This device class carries all the controller's dedicated functions, such as power-on / off control, firmware flash SPI switching, and version management.

[0082] (3) Standard functional modules interface with the kernel subsystem;

[0083] For the standard functional modules integrated into the controller (GPIO, I2C, Watchdog), a standardized driver interface is implemented by interfacing with the corresponding subsystems in the Linux kernel:

[0084] GPIO controller driver: Based on the kernel gpiolib subsystem, the structgpio_chip structure is defined. Its core interfaces (such as get_direction to read the pin direction and set_value to set the output level) are all implemented by calling the register read and write of the core layer. For example, the get_direction interface reads the direction register of the controller's GPIO module and returns the input and output status of the corresponding pin.

[0085] I2C controller driver: Interacts with the kernel I2C subsystem, implements the master_xfer interface of structi2c_adapter, and completes I2C timing generation, data transmission and reception, and bus arbitration by reading and writing the control registers (such as data transfer registers and status registers) of the I2C module through the core layer.

[0086] Watchdog device driver: Based on the kernel watchdog subsystem, it implements interfaces such as start / stop / ping. It operates the timeout configuration register and feed register of the Watchdog module through the core layer to realize the functions of timed reset and manual feed.

[0087] (4) User-mode interface adaptation for non-standard management functions;

[0088] For non-standard management functions of the controller (such as FPGA firmware version query, power-on / off control, etc.), the solution abstracts them as virtual SPI devices, uniformly classifies them under the device class created in the core layer, and exposes them to the application layer through the sysfs interface:

[0089] Each non-standard function corresponds to an independent sysfs node, thereby enabling full activation of the controller hardware functions.

[0090] The read and write operations of these nodes are mapped to corresponding dedicated registers (such as version registers, interrupt vector table registers, and power-on / off control registers) through the core layer. The application layer does not need to pay attention to the details of the SPI protocol and can directly call functions through file operations (cat / echo), simplifying the user-mode call process for non-standard functions.

[0091] This embodiment has at least the following beneficial effects:

[0092] (1) The core layer uniformly encapsulates common logic such as SPI protocol parsing and register operation, which can be directly called by each functional module, reducing redundant development and eliminating the need to pay attention to hardware details, thus lowering the development threshold. Moreover, when the hardware version is updated, only the protocol mapping and register definition of the core layer need to be modified, and the interface logic between the upper functional modules and subsystems does not need to be changed, which greatly improves the iteration efficiency. When introducing new functional controller requirements, it is only necessary to enrich the relevant controller subsystem interface or add a sysfs interface to directly implement its function.

[0093] (2) Fully activate controller functions through driver customization and adaptation: Design a dedicated configuration interface and register mapping to expose global hardware information and facilitate fault diagnosis and version adaptation. The driver reads the controller's global configuration registers (such as firmware version) and exposes them to the upper layer through the sysfs interface. Applications can quickly complete hardware version adaptation through this information; the interrupt vector table is directly exposed, and applications can directly query hardware faults through the sysfs interface; controller functions are adapted separately, and the functions are uniformly provided to the application layer for direct use.

[0094] (3) By interfacing with the kernel subsystem, standardized interfaces are reused, lowering the development threshold. Applications do not need to directly manipulate the SPI bus; they can directly call the kernel's native interfaces to achieve functionality. This eliminates redundant application development, shortens the R&D cycle and reduces debugging costs. The kernel subsystem has already encapsulated common capabilities (such as GPIO pin management, I2C bus arbitration, and Watchdog timer scheduling), which are directly reused and interfacing with the controller hardware in this driver, eliminating the need for applications to implement them repeatedly. This isolates hardware and applications, reducing maintenance costs and improving adaptability. As an "intermediate layer between hardware and applications," the driver achieves hardware detail isolation.

[0095] (4) This driver takes "a single driver instance corresponding to a single hardware entity" as its core and builds a unified resource management framework to completely solve the problem of fragmentation:

[0096] Unified SPI bus scheduling avoids transmission conflicts between multiple modules. The driver has an integrated SPI transmission arbitration module that separates the transmission and reception of SPI command requests for various functions (such as GPIO register read / write, I2C data transmission / reception, and watchdog feeding), preventing timing chaos caused by multiple modules initiating SPI requests in parallel. For example, when an application simultaneously triggers I2C reading from the temperature and humidity sensor and GPIO control, the driver will complete the I2C data transmission first, and then execute the GPIO command transmission, avoiding communication failures caused by data frame overlap.

[0097] In summary, the solution achieves unified protocol encapsulation, SPI transmission queuing, standard function subsystemization, and non-standard function interfaceization. This not only ensures reliable collaboration among the various modules of the controller (especially out-of-band management functions) but also reduces the complexity of driver development and application calls, fully leveraging the hardware characteristics of the FPGA multi-functional controller.

[0098] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A multi-functional controller based on SPI bus, characterized in that, Running in a programmable logic device, the SPI bus-based multi-functional controller includes: The core control module is used to encapsulate SPI communication protocol frames to provide a standardized SPI interface, and to encapsulate register read and write instructions based on the Linux kernel subsystem. The core control module interacts with the main system through the SPI communication protocol frames. The device class registration module communicates with the core control module. The device class registration module is used to register a dedicated device class when the core control module is initialized, so as to manage the corresponding dedicated functions through the device class registration module. The first docking module is communicatively connected to the core control module and the device registration module. The first docking module is used to dock the standard functions with the Linux kernel subsystem to drive the standard functions based on the corresponding SPI interface and the corresponding register read and write instructions. The second docking module is connected to the core control module and the device class registration module. The second docking module is used to abstract non-standard functions into virtual SPI devices, set the virtual SPI devices in the dedicated device class, and dock the virtual SPI devices with the application layer.

2. The multi-functional controller based on SPI bus according to claim 1, characterized in that, The core control module is also used to: control the SPI queue of the Linux kernel subsystem to implement the transmission scheduling of register read and write instructions.

3. A multi-functional controller based on an SPI bus according to claim 2, characterized in that, The dedicated functions include at least power-on / off control, SPI switching of firmware flash, and version management.

4. A multi-functional controller based on an SPI bus according to claim 1, characterized in that, The core control module is equipped with dynamic reconfiguration logic and interrupt feedback mechanism for the standard functions.

5. A multi-functional controller based on an SPI bus according to claim 4, characterized in that, The standard functions include at least GPIO control; The GPIO control includes: Based on the Linux kernel GPIO subsystem, determine the corresponding SPI interface; Based on the corresponding SPI interface, the corresponding register read / write instructions in the core control module are called to drive GPIO control.

6. A multi-functional controller based on an SPI bus according to claim 4, characterized in that, The standard functions include at least I2C control; Driving the I2C control includes: Based on the Linux kernel I2C subsystem, determine the corresponding SPI interface; Based on the corresponding SPI interface, the corresponding register read / write instructions in the core control module are called to drive I2C control.

7. A multi-functional controller based on an SPI bus according to claim 4, characterized in that, The standard features include at least Watchdog control; The Watchdog control includes: Based on the Linux kernel Watchdog subsystem, determine the corresponding SPI interface; Based on the corresponding SPI interface, the corresponding register read / write instructions in the core control module are called to drive the Watchdog control.

8. A multi-functional controller based on an SPI bus according to claim 1, characterized in that, The SPI communication protocol frame includes at least: frame header, effective data length, protocol version, register address, frame data length, and checksum.

9. A multi-functional controller based on an SPI bus according to claim 1, characterized in that, The step of interfacing the virtual SPI device with the application layer includes: Each of the virtual SPI devices interfaces with the application layer through a corresponding sysfs interface; wherein, the read and write instructions of the sysfs interface node are mapped to the corresponding registers through the core control module, so that the application layer can call the non-standard functions.

10. A multi-functional controller based on an SPI bus according to any one of claims 1 to 9, characterized in that, The programmable logic device is an FPGA.

Images