Keil和GCC在ARM7开发中有什么区别？我正在为一个中等规模项目选择硬件顾问，有些人使用Keil，有些人使用GCC。我想知道选择任何一种选项时需要注意的问题...
5个回答
8
从编码/开发角度来看，这两者之间几乎没有什么区别。我认为你应该考虑的唯一一件事情与这些编译器无关。维护:
- 如果您无法访问Keil编译器，您能否维护软件，或者这只是一个小成本？
- 另外，支持哪些调试硬件/JTAG，如果需要获取一些硬件，成本会是多少？
- 如果由于需要更换开发人员而必须从一个编译器转移到另一个编译器，成本将是多少？
- Gerhard
6
可以结构化你的代码，以同时使用这两种编译器。"packed"等属性可以用宏来处理，使代码在两种编译器下都能正常工作。将硬件细节推到较低的层级，并在运行时而不是编译时配置硬件映射。如果必须有单独的Kiel和GCC版本的代码，请将它们放在单独的文件中，并使用gcc make或Kiel项目文件配置要使用哪一个。
我还未解决的一个问题是汇编代码。Kiel使用armasm，而gcc使用as。它们似乎具有非常不同的源代码格式。如果可以避免使用汇编，则另一种选择更好。
选择GCC的优点是您可以针对非ARM平台进行开发 - 这对于在具有更好开发工具的平台上模拟应用程序非常理想（即x86 Linux下的valgrind）。事实上，每个针对ARM的应用程序都应采取这种方法。先在x86上开发，然后再移植到ARM。
还有使用Kiel保持当前的成本。我知道有一个地方停留在RVDK 2.1（2002年？），因为升级到最新版对三位开发人员来说成本过高。
我还要补充的是，相比我们（固然古老的）版本的Kiel，gcc和pedantic会更好地发现代码中的警告和错误。
Kiel可能提供更紧凑的ARM代码，因此请将其用于目标构建。否则，请使用GCC。
我还未解决的一个问题是汇编代码。Kiel使用armasm，而gcc使用as。它们似乎具有非常不同的源代码格式。如果可以避免使用汇编，则另一种选择更好。
选择GCC的优点是您可以针对非ARM平台进行开发 - 这对于在具有更好开发工具的平台上模拟应用程序非常理想（即x86 Linux下的valgrind）。事实上，每个针对ARM的应用程序都应采取这种方法。先在x86上开发，然后再移植到ARM。
还有使用Kiel保持当前的成本。我知道有一个地方停留在RVDK 2.1（2002年？），因为升级到最新版对三位开发人员来说成本过高。
我还要补充的是，相比我们（固然古老的）版本的Kiel，gcc和pedantic会更好地发现代码中的警告和错误。
Kiel可能提供更紧凑的ARM代码，因此请将其用于目标构建。否则，请使用GCC。
- Craig Mc
4
如果我没记错，Kiel现在是由ARM公司拥有的。相比于gcc编译器，ARM编译器可以更快地生成高质量的代码。我记得Kiel包含了一个简化版或免费版的rvct。所以我的问题是，使用商业解决方案来获得更快、更干净、更好的代码是否值得，尤其是当gcc已经存在并被广泛使用时？除非你处于性能危机的情况下，并且愿意在所有基于gcc的信息和你的商业工具之间进行心理翻译，否则我会选择gcc。总的来说，选择gcc可能是更好的选择，尽管在Kiel背后可能有大量的信息和知识，但是基于gcc的解决方案的知识和信息量要更多。
如果顾问们使用一种工具来为您的项目做初步的工作，然后在最后他们将工作交给您，那么您可能希望使用基于gcc的解决方案（这并不意味着使用vxworks gcc，甚至不是code sourcery gcc，而是一个通用的gcc解决方案），因为毫无疑问，您或者您雇佣的其他人都将必须接手并运行它，使用gcc您更有可能找到愿意并且能够胜任的人。
如果顾问们使用一种工具来为您的项目做初步的工作，然后在最后他们将工作交给您，那么您可能希望使用基于gcc的解决方案（这并不意味着使用vxworks gcc，甚至不是code sourcery gcc，而是一个通用的gcc解决方案），因为毫无疑问，您或者您雇佣的其他人都将必须接手并运行它，使用gcc您更有可能找到愿意并且能够胜任的人。
- old_timer
1
商业解决方案的主要好处是，如果您在编译器或库方面遇到问题，可以得到支持。
当您使用主流硬件（例如gcc = x86）时，开源是可以接受的。编译器或库的大多数问题通常会很快被社区修复。
如果您正在开发（也许是异乎寻常的）嵌入式平台，如果工具链出现任何问题，您很快就会感到孤独。
当您使用主流硬件（例如gcc = x86）时，开源是可以接受的。编译器或库的大多数问题通常会很快被社区修复。
如果您正在开发（也许是异乎寻常的）嵌入式平台，如果工具链出现任何问题，您很快就会感到孤独。
- chrmue
6
1说实话，你在编译器方面遇到问题的频率有多高？我已经使用商业选项多年了（在ARM7和8051开发中），很少遇到困难。 - Nate
@Nate：感到幸运吧！我们在这里使用ARM9的gcc编译器，当我们尝试使用优化时，遇到了一个非常棘手的编译问题。幸运的是，我们找到了一个补丁来解决这个问题。几年前，我曾在另一家公司工作，那里我们不得不从gcc（用于C166）转换到KEIL，因为库中充满了错误。 - chrmue
3作为CodeSourcery的员工，我觉得有必要指出，“商业解决方案”和“开源”并不是非此即彼的选择——我们销售基于GCC的解决方案，并提供全面的商业级技术支持，以解决和预防这类问题。（我们不是唯一销售GCC支持的公司。） - Brooks Moses
曾经在DEC和Intel的VC++链接器和编译器上工作过，即使有支持也不代表能得到支持。我花了三个月时间才得到一个能够组合32MB可执行文件的DEC Alpha链接器。三个月的时间里，我无法在他们的平台上发布我的代码。这很糟糕（也许是他们现在已经死亡的原因之一）。 - Chris K
我们使用Rowley CrossWorks编译器 - 在底层使用GCC，但获得商业支持。支持非常好 - 根据我的经验比IAR更好。 - peter_mcc
这整个线程让我更加困惑了。我只想建立一个尽可能少出问题的工作项目。现在我听说有多个gcc来源和多个支持平台，天啊。好吧，这是一个非常陡峭的学习曲线 :) - hamish
1
我们使用Keil平台，非常满意它的性能和优化。我在几年前运行了一些标准基准测试，结果相当不错。另一个考虑因素是支持，到目前为止，Keil的响应时间非常好，并且在一些棘手问题上反馈相对良好。
顺便说一下，如果您的项目将使用Keil RTOS并且有任何问题，请注意源代码可供购买。
- Answerguru
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接