(!C) 嵌入式平台开发
我很好奇 C 的替代品在嵌入式开发人员世界中有多受欢迎，例如 Ada...
我只使用过 C（带有一点汇编程序），但我的目标资源非常有限。 在这个空间中是否有其他地方的移动？ 机顶盒中的制胜法宝是什么？
如果！C 根本原因是什么？
- 编译器支持目标
- Trace\静态分析工具
- 其他...
谢谢。
I'm curious to see how popular the alternatives to C are in the embedded developer world e.g. Ada...
I've only ever used C (with a little bit of assembler), but then my targets have very limited resources. Is there a move else where in this space to something else? What is winning the ware in set top boxes?
If !C what was the underlying reason?
- Compiler support for target
- Trace \ static analysis tools
- other...
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（19）
Forth 对于嵌入式开发来说非常流行。
此外，虽然 Smalltalk 在嵌入式社区中可能并不流行，嵌入式开发 在 Smalltalk 社区中绝对很流行。
Forth is quite popular for embedded development.
Also, while Smalltalk is probably not popular in the embedded community, embedded development is definitely popular in the Smalltalk community.
当您说“嵌入式开发”时，请记住您必须考虑项目的规模。
当对微控制器或 ASIC 固件规模进行编程时，您往往会看到 C 和汇编占据主导地位。 嵌入式开发人员倾向于“专注于”这些语言，因为几乎每个嵌入式目标平台都可以使用这些语言的编译器。 如果您的项目从具有 PowerPC 内核的芯片迁移到具有 ARM 内核的芯片，您可以相当确信您的 C 代码的移植不会太困难。 有些芯片确实具有可用于其他语言的编译器，但通常它们在生成二进制文件的效率方面与 C 编译器不匹配。 由于嵌入式系统通常资源不足，系统设计人员希望使他们的代码尽可能高效（这也是您看到大量汇编语言代码的原因之一）。 我见过可用于 C++、Pascal、Basic 等语言的开发工具，但它们通常是小众工具，不够成熟，无法与可用 C 编译器的效率相匹配。 这些语言的调试工具往往比 C/汇编语言更难找到。
您还提到了机顶盒。 这种规模的嵌入式系统可以提供相当于 7-8 年前台式计算机的功能。 它们的可用 RAM、存储空间和处理能力使它们能够运行功能齐全的操作系统和高级语言的解释器。 在这些更强大的系统上，您仍然会看到使用 C 和汇编语言（用于驱动程序代码，如果没有其他的话），但其他语言（例如 Java、Lua、Tcl、Ruby 等）正变得越来越普遍。 使用解释性语言可以使将代码从一个平台移植到另一平台变得更加容易，只要该平台有足够的资源来处理语言解释器的开销。 任何直接与硬件（驱动程序）交互的低级代码通常仍然使用汇编或 C，因为高级语言并不总是有能力执行此类操作。 在嵌入式操作系统之上作为应用程序运行的任何内容通常都可以在模拟器或虚拟机内进行开发和测试，因此您会看到许多代码正在使用开发人员恰好熟悉的任何语言进行开发。
TLDR 版本： C 之所以流行，是因为它是一种几乎所有开发人员都熟悉的多功能语言。 汇编很受欢迎，因为它允许以其他方式困难或不可能的方式进行低级硬件访问。 Java 等解释型/脚本语言正变得越来越流行，但这些语言的解释器的资源需求对于某些嵌入式系统来说可能难以处理。 C 语言和汇编语言的开发/调试工具的质量和多样性也使这些选项具有吸引力。
When you say "embedded development", keep in mind that you have to consider the scale of the project.
When programming something on the scale of a microcontroller or the firmware for an ASIC, you tend to see C and assembly dominate the scene. Embedded developers tend to "specialize" in these languages since compilers for them are available for nearly every embedded target platform. If your project migrates from, say, a chip with a PowerPC core to a chip with an ARM core, you can be fairly confident that your C code will not be overly difficult to port over. Some chips do have compilers available for other languages, but typically they do not match the C compiler in terms of efficiency of the resulting binary. Since embedded systems are often low on resources, system designers want to make their code as efficient as possible (also one reason why you see a lot of assembly language code). I have seen development tools available for languages such as C++, Pascal, Basic, and others, but they are typically niche tools that are not mature enough to match the efficiency of the available C compilers. Debugging tools for these languages also tend to be harder to find than what is available for C/assembly.
You also mentioned set-top boxes. Embedded systems on this scale can pack the equivalent power of a desktop computer from 7-8 years ago. Their available RAM, storage space, and processing power allows them to run full-featured operating systems and interpreters for higher-level languages. On these more powerful systems you will still see C and assembly language being used (for driver code, if nothing else), but other languages (such as Java, Lua, Tcl, Ruby, etc) are becoming more and more common. Using interpreted languages makes porting code from one platform to another even easier, as long as the platform has sufficient resources to handle the overhead of the language interpreter. Any low-level code that interfaces directly with hardware (drivers) with still typically use assembly or C since high-level languages don't always have the capability to do this sort of thing. Anything running as an application on top of the embedded operating system can usually be developed and tested inside an emulator or virtual machine, and so you will see a lot of code being developed in whatever language the developer happens to be comfortable with.
TLDR version: C is popular because is it a versatile language that nearly all developers are familiar with. Assembly is popular because it allows for low-level hardware access in ways that would otherwise be difficult or impossible. Interpreted/scripted languages such as Java are becoming more popular, but the resource requirements of the interpreters for these languages may be too much for some embedded systems to handle. The quality and variety of development/debugging tools availability for the C and assembly languages also makes these options attractive.
也许与您正在寻找的 C 相比并没有很大的进步，但 C++ 在嵌入式项目中也相当受欢迎。
Perhaps not quite the large step from C you're looking for but C++ is also resonably popular for embedded projects.
我自己没用过，但是 Bascom 对于 AVR 来说相当流行微控制器。 它是一个基本 IDE，可让您非常轻松地与外围设备交互。 我遇到过成功使用它的硬件人员。
I haven't used myself, but Bascom is quite popular for AVR microcontrollers. It is a Basic IDE that lets you interact with the peripherals very easily. I've met hardware people that successfully use it.
是的。 Java 变得越来越流行 - 许多处理器添加了主要与 Java 和类似语言 (.net) 有关的指令。 此外，uclinux 在微控制器上运行，因此您几乎可以对一些较大的微控制器使用任何语言。
Basic 仍然很常见，组装也是如此。
您会在某些政府项目中看到 Ada。
一些工程师甚至将 Lua 和其他解释器放在他们的微型计算机上，以便他们的客户可以扩展功能。
但C仍然占据主导地位。
-亚当
Yes. Java is becoming more popular - many processors have added instructions that pertain primarily to Java and similar languages (.net). Also, uclinux runs on microcontrollers, so you can use practically any language for some of the larger micros.
Basic is still common, as is assembly.
You'll see Ada in certain gov't projects.
And some engineers are even putting Lua and other interpreters on their micros so their customers can extend the functionality.
But C is still dominant.
-Adam
90 年代初期，我使用 Intel PLM51 和 DCX51 操作系统在 8051 上进行了大量嵌入式开发。
PLM 是非常简单的语言 – 但非常强大
我们现在使用 C
In the early 90 I did a lot of embedded development on the 8051 using Intel PLM51 and the DCX51 operating system.
PLM is very simple language – but very powerful
We now use C
如果您从事智能卡领域的工作，则可以使用 Java Card。 是的，Java，在 8 位微处理器上。 实际上这有点有趣。 我可以在 Eclipse 中进行开发，在 PC 模拟器上进行测试（和调试！），并且可以确信它会在卡上运行相同的功能。 遗憾的是，对于嵌入式应用程序来说，Java 是一门糟糕的语言:)
If you work in the smartcard space, you get to use Java Card. Yep, Java, on an 8-bit micro. It's kinda fun, actually. I get to develop in Eclipse, test ( & debug!) on the PC simulator, and can be confident that it'll run the same on the card. It's just such a pity Java is a terrible language for embedded apps :)
我使用过 EC++ (嵌入式 C++）相当广泛。
此外，PICBasic 已在 PIC'ers 已经有很多年了。
I've used EC++ (Embedded C++) quite extensively.
Also, PICBasic has been popular with the PIC'ers for eons now.
由于客户的要求，我在军用航空电子设备的嵌入式项目中使用了 Ada。 有很多用于嵌入式开发的 Ada 工具，但大多数都非常昂贵。 就我个人而言，我只会使用 C。
I have used Ada in embedded project for military avionics because of customer requirements. There is lots of Ada tools for embedded development but most of it is very expensive. Personally I would just use C.
有一个用于 8051 的 Pascal 编译器
There is a Pascal compiler for 8051
JAL
JAL
有一群一群人致力于使 Lua 成为嵌入式工作的可行选择。 他们主要针对具有 256K 闪存和 64K RAM 或更好的 32 位 ARM，并且似乎对迄今为止的工作感到满意。
它们的部分灵感来自经典的 BASIC-Stamp，这是一个运行在功能中等的 PIC 中的 BASIC 解释器，带有该程序本身存储在串行 EEPROM 设备中。
在工作中，我仍在维护客户的嵌入式系统，该系统是用在 Zilog Z180 CPU 中运行的 BASIC 编译版本编写的。 1980 年代的技术无处不在，大部分系统仍然采用插座中的 24 槽 DIP 封装构建。 编译器在 Z80 模拟器中运行的 CP/M-80 下运行，Z80 模拟器本身在 Windows 内置的 MS-DOS 模拟器中运行。 除了令人惊讶的是，任何富有成效的事情都可以通过这种方式完成（并且您仍然可以购买 27C256 UV 可擦除 EPROMS，并且我近 20 年的数据/IO PROM 程序员仍然可以工作），我真的希望客户能够负担得起搬到新的硬件设计，以便系统可以用可维护的语言重写。
There is a group of folks working to make Lua a viable option for embedded work. They are targeting primarily 32-bit ARMs with 256K FLASH and 64K RAM or better, and seem happy with their work so far.
They are partly inspired by the classic BASIC-Stamp, a BASIC interpreter running in a moderately powerful PIC with the program itself stored in a serial EEPROM device.
At work, I am still maintaining a customer's embedded system that is written in a compiled flavor of BASIC running in a Zilog Z180 CPU. 1980's technology all around, with most of the system still built out of 24-bin DIP packages in sockets. The compiler runs under CP/M-80 running in a Z80 simulator, that itself runs in the MS-DOS simulator built into Windows. Aside from the shear amazement that anything productive can be done this way (and that you can still buy 27C256 UV erasable EPROMS, and that my nearly 20 year old Data/IO PROM programmer still works) I really wish the customer could afford to move to a new hardware design so the system could be rewritten in a maintainable language.
取决于微控制器，其中许多都有 C 语言，但编译器非常糟糕，汇编器通常很简单，而且性能最好、效率最高等。像 msp、avr 和 arm 这样的编译器对于 C 编译器以及我想要和的人来说都很好。使用C（取决于问题）。
我会坚持使用 C 或汇编程序，使用其他任何东西都会浪费内存、性能和资源。
Depends on the microcontroller, many of them have C but the compilers are horribly, assembler is usually easy and the best performing, most efficient, etc. Ones like the msp, avr, and arm are good for C compilers and for those I would and do use C (depending on the problem).
I would stick to C or assembler, you are wasting memory, performance, and resources using anything else.
Pascal、Modula2 也能正常工作。 本质上它们与 C 几乎相同，除了无法进行分配（尽管有些将其作为扩展）。
但核心问题将是任何 !C 编译器的问题：您更喜欢什么，更好的编译器/工具链还是首选语言。
尽管我最喜欢 Wirthian 语言，但我只是使用 C，并且接受后果，仅仅是因为工具链更好。
过去有过例子（Pascals，甚至是紧密编译的 Basics），但 C 大多是规范。 我一直不明白为什么。
Pascal, Modula2 work fine too. Essentially they are pretty much equivalent to C, except for the inability to do alloca (though some have that as extension).
But the core problem will be the problem with any !C compiler: what do you prefer, a better compiler/toolchain or the language of preference.
Despite I like the Wirthian languages most, I simply use C, and am living with the consequences, simply because the toolchain is better.
There have been examples in the past (Pascals, or even tightly compiled Basics), but C is mostly the norm. I never understood why.
我在一台运行一些令人难以置信的旧版本 python（1.4 或其他版本）的设备上工作。 没有办法调试它（除了打印调试消息），所以当你的代码遇到异常时，一切都会停止，你摸不着头脑一个小时。 每当您对正在运行的代码进行更改和升级时，都需要大约 10 分钟来解释和编译它。
不用说，我们放弃了这一点，并用运行 C 的微控制器替换了微控制器。
I worked on a device which ran some incredibly old version of python (1.4 or something). There was no way to debug it (other than printing debug messages) so when your code hit an exception everything would just stop and you scratched your head for an hour. Whenever you made a change and upgraded the code it was running, it took about 10 minutes to interpret and compile it.
Needless to say we scrapped that and replaced the microcontroller with one that ran C.
请参阅此相关问题：
实时系统使用哪些语言编程。
回答你的“为什么”问题，从政府/军事采购的角度来看，人们认为 Java（语言、平台等）是当今的通用语言，并且该语言的规模经济将会减少采购和维护成本。 人们还希望能够比学习一门新语言更快地有效地培训一名有能力的 Java 程序员成为一名合理的 Java RT/嵌入式程序员。 在我看来，这个理由是可疑的，但它确实回答了“为什么”的问题。
See this related question:
What languages are used for real-time systems programming.
In response to your "why" question, from the standpoint of government/military acquisition, there is a perception that Java (language, platform, etc...) is the lingua franca these days and that economies of scale in the language will reduce acquisition and maintenance cost. There's also a hope that one can efficiently train a competent Java programmer to be a reasonable RT/embedded programmer in Java faster than if they are required to learn a new language. This rationale is suspect, in my opinion, but it does answer the "why" question.
如果您将 iPhone 作为嵌入式平台，那么 Objective-C
If you include the iPhone as an embedded platform then Objective-C
考虑到我的手机上有多少次出现 Java 内存不足异常（大多数时候我做了一些远程有趣的事情），我会像蝙蝠逃离炎热的地方一样逃离 Java。
我听说 Erlang 是为手机而设计的。 我认为 Lisp 是一个很好的远程设备支持架构——如果设备能够处理运行时的话。
Considering how many times I've had a Java out-of-memory exception on my phone(most of the time I do anything remotely interesting), I'd run away from Java like a bat out of a hot place.
I've heard that Erlang was designed for use for cell phones. I think Lisp is a good architecture for remote device support- if the device cna handle the run-time.
许多需要廉价解决方案的自制用户和小公司发现 Tiny Tiger 和 Basic STAMP（使用 BASIC）满足了他们的需求。
A lot of home-brew users and small companies needing a cheap solution have found Tiny Tiger and Basic STAMP (using BASIC) meets their needs.