企业官网建设流程全解析

简介：这份rar压缩包围绕DA217设备提供G-senor（加速度传感器）与pagerwe驱动的纯C实现，面向物联网和嵌入式开发者，适用于健身追踪、设备姿态检测、无线数据传输等场景，可帮助解决传感器接入及通信模块驱动适配问题。包体很小，仅2KB，总共3个文件，包含mir3da.c驱动源代码、mir3da.h头文件以及readme.txt说明文档，结构清晰，便于对照阅读和二次开发。目前已有497人学习下载，说明这一驱动方案对DA217相关项目具有一定参考价值。从源码与说明中，使用者可以掌握传感器初始化、数据读取、设备控制等核心函数实现，并理解pagerwe无线通信协议的数据收发流程。同时借助readme中的编译与安装指引，能够快速将驱动移植到不同C语言平台，进而用于健身追踪器的计步、设备的姿态检测或安防系统的位移监测等场景，有效缩短产品开发周期，降低物联网项目的集成门槛。

1. DA217 G-sensor 驱动包到底要干什么

拿到一个命名成G-sensor_pagerwe的驱动压缩包，第一件事不是解压，而是先认清这个包在系统里处于哪一层。DA217 是一颗三轴加速度传感器，走 I2C 接口，常见于平板、智能手表和工业手持设备，用来做屏幕旋转、计步、跌倒检测和自由落体保护。所谓“驱动”，在这个场景里通常包含三层内容：内核态的 I2C 客户端驱动、用户态的校准工具、以及设备树或板级配置。驱动包名里的pagerwe常见于方案商的版本代号，不同方案商的命名习惯都不一样，但解压后目录结构通常会暴露它的出处。

这颗芯片本身并不复杂，但在实际项目中，真正消耗时间的从来不是把 I2C 寄存器读出来，而是数据方向、量程、ODR（输出数据速率）和中断行为是否跟产品定义一致。屏幕旋转要的是低频低功耗，计步要的是高 ODR 和阈值过滤，自由落体保护要的是快速响应和硬件中断。同一个驱动，面对不同场景需要调整的参数完全不同。这篇文章会用实际可跑的代码，把 DA217 的驱动拆到寄存器级，讲清楚每一处配置对应产品的哪个行为，以及出问题时从哪查起。

2. DA217 G-sensor 的 I2C 通信与寄存器配置

2.1 设备地址与 I2C 探测

DA217 的 7 位 I2C 地址由 SAO 引脚的电平决定。SAO 接地时地址为 0x18，接高电平时为 0x19。极少数板子会把 SDO 和 SAO 混为一谈，实际 DA217 的地址引脚标号是 SAO，数据手册里的地址表也是围绕这个引脚展开。拿到一款陌生板子，先用 i2cdetect 扫描是最稳妥的做法。

# 安装 i2c-tools（Debian/Ubuntu 系） sudo apt-get install i2c-tools # 查看当前 I2C 总线 ls /dev/i2c-* # 扫描总线 1 上的设备，0x18 附近出现编号即说明 DA217 挂在总线上 sudo i2cdetect -y 1

扫描结果里若出现18或19，硬件连接基本没问题。若出现UU，说明该地址已被内核驱动占用，需要先卸载现有驱动模块再扫描。扫描不到时优先排查 SAO 引脚的上拉电阻和 I2C 总线上拉是否接对，再用示波器确认 SCL 上有没有时钟信号。DA217 的 I2C 时钟最高支持 400kHz，主控端配置为 100kHz 或 400kHz 均可，传感器本身不挑速率。

2.2 芯片 ID 校验与软复位

探测到地址后，第一步永远是读 WHO_AM_I。DA217 的 WHO_AM_I 寄存器地址是 0x00，复位值固定为 0x13。这里有一个值得注意的差异：不少国产加速度传感器的 WHO_AM_I 是 0x11 或 0x33，如果代码里写死为其他芯片的值，就会出现“读到了 ID 但驱动 probe 失败”的情况。正确做法是把 ID 检查做成一个表，允许内核参数覆盖。

// da217_core.c —— 芯片 ID 校验 #define DA217_WHO_AM_I 0x00 #define DA217_WHO_AM_I_VAL 0x13 static int da217_check_device(struct da217_chip *chip) { int ret; u8 val; ret = i2c_smbus_read_byte_data(chip->client, DA217_WHO_AM_I); if (ret < 0) { dev_err(&chip->client->dev, "failed to read WHO_AM_I\n"); return ret; } val = (u8)ret; if (val != DA217_WHO_AM_I_VAL) { dev_warn(&chip->client->dev, "unexpected WHO_AM_I: 0x%02x\n", val); return -ENODEV; } return 0; }

这段代码的逻辑不复杂：i2c_smbus_read_byte_data发出一个读字节事务，第一个参数是 client 结构体，第二个参数是寄存器地址。返回值为负数表示总线错误，非负数则是读到的寄存器值。如果值不等于 0x13，直接返回-ENODEV，驱动 probe 会失败并释放占用的资源。这里有个细节：某些批次的 DA217 在第 0 页与第 1 页之间切换后，WHO_AM_I 读到的仍是同一个值，但如果你用的是一颗兼容型号（如 DA217 与 DA228 共用驱动），ID 校验就会挡掉一部分兼容芯片，此时建议把校验函数做成弱符号，允许板级文件覆盖。

软复位安排在 ID 校验之后。DA217 的软复位是通过往锁存寄存器写入特定序列来实现的，具体要参考数据手册的 Reset 章节。常见的做法是写 0x00 到 0x4A 锁存寄存器，然后延时 10ms 等待内部上电序列完成。注意软复位后所有寄存器都会恢复到默认值，所以复位必须放在初始化流程的最前面，之后再逐项配置量程和 ODR。

2.3 量程、ODR 和滤波器的寄存器组合

DA217 的量程和 ODR 是驱动里最需要仔细权衡的一组参数。量程有 ±2g、±4g、±8g、±16g 四挡，ODR 支持从 1Hz 到 256Hz 的挡位，还包括一个低功耗模式下的输出速率下拉选项。量程选的越大，相同物理加速度下 LSB 对应的重力值就越大，分辨率越差。产品若要做角度检测，选 ±2g；做碰撞检测或跌落保护，选 ±8g 更合理。

下面是配置量程和 ODR 的典型代码，先关掉传感器再修改配置，避免配置过程中产生噪声数据：

// da217_config.c —— 量程与 ODR 配置 #define DA217_CTRL0 0x10 #define DA217_CTRL1 0x11 #define DA217_CTRL2 0x12 #define DA217_CTRL2_EN_BIT BIT(7) /* 传感器使能 */ #define DA217_CTRL1_ODR_125 (0x02 << 4) #define DA217_CTRL0_RANGE_8G (0x02 << 6) static int da217_set_range_odr(struct da217_chip *chip, u8 range, u8 odr) { struct i2c_client *client = chip->client; int ret; u8 ctrl0, ctrl1; /* 1. 先失能传感器，避免配置过程中产生脏数据 */ ret = i2c_smbus_write_byte_data(client, DA217_CTRL2, 0x00); if (ret < 0) return ret; /* 2. 配置量程到 CTRL0 高两位 */ ctrl0 = i2c_smbus_read_byte_data(client, DA217_CTRL0); ctrl0 &= ~(0x03 << 6); ctrl0 |= (range & 0x03) << 6; ret = i2c_smbus_write_byte_data(client, DA217_CTRL0, ctrl0); if (ret < 0) return ret; /* 3. 配置 ODR 到 CTRL1 的 bit7:4 */ ctrl1 = i2c_smbus_read_byte_data(client, DA217_CTRL1); ctrl1 &= ~(0x0F << 4); ctrl1 |= (odr & 0x0F) << 4; ret = i2c_smbus_write_byte_data(client, DA217_CTRL1, ctrl1); if (ret < 0) return ret; /* 4. 重新使能传感器，开始输出数据 */ ret = i2c_smbus_write_byte_data(client, DA217_CTRL2, DA217_CTRL2_EN_BIT); if (ret < 0) return ret; return 0; }

参数说明：range取值 0 到 3，分别对应 ±2g、±4g、±8g、±16g；odr取 0 到 15，实际映射关系要按数据手册里的表对照，不同批次芯片的部分 ODR 挡位可能为保留值。代码里的i2c_smbus_read_byte_data先读回原有值，再用掩码清除对应位域，最后写入新值，这属于标准的“读-改-写”流程，防止覆盖掉同一寄存器里的其他配置位。CTRL2 的 bit7 是总开关，驱动初始化完成后必须置 1，负责计步或屏幕旋转的应用线程才能从数据寄存器拿到非零输出。

2.4 数据寄存器与三轴方向校正

DA217 的输出数据寄存器按 X、Y、Z 顺序排列，每组轴包含低字节和高字节。读数据寄存器时有个常见的坑：如果只读单一字节，某些 I2C 控制器会自动递增寄存器地址，但只要一次 I2C 事务里读的字节数不是 6 的整数倍，下一条数据就可能出现高低字节错位。所以读取数据时推荐一次读 6 个字节，然后拼成三个 16 位有符号数。

// da217_read.c —— 一次读取 6 字节，解析三轴数据 #define DA217_OUT_X_L 0x08 static int da217_read_accel_xyz(struct da217_chip *chip, s16 *x, s16 *y, s16 *z) { u8 buf[6]; int ret; ret = i2c_smbus_read_i2c_block_data(chip->client, DA217_OUT_X_L, sizeof(buf), buf); if (ret < 0) return ret; *x = (s16)((buf[1] << 8) | buf[0]); *y = (s16)((buf[3] << 8) | buf[2]); *z = (s16)((buf[5] << 8) | buf[4]); return 0; }

i2c_smbus_read_i2c_block_data会在一次 I2C 事务中完成“设置寄存器地址 + 连续读取 6 字节”，避免多次事务间的数据抖动。拼数时用(s16)强转是因为 DA217 的输出是二进制补码，符号位在第 15 位，直接赋给s16类型变量即可保留正负号。方向校正在拿到原始值之后做，常见做法是定义一组符号位和轴交换宏，根据板子安装方向调整。驱动里不要硬编码方向，最好在设备树里用mount-matrix属性描述传感器相对机壳的安装姿态，用户空间程序读到的是修正后的坐标轴，上层逻辑不用改。

3. DA217 校准流程与偏差补偿

3.1 零偏和标度因子的来源

加速度传感器出厂时会有零偏（offset）和标度因子（scale）误差。零偏是指传感器静止时输出不为 0g，而是有一个固定偏差；标度因子是指芯片输出的 LSB/g 值与理想值的偏差，通常在 ±1% 到 ±3% 之间。DA217 内部有出厂校准值，存储在 OTP 里，但产品组装时 PCB 焊接应力、外壳装配应力会引入额外的零偏，所以量产流程里几乎都会加一道静态校准。

校准的原理很简单：让设备分别以六个姿态静止（X 向上、X 向下、Y 向上、Y 向下、Z 向上、Z 向下），每组姿态采集 N 个样本取平均，然后用平均值反推零偏和标度因子。实际做产品时不会六面全做，至少要做 Z 轴向上和 Z 轴向下两组，因为 Z 轴是重力方向，误差对屏幕旋转和倾斜检测的影响最大。

3.2 用户态校准脚本的实现

驱动层面只需要提供校准数据的存取接口，真正的校准计算放在用户态会灵活很多。以下是一段 Python 校准脚本的核心逻辑：

# da217_calibrate.py —— 六面静态校准脚本 import smbus2 import time import statistics DA217_ADDR = 0x18 OUT_X_L = 0x08 def read_accel(bus): data = bus.read_i2c_block_data(DA217_ADDR, OUT_X_L, 6) x = (data[1] << 8) | data[0] y = (data[3] << 8) | data[2] z = (data[5] << 8) | data[4] if x >= 32768: x -= 65536 if y >= 32768: y -= 65536 if z >= 32768: z -= 65536 return x, y, z def collect_samples(bus, count=100): xs, ys, zs = [], [], [] for _ in range(count): x, y, z = read_accel(bus) xs.append(x); ys.append(y); zs.append(z) # 延时 10ms，等待数据寄存器更新 time.sleep(0.01) return statistics.mean(xs), statistics.mean(ys), statistics.mean(zs) # 使用示例：采集 Z 轴向上时的数据 bus = smbus2.SMBus(1) avg_x, avg_y, avg_z = collect_samples(bus) print(f"Z-up avg: x={avg_x:.1f}, y={avg_y:.1f}, z={avg_z:.1f}")

这段脚本里smbus2是用户态访问 I2C 的 Python 库，read_i2c_block_data对应内核里的 block read 操作。采集样本时每采一次间隔 10ms，这个延时比 DA217 的最高 ODR 周期长，能确保两次采样之间数据寄存器至少更新过一遍，避免重复读同一组数据导致平均值无意义。计算平均值后用六面数据解方程组，得到 offset 值和 scale 值，写入设备树或一个/etc/da217_calib.conf文件，驱动每次 probe 时读取并应用。

3.3 温漂补偿的策略

DA217 的零偏会随温度变化，典型温漂系数在 ±0.5mg/°C 量级。消费类产品在室内使用，温漂影响不明显，但车载或户外设备在 -20°C 到 60°C 范围内工作，温漂误差就会超过角度检测的精度预算。常见的补偿方案是建立一张温漂查找表，在 -20°C、0°C、25°C、50°C 四个温度点做标定，记录每个温度点的 Z 轴零偏，运行时用线性插值算出当前温度下的补偿值。

驱动代码里需要增加一个读温度的函数。DA217 内部没有温度传感器，但有几种替代做法：一是读取主控 SoC 内部温度，二是挂一个外部温度芯片，三是用 NTC 分压加 ADC 采集。第三种成本最低，但需要板级配合。温漂补偿表不要放在驱动源码里，最好通过 sysfs 节点动态更新，这样产线标定时不用重新编译内核。

4. DA217 运动检测中断与低功耗模式下的唤醒逻辑

4.1 运动/静止中断的配置方式

DA217 的运动检测是基于阈值比较的：当任意轴的加速度变化量超过设定的阈值，并且持续超过设定的时间，就触发中断。这个功能在低功耗应用里非常关键，因为系统平时可以深度睡眠，只有传感器检测到运动时才唤醒主控。寄存器配置涉及阈值寄存器、持续时间寄存器和使能位三部分。

// da217_interrupt.c —— 运动检测中断配置 #define DA217_INT_CFG 0x20 #define DA217_INT_STATUS 0x21 #define DA217_INT_THRESH 0x22 #define DA217_INT_DUR 0x23 static int da217_setup_motion_detect(struct da217_chip *chip, u8 threshold, u8 duration) { struct i2c_client *client = chip->client; int ret; /* 阈值写入，单位通常为 mg */ ret = i2c_smbus_write_byte_data(client, DA217_INT_THRESH, threshold); if (ret < 0) return ret; /* 持续时间写入，单位通常为 10ms */ ret = i2c_smbus_write_byte_data(client, DA217_INT_DUR, duration); if (ret < 0) return ret; /* 使能运动中断，并配置为锁存模式 */ ret = i2c_smbus_write_byte_data(client, DA217_INT_CFG, 0x15); if (ret < 0) return ret; return 0; }

中断配置里最容易出错的是锁存模式与脉冲模式的差异。锁存模式下，中断标志会一直保持到主控读取中断状态寄存器才清除；脉冲模式则是中断引脚输出一个固定宽度的低电平后自动释放，适合接到主控的 GPIO 唤醒引脚。如果主控用的是边沿触发的外部中断，锁存模式更安全，因为不会漏事件；如果用的是电平触发，脉冲模式可以避免中断处理函数反复进入。DA217_INT_CFG写入 0x15 的含义是：使能运动中断、选择锁存模式、中断输出到 INT1 引脚，具体位定义要对数据手册确认。

4.2 中断与数据就绪引脚的分工

DA217 通常有两个中断引脚 INT1 和 INT2，可以独立映射不同中断源。数据就绪（DRDY）和运动检测分别接到两个引脚，是低功耗设计里推荐的做法。DRDY 接主控的一个 GPIO，运动检测接另一个带唤醒功能的 GPIO，二者互不干扰。这样做的好处是：系统正常工作时，主控通过 DRDY 中断触发读取数据；系统休眠时，DRDY 中断被屏蔽，只有运动检测中断能唤醒 CPU。驱动代码里可以用devm_request_threaded_irq注册两个独立的中断处理函数。

// da217_irq.c —— 双中断注册示例 static irqreturn_t da217_drdy_irq_handler(int irq, void *data) { struct da217_chip *chip = data; s16 x, y, z; da217_read_accel_xyz(chip, &x, &y, &z); input_report_abs(chip->idev, ABS_X, x); input_report_abs(chip->idev, ABS_Y, y); input_report_abs(chip->idev, ABS_Z, z); input_sync(chip->idev); return IRQ_HANDLED; } static irqreturn_t da217_motion_irq_handler(int irq, void *data) { struct da217_chip *chip = data; /* 读取中断状态寄存器，清除锁存标志 */ i2c_smbus_read_byte_data(chip->client, DA217_INT_STATUS); pm_stay_awake(chip->dev); schedule_work(&chip->motion_work); return IRQ_HANDLED; }

DRDY 中断处理函数里直接读取数据并上报给 input 子系统，数据处理链路短，适合高频读取。运动中断处理函数里不能做耗时操作，只做清标志和调度工作队列，因为中断上下文里调用 I2C 传输本身就是不被推荐的——虽然i2c_smbus_*接口可以跑，但在持锁和调度延迟上的表现很差，长时间占用 I2C 总线会影响其他设备通信。用pm_stay_awake防止处理工作队列时系统再次休眠，这个函数配对pm_relax使用，否则系统会一直处于唤醒状态，功耗问题就来了。

4.3 低功耗模式下数据读取的时序约束

DA217 在低功耗模式下的 ODR 降到 1Hz 到 25Hz，数据寄存器的更新频率也随之下降。这里有一个隐藏的时序问题：低 ODR 下，两个样本之间的间隔可能长达 1 秒，如果主机在数据更新前读了数据寄存器，读到的是上一帧数据，表现上就是数据卡顿或重复。判断数据是否更新，标准做法是读数据就绪标志位，但 DA217 的数据就绪标志在某些低功耗模式下不会置位，只能靠 DRDY 引脚中断或定时器唤醒来做同步。

实用的兜底方案是：每次读取前先记录读到的值，延时一个 ODR 周期后再读一次，两次完全一致时认为数据已稳定。这个方案不优雅但可靠，适合 ODR 低于 25Hz 的场景。对于要求严格同步的应用，建议直接用 DRDY 中断驱动数据读取，不要依赖轮询。

5. Linux 下 DA217 驱动的设备树适配与 iio 框架接入

5.1 设备树节点与 GPIO 中断的映射

DA217 在内核里的标准做法是挂到 I2C 总线下，通过设备树描述寄存器地址、中断引脚和 mount-matrix。设备树节点不仅要配 I2C 地址，还要把两个 GPIO 中断映射正确，否则驱动 probe 成功但中断一直不触发，问题排查会非常困难。

// da217.dtsi —— 设备树节点示例 &i2c1 { status = "okay"; clock-frequency = <100000>; da217: accelerometer@18 { compatible = "da217,accel"; reg = <0x18>; interrupt-parent = <&gpio2>; interrupts = <14 IRQ_TYPE_EDGE_FALLING>, <15 IRQ_TYPE_EDGE_FALLING>; interrupt-names = "DRDY", "MOTION"; mount-matrix = "1", "0", "0", "0", "1", "0", "0", "0", "1"; vdd-supply = <&reg_3v3>; }; };

设备树里interrupts两个条目分别对应两个中断号，interrupt-names里的字符串要和驱动程序里platform_get_irq_byname的参数一致。mount-matrix是一个 3×3 旋转矩阵，描述传感器坐标轴到机壳坐标系的变换关系。默认单位矩阵代表传感器直接平放在板上，Z 轴向上；若传感器旋转了 90° 安装，矩阵就需要相应调整。内核的 iio 框架在读取mount-matrix属性后会自动应用旋转，用户空间通过 iio 接口读到的已经是修正后的坐标轴数据。

5.2 注册为 iio 设备并导出 sysfs 接口

DA217 推荐接入内核的 iio 子系统，而不是直接用 input 子系统上报事件。理由很简单：iio 提供了统一的in_accel_x_raw系列属性，用户空间可以用cat直接读取原始值，配合in_accel_scale计算物理量，调试和开发效率高很多。input 子系统适合已经做好方向映射和阈值过滤的成熟产品，开发阶段用 iio 更合适。

// da217_iio.c —— iio 设备注册与 attribute static const struct iio_chan_spec da217_channels[] = { { .type = IIO_ACCEL, .modified = 1, .channel2 = IIO_MOD_X, .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), }, { .type = IIO_ACCEL, .modified = 1, .channel2 = IIO_MOD_Y, .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), }, { .type = IIO_ACCEL, .modified = 1, .channel2 = IIO_MOD_Z, .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), }, }; static int da217_read_raw(struct iio_dev *indio_dev, struct iio_chan_spec const *chan, int *val, int *val2, long mask) { struct da217_chip *chip = iio_priv(indio_dev); s16 x, y, z; int ret; ret = da217_read_accel_xyz(chip, &x, &y, &z); if (ret < 0) return ret; switch (chan->channel2) { case IIO_MOD_X: *val = x; return IIO_VAL_INT; case IIO_MOD_Y: *val = y; return IIO_VAL_INT; case IIO_MOD_Z: *val = z; return IIO_VAL_INT; } return -EINVAL; }

iio_chan_spec数组定义了三个通道，每个通道对应一个轴。info_mask_separate声明该通道支持读取原始值，info_mask_shared_by_type声明该设备的 scale 属性。da217_read_raw是 iio 框架的回调函数，应用层cat /sys/bus/iio/devices/iio:device0/in_accel_x_raw时内核会调用这个函数。scale 值通过另一个回调函数返回，通常是一个以 mg/LSB 为单位的小数，用户空间用原始值乘以 scale 就得到真正的加速度值。

5.3 验证驱动工作的几个关键节点

驱动注册完成后，验证工作分四步走。第一，看内核日志里有没有da217: probe success字样，确认 I2C 通信和 ID 校验都通过了。第二，检查 iio 设备节点是否存在，读一次原始数据确认传感器有输出。第三，短接传感器的 INT 引脚到地，看中断号和中断处理函数是否触发。第四，用iio_info工具或evtest观察数据的动态变化。

# 查看 iio 设备列表 ls /sys/bus/iio/devices/ # 读取 X 轴原始值，静止时应在 0 附近 cat /sys/bus/iio/devices/iio:device0/in_accel_x_raw # 查看量程对应的 scale 值 cat /sys/bus/iio/devices/iio:device0/in_accel_scale # 监控内核日志中的中断信息 sudo dmesg | grep da217

如果读到的原始值始终为 0，优先检查 CTRL2 的使能位是否被意外清零；如果三个轴的值都偏大，优先检查量程配置和 scale 的对应关系；如果只有某一个轴的值异常，大概率是 mount-matrix 配错或焊接虚焊。这四步走完，驱动基本可以进入应用层联调阶段。

5.4 在用户态用 sysfs 快速读出有意义的数据

驱动接入 iio 后，用户态程序只需要读三个文件就能实时获取三轴加速度原始值，乘以 scale 后换算成 g。以下是一段 C 语言的读取示例：

// da217_read_sysfs.c —— 用户态读取 iio 接口 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #define IIO_PATH "/sys/bus/iio/devices/iio:device0" #define SYSFS_BUF_SIZE 32 static int read_sysfs_val(const char *node, int *val) { char path[128]; char buf[SYSFS_BUF_SIZE]; int fd, ret; snprintf(path, sizeof(path), "%s/%s", IIO_PATH, node); fd = open(path, O_RDONLY); if (fd < 0) return -1; ret = read(fd, buf, sizeof(buf) - 1); if (ret < 0) { close(fd); return -1; } buf[ret] = '\0'; *val = atoi(buf); close(fd); return 0; } int main(void) { int x, y, z, scale; while (1) { if (read_sysfs_val("in_accel_x_raw", &x) || read_sysfs_val("in_accel_y_raw", &y) || read_sysfs_val("in_accel_z_raw", &z) || read_sysfs_val("in_accel_scale", &scale)) break; /* scale 以 μg/LSB 表示，除以 1000 得到 mg/LSB */ printf("accel: x=%7.2f mg, y=%7.2f mg, z=%7.2f mg\r", (double)x * scale / 1000.0, (double)y * scale / 1000.0, (double)z * scale / 1000.0); fflush(stdout); usleep(100000); } return 0; }

这段代码里scale参数的单位是 μg/LSB，比如量程为 ±2g 时，16 位输出对应 4g 范围，每个 LSB 约 122μg，即 0.122 mg。所有数值都带正负号，静止时 Z 轴读数约等于 1000 mg，X 轴和 Y 轴接近 0，这就是判断驱动工作正常的最终依据。

本文还有配套的精品资源，点击获取