• 状态
  • 已锁定 已锁定
  • 回复 3 回复
  • 订户 0 订户
  • 视图 0 视图
  • 用户 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.

[参考译文] IWR6843：Linux OS 与 Windows 中的 MMWAVE-SDK

admin
Guru**** 2866460 points

Other Parts Discussed in Thread: IWR6843, MMWAVE-SDK

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

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1636719/iwr6843-mmwave-sdk-in-linux-os-vs-windows

器件型号： IWR6843
Thread 中讨论的其他器件： MMWAVE-SDK

我们在应用中使用的是 IWR6843 芯片。 现在我们发现了在 Windows 11 中构建应用程序固件的操作与在 Linux Ubuntu 18.04 中构建的操作稍有不同的问题。

我们将在 Windows 和 Linux 中使用最新的 MMWAVE-SDK (SDK_03_06_02_00-LTS)

现在、我正在验证两个操作系统 (Win 和 Linux) 中的构建环境是否正确

我决定在 Windows 和 Linux 中构建 ti 演示代码 (xwr68xx)、以验证我是否获得相同的输出二进制文件 (C：\ti\mmwave_sdk_03_06_02_00-LTS\packages\ti\demo\xwr68xx)

使用毫米波 SDK 用户指南中的指令构建演示代码后、我发现输出二进制文件 (xwr68_mmw_demo.bin) 并不完全相同。

问题：在 Windows 11 和 Linux (Ubuntu 18.04) 中构建 xwr68xx TI 演示代码之后、我是否应该获得完全相同的输出二进制文件？ 我无法在实际硬件中测试输出二进制文件。

附件是来自 Windows 内部版本和 Linux 内部版本的 mmw 输出日志
mmw_output_win.zip
mmw_output_linux.zip  

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

    尊敬的 Tuomas：

    我们正在查看您的查询。 请给我们一些时间来答复。

    谢谢、
    Saransh Gautam

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

    您好：

    您是否在 Windows 和 Linux 操作系统中都使用了 Code Composer Studio 来生成这些工程？ 我的猜测可能是偶然使用不同的依赖关系。 可能是一个与另一个较新的编译器版本、这可能会导致二进制大小略有不同。 两个二进制文件是否都可以工作？

    此致、

    Pedrorm

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

    您好、

    遗憾的是、由于缺少硬件、我无法测试 TI 演示代码二进制文件。

    但是、关于我最初发布的与我们使用 IWR6843 的应用相关的问题：多年来、我们使用 Windows 编译应用固件。 最近、我们开始使用 Linux、编译工作顺利几个月、但随后基于 Linux 构建的应用程序固件开始崩溃（断言失败）。 在 Windows 上构建的相同固件没有问题。

    使用 Code Composer Studio 进行调试后、我们找到了发生断言的位置、很明显这是一个时序问题、即 DSP 帧处理未在帧周期内完成。

    我们分析了构建工件、发现 Linux 构建会生成稍大的 DSP 二进制文件。 这将预编译的运行时支持库作为差异的来源。 根据这一发现、我们尝试将 rts6740_elf.lib 从 Windows (C：\ti\cgt-c6000_8.3.3\lib\rts6740_elf.lib) 复制到 Linux、并使用此 Windows RTS 库执行干净构建。 更换后、应用程序工作正常—未发生断言。

    我们还按相反的方向进行了验证：我们将 Linux rts6740_elf.lib 复制到 Windows 并在其中执行了全新构建。 该构建发生了相同的断言失败、从而确认库是根本原因。

    因此、Windows 和 Linux TI CGT C6000 v8.3.3 软件包中包含略有不同的预编译 rts6740_elf.lib 库。 我们详细比较了这两个库：

    -两者都是具有 554 个对象成员的 Unix ar 档案
    -构建属性 (.c6xabi.attributes) 是字节相同的—相同的编译器标志和优化级别
    -两者都是基于 TI 的 Linux Jenkins CI 构建的（编译路径包含/linux/,甚至在 Windows 软件包中）
    -但是,33 个对象大小不同,510 个对象大小相同,但内容不同
    -关键数学函数在 Linux 上产生更大的代码:__c6xabi_divd（+32 字节）,__c6xabi_divf（+32 字节）, ldexp（+64 字节）

    这在编译器的代码生成（指令调度，寄存器分配）中似乎是非确定性的、而不是构建配置的差异。

    此库的最后一个更新是在 2019年02月18日 上进行的、因此我假设不会有任何进一步的更新。

    我们的应用对时间要求相当严格、在使用 Linux rts6740_elf.lib 时、我们最近所做的代码更改似乎推动了 DSP 处理时间超出了预算。 Linux 预编译库之前确实使用了较小的应用程序代码。

    库位置：
    - Windows：c：\ti\ti-cgt-c6000_8.3.3\lib\rts6740_elf.lib
    - Linux:~/ti/ti-cgt-c6000_8.3.3/lib/rts6740_elf.lib

    问题：
    1.是否在 Linux 上使用 Windows 版本的 rts6740_elf.lib 是唯一可行的权变措施？
    2.是否可以使用 lib/Makefile 中 TI 提供的 Makefile 和源文件从源代码重新编译 rts6740_elf.lib src？ 这是否会产生确定的结果？