Add RT_TICK_USING_64BIT Kconfig option for configure sizeof rt_tick_t

[lygstate]

拉取/合并请求描述：(PR description)

Replace https://github.com/RT-Thread/rt-thread/pull/9496

Closes: https://github.com/RT-Thread/rt-thread/issues/9482

[

为什么提交这份PR (why to submit this PR)

你的解决方案是什么 (what is your solution)

请提供验证的bsp和config (provide the config and bsp)

• BSP:

• .config:

• action:

]

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

• [ ] 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
• [ ] 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

• [x] 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
• [x] 代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
• [x] 没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
• [x] 所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
• [x] 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
• [x] 代码是高质量的 Code in this PR is of high quality
• [x] 已经使用formatting 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification
• [x] 如果是新增bsp, 已经添加ci检查到.github/ALL_BSP_COMPILE.json 详细请参考链接BSP自查

[github-actions[bot]]

👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread!

为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流。 To ensure your code complies with RT-Thread's coding style, please run the code formatting workflow by following the steps below.

---

🛠 操作步骤 | Steps

1. 前往 Actions 页面 | Go to the Actions page 点击进入工作流 → | Click to open workflow →

2. 点击 Run workflow | Click Run workflow

• 设置需排除的文件/目录（目录请以"/"结尾） Set files/directories to exclude (directories should end with "/")
• 将目标分支设置为 \ Set the target branch to：add_tick_uint
• 设置PR number为 \ Set the PR number to：10735

3. 等待工作流完成 | Wait for the workflow to complete 格式化后的代码将自动推送至你的分支。 The formatted code will be automatically pushed to your branch.

完成后，提交将自动更新至 add_tick_uint 分支，关联的 Pull Request 也会同步更新。 Once completed, commits will be pushed to the add_tick_uint branch automatically, and the related Pull Request will be updated.

如有问题欢迎联系我们，再次感谢您的贡献！💐 If you have any questions, feel free to reach out. Thanks again for your contribution!

[github-actions[bot]]

📌 Code Review Assignment

🏷️ Tag: kernel

Reviewers: @GorrayLi @ReviewSun @hamburger-os @lianux-mm @wdfk-prog @xu18838022837

Changed Files (Click to expand)

• src/Kconfig

---

📊 Current Review Status (Last Updated: 2025-10-13 20:11 CST)

• ⌛ @GorrayLi Pending Review
• ⌛ @ReviewSun Pending Review
• ⌛ @hamburger-os Pending Review
• ⌛ @lianux-mm Pending Review
• ⌛ @wdfk-prog Pending Review
• ⌛ @xu18838022837 Pending Review

---

📝 Review Instructions

1. 维护者可以通过单击此处来刷新审查状态: 🔄 刷新状态 Maintainers can refresh the review status by clicking here: 🔄 Refresh Status

2. 确认审核通过后评论 LGTM/lgtm Comment LGTM/lgtm after confirming approval

3. PR合并前需至少一位维护者确认 PR must be confirmed by at least one maintainer before merging

ℹ️ 刷新CI状态操作需要具备仓库写入权限。 ℹ️ Refresh CI status operation requires repository Write permission.

[unicornx]

这个 PR 到底几个意思？从标题看就是改个 Kconfig 选项，为啥改动还涉及几个 bsp（而且为啥是这几个而不是所有相关的?), 以及为啥还涉及 toolchain 修改以及 ci? 看上去这个 PR 引入了很多不同主题的改动。请在 PR 中详细描述修改原因，必要时需要将该 PR 拆分成多个独立的主题 PR 提交。

P.S. 本 PR 的 commit 有 6 个？是故意的划分行为，还是只是提交的一些中间过程？我建议以后 pr 统一一下规则。 为了避免歧义，我建议每次 pr（包括 rework 后的）都应该避免保留中间的修改过程，如果一个 pr 中存在多个 commit，那也应该只是为了 review 方便从而将整体提交划分为多个子主题，类似多个相关的子 pr 放在一个大的 pr 中提交的概念。

[lygstate]

这个 PR 到底几个意思？从标题看就是改个 Kconfig 选项，为啥改动还涉及几个 bsp（而且为啥是这几个而不是所有相关的?), 以及为啥还涉及 toolchain 修改以及 ci? 看上去这个 PR 引入了很多不同主题的改动。请在 PR 中详细描述修改原因，必要时需要将该 PR 拆分成多个独立的主题 PR 提交。

P.S. 本 PR 的 commit 有 6 个？是故意的划分行为，还是只是提交的一些中间过程？我建议以后 pr 统一一下规则。 为了避免歧义，我建议每次 pr（包括 rework 后的）都应该避免保留中间的修改过程，如果一个 pr 中存在多个 commit，那也应该只是为了 review 方便从而将整体提交划分为多个子主题，类似多个相关的子 pr 放在一个大的 pr 中提交的概念。

拆出去了，主要目的是通过CI来验证这个新改动是否有问题， 通过之后就可以拆出去。 因为riscv的工具链太老了，找不到对应的windows版本，所以需要升级一下

[Rbb666]

• 目前的系统时钟溢出后会自动回绕机制不能满足需求吗？ https://club.rt-thread.org/ask/question/c8735b1faa3b05c5.html https://club.rt-thread.org/ask/question/fc01110aed5d56be.html

• 感觉也没必要新增一个 RT_TICK_USING_64BIT 宏吧， ARCH_CPU_64BIT 就可以满足

[lygstate]

• 目前的系统时钟溢出后会自动回绕机制不能满足需求吗？ https://club.rt-thread.org/ask/question/c8735b1faa3b05c5.html https://club.rt-thread.org/ask/question/fc01110aed5d56be.html
• 感觉也没必要新增一个 RT_TICK_USING_64BIT 宏吧， ARCH_CPU_64BIT 就可以满足

需要获取 更大的时钟，不只是 自动回绕机制的问题， 需要在32位CPU上使用 64位tick， 对于长时间运行的设备是很有用的

[Rbb666]

• 目前的系统时钟溢出后会自动回绕机制不能满足需求吗？ https://club.rt-thread.org/ask/question/c8735b1faa3b05c5.html https://club.rt-thread.org/ask/question/fc01110aed5d56be.html
• 感觉也没必要新增一个 RT_TICK_USING_64BIT 宏吧， ARCH_CPU_64BIT 就可以满足

需要获取 更大的时钟，不只是 自动回绕机制的问题， 需要在32位CPU上使用 64位tick， 对于长时间运行的设备是很有用的

如果需求是要统计时间，不建议根据tick来做时间判断，建议用rtc

[lygstate]

• 目前的系统时钟溢出后会自动回绕机制不能满足需求吗？ https://club.rt-thread.org/ask/question/c8735b1faa3b05c5.html https://club.rt-thread.org/ask/question/fc01110aed5d56be.html
• 感觉也没必要新增一个 RT_TICK_USING_64BIT 宏吧， ARCH_CPU_64BIT 就可以满足

需要获取 更大的时钟，不只是 自动回绕机制的问题， 需要在32位CPU上使用 64位tick， 对于长时间运行的设备是很有用的

如果需求是要统计时间，不建议根据tick来做时间判断，建议用rtc

不是时间是 单调时钟 monotonic clock

[lygstate]

• 目前的系统时钟溢出后会自动回绕机制不能满足需求吗？ https://club.rt-thread.org/ask/question/c8735b1faa3b05c5.html https://club.rt-thread.org/ask/question/fc01110aed5d56be.html
• 感觉也没必要新增一个 RT_TICK_USING_64BIT 宏吧， ARCH_CPU_64BIT 就可以满足

需要获取 更大的时钟，不只是 自动回绕机制的问题， 需要在32位CPU上使用 64位tick， 对于长时间运行的设备是很有用的

如果需求是要统计时间，不建议根据tick来做时间判断，建议用rtc

查了下代码，就是为了解决 RTC在32位系统下精度不够的问题，看来问题解决还没到位，本想直接使用rt_tick_get，问题就解决了，

结果发现RTC相关代码调用的就是

rt_weak rt_err_t rt_ktime_boottime_get_ns(struct timespec *ts)
{
    RT_ASSERT(ts != RT_NULL);

    rt_uint64_t ns = (rt_ktime_cputimer_getcnt() * rt_ktime_cputimer_getres()) / RT_KTIME_RESMUL;

    ts->tv_sec  = ns / (1000ULL * 1000 * 1000);
    ts->tv_nsec = ns % (1000ULL * 1000 * 1000);

    return RT_EOK;
}

rt_weak unsigned long rt_ktime_cputimer_getcnt(void)
{
    return rt_tick_get();
}

所以瓶颈既在rt_tick_get 也在 components\drivers\ktime,

两种思路，第一种对于时钟相关，全部使用 uint64_t，第二种就是使用RT_TICK_USING_64BIT ， 并且 https://github.com/RT-Thread/rt-thread/pull/9008 也没有合理解决问题，应该使用

rt_tickt_t MulDiv(
  rt_tickt_t  nNumber,
  rt_tickt_t nNumerator,
  rt_tickt_t  nDenominator
);

这样对于64位的tick也能正确计算不溢出，目前总是使用 uint64_t,只能保证32位不溢出

[Rbb666]

@Guozhanxin 郭老师可以帮review下吗