我们正在启动一个基于微芯片PIC18F252的新项目。什么是最好的" c"编译器？

解决方案

我们使用CCS，这非常好。速度很慢，但是效果很好。无论如何，我与其他编译器没有任何比较，因此可能会有更好的选择。

如果可以解决(我希望这样做)，请使用带MPLAB的PIC18汇编器。它具有免费和相对完善的文档记录的优势，同时它还具有不错的硬件/调试器支持。它的指令集小且简单，因此可以轻松快速地进行编码。

如果我们在c上进行设置：

CCS是一个好用的编译器，有点bug，非常昂贵，但也具有良好的调试功能。

如果我们已经习惯了使用Visual Studio 6编写c代码的方法，则Microsoft Embedded Studio(或者类似的工具)将非常有用。再次是良好的硬件支持和出色的调试器。

我相信，如果我们正在寻找免费的解决方案，那么我们确实可以为MPLAB获得C编译器，尽管我个人从未使用过C编译器，因此我无法通过判断。

我不喜欢CCS，这太古怪了。

SourceBoost不错，也很便宜，大约40。

Microchip C18编译器是最好的IMO，但是非常昂贵。不过，有一个免费的演示版/学生版。

• Microchip C18编译器：确实是最好，最容易使用的编译器。非常适合专业使用。
• HI-TECH：当Microchip不工作时使用(适用于PIC16)。
• 碳捕集与封存
• SourceBoost

PS：我本人是在PIC18F25XX和PIC18F45xx系列上工作的，所以我对此有些了解。 ;)

PS2：万一发生编译器错误(发生在我们这里)，Microchip团队反应迅速，并且很快发布了新版本。尝试找到与Microchip有联系的本地经销商，然后与他们一起参加活动并获得直接联系。无价。

我会坚持要求我们使用C18编译器。它非常强大并且非常易于使用。这是专业发展的必备条件。这实际上取决于我们正在处理的项目的大小。

从免费/学生版开始，我们会很好地使用它。如果项目很小，那可能就是我们所需要的。我刚刚在PIC 18F上完成了一个大型开发项目，并且对C18编译器感到非常满意。

我目前正在使用CCS并讨厌它。它是如此的非标准，并且包含大量的C子集，以至于它很烂。我正在考虑尽快切换。我将首先尝试使用Microchip C18编译器，然后再努力学习并获得HighTech，这从审阅试用版和示例来看似乎很可靠。

使用sdcc：

http://sdcc.sourceforge.net/

对于非免费(但免费！)的PIC编译器，mikroC是gr8！

http://www.mikroe.com/sc/products/view/7/mikroc-pro-for-pic/

高温超导

PICC一直以来对我来说都是可靠的，并且经过多年的发展。

IAR系统具有PIC18编译器/ IDE：用于PIC18的IAR嵌入式工作台。

几年前，我对Hitech PICC18编译器和Microchip C18编译器进行了广泛的研究。

我认为大多数决定使用Microchip C18编译器的人只是因为他们在访问微芯片网站时就可以看到它，并且已经对MpLab进行了组装(这是很糟糕的IDE恕我直言)。

HiTech的解决方案更接近ANSI C(因此代码更易移植)。使用C18，我们可以添加各种特定于编译器的关键字，并且我们不得不管理更多的内存。

• 我们必须指定要将变量分配给哪个内存库。
• 为了将const字符串分配给程序空间(而不是ram)，必须使用rom关键字。
• 如果不编辑链接描述文件，则不能分配大于256字节的变量。

可以在这里找到更深入的出色比较：http://www.xargs.com/pic/picc18-vs-c18.html

除了从编译器中，我们还需要考虑IDE。我是个狂热的蚀迷，因此我非常喜欢HiTech的HiTide。但是，由于Microchip已经购买了HiTech ...，看来他们不再支持HiTide。我不认为这是官方的...但是从我对HiTech支持的经验来看，他们不再修复错误，这实在令人遗憾。

我也尝试过他们的专业编译器。我真的很喜欢这个主意。但是，我的项目超出了自动参数块的要求，因此无法使用它。似乎也需要很长时间才能编译，但这可能是程序复杂性的根本原因。

我已经使用CCS多年了。我发现了一些错误，但是有很多支持，而且与C18或者HiTec相比，使用CCS可以更快，更轻松地进行开发。

MPLAB C18学生

我没有使用Microchip编译器，但是多年来一直在使用HiTech的产品。我通常喜欢他们的PIC16编译器，但是发现他们的PIC18编译器相当令人沮丧。尽管我欣赏不必将所有变量都放入库中，但HiTech编译器使用的规则令人讨厌，离奇而愚蠢。简要背景：该芯片具有16个256字节的变量库(*并非所有256字节在所有库中都可用)和一个库指针。直接访问变量需要选择适当的库；更换银行只需要一条指令。

全局和静态int和struct及其数组(其大小范围为2-255字节)将分别按模块分配给psect；每个模块的psect必须适合256字节的页面。字节数组以及单个字节以"大" psect的形式出现，其中假定每个字节可能驻留在不同的页面中。

整个程序中的所有自动变量和参数都必须位于256字节的页面中(它们在链接时静态分配)。链接器会覆盖永远不会同时存在的变量，但它假定对具有特定签名的函数指针的任何调用都可以调用其地址已获取且具有该签名的任何函数。

可以声明价值接近128字节的全局变量和静态变量为" near"。无需切换银行即可访问这些内容。无法指定将自动变量或者参数放置在"附近"。

HiTech使用的库切换规则意味着，即使许多功能从不使用自己模块外的任何变量，也将使用movlb(switch-bank)指令。

我不想"无所不知的代码生成"。我希望能够通过为自定义psect定义关键字或者宏来添加一些提示以合理地放置事物，允许自动变量和局部变量与其他变量共享psect(在给定银行限制的情况下，尽可能覆盖自动变量/参数)。如果编译器供应商确实希望变得更好，请允许指针接受bank限定符，以便只将指向某个psect中内容的指针存储在8位中。同样，允许函数和函数指针上的库限定符指定某些间接调用只能与某些函数一起使用。与其将函数指针设置为24位，或者不必确保间接调用的函数最终出现在前64K中，不如将自动GOTO放入前64K中，以便函数指针可以为16位。或者更好的是，如果一个函数"类"具有少于64个不同的函数，请使用8位指针。

我问得太多了吗？

我已经使用SourceBoost大约一年了，虽然我并不感到很兴奋，但是还不错。但是，我刚刚完成了SourceBoost 7，MCC18和Hi-Tech C之间的代码大小测试。结果非常出色。

对于一个小的示例程序(包括结构，数组，函数指针，结构指针，字符和整数)，SB7套件产生的代码约为MCC18和HTC的2/3. 我想确定其中有多少是启动和运行时开销，所以我在示例程序中添加了更多随机内容，并且大小增量显示SB仍然是其他大小的2/3. HTC略小于MCC18，但不明显。所有优化均在所有环境中进行。

我不喜欢SB的事情是：

• 有限的在线汇编器
• 编译和链接速度慢
• IDE仅比MPLAB好一点。

我喜欢的东西是：

• 好吧，代码的大小肯定比竞争对手要小。
• 语言的一些扩展(例如参考)。不过，这会杀死可移植性。
• 价格。
• 通过论坛提供的支持实际上是相当不错的。作者经常发帖。
• 自动消除未使用的代码(我认为此功能会减慢编译和链接的速度)

由于我不喜欢SB IDE，因此我将Source Insight用于编辑器，它震撼人心！ SB" make"实用程序也是没有希望的，因此我使用了GnuWin32 make，它绝对是免费的。

所以总的来说，我对工具的选择感觉好多了。

无论如何，希望这可以帮助某个人。