企业官网建设流程全解析

最近在折腾一块 STM32C5 开发板，正好手边有一颗 IIS2ICLX。这颗芯片是意法半导体主攻工业倾斜测量和低频振动监测的双轴加速度计，内部 16 位 ADC，在 ±0.5g 量程下的典型灵敏度能做到 0.0154 mg/LSB 这个级别。光看参数就知道，它不是拿来玩简单计步的，而是奔着高分辨率测量去的。IIS2ICLX 的物理接口同时支持 I2C 和 SPI，我这次选择用 SPI，原因后面会展开：如果要拉高输出数据率、配合 FIFO 批量搬数据，SPI 的时钟驱动和连续读能力比 I2C 干净得多。

这篇是 IIS2ICLX 系列博客的第一篇，目标定得很小：把 STM32C5 的 SPI 外设和 IIS2ICLX 之间的链路打通，正确读出 X/Y 两轴加速度原始值，再换算成 mg 或 g 在串口上打出来。整个过程不涉及 FFT、不涉及姿态解算，甚至不用 FIFO 和 DMA，先确认最底层的寄存器访问是对的。我见过太多人在高分辨率流式传输这件事上折腾一整天，最后发现其实连 WHO_AM_I 都读不回来。如果你是第一次在 STM32 上接数字加速度计，这一篇足够让你少走几条弯路。

1. 为什么是STM32C5加IIS2ICLX，以及这个组合的关键特点

1.1 STM32C5的定位：Cortex-M33的新一代主流选择

先聊主控。STM32C5 是 ST 新推出的一代 MCU 系列，内核换成了 Arm Cortex-M33，相比 C0 系列的 M0+ 内核，性能、中断响应和安全特性都有了明显提升。放在几年前，M33 内核基本属于中高端定位，现在被压到更主流的价位段，这就让“一颗低成本的 MCU 去接高精度 MEMS 传感器”这件事变得很划算。我手上这颗芯片最大的感触是：外设没有堆得很夸张，但该有的都给了——SPI、I2C、UART、定时器、DMA 一应俱全，做传感器数据采集绰绰有余。

需要提醒的是，STM32C5 这颗料相对比较新，在 STM32CubeMX 里如果要选到对应型号，记得先升级 CubeMX 和 STM32Cube 固件包到较新版本。我一开始用旧版本打开，芯片列表里压根找不到 C5 开头型号，换了个新版本才正常。这个坑很基础，但确实容易卡人。

1.2 IIS2ICLX不是普通三轴加速度计：双轴、高分辨、低噪声

很多做消费电子出身的人看到加速度计，第一反应是三轴 XYZ。IIS2ICLX 不是这个路数，它是双轴加速计，只输出 X 和 Y，也就是水平面内两个正交方向。可能有人会疑惑：现在手机里的加速度计不都三轴吗？没错，但 IIS2ICLX 的设计目标是工业倾斜测量、平台水平校准、结构健康监测这类场景。工业上很多需求只需要知道设备相对重力方向的两个角度，省掉一路 Z 轴，把面积和功耗留给精度，这才是这颗芯片的核心定位。

它的分辨率是真的高。在 ±0.5g 量程下，16 位输出对应的灵敏度约为 0.0154 mg/LSB，这是什么概念？一个 LSB 对应的重力加速度变化量只有 0.0000154 g。也就是说，传感器能分辨出非常微小的倾斜角度变化。配合低噪声设计，它做倾角测量的分辨率能到 0.001° 级别，这在传统的 8 位、10 位加速度计上根本不敢想。

1.3 SPI接口选择的工程逻辑：为什么高分辨率场景默认走SPI

IIS2ICLX 同时支持 I2C 和 SPI，但我在项目里会优先选 SPI，理由其实不复杂。I2C 是半双工、帧格式里有地址确认和起始停止位，每次读数据都要做总线仲裁，速率和效率天然被协议限制。SPI 是全双工，主机给时钟，想读多少字节就连着读多少字节，尤其适合后面要做 FIFO 批量导出、连续高频采样的场景。

这颗芯片声称的高分辨率能力，往往要配合较高的数据率使用，比如几百赫兹的低频振动采样。这种情况下，SPI 的优势就非常明显：时钟由主机完全掌控，数据流可以做到严格连续，不会像 I2C 那样在主机和从机之间反复协商。不过这里要提前说清楚一个容易误解的点：高分辨率不等于必须用 SPI，I2C 在低速率下也能读出 16 位数据。选 SPI 更多是为了“数据连续性和高吞吐”，这个思考方式在第四章会专门展开。

2. CubeMX工程与接线：先把SPI物理层跑通

2.1 硬件接线：四线就够了

IIS2ICLX 的 SPI 接口是标准四线制：SCLK、MOSI（SDI）、MISO（SDO）、CS。板上供电我直接用 3.3V，传感器 VDD 和 VDDIO 并在一起接到同一个 3.3V 电源域。接线表如下：

有一个值得注意的细节：CS 片选我建议用普通 GPIO 来做软件片选，而不是硬件 NSS。原因有两点：一是 IIS2ICLX 是单从机，软件片选完全够用；二是硬件 NSS 在某些 MCU 上会自动输出，或者和 SPI 模式绑定，一旦没配好会出现片选信号异常，排查起来很恼火。软件片选把时序完全握在自己手里，调试阶段是最稳的方案。

2.2 CubeMX配置里的几个关键选择

在 CubeMX 里时钟配置好之后，把 SPI1 选为 Full-Duplex Master。参数配置上，我最关心的三个点分别是：

• 数据帧格式：8 位数据宽度，Motorola 帧格式，这符合绝大多数 MEMS 传感器的 SPI 协议。
• CPOL/CPHA：配置为 Mode 0（CPOL=0，CPHA=0）。IIS2ICLX 的手册时序图支持这种常规模式，SCLK 空闲时低电平，数据在上升沿采样。
• 时钟速率：先不要追求高速，我的初始配置把 SCLK 设成了 1 MHz 左右。SPI 从机对时序的要求通常不高，但我们在调试阶段要留足裕量，等确认链路稳定后再提高分频比。

模式 0 这几个参数看起来简单，但实际上很多传感器连接失败都出在这里。CPOL 或 CPHA 配置错一位，读回来的数据就是全 0 或者全 1，而且不会报错。第一次调试时可以把 SCLK 频率放低，再用逻辑分析仪看信号，确认每个字节的采样点都对上了，再慢慢提速。

2.3 NSS软件模式与GPIO初始化

CubeMX 里 SPI 的 NSS 要选 Software模式。如果选了硬件 NSS，MCU 可能会在传输时自动拉低片选，或者需要额外的时序配合，在单从机场景下反而麻烦。我用一个普通 GPIO 叫IIS2ICLX_CS_PIN，初始化时默认输出高电平，需要通信时再拉低，一个字节或一帧数据结束后拉高。

初始化代码大概是这样的：

GPIO_InitStruct.Pin = IIS2ICLX_CS_PIN; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull = GPIO_PULLUP; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(IIS2ICLX_CS_GPIO_PORT, &GPIO_InitStruct); HAL_GPIO_WritePin(IIS2ICLX_CS_GPIO_PORT, IIS2ICLX_CS_PIN, GPIO_PIN_SET);

CS 引脚为什么默认要拉高：IIS2ICLX 的片选是低有效，只有当 CS 为低时传感器才会响应 SPI 命令，所以空闲状态必须保持高电平。这个看似不起眼的行为，如果初始化时漏了，后面所有读写都会失效。

3. 寄存器体系与SPI读写时序：从WHO_AM_I开始验证链路

3.1 ST MEMS传感器的通用SPI读写格式

ST 的 MEMS 传感器在 SPI 通信上有一个很统一的套路：第一个字节是地址字节，其中最高位表示读写方向，bit7 为 1 表示读，为 0 表示写；剩下的位是寄存器地址。读操作时，主机发出地址字节后，从请求到读出数据会有一个字节的延迟，所以一次读操作往往需要发两个字节：第一个是地址，第二个是 dummy，真正的数据在接收缓冲的第二个字节里。

举个例子，要读 WHO_AM_I 寄存器（地址 0x0F），主机发出的第一个字节就是0x0F | 0x80 = 0x8F，然后发一个任意 dummy 字节，MISO 上返回的第二个字节就是寄存器内容。这个模式遇到过几次之后就熟门熟路了，第一次接触时容易犯的错是把返回值错误地取到第一个接收字节上，导致读出来永远是 0。

3.2 从WHO_AM_I到加速度数据：几个关键寄存器先过一遍

IIS2ICLX 的寄存器映射不算复杂，第一篇文章里我们只需要关心四个地方：

• WHO_AM_I（0x0F）：设备 ID 寄存器，上电后应读回一个固定的非 0 值。这是验证 SPI 链路是否打通的第一道关口。
• CTRL1（0x20）：模式控制寄存器，选择连续测量模式、输出数据率 ODR、量程等。
• CTRL3（0x22）：包含地址自动递增 IF_ADD_INC 位。置 1 后，连续读多个字节时会自动递增寄存器地址，不需要手动逐个指定。
• OUT_X_L / OUT_X_H / OUT_Y_L / OUT_Y_H（0x28~0x2B）：X 和 Y 轴的 16 位加速度原始值，低字节在前。

不同版本的数据手册对寄存器位的定义可能有细微差别，我第一次用新芯片时总会把 CTRL1 和 CTRL3 的位定义打印出来摆在旁边对照，这一步很值得做。因为这些位一旦配错，表现出的症状很多样：数据不动、数据只有一端变化、量程不对、正负方向相反，如果一开始不从寄存器表上校对，后面就要靠猜。

3.3 地址自增IF_ADD_INC与多字节连续读

ST 传感器对多字节读取提供了一个很贴心的机制：把 CTRL3 的 IF_ADD_INC 位置 1 后，只要在同一个片选周期内连续发送读命令和 dummy 字节，传感器内部就会自动把寄存器地址加 1。这意味着我们读四个字节只需要发一次地址，后面跟着四个 dummy，就能一口气把 X_L、X_H、Y_L、Y_H 全部取回来。

这个功能在你做高数据率采集时特别重要。如果没有地址自增，每读一个字节就要单独拉低 CS、发一次地址、拉高 CS，时序开销会大不少。开了自增之后，一次 CS 周期就能完成一帧数据的导出，不仅省时间，还能保证同一组 X/Y 数据来自同一个采样时刻，不会出现 X 是上一帧、Y 是这一帧的错位问题。

3.4 验证链路的第一步：读WHO_AM_I

代码写出来之前，先用最简单的方式确认 SPI 链路。我习惯的做法是：上电后立刻读 WHO_AM_I，把返回值通过串口打出来。如果返回值和数据手册上的设备 ID 一致，说明物理接线、SPI 模式、时钟极性全部正确，可以继续往下配置寄存器。如果读回来是 0x00，大概率是 MISO 没接通、数据采样点不对、或者第一个接收字节被误当成有效数据。如果读回来是 0xFF，则多半是 MOSI 或时钟极性出问题。

这一步怎么强调都不过分。很多人在 SPI 通信上浪费大半天，最后发现只是 dummy 字节顺序没搞清楚，或者 CPHA 配错了。先把 WHO_AM_I 弄对，后面所有寄存器配置才有可信的基础。

4. 高分辨率SPI读取与传统中断/轮询方式的异同：选型不只是接口选择

4.1 先把概念边界划清楚

说到“高分辨率 SPI 读取”和“传统中断/轮询方式”，很多人容易把这两个概念放在对立面：以为用了 SPI 就是高分辨率，用了中断就是传统方案。实际上，这两组词不在同一个维度上。SPI 是物理层接口，中断和轮询是应用层的数据读取策略。IIS2ICLX 完全可以走“中断触发 + SPI 单次读取”，也可以走“主循环轮询 + SPI 阻塞读取”，这些组合里都有 SPI 的身影。

我更倾向于把这次要对比的对象定义为两种系统架构：

• 流式批量读取架构：传感器持续采样，数据在 FIFO 里缓存，MCU 通过 SPI 批量导出，可能配合 DMA 直接把数据搬进内存。这种架构适合高数据率、需要连续样本的应用。
• 事件驱动单次读取架构：传感器每完成一次采样就通过 INT 引脚通知 MCU，MCU 才去 SPI 读一次；或者 MCU 按固定周期轮询状态位。这种架构适合低数据率、低功耗、事件触发类应用。

这样划清楚之后，比较才有意义：我们比的是“流式批量读”和“事件驱动单次读”，而不是单纯地比 SPI 和 GPIO。

4.2 延迟一致性、CPU占用、数据完整性三个维度

从工程学的角度，我习惯用三个维度去判断到底选哪种方案：延迟一致性、CPU 占用、数据完整性。

延迟一致性。中断方式的响应延迟最小，理论上数据就绪后 MCU 能立刻感知，但代价是延迟的确定性受中断优先级、其他中断抢占、以及 SPI 传输代码本身耗时的影响。举个例子，如果 ISR 里用阻塞式 SPI 读两个字节，SCLK 从产生到数据接收需要一段时间，这段时间内其他中断全被挡着。轮询方式就更不用说了，延迟完全取决于主循环什么时候转到这里，可能差出好几毫秒。流式批量读取的延迟是周期性的，数据以固定的节拍到内存，虽然单次事件的“实时响应”不如中断那样立竿见影，但整体时间轴非常均匀，这对后续做 FFT、做滤波非常友好。

CPU 占用。这是流式批量方案最大的优势。如果传感器以 1 kHz 输出频率采样，事件驱动模式下意味着每毫秒就要进一次中断，MCU 一秒钟被唤醒一千次，每次还要跑完整个 SPI 传输。而流式方案里，FIFO 可以攒下几百个样本，MCU 每隔一小段时间才批量搬一次，剩下的时间可以去跑算法、维护通信、睡大觉。对高数据率来说，CPU 占用率可能相差一个数量级。

数据完整性。高分辨率测量最怕的不是噪声，而是丢点。中断模式下，MCU 一旦在处理其他任务时错过了 INT 引脚的状态，这一帧样本就悄悄丢了。低频倾角测量丢一帧可能无所谓，但振动分析里数据流的连续性就是生命线，任何丢点都会在频谱上制造假峰。流式批量读取配合 FIFO，相当于给数据流加了一个缓冲保护，即便 MCU 被别的事情拖住几十毫秒，FIFO 里的样本也不会丢，缓冲满了还有溢出标志可以查。这三者的对比我总结成一张表：

4.3 分辨率不等于采样率，SPI也不等于快

这里想专门辟一个误区：很多人看到 IIS2ICLX 的 16 位分辨率，就觉得必须用 SPI 高速连续读取，否则浪费了这颗芯片。但“分辨率”和“采样率”是两个完全不同的概念。16 位分辨率描述的是每一个样本的量化精细度，它由内部 ADC 的量程和位数决定，跟你用 I2C 还是 SPI 读没有关系。哪怕你每秒只读一次，只要寄存器配置正确，读到的依然是 16 位精度的数据。

SPI 的真正价值在于它能够承载“高采样率下的连续数据流”。如果你做的是低频倾角监测，ODR 只有 1 Hz 到 12.5 Hz，那么用 I2C 或者轮询方式完全够用。只有当 ODR 到几百赫兹甚至上千赫兹、并且需要全部样本做连续分析时，SPI 的高吞吐能力才真正变成必要条件。选型第一件事，永远是先搞清楚应用到底需要多高的数据率，而不是看到“高分辨率”三个字就条件反射地选最贵的方案。

4.4 实际项目里我的决策方式

在真实的项目里，我的判断标准可以浓缩成三条。第一条，如果传感器输出数据率低于 100 Hz，且 MCU 主要功能是待机、通信、显示，那我倾向用中断驱动方式，数据就绪才读，省电且实现简单。第二条，如果 ODR 高于几百 Hz，且我需要完整的样本做频谱、滤波、趋势分析，那就毫不犹豫走 SPI + FIFO + DMA 的流式方案，这是唯一能保证数据连续性的做法。第三条，如果只是调试阶段验证传感器、标定零偏、看看基本输出是否符合预期，轮询就够，直接定时去读四个字节，简单直接。

这篇文章的第一版驱动，做的就是第三条路线：用最保守的阻塞式 SPI 轮询读取，先把传感器调通。代码结构上保留了三层分离的接口，后续切到中断触发或 DMA 批量搬移时，只需要替换最底层的读取函数，上层的换算和数据处理逻辑不用动。

5. 驱动代码实现：从阻塞式读寄存器到加速度换算

5.1 驱动分层：先想清楚再动手

写驱动之前，我习惯先分两层。第一层是 SPI 物理层，只负责发地址、收数据，不关心数据含义，这一层直接封装 HAL_SPI_TransmitReceive 系列函数；第二层是传感器寄存器层，负责组织寄存器地址、配置模式、读取输出数据、做补码换算。分层的好处是：将来要换成 DMA 读取，只需要重写物理层的函数，寄存器层的调用和换算逻辑完全不受影响。

5.2 SPI收发函数与寄存器读写函数

先定义片选操作和底层收发函数：

#define IIS2ICLX_CS_LOW() HAL_GPIO_WritePin(IIS2ICLX_CS_GPIO_PORT, IIS2ICLX_CS_PIN, GPIO_PIN_RESET) #define IIS2ICLX_CS_HIGH() HAL_GPIO_WritePin(IIS2ICLX_CS_GPIO_PORT, IIS2ICLX_CS_PIN, GPIO_PIN_SET) uint8_t IIS2ICLX_ReadReg(uint8_t reg) { uint8_t tx[2]; uint8_t rx[2] = {0}; tx[0] = reg | 0x80; // 读操作，最高位置1 tx[1] = 0x00; // dummy字节 IIS2ICLX_CS_LOW(); HAL_SPI_TransmitReceive(&hspi1, tx, rx, 2, 100); IIS2ICLX_CS_HIGH(); return rx[1]; // 有效数据在第二个接收字节 } void IIS2ICLX_WriteReg(uint8_t reg, uint8_t value) { uint8_t tx[2]; tx[0] = reg & 0x7F; // 写操作，最高位清零 tx[1] = value; IIS2ICLX_CS_LOW(); HAL_SPI_Transmit(&hspi1, tx, 2, 100); IIS2ICLX_CS_HIGH(); }

有不少人一上来就去查 FIFO 配置、查 DMA 通道，结果连寄存器读写函数都没写对。读函数返回rx[1]这个细节就是典型问题：如果返回了rx[0]，那个字节只是地址回显或无效数据，会导致后面所有断言全部失败。先把这个函数调对，其他都顺了。

5.3 初始化：配置CTRL3、CTRL1与量程

初始化要做的就是把芯片从默认状态切到连续测量模式，并打开地址自增。下面代码中的寄存器值是我在调试时使用的示例，具体位定义请务必对照你手上的数据手册做二次确认：

void IIS2ICLX_Init(void) { uint8_t id = 0; id = IIS2ICLX_ReadReg(0x0F); // WHO_AM_I printf("WHO_AM_I = 0x%02X\n", id); // 打开地址自增 IF_ADD_INC IIS2ICLX_WriteReg(0x22, 0x10); // CTRL3，示例值，按数据手册确认位定义 // 设置连续测量模式、ODR、量程 IIS2ICLX_WriteReg(0x20, 0x80); // CTRL1，示例值，按数据手册确认位定义 }

初始化这一步做两件事：读取 WHO_AM_I 确认链路，然后配置测量模式。如果你读回来的 ID 是 0 或者 0xFF，不要继续往下配寄存器，先把 SPI 物理层查干净。我在项目中见过太多人跳过 WHO_AM_I 直接配 CTRL1，最后数据出来的形态完全没规律，不得不回头检查链路，白白浪费大半天。

5.4 一次读四个字节：X/Y轴原始数据与换算

利用地址自增，一次片选读完四个输出寄存器。顺序是 X 低字节、X 高字节、Y 低字节、Y 高字节，拼成两个 int16_t：

void IIS2ICLX_ReadAccel(int16_t *acc_x, int16_t *acc_y) { uint8_t tx[5]; uint8_t rx[5] = {0}; tx[0] = 0x28 | 0x80; // OUT_X_L，读操作 tx[1] = 0x00; // dummy，对应 OUT_X_L tx[2] = 0x00; // dummy，对应 OUT_X_H tx[3] = 0x00; // dummy，对应 OUT_Y_L tx[4] = 0x00; // dummy，对应 OUT_Y_H IIS2ICLX_CS_LOW(); HAL_SPI_TransmitReceive(&hspi1, tx, rx, 5, 100); IIS2ICLX_CS_HIGH(); *acc_x = (int16_t)(rx[1] | (rx[2] << 8)); *acc_y = (int16_t)(rx[3] | (rx[4] << 8)); }

拿到原始值后，换算公式取决于量程和灵敏度。以 ±0.5g 量程为例，IIS2ICLX 的典型灵敏度是 0.0154 mg/LSB，换算关系如下：

#define IIS2ICLX_SENSITIVITY_MG 0.0154f // mg/LSB，±0.5g量程 float acc_x_mg = (float)acc_x * IIS2ICLX_SENSITIVITY_MG; float acc_y_mg = (float)acc_y * IIS2ICLX_SENSITIVITY_MG;

如果配置的是 ±1g、±2g、±3g 量程，灵敏度要对应减半、或按比例调整。这一点很容易被忽略，导致同一个静态角度下数据差了数倍。我一般会在驱动里做一个量程枚举和灵敏度表，每次改量程时同步换表，避免手动改数字改错。

5.5 主循环中的读取与打印

主循环就简单了，设置一个定时节奏，然后读取、换算、通过串口打印：

int16_t acc_x, acc_y; float x_mg, y_mg; while (1) { IIS2ICLX_ReadAccel(&acc_x, &acc_y); x_mg = (float)acc_x * IIS2ICLX_SENSITIVITY_MG; y_mg = (float)acc_y * IIS2ICLX_SENSITIVITY_MG; printf("X: %.3f mg, Y: %.3f mg\r\n", x_mg, y_mg); HAL_Delay(10); }

10 毫秒读一次，对应约 100 Hz 的数据率。在阻塞模式下，这个节奏已经能把 SPI 链路验证得很透彻了。把板子放平、放斜、翻过来，观察输出的正负方向和数值变化是否合理，这是验证加速度计最直观的手段。

6. 实测结果与调试经验：静态标定、常见坑、下一步扩展

6.1 静态验证：水平与竖直放置时数据表现

把这块传感器平放在桌面上，X 和 Y 轴的输出应该在 0 mg 附近小幅波动，波动幅度取决于传感器的噪声水平。再把传感器竖起来，让 Y 轴垂直指向地面，Y 轴输出会接近 ±1000 mg 左右；反过来 X 轴垂直指向地面时，X 轴也会有类似表现。通过这种简单的旋转，能立刻判断引脚映射、量程配置、正负方向是否正确。

这里有个细节值得注意：IIS2ICLX 是双轴传感器，没有 Z 轴，所以当你把传感器竖直放置、让某个轴完全垂直于重力方向时，另一个轴会看到接近 1000 mg 的重力分量。如果预期是三轴加速度计那种“Z 轴变 1g、其余两轴接近 0”的行为模式，用在这颗芯片上就会觉得“少了一轴”。这是芯片定位决定的，不是出了问题。

6.2 WHO_AM_I读不到？按这条链路去查

如果 WHO_AM_I 读出来不对，我建议按固定顺序排查：

• 线序：MISO 和 MOSI 有没有接反。接反后主机发出的地址从机收不到，从机返回的数据主机也收不到，症状就是读回 0xFF 或 0x00。
• SPI 模式：CPOL/CPHA 是否正确。模式配错时，采样点会落在数据变化的瞬间，读出的数据毫无规律。
• 片选时序：CS 是否在每次通信周期之间拉高。如果 CS 一直低着，传感器可能卡在某个状态，不再响应新的 SPI 命令。
• 时钟速率：很多传感器对 SCLK 的最高频率有上限，虽然 IIS2ICLX 不算慢，但在长杜邦线、无阻抗匹配的情况下，速率太高会导致数据错位，先降到 1 MHz 再测。
• 去耦电容：供电不稳、电源纹波大，也可能导致芯片上电没完成初始化，WHO_AM_I 读不到。传感器 VDD 旁边并一颗 100nF，大多数情况能解决稳定性问题。

排查链路的核心思想，是从“链路有没有通”到“链路通得对不对”到“芯片有没有正常工作”一层层剥。不要一上来就怀疑芯片坏了，实际上百分之九十的故障都出在接线和 SPI 参数上。

6.3 零偏与噪声毛刺：短时间波动用均值

任何加速度计都不可能完全零偏。IIS2ICLX 的高灵敏度意味着它会忠实地把微小的机械振动、热噪声、电路噪声全部带进数据里。静态放置时，数据在小范围内来回跳是很正常的，如果每个 LSB 换算后的值一直稳定在 0.0154 mg 的台阶上，那才说明传感器已经死掉了。

实际做倾角测量时，最简单的降噪手段就是滑动均值。我的做法是在驱动层保留原始数据，在应用层开一个长度为 16 或 32 的环形缓冲区，每来一个新样本就更新平均值。这样既不影响 SPI 读取的实时性，又能把高频噪声压下去。对静态倾角应用来说，这个方案性价比高到离谱，完全不需要先把数据做 FFT 分析再设计滤波器。

6.4 从轮询到FIFO与DMA：下一阶段的演进方向

这篇文章里我们一直用的是阻塞式轮询读取，它存在的意义就是把传感器链路先调通。等确认数据格式、量程、正负方向、零偏表现都符合预期后，下一步自然要往高分辨率流式方案走：配置传感器的 FIFO，把多组样本攒在芯片内部，然后通过 SPI DMA 批量搬到 MCU 内存。这样做的收益是双重的，一方面 CPU 不用频繁进出中断，另一方面数据流连续性好，给后续的时域分析和频域分析打底。

我自己做这类项目时，总是认同一句话：先把最简单的方式跑通，再往复杂方向演进。直接上 DMA 的方案省掉了理解传感器时序的机会，一旦出问题，芯片、接线、DMA、FIFO 四个变量搅在一起，谁也没法快速定位。先轮询跑通，等于把变量一个个消掉，后面再做优化时思路会清晰很多。

就写到这里，这颗芯片的 SPI 通路就算打通了。如果只是想先把 IIS2ICLX 跑起来，上面的驱动和调试思路已经够用；后面要做的 FIFO、DMA、真正的倾角算法，都是在这条已经验证过的链路上叠加。我调试传感器时最喜欢的顺序永远是：先读 WHO_AM_I，再转板子看输出方向，最后才碰传输优化，这个顺序帮我省下的时间，远比看起来多得多。