简介：这是一份针对 ADT75 数字温度传感器开发的驱动程序源码包，面向嵌入式开发者和 Linux 驱动学习者，用于解决传感器与主机之间的通信以及温度数据准确读取问题。ADT75 由 Analog Devices 公司出品，属于高精度数字温度传感器，常见于工业监控、环境采集、设备散热控制等场景。该资源使用 C 语言编写，以单文件源码形式呈现驱动逻辑，便于快速研读和复用。压缩包仅含 1 个 .c 文件，大小约 3KB，内容精简，覆盖传感器初始化、I²C 读写、温度数据转换及错误处理等关键环节。通过研读这份代码，可以掌握 ADT75 的寄存器配置方法、理解 I²C 通信时序、学习原始二进制数据到实际温度值的换算技巧，同时了解在内核或用户空间集成传感器驱动的整体思路。尤其适合正在学习嵌入式驱动开发、需要参考实际硬件驱动代码的开发者，可以直接在此基础上做二次开发，也可作为编写其他 I²C 接口传感器驱动的模板。目前已有 87 人学习下载，对数字温度传感器驱动编写有直接参考价值。
1. 从 adt75.rar 这个包说起：拿到一个版本号不明的 RAR 该先做什么
拿到一个叫 adt75.rar 的包时，真正有用的信息其实只有三样：产品缩写 adt、构建序号 75、压缩格式 rar。包是完整的还是下载到一半的、里面是源码还是编译产物、解压出来会不会把正在用的旧文件覆盖掉，这些问题文件名一个都不会回答。下面按处理发布包的实际顺序展开：先识别真实格式，再用不落盘的方式看包内清单，然后测试 CRC，确认无误后才动手解压，最后补上 SHA256 校验和版本目录隔离。命令以 unrar 与 7-Zip 为主，覆盖 RAR4/RAR5 两种常见格式。适合运维、构建工程师，以及所有经常接收第三方 RAR 包、不想被一个坏包拖上半天的开发人员。
2. 解压前先识货：用 file 与归档工具识别 adt75.rar 的真实格式
2.1 扩展名可以撒谎，file 命令看的是文件头里的魔数
下载工具补扩展名的情况很常见：URL 末尾挂着 .rar，落盘的文件却可能是 nginx 的 403 页面、一个被截断的 zip，甚至是纯文本的错误提示。RAR 格式在文件头部有固定的魔术字节，RAR4 的头部是 52 61 72 21 1A 07 00，对应可见字符就是 Rar!；RAR5 是 52 61 72 21 1A 07 01 00。file 命令读取的就是这段二进制头部，与扩展名没有任何关系，这一步能直接排除掉一大批"假 rar"。
# 先看体积，再识别真实格式；file 读文件头魔数，不看扩展名 ls -lh adt75.rar file adt75.rar # 正常输出：adt75.rar: RAR archive data, v5, original size: 284319744 # 异常输出：adt75.rar: HTML document, ASCII textfile 输出里如果出现 HTML document、gzip compressed data 这类字样，直接去重新下载，不要在这份文件上继续浪费时间。输出里的 original size 表示解压后的总大小，可以拿来估算磁盘占用，如果这个值和发布说明里写的体积差了几个数量级，包大概率是坏的。
在脚本里做二次确认时，用 xxd 直接看前 8 个字节更硬核：输出以 5261 7221 开头的才继续往下走，两个字节两个字节地从十六进制转回 ASCII 就是 Rar!，这一招在排查"unrar 报 No archives found 但 file 说这是 RAR"的版本差异问题上尤其有用，因为 file 和 unrar 对旧版 RAR 的识别规则并不完全一致。
2.2 不落盘先看清单：unrar l 与 7z l 输出里的关键字段
unrar l 和 7z l 都只读取归档文件，把每条文件记录打印出来，不向磁盘写入任何东西。对 adt75 这种内部命名的包，这一步能回答三个问题：包内第一层有什么、总大小多少、有没有加密。即使是一个几个 GB 的大包，列清单也只需要读取归档末尾的目录区，耗时几乎可以忽略。
# 列出 adt75.rar 包内清单，不写任何文件 unrar l adt75.rar # 7-Zip 的清单同样只读，输出字段略有差异 7z l adt75.rar两份输出对照着看，重点字段整理如下：
| 字段 | unrar l | 7z l | 看什么 |
|---|---|---|---|
| 文件名 | Name | Name | 顶层目录结构，区分源码包与产物包 |
| 原始大小 | Size | Size | 估算解压后的磁盘占用 |
| 压缩体积 | Packed Size | Packed Size | 与 Size 对比判断压缩率是否异常 |
| 校验值 | CRC | CRC | 解压后逐文件核对用 |
| 压缩方式 | Method | Method | m0 表示无压缩存储，m3/m5 表示有压缩 |
| 加密标记 | Attr 列末尾出现* | 文件行属性列出现+ | 有标记说明该文件要求密码 |
Method 列如果整包都是 m0，说明打包的人只是用 rar 做了容器，内部文件全部无压缩存储，通常是因为内容本身已经是压缩过的二进制；如果出现 m5，说明用了默认压缩级别，代码和文本类内容的压缩收益明显。7z l 的加密标记比 unrar 更直观，属性列的+一眼就能扫出来，看到任何加密标记，就得先准备密码再走第 3 章的流程。
2.3 先判断 adt75 是源码包还是构建产物，再决定解压方式
看清单第一层就能区分两类包，这一步决定了后面第 3 章的参数怎么选。顶层出现 src/、CMakeLists.txt、build.gradle 这类，是源码包，解压必须保留目录结构、文件权限和符号链接，丢了任何一个 build 流程都走不通；顶层出现 bin/、lib/、.jar、.so、version.txt，是编译产物包，更关心顶层目录是否干净，能否直接并入某个运行时目录。
判断对了类别，后面的存放位置才选得对。源码包通常解压到独立工作区，产物包必须按版本号隔离存放，这个放到第 4 章细说。还有一种常见情况值得警惕：清单里出现 .git/ 或 .svn/，说明打包的人忘了清理版本控制目录，解压后体积会比预期大不少，后续做全目录 diff 时也会被这些内部文件干扰，建议在解压完成后直接删除。
3. 安全解压 adt75.rar：先测 CRC 再落盘，参数这样配
3.1 解压前必跑的 unrar t：测试模式到底在做什么
unrar t 会把包内每个文件解压到内存缓冲区，重新计算 CRC32 并与归档里记录的 CRC 值比对，全部一致才在结尾输出 Everything is Ok。整个过程不写磁盘，速度通常比解压快，也不需要额外的临时空间。7z t 做的事情等价，对 RAR5 的兼容性更好，我在混合环境里默认用 7z t 做测试。
# 测试 adt75.rar 完整性，t 模式不产生任何新文件 unrar t adt75.rar # 7-Zip 等价命令，RAR5 包优先用它 7z t adt75.rar测试过程中的每一行 Testing adt75/xxx OK 对应一个文件的 CRC 比对结果，如果中途出现 CRC failed in file，后面就没必要继续，问题文件已经定位。注意 t 模式验证的只是"包内自洽"：解压结果与归档记录一致，它验证不了这个包是不是发布方最初签发的那个文件，内容可信问题要留给第 4 章用 SHA256 解决。
提示：t 报 CRC failed 时不要用 unrar x 硬解。截断的包硬解会把损坏文件提前写进磁盘，之后再排查故障就多了一个"文件本来就是坏的"干扰因素。
3.2 unrar x 与 unrar e 的差别，以及覆盖策略参数
unrar 有两个容易混淆的解压命令：x 保留归档里的目录结构，e 把全部文件平铺到单个目录。对于带顶层目录的发布包，e 会把所有文件混在一起，同名文件互相覆盖，相当危险；x 是默认选择，只有明确知道自己在拍平时才用 e。
# 推荐：保留 adt75.rar 内的目录结构 unrar x adt75.rar # 平铺到指定目录，同名文件会被覆盖，慎用 unrar e adt75.rar adt75_flat/ # 覆盖策略三件套 unrar x -o+ adt75.rar # 已存在文件直接覆盖 unrar x -o- adt75.rar # 已存在文件跳过 unrar x -o adt75.rar # 逐个询问，交互模式下用覆盖策略参数用在重复解压场景，比如同一个 adt75.rar 解了两遍，或目录里已有旧版本的部分文件。不带参数时 unrar 在覆盖前会逐文件询问，脚本里跑会卡住，所以脚本场景一定显式写 -o+ 或 -o-。相关参数一张表收完：
| 参数 | 含义 | 典型场景 |
|---|---|---|
-o+ | 覆盖已存在文件 | 重新发布同一个版本 |
-o- | 跳过已存在文件 | 增量补齐缺失文件 |
-or | 已存在文件自动改名保留 | 想保留现场做对比 |
-p- | 转入交互式密码输入 | 所有需要密码的包 |
密码参数单独说：能交互输入就不要写在命令行。unrar x -p'build2024' adt75.rar 的密码会同时出现在 shell 历史、进程列表以及终端日志里，多人共用的构建机上等于明文泄漏；用 -p- 让工具提示输入，密码只进工具内部。
# 推荐：-p- 表示转入交互提示，密码不进 shell 历史 unrar x -p- adt75.rar3.3 7-Zip 命令行解压的等价操作与 -o 参数坑
7-Zip 命令行的对应写法是 7z x，参数风格和 unrar 完全不同。最容易踩的坑是 -o：后面必须紧跟目录，不能有空格。
# 解压到 adt75 目录，-y 表示所有询问都回答是 7z x adt75.rar -oadt75 -y-oadt75 如果写成 -o adt75，7z 会把 adt75 当成另一个参数解析，直接报错。输出目录不存在时 7z 会自动创建，不需要预先 mkdir。7z x 默认保留包内目录结构，平铺操作对应的是 7z e，和 unrar 的 x/e 对应关系一致。
Linux 下解压从 Windows 打出来的 RAR 包，中文文件名乱码是高频问题，根源是压缩端用了 GBK 存文件名，解压端却按 UTF-8 解析。处理顺序是这样：先看 7z l 输出里的文件名是否正常，正常就直接解；乱码的话，回到 Windows 用 7-Zip 解压后重新打成 UTF-8 的 zip 往往最省事，在 Linux 上则可以用 convmv 做转码：
# 把解压目录里的文件名从 GBK 转成 UTF-8，--notest 表示真执行 convmv -f GBK -t UTF-8 --notest -r adt75/convmv 只改文件名，不改文件内容，先跑一遍不带 --notest 的预览，确认要改的范围符合预期再真执行。注意包内如果是符号链接，转码同样作用在链接名上，别把链接指向转坏了。
4. 解压 adt75.rar 之后的事：校验、版本隔离与归档脚本化
4.1 用 SHA256 把"能解压"升级成"内容可信"
unrar t 通过只说明包本身没坏，但没坏不等于没问题。内网发布包被替换、被改名的例子并不少见，随包附 SHA256 校验文件是通行做法。SHA256 是内容级摘要，文件名相同、内容差一个字节，摘要就完全不同，因此它比 CRC32 更适合做发布物的身份确认。
# 计算当前文件的 SHA256 摘要 sha256sum adt75.rar # 输出格式：<64 位十六进制摘要> 文件名 # 用发布方提供的校验文件自动对比 sha256sum -c adt75.rar.sha256 # 输出 adt75.rar: OK 表示一致，FAILED 表示不一致sha256sum -c 会读取校验文件，逐行重新计算并对比。release notes 里直接贴摘要的场景，手工拼一行再喂给 -c 也行：echo '8c5f9a... adt75.rar' | sha256sum -c -，注意中间两个空格是格式要求，最后的 - 表示从标准输入读取。校验不一致时不要解压，先找发布方确认，避免一个被替换的包混进后续流程。
4.2 按版本号隔离目录，防止覆盖旧版本残留
adt75 这种带构建序号的包，最忌讳直接在工作目录里解压。假设目录里正在跑 adt74，直接原地解压 adt75，包内的 lib/、bin/、config/ 会一层层合并进现有目录：新版本里没有而旧版本里有的文件会残留，新版本已删除的文件不会消失，这种残留目录排查起来非常痛苦。
# 解压前先建好版本目录，unrar x 会把包内路径整体放到该目录下 mkdir -p releases/adt75 unrar x adt75.rar releases/adt75/ # 7-Zip 等价写法，-o 后直接跟目录 7z x adt75.rar -oreleases/adt75 -y之后切换版本只需要改入口，不用反复解压覆盖：脚本或 systemd 单元引用 /opt/app/current 时，把 current 做成指向 releases/adt75 的符号链接，升级就是换个链接的事。这一节顺带处理高频报错，表格里是解压时最常见的四种：
| 报错信息 | 原因 | 处理 |
|---|---|---|
| No archives found | 文件不是 RAR 或已截断 | 先用 file 确认格式，再重新下载 |
| CRC failed in ... | 包内单个文件损坏 | 重新下载对应分卷，不要硬解使用 |
| Unexpected end of archive | 多卷包缺了最后一个分卷 | 补齐 part2 之后的文件再解 |
| Extract with wrong password? | 密码错误或包头加密 | 确认密码来源，必要时要求发布方重发 |
前两类报错在下载来源不可靠时尤其常见，处理原则一样：任何校验失败都先重下，而不是带病解压。
4.3 一个验证加解压的脚本模板
真实环境里处理的不止一个 adt75.rar，而是连续几个版本的发布包，手工敲命令迟早会漏一步。把测试和解压压进一个脚本，参数化存档，比每次都手动敲命令可靠得多：
#!/usr/bin/env bash # 用法：./verify_extract.sh adt75.rar releases/adt75 set -euo pipefail ARCHIVE="$1" TARGET="$2" # 1. 文件存在且非空才继续 [[ -s "$ARCHIVE" ]] || { echo "archive missing or empty" >&2; exit 1; } # 2. 先测试完整性；失败时脚本在此退出 7z t "$ARCHIVE" >/dev/null # 3. 建目录并解压，-o 后紧跟目标路径 mkdir -p "$TARGET" 7z x "$ARCHIVE" -o"$TARGET" -y >/dev/null # 4. 打印解压后的文件数，和包内清单数量比对 find "$TARGET" -type f | wc -l第 1 行的 set -euo pipefail 让任何一步命令失败就立刻退出，避免解压到一半还继续往下走；第 2 步和第 3 步刻意用同一个 7z 工具，不同版本的 unrar 对 RAR5 的解析存在细微差异，测试和实际解压用同一套逻辑能减少这类差异带来的误判；stdout 重定向到 /dev/null 只清理正常输出，错误信息仍会走 stderr 显示出来。最后打印的文件数与 2.2 节清单里的行数对不上，就说明有文件没解出来，先别急着用。
5. 把 adt75.rar 变成可审计的版本件：固化清单并干净地再打包
5.1 解压后立即生成相对路径清单
解压完成的第一件事，是把这一版的内容固化下来，否则过一会儿你就说不清 adt75 里到底有什么。常规做法是生成相对路径加 SHA256 的清单文件：
# 对解压目录逐个文件求摘要，去掉路径前缀后排序 find releases/adt75 -type f -exec sha256sum {} \; | \ sed 's# releases/adt75/# #' | sort > adt75.manifestsed 把路径前缀抹掉后，两个版本的清单可以直接 diff：新增文件以 > 开头，删除的以 < 开头，相同行自动略过。对照 2.2 节的包内清单，能快速分清哪些改动是代码真实变更，哪些只是打包脚本造成的目录漂移。
5.2 用 rar a -ep1 重新打包出干净的副本
原始 adt75.rar 里可能带着 .git/、临时文件或错误的文件权限，直接分发不是好选择。整理解压目录后重新打包，才适合做长期保留的制品：
cd releases && rar a -m5 -ep1 adt75-clean.rar adt75/ unrar t adt75-clean.rara 是添加文件到归档；-m5 表示最高压缩级别，压源码值得，压已经压缩过的二进制收益不大，构建产物场景改成 -m3 更快；-ep1 表示只保留命令行指定目录这一层，包内条目形如 adt75/xxx，不会把外层 releases/ 也写进去。打完包立刻 unrar t 验证，这条命令收尾成本极低，但能拦住一半"打出来的包自己都解不开"的事故。
5.3 不落盘读取包内单个文件：unrar p 的两个用处
最后一个技巧回落到复查场景：收到 adt75.rar 后想先确认版本，不必走完整解压流程，unrar p 能把包内单个文件打到标准输出：
# 只把 version.txt 的内容打出来，不落盘 unrar p adt75.rar adt75/version.txtp 模式适合两种用法：一是快速确认版本号和包内自带校验文件，二是配合 sha256sum -c - 做只读校验。如果包内带 SHA256SUMS，用 unrar p 导出后直接交给 -c 比对，整个确认过程不需要解压到磁盘。如果包内没有校验文件，就把 5.1 生成的 adt75.manifest 存进发布目录作为下一次到包时的比对基准，adt76.rar 到位后走一遍完整流程生成 adt76.manifest，两条命令 diff 两份清单，版本间差异一眼就能定位。
本文还有配套的精品资源，点击获取
