logging - 微 Controller 上的错误记录

标签 logging resources embedded queue error-code

我有一个一般性的问题。我在微 Controller 上记录错误。但是微 Controller 的资源比 Windows 计算机更有限。 在我的例子中,我将 64 个错误代码保存在一个队列中,由 FreeRTOS 管理。我选择了 64,因为资源有限。

我的问题是:当这个队列已满时我该怎么办?

客户端通过 USB 连接到微 Controller ,负责读取这些错误代码,从而将它们从队列中移除。但是当客户端不这样做时,队列会在64个错误码后变满。

我应该从队列中删除最早的错误并用最新的替换它吗?还是只要队列已满,我就应该保存未读的错误代码并丢弃新的错误代码?

请说说你的看法,为什么?

提前感谢您的建议。

最佳答案

不要担心 64 与任何其他大小。无论大小,您最终都需要做出这个决定,因为主机可能决定永远不读取队列。

正确的方法取决于您的系统如何工作以及您记录的错误类型。

保持第一个记录的好处:如果您的系统在出现问题时会级联成许多其他故障,那么记录第一个错误将有助于确定导致错误的原因链发生。

保持第一个记录的弱点:根据主机决定读取错误的时间,代码可能是 1 分钟前或 1 周前的,没有人知道。正如 Ian 的回答说明,可以向主机提供错误计数,知道它丢失了错误。

保留最后记录的好处:如果您的错误之间存在很大的独立性,那么最早的错误可能并不重要,只有最近的错误才能很好地了解当前的情况设备状态。

保留最后记录的缺点:与保留第一个的好处相反。您可能会丢失所有错误的根本原因。

因此,您必须查看您的设备可能产生的错误类型,并决定哪种技术最有可能对您的用户有用。

关于logging - 微 Controller 上的错误记录,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12859201/

相关文章:

c - 使用c中的文件操作写入文本文件时获取空格

c - 嵌入式设备与远程服务器通信的协议(protocol)架构

Azure Databricks 和日志分析设置需要重新启动或重建吗?

python - 根记录器忽略记录器级别

java - 可执行jar看不到图像

embedded - 用于在嵌入式 CPU 和 PC 之间进行通信的协议(protocol)

logging - 是否有一种工具可以轻松地以聚合方式从 AWS Elastic Beanstalk 搜索 S3 中每小时轮换的日志?

database - 有效地跟踪多个日志文件

c++ - 来自资源数据的 C/C++ 消息框

c++ - IDC 是什么意思?