我有一个带有 32 个微控制器的嵌入式板，以及一个定制的操作系统，
问题，
没有像 NAND FLASH 之类的持久存储。
如果没有串口，
【问题讨论】：
您可能想确定记录时 RAM 溢出的原因，如果您只记录需要查看的内容，则不需要太多记录。您可以登录到循环缓冲区以防止溢出。使用 Ram 日志记录，您可能可以接近真实速度运行。记录到通信链路会增加系统的延迟、中断和任务切换。
不要从一开始就记录所有内容。仅记录足以了解您的问题何时发生。一旦您知道问题发生的时间，请在输入问题部分后立即记录更多详细信息。
如果您真的想立即解决问题，请获取Green Hills Trace pod。您的硬件必须设计为允许连接 Pod，而且非常昂贵。然而结果令人难以置信......
【讨论】：
如果您可以使用微控制器上的输出端口而不会过多地干扰其他硬件，则可以输出当前任务编号并使用逻辑分析仪对其进行捕获。
【讨论】：
- 当我尝试写入 RAM 时，它会溢出 ~~
你在记录什么以及你允许有多大的缓冲区？如果不知道您是如何实现的，很难给出建议，但您可能可以做很多事情来优化内存日志记录。
如果在每次上下文切换时记录任务 ID 和时间戳（例如每个事件 3 个字节），则每 KB 应该获得 341 个上下文切换。在许多系统中，这将是一个重要的时期，记住这只是 1K 的缓冲区。如果您还要记录中断，那可能会更昂贵，因为记录所有系统调用而不仅仅是上下文切换。也许你可以在日志中实现一个过滤器，所以它只记录感兴趣的任务或事件。您还可以实现事件触发器，以便在发生此类事件时将记录的数据自动转储到您的串行端口（并且当感兴趣的事件发生时，因此传输行为不会干扰您的调查）。您还应该将缓冲区实现为循环缓冲区，以便简单地丢弃最旧的数据而不是溢出，为新数据腾出空间，以便在发生触发事件时，您可以获得所有导致它的事件信息。
【讨论】：
比 Johan 强调的 ARM ETM 更轻巧，MIPI System Trace Protocol 专为此类跟踪活动而设计。它专为仪器跟踪而设计，典型实现通过四位端口提供约 500 Mbit/s 的跟踪带宽。
但是，您的董事会不太可能支持它。 :-( 另外，您需要一个跟踪接收器，这又要花费一辆小型汽车的价格（劳特巴赫有一个）。
【讨论】：
我不知道您使用的是什么平台，但是...
ARM:s 有一个名为ETM 的块，可以解决您的问题。 通过Lauterbach 的核心调试器，您可以使用该块。
缺点是成本高，和小新车差不多:)
而且我不知道你的硬件是否有 ETM 块...
【讨论】：
您可以访问任何 gpio 或测试点吗？根据您真正实际切换的任务数量，您也许可以为每个任务切换设置一个 gpio，并使用示波器或逻辑分析仪进行观察。了解问题任务的基本切换和性能就足够了，而且它比调试器便宜。（如果您有权访问并知道如何对 gpio 进行编程，至少部分成本和人工）这可能是足够的信息解决问题。
【讨论】：
当我尝试通过串口发送它时，系统行为会发生变化（因为串口很慢）
这听起来好像您正在阻止对串行端口的写入（如果我的猜测有误，我深表歉意）。
串行端口可能很慢，但如果您使用基于中断的 TX，它应该对您的系统产生轻微影响。也就是说，将数据写入循环缓冲区，然后使用串行 TX 中断例程从缓冲区中获取字节并在后台传输它们。
在 57,600 bps、8-N-1 的情况下，您每秒最多可以传输 5,760 字节。如果您的任务切换器生成一个 2 字节的时间戳加上一个 1 字节的任务 ID，那么您每秒最多可以跟踪 1,900 个任务切换。但你可能想把它框起来，例如使用 COBS，这意味着每条记录 5 个字节，因此您每秒最多可以跟踪 1,100 个任务切换。
【讨论】：
首先计算您将拥有多少个任务开关，并与您的串行速度进行比较。也许无法推送这么多数据？考虑比
如果串行就足够了，那么也许可以使用缓存？首先写入内存，并且是单独的任务从内存中以块发送到串行的方式获取数据。寻找circular buffering 之类的东西以避免锁定。
【讨论】：
运行跟踪时是否需要实时行为？我的意思是，是否可以选择登录 RAM 直到缓冲区（几乎）已满，然后进入一个关键部分，以防止应用程序进行任务切换和服务中断并将缓冲区转储到串行线路上。这将阻止应用程序的运行一段时间，但根据您正在运行的测试，它可能是可以接受的。 任何通过串口、USB 等进行的实时跟踪都会影响应用程序的行为，因此无法确定您所测量的内容是否相关。
您可以做的另一件事（如果您还没有这样做的话）是使日志记录尽可能小，例如：每个任务切换 1 个字节，最重要的半字节旧任务的任务 ID 和最不重要的半字节新任务的任务 ID。这样，您应该能够在 512KB 的内存中处理大量任务切换。
【讨论】：