C语言 芯片为什么控制语言选择

m528fe3b  于 2023-03-17  发布在  其他
关注(0)|答案(8)|浏览(178)

我之前也问过嵌入式开发应该学什么语言,大多数嵌入式工程师都说c和c是必须的,但也指出要看芯片。
有人能澄清一下吗?这是一个编译器的问题还是什么?芯片有自己的特定编译器(如c编译器或c
编译器),这就是为什么你必须使用编译器知道的语言?是不是不可能在其他地方编码和编译它,然后直接在编译状态下刻录到芯片上?(我想我听到一个熟人说了一些类似的话)
我不知道这是如何工作的,因为很明显我不太了解嵌入式系统,也不知道它们是如何工作的。对于你们中知道的人来说,这可能是一个简单的答案。

zbdgwd5y

zbdgwd5y1#

也许,他们的意思是一些工具链不支持C++。是的,许多芯片和电路板都自带工具链。不同的处理器有不同的指令集,这意味着不同的编译器(或者更具体地说是一个不同的后端)。这并不意味着你总是要重新学习所有的东西。其中很多都是基于GCC的(通常被认为是移植性最强的编译器)。最终的可执行文件/映像格式也会有所不同,因此您需要一个特定的链接器。在“常规”计算机上(交叉)编译芯片,然后将其刻录到芯片上。然而,这并不意味着您可以使用针对桌面操作系统的典型编译器和链接器。

qhhrdooz

qhhrdooz2#

它在三种可能的方式中“依赖于芯片”:
1.一些非常受限的体系结构不适合C++,或者至少C提供了不适合这种体系结构的构造,因此没有提供优于C的优点。大多数8位设备属于这一类别,但决不是全部;例如,我看到过在MegaAVR上实现的有用的C代码。

  1. C编译器不支持某些设备,例如Microchip的dsPIC/PIC 24编译器仅支持C(第三方工具可能支持C)。
    1.芯片架构是专门为特定语言设计的;例如INMOS晶片机总是运行OCCAM。
    除了C、C++,其他可能的语言还有汇编、Forth、Ada、Pascal等,但C几乎无处不在;很少有芯片厂商会在没有C编译器的情况下发布一种新的体系结构或设备。对于其他语言,你通常要等到第三方决定开发一种,而这种等待对于利基体系结构来说可能是永远的。
    难道不能在别处编码编译,然后以编译状态直接烧录到芯片上吗?
    这就是所谓的交叉编译或交叉开发,是嵌入式系统常用的开发方法。大多数嵌入式系统缺乏操作系统、文件系统、性能和内存资源来自托管编译器,大多数开发人员希望在熟悉的面向用户的桌面操作系统中拥有一个复杂的开发环境,包括IDE、调试器等。
    我不知道这是如何工作的,因为很明显,我不知道很多嵌入式系统或他们如何工作。
    了解其中一些最新信息:
wsxa1bj1

wsxa1bj13#

是的,有许多体系结构存在C编译器,但没有C++编译器。您选择的处理器越小、功能越不全,这种情况就越有可能发生。
对于嵌入式开发,您几乎总是在“别处”编译代码,然后将其发送到芯片进行执行/调试。为不同于编译器本身构建的体系结构编译代码的过程称为“交叉编译”。

eeq64g8w

eeq64g8w4#

您是正确的:芯片在编译器上有不同的版本。大多数/许多现代芯片都有一个gcc端口;但不是全部。

nwnhqdif

nwnhqdif5#

“嵌入式”一词用于描述各种各样的硬件。大多数嵌入式软件工程包括编写C/C++代码,为目标微处理器生成二进制代码,但也有一些设备可能不是用编译后的二进制代码编写的。
一个例子是可编程逻辑控制器(PLC)。这些设备使用一种叫做“Ladder Logic“的语言。这是一种很棒的语言。我过去很喜欢用它工作。
另一件你可能会遇到的事情,就像我过去遇到的那样,是解释了BASIC模拟器的设备。希望这在今天很少见。

e5nszbig

e5nszbig6#

C/C是固件开发的一个很好的选择。所以你所做的软件将运行在嵌入式CPU/微控制器上。为了正确地编程设备,你需要知道语言和设备架构。
同样的代码可能不会在不同的设备上工作。所以,你必须学习语言,和设备架构。
另一种选择是FPGA,它不是微控制器。FPGA是具有特殊单元的设备,能够在任何类型的同步电路中转换自身,包括微控制器。FPGA是用硬件描述语言编程的,如verilog和VHDL。软件的“编译”(合成)版本称为网关件。
HDL也是用于ASIC设计的相同语言。正确学习语言的道路很长。所以我建议从C/C
与PIC形式的Microchip开始,这是一种低成本和高接受度的微控制器。
如果你打算做FPGA开发,用C/C++/pic获得的知识将是有帮助的和重要的,因为FPGA必须有嵌入式CPU/微控制器在里面。

f2uvfpb9

f2uvfpb97#

这并没有直接的科学依据,在很多情况下,这与特定公司的管理和政策有关。
有些公司被迫创建一个交钥匙系统,强迫你购买该系统并支付维护费用,它把个人开发者拒之门外,但有许多公司和特别是政府机构更喜欢这种模式,因为支持往往更好,你往往可以推动他们的产品方向,以满足你的需求。
其他公司没有员工或人才,将解决方案外包,有时候他们会拿走任何他们能得到的东西。你可能最终得到一个一次性开发的工具,在承包商离开后再也不会更新或修复,或者如果修复了,那就是别人的补丁工作。赚钱需要钱,但如果你在销售产品之前就把钱花光了,你仍然会失败。
有时你有公司,既有一个员工,维护他们的内部必须从他们那里购买工具,并有个人,也有助于开放的工具,如gcc。
有时候,公司的政治或管理层中有一些人对世界必须是什么样的有着强烈的看法,他们只允许为特定的语言开发工具;或者,他们可能属于某个公司,或与该公司合作,或就像某个公司一样,该公司拥有特定的语言,而这种芯片产品只是为了支持该语言。
除此之外,还有内存空间、指令集的质量和效率以及编译器的友好性等非常真实的的技术问题。有些架构对于汇编程序来说可能很好,但更高级的编译代码会过快地消耗有限的内存资源。
特别是GCC内部存在很多问题(不是作为一个人,而是软件/源代码本身)。我挑战你写一个后端,即使有教程在那里。一个公司需要专门的人才,以便创建,然后年复一年地维护GCC后端,否则你就会被抛弃。如果你的芯片架构不是32位或更大,你已经在与gcc打一场必败之战,你的芯片架构可能是编译器友好的,但只是对流行的编译器设计不友好。
在不久的将来,llvm将作为相对于gcc的交叉编译器大放异彩,因为它还没有构建这个内部块,也许因为内部的guts本身就是一个定义的语言/系统,它可能永远不会遭受gcc所发生的事情。随着越来越多的人适应llvm,我们将看到许多体系结构移植到它上面。msp430后端是专门用来演示您可以在一个下午添加一个目标的。一些有动机的人可以把我们大多数人听说过的所有目标都移植到llvm上。而且你不必构建一个交叉编译器,它总是一个交叉编译器。我之所以提到llvm,是因为现在已经为那些遭受坏工具之苦的目标打开了恢复的大门。
一些公司,特别是微控制器公司,我可以并且将会使编程接口成为专有的,因此您必须使用他们的编程工具(或者破解它,抓住机会发布这些结果,或者猫捉老鼠地改变它来打败你)。而且他们可能只为Windows开发了工具,让Linux和苹果的人悬在风中。或者,他们使它只加载由他们的工具生成的二进制文件,在这里,你可能会再次破解二进制格式,允许一个替代编译器,他们可能会或可能不会击败你。
尽管存在技术问题,但最大的问题是公司的政治、管理、营销团队以及工程人员的人才供应或缺乏。底线是,遵循美元而不是技术或科学来理解为什么支持这种语言而不支持那种语言,或者对这种语言的支持是好的、坏的或边缘的。
作为所有这一切的结果,该学习什么语言呢?从至少三种不同架构的汇编语言开始。然后是C,如果你觉得你真的需要C++。C和汇编语言是你的主要嵌入式语言(取决于你对嵌入式的定义)。不,我们写汇编程序主要是为了初始化 Boot 代码和支持C,编译器无法创建的中断材料或特殊指令。在微控制器等场合,由于各种原因,如工具,有限的芯片资源,即使你不使用汇编程序,知道它会使你成为一个更好的高级程序员。

你确实需要决定你对嵌入式的定义是什么,它是一个应用程序的API和库调用吗?嵌入式linux系统(与桌面系统上的相同程序/调用无法区分)。或者在频谱的另一端,您正在谈论可能具有256或1024字节的微控制器(不是百万或千兆,而是字节)的程序空间?还是介于两者之间?大多数“嵌入式”的人更接近于操作系统上应用程序的API调用(RTOS、Linux、Wince等),而不是深度嵌入的,所以这意味着C,也许是C++(总是能够回落到C),试图避免Python和其他占用资源的脚本语言。

7fyelxc5

7fyelxc58#

一些8位部件不能有效地从堆栈访问数据。自动变量和参数被静态分配,而不是使用堆栈来传递参数;通常,链接器在内存的一端为main()分配自动变量,然后为main调用的函数分配变量,而不分配其他变量,然后为这些函数调用的函数分配变量,而不分配其他变量,以此类推。这将相当容易地产生最佳分配,但需要注意以下几点:
1.递归只能通过添加代码来显式地将变量复制到某种堆栈安排上来支持;在许多编译器中,根本就不支持它。
1.如果一个函数看起来“可能”调用另一个函数,链接器会假设它在所有情况下都可以这样做(例如,当'foo'调用'bar'时,它的一个参数可能总是有一个值,这样'bar'就不会调用'boz',但链接器不会知道)。
1.对具有特定签名的函数指针的任何调用都将被视为对所有具有相同签名且地址已被获取的函数的调用。
1.如果对一个函数的多个参数的求值需要进行额外的函数调用,则通常必须悲观地分配额外的临时存储器,即使参数存储器的最佳放置可以避免这种情况。
有许多类型的C程序,上面的限制根本不会造成任何问题,还有更多的程序,它们造成了麻烦,但不是一个巨大的麻烦(例如通过添加伪参数或返回值以确保不同类的间接调用函数具有不同的签名)。不幸的是,由C到C预编译器生成的代码几乎总是涉及其调用图不能被合理地推测的函数指针,因此在这样的平台上使用C即使不是不可能也是很困难的。

相关问题