MPLABX具有许多仿真功能，故障排除和错误测试功能，在大学期间编写C代码时发现这些功能非常有用。既然即时消息在行业中和系统变得更加复杂，则实时操作系统（RTOS）似乎已很普遍。
我还无法将这些出色的故障排除工具与RTOS集成在一起。有没有被忽略的快速修复方法？还是关于这两个不跳动的更根本的东西？
谢谢！
最佳答案
没有什么可以阻止MPLABX中的RTOS开发，缺少任何集成功能也不能阻止使用RTOS库。毕竟它只是一个像其他图书馆一样的图书馆。但是，RTOS所暗示的是稍微复杂一些的运行时和调试环境，在大多数情况下，当您遇到断点时，所有线程都将挂起。
您对RTOS集成有什么期望？在提供这种整合的情况下，支持会有所不同；一些可能的功能包括：
查看线程调用栈
查看多个线程的状态，
查看状态内核对象，
线程感知的调试和断点，
每线程CPU负载统计信息
线程执行和上下文切换的时序图。
当RTOS产品来自第三方供应商时，RTOS集成必须通过两家供应商之间的双边协议来达成，或者在IDE供应商为此目的提供了文档化的插件体系结构的情况下，RTOS供应商或另一方选择了支持它。有很多RTOS供应商和许多IDE-选择两个可以协同工作，而将您的选择限制在可能不太适合您的应用程序或目标的产品上。
即使是具有一定程度的RTOS集成的IDE也很少实现线程级断点-它们需要具有内置到内核中的能力（在上下文切换器上切换断点），而不仅仅是IDE或调试器。例如，VxWorks支持该功能，但不针对PIC。
当IDE，RTOS和编译器通常来自同一供应商时，IDE中的RTOS集成最为常见。例如Mentor Graphics Nucleus，WindRiver的VxWorks，QSSL的QNX，TI的CCS和DSP / BIOS或Keil的uVision和RTX；都不是目标PIC。 Xpress Logic的ThreadX与用于PIC32的MPLAB Harmony集成在一起。
大多数RTOS / PIC组合可能过于简单和利基，而且市场过于分散，甚至不起作用，老实说，您可能并没有错过太多。
不管IDE中对RTOS的意识如何，您仍然可以期待正常的源代码级符号调试器功能，但只能看到当前线程的非静态局部变量。这似乎没有看起来那么严格；通过在线程交互的信号发送和接收端使用断点，可以在大多数情况下充分调试线程交互行为。
关于c - 为什么MPLAB X与RTOS不兼容，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/30511297/