• 状态 Resolved
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 0 订户
  • 视图 701 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC1310：RTC 计时是否会遇到2038年问题？

admin
Guru**** 2478765 points
Other Parts Discussed in Thread: SYSBIOS, CC1310

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1325975/cc1310-will-rtc-timing-encounter-year-2038-problems

器件型号：CC1310
Thread 中讨论的其他器件：SYSBIOS、

大家好、

客户使用 simplelink_cc13x0_sdk_4_20_02_07中的 seconds_set API 来设置系统时间、然后使用本地时间获取年、月、日和其他信息。 此 SDK 是否解决了2038年的问题？  

谢谢！此致！

约兰德

  • 0
    TI__Guru**** 2478765 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    不,我不这么认为。 如果您在 SDK 中的 C：\ti_simplelink_cc13x0_sdk_4_20_02_07\kernel\tirtos\packages\ti\sysbios\fale\arm\msp432文件中、实际上会出现警告： 

    /*
 *  ======== Seconds_get ========
 *
 *  Note: This function is only valid until 2036-02-07 06:28:15 (TI Compiler)
 *      or 2038-01-19 03:14:07(GNU, IAR Compilers). At this time the number
 *      of seconds since 1900/1970 will cause integer overflow on 32-bit
 *      systems.
 */

    CC26xx 的 seconds.c 文件(C：\ti\simplelink_cc13x0_sdk_4_20_02_07\kernel\tirtos\packages\ti\sysbios\family\arm\cc26xx)中不存在相同的警告

    但我认为这并不意味着这在这里不是问题，只是没有警告。

    Br

    Siri

  • 0
    TI__Guru**** 2478765 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好，Siri，ć

    感谢您的答复。

    但我想知道如何避免这个问题。

    此致、

    约兰德

  • 0
    TI__Guru**** 2478765 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您无法避免该问题。

    如果使用 UNIX 时间并使用带符号的32位整数来存储 它、则会出现溢出。

    参见 年2038问题-维基百科 ,自由的百科全书。

    如果此溢出对您的系统而言是否严重、我想取决于您使用的时间和日期。

    如果你只是有一些东西只是要显示当前时间,你可以做某种检查代码,看看数据是否已换行(时间突然出现在 00 : 00:00 UTC 在  1970年1月1日), 然后对 其进行某种补偿。

    很抱歉，我不能为您提供任何解决办法。

    Siri

  • 0
    TI__Guru**** 2478765 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好，Siri，ć

    客户表示：

    SDK 从寄存器中读取从1970年开始的秒数、但在计算时、添加1900至1970年之间的秒数、并且计算始于1900年。 在这种情况下、32位秒的最大值仅为136年。 关于。 到2036年将出现问题。 对于像我这样需要时间戳转换的应用程序而言、这会有问题。 我想您可以添加一个从1900年开始、一个从1970年开始的宏定义(或者您是否已经有这个定义？)、以便能够解决这个问题。

    此致、

    约兰德

  • 0
    TI__Guru**** 2478765 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    正如我所说，我们没有解决这一问题的办法，我认为也没有计划对此作出任何修正。

    我认为、在我们使用 RTOS 7 (CC13x2 SDK)的较新器件上、此问题可能已通过使用64位而不是32位进行了修复、但没有计划针对 CC1310进行 SDK 更新。

  • 0
    TI__Guru**** 2478765 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Siri：

    客户认为可以通过修改代码来解决：

    是否可能不补偿这70年、而是直接使用从1970年开始的秒来计算当前时间？ 32位变量138年、它应该能够记住2100多年、或者我的理解中有什么错误吗？

    _ti__有一个宏定义(我不知道这个宏用于什么应用)：

    此致、

    约兰德

  • 0
    TI__Guru**** 2478765 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好，Siri，

    2038年的发行时间是从1970年1月1日开始计算的，没有赔偿问题。 SDK 代码使用 uint 无符号整数、此整数应能够在2106之前使用、因此2038年没有时间溢出。 我是否理解正确？

    此致、

    约兰德  

  • 0
    TI__Guru**** 2478765 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    CC1310 SDK 使用32位变量、会在2036年02月07日06：28：15中遇到问题。

    会发生溢出、如下所述/说明：

    第2038年-维基百科,自由的百科

    也许可以在应用中解决这个问题、客户也可以随意尝试在实现中修复这个问题、但我将无法提供关于如何做到这一点的任何更多指导和/或示例代码。

    如果客户认为自己有一个解决方案、他只需要尝试以某种方式进行测试。

    很抱歉、我无法就此主题提供更多帮助。

    Siri