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