[参考译文] tm4c129encpdt：lwIP 和 TivaWare 的使用体验？

您好、12月12日下午、

[引用 user="12ve12pm">也就是说、我是否可能认为有必要从简单的轮询超级循环切换到更复杂的 基于 TI-RTOS 的固件？

[/报价]

我对 lwIP 的了解不够、无法用一种或多种方式来形容、但正如一般的 TI 支持声明一样、我们针对 TM4C 的所有 lwIP 示例都使用 TI-RTOS、并得到 TI RTOS 团队的支持、他们不太可能支持非 RTOS 实现。

[引用用户="12ve12PM]TivaWare_C_Series-2.1.4.178附带 lwip-1.4.1。 目前最新的代码是 lwip-2.0.2、但在 savannah.nongnu.org/.../上发布的代码 似乎缺少任何特定于 TM4C 的代码。 我从1.4.1开始、因为示例程序是基于该代码的、但如果可能、我希望使用最新的代码。 有没有人这么做过、如果是这样、替换较新的代码是否相对快速且容易、或者这是一项困难且耗时的任务？

[/报价]

这项工作尚未完成、我目前还不知道有计划将此支持添加到 TM4C、但这通常由 TI-RTOS 团队来处理。 就更轻松的路线而言、我将了解我是否可以 ping 团队、看看他们是否对此有任何有用的反馈。

您好！

我是 TI-RTOS 团队的一员。 作为一个科学项目、我们在内部将 lwIP 移植到与 TM4C129器件类似的芯片上的 TI-RTOS。 我们发现 lwIP 的封装尺寸略小、但 NDK 的性能略好。 当时、NDK 中的 IPv6支持要好得多。 这是几年前的事情、因此 lwIP IPv6支持现在可能已经得到改善。

关于 RTOS 的"复杂得多"、虽然我同意任何新软件都有学习曲线、但我认为向 RTOS 迁移并不是那么困难。 在单个任务中使用超级循环、而不是主函数中的超级循环。 然后、当您觉得超级循环太复杂时、您可以将较高或低优先级的片段剥离到它自己的任务中。

最大的变化实际上是让 RTOS 管理中断、而不是自己处理矢量表。 您需要在 TI-RTOS 中使用 Hwi 模块、而不是 driverlib。 因此、您不需要填充数组、而是调用 Hwi_create 来将其插入。

一般来说、RTOS 会尝试提供一个结构化的确定性框架来使用。 与复杂应用中的超循环相比、我发现在 RTOS 中实现实时更容易。 此外、您还可以免费获得大量经过测试和记录的代码(以及免费支持)。

在一天结束时、这显然是您的机会。 如果我生产的产品具有最小的内存和简单的功能...我是否会使用 RTOS ...我对此有疑问。 不过、当营销部门开始要求提供更多功能(例如添加文件系统和 BLE 和 XYZ)时、RTOS 使应用程序更易于管理... IMHO

Todd

感谢您的回复。

[引用用户="Ralph Jacobi"]

我对 lwIP 的了解不够、无法用一种或多种方式来形容、但正如一般的 TI 支持声明一样、我们针对 TM4C 的所有 lwIP 示例都使用 TI-RTOS、并得到 TI RTOS 团队的支持、他们不太可能支持非 RTOS 实现。

[/报价]

只需 fyi、lwIP 就可以安装裸机 TivaWare (以及 TI-RTOS)。 在最新的 TivaWare 中、可在 C：\ti\TivaWare_C_Series-2.1.4.178\third_party 下找到 lwip-1.4.1。 在发布问题之前、我找到了以下 TivaWare lwIP 示例。 我一直在研究这些、并构建并运行 enet_io。 除非我遗漏了一些东西，否则这些都似乎都在运行"基本"----不依赖 TI-RTOS。

C：\ti\TivaWare_C_Series-2.1.4.178\examples\boards\ek-tm4c129exl\enet_io

C：\ti\TivaWare_C_Series-2.1.4.178\examples\boards\ek-tm4c129exl\enet_lwip

C：\ti\TivaWare_C_Series-2.1.4.178\examples\boards\ek-tm4c129exl\enet_weather

在没有进一步研究的情况下、我目前唯一不清楚的是 lwIP 在以这种方式使用时是否会在等待网络事件时避免阻止执行。 目前、我认为应该可以。 文件 C：\ti\TivaWare_C_Series-2.1.4.178\third_part手\lwip-1.4.1\doc\rawapi.txt 介绍了 lwIP 的接口、包括以下文本：

"原始 TCP/IP 接口使应用程序能够更好地与 TCP/IP 代码集成。 通过从 TCP/IP 代码中调用回调函数、程序执行是基于事件的。 TCP/IP 代码和应用程序都以相同的方式运行
线程。"

这听起来很有希望。 是否有人对此有过经验、以及是否真正避免了阻止？

[引用 user="ToddMullanix"]

我是 TI-RTOS 团队的一员。 作为一个科学项目、我们在内部将 lwIP 移植到与 TM4C129器件类似的芯片上的 TI-RTOS。 我们发现 lwIP 的封装尺寸略小、但 NDK 的性能略好。 当时、NDK 中的 IPv6支持要好得多。 这是几年前的事情、因此 lwIP IPv6支持现在可能已经得到改善。

[/报价]

感谢您的提及。 我一定会研究 NDK。

[引用 user="ToddMullanix"]

关于 RTOS 的"复杂得多"、虽然我同意任何新软件都有学习曲线、但我认为向 RTOS 迁移并不是那么困难。 在单个任务中使用超级循环、而不是主函数中的超级循环。 然后、当您觉得超级循环太复杂时、您可以将较高或低优先级的片段剥离到它自己的任务中。

[/报价]

我们当然愿意使用 TI-RTOS、前提是它不会干扰我们的中断(例如、对 QEI 进行采样的最高优先级中断)、并且它不会妨碍我们按照我们的要求配置外设(并以不同的方式动态地重新配置外设)。

我喜欢您将我们的普通超循环放入线程中的想法。 在这种情况下、我可能会在单独的线程中运行 TCP/IP 网络、以避免超循环的任何潜在阻塞。

需要注意的是、我们的电路板是多处理器、它们运行共享代码库、但只有一个处理器是具有网络功能的 TM4C129。 出于维护和一致性的目的、将所有内容保留在共享代码库中意味着也需要在 TI-RTOS 上运行较小的处理器。 他们的资源更有限。 或者我们必须重新思考一些问题。

[引用 user="ToddMullanix"]

最大的变化实际上是让 RTOS 管理中断、而不是自己处理矢量表。 您需要在 TI-RTOS 中使用 Hwi 模块、而不是 driverlib。 因此、您不需要填充数组、而是调用 Hwi_create 来将其插入。

[/报价]

这是否意味着在 TI-RTOS 下、矢量表始终驻留在 RAM 中？ (对于基本 TivaWare、矢量表驻留在闪存中、除非有人调用 IntRegister()、在这种情况下、矢量表被复制到 RAM 中。) 如果可能、我更喜欢将其保留在闪存中。 它可以节省内存、并且不太可能在运行时意外地被占用。

我注意到、安装在 TI-RTOS 下的 TivaWare 似乎是较旧版本、v2.1.1.71b (C：\ti_tirtos_tivac_2_16_01_14\products\TivaWare_C_Series-2.1.1.71b)。 TI-RTOS 似乎使用旧代码的原因是什么？

先简单...

[引用用户="12ve12pm]]我注意 到、安装在 TI-RTOS 下的 TivaWare 似乎是较旧版本、v2.1.71b (C：\ti\tirtos_tivac_2_16_01_14\products\TivaWare_C_Series-2.1.1.71b)。 TI-RTOS 似乎使用旧代码的原因是什么？

我们已经有一段时间没有发布用于 TivaC 的新 TI-RTOS、也就是旧版 TivaWare。 小型增强请求和小型错误列表不能保证有新的请求。

[引用 user="12ve12pm]*这是否意味着在 TI-RTOS 下、矢量表始终驻留在 RAM 中？ [/报价]

不可以、我们可以选择仅在闪存中使用矢量表。 您将失去在运行时更改它的能力。 这对于 TI-RTOS 驱动程序来说是一个问题、因为它们在运行时插入矢量表(例如、UART_open 会插入 UART ISR)。 如果您制作了自己的驱动程序、则可以根据需要将其插入。

[引用 user="12ve12pm"]我们当然愿意使用 TI-RTOS，只要它不会干扰我们的中断[/引用]

我们还可以选择将中断设置为"零延迟"中断。 这意味着内核不会与其交互...因此内核会增加零延迟。 这些类型的中断需要注意的是、它们不能在内核调用影响调度(例如 Semaphore_post 等)。 我们还支持受管中断的优先级。

Todd

[引用 user="12ve12pm "]

我的目标问题：

1.避免阻塞函数调用是否困难或不可能？ 也就是说、我是否可能认为有必要从简单的轮询超级循环切换到更复杂的 基于 TI-RTOS 的固件？ 我尝试避免使用完整的 RTOS (代码大小、执行开销、简单性等)、但我们的固件必须连续轮询、并且不能阻止在其控制之外等待网络事件。

[/报价]

在这样的环境中、我不知道如何避免 RTOS 或本质上只能不太好地重新内联 RTOS 的结构。

如果您确实迁移到 RTOS、我建议您也查看 FREE-RTOS。 它与 TI 无关、从我看到的支持请求和 TI-RTOS 说明中可以看出、这里的 FREE-RTOS 限制性较低。

我认为 CB1在使用免费 RTOS 方面可能有一些经验。

Robert

[引用 user="ToddMullanix"]

不可以、我们可以选择仅在闪存中使用矢量表。 您将失去在运行时更改它的能力。 这对于 TI-RTOS 驱动程序来说是一个问题、因为它们在运行时插入矢量表(例如、UART_open 会插入 UART ISR)。 如果您制作了自己的驱动程序、则可以根据需要将其插入。

(笑声)

我们还可以选择将中断设置为"零延迟"中断。 这意味着内核不会与其交互...因此内核会增加零延迟。 这些类型的中断需要注意的是、它们不能在内核调用影响调度(例如 Semaphore_post 等)。 我们还支持受管中断的优先级。

[/报价]

这个零延迟中断看起来正是我们所需要的。

非常重要的问题：(因为您说我们无法与内核或调度程序进行交互。) 这个零延迟中断能够触发另外一个中断吗？ 目前我们使用 IntTrigger()来实现这一目的。 它通过 SWTRIG 触发中断。 我们"窃取"属于未使用的 I2C 外设的中断向量、并将其用于其他用途。 原因是将我们的任务分为两部分。 高优先级中断优先于系统中的任何其它东西来采样 QEI 接通时间。 然后它触发低优先级中断、执行计算。 这解决了长时间运行的计算(在这里、long 是相对的术语)会阻止其他更高优先级的任务(例如、为 I/O、通信等提供服务)的问题。

顺便说一下、如果 QEI 外设的设计能够在硬件中通过计时器外设触发到影子寄存器的副本、该计时器外设也会触发中断(这就是我们在不同 MCU 平台上执行的操作方式)、则不需要上述任何操作。 在设计下一个 MCU 时需要思考的问题。

是否有将应用从裸片 TivaWare 迁移到 TI-RTOS 的指南？

在哪里可以找到有关 TI-RTOS 中包含的旧版 TivaWare v2.1.1.71b 与新版本 TivaWare 2.1.4.178之间差异的文档？

我们使用大量的 MAP_调用来使用 ROM 中的代码。 芯片的 ROM 中硬编码了哪个版本？

是否有人尝试将 TI-RTOS 与较新的 TivaWare 配合使用？

您好、12月12日下午、

首先，我承认，我们忘记了“裸骨头 Enet”的例子是依靠 lwIP 的。 很抱歉,并感谢你纠正我对这一问题的评论。

关于您的一些问题：

[引用 user="12ve12pm "]

在哪里可以找到 有关 TI-RTOS 中包含的旧版 TivaWare v2.1.1.71b 与新版本 TivaWare 2.1.4.178之间差异的文档？

[/报价]

在 TivaWare 2.1.4.178安装中、您可以在 docs 文件夹中找到"SW-TM4C-RLN-2.1.4.178.pdf"。 这是 TivaWare 的发行说明、它们远远超过2.1.1、因此您可以使用它来查看所有可用的版本。

[引用 user="12ve12pm "]

我们使用大量的 MAP_调用来使用 ROM 中的代码。 芯片的 ROM 中硬编码了哪个版本？

[/报价]

版本比上述任何一种版本都旧。 我不知道是哪一个、但出于我将要解释的原因、知道这一点并不重要：使用映射调用是因为当 ROM API 对最新的 TivaWare 不再准确时、我们会更新 rom_map.h 文件。 这意味着 DriverLib 用户指南准确记录了特定版本中的所有 API、因此您无需在过去数年中寻找旧文档即可了解每个 API 的功能。

[引用 user="12ve12pm "]

是否有人尝试  将 TI-RTOS 与较新的 TivaWare 配合使用？

[/报价]

我不相信、但我们将看到 Todd 是否对此有任何反馈。

[引用 user="ToddMullanix"]

12时12分

这个零延迟中断能够触发另外一个中断吗？

[/报价]

内核对受管 ISR 执行的其他管理是什么？

仅供参考、以防将来对他人有所帮助...

作为概念验证、我们创建了一个应用版本、其中包括 lwIP、使用 TivaWare 运行裸片。 目前、我们尚未尝试使用 TI-RTOS、但将来可能会使用。

我在这里所写的内容非常初步、因为我们在测试方面没有进行太多的实验... 实际上，我们*Just *在一个小时前使代码运行。 之后、我必须返回并在我们了解更多信息时发布更多详细信息。

尽管我们的固件面向定制电路板、但我们在此测试中使用了 EK-TM4C129EXL (Crypto Connected LaunchPad)。

我们使用的是目前最新的 TivaWare 版本2.1.4.178。

lwIP 的版本为1.4.1、并与 TivaWare 一同安装在 C：\ti\TivaWare_C_Series-2.1.4.178\third_parti\lwip-1.4.1下。

我们的终端应用不包括嵌入式 Web 服务器、但为了证明 lwIP 能够以最简单的方式与我们的应用配合使用、我们基本上将 enet_io 示例的功能添加到了我们的应用中。 这是 TivaWare 示例、位于 C：\ti\TivaWare_C_Series-2.1.4.178\examples\boards\ek-tm4c129exl\enet_io 下。 它将电路板连接到网络并显示一个网站、该网站显示文本和图像、用户可通过该网站切换 LED 并执行其他功能。

我们首先将 Enet_IO 导入 CCS 工作区、然后在 EK-TM4C129EXL 上成功构建并运行该程序(正如我们完全预期的那样)。

演示了该程序的工作原理后、我们返回固件项目并添加了一个新模块 Network.c Network.h 此模块的目的是初始化网络。 为了编写初始化函数、我们在 enet_io 中关注它的功能、并向代码添加了相关调用、注意不要与现有应用程序发生冲突。 我们复制了 Enet_IO 中的多个函数、表和定义、httpd 服务器依赖这些函数、表和定义来支持 CGI 等。同样、请注意修复与我们现有代码冲突的问题。 我们复制了 io.c、io.h、cgifuncs.c、cgifuncs.h、io_fs.c、 io_fssdata.h 这些文件不会保留在我们的实际固件中、但需要满足这种概念验证的依赖关系。

enet_IO 示例配置三个重要中断：SysTickIntHandler、lwIPEthernetIntHandler 和 AnimTimerIntHandler。 我们消除了 AnimTimerIntHandler 并重写了 io.c、以与我们的应用程序不冲突的方式处理 IO。 lwIPEthernetIntHandler 是芯片以太网中断的处理程序、在 TivaWare 的 utils 目录下的 lwiplib.c 中实现。 这将离开 SysTickIntHandler。 由于我们的应用已经将 Cortex M4的 SysTick 用于其他用途、因此我们配置了 Timer2A 来生成该中断。 我们配置这些中断的优先级与在 enet_io 中的完成方式类似(由于 enet_io.c 中的注释中解释的原因、Timer2A 中断的优先级略高于以太网中断)。

我们向项目添加了必要的包含目录和包含头文件。

满足依赖项并构建代码后，我们就卡在 IntDefaultHandler()中。 我们大部分时间都在跟踪原因、只是为了发现我们忘记在 C 启动文件中实际设置以太网中断矢量！

另一个错误是、我们忘记关闭 Timer2A ISR 处理程序中的 Timer2A 中断标志。 这种忽略导致代码卡在该中断中。

除了这两个错误之外，这一过程也相当顺利。

完成所有这些后、程序将会生成并运行。 它显示的网页与 enet_io 示例相同、而我们的其余固件代码看起来运行正常、看起来响应迅速。 当然、需要进行相当多的测试才能确定此配置是否适用于我们的应用、这是可以接受的。

关于本主题前面有关 TI-RTOS 的讨论：我们研究了这种可能性、并决定尝试在此时不使用 RTOS、原因如下：

(1)实施了我们的大部分应用和电路板驱动程序代码。 将网络这一重要问题留到游戏的后期并不是我们的好主意、但这是由于各种情况而发生的。 我们确信以太网可以正常工作、并且必须测试其他事项以回答设计人员在设计新电路板时提出的紧迫问题。 由于代码已经被执行、我们要么必须在 TI-RTOS 中重新执行、要么保持原样、调用基础 TivaWare 驱动程序库。 第一个选项对我们没有吸引力；第二个选项需要保护用于可重入性的驱动程序库调用。

(2)存在一个微妙的问题、即我们有多种电路板设计、即 TM4C129和 TM4C123系列的多处理器。 我们构建了软件、使具有相同代码构建的相同源模块能够在所有处理器上运行。 配置标头根据目标板和处理器设置大量编译时定义、这些定义将所有内容映射到适当的硬件外设和 I/O 引脚等 这对于维护、实施新功能和降低总体成本非常重要。 但这意味着、如果我们出于网络原因对 TM4C129采用 TI-RTOS、我们将不得不将其用于更有限的 TM4C123处理器、即使在这些处理器上运行的代码与裸机完全一样工作、并且不会受益。

(3)我们的项目主管不喜欢 TI-RTOS 使用较旧版本的 TivaWare。 我可以通过将更新的 TivaWare 中的修复程序反向移植到 TI-RTOS 使用的修复程序并重建 TI-RTOS 来轻松修复该问题、但我们的修复程序会导致难以跟踪的细微损坏、这一想法被打破。

(4) lwIP 似乎可以与 RTOS 配合使用或不与 RTOS 配合使用。 在没有 RTOS 的情况下运行时、lwIP 的 TivaWare 端口会执行以太网 ISR 处理程序中的所有操作。 我们已经将这个设置为最低优先级、这样我们的大多数中断将优先于它。 我只需验证 lwIP 代码中没有任何内容是完全禁用中断、但如果是这种情况、我们应该可以。

在我们进一步测试时、我将返回报告我们发现的内容。 感谢大家的帮助。

仅供参考、以防将来对他人有所帮助...

作为概念验证、我们创建了一个应用版本、其中包括 lwIP、使用 TivaWare 运行裸片。 目前、我们尚未尝试使用 TI-RTOS、但将来可能会使用。

我在这里所写的内容非常初步、因为我们在测试方面没有进行太多的实验... 实际上，我们*Just *在一个小时前使代码运行。 之后、我必须返回并在我们了解更多信息时发布更多详细信息。

尽管我们的固件面向定制电路板、但我们在此测试中使用了 EK-TM4C129EXL (Crypto Connected LaunchPad)。

我们使用的是目前最新的 TivaWare 版本2.1.4.178。

lwIP 的版本为1.4.1、并与 TivaWare 一同安装在 C：\ti\TivaWare_C_Series-2.1.4.178\third_parti\lwip-1.4.1下。

我们的终端应用不包括嵌入式 Web 服务器、但为了证明 lwIP 能够以最简单的方式与我们的应用配合使用、我们基本上将 enet_io 示例的功能添加到了我们的应用中。 这是 TivaWare 示例、位于 C：\ti\TivaWare_C_Series-2.1.4.178\examples\boards\ek-tm4c129exl\enet_io 下。 它将电路板连接到网络并显示一个网站、该网站显示文本和图像、用户可通过该网站切换 LED 并执行其他功能。

我们首先将 Enet_IO 导入 CCS 工作区、然后在 EK-TM4C129EXL 上成功构建并运行该程序(正如我们完全预期的那样)。

演示了该程序的工作原理后、我们返回固件项目并添加了一个新模块 Network.c Network.h 此模块的目的是初始化网络。 为了编写初始化函数、我们在 enet_io 中关注它的功能、并向代码添加了相关调用、注意不要与现有应用程序发生冲突。 我们复制了 Enet_IO 中的多个函数、表和定义、httpd 服务器依赖这些函数、表和定义来支持 CGI 等。同样、请注意修复与我们现有代码冲突的问题。 我们复制了 io.c、io.h、cgifuncs.c、cgifuncs.h、io_fs.c、 io_fssdata.h 这些文件不会保留在我们的实际固件中、但需要满足这种概念验证的依赖关系。

enet_IO 示例配置三个重要中断：SysTickIntHandler、lwIPEthernetIntHandler 和 AnimTimerIntHandler。 我们消除了 AnimTimerIntHandler 并重写了 io.c、以与我们的应用程序不冲突的方式处理 IO。 lwIPEthernetIntHandler 是芯片以太网中断的处理程序、在 TivaWare 的 utils 目录下的 lwiplib.c 中实现。 这将离开 SysTickIntHandler。 由于我们的应用已经将 Cortex M4的 SysTick 用于其他用途、因此我们配置了 Timer2A 来生成该中断。 我们配置这些中断的优先级与在 enet_io 中的完成方式类似(由于 enet_io.c 中的注释中解释的原因、Timer2A 中断的优先级略高于以太网中断)。

我们向项目添加了必要的包含目录和包含头文件。

满足依赖项并构建代码后，我们就卡在 IntDefaultHandler()中。 我们大部分时间都在跟踪原因、只是为了发现我们忘记在 C 启动文件中实际设置以太网中断矢量！

另一个错误是、我们忘记关闭 Timer2A ISR 处理程序中的 Timer2A 中断标志。 这种忽略导致代码卡在该中断中。

除了这两个错误之外，这一过程也相当顺利。

完成所有这些后、程序将会生成并运行。 它显示的网页与 enet_io 示例相同、而我们的其余固件代码看起来运行正常、看起来响应迅速。 当然、需要进行相当多的测试才能确定此配置是否适用于我们的应用、这是可以接受的。

关于本主题前面有关 TI-RTOS 的讨论：我们研究了这种可能性、并决定尝试在此时不使用 RTOS、原因如下：

(1)实施了我们的大部分应用和电路板驱动程序代码。 将网络这一重要问题留到游戏的后期并不是我们的好主意、但这是由于各种情况而发生的。 我们确信以太网可以正常工作、并且必须测试其他事项以回答设计人员在设计新电路板时提出的紧迫问题。 由于代码已经被执行、我们要么必须在 TI-RTOS 中重新执行、要么保持原样、调用基础 TivaWare 驱动程序库。 第一个选项对我们没有吸引力；第二个选项需要保护用于可重入性的驱动程序库调用。

(2)存在一个微妙的问题、即我们有多种电路板设计、即 TM4C129和 TM4C123系列的多处理器。 我们构建了软件、使具有相同代码构建的相同源模块能够在所有处理器上运行。 配置标头根据目标板和处理器设置大量编译时定义、这些定义将所有内容映射到适当的硬件外设和 I/O 引脚等 这对于维护、实施新功能和降低总体成本非常重要。 但这意味着、如果我们出于网络原因对 TM4C129采用 TI-RTOS、我们将不得不将其用于更有限的 TM4C123处理器、即使在这些处理器上运行的代码与裸机完全一样工作、并且不会受益。

(3)我们的项目主管不喜欢 TI-RTOS 使用较旧版本的 TivaWare。 我可以通过将更新的 TivaWare 中的修复程序反向移植到 TI-RTOS 使用的修复程序并重建 TI-RTOS 来轻松修复该问题、但我们的修复程序会导致难以跟踪的细微损坏、这一想法被打破。

(4) lwIP 似乎可以与 RTOS 配合使用或不与 RTOS 配合使用。 在没有 RTOS 的情况下运行时、lwIP 的 TivaWare 端口会执行以太网 ISR 处理程序中的所有操作。 我们已经将这个设置为最低优先级、这样我们的大多数中断将优先于它。 我只需验证 lwIP 代码中没有任何内容是完全禁用中断、但如果是这种情况、我们应该可以。

在我们进一步测试时、我将返回报告我们发现的内容。 感谢大家的帮助。