[参考译文] CC3551E：从 CC3135迁移

Shlomi、您好！
CC35xx 系统内核通过某种总线连接到连接内核(也称为网络内核)、对吗？ 我假设简单地将每个读取字节从 SPI 转发到总线上的器件是无效的。 编写翻译地图的工作量可能太大、并会引入新的故障点。 我想现在我们将考虑使用 CC3351来简化从 CC3135的迁移。

编辑：我看到旧的 CC3135黑盒式 API 不见了、CC33也依赖于外部 MCU 上的 lwip、对吗？

谢谢
此致、
Lukas

您好！

您一定可以出于您的目的使用 cc33xx。 它甚至更好。

我们拥有客户、他们使用它来连接外部 MCU (胖 MAC 选项)。 就像 cc31xx 一样、它通过 SPI 接口连接。

 此时、API 集要低得多、因此我认为会更容易。

LwIP 与 Thick MAC 选项一起使用、在 MCU 端运行、而 cc31xx 只有自己的网络协议栈、并且完全运行。

此致、

Shlomi

您好！
现在、我可以确认、CC3551是我们唯一的选择。 我们当前的外部 MCU 上没有足够的存储器用于新的 TCP/IP 堆栈、因此我们必须使用额外的 M33来实现该堆栈。
我还有几个问题：
1.您能详细说明需要如何根据我们的用例调整 AT 库吗? 我们需要使该器件与基于 CC3135的旧网络模块兼容。

2. TI 是否可以提供旧的 CC3135服务包的源代码供参考？ 这将大大减少开发工作。

3. TI 有没有计划为这些芯片提供完整的固件、让客户再次享受以前配套 IC 带来的便利？ 也许以未来 MOD 变体的形式出现？

此致、
Lukas

您好！

1. 目前、我们没有像在 CC32xx 上那样在 CC35xx 上实现 AT 命令库、但在集成之后、您的外部主机需要通过 UART (或 SPI)遵循 AT 命令语法。
2. 您指的是什么代码？ 我们仅共享应用层代码、该代码适用于 CC31xx 情况、以及在外部 MCU 上运行的代码。
3. 固件从不共享、是在内部处理器上运行的 IP。 同样、如果您以前在 CC31xx 上运行代码并且想要使用 CC35xx、则需要进行迁移(目前还不存在文档)。

Shlomi