3

在我应该为嵌入式开发学习哪种语言之前，我已经问过这个问题。大多数嵌入式工程师说c和c++是必须的，但也指出这取决于芯片。

有人可以澄清吗？是编译器问题还是什么？芯片是否带有自己特定的编译器（如 ac 编译器或 c++ 编译器），这就是为什么您必须使用编译器知道的语言的原因？难道不能在别处编码编译，然后直接以编译状态烧录到芯片上吗？（我想我听到一个熟人说过这样的话）

我不确定这是如何工作的，因为显然我不太了解嵌入式系统或它们是如何工作的。对于那些知道的人来说，这可能是一个简单的答案。

4

8 回答 8

6

可能，它们意味着某些工具链不支持 C++。是的，许多芯片和电路板都带有自己的工具链。不同的处理器有不同的指令集，这意味着不同的编译器（或者更具体地说是不同的后端）。这并不意味着您总是必须重新学习所有内容。其中许多基于 GCC（通常被认为是移植最多的编译器）。最终的可执行文件/图像格式也各不相同，因此您需要一个特定的链接器。最有可能的是，您将在“常规”计算机上（交叉）编译芯片，然后将其刻录到芯片上。但是，这并不意味着您可以使用针对桌面操作系统的典型编译器和链接器。

于 2010-07-18T05:49:08.290 回答
4

它以三种可能的方式“取决于芯片”：

  1. 一些非常受限的架构不适合 C++，或者至少 C++ 提供了不适合此类架构的结构，因此与 C 相比没有任何优势。大多数 8 位设备都属于这一类，但绝不是全部；例如，我已经看到了在 MegaAVR 上实现的有用的 C++ 代码。

  2. C++ 编译器不支持某些设备。例如，Microchip 的 dsPIC/PIC24 编译器仅支持 C（第三方工具可能支持 C++）。

  3. 芯片架构专为特定语言设计；例如，INMOS Transputers 总是运行 OCCAM。

除了 C、C++，还有汇编程序、Forth、Ada、Pascal 等等，但 C 几乎无处不在；很少有芯片供应商会从一开始就发布没有 C 编译器的新架构或设备。对于其他语言，您通常必须等到第三方决定开发一种语言，而对于小众架构来说，这种等待可能是永远的。

难道不能在别处编码编译，然后直接以编译状态烧录到芯片上吗？

这就是所谓的交叉编译或交叉开发，是嵌入式系统常用的开发方法。大多数嵌入式系统缺乏操作系统、文件、性能和内存资源来自托管编译器，大多数开发人员希望在熟悉的面向用户的桌面操作系统中使用带有 IDE、调试器等的复杂开发环境。

我不确定这是如何工作的，因为显然我不太了解嵌入式系统或它们是如何工作的。

了解其中一些内容：

于 2010-07-20T22:42:06.023 回答
3

是的，有许多架构都存在 C 编译器，但 C++ 编译器不存在。您选择的处理器越小，功能越少，这种情况发生的可能性就越大。

对于嵌入式开发，正如您所说，您几乎总是在“其他地方”编译代码，然后将其发送到芯片进行执行/调试。为不同于编译器本身的架构编译代码的过程称为“交叉编译”。

于 2010-07-18T05:49:07.100 回答
3

你是对的：芯片在编译器上有变化。大多数/许多现代芯片都有一个 gcc 端口；但不是所有的。

于 2010-07-18T05:54:16.057 回答
1

没有直接的科学原因。在很多情况下，它与特定公司的管理和政治有关。

一些公司被迫创建一个交钥匙系统并强迫您购买该系统并支付维护费用。它锁定了个人开发人员，但有许多公司和尤其是政府机构更喜欢这种模式，因为支持通常要好得多，而且您通常可以推动他们的产品方向以满足您的需求。

其他公司没有员工或人才，将解决方案外包，有时会尽其所能。您最终可能会得到一个一次性开发的工具，该工具在承包商离开后再也不会更新或修复，或者如果它被修复，它是其他人的修补工作。赚钱需要钱，但如果你在卖掉你的产品之前用光了钱，你仍然会失败。

有时，您的公司既有维护内部人员的公司，必须从他们那里购买工具，也有个人也为 gcc 等开放工具做出贡献。

有时，公司的政治或管理人员对世界必须如何有强烈的看法，并且只允许为特定语言开发工具。或者，它们可能由具有特定语言的公司拥有或与之合作，或者就像具有特定语言的公司一样，而这种芯片产品只是为了支持该语言。

除此之外，还有内存空间、指令集的质量和效率以及它对编译器的友好程度等非常现实的技术问题。有些体系结构可能适合汇编程序，但更高级别的编译代码会过快地消耗有限的内存资源。

特别是 Gcc 在内部有很多问题（不是作为一个人，而是软件/源代码本身）。我挑战你写一个后端，即使有教程。一家公司需要专门的人才来创建并年复一年地维护一个 gcc 后端，否则你会被抛弃。如果您的芯片架构不是 32 位或更大，您已经在与 gcc 打一场失败的战斗，您的芯片架构可能对编译器友好，但对流行的编译器设计不友好。

在不久的将来，llvm 将作为一个相对于 gcc 的交叉编译器而大放异彩，因为它还没有构建这个内部块，也许因为内部胆量本身就是一个定义的语言/系统，它可能永远不会遭受 gcc 发生的事情。随着越来越多的人对 llvm 感到满意，我们将看到许多架构被移植到它。msp430 后端专门用于演示您可以在一个下午按字面意思添加目标。到下个月底，一些有动力的人可能会将我们大多数人听说过的所有目标都移植到 llvm。而且您不必构建交叉编译器，它始终是交叉编译器。我只提到 llvm 是因为现在为遭受不良工具恢复的目标敞开了大门。

一些公司，尤其是微控制器，可以并且将会使编程接口成为专有的，因此您必须使用他们的编程工具（和/或破解它并抓住机会发布这些结果，或者他们的猫捉老鼠改变它以击败您） . 他们可能只为 Windows 制作了工具，而让 linux 和苹果的人望而却步。或者他们这样做，以便它加载的唯一二进制文件是由他们的工具生成的二进制文件，在这里你可以再次破解允许备用编译器的二进制格式，它们可能会或可能不会打败你。

尽管存在技术问题，但最大的问题是公司的政治、管理、营销团队以及工程人员的人才供应或缺乏。最重要的是，遵循美元而不是技术或科学来理解为什么支持这种语言而不是那种语言，或者对这种语言的支持是好的、坏的或边缘的。

作为所有这一切的结果，要学习什么语言？从至少三种不同架构上的汇编程序开始。如果你觉得你真的需要它，然后是 C，然后是 C++。C 和汇编程序是您用于嵌入式的主要语言（取决于您对嵌入式的定义）。不，我们编写汇编程序主要用于初始引导代码并支持编译器无法创建的 C、中断内容或特殊指令。在诸如微控制器之类的地方，出于各种原因（例如工具、有限的芯片资源等）使用汇编程序可能非常有意义。即使您不使用汇编程序，知道它也会使您成为更好的高级程序员。

您确实需要确定您对嵌入式的定义是什么。它是（n 嵌入式）Linux 系统上的应用程序的 api 和库调用（与桌面系统上的相同程序/调用无法区分）。或者在频谱的另一端，您是在谈论具有 256 或 1024 字节（不是兆或千兆，而是字节）程序空间的微控制器？还是中间的东西？与深度嵌入式相比，大多数“嵌入式”人更接近操作系统（rtos、linux、wince 等）上应用程序的 api 调用，因此这意味着 C，也许是 C++（总是能够下降）回到 C），试图避免使用 python 和其他脚本语言，它们是资源消耗。

于 2010-07-31T04:56:55.700 回答
1

术语“嵌入式”用于描述范围广泛的硬件。大多数嵌入式软件工程将包括编写 C/C++ 代码以生成用于目标微处理器的二进制文件，但您可能使用的某些设备未使用已编译的二进制文件进行编码。

一个例子是可编程逻辑控制器 (PLC)。这些设备使用一种称为“梯形逻辑”的语言。这是一门美妙的语言。过去我很喜欢使用它。

与我过去一样，您可能会遇到的另一件事是解释了 BASIC 仿真器的设备。希望今天很少见。

于 2010-07-18T13:15:06.233 回答
1

C/C++ 是固件开发的一个很好的选择。因此，您制作的软件将在嵌入式 CPU/微控制器上运行。为了对设备进行适当的编程，您需要了解语言和设备架构。

相同的代码可能无法在不同的设备上运行。因此，您必须学习语言和设备架构。

另一种选择是 FPGA，它不是微控制器。FPGA 是具有专门单元的设备，能够在任何类型的同步电路中进行自我转换，包括微控制器。FPGA 使用硬件描述语言（如 verilog 和 VHDL）进行编程。该软件的“编译”（合成）版本称为网关件。

HDL 也与用于 ASIC 设计的语言相同。正确学习语言的道路很长。所以我建议从带有 pic 形式 Microchip 的 C/C++ 开始，它是一种低成本且被高度接受的微控制器。

如果您打算进行 FPGA 开发，那么使用 C/C++/pic 获得的知识将很有帮助且很重要，因为 FPGA 必须在内部嵌入 CPU/微控制器。

于 2010-07-30T21:34:58.067 回答
0

某些 8 位部分无法有效地访问堆栈中的数据。自动变量和参数是静态分配的，而不是使用堆栈来传递参数；通常，链接器在内存的一端为 main() 分配自动变量，然后为 main 调用的函数分配变量，然后为这些函数调用的函数分配变量，仅此而已，等等。这将相当容易地产生最佳分配，但需要注意一些警告：

  1. 只能通过添加代码以将变量显式复制到某种堆栈排列上来支持递归；在许多编译器中，根本不支持它。
  2. 如果一个函数看起来“可能”调用另一个函数，链接器将假定它在所有情况下都可以这样做（例如，当 'foo' 调用 'bar' 时，它的一个参数可能总是具有这样的值'bar' 不会调用 'boz'，但链接器不会知道）。
  3. 任何对具有特定签名的函数指针的调用都将被视为对所有具有相同签名且地址被占用的函数的调用。
  4. 如果对一个函数的多个参数的评估需要进行额外的函数调用，则通常必须悲观地分配额外的临时存储，即使参数存储的最佳放置可以避免这种情况。

有许多类型的 C 程序，上述限制完全没有问题，还有更多类型的 C 程序会造成麻烦但不是很大（例如，通过添加虚拟参数或返回值来确保不同类别的间接调用函数有不同的签名）。不幸的是，由 C++ 到 C 的预编译器生成的代码几乎总是涉及无法合理预测其调用图的函数指针，因此在这样的平台上使用 C++ 即使不是不可能也很困难。

于 2010-08-02T16:03:31.700 回答