1. 为什么还要折腾 DS1302 这颗老芯片

前阵子帮朋友调一块工业采集板，主控是 STM32F103，板子上挂了一颗 DS1302 做本地时间戳。朋友的原话是"这芯片都二十多年了，网上例程一抓一大把，应该半小时就能跑通"。结果他折腾了整整两天，时间不是走快就是走慢，偶尔还会在整点跳变时丢一秒。我接手后发现问题根本不在代码逻辑，而在于三个被绝大多数例程忽略的细节：晶振负载电容匹配、写保护寄存器的操作时序、以及突发模式读写时的 CE 拉低时机。

DS1302 这颗芯片确实老，老到很多新手觉得它"过时了"。但现实情况是，在成本敏感、不需要网络对时、又要求掉电走时的场景里，它依然是出货量极大的选择。它便宜、货源稳、SPI 三线接口占用 IO 少，而且不需要像某些 I2C RTC 那样担心总线锁死。问题在于，它的数据手册写得比较"精简"，很多关键时序要靠实测去补。

这篇笔记面向的是已经会用 STM32 标准库或 HAL 库点灯、但第一次接触 DS1302 的开发者，也适合那些"例程能跑但时间不准"想找根因的人。我会从硬件连接讲到寄存器操作，再到时间校准和掉电保护，把每个环节里容易踩的坑都摊开说。代码部分基于 STM32F103 + 标准库风格给出，HAL 库用户把 GPIO 操作替换一下即可，逻辑完全通用。

需要先明确一点：DS1302 不是 SPI 协议，虽然它长得像 SPI。它是自定义的三线同步串行协议，CE、I/O、SCLK 三根线，数据在 SCLK 的上升沿被写入、下降沿被读出。这个"上升沿写、下降沿读"的方向约定，是后面所有时序问题的总根源，记住它比记任何代码都重要。

2. 硬件层：三根线背后的电气陷阱

2.1 晶振与负载电容：时间不准的头号元凶

DS1302 的标准配置是外接一颗 32.768kHz 的圆柱晶振。很多人随手拿一颗晶振焊上去，发现每天快十几秒，第一反应是"芯片坏了"，其实九成是负载电容不匹配。

32.768kHz 晶振的负载电容常见有 6pF 和 12.5pF 两种规格。DS1302 内部已经集成了约 6pF 的等效电容，所以：

• 如果你用的是6pF 负载电容的晶振，理论上不需要外接电容，直接接晶振两端即可。
• 如果你用的是12.5pF 负载电容的晶振，就需要在晶振两端各接一个约 6~10pF 的补偿电容到地。

我实测过一批 12.5pF 晶振不加补偿电容的情况，日误差能到 +8 秒左右，一个月就是四分钟。加上 8pF 补偿后，日误差压到 1 秒以内。这个数字不是理论推导，是拿频率计和标准时钟对比了 72 小时得出的。

注意：补偿电容要用温度系数好的瓷片电容或NP0电容，普通瓷片电容温漂大，夏天和冬天走时差异会很明显。

另外，晶振的走线要尽量短，最好紧贴 DS1302 的 X1、X2 引脚，下方铺地隔离。我见过把晶振放在板子另一头、走线绕了 3 厘米的板子，时间飘得没法看。

2.2 备用电池与涓流充电

DS1302 的 VCC1 接备用电池（通常是 3V 纽扣电池），VCC2 接主电源。芯片内部会自动选择电压较高的那一路供电。这里有个细节：当主电源 VCC2 高于 VCC1 约 0.2V 时，芯片由 VCC2 供电；主电源掉电后自动切到 VCC1。

如果你希望主电源在的时候顺便给电池充电，可以用 DS1302 内部的涓流充电寄存器。但要注意，只有可充电的电池（如可充电纽扣或法拉电容）才能开启涓流充电，普通一次性 CR2032 开启充电会有安全隐患。我一般建议直接用不可充电电池，关掉涓流充电功能，简单可靠。

涓流充电寄存器的地址是 0x90，写保护解除后才能写。典型配置值：

选哪个取决于你的电池充电电流需求。法拉电容一般选 0xA5 或 0xA6，充电电流大一点恢复快。

2.3 上拉电阻与 IO 方向切换

DS1302 的 I/O 引脚是双向单线，读的时候是输入，写的时候是输出。STM32 这边必须用开漏输出模式，并外接一个 4.7k~10k 的上拉电阻到 3.3V。如果你用推挽输出，读数据时 STM32 会强行拉高或拉低这条线，和 DS1302 的输出打架，轻则读错数据，重则长期损坏 IO。

我的做法是：把 I/O 引脚配置为开漏输出，读之前先写 1（释放总线），然后切换成输入模式读取，读完再切回开漏输出。这样最稳妥。有些例程图省事，全程用开漏输出加读 IDR 寄存器，也能跑，但在某些批次的芯片上会出现读电平不稳的情况。

3. 寄存器地图：命令字是怎么拼出来的

3.1 命令字节的位定义

DS1302 的每一次操作，都是先发一个命令字节，再发或收数据。命令字节的 8 位定义如下：

举个例子，要写"秒寄存器"（地址 0x80），命令字节就是1000 0000= 0x80；要读秒寄存器，就是1000 0001= 0x81。要写 RAM 的第一个字节（地址 0xC0），命令是 0xC0，读是 0xC1。

这个位拼接规则一定要自己动手算一遍，不要死记例程里的十六进制值。我见过有人把读写位搞反，结果写进去的数据全乱，查了半天以为是硬件问题。

3.2 时钟寄存器的地址分布

DS1302 的时钟寄存器一共 8 个，地址从 0x80 到 0x8E（偶数地址写，奇数地址读）：

注意，所有时间数据都是 BCD 码格式，不是二进制。比如"23 分"存进去是 0x23，不是 0x17。这个转换必须自己做，忘了转换是新手最常见的错误之一。

3.3 写保护寄存器：不解除就白写

DS1302 上电后，写保护寄存器（0x8E）的 bit7 默认是 1，意味着所有写操作都被禁止。你必须先写 0x00 到 0x8E 解除保护，才能修改时间和配置。

很多例程能跑，是因为它们初始化时先解了保护。但如果你在运行中想改时间，忘了重新解保护，就会发现"写进去没反应"。我的习惯是：每次写时间前都先解保护，写完立刻重新上保护，防止程序跑飞时误改时间。

// 解除写保护 DS1302_WriteByte(0x8E, 0x00); // ... 写时间操作 ... // 重新上保护 DS1302_WriteByte(0x8E, 0x80);

4. 底层时序：上升沿写、下降沿读的实操细节

4.1 单字节写时序

写一个字节的完整流程是：

1. CE 拉低，SCLK 拉低（初始状态）。
2. CE 拉高，启动一次传输。
3. 把命令字节的 bit0 放到 I/O 线上。
4. SCLK 拉高（上升沿，DS1302 采样 I/O）。
5. SCLK 拉低。
6. 重复 3~5，直到 8 位命令发完。
7. 接着发 8 位数据，同样是低位在前，每个 bit 在 SCLK 上升沿被采样。
8. CE 拉低，结束传输。

关键点：数据必须在 SCLK 拉高之前就稳定在 I/O 线上，也就是先设数据、再拉高时钟。如果你先拉高时钟再设数据，DS1302 采到的是上一个 bit 的值，数据整体错位。

void DS1302_WriteByte(uint8_t cmd, uint8_t dat) { uint8_t i; DS1302_CE_LOW(); DS1302_SCLK_LOW(); DS1302_CE_HIGH(); for (i = 0; i < 8; i++) { if (cmd & 0x01) DS1302_IO_HIGH(); else DS1302_IO_LOW(); DS1302_SCLK_HIGH(); DS1302_SCLK_LOW(); cmd >>= 1; } for (i = 0; i < 8; i++) { if (dat & 0x01) DS1302_IO_HIGH(); else DS1302_IO_LOW(); DS1302_SCLK_HIGH(); DS1302_SCLK_LOW(); dat >>= 1; } DS1302_CE_LOW(); }

4.2 单字节读时序

读的时候方向反过来：DS1302 在 SCLK 的下降沿把数据放到 I/O 线上，STM32 在下降沿之后读取。

流程是：

1. CE 拉高，先发 8 位命令（写方向，因为命令总是 STM32 发出的）。
2. 然后把 I/O 切换为输入模式。
3. 每个 bit：SCLK 拉高，再拉低（下降沿，DS1302 输出数据），然后读 I/O 电平。
4. 读完 8 位，CE 拉低。

uint8_t DS1302_ReadByte(uint8_t cmd) { uint8_t i, dat = 0; DS1302_CE_LOW(); DS1302_SCLK_LOW(); DS1302_CE_HIGH(); for (i = 0; i < 8; i++) { if (cmd & 0x01) DS1302_IO_HIGH(); else DS1302_IO_LOW(); DS1302_SCLK_HIGH(); DS1302_SCLK_LOW(); cmd >>= 1; } DS1302_IO_INPUT(); // 切换为输入 for (i = 0; i < 8; i++) { dat >>= 1; DS1302_SCLK_HIGH(); DS1302_SCLK_LOW(); // 下降沿，DS1302 输出数据 if (DS1302_IO_READ()) dat |= 0x80; } DS1302_IO_OUTPUT(); // 切回输出 DS1302_CE_LOW(); return dat; }

注意：读的时候dat >>= 1要在读取之前做，这样第一次读到的 bit 最终落在 bit7，符合"低位在前"的传输顺序。这个移位顺序很容易写反，写反了读出来的时间会变成乱码。

4.3 突发模式：一次读完 7 个时间寄存器

如果你要连续读秒、分、时、日、月、星期、年，用单字节读要发 7 次命令，效率低还容易在跨秒时读到不一致的数据。DS1302 提供了突发模式（Burst Mode），命令字节是 0xBF（读）或 0xBE（写），一次传输就能读写全部 7 个时间寄存器。

突发模式的好处是数据一致性：DS1302 内部会把 7 个寄存器的值锁存后一次性输出，避免你在读秒和读分之间刚好跨秒导致的时间错乱。做数据记录、时间戳这种对一致性要求高的场景，强烈建议用突发模式。

void DS1302_ReadTime(uint8_t *buf) { uint8_t i; DS1302_CE_LOW(); DS1302_SCLK_LOW(); DS1302_CE_HIGH(); // 发突发读命令 0xBF for (i = 0; i < 8; i++) { if (0xBF & 0x01) DS1302_IO_HIGH(); else DS1302_IO_LOW(); DS1302_SCLK_HIGH(); DS1302_SCLK_LOW(); // 注意这里要移位，示例略 } // 连续读 7 字节 // ... DS1302_CE_LOW(); }

5. BCD 转换与时间校准的实战处理

5.1 BCD 与十进制互转

前面说过，DS1302 存的是 BCD 码。BCD 码的特点是"每 4 位表示一个十进制数字"，比如十进制 23 的 BCD 是 0x23。

转换函数很简单，但必须写对：

uint8_t DecToBcd(uint8_t dec) { return ((dec / 10) << 4) | (dec % 10); } uint8_t BcdToDec(uint8_t bcd) { return ((bcd >> 4) * 10) + (bcd & 0x0F); }

我见过有人用dec + 6 * (dec / 10)这种位运算技巧，也能得到正确结果，但可读性差，不推荐。老老实实用除法和取模，编译器会优化，性能没差别。

5.2 小时寄存器的 12/24 小时制

小时寄存器（0x84）的 bit7 是 12/24 小时制选择位。bit7 = 0 表示 24 小时制，bit7 = 1 表示 12 小时制。如果你写时间时不小心把 bit7 置 1，读出来的小时就会变成 12 小时制，下午的时间会显示错误。

我的建议是：统一用 24 小时制，写小时前先确保 bit7 为 0。如果你从某个例程抄来的代码读出来小时总是差 12，八成就是这个位的问题。

// 写小时（24小时制） DS1302_WriteByte(0x84, DecToBcd(hour) & 0x3F); // 清掉 bit7 和 bit6

5.3 上电初始化：只在第一次写时间

一个常见的错误做法是：每次上电都无条件把编译时的固定时间写进 DS1302。这样一旦掉电重启，时间就被重置了，备用电池白装。

正确的做法是：用一个标志位判断 DS1302 是否已经初始化过。可以在 DS1302 的 RAM 里写一个魔数（比如 0x5A），上电时读这个 RAM，如果是 0x5A 就说明已经初始化过，不再写时间；否则写入默认时间并设置魔数。

#define INIT_FLAG_ADDR 0xC0 #define INIT_FLAG_VAL 0x5A void DS1302_Init(void) { DS1302_WriteByte(0x8E, 0x00); // 解保护 if (DS1302_ReadByte(INIT_FLAG_ADDR | 0x01) != INIT_FLAG_VAL) { // 首次上电，写入默认时间 DS1302_WriteByte(0x80, 0x00); // 秒 DS1302_WriteByte(0x82, 0x00); // 分 DS1302_WriteByte(0x84, 0x12); // 时 // ... 其他寄存器 DS1302_WriteByte(INIT_FLAG_ADDR, INIT_FLAG_VAL); } DS1302_WriteByte(0x8E, 0x80); // 上保护 }

这个技巧看起来简单，但能避免大量"重启后时间归零"的投诉。我在实际项目里还会把校准偏移量也存进 RAM，方便后期微调。

6. 那些例程不会告诉你的踩坑记录

6.1 整点跳变丢秒的排查过程

回到开头朋友那块板子的问题：整点跳变时偶尔丢一秒。我一开始怀疑是读时序问题，用逻辑分析仪抓了波形，发现读操作本身没问题。后来把读时间的频率提高到每秒 10 次，发现丢秒只发生在秒寄存器从 59 跳到 00 的瞬间。

根因是：他用的单字节读，先读秒、再读分、再读时。如果在读完秒之后、读分之前刚好跨秒，秒已经变成 00，但分还是旧值，拼出来的时间就错了一秒。改成突发模式后问题消失。

这个坑的教训是：只要涉及多个时间寄存器的组合读取，就必须用突发模式，否则跨秒、跨分、跨时的边界条件迟早会咬你一口。

6.2 写保护忘记解除导致的"假死"

另一个高频问题是：程序运行中想通过串口命令修改时间，写完发现时间没变。查代码逻辑没问题，最后发现是写保护没解除。因为初始化时解了保护、写完又上了保护，运行中改时间时忘了再解一次。

我的做法是封装一个DS1302_SetTime函数，内部自动处理解保护、写时间、上保护三步，调用方不需要关心保护状态。这样从接口层面杜绝了忘记解保护的可能。

6.3 电源切换瞬间的数据损坏

DS1302 在主电源掉电、切到备用电池的瞬间，如果正好在写操作，可能写入半个字节导致寄存器损坏。虽然概率低，但在工业现场是真实存在的。

缓解办法有两个：一是主电源掉电检测，检测到电压下降立即停止所有 DS1302 操作；二是定期校验，比如每小时读一次时间，如果发现秒、分、时超出合法范围（比如秒 > 59），就重新初始化。我在一个户外采集项目里加了掉电检测，之后再没出现过时间乱码。

6.4 读出来的年份总是 2000 年

DS1302 的年份寄存器只有两位，范围 00~99。它不知道现在是哪一年，需要你在软件里补全世纪。如果你读出来年份是 25，要自己判断这是 2025 还是 1925。常规做法是约定 00~69 对应 2000~2069，70~99 对应 1970~1999，或者干脆在软件里固定加 2000。

这个不是 bug，是芯片设计的历史局限。写代码时记得处理，否则显示出来的日期会让人一脸懵。

7. 完整驱动代码的组织方式

7.1 分层设计：硬件层与业务层分离

我习惯把 DS1302 驱动分成两层：

• 硬件层：只负责 GPIO 操作和字节读写，函数名如DS1302_WriteByte、DS1302_ReadByte。这一层和具体 MCU 相关，换平台时只改这一层。
• 业务层：负责 BCD 转换、时间结构体封装、突发读写、初始化判断。这一层和平台无关，可以直接复用。

时间用一个结构体封装，比散落的全局变量清晰得多：

typedef struct { uint8_t year; // 00~99 uint8_t month; // 01~12 uint8_t day; // 01~31 uint8_t week; // 01~07 uint8_t hour; // 00~23 uint8_t min; // 00~59 uint8_t sec; // 00~59 } DS1302_Time_t;

读写函数直接操作这个结构体，业务代码里就不用关心寄存器地址和 BCD 转换了。

7.2 关键延时与 GPIO 速度

DS1302 的 SCLK 最高频率是 2MHz，但实际用的时候没必要跑那么快。我一般把 GPIO 翻转速度配置为中速或低速，并在每个时钟沿之间加一个微秒级延时（用__NOP()或简单循环）。太快反而容易在长走线或劣质杜邦线上出现时序问题。

如果你用 HAL 库，HAL_GPIO_WritePin本身就有一定开销，通常不需要额外延时。但如果你直接操作 BSRR 寄存器追求速度，就要自己评估是否需要补延时。我的经验是：在 72MHz 的 F103 上直接操作寄存器，加 2~3 个 NOP 就很稳。

7.3 调试手段：先读 ID 再读时间

DS1302 没有 ID 寄存器，怎么确认通信正常？我的办法是：先往 RAM 里写一个已知值，再读回来对比。如果读写一致，说明时序没问题；如果不一致，就是硬件或时序问题，不用去怀疑时间寄存器。

DS1302_WriteByte(0xC0, 0xA5); if (DS1302_ReadByte(0xC1) == 0xA5) { // 通信正常 }

这一步能帮你快速区分"通信问题"和"时间数据问题"，省下大量瞎猜的时间。

8. 关于这颗老芯片的一点个人体会

DS1302 的精度上限其实不低，前提是你把晶振和负载电容这对搭档配好。我手上有一块跑了三年的采集板，用 6pF 晶振不加补偿电容，三年累计误差不到两分钟，平均每天一秒出头。这个成绩对于一颗几毛钱的芯片来说，已经相当能打了。

真正让人头疼的从来不是芯片本身，而是那些"能跑就行"的例程——它们把写保护、突发模式、BCD 转换这些关键点要么省略、要么写错，导致后来的人反复踩坑。我写这篇笔记的目的，就是把这些藏在细节里的东西摊开，让你少走两天弯路。

如果你现在正准备用 DS1302，我的建议是：先把晶振和电容配对确认好，再把突发模式读写跑通，最后加上初始化标志位和掉电校验。这三步做完，你的 RTC 基本就能稳定运行了。至于那些花哨的功能，等基础跑稳了再慢慢加也不迟。