c++ - 微 Controller 上 C 和 asm 的替代品

Question

关闭。这个问题需要更多 focused .它目前不接受答案。












想改进这个问题？更新问题，使其仅关注一个问题 editing this post .

7年前关闭。




Improve this question




我的背景是这样的:嵌入式/C，然后是 C++，然后是更高级别的 OO 语言(Java、Scala、Ruby、Groovy 等)，现在我正在做一个涉及 MSP430 微 Controller 的小项目。同时，受此启发，我正在考虑一些潜在的宠物嵌入式系统项目(网格和/或 RTLS 看起来很吸引人)。所以我的问题目前主要集中在 MSP430 上，不过，顺便说一句，我也希望有一个更广泛的情况，涉及其他微 Controller 。

我有点惊讶地发现，经过这么多年，我可能需要回到 C 语言，包括它的宏、命名约定等等。我的大脑曾经被连接到 C，但那是很多很多年前的事了。

那么有哪些替代方案可用呢？

C++ 对我来说更合适，幸运的是，它似乎可行:http://stonepile.fi/object-oriented-approach-to-embedded-programming-with-c/

所以如果我要编写 C++，我只需要内联很多，尽可能避免使用虚函数，我应该很好，对吧？ (至少，在内存方面；他们没有在上述链接中对性能进行基准测试)。

但是，如果它这么简单，为什么人们要编写 C 语言呢？我肯定错过了什么。

上面的链接似乎也为 pico]OS 提供了一个包装库。有没有人在MSP430上用过picoOS，可靠性如何，需要多少资源？

对于一个简单的 MS430 项目，Energia 的优缺点是什么？我试过了，它看起来非常直观和自我记录，但它是否会在引擎盖下产生整洁的代码？例如，Energia 是否将未使用的 GPIO 初始化为关闭状态以节省能源？它会初始化未使用的中断吗？内存和速度方面的开销是多少？等等。

编辑:作为一个长期使用 Eclipse 的人，我很想使用 CCS。我看到可以将 Energia 草图导入 CCS。这是否意味着 CCS 完全支持 Energia 并且可以用作 Energia IDE？

有没有人用过Java Grinder http://hackaday.com/2014/02/10/java-grinder-spits-out-dspic-and-msp430-assembly-code/ ?这看起来很吸引人，但因为它输出的是一个汇编而不是 C/C++ 代码，所以提交它有点吓人:如果我被锁定在它里面并且它还没有准备好迎接黄金时段怎么办？如果它生成了 C 代码，如果它不起作用，我可以很容易地放弃它。

我提到了 Java，我的问题被删除了，因为不言而喻，除了像磨床一样的语法糖(我不介意语法糖!)，Java 不能在 MSP430 上运行。我想我会问另一个问题，Java 可以在哪里运行。这已经增长太久了。

还有哪些其他语言/环境可以填补低级和高级语言之间的空白？

Answer 1

您在这里似乎有几个问题，所以我将按照您编号的顺序进行。

大多数 micros 确实会运行 C++(假设制造商或开源项目提供编译器后端)，但是您必须警惕一些缺点。 C++ 的确定性较低，因为它提供了显着更高级别的抽象，人们可能不想要一个资源受限的嵌入式系统，而且总的来说也不需要它，因为嵌入式系统很少强大到足以有效地运行极其复杂的算法需要像 C++ 这样的高级语言。考虑到从嵌入式系统调试代码的难度，具有简单且易于跟踪的错误非常好，它也可能导致范围广泛的难以跟踪的错误。然而非常重要的是，C++ 标准库非常庞大，它们会使用过多的内存，并且很可能会浪费您有限的内存空间。因此，即使您确实使用 C++，您也无法使用任何使其强大的技术。

简单地说，我没有使用过它，但是像任何 RTOS 一样，如果你想要一个更高级别的接口(interface)，它会很有用，但是对于一个微型的 MSP430 来说，它似乎有点过分了，我无法想象你在那里做任何事情来保证ROTS，如果您需要多任务处理，最好自己提供简单的协作任务。

不幸的是，我也没有使用过那个平台，但是鉴于它是基于布线的，我猜它不提供高级别的硬件特定优化，如果你愿意的话，我建议将它用于你的大部分代码但调用需要时使用较低级别的库。然而，除此之外，它确实提供了一个可爱的、自我记录的界面，我强烈建议您尝试一下。如果您稍后切换到另一个 micro，它还将使您的代码更容易移植很多倍(许多公司的许多系统都提供接线绑定(bind))。

在这里你真的自己回答，它可能很强大但仍然很不成熟，我会纯粹因为这种锁定而避免它，直到它变得更加成熟，然后它值得重新评估。

Java 可以在更强大的 ARM 芯片上很好地工作，这是我看到它被广泛使用的唯一地方，并且在 micro 中相当有效地实现(ARM 专门为 Java 提供硬件支持)。除此之外，Java 不适合微观世界，在某个时候，它似乎可能会去某个地方，但这在很大程度上是未实现的，因为现在 C 喜欢是更小的微型世界的方式。

不幸的是，除了 C 之外并没有太多的选择。我最好的建议是使用更高级别的库，如布线。这会在不降低效率的情况下为您提供更好的接口(interface)，否则如果您需要高级别的抽象，使用微型微几乎没有意义。

总之，C 在这里做得相当好，我认为没有任何动机或努力来做出好的替代品。坦率地说，我在很大程度上也有这种感觉，C 从未成为一门糟糕的语言，它仍然非常适合小型系统，原因与以前相同。它提供动力、效率和可预测性。

我希望这会有所帮助，如果您有任何疑问，请评论我，我会看看我能做些什么来提供帮助。