A method and system for access control of a BMS peripheral, and a vehicle

Abstract

This invention provides a method, system, and vehicle for access control of BMS peripherals, relating to the field of BMS control technology. The method is applied to a domain controller, which is communicatively connected to a bridge chip in the BMS controller. The BMS controller does not have an internal MCU. The bridge chip is communicatively connected to multiple BMS peripherals, each corresponding to an instruction buffer and a peripheral driver. The method includes: initializing the instruction buffer; running the peripheral driver, generating a first access instruction based on the access requirements of the corresponding first peripheral, and writing it to the corresponding instruction buffer; running the bridge chip driver, querying the instruction buffer to determine the first access instruction to be sent, and sending it to the bridge chip, enabling the bridge chip to access the corresponding first peripheral. Through this invention, peripheral access is achieved without an internal MCU in the BMS controller, improving the orderliness and maintainability of access control.

Description

Technical Field

[0001] This invention relates to the field of BMS control technology, and in particular to an access control method, system, and vehicle for BMS peripherals. Background Technology

[0002] With the development of power battery systems for new energy vehicles, the Battery Management System (BMS) controller has become an important component of power battery packs. The BMS controller is typically used to perform functions such as cell voltage acquisition, cell temperature acquisition, high-voltage sampling of the battery pack, insulation monitoring, equalization control, relay control, fault diagnosis, and data communication with domain controllers.

[0003] In existing BMS controllers, the microcontroller unit (MCU) within the BMS controller typically runs various peripheral driver programs directly. These peripherals access interfaces such as Serial Peripheral Interface (SPI), Universal Asynchronous Receiver / Transmitter (UART), General Purpose Input / Output (GPIO), and Analog-to-Digital Converter (ADC). For example, the MCU drives cell voltage and temperature acquisition and equalization control via an analog front-end (AFE), atmospheric pressure acquisition via a pressure sensor, input / output control via input / output (IO) expansion chips, and analog signal acquisition via an analog-to-digital (AD) sampling chip. Since the MCU is located locally within the BMS controller, it can directly manage the communication timing, command transmission, response reading, and status updates of each peripheral.

[0004] To reduce the cost of the BMS controller and simplify the hardware structure, the inventors have researched a method that eliminates the need for an internal MCU in the BMS controller. Instead, control logic and data processing are centralized on the domain controller side. The domain controller communicates with a bridge chip in the coreless BMS controller (i.e., a BMS controller without an MCU), indirectly accessing BMS peripherals (e.g., AFE chips, high-voltage sampling chips, and various SPI peripherals) through the bridge chip. In other words, the domain controller does not directly connect to each BMS peripheral; instead, it first sends control commands to the bridge chip, which then completes the access to the specific BMS peripherals.

[0005] Therefore, how to enable access between domain controllers and BMS peripherals in a kernelless BMS controller has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] The purpose of this invention is to provide an access control method, system, and vehicle for BMS peripherals to solve the aforementioned technical problems in the prior art.

[0007] On the one hand, in order to achieve the above objectives, the present invention provides an access control method for BMS peripherals.

[0008] The access control method for BMS peripherals is applied to a domain controller. The domain controller communicates with a bridge chip in the BMS controller. The BMS controller does not have an internal MCU. The bridge chip communicates with the BMS peripherals. The BMS peripherals include multiple first peripherals. The domain controller is equipped with a bridge chip driver, a peripheral driver, and an instruction buffer. The first peripherals, the instruction buffer, and the peripheral driver correspond one-to-one. The method includes: initializing the instruction buffer; running the peripheral driver, which generates a first access instruction based on the access requirements of the corresponding first peripheral, and writes the first access instruction into the instruction buffer of the corresponding first peripheral; running the bridge chip driver, which queries the instruction buffer to determine the first access instruction to be sent; and sending the first access instruction to be sent to the bridge chip, wherein the bridge chip is used to access the first peripheral according to the received first access instruction.

[0009] On the other hand, in order to achieve the above objectives, the present invention provides an access control system for BMS peripherals.

[0010] The access control system for the BMS peripherals includes a domain controller and a BMS controller. The BMS controller does not have an internal MCU. The domain controller communicates with a bridge chip within the BMS controller, and the bridge chip communicates with the BMS peripherals. The BMS peripherals include multiple first peripherals. The domain controller has a bridge chip driver, a peripheral driver, and an instruction buffer. Each first peripheral, instruction buffer, and peripheral driver corresponds one-to-one. The domain controller initializes the instruction buffer, runs the peripheral driver, which generates a first access instruction based on the access requirements of the corresponding first peripheral, writes the first access instruction into the instruction buffer of the corresponding first peripheral, runs the bridge chip driver, queries the instruction buffer through the bridge chip driver to determine the first access instruction to be sent, and sends the first access instruction to the bridge chip. The bridge chip accesses the first peripheral based on the received first access instruction.

[0011] On the other hand, in order to achieve the above objectives, the present invention provides a vehicle.

[0012] The vehicle includes an access control system for any of the BMS peripherals provided by this invention.

[0013] This invention provides a method, system, and vehicle for access control of BMS peripherals. The access control system includes a domain controller and a BMS controller. The domain controller is communicatively connected to a bridge chip in the BMS controller. The BMS controller does not have an internal MCU. The domain controller sets up peripheral drivers and instruction buffers for multiple first peripherals. Each peripheral driver generates a first access instruction based on the access requirements of the corresponding first peripheral and writes the first access instruction into the instruction buffer of the corresponding first peripheral. The bridge chip driver then queries the instruction buffer to determine the first access instruction to be sent and sends it to the bridge chip, enabling the bridge chip to access the corresponding first peripheral based on the received first access instruction. Through this invention, access instructions for different first peripherals are generated separately by their respective peripheral drivers and written into their respective instruction buffers, allowing access requests for different first peripherals to be managed separately on the domain controller side, preventing the access instructions from different first peripherals from mixing. Simultaneously, the bridge chip driver centrally queries the instruction buffer and uniformly sends the first access instructions to be sent, enabling centralized coordination of the use of the bridge chip communication link by multiple first peripherals. Therefore, even without an MCU inside the BMS controller, orderly access control of multiple BMS peripherals can still be achieved, reducing the software and hardware resource requirements of the BMS controller and lowering the scheduling complexity caused by multiple peripheral access requests directly contending for bridge chip communication resources. Furthermore, since there is a one-to-one correspondence between the first peripheral, the instruction buffer, and the peripheral driver, when a new first peripheral needs to be added, a corresponding peripheral driver and instruction buffer can be configured for the new first peripheral. The new peripheral driver will generate the first access instruction and write it to the corresponding instruction buffer in the same way, and the bridge chip driver will still determine the first access instruction to be sent by querying the instruction buffer. When a first peripheral needs to be deleted, the peripheral driver and instruction buffer corresponding to that first peripheral can be deleted or disabled without affecting the centralized query and sending mechanism of the peripheral drivers, instruction buffers, and bridge chip drivers of other first peripherals. Therefore, this method decouples the access instruction encapsulation process of each first peripheral from each other, so that the addition or deletion of the first peripheral is mainly reflected in the addition or deletion or configuration adjustment of the corresponding peripheral driver and instruction cache, which reduces the complexity of modifying the overall access control logic due to the addition or deletion of the first peripheral, and also improves the scalability and maintenance convenience of the BMS peripheral access control method. Attached Figure Description

[0014] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a block diagram of the access control system for BMS peripherals provided in Embodiment 1 of the present invention; Figure 2 A flowchart of the access control method for BMS peripherals provided in Embodiment 1 of the present invention; Figure 3 This is a block diagram of the access control system for BMS peripherals provided in Embodiment 2 of the present invention; Figure 4 This is a flowchart illustrating the process of running the bridge chip driver and sending instructions to control the peripheral in the BMS peripheral access control method provided in Embodiment 2 of the present invention. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0016] In this invention, the BMS controller performs functions related to the power battery pack, including data acquisition, control, communication, and peripheral access. MCU refers to a microcontroller unit; in traditional BMS controllers, the MCU typically executes control logic, data processing logic, peripheral drive logic, and communication scheduling logic locally. The BMS controller in this invention does not have an internal MCU, meaning it does not contain a microcontroller chip for independently running the aforementioned local control logic. The domain controller is located outside the BMS controller and can perform at least some of the control logic, data processing logic, and peripheral access scheduling logic originally executed by the MCU inside the BMS controller.

[0017] To address the technical solution of eliminating the local MCU of the BMS controller, i.e., a coreless BMS controller, the inventors further conducted the following research: In a coreless BMS controller architecture, a bridge chip is placed in the BMS controller, and the domain controller communicates with the bridge chip. The bridge chip becomes the centralized channel for the domain controller to access BMS peripherals. The bridge chip receives access commands sent by the domain controller and accesses the BMS peripherals that are communicatively connected to the bridge chip according to the access commands. Read / write requests, sampling requests, and equalization control requests from multiple BMS peripherals all need to be scheduled and sent through the bridge chip. The command requests from different BMS peripherals are mixed together, making it difficult to distinguish between different BMS peripherals. When the types of BMS peripherals increase or the peripheral chips are replaced, the processing logic also needs to be modified, resulting in high software maintenance complexity. To address this problem, this application proposes a BMS peripheral access control method, system, and vehicle, the specific implementation of which is detailed in the following embodiments.

[0018] Example 1 This invention provides an access control method for BMS peripherals, applied to a domain controller. This method, without an internal MCU within the BMS controller, distributes access commands corresponding to different BMS peripherals on the domain controller side. A bridge chip on the domain controller side then centrally queries and sends the access commands to be sent, enabling the bridge chip to access the corresponding BMS peripherals based on the access commands sent by the domain controller. Specifically, Figure 1 This is a block diagram of the BMS peripheral access control system provided in Embodiment 1 of the present invention. Figure 2 The flowchart is as follows: This is a BMS peripheral access control method provided in Embodiment 1 of the present invention. Figure 1 and Figure 2 As shown, the access control method for BMS peripherals provided in this embodiment includes the following steps S101 to S104, and the system framework for implementing this method is as follows: Figure 1 As shown.

[0019] Step S101: Initialize the instruction buffer.

[0020] In this design, the domain controller communicates with the bridge chip in the BMS controller. The BMS controller does not have an internal MCU, and the bridge chip communicates with the BMS peripherals. The BMS peripherals include multiple first peripherals. The domain controller is equipped with a bridge chip driver, a peripheral driver, and an instruction buffer. The first peripherals, the instruction buffer, and the peripheral driver correspond one-to-one. Optionally, the BMS peripherals can be located on the BMS controller or outside the BMS controller; this application does not impose any limitations on this.

[0021] In this embodiment, the instruction cache is used to cache the first access instruction corresponding to the first peripheral. Different first peripherals correspond to different instruction caches, and different first peripherals also correspond to different peripheral drivers. That is, each first peripheral has its own corresponding peripheral driver and instruction cache. Through this one-to-one correspondence, the access requirements, access instructions, and instruction states of different first peripherals can be maintained separately, avoiding management chaos caused by the mixed storage of access instructions from multiple first peripherals.

[0022] Specifically, initializing the instruction buffer may include: allocating a corresponding buffer space for each first peripheral, clearing historical data in the buffer space, setting the initial state of the instruction buffer, and writing initial configuration parameters related to accessing the first peripheral. These initial configuration parameters may include communication parameters for the corresponding first peripheral, the maximum number of bytes transmitted per instruction, the default response length, and the default execution state. After initialization, the peripheral driver for each first peripheral can write its generated first access instruction into the corresponding instruction buffer.

[0023] Step S102: Run the peripheral driver, which generates a first access instruction based on the access requirements of the corresponding first peripheral, and writes the first access instruction into the instruction buffer of the corresponding first peripheral.

[0024] The peripheral driver runs on the domain controller side. Different first peripherals may have different access requirements, such as reading the first peripheral's collected data, writing the first peripheral's configuration parameters, reading the first peripheral's status data, or triggering the first peripheral to execute preset functions. Correspondingly, the peripheral driver of each first peripheral generates a first access command based on its access requirements.

[0025] In this embodiment, since different first peripherals correspond to different peripheral drivers, each peripheral driver can run independently in its own periodic task or triggered task. When a certain first peripheral has an access requirement, the peripheral driver corresponding to that first peripheral generates a first access instruction based on the access requirement and writes the first access instruction into the instruction cache area corresponding to that first peripheral. Thus, the access instructions for different first peripherals are generated separately in their respective peripheral drivers and stored separately in their respective instruction cache areas, realizing distributed instruction encapsulation.

[0026] The first access instruction may include the command content for accessing the first peripheral device, and may further include information such as the first peripheral device identifier, operation type, requested data length, response length, and execution status. This information can be used by the subsequent bridging chip driver to determine the instruction to be sent and to perform parsing processing after the bridging chip returns response data.

[0027] Step S103: Run the bridge chip driver, query the instruction buffer through the bridge chip driver, and determine the first access instruction to be sent.

[0028] The bridging chip driver runs on the domain controller side and is used to uniformly manage the access commands sent by the domain controller to the bridging chip. The bridging chip driver can run according to a preset task cycle, or it can be triggered to run when an unprocessed command is detected in the command buffer.

[0029] In this step, the bridge chip driver queries the instruction cache corresponding to each first peripheral to determine whether a first access instruction exists. When a first access instruction is found in one or more instruction caches, the bridge chip driver determines the first access instruction to be sent from these instruction caches. The specific determination method may include determining it according to a preset query order, or it may be determined by combining factors such as the instruction priority, instruction execution status, data transmission status, or task cycle of the first peripheral.

[0030] Through this step, each first peripheral driver only needs to be responsible for generating and writing its own first access instruction, without directly contending for the communication link with the bridge chip. The bridge chip driver centrally queries multiple instruction buffers and uniformly decides which first access instruction to send to the bridge chip, thereby achieving centralized instruction processing.

[0031] Step S104: Send the first access command to be sent to the bridge chip.

[0032] The bridging chip is used to access the first peripheral device according to the received first access instruction.

[0033] After determining the first access command to be sent, the domain controller sends the first access command to the bridge chip in the BMS controller through the bridge chip driver. After receiving the first access command, the bridge chip accesses the corresponding first peripheral based on the command content, target peripheral information, operation type, etc. carried in the first access command.

[0034] In this embodiment, since the BMS controller does not have an internal MCU, the local MCU is not required to generate, schedule, and manage the first peripheral access command. The domain controller is responsible for generating, caching, querying, and sending the first access command, while the bridge chip is responsible for performing the underlying access operation based on the first access command sent by the domain controller. The response data returned by the first peripheral can first enter the bridge chip, and then be read and processed by the bridge chip driver on the domain controller side.

[0035] In the BMS peripheral access control method provided in this embodiment, the domain controller and the bridge chip in the BMS controller are communicatively connected, and the BMS controller does not have an internal MCU. The domain controller sets up peripheral drivers and instruction buffers for multiple first peripherals respectively. Each peripheral driver generates a first access instruction according to the access requirements of the corresponding first peripheral and writes the first access instruction into the instruction buffer of the corresponding first peripheral. Then, the bridge chip driver queries the instruction buffer to determine the first access instruction to be sent and sends the first access instruction to be sent to the bridge chip, so that the bridge chip accesses the corresponding first peripheral according to the received first access instruction. By using the BMS peripheral access control method provided in this embodiment, the access instructions of different first peripherals are generated by the corresponding peripheral drivers and written into their respective instruction buffers, so that the access requests of different first peripherals are managed separately on the domain controller side, avoiding the mixing of access instructions of different first peripherals. At the same time, the bridge chip driver centrally queries the instruction buffer and uniformly sends the first access instruction to be sent, so that the use of the bridge chip communication link by multiple first peripherals is centrally coordinated by the bridge chip driver. Therefore, even without an MCU inside the BMS controller, orderly access control of multiple BMS peripherals can still be achieved, reducing the software and hardware resource requirements of the BMS controller and lowering the scheduling complexity caused by multiple peripheral access requests directly contending for bridge chip communication resources. Furthermore, since there is a one-to-one correspondence between the first peripheral, the instruction buffer, and the peripheral driver, when a new first peripheral needs to be added, a corresponding peripheral driver and instruction buffer can be configured for the new first peripheral. The new peripheral driver will generate the first access instruction and write it to the corresponding instruction buffer in the same way, and the bridge chip driver will still determine the first access instruction to be sent by querying the instruction buffer. When a first peripheral needs to be deleted, the peripheral driver and instruction buffer corresponding to that first peripheral can be deleted or disabled without affecting the centralized query and sending mechanism of the peripheral drivers, instruction buffers, and bridge chip drivers of other first peripherals. Therefore, this method decouples the access instruction encapsulation process of each first peripheral from each other, so that the addition or deletion of the first peripheral is mainly reflected in the addition or deletion or configuration adjustment of the corresponding peripheral driver and instruction cache, which reduces the complexity of modifying the overall access control logic due to the addition or deletion of the first peripheral, and also improves the scalability and maintenance convenience of the BMS peripheral access control method.

[0036] Optionally, in one embodiment, the first peripheral is connected to the bridge chip via SPI communication, and the BMS peripheral further includes a second peripheral connected to the bridge chip via daisy-chain communication, such as... Figure 2 As shown. The method further includes: running a bridge chip driver to encapsulate a second access instruction for accessing a second peripheral; sending the second access instruction to the bridge chip, wherein the bridge chip is used to access the second peripheral according to the second access instruction.

[0037] In this embodiment, the first peripheral can be a peripheral chip connected to the bridge chip via SPI communication, such as an atmospheric pressure sensor, an extended I / O chip, an AD sampling chip, an EEPROM (Electrically Erasable Programmable Read-Only Memory) chip, or other memory chips. The bridge chip can have SPI master device functionality, enabling it to access the first peripheral via SPI communication. The chip select signal of the first peripheral can be controlled by different GPIO pins of the bridge chip, allowing the bridge chip to select the first peripheral corresponding to the first access instruction from among multiple first peripherals.

[0038] The second peripheral can be a peripheral connected to the bridge chip via daisy-chain communication, such as a high-voltage sampling chip and / or an AFE chip. The access instructions for the second peripheral are encapsulated by the bridge chip driver, and do not necessarily need to be generated by the corresponding peripheral drivers for each first peripheral. Specifically, the bridge chip driver can encapsulate second access instructions for accessing the second peripheral, such as reading cell voltage, reading cell temperature, reading high-voltage sampling data, and controlling the equalization switch, and send these second access instructions to the bridge chip. Upon receiving the second access instructions, the bridge chip converts them into communication data suitable for daisy-chain communication and accesses the second peripheral through the daisy-chain communication link.

[0039] The access control method for BMS peripherals provided in this embodiment limits the BMS peripherals to include a first peripheral connected to the bridge chip via SPI communication and a second peripheral connected to the bridge chip via daisy-chain communication. The first access instruction, i.e., the access instruction of the SPI peripheral, is encapsulated and cached by the corresponding peripheral driver, while the second access instructions of the second peripherals such as the high-voltage sampling chip and the AFE chip can be uniformly encapsulated and sent by the bridge chip driver. This avoids confusion in the generation and management of SPI peripheral access instructions and sampling chip or AFE chip access instructions, and facilitates the bridge chip driver to coordinate SPI peripheral access tasks and daisy-chain sampling or equalization control tasks.

[0040] Optionally, in one embodiment, the method further includes: querying the response status of the bridge chip through the bridge chip driver, wherein the response status is used to characterize whether the bridge chip has received response data returned by the BMS peripheral; when the response status indicates that the bridge chip has received response data, reading and parsing the response data through the bridge chip driver.

[0041] Specifically, the response data can be either the response data returned by the first peripheral to the bridge chip via SPI communication, or the response data returned by the second peripheral to the bridge chip via daisy-chain communication. After accessing the first or second peripheral, the bridge chip can temporarily store the returned response data in its internal receive register or response buffer, and record the response completion status, data length, or error status through relevant status registers. The response status is used to indicate whether the bridge chip has received the response data returned by the BMS peripheral; for example, it can be a response completion flag indicating that the response data has been received, a flag indicating the length of the received response data, or a flag indicating that no response data has been received.

[0042] On the domain controller side, the bridge chip driver can first query the bridge chip's response status. If the response status indicates that the bridge chip has not yet received response data, the bridge chip driver can continue waiting, skip the current read operation, or execute other pending instructions. If the response status indicates that the bridge chip has received response data, the bridge chip driver reads the response data from the bridge chip and parses it based on the source of the response data, the corresponding access instruction, or information carried within the response data itself.

[0043] The access control method for BMS peripherals provided in this embodiment uses a bridging chip driver to uniformly query the response status of the bridging chip and uniformly read and parse the response data when the bridging chip receives it. Since the data returned by the BMS peripherals is all output to the domain controller via the bridging chip, the response data read from the domain controller uniformly follows the bridging chip's communication protocol and has the same or compatible data format. Therefore, centralized parsing of the response data by the bridging chip driver can centrally complete frame format parsing, length judgment, status judgment, error identification, and data extraction at the bridging chip protocol level within a single driver. This avoids the problems of repetitive parsing logic, inconsistent parsing rules, and scattered error handling caused by different peripheral drivers parsing the data returned by the bridging chip separately. Simultaneously, each peripheral driver can focus primarily on the access requirements and business data meaning of the corresponding peripheral without needing to adapt to the underlying response protocol of the bridging chip separately, thereby reducing the complexity of peripheral driver development. Furthermore, when a new or removed peripheral device is added, or when the response protocol between the bridge chip and the domain controller is adjusted, adaptation can be achieved primarily by adjusting the unified parsing logic in the bridge chip driver, without needing to repeatedly modify the drivers of each peripheral device. This improves the scalability, maintenance convenience, and consistency of response data processing of the BMS peripheral access control method.

[0044] Optionally, in one embodiment, the step of generating a first access instruction by the peripheral driver according to the access requirements of the corresponding first peripheral and writing the first access instruction into the instruction buffer of the corresponding first peripheral includes: the peripheral driver generating the command content, response length, instruction type and execution status of the first access instruction according to the access requirements; and writing the command content, response length, instruction type and execution status into the corresponding instruction buffer, wherein the instruction type includes a read instruction and / or a write instruction, and the execution status includes at least one of a waiting to send status, a sending completed status and a response reading completed status.

[0045] Specifically, the command content characterizes the specific control content to be sent when accessing the first peripheral device. For example, when the first peripheral device is a pressure sensor, the command content may include a command code to read the pressure value; when the first peripheral device is an EEPROM chip, the command content may include a read command, a write command, a register address, or a memory address; when the first peripheral device is an AD sampling chip, the command content may include a sampling channel selection command or a sampling result reading command. The response length characterizes the expected data length to be returned after the first peripheral device executes the first access instruction. The instruction type distinguishes whether the first access instruction is a read instruction, a write instruction, or a combined read / write instruction. The execution status describes the state of the first access instruction in the current processing flow; for example, a waiting-to-send status indicates that the first access instruction has been written to the instruction buffer but has not yet been sent to the bridge chip; a sent-complete status indicates that the first access instruction has been sent to the bridge chip; and a response read-complete status indicates that the response data corresponding to the first access instruction has been read.

[0046] Furthermore, the peripheral driver can generate the aforementioned information based on the access requirements of the corresponding first peripheral during a periodic task, and write this information as part of the first access instruction into the corresponding instruction cache. When the bridge chip driver queries the instruction cache, it can determine whether the first access instruction needs to be sent based on the execution status; after sending, it can update the execution status; after the response data is read, it can further update the execution status or clear the corresponding cache content.

[0047] The access control method for BMS peripherals provided in this embodiment writes the command content, response length, instruction type, and execution status of the first access instruction into the corresponding instruction buffer. This allows the instruction buffer to store not only the command data to be sent but also information related to instruction sending, response reading, and status transitions. Therefore, when the bridge chip driver centrally queries and sends access instructions, it can determine the instruction processing stage based on the instruction type and execution status, and can perform subsequent response reading based on the response length, thereby improving the orderliness and traceability of the multi-peripheral access control process.

[0048] Optionally, in one embodiment, the response data includes SPI response data returned by a first peripheral and / or daisy-chain response data returned by a second peripheral; the step of reading and parsing the response data includes: reading the SPI response data and parsing the SPI response data according to the first peripheral, the instruction type of the first access instruction, and the response length corresponding to the SPI response data; and / or reading the daisy-chain response data and parsing the daisy-chain response data according to the device information and / or register information in the daisy-chain response data.

[0049] Specifically, the SPI response data returned by the first peripheral via SPI communication is typically SPI master-slave output data, that is, the raw response data returned by the first peripheral to the bridge chip via the SPI bus. Since the SPI response data itself is usually just a raw data stream and does not necessarily carry complete device identification, register addresses, or command meanings, the actual meaning of the SPI response data can be determined by combining the corresponding first peripheral, the instruction type of the first access instruction, and the response length. For example, when the first access instruction is a read instruction to read the pressure value of a pressure sensor, and the response length is two bytes, the read SPI response data can be parsed as a pressure value based on the first peripheral and the response length; when the first access instruction is a read instruction to read the contents of a memory chip, the SPI response data can be parsed as storage data based on the corresponding first peripheral and the instruction type.

[0050] Daisy-chain response data typically carries device information and / or register information. For example, data returned by a high-voltage sampling chip or AFE chip via a daisy-chain communication link may include device identifiers, register addresses, data fields, and checksum fields. After the domain controller reads the daisy-chain response data through the bridge chip driver, it can determine which sampling chip or AFE chip the response data originated from based on the device information, and determine the corresponding cell voltage, cell temperature, high-voltage sampling value, or equalization status based on the register information.

[0051] The BMS peripheral access control method provided in this embodiment employs different parsing criteria for SPI response data and daisy-chain response data. For SPI response data, parsing is performed by combining the corresponding first peripheral, instruction type, and response length, which can compensate for the lack of instruction meaning in the original SPI response data. For daisy-chain response data, parsing is performed using the device information and / or register information it carries, which can directly locate the source and meaning of the response data. This enables the domain controller to process data returned by different communication methods compatiblely within the same bridge chip driver framework, improving the accuracy and consistency of response data parsing.

[0052] Optionally, in one embodiment, the step of the bridge chip driver querying the instruction cache to determine the first access instruction to be sent includes: querying each instruction cache separately through the bridge chip driver to determine whether the first access instruction exists in each instruction cache; when the first access instruction exists in at least two instruction caches, determining the target instruction cache from the at least two instruction caches according to the instruction priority of the first peripheral, wherein the instruction priority is determined according to the functional real-time requirements of each first peripheral; and determining the first access instruction in the target instruction cache as the first access instruction to be sent.

[0053] Specifically, during runtime, the bridge chip driver can sequentially query the instruction buffer corresponding to each first peripheral to determine whether a first access instruction awaiting transmission exists in each instruction buffer. When only one instruction buffer contains a first access instruction, it can be directly used as the first access instruction to be transmitted. When at least two instruction buffers contain a first access instruction, the bridge chip driver can determine the target instruction buffer based on the instruction priority of the first peripheral and identify the first access instruction in the target instruction buffer as the first access instruction to be transmitted.

[0054] The instruction priority of the first peripheral can be determined based on the real-time requirements of its function. For example, a higher instruction priority can be set for a first peripheral with high real-time requirements and a need for fast response data acquisition; a lower instruction priority can be set for a first peripheral with lower real-time requirements and a need for delayed access. Instruction priorities can be pre-configured in the domain controller or written to the corresponding configuration parameters when initializing the instruction buffer.

[0055] The access control method for BMS peripherals provided in this embodiment determines the instruction priority based on the real-time requirements of the first peripheral when two or more instruction buffers contain first access instructions. The target instruction buffer is then determined accordingly, enabling the bridge chip driver to prioritize sending first access instructions with higher real-time requirements. This avoids disorderly contention for the bridge chip communication link when multiple first peripherals have access requests simultaneously, which helps improve the rationality of peripheral access scheduling and reduces the impact of low-priority access tasks on high-real-time peripheral access tasks.

[0056] Optionally, in one embodiment, the first peripheral is connected to the bridge chip via SPI communication, and the first peripheral corresponding to the first access instruction to be sent is the target first peripheral. The step of sending the first access instruction to be sent to the bridge chip includes: determining the SPI access parameters and chip select information corresponding to the target first peripheral; sending a configuration instruction to the bridge chip to configure the SPI control register of the bridge chip according to the SPI access parameters; sending a data write instruction to the bridge chip to write the transmission data corresponding to the first access instruction to be sent into the SPI transmission register of the bridge chip; sending a start instruction to the bridge chip to enable the bridge chip to select the target first peripheral according to the chip select information and access the target first peripheral via SPI communication; and clearing the sent instructions in the corresponding instruction buffer after the first access instruction to be sent is completed.

[0057] In this embodiment, SPI access parameters may include SPI clock frequency, clock polarity, clock phase, data transmission length, read / write direction, and other parameters. Chip select information is used to instruct the bridge chip to select the target first peripheral from among multiple first peripherals; for example, it may include the chip select channel number, chip select pin identifier, or chip select control mode. The bridge chip may include an SPI control register and an SPI transmit register. The SPI control register is used to configure the SPI access parameters, and the SPI transmit register is used to store data to be sent to the target first peripheral.

[0058] During the actual access process, the bridge chip driver first determines the target first peripheral based on the first access instruction to be sent, and obtains the SPI access parameters and chip select information corresponding to the target first peripheral. Then, the bridge chip driver sends a configuration instruction to the bridge chip, causing the bridge chip to configure the SPI control register according to the SPI access parameters; next, it sends a data write instruction to the bridge chip, writing the transmission data corresponding to the first access instruction into the SPI transmit register; subsequently, it sends a start instruction to the bridge chip, causing the bridge chip to select the target first peripheral according to the chip select information and trigger SPI transmission. After the SPI transmission is completed, the bridge chip driver can clear the transmitted instructions in the corresponding instruction buffer so that the corresponding peripheral driver can subsequently write new first access instructions.

[0059] The access control method for BMS peripherals provided in this embodiment enables the domain controller to indirectly control the bridge chip to complete SPI access to the target first peripheral by configuring the SPI control register, writing to the SPI transmit register, and sending a start command. After the transmission is completed, the transmitted command in the corresponding command buffer is cleared, which can also avoid repeatedly sending the same first access command and release the buffer space for subsequent commands.

[0060] Optionally, in one embodiment, the step of the peripheral driver generating a first access instruction according to the access requirements of the corresponding first peripheral includes: when multiple first access instructions are generated according to the access requirements, the multiple first access instructions are divided into multiple instruction groups; within a task cycle, when the data transmission state of the first peripheral is idle, one instruction group from the multiple instruction groups is written into the instruction buffer of the first peripheral, and the data transmission state of the first peripheral is set to busy; after the bridge chip driver completes the transmission of the instruction group, the data transmission state of the first peripheral is updated to idle; wherein, when the data length of the first access instruction in the instruction group is greater than the maximum transmission length of the bridge chip at one time, the first access instruction is split into multiple data packets, and the multiple data packets are sent to the bridge chip in multiple batches.

[0061] Specifically, a single access request for a primary peripheral may require multiple primary access instructions to complete. For example, complex function configuration, continuous register reading, and batch data writing for an SPI peripheral may require executing multiple read / write instructions consecutively. If all primary access instructions are sent at once within a single task cycle, the bridge chip's communication resources may be occupied by that primary peripheral for an extended period, thus affecting the execution of other BMS tasks. Therefore, multiple primary access instructions are divided into multiple instruction groups, and written and sent gradually within different task cycles.

[0062] The data transmission status of the first peripheral is used to indicate whether the first peripheral is currently transmitting data. An idle state indicates that the first peripheral has no pending instruction group transmissions and can write new instruction groups; a busy state indicates that the first peripheral already has instruction groups waiting to be sent or is sending, and no new instruction groups will be written repeatedly. When the data transmission status of the first peripheral is idle, one instruction group from multiple instruction groups can be written to the instruction buffer of the first peripheral within a task cycle, and the data transmission status of the first peripheral is set to busy. After the bridge chip driver completes the transmission of the instruction group, the data transmission status of the first peripheral is updated back to idle, allowing the peripheral driver to write the next instruction group in subsequent task cycles.

[0063] Furthermore, if the data length of a first access instruction in the instruction group exceeds the maximum single transmission length of the bridging chip, it indicates that the bridging chip cannot complete the transmission of all data for that first access instruction in a single transmission. In this case, the first access instruction can be split into multiple data packets, each with a data length not exceeding the maximum single transmission length of the bridging chip, and these multiple data packets can be sent to the bridging chip in multiple transmissions. This method can adapt to differences in data length under different first peripherals and different access requirements.

[0064] The BMS peripheral access control method provided in this embodiment, based on the generation of first access instructions by each peripheral driver and the centralized transmission of first access instructions by the bridge chip driver, can avoid a single first peripheral access task occupying the bridge chip communication resources for a long time when the access requirement of a certain first peripheral requires multiple first access instructions. This is achieved by dividing the multiple first access instructions into multiple instruction groups and writing and sending only one instruction group within a task cycle. Simultaneously, when the data length of the first access instruction exceeds the maximum single transmission length of the bridge chip, it is split into multiple data packets and sent in batches. This allows the method to adapt to access tasks with different data lengths, thereby improving the scheduling flexibility of multiple peripheral access tasks in a coreless BMS controller and reducing the impact of long data access tasks on other BMS control tasks.

[0065] Example 2 This invention also provides an access control method for BMS peripherals. Figure 3 This is a block diagram of the access control system for BMS peripherals provided in Embodiment 2 of the present invention. This embodiment is for a coreless BMS controller based on a bridge chip-based distributed instruction encapsulation and centralized instruction processing. The system framework for implementing this method is as follows: Figure 3 As shown in the diagram. In this embodiment, all control logic and data processing are centralized at the domain controller. The bridge chip in the coreless BMS controller communicates with the domain controller via UART. The domain controller operates various peripherals by controlling the bridge chip. An MCU is set up on the domain controller side, and the control logic is implemented based on the bridge chip driver and peripheral drivers to achieve distributed encapsulation and centralized processing. The bridge chip and each SPI peripheral communicate via SPI. The chip select signal of each SPI peripheral is controlled by different GPIOs (General Purpose Input / Output) of the bridge chip. Different peripheral instruction priorities are assigned according to the real-time requirements of each SPI peripheral function. Each SPI peripheral driver is executed separately in a periodic task. The read and write instructions are encapsulated in their respective peripheral drivers and stored in the instruction buffer of that driver. When the bridge chip driver is running, the instructions that different SPI peripherals need to send are centrally sent to the corresponding SPI peripherals through the bridge chip and the SPI bus according to the peripheral instruction priorities. The bridging chip and the sampling chip communicate via a daisy-chain communication method. Optionally, the sampling chip includes a high-voltage sampling chip and an AFE chip (i.e., analog front-end chip). The high-voltage sampling chip is used to collect parameters of the high-voltage circuit of the battery pack, such as the total voltage of the battery pack, the bus voltage, the pre-charge circuit voltage, and the voltage across the relay. The AFE chip is used to collect cell parameters, such as cell voltage and cell temperature, and can also be used to perform cell equalization control.

[0066] The method provided in this embodiment includes the following steps: Step S1: Initialize the domain controller. The specific implementation method is as follows: Initialize the domain controller's MCU, completing the relevant configurations for interrupts, clocks, and ports. Initialize the relevant variables and configuration parameters of the coreless BMS controller bridge chip on the domain controller's MCU. Initialize the request instruction buffers for different peripherals, and write the configuration parameters (SPI polarity and phase, maximum number of bytes transmitted per instruction, etc.) for each peripheral.

[0067] Step S2 involves running the drivers for each peripheral device and collecting peripheral read / write command requests in a distributed manner. The specific implementation method is as follows: In the periodic task, each peripheral driver is run, recording the content of the command to be sent, which peripheral the command request comes from, the expected response length, the type of the current request instruction (read instruction or write instruction), and the execution status of the current peripheral instruction (waiting to send, sending completed, successfully reading response data, etc.), and storing the above information in the BUFFER of the corresponding peripheral.

[0068] Step S3: Run the bridge chip driver and send commands to control peripherals. Figure 4 This is a flowchart illustrating the process of running the bridge chip driver and sending instructions to control the peripheral in the BMS peripheral access control method provided in Embodiment 2 of the present invention, as follows: Figure 4 As shown, the specific implementation method can be divided into the following sub-steps: Step S201: First, check if the bridging chip has received response data from the peripheral device; Step S202: Determine if there is any response data; If the bridging chip receives response data from the peripheral device, it executes step S203: centrally parses and processes the response data, that is, reads the response data and centrally parses and processes this response data in the bridging chip driver.

[0069] If the bridge chip does not receive response data from the peripheral device, then step S204 is executed: encapsulate the AFE's read voltage, read temperature, and equalization switch instructions, that is, encapsulate the AFE (analog front-end chip)'s read cell voltage, read cell temperature, and control equalization switch instructions in the bridge chip driver.

[0070] Step S205: Send a write command to modify the SPI control register (clock, data length), write to the SPI transmit register, configure chip select mode to start communication, clear the buffer of the sent command, and modify the execution status. That is, based on the peripheral command priority, query which peripheral command request needs to be executed, and send a write command through the domain controller to modify the SPI control register of the bridge chip, setting the clock parameters, data length, etc., for this communication. Then, write the data to be sent to the SPI peripheral into the SPI transmit register of the bridge chip, configure the start bit and chip select mode of the SPI control register. The chip select mode corresponds to the CS (Chip Select) pin of the peripheral to be operated. The domain controller sends a write command to trigger the SPI communication of the bridge chip. Finally, clear the buffer of the peripheral that has already sent the command, modify the execution status of the peripheral command, and wait for the next time to add command data in the peripheral driver function.

[0071] Step S206: Send commands to read voltage, read temperature, and control the equalization switch. That is, the domain controller sends commands to read cell voltage, read cell temperature, and control the equalization switch to complete the AFE-related functions.

[0072] Step S4: The domain controller jumps to step S2 and continues to execute a new round of control logic.

[0073] This embodiment proposes a coreless BMS peripheral access control method based on a bridge chip, employing distributed instruction encapsulation and centralized instruction processing. Compared to traditional BMS controller solutions, this method eliminates the need for an MCU in the BMS controller, reducing its cost. Furthermore, it eliminates the need for separate debugging of the domain controller and BMS controller programs, allowing for more direct software problem localization. Moreover, the distributed instruction encapsulation and centralized instruction processing effectively avoid the chaotic management of peripheral request instructions and AFE request instructions compared to centralized instruction encapsulation. After sending an instruction to a single peripheral, only its own buffer needs to be cleared. This decoupling management of different peripheral driver functions and data buffers prevents mutual interference between different peripherals. Simultaneously, the modular management approach efficiently handles situations requiring the replacement or addition of peripheral chips, significantly reducing development complexity. During communication between the domain controller and the bridge chip, each round of control logic consists of interleaved parsing of response data, sending of SPI peripheral instructions, and sending of AFE-related instructions, achieving periodic coordination between SPI peripheral instructions and AFE tasks.

[0074] Example 3 Corresponding to Embodiment 1 above, this embodiment of the invention also provides an access control system for BMS peripherals. For example... Figure 1 and Figure 3As shown, the system includes a domain controller and a BMS controller. The BMS controller does not have an internal MCU. The domain controller communicates with the bridge chip in the BMS controller, and the bridge chip communicates with the BMS peripherals. The BMS peripherals include multiple first peripherals. The domain controller is equipped with a bridge chip driver, a peripheral driver, and an instruction buffer. The first peripherals, the instruction buffer, and the peripheral driver correspond one-to-one.

[0075] The domain controller initializes the instruction buffer, runs the peripheral driver, and generates a first access instruction based on the access requirements of the corresponding first peripheral. This first access instruction is then written into the instruction buffer of the corresponding first peripheral. The domain controller also runs the bridge chip driver, which queries the instruction buffer to determine the first access instruction to be sent and sends it to the bridge chip. The bridge chip then accesses the first peripheral based on the received first access instruction.

[0076] In this system, the domain controller is responsible for the generation, caching, querying, and sending management of the first access commands, while the bridge chip in the BMS controller is responsible for the low-level access execution functions for the first peripherals. Since the BMS controller does not have an internal MCU, there is no need to deploy an MCU program locally on the BMS controller for peripheral access scheduling and data processing. The peripheral drivers and command buffers corresponding to different first peripherals are all located on the domain controller side, allowing for separate management of the generation and caching of first peripheral access commands within the domain controller. The bridge chip driver is also located on the domain controller side, used for centralized querying of each command buffer and unified sending of access commands to the bridge chip.

[0077] The BMS peripheral access control system provided in this embodiment sets up peripheral drivers and instruction buffers corresponding one-to-one with multiple first peripherals on the domain controller side. The bridging chip on the domain controller side centrally queries and sends first access instructions, enabling the BMS controller to access multiple first peripherals through the bridging chip without requiring an MCU. This reduces the number of control chips inside the BMS controller and the complexity of local software, while enabling distributed encapsulation and centralized processing of different first peripheral access instructions on the domain controller side, improving the maintainability and scheduling order of multi-peripheral access control.

[0078] Optionally, in one embodiment, the first peripheral is connected to the bridge chip via SPI communication. The BMS peripheral further includes a second peripheral connected to the bridge chip via daisy-chain communication. The domain controller is further configured to run the bridge chip driver, encapsulate a second access instruction for accessing the second peripheral, and send the second access instruction to the bridge chip. The bridge chip is further configured to access the second peripheral according to the second access instruction.

[0079] Optionally, in one embodiment, the domain controller is further configured to query the response status of the bridge chip through the bridge chip driver, wherein the response status is used to characterize whether the bridge chip has received response data returned by the BMS peripheral, and when the response status characterizes that the bridge chip has received the response data, the response data is read and parsed through the bridge chip driver.

[0080] Optionally, in one embodiment, the step of generating a first access instruction by the peripheral driver according to the access requirements of the corresponding first peripheral and writing the first access instruction into the instruction buffer of the corresponding first peripheral includes: the peripheral driver generating the command content, response length, instruction type, and execution status of the first access instruction according to the access requirements; and writing the command content, response length, instruction type, and execution status into the corresponding instruction buffer, wherein the instruction type includes a read instruction and / or a write instruction, and the execution status includes at least one of a waiting to send status, a send completed status, and a response read completed status.

[0081] Optionally, in one embodiment, the response data includes SPI response data returned by the first peripheral and / or daisy-chain response data returned by the second peripheral. The step of reading and parsing the response data includes: reading the SPI response data and parsing the SPI response data according to the first peripheral corresponding to the SPI response data, the instruction type of the first access instruction, and the response length; and / or reading the daisy-chain response data and parsing the daisy-chain response data according to the device information and / or register information in the daisy-chain response data.

[0082] Optionally, in one embodiment, the step of querying the instruction cache through the bridge chip driver to determine the first access instruction to be sent includes: querying each instruction cache through the bridge chip driver to determine whether the first access instruction exists in each instruction cache; when the first access instruction exists in at least two instruction caches, determining a target instruction cache from the at least two instruction caches according to the instruction priority of the first peripheral, wherein the instruction priority is determined according to the real-time requirements of the functions of each first peripheral; and determining the first access instruction in the target instruction cache as the first access instruction to be sent.

[0083] Optionally, in one embodiment, the first peripheral is connected to the bridge chip via SPI communication, and the first peripheral corresponding to the first access instruction to be sent is the target first peripheral. The step of sending the first access instruction to be sent to the bridge chip includes: determining the SPI access parameters and chip select information corresponding to the target first peripheral; sending a configuration instruction to the bridge chip to configure the SPI control register of the bridge chip according to the SPI access parameters; sending a data write instruction to the bridge chip to write the transmission data corresponding to the first access instruction to be sent into the SPI transmission register of the bridge chip; sending a start instruction to the bridge chip to enable the bridge chip to select the target first peripheral according to the chip select information and access the target first peripheral via SPI communication; and clearing the sent instructions in the corresponding instruction buffer after the first access instruction to be sent is completed.

[0084] Optionally, in one embodiment, the step of the peripheral driver generating a first access instruction according to the access requirements of the corresponding first peripheral includes: when multiple first access instructions are generated according to the access requirements, dividing the multiple first access instructions into multiple instruction groups; within a task cycle, when the data transmission state of the first peripheral is idle, writing one of the instruction groups into the instruction buffer of the first peripheral, and setting the data transmission state of the first peripheral to busy; after the bridge chip driver completes the transmission of the instruction group, updating the data transmission state of the first peripheral to idle; wherein, when the data length of the first access instruction in the instruction group is greater than the maximum single transmission length of the bridge chip, splitting the first access instruction into multiple data packets, and sending the multiple data packets to the bridge chip in multiple batches.

[0085] Example 4 This invention also provides a vehicle. The vehicle includes the access control system for the BMS peripherals described in the above embodiments. The vehicle can be a pure electric vehicle, a hybrid vehicle, an energy storage vehicle, or other vehicles using a power battery pack. The vehicle includes a power battery pack, a domain controller, and a BMS controller. The BMS controller does not have an internal MCU; the bridge chip in the BMS controller is communicatively connected to the domain controller and also to the BMS peripherals. The domain controller is equipped with a bridge chip driver, a peripheral driver, and an instruction buffer, enabling it to perform access control on the BMS peripherals according to the access control method provided in the above embodiments.

[0086] During vehicle operation, the domain controller determines the access requirements for BMS peripherals based on the vehicle's operating status and power battery management needs. The peripheral driver for the corresponding first peripheral generates a first access command based on the access requirement and writes it to the command buffer of the corresponding first peripheral. The bridge chip driver queries the command buffer to determine the first access command to be sent and sends it to the bridge chip in the BMS controller. The bridge chip accesses the corresponding first peripheral based on the received first access command and returns the data from the first peripheral to the domain controller via the bridge chip. The domain controller can further perform battery status judgment, peripheral status monitoring, or vehicle-related control strategy calculations based on the returned data.

[0087] The vehicle using this embodiment, by setting up the aforementioned BMS peripheral access control system within the vehicle, can centralize the generation and scheduling of BMS peripheral access commands to the domain controller side. This allows the BMS controller to control access to multiple BMS peripherals without requiring an internal MCU. Consequently, it reduces the hardware and software maintenance costs of the BMS controller and makes the vehicle's electronic and electrical architecture more suitable for a centralized domain control approach.

[0088] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0089] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0090] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0091] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. An access control method for BMS peripherals, characterized in that, The method is applied to a domain controller, which is communicatively connected to a bridge chip in a BMS controller. The BMS controller does not have an internal MCU. The bridge chip is communicatively connected to BMS peripherals, which include multiple first peripherals. The domain controller is equipped with a bridge chip driver, a peripheral driver, and an instruction cache. The first peripherals, the instruction cache, and the peripheral driver correspond one-to-one. The method includes: Initialize the instruction buffer; Run the peripheral driver, and the peripheral driver generates a first access instruction according to the access requirements of the corresponding first peripheral, and writes the first access instruction into the instruction cache area of ​​the corresponding first peripheral; Run the bridge chip driver, query the instruction buffer through the bridge chip driver, and determine the first access instruction to be sent; and The first access instruction to be sent is sent to the bridge chip, wherein the bridge chip is used to access the first peripheral device according to the received first access instruction.

2. The access control method for BMS peripherals according to claim 1, characterized in that, The first peripheral is connected to the bridge chip via SPI communication. The BMS peripheral also includes a second peripheral connected to the bridge chip via daisy-chain communication. The method further includes: Run the bridge chip driver to encapsulate a second access instruction for accessing the second peripheral; The second access instruction is sent to the bridge chip, wherein the bridge chip is used to access the second peripheral device according to the second access instruction.

3. The access control method for BMS peripherals according to claim 2, characterized in that, The method further includes: The response status of the bridge chip is queried through the bridge chip driver, wherein the response status is used to characterize whether the bridge chip has received response data returned by the BMS peripheral. When the response status indicates that the bridging chip has received the response data, the bridging chip driver reads and parses the response data.

4. The access control method for BMS peripherals according to claim 3, characterized in that, The step of generating a first access instruction by the peripheral driver according to the access requirements of the corresponding first peripheral, and writing the first access instruction into the instruction buffer of the corresponding first peripheral includes: The peripheral driver generates the command content, response length, instruction type, and execution status of the first access instruction based on the access request. Write the command content, response length, instruction type, and execution status into the corresponding instruction cache area; The instruction type includes read instructions and / or write instructions, and the execution state includes at least one of waiting to send, sending completed, and responding to read completed.

5. The access control method for BMS peripherals according to claim 4, characterized in that, The response data includes SPI response data returned by the first peripheral and / or daisy-chain response data returned by the second peripheral. The steps of reading and parsing the response data include: Read the SPI response data, and parse the SPI response data according to the first peripheral device corresponding to the SPI response data, the instruction type of the first access instruction, and the response length; and / or Read the daisy-chain response data and parse the daisy-chain response data based on the device information and / or register information in the daisy-chain response data.

6. The access control method for BMS peripherals according to claim 1, characterized in that, The step of querying the instruction cache through the bridge chip driver to determine the first access instruction to be sent includes: The bridge chip driver queries each instruction cache to determine whether the first access instruction exists in each instruction cache. When the first access instruction exists in at least two of the instruction caches, the target instruction cache is determined from the at least two instruction caches according to the instruction priority of the first peripheral device, wherein the instruction priority is determined according to the real-time requirements of the functions of each of the first peripheral devices. The first access instruction in the target instruction buffer is determined as the first access instruction to be sent.

7. The access control method for BMS peripherals according to claim 1, characterized in that, The first peripheral is connected to the bridge chip via SPI communication. The first peripheral corresponding to the first access command to be sent is the target first peripheral. The step of sending the first access command to be sent to the bridge chip includes: Determine the SPI access parameters and chip select information corresponding to the target first peripheral; Send configuration instructions to the bridge chip to configure the SPI control register of the bridge chip according to the SPI access parameters; Send a data write instruction to the bridge chip to write the transmission data corresponding to the first access instruction to be sent into the SPI transmission register of the bridge chip; A start command is sent to the bridging chip, causing the bridging chip to select the target first peripheral according to the chip select information and access the target first peripheral via SPI communication; and After the first access instruction to be sent is completed, the sent instructions in the corresponding instruction buffer are cleared.

8. The access control method for BMS peripherals according to claim 1, characterized in that, The step of the peripheral driver generating a first access instruction according to the access requirements of the corresponding first peripheral includes: When multiple first access instructions are generated according to the access requirements, the multiple first access instructions are divided into multiple instruction groups; During a task cycle, when the data transmission status of the first peripheral is idle, one of the multiple instruction groups is written into the instruction buffer of the first peripheral, and the data transmission status of the first peripheral is set to busy. After the bridge chip driver completes the transmission of the instruction group, it updates the data transmission status of the first peripheral to the idle state. Specifically, when the data length of the first access instruction in the instruction group is greater than the maximum single transmission length of the bridging chip, the first access instruction is split into multiple data packets, and the multiple data packets are sent to the bridging chip in batches.

9. An access control system for BMS peripherals, characterized in that, The system includes a domain controller and a BMS controller. The BMS controller does not have an internal MCU. The domain controller is communicatively connected to a bridge chip in the BMS controller. The bridge chip is communicatively connected to BMS peripherals. The BMS peripherals include multiple first peripherals. The domain controller is equipped with a bridge chip driver, a peripheral driver, and an instruction cache. The first peripherals, the instruction cache, and the peripheral driver correspond one-to-one. The domain controller is used to initialize the instruction cache, run the peripheral driver, generate a first access instruction according to the access requirements of the corresponding first peripheral, write the first access instruction into the instruction cache of the corresponding first peripheral, run the bridge chip driver, query the instruction cache through the bridge chip driver, determine the first access instruction to be sent, and send the first access instruction to be sent to the bridge chip. The bridging chip is used to access the first peripheral device according to the received first access instruction.

10. A vehicle, characterized in that, The access control system includes the BMS peripheral as described in claim 9.

Images