使用适合工作的正确工具：嵌入式编程
我对非常适合嵌入式编程的编程语言感兴趣。 特别是：
是否可以用 C++ 对嵌入式系统进行编程？ 还是使用纯C更好？ 或者只有在排除该语言的某些功能（例如 RTTI、异常和模板）时，C++ 才可以吗？
Java 在这个领域怎么样？
谢谢。
I'm interested in programming languages well suited for embedded programming.
In particular:
Is it possible to program embedded systems in C++?
Or is it better to use pure C?
Or is C++ OK only if some features of the language (e.g. RTTI, exceptions and templates) are excluded?
What about Java in this domain?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
是的，当然，即使在 8 位系统上也是如此。 C++ 与 C 的运行时初始化要求略有不同，即在调用 main() 之前，必须调用任何静态对象的构造函数。其开销（不包括您可以控制的构造函数本身）很小，但您必须小心，因为构造顺序未定义。
使用 C++，您只需为使用的内容付费（许多有用的内容可能是免费的）。也就是说，例如，一段同样可 C++ 编译的 C 代码通常不需要更多内存，并且编译为 C++ 时的执行速度不会比编译为 C 时慢。 C++ 的某些元素可能需要小心与，但许多最有用的功能只需很少或没有成本，却能带来巨大的好处。
可能，在某些情况下。一些较小的 8 位甚至 16 位目标没有 C++ 编译器（或者至少没有任何声誉的编译器），如果这是一个问题，使用 C 代码将提供更大的可移植性。此外，在资源严重受限的小型应用程序目标上，C++ 相对于 C 带来的好处微乎其微。 C++ 中的额外功能（主要是支持 OOP 的功能）使其适合相对较大且复杂的软件构建。
可接受的语言特性完全取决于目标和应用程序。如果您的内存有限，您可能会避免使用昂贵的功能或库，即使如此，它也可能取决于您缺少的是代码还是数据空间（在这些空间是独立的目标上）。如果应用程序是硬实时，您将避免使用这些功能和库类那些是不确定的。
一般来说，我建议如果您的目标是 32 位，请始终优先使用 C++ 而不是 C，然后削减 C++ 以适应内存和性能限制。对于较小的部件，选择 C++ 时要更加谨慎，但不要完全忽视它；它可以让生活更轻松。
如果您选择使用 C++，请确保您拥有支持 C++ 的良好调试器硬件/软件。用 C++ 构建复杂的软件相对容易，这使得一个像样的调试器更有价值。并非嵌入式领域中的所有工具都支持 C++ 或具有 C++ 功能。
我总是建议在 Embedded.com 上挖掘任何嵌入式主题的档案，它有大量文章，包括许多只是这个问题，包括：
关于 Java，我不是专家，但它有显着的运行时要求，这使得它不适合资源受限的系统。使用 Java 您可能会限制自己使用相对昂贵的硬件。它的主要好处是平台独立性，但可移植性不会扩展到不能支持 Java 的平台（有很多），因此可以说它的可移植性不如设计良好的具有抽象硬件接口的 C 或 C++ 实现。
[编辑] 顺便说一句，我刚刚在 TechOnline 时事通讯中收到此消息：在嵌入式应用程序中高效使用 C++
Yes, of course, even on 8bit systems. C++ only has a slightly different run-time initialisation requirements than C, that being that before main() is invoked constructors for any static objects must be called. The overhead (not including the constructors themselves which is within your control) for that is tiny, though you do have to be careful since the order of construction is not defined.
With C++ you only pay for what you use (and much that is useful may be free). That is to say for example, a piece of C code that is also C++ compilable will generally require no more memory and execute no slower when compiled as C++ than when compiled as C. There are some elements of C++ that you may need to be careful with, but much of the most useful features come at little or no cost, and great benefit.
Possibly, in some cases. Some smaller 8 and even 16 bit targets have no C++ compiler (or at least not one of any repute), using C code will give greater portability should that be an issue. Moreover on severely resource constrained targets with small applications, the benefits that C++ can bring over C are minimal. The extra features in C++ (primarily those that enable OOP) make it suited to relatively large and complex software construction.
The language features that may be acceptable depend entirely on the target and the application. If you are memory constrained, you might avoid expensive features or libraries, and even then it may depend on whether it is code or data space you are short of (on targets where these are separate). If the application is hard real-time, you would avoid those features and library classes that are non-deterministic.
In general, I suggest that if your target will be 32bit, always use C++ in preference to C, then cut your C++ to suit the memory and performance constraints. For smaller parts be a little more circumspect when choosing C++, though do not discount it altogether; it can make life easier.
If you do choose to use C++, make sure you have decent debugger hardware/software that is C++ aware. The relative ease with which complex software can be constructed in C++, make a decent debugger even more valuable. Not all tools in the embedded arena are C++ aware or capable.
I always recommend digging in the archives at Embedded.com on any embedded subject, it has a wealth of articles, including a number of just this question, including:
Regarding Java, I am no expert, but it has significant run-time requirements that make it unsuited to resource constrained systems. You will probably constrain yourself to relatively expensive hardware using Java. Its primary benefit is platform independence, but that portability does not extend to platforms that cannot support Java (of which there are many), so it is arguably less portable than a well designed C or C++ implementation with an abstracted hardware interface.
[edit] Concidentally I just received this in the TechOnline newsletter: Using C++ Efficiently in Embedded Applications
在嵌入式系统中，您编程所使用的语言通常取决于实际可用的编译器。
如果您的硬件只有一个 C 编译器，那么您将使用它。如果它有一个像样的 C++ 编译器，那么确实没有理由更喜欢 C 而不是 C++。
我敢说 Java 在嵌入式系统中并不是一个非常流行的选择。
More often than not in embedded systems, the language you're programming in is determined by which compiler is actually available.
If you're hardware only has a C compiler, that's what you're going to use. IF it has a decent C++ compiler than there is really no reason to prefer C over C++.
I would dare say that Java isn't a very popular choice in embedded systems.
如今的嵌入式编程涵盖了广泛的应用。
粗略地说，它从传感器/开关到完整的安全系统。
您应该根据复杂性和硬件资源来选择您的语言。
它是硬件（CPU，...），操作系统，协议，...旁边的选择之一
可能的选择：
Embedded programming these days spans a large range of applications.
Roughly, it goes from sensors/switches up to complete security systems.
You should base your language on the complexity and the hardware resources.
It is 1 of the choices next to HW (CPU,...), OS, protocols,...
possible choices:
沿着这些思路思考是件好事。编译时复杂性并不是什么大问题，但运行时复杂性却有资源成本。
C++ 促进了类/命名空间模块化（例如，在多个上下文中的方法
foo()）和实例模块化（成员字段bar属于多个对象），这两者在软件设计中是一个很大的优势。还有诸如 const、引用、静态转换和模板之类的功能，这些功能可以帮助强制实施约束，并且运行时成本很少或没有。我不会排除模板。它们考虑起来很复杂，您需要一个能够很好地处理它们的编译器，但资源成本几乎全部是编译时间——真正让您“付出代价”的是每次使用具有不同类参数的模板时，您生成一组新代码来实例化成员函数。但如果没有模板，您几乎肯定必须做同样的事情。此外，模板允许您在编译时而不是链接时实例化的单独文件中设计和测试一般情况下的库。只是为了澄清这一点：模板允许您拥有一个您测试的文件啊。然后将其与文件 Bh 或 Bc 一起使用以在编译时实例化它。 （库将被链接而不是编译，这使得它不太灵活——模板方法可以被优化，这样它们就不会引起函数调用。）我在嵌入式系统中使用模板来实现 CRC 代码和固定-数学要点：我可以测试通用代码，将其放入版本控制中，然后通过编写一个派生自模板或具有模板成员字段的简单类来多次重用它。典型的例子当然是STL。
RTTI 和异常：这些增加了运行时的复杂性。我不太清楚资源成本，但我预计 RTTI 会相当简单（只需添加一个类型标签，消耗额外的空间），而异常可能很糟糕，涉及堆栈展开。
虚拟函数：我曾经排除这些，因为内存+执行时间成本（最小但仍然存在），以及调试的复杂性，但它们允许您将对象彼此解耦。如果不使用虚函数，当一个类的实例（例如 Foo）需要执行与另一个类（例如 Bar）的实例关联的代码时，第一个类需要了解第二个类的所有信息（以编译 Foo）您需要对 Bar 中的所有方法进行静态链接）——这增加了很多紧密耦合。
动态内存分配：这是另一件大事（在 C 语言中也是如此），我们在我的公司像避免瘟疫一样避免它 - 不仅可能出现各种错误，而且最大的运行时成本是分配器/释放器，您必须愿意并且能够知道该成本是什么并接受它。
编辑：我喜欢在嵌入式世界中使用Java而不是C++。不幸的是，我的选择是有限的，而且运行时资源成本（代码大小、内存大小、垃圾收集时间限制）在我工作的空间中太高。我使用 Java 的原因不是因为它的运行时好处，而是因为它的运行时优势。事实上，它的软件设计更加简洁，工具也更好（天哪！重构！哇哦！）...对我来说关键在于两件事，这使得 C/C++ 相比之下感觉非常笨重：
一切都是对象，所有方法都是虚拟的，因此您可以严重依赖接口的抽象。
Java 中的接口/实现分离并不是这种笨重丑陋的
.c/.h文件分割问题，它使编译器变得如此缓慢。相比之下，我在 Eclipse 中使用 Java，它会在我编辑代码时自动编译代码。这是巨大的！我立刻就发现了我的大部分错误。在 C/C++ 中，我必须等待整个编译周期。有一天，我希望出现一种介于 C/C++ 和 Java 之间的语言，它可以提供 Java 在软件开发方面的优势，而不需要那些使 Java 对于桌面/服务器应用程序如此有吸引力但在大多数嵌入式世界中没有吸引力的附加功能。
It's good to be thinking along these lines. Compile-time complexity is not a big deal, but runtime complexity has a resource cost.
C++ facilitates class/namespace modularity (e.g. method
foo()in more than one context) and instance modularity (member fieldbarbelonging to more than one object), both of which are a big advantage in software design. There are also features likeconst, references, static casts, and templates, which can help enforce constraints and have little or no runtime cost.I would not exclude templates. They're complex to think about and you need a compiler that handles them well, but the resource cost is almost all compile time -- what's going to "cost" you is the fact that each time you use a template with different class parameters, you produce a new set of code to instantiate member functions. But you would almost certainly have to do the same thing without templates. Furthermore, templates allow you to design and test libraries for general circumstances, in separate files that are instantiated at compile time rather than link time. Just to clarify that: templates allow you to have a file A.h that you test. Then you use it with file B.h or B.c to instantiate it at compile time. (A library would be linked in rather than compiled, and this makes it less flexible -- template methods can be optimized out so they do not incur a function call.) I've used templates in embedded systems to implement CRC code and fixed-point math: I can test the general code, put it in version control, and then reuse it multiple times by writing a simple class that derives from a template or has a template member field. The classic example of course is STL.
RTTI and exceptions: these add run-time complexity. I don't have a good idea of the resource cost but I expect RTTI would be fairly simple (just adds a type tag, costing extra space) whereas exceptions are probably beastly, involving stack unwinding.
virtual functions: I used to rule these out because of the memory + executiontime costs (minimal but still there), as well as the complexity of debugging, but they allow you to decouple objects from each other. If you don't use virtual functions, when an instance of one class (e.g. Foo) needs to execute code associated with an instance of another class (e.g. Bar), then the first class needs to know everything about the second (to compile Foo you need to have static linkage to all the methods in Bar) -- this adds a lot of tight coupling.
dynamic memory allocation: this is another big thing (that is in C as well), which we avoid like the plague at my company -- not only are there all sorts of errors that can arise, but the big runtime cost is the allocator/deallocator, and you've got to be willing and able to know what that cost is and accept it.
edit: I would love to use Java instead of C++ in the embedded world. Unfortunately my choices are limited and the runtime resource costs (code size, memory size, garbage-collecting time constraints) are too high in the space that I work in. My reason for using Java is less because of its runtime goodies and more for the fact that its software design is much cleaner, and the tools are much better (OMG! refactoring! woohoo!)... the key to me seems to lie with two things, which make C/C++ feel very clunky in comparison:
that everything is an object and all the methods are virtual, so you can lean heavily on the abstractions of interfaces.
the interface/implementation separation in Java is not this clunky ugly
.c/.hfile splitting thing that makes compilers so slow. In constrast, I use Java in Eclipse and it automatically compiles the code right as I edit it. This is huge! I find most of my errors right away. In C/C++ I have to wait for a whole compile cycle.Someday I hope there will be a language between C/C++ and Java that provides the advantages of Java for software development, without requiring the bells and whistles that make Java so attractive for desktop/server applications but unattractive in most of the embedded world.
C 和 C++ 都可以在嵌入式系统上使用。如果您确实限制了您使用的 C++ 功能，那么它将使用与 C 大致相同的速度和空间。至于使用这些附加功能，这实际上取决于您的限制。例如，如果您正在制作一个实时系统，那么异常可能不是一个好主意，因为考虑到异常的传播时间以及异常可能传播的所有路径可能会使硬实时保证变得相当困难（尽管话又说回来，ACE/Tao 实时 CORBA 实现使用了异常）。虽然模板和 RTTI 可以生成更大的程序，但嵌入式系统存在很多变化，因此根据您的资源限制，这可能完全没问题，也可能不可接受。 Java 也是如此。 Java（从技术上来说，是带有 Java API 子集的 Java 编程语言）在 Android 上运行，例如使用 Dalvik VM。 J2ME 运行在各种嵌入式设备上。它是否适合您的应用程序，取决于您的特定限制。
Both C and C++ can be used on embedded systems. If you do limit the features of C++ that you use, then it is going to use roughly the same speed and space as C. As for using these additional features, it really depends on your constraints. For example, if you are making a real-time system, then exceptions might not be a good idea, simply because considering the propagation time for exceptions and all the paths through which exceptions can possibly propagate can make hard real-time guarantees quite tough (although, then again, the ACE / Tao real-time CORBA implementation uses exceptions). While templates and RTTI can lead to larger programs, there is a lot of variability in embedded systems, and so depending on your resource constraints, this could be perfectly fine or unacceptable. The same goes for Java. Java (well, technically, the Java programming language with a subset of the Java API) is running on Android, for example, using the Dalvik VM. J2ME runs on a variety of embedded devices. Whether it will or will not work for your application, depends on your particular constraints.
c是嵌入式系统中最常用的语言。
不过，我认为C++的未来在于嵌入式系统领域。我认为 C++0x 标准将在这方面有所帮助。因此，如果看到 C++ 在该领域得到更多使用，我不会感到惊讶。
c is the most common language used in embedded systems.
However, I think C++'s future lies in the embedded system domain. I think the C++0x standards will help in that resepect. So I wouldn't be surprised to see C++ used a lot more in this field.
我认为克利福德已经给了你一个很好的答案，但我会补充我的经验。正如所指出的，嵌入式系统的类型是主要驱动力。在国防/航空航天领域，C 和 Ada 是我遇到的最流行的嵌入式语言。尽管随着时间的推移，随着基于模型的开发在 Rhapsody 等工具中变得流行，我看到了更多的 C++。在职位列表中，看到对面向对象设计经验的要求也让我相信市场正在慢慢转向追随主流发展趋势。
如果你真的对嵌入式开发感兴趣，我会从 C 开始。它非常通用。几乎每个操作系统，包括 Integrity、Nucleus、VxWorks 和嵌入式 Linux 等实时操作系统，都有一个编译器和工具。您将学到的有关指针、内存管理等的知识...将至少在嵌入式世界中很好地转化为 C++ 开发。
至于Java，如果您对智能手机等移动平台的开发感兴趣，那么这是一个不错的选择（我想到的是Android）。但在实时操作系统的世界里，我还没有见过。
关于这一点，这引出了我的最后一点和建议。如果我想进入嵌入式编程（我 4 年前就这样做了），我会像上面提到的那样，专注于从低层次的角度学习 C。然后，我还将了解是什么让实时编程如此困难/不同。我发现下面这本书非常擅长教你像嵌入式程序员和应用程序开发人员一样思考。祝你好运！
嵌入式软件入门
I think you already have a great answer by Clifford, but I'll add my experience to it. As was pointed out, the type of embedded system is the main driver. In Defense/Aerospace, C and Ada are the most popular embedded languages I encounter. Although as time goes on, I am seeing more C++ as the model based development becomes popular with the tools such as Rhapsody. In the jobs listing, seeing requirements for Object Oriented Design experience also leads me to believe that the market is slowly shifting to follow the trends of mainstream development.
If you're really interested in embedded development, I would start with C. It is pretty universal. Almost every OS, including real time OS's like Integrity, Nucleus, VxWorks, and embedded Linux, has a compiler and tools for it. The things you'll learn about pointers, memory management, etc... will translate into C++ development well in the embedded world at least.
As for Java, if you're interested in development for mobile platforms like smart phones, this is a solid choice (Android comes to mind). But in the world of Real Time Operating Systems, I haven't seen it.
On that note, that brings me to my last point and advice. If I wanted to jump into embedded programming (which I did just 4 years ago), I would focus on learning C from a low level point of view as mentioned above. Then, I would also learn what makes real time programming so difficult/different. I found the book below quite good at teaching you to think like an embedded programmer vs. an application developer. Good luck!
An Embedded Software Primer
这实际上取决于您正在运行的硬件平台以及对您开放的软件平台。对于许多最近的嵌入式套件（围绕片上系统、一兆或两兆字节的 RAM、一些设备而设计），您确实需要一个小型操作系统来管理低级硬件，同时您可以专注于应用程序。您选择的操作系统会限制您可用的语言集。
当然可以在嵌入式领域使用 C++，但该语言的完整功能集需要大量工作才能正确移植。例如，eCos 是用 C 和 C++ 的结构方面的混合实现的；免费版本缺乏对 RTTI、异常和 STL 的支持，尽管有人致力于此（并且有可用的商业端口）。
同样，也可以使用 Java——我知道，我已经将 JVM 移植到了嵌入式环境；这并不有趣——尽管您通常会得到精简的 Java 语言配置，通常是基于 J2ME 的东西。
It really boils down to what hardware platform you're operating on and hence what software platforms are open to you. For a lot of recent embedded kit - designed around a system-on-chip, a megabyte or two of RAM, a few devices - you really want a small operating system to manage the low level hardware while you concentrate on your application. Your choice of OS then constrains your available language set.
It's certainly possible to use C++ in the embedded space, but the full feature set of the language takes a lot of work to port correctly. For example, eCos is implemented in a mixture of C and what you might call the structural aspects of C++; support for RTTI, exceptions and the STL are lacking in the free version, though there are people working on this (and a commercial port available).
Similarly, it's possible to use Java - I know, I've ported a JVM to an embedded environment; it wasn't fun - though you usually get a cut-down Java language configuration, often something based on J2ME.