Thread 中讨论的其他器件:UNIFLASH、 IWRL6432
工具/软件:
您好!
我正在探索6432AOP、并运行一些预构建的图像和可视化工具、虽然有点古怪、但最终确实可行。 我一直在使用生命体征演示、它是预构建的 appImage。 我想开始使用代码、因此我的第一步是推送我认为与 https://dev.ti.com/tirex/explore/node?node=A__AS5.DPBhh5hqkLB3.kAODg__radar_toolbox__1AslXXD__LATEST&placeholder=true 中完全相同的代码
我遵循了以下步骤:
- 我将工程导入云 CCS
- 在释放模式下编译它
- 已下载 vital_signsxxxx.out 文件
- 使用 out2rprc 将.out 转换为.rprc
- 使用 multicoreimagegen 将其转换为.appImage
- 使用 crcMultiCoreImage 计算 CRC
- 已使用 appendbinCrc 来附加它
- 已使用 uniflash 上传映像。
所有这些似乎都起了作用。 当我将可视化工具连接到它时、它似乎冻结了、然而看着它后面的控制台、它一直在逐行缓慢地向它馈送线性调频脉冲配置、花费了大约1分钟、然后基本上出现错误。
我不是很清楚我做了什么错了,我希望这是显而易见的。 我在 CCS 中没有看到 AOP 版本的芯片列为器件、只有 IWRL6432我不确定是否重要、我假设线性调频脉冲配置解决了很多差异。 使我在 MacBook M4上的一些事情复杂化,但在 Windows 11 Arm 的 Parallels 中执行大部分这些步骤。
请注意、我认为 USB XDS110的驱动程序在 Windows 11 Arm 64位上不起作用。 我可以通过 UART 与它交谈,但我认为不运行常用的 windows x86-64如果复杂的事情.
最后、我注意到似乎有更多文件被拉入云 CCS 版本的代码中、但它们似乎与 SDK 相关(我确实看到了 mmw_cli.h 等似乎包含的内容)、我假设云 CCS 只是将它们拉入、因为它必须以不同的方式进行封装。
不管怎样-我希望这是足够的细节。