Arm 是否有可能为32位微控制器（无操作系统）开发嵌入式c中的ASN.1协议？

是否有可能为32位微控制器（无操作系统）开发嵌入式c中的ASN.1协议

我正在使用ARM micro（32位）和cubesuite编译器

Maasi

这当然是可能的：ASN.1标准化了协议符号语法（X.680-X.683）和编码（X.690-X.696），尽管此列表似乎缺少八位字节编码规则（X.696）

它实用吗？这有点可疑。如果您正在编写自己的协议，那么您可以自由设计一些可以在硬件或固件中实现的内容，而无需使用外部工具。另一方面，支持当前标准（如LTE）更难：协议相当复杂

---

如果您有这种设计自由，您可能会发现非ASN.1选项更容易实现。ASN.1的主要优点之一是工具支持生成API。否则，编码规则就足够复杂，手工实现可能非常容易出错。

您可以尝试使用该库。它可以解析和编码ASN.1数据，不使用任何malloc，并且针对嵌入式平台。

我可以知道为什么会出现这种情况吗？这个问题尚不清楚。信息太少，不清楚你在问什么。关于你所写的代码，你有什么特别的问题吗？自己做一些调查。无意冒犯，但是：如果你对这两个主题都足够了解，你应该能够自己回答这个问题。请注意，这是一种描述语言，而不是协议。请注意，没有“嵌入式C”。只有最新版本：2011，又名C11。@Olaf，本质上，maasi是在询问是否有任何可用的ASN.1工具集（OSS Nokalva、目标系统等）具有运行时库，这些库不假定其下有POSIX或Win32操作系统。这样的操作系统将提供诸如

read（）

，

write（）

，更重要的是

malloc（）

，这些例程通常在嵌入式平台上不可用。@bazza:Late comment。然而，我不认为总是需要FS，但我同意他们可能会使用

malloc

&friends。但是，由于OP使用32位MCU，它不像在较小的MCU上那样不可能/不典型地可用/可实现。这不需要（完全成熟的）操作系统（在这样的平台上，小型RTO通常是有利的）。然而，他本应该亲自检查一下自己。鉴于问题过于广泛、不明确和/或要求场外资源。显然，它已经被抛弃了。我经常认为，在没有动态内存分配的嵌入式平台上，任何类型的复杂数据类型都将是一个挑战。无论是在ASN.1、JSON还是其他版本中，如果不实现

malloc（）

/

free（）

，事情都会变得非常困难，除非人们开始将自己限制在语法的子集（例如，没有可变长度数组，没有可扩展性等）。@bazza：对不起，这不是真的。如果只是为了内存分配，那么还有其他方法来维护可扩展的数据结构，其中一些方法甚至对提供

malloc

&friends的系统很有用。序列化本身并没有太大的不同。如果你只习惯于使用外部工具来实现这一点，事情可能会有所不同，但这是一个安慰的问题。@Olaf，是的，我确实指的是使用外部工具的困难。我使用的一个ASN.1工具集允许一个人提供自己的malloc/free实现，我的观点是，如果一个人必须这样做，那就需要做更多的工作。拥有一个操作系统会让事情变得简单很多@巴扎：不必绑定到操作系统，只留下自己创建的bug更有趣，而且（通常）不那么令人沮丧：-）。而且——糟糕透了——我向你保证，非常昂贵的库/工具不能保证更少的错误。有经验的开发人员可以更快地实现许多功能，而不是让这样的库运行并集成到您的系统体系结构中（或者按照该库的设计者认为是个好主意的方式采用您的体系结构…。@Olaf，的确如此！这是一个系统的复杂性、裸机软件开发所需的时间、成本和风险之间的平衡。如果系统有很多事情要做，没有什么比能够使用一个人已经信任的库更好的了。是的，我在商用ASN.1工具和库中发现了bug，但我很幸运，我所从事的项目有足够的bug，能够为支持成本提供资金。我希望谷歌已经做了一些好的开源ASN1工具，而不是谷歌协议缓冲区。。。