Performance Comparison and Trade-offs of CAN, I2C, and SPI Across Different Scenarios

The selection of communication protocols for modern Battery Management Systems (BMS) is no longer limited to a single standard; instead, it involves a multi-dimensional evaluation based on the specific requirements of the application scenario. As the three most common serial communication interfaces in embedded systems, CAN, I2C, and SPI are widely used in electric vehicles, energy storage systems, consumer electronics, and industrial equipment. Each possesses unique electrical characteristics, topologies, and protocol mechanisms, necessitating trade-offs among communication speed, reliability, resource utilization, scalability, and power consumption during actual deployment.

This chapter draws on empirical data to analyze the performance differences of these three protocols within typical BMS environments. By establishing a standardized testing platform, we collect key metrics—such as throughput, latency, and error rates—under varying load conditions and analyze their impact on overall system performance using MCU resource consumption models. The ultimate goal is to establish a quantifiable decision-making framework that assists engineers in selecting the optimal communication solution amidst complex design constraints.

It is worth noting that these protocols are not mutually exclusive; an increasing number of high-end BMS designs employ hybrid architectures. For instance, CAN might be used for highly reliable, long-distance communication between master control units, while I2C connects voltage and temperature sensors within individual battery modules, and SPI handles high-speed ADC sampling. Consequently, understanding the fundamental strengths and limitations of each protocol is a prerequisite for system-level optimization.

Empirical Comparison of Communication Speed ​​and Latency

In BMS systems, communication latency directly affects the real-time nature of state monitoring and the speed of fault response. In the context of electric vehicles, for example, a delay exceeding 5 ms in reporting abnormal individual cell voltage could compromise the effectiveness of thermal runaway warnings. Therefore, accurately measuring transmission latency and effective throughput for CAN, I2C, and SPI under realistic load conditions is crucial. This section utilizes a unified testing platform and the method of controlled variables to compare the performance of these three protocols across various data packet lengths and bus load conditions. Experimental Setup and Testing Methodology

• To ensure the comparability of test results, all experiments were conducted on the same hardware platform:
• Master MCU: STM32H743 (480 MHz Cortex-M7)
• Slave Device Simulators:
• CAN: MCP2515 + TJA1050 transceiver
• I2C: AT24C512 EEPROM + PCA9548A multiplexer
• SPI: W25Q64 Flash memory
• Signal Acquisition Tools: Keysight DSOX3054T oscilloscope (1 GHz bandwidth), Saleae Logic Pro 16 logic analyzer
• Software Layer: FreeRTOS v10.5.1, custom communication stress test task

Test Procedure Design
A “request-response” model is employed to simulate typical BMS communication behavior:

// General test task pseudo-code
void communication_test_task(void *pvParameters) {
TickType_t start, end;
uint8_t tx_data[32] = {0xAA};
uint8_t rx_data[32];
while(1) {
start = xTaskGetTickCount(); // Record the start timestamp
switch(protocol) {
case CAN:
can_transmit(CAN_ID_SENSOR_DATA, tx_data, 8);
can_receive(&rx_data, &len); // Block and wait for the echo acknowledgment
break;
case I2C:
i2c_write(DEVICE_ADDR, REG_CMD, 1); // Write to the command register
vTaskDelay(pdMS_TO_TICKS(1)); // Simulate slave processing time
i2c_read(DEVICE_ADDR, REG_DATA, rx_data, 8);
break;
case SPI:
spi_select_slave(SLAVE_FLASH);
spi_transfer(CMD_READ_DATA, tx_data, rx_data, 8);
spi_deselect_slave();
break;
}
end = xTaskGetTickCount();
uint32_t latency_us = (end - start) * portTICK_PERIOD_MS * 1000;
collect_statistics(latency_us); // Collect latency distribution statistics
vTaskDelay(pdMS_TO_TICKS(10)); // Control the transmission frequency
}
}

Line-by-line code logic analysis:

• xTaskGetTickCount()retrieves the FreeRTOS system tick counter value; its precision depends on `configTICK_RATE_HZ` (typically 1 kHz), meaning it updates once per millisecond.
• can_transmit()calls the underlying HAL library function to send a CAN message (including ID, DLC, and data fields), while `can_receive()` uses either interrupts or polling to receive the response frame.
• The I2C section first writes a command to trigger a slave device action, introduces a 1ms delay to simulate the sensor’s conversion time, and then reads the result; this represents a typical I2C sensor interaction pattern.
• SPI requires manual control of the Chip Select (CS) signal to ensure that only one peripheral is selected at any given time.
• The final calculated time difference accounts for protocol overhead, physical layer transmission time, slave device response latency, and software scheduling jitter.

Test Parameter Configuration Table

This setup is designed to reflect real-world BMS module communication scenarios: CAN for master-slave communication, I2C for connecting multiple sensors, and SPI for high-speed peripheral devices.

Test Topology (Mermaid Flowchart)

The figure illustrates the connection methods for three types of buses. CAN uses differential twisted-pair wiring, supporting long-distance, interference-resistant transmission; I2C shares SDA/SCL pins and relies on addresses to distinguish between devices; and SPI employs a point-to-point or daisy-chain architecture, requiring a dedicated Chip Select (CS) line to control each slave device.

Throughput Trends Under Varying Loads

To evaluate the protocol’s performance in high-concurrency scenarios, the number of packets transmitted per unit of time was incrementally increased, while effective throughput (in kbps) and average latency (in μs) were recorded. The test results are as follows:

Comparison Table: Throughput vs. Latency (Average Values)

Note: Frequent NACKs and SCL bus lock-ups occur with I2C at 1000 Hz, preventing stable communication.

Analysis Conclusions:

• SPI possesses a distinct speed advantage: At an SCLK of 20 MHz, the theoretical time for an 8-byte transfer is (8 × 8) / 20e6 ≈ 3.2 μs; including chip-select switching and driver overhead, the measured time is approximately 8–10 μs, approaching the physical limit. Its full-duplex capability also ensures high bus utilization.
• CAN demonstrates excellent determinism: Although the bit rate is only 500 kbps, the compact frame structure (requiring just 127 bits to transmit 8 bytes of data) and an arbitration mechanism that prevents collisions result in stable latency within the 130–190 μs range, making it suitable for periodic status broadcasting.
• I2C is constrained by bidirectional switching and slave response times: Each read operation requires two START conditions, address transmission, and ACK/NACK processing; combined with the EEPROM’s internal write cycle (typically 5 ms), the protocol is unsuitable for high-frequency communication tasks, even when operating in Fast Mode (400 kHz).

Throughput vs. Load Trend Chart (Mermaid Line Graph)

As shown, SPI maintains a consistently high throughput; CAN experiences a slight decline due to retransmissions and buffer queuing; and I2C performance collapses under high loads.

Further testing on the impact of data length on latency yielded the results shown in the table below:

Formula Derivation:

• CAN: Total bits = 1 + 11 (ID) + 1 (RTR) + 4 (DLC) + 8×n (data) + 15 (CRC) + … ≈ 127 bits at n=8 → 127 / 500e3 = 254 μs (theoretical maximum); actual measured values ​​are lower, indicating parallel processing.
• I2C: Requires 9 bits per byte (8 data + 1 ACK); plus address and control words, resulting in approximately linear growth.
• SPI: Strictly proportional to data length: (n × 8) / f_SCK.

In summary, SPI is undoubtedly the preferred choice for applications demanding extreme speed and low latency (such as ADC sampling synchronization). Meanwhile, CAN dominates in distributed systems requiring multi-node support and strong interference immunity, thanks to its robustness and priority-based arbitration mechanism. I2C is better suited for low-speed, short-range, and low-cost sensor connectivity scenarios.

Evaluation of Reliability and Interference Immunity

In industrial or automotive environments, electromagnetic interference (EMI), power supply fluctuations, and ground noise can severely compromise communication stability. A BMS must maintain data integrity under harsh conditions; failure to do so could lead to erroneous assessments or even safety incidents. This section focuses on evaluating the Bit Error Rate (BER) of CAN, I2C, and SPI in environments with high-frequency noise injection, as well as their recovery capabilities following bus collisions.

Bit Error Rate Testing in High-Frequency Noise Environments

Experimental Design

Controllable interference sources are introduced to simulate real-world operating conditions, such as switching power supply noise and back-EMF coupling from motors:

• Noise type: 2 MHz square wave, ±1 V peak-to-peak, injected into the power line via capacitive coupling
• Injection location: PCB trace area adjacent to communication lines
• Duration: 1 hour per test; the number of error frames is recorded

Error criteria:

• CAN: FIFO overflow, CRC check failure, missing ACK
• I2C: NACK response, SCL/SDA bus lockup, timeout
• SPI: MISO data mismatch with expected values ​​(verified via loopback)
• BER Test Results Table

Bit Error Rate Test Results Table

Note: BER = Number of error bits / Total number of transmitted bits.

Analysis of Interference Immunity

CAN performs best: Thanks to differential signaling (CAN_H – CAN_L), Manchester-style NRZ encoding, bit-stuffing rules, and robust CRC-15 error checking, it maintains an extremely low error rate even in the presence of strong noise. Crucially, its automatic retransmission mechanism allows for immediate resending upon error detection without requiring host intervention.

I2C is the most vulnerable: Its open-drain architecture makes rising edges dependent on external pull-up resistors; noise can easily pull the SDA or SCL lines low unexpectedly, disrupting the state machine. If a deadlock occurs where a slave holds the SCL line low, the host must issue nine additional clock pulses to release the bus.

// I2C bus recovery function example
void i2c_bus_recovery(void) {
gpio_set_mode(GPIOB, GPIO_MODE_OUTPUT); // Switch SCL to GPIO mode
for(int i = 0; i < 9; i++) {
gpio_clear(GPIOB, GPIO_PIN_6); // Pull SCL low
delay_us(5);
gpio_set(GPIOB, GPIO_PIN_6); // Release SCL (pull-up)
delay_us(5);
}
// Attempt to generate a STOP condition to restore normal state
i2c_generate_stop(I2C1);
}

Code explanation:

• Switch the SCL pin to standard GPIO output mode, bypassing the hardware I2C controller.
• Send nine consecutive clock pulses to force all slave devices to exit their current operations.
• Finally, generate a STOP condition to reset the bus state.
• This method complies with I2C specifications but increases software complexity.
• SPI falls somewhere in between: although it uses single-ended signaling, the high-speed clock results in a short noise integration time, and trace lengths are typically short. However, SPI lacks built-in error detection mechanisms; data errors cannot be detected unless a CRC or checksum is implemented at the application layer.

Comparison of Bus Conflict Handling and Recovery Mechanisms

When multiple master devices attempt to access the bus simultaneously, the protocol’s handling of conflicts directly determines system availability.

One of CAN’s core advantages is its “non-destructive arbitration”: all nodes transmit simultaneously and determine whether they have won arbitration by monitoring the bus level. Messages with low IDs (high priority) remain unaffected, while messages with high IDs automatically back off and retransmit.

In contrast, although I2C supports multi-master configurations, it is rarely used in actual BMS applications due to difficulties with bus recovery and its sensitivity to timing. SPI lacks any concept of arbitration; if two master devices drive the MOSI/MISO lines simultaneously, it can result in a short circuit or data corruption.

Multi-master contention recovery flowchart (Mermaid)

Thus, it is evident that CAN far surpasses I2C and SPI in terms of reliability design, making it particularly suitable for safety-critical systems, whereas I2C and SPI rely more heavily on sound system planning to avoid conflicts.