将来是否可以用C ++为PIC微控制器编写代码?


8

使用C ++编码PIC是否有可能?是否有任何硬件限制使我们无法使用C ++?当我们使用C ++而不是C时,生成的.hex文件的大小和程序的运行时间增加了多少?在当前的PIC中实际上可以使用C ++吗?有没有未来的计划或正在进行的发展?


我认为这是有可能的,而且仍然将有可能,但是AFAIK不建议这样做,因为它实现的高级结构和功能不适合与硬件高度相关的编程
clabacchio


2
因为答案是“是的,已经有C ++编译器”,所以我要让这一立场成立,但是将来您应该意识到Stack Exchange问​​题应该是关于可验证的事实,而不是关于未来的假设。
凯文·维米尔

2
@clabacchio:不一定正确。在C ++中,您只需为使用的东西付费。见我的答案在:electronics.stackexchange.com/questions/3027/...
Rocketmagnet

“ PIC”是无用的概括。在某些低端PIC(例如10F200)上,几乎无法使用C。有传言称,目前在某些高端PIC(32MX系列)上使用C ++,当然,没有技术原因不能使用C ++。因此,更好地专注可能会提供更多有用的答案,目前每个人实际上都在回答另一个问题。
Wouter van Ooijen 2012年

Answers:


17

使用C ++编码PIC是否有可能?

是的,现在有可能。对于dsPIC,有IAR Systems C ++编译器(尽管它很旧并且不受支持)。

另一种选择是使用C ++到C的转换器。使用预构建步骤,将C ++转换为C,然后将(讨厌的)C提供给常规C编译器。看一下LLVMComeau的C ++编译器都可以做到这一点。Comeau的价格仅为50美元,但可能需要一些努力才能使整个工具链和库正常工作。

是否有任何硬件限制使我们无法使用C ++?

简短的回答,不,没有硬件限制。长话大说,C ++肯定会鼓励使用堆和/或堆栈,而内存有限的小型MCU会遇到困难。

他们为什么要在堆/堆栈上挣扎?原因有两个:A)许多MCU的RAM有限,肯定不足以容纳堆,而不足以容纳堆栈。B)许多MCU不能很好地处理指针,因此在堆栈上使用变量确实会降低性能。

当人们问到在MCU上使用C ++时,我发现将C ++与C进行比较很有建设性。关于(仍然是)关于MCU上的C的问题完全相同。人们过去常常不赞成这个主意。256字节RAM MCU上的高级语言 不可能。但是现在我们都知道这是可能的。我已经为PIC12写了C语言。没问题。可能是因为A)软件开发人员知道他们必须加倍小心:不要使用malloc()等。B)专门为MCU编写的编译器。编译器在分配内存时也要格外小心,它不会尝试创建堆,也可能不会创建堆栈。有些C编译器根本不允许您编写绝对需要堆栈的可重入(递归)代码。

知道可以为MCU编写C,因此相同的答案也适用于在MCU上编写C ++的问题。只要编译器了解目标设备的局限性,并且用户也了解该语言,就真的没有问题。在C ++中,您只需为使用的东西付费。完全有可能编写C ++(包含对象和所有内容)来产生与使用C时所获得的asm输出完全相同的输出。

现在,PIC32无疑可以应付C ++。它们具有高达64kB的RAM,并且基于MIPS内核,该内核是一个适当成长的32位处理器。它可以处理指针,堆栈以及PC。确实,有一些基于MIPS的PC(或者至少是以前的MIPS)。

可悲的是,围绕C ++的理解如此之多。即使是非常有经验的编码人员似乎也不知道该语言如何工作。请参阅我的答案,以了解C ++为什么适用于嵌入式CPU。

当我们使用C ++而不是C时,生成的.hex文件的大小和程序的运行时间增加了多少?

正如我所说,可能没有区别。Bjarne Stroustrup对一堆C / C ++编译器进行了比较,以比较许多操作的时间和空间性能。结果差异很大。在某些情况下,C ++的速度变慢而变大,在某些情况下,速度变慢而变小,或者速度越来越大,甚至变得越来越快!因此,您的问题的答案是它在很大程度上取决于编译器,但总的来说,它根本不需要任何改变。有关更多详细信息,请参见有关C ++性能技术报告。

有没有未来的计划或正在进行的发展?

我不知道 我确实知道Microchip C32编译器是开源的,您可以下载源代码。我也知道,与我一起工作的人实际上在网上找到了一些指令,并设法使编译器编译C ++代码。但是他在能够为我建立合适的工具链之前就离开了公司。


更新

Microchip现在为其PIC32系列嵌入式MCU提供了一个C ++编译器



可以从IAR网页上获取:“旧版产品:用于dsPIC的IAR嵌入式工作台是旧版产品。IARSystems无法对其进行更新,因此无法为其购买支持和更新协议。”
杰森S

我知道IAR产品很棒,但不幸的是非常昂贵,而且看起来“很旧”。我知道C ++在任何平台上都是可行的,只要您不使用所有功能。但是,它确实为类增加了额外的抽象层的可能性。我不经常使用模板,也完全不使用动态内存分配。是否有人碰巧知道PIC24 / PIC32上C ++的其他竞争对手?
汉斯

是的,很抱歉,这并不是一个很好的发现。让我在回答中添加更多内容。
Rocketmagnet 2012年

1
我会认为C是微控制器上C ++的竞争对手。我想不出我想在C ++中做的任何事情,而在C ++中我做不到的事情,而且看不见的函数调用(构造函数,析构函数等)更少。使代码更具确定性和简洁性。C ++的哪些功能是不可与C混淆的必备功能?
AngryEE 2012年

1
一个人可能会问:“ C的哪些功能必须在ASM中无法理解?” 回答:“没有”。好处是使设计人员可以指定设计,并让编译器检查实现是否正确,从而提高了能力。请参阅我的答案electronics.stackexchange.com/questions/3027/…,以获取C ++在这方面真正和直接的好处的列表。
Rocketmagnet'4

5

当我们使用C ++而不是C时,生成的.hex文件的大小和程序的运行时间增加了多少?

取决于您使用的功能。如果使用核心的面向对象功能(类+方法),则效果可能很小(变量/函数名称混杂在一起,因此符号表可能会有所增加)。模板也不应通过良好的编译器添加太多内容。

如果您全力以赴,使用标准模板库之类的东西,并使用动态内存分配和异常,那么您很可能会陷入代码膨胀。


提醒OP,要非常小心小内存体系结构和嵌入式始终运行的系统上的内存分配。
肯尼2012年

“ -1”人能否就他/她为何不同意发表评论?
杰森S

我不是-1er,但是模板是一项功能,必须格外小心,以免代码膨胀。当一个算法就足够时,您可以轻松获得一个算法的许多副本。
彼得·格林

要做到这一点,你实际上必须使用模板与几个不同的数据类型,以及一个拷贝不会就足够了,除非你使用的是有一个共同的基类的多形态代码。(在这种情况下,这会产生运行时成本。)模板不会神奇地导致您的代码膨胀,仅当您在不知道其后果的情况下将它们与多种数据类型一起使用时,它们才会导致代码膨胀。
杰森S


1

使您的问题稍微有些笼统,有一些针对嵌入式市场而构建的ARM处理器,其中包含MMU(内存管理单元)。内存大小和分配使诸如Java和C ++之类的语言无法选择嵌入式。随着嵌入式处理器不断变得越来越快,功能越来越强大,以及内存越来越密集,越来越便宜,嵌入式工程师可用的语言选择发生了巨大变化。具有MMU和64G闪存卡的32位600MHz ARM处理器非常适合c ++应用程序。它是否符合经典嵌入式处理器的定义是另一个问题。


0

可能是的..但是无论如何都不应该... C是嵌入式语言,使用C ++没有任何优势。确切地说,C的优势远远超过C ++的嵌入式优势。不要浪费你的时间。

  • 如果您知道如何使用函数指针等。可以使用C ++这样的代码,那里没有问题。

5
我不敢苟同。您可以使用C ++的许多功能(类,模板,运算符重载,引用),而几乎不需要运行时开销。是的,您可以使用朴实的C结构在纯C语言中完成所有这些操作,但这是您的脑筋,我宁愿使用C ++。(当然,我宁愿使用更好的语言,但我会选择普通C之上的C ++编译器。)
Jason S

1
类=结构(没有内置方法,但是如果您愿意,可以将函数指针存储在结构中并对其进行调用)。模板=您使用那些模板???运算符重载=是,我也想这样做。参考=指针,不是吗?至少使用C,您只需要使用C ++的“功能”,而不必担心过多的代码生成,也不必包括随机的大型库就可以进行编译。
AngryEE

1
我也希望有所不同。
Rocketmagnet'4

3
是的,模板是生成可靠和高性能代码的一种非常强大的方法。引用是更可靠的指针。使用C ++,您还只需为使用的功能付费。我认为您确实需要更多地了解C ++。
Rocketmagnet'4

3
我不知道“ C是嵌入式语言”的意思。当然,它很受欢迎。您是说这是最好的语言吗?当然不是。
Rocketmagnet'4
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.