[参考译文] TM4C1294NCPDT：管理器件配置

诺伯特

我特别对 JSON 这样的"动态"结构化协议感到失望，我认为这些协议是浪费空间和带宽的，应该加以禁止，至少是绿色和平运动的支持者应该予以禁止，以便使地球免于不必要的能源消耗！

EEPROM 对这些内容更加敏感、因为很难控制所有存储内容的实际长度- TM4C 内的 EEPROM 相对较小、 此外、"不是永恒的"、因此如果您需要频繁写入 EEPROM、您应该进行某种旋转、以便不总是在同一位置写入-对于不可预测的动态内容、甚至会更加困难。

当然、我假设您正在寻找某种通用存储。 但我的建议是：您能否预先定义要存储的内容、只需使用固定结构来保存这些值？

几年后、我们最终实现了两个不同的组：

-一个是公司中任何项目的通用信息，包含序列号、使用的总秒数、会话总数等信息。 对于这些基本信息、所有产品都使用固定的内存大小。

-另一组是"特定于产品"的存储序列、使用如下结构：
｛
浮点 PID1_CALIBRATION；
浮点 PID2_CALIBRATION；
int32 TEMP1_ALARM；
｝

如果您创建整洁的框架、创建新产品非常简单快捷、在器件之间读取/写入/传输这些设置。 当现有产品需要新项目时、新条目将添加到现有条目之后、以便当前 EEPROM 值在其现有位置仍然有效。

总之、我想说几个方面。 对我来说、基于 JSON 的适用于无限存储和带宽情况...

谢谢

布鲁诺

您好、Bruno、
我们非常感谢像您和其他人这样的人(不能在这里说出所有的人...) 凭借能够回答问题的四人行业丰富经验、有时 TI 员工没有相关经验。 我只是在谷歌一下 BSON 和 JSON 是什么。 :-)

尊敬的 Nobert：
很抱歉、我对这两种不同格式缺乏经验。 我找到了以下比较 BSON 和 JSON 格式的链接。 布鲁诺表示、与 BSON 格式相比、JSON 占用的空间要大得多。 考虑到 EEPROM 的大小有限、最好采用较小的格式、但这将如何影响检索数据和处理数据的效率、我真的无法评论。

stackoverflow.com/.../compare-json-and-bson

大家好、

我不想在控制器本身上使用 JSON： 它被缩进为一种输入格式(并且只是一个示例)、可以手动编辑、或者可以生成 Web 服务甚至桌面应用程序、并且可以用于生成存储在 MCU 站点 EEPROM 中的二进制数据。

我的问题是、这些属性可能会因产品而发生变化、我们希望避免使用自己开发的二进制协议。 这就是我寻找可能解决方案的原因。 我们已经有一个应用程序可以读取此类文件、如 XML 或 JSON、将其序列化为二进制流、该二进制流可下载到 EEPROM、除此之外、还可以生成 C++类、这些类可以实例化并访问上述属性。 例如(它们可能比有效源多得多的伪代码)：

输入 JSON 描述了一个具有值的属性

｛MaxSpeed：2000｝ 

生成的二进制文件位于偏移量为 X 的 EEPROM 中

串行器除了生成二进制文件之外、还生成 C++类、如下所示：

类控制器{
public：
unsigned int MaxSpeed() const {
return ReadIntEEPROM (X)；
}
private：
int startAddress；
} 

请注意、偏移量是在代码中生成的。 其他内容将添加到我们的项目中...  因此、我的目的是减少需要维护此类开发的大量工作、即使我们在启动过程中使用了这些操作、也会损失一些性能。

再次提到 BSON 和 JSON 只是一个例子

此致、

Norbert

诺伯特

让我看看我现在是否得到了这样的结果：您刚刚讨论了在外部器件(如 PC)和 TM4C 之间传输结构化数据的方法、是这样吗？ EEPROM 存储器件是您将在控制器内部单独处理的部件、是吗？

嗯、我们确实使用了我们自己的二进制协议-时间和痛苦使我们确信这是需要的。

对于该传输、您可能可以使用 C 语言中提供的某种 JSON 代码。我在将通用 C 代码移植到 MCU 世界方面没有太多经验、尤其是这样的事情、这肯定需要管理缓冲区... 但它可能比在 PC/其他设备端实现您自己的串行协议更容易。

当我们"创建自己的"时、我们可能会寻找您现在所寻求的解决方案-解决方案看起来都相似且非标准... 老实说、我不知道是否有一个。 例如、TI 使用一种协议来控制引导加载程序传输、而且似乎也不尊重任何形式的"通用规则"。

无论采用哪种方法、都可以考虑、即使对于 JSON 这样的人、您可能希望在二进制传输本身中包含某种校验和、否则您永远无法确定完整的1762字节是否正确到达 MCU。

布鲁诺