高速追踪
我有一个带有 32 微控制器的嵌入式板和一个定制的操作系统，
- 不幸的是，到目前为止，连接 只能通过串口连接到PC 端口，
- 内部存储器限制为 512KB。
- 至少有 10 个任务 系统
问题，
- 我想捕获序列 哪个任务切换发生，
- 当我尝试写入 RAM，它溢出了~~
- 当我尝试发送它时 串行端口，系统行为 变化（因为串行端口很慢）
没有像 NAND FLASH 之类的持久存储。
- 你们能想出一些主意吗？
如果没有办法使用串口，
- 你们能推荐一些其他的吗 接口或串行端口。
I have an embedded board with a 32 Micro-controller, and an custom built OS,
- Unfortunately, as of now, connection
to the PC is only through serial
port, - Internal memory is limited to 512KB.
- There are at-least 10 tasks in the
system
Question,
- I want to capture the sequence in
which task switch happens, - And when I try to write into the
RAM, it overflows ~~ - And when I try to send it though
serial port, the system behavior
changes (as serial port is slow)
There is no persistent storage like NAND FLASH, or something.
- Can you guys think of some Idea?
If there is no way with Serial port,
- Can you guys recommend some other
interface or than Serial port.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
您可能想要确定日志记录时 RAM 溢出的原因，如果您只记录需要查看的内容，则不需要太多日志记录。您可以登录到循环缓冲区以防止溢出。通过 Ram 日志记录，您可能可以以接近真实速度运行。记录到通信链路会增加系统的延迟、中断和任务切换。
不要从一开始就记录所有内容。日志仅足以了解您的问题何时发生。一旦您知道问题何时发生，请在输入问题部分后立即记录更多详细信息。
如果您确实想立即解决问题，请获取 Green Hills Trace pod。您的硬件必须设计为允许连接 Pod，而且它非常昂贵。然而结果却令人难以置信......
You probability want to determine why your RAM overflows when logging, you don't need much logging if you log only what you need to see. You can log into a circular buffer to prevent overflow. With Ram logging you probably can run at close to true speed. Logging to a communications link added latency, interrupts and task switches to the system.
Don't log everything from the start. Log only enough to understand when your problem occurs. Once you know when your problem occur log more detail as soon as the problem section is entered.
If you really want to solve the problem in no time get a Green Hills Trace pod. Your hardware must be designed to allow the Pod to be connected and it is terribly expensive. However the results is incredible ...
如果您可以使用微控制器上的输出端口而不会过多干扰其他硬件，则可以输出当前任务编号并使用逻辑分析仪捕获它。
If you can use an output port on the microcontrollers without disturbing other hardware too much you can output the current task number and capture it with a logic analyzer.
你在记录什么以及你允许多大的缓冲区？如果不知道如何实现这一点，很难提供建议，但您可能可以做很多事情来优化内存中日志记录。
如果在每次上下文切换时记录任务 ID 和时间戳（例如每个事件 3 个字节），则每 KB 应该获得 341 次上下文切换。在许多系统中，这将是一个重要的时期，请记住，这只是 1K 的缓冲区。如果您还记录中断，那么可能会更昂贵，因为记录所有系统调用而不仅仅是上下文切换。也许您可以在日志记录中实现一个过滤器，这样它只记录感兴趣的任务或事件。您还可以实现事件触发器，以便在发生此类事件时（以及当发生感兴趣的事件时，因此传输行为不会干扰您的调查），记录的数据会自动转储到串行端口。您还应该将缓冲区实现为循环缓冲区，以便简单地丢弃最旧的数据以为新数据腾出空间，而不是溢出，这样在发生触发事件时，您就可以获得导致该事件的所有事件信息。
What are you logging and how large a buffer do you allow? Without knowing how you implemented this it is hard to advise, but there is probably much you could do to optimise in-memory logging.
If at each context switch you log task ID and time-stamp (say 3 bytes per event) you should get 341 context switches per Kbyte. In many systems that would be a significant period, and remember that is for just 1K of buffer. If you are logging interrupts as well that may be more expensive, as would logging all system calls rather than just context switches. Perhaps you could implement a filter in the logging, so it only logged tasks or events of interest. You might also implement event triggers so that the logged data is automatically dumped to your serial port when such an event occurs (and when the event of interest has occurred, so the act of transmission is not intrusive to your investigation). You should also implement the buffer as a circular buffer so that rather than overflowing, the oldest data is simply discarded to make room for the new, so that on occurrence of a trigger event, you have all the event information leading up to it.
MIPI 系统跟踪协议 比 Johan 强调的 ARM ETM 更轻量级专为此类跟踪活动而设计。它专为仪器跟踪而设计，典型的实现通过四位端口提供大约 500 Mbit/s 的跟踪带宽。
然而，你的董事会不太可能支持它。 :-( 另外，您还需要一个跟踪接收器，这又要花费一辆小型汽车的价格（劳特巴赫有一辆）。
Somewhat more light-weight than the ARM ETM highlighted by Johan, the MIPI System Trace Protocol has been designed for just this sort of trace activity. It is designed for instrumentation trace, and typical implementations offer around 500 Mbit/s of trace bandwidth over a four-bit port.
However, it is unlikely your board has support for it. :-( Also, you need a trace receiver, which again can cost the price of a small car (Lauterbach have one).
我不知道你正在使用什么平台，但是...
ARM：有一个名为 ETM，解决您的问题。
通过 Lauterbach 的硬核调试器，您可以使用该块。
缺点是成本高，和一辆小新车差不多:)
而且不知道你的硬件有没有ETM块...
I don't know what platform you are using but...
The ARM:s have a block called ETM, that solves your problem.
And with a hardcore debugger from Lauterbach you can use that block.
The downside is that the cost is high, approximately the same as a small new car :)
And I don't know if your hardware has a ETM block...
您可以访问任何 GPIO 或测试点吗？根据您实际切换的任务数量，您也许可以为每个任务切换设置一个 GPIO，并使用示波器或逻辑分析仪进行观察。了解问题任务的基本切换和性能就足够了，而且比调试器便宜。（至少零件成本和劳动力，如果您有权访问并知道如何对 GPIO 进行编程）这可能是足够的信息来解决问题。
Do you have access to any gpio's or test points? Depending on how many tasks you are really actually switching between, you maybe able to set a gpio for each task switch, and observe with an oscilloscope or logic analyzer. It will be enough to understand the basic switching and performance of the problem tasks, and it will be cheaper than a debugger.(at least parts cost, and labor if you have access and know how to program the gpio's) This may be enough info to troubleshoot the problem.
这听起来好像您正在阻止对串行端口的写入（如果我的猜测是错误的，我很抱歉）。
串行端口可能会很慢，但如果您使用基于中断的TX，它应该对您的系统产生较小的影响。也就是说，将数据写入循环缓冲区，然后使用串行 TX 中断例程从缓冲区抓取字节并在后台传输它们。
在 57,600 bps、8-N-1 的情况下，每秒最多可以传输 5,760 字节。如果您的任务切换器生成 2 字节时间戳加上 1 字节任务 ID，那么您每秒最多可以跟踪 1,900 次任务切换。但您可能想对其进行框架，例如使用 COBS，这意味着每条记录 5 个字节，因此每秒最多可以跟踪 1,100 个任务切换。
That makes it sound as though you're doing blocking writes to the serial port (my apologies if my guess is wrong).
The serial port may be slow, but if you use interrupt-based TX, it should have a minor impact on your system. That is, write your data into a circular buffer, and then have a serial TX interrupt routine to grab the bytes from the buffer and transmit them in the background.
At 57,600 bps, 8-N-1, you could transmit up to 5,760 bytes per second. If your task switcher generates a 2-byte timestamp plus a 1-byte task ID, then you can trace up to 1,900 task switches per second. But you may want to frame it, e.g. using COBS, which would mean 5 bytes per record, so you can trace up to 1,100 task switches per second.
首先计算您将有多少个任务切换，并与串行速度进行比较。也许只是无法推送这么多数据？考虑
如果串行就足够了，那么也许可以使用缓存？首先写入内存，并且是单独的任务，以块的形式从内存获取数据发送到串行。寻找诸如循环缓冲之类的东西来避免锁定。
First calculate how many task switches you will have and compare with speed of your serial. Maybe it is just not possible to push this amount of data? Consider than
If serial is enough, than maybe go with cache? First write to memory and is separate task get data from memory in blocks send to serial. Look for things like circular buffering to avoid locking.
运行跟踪时是否需要实时行为？我的意思是，是否可以选择登录 RAM 直到缓冲区（几乎）已满，然后进入关键部分以防止应用程序进行任务切换和服务中断以及通过串行线路转储缓冲区。这将阻止应用程序的运行一段时间，但根据您正在运行的测试，它可能是可以接受的。
通过串行、USB 等进行的任何实时跟踪都会影响应用程序的行为，因此不确定您所测量的内容是否相关。
您可以做的另一件事（如果您还没有这样做）是使日志记录尽可能小，例如：每个任务切换 1 个字节，其中最高有效半字节是旧任务的任务 ID，最低有效半字节是任务 ID的新任务。这样您应该能够在 512KB 内存中处理大量任务切换。
Do you need real-time behavior when running the traces? I mean, is it an option to log into RAM until the buffer is (nearly) full, then enter a critical section preventing the application from task-switching and servicing interrupt and dumping the buffer over the serial line. This will block the operation of the application for a while, but depending on the test you're running it may be acceptable.
Any real-time tracing over serial, USB,... will influence the behavior of the application so it's not sure that what you are measuring is relevant.
Another thing you can do (if you don't already) is make the logging as small as possible, for example: 1 byte per task switch with the most significant nibble the task ID of the old task and the least significant nibble the task ID of the new task. This way you should be able to cover a lot of task switches in your 512KB of memory.