ARM7 的 Keil 与 GCC？
对于 ARM7 开发，Keil 与 GCC 相比如何？ 我正在为一个中型项目选择硬件顾问，有些使用 keil，有些使用 gcc。 我想知道使用任一选项所涉及的问题......
How does Keil compare to GCC for ARM7 development? I'm in the process of choosing hw consultants for a medium size project and some use keil and some use gcc. I'd like to know the gotchas involved in going with either option...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
从编码/开发的角度来看，两者之间几乎没有什么区别。 我认为您应该考虑的唯一一件事不是特定于这些编译器。 维护：
如果您无权访问该软件
Keil 编译器还是
小成本？
如果您必须从一个编译器迁移
到其他编译器，因为必须
稍后更换开发人员？
除非您对成本非常敏感，否则我认为真正的问题是谁会做得最好，因为编译器将是一个小问题。
There is very little difference between the two from a coding/development standpoint. The only thing I think you should consider is not specific to these compiler. Maintenance:
software if you do not have access to
the Keil compiler or will it be a
minor cost?
if you have to move from one compiler
to other compiler due to having to
switch developers later?
Unless you are very cost sensitive I think the real question is who will do the best job since the compiler will be a minor problem.
应该可以构建您的代码以使用这两个编译器。 像“packed”这样的属性可以被宏化，因此代码在这两种情况下都很满意。 将硬件详细信息下推到较低级别，并在运行时而不是编译时配置硬件映射。 如果您必须拥有一段代码的单独 Kiel 和 GCC 版本，请将它们放在单独的文件中并配置与 gcc make 或 Kiel 项目文件一起使用。
我尚未解决的一个问题是汇编代码。 Kiel使用armasm，而gcc使用as。 他们似乎有非常不同的源代码格式。 如果可以的话，避免使用汇编程序的另一个原因。
使用 GCC 的优点是您可以针对非 ARM 平台 - 非常适合在具有更好的开发工具（即 x86 linux 下的 valgrind）的平台上模拟您的应用程序。 事实上，这是每个 ARM 目标应用程序都应该采用的方法。 首先在 x86 上开发，然后移植到 ARM。
与基尔保持同步还需要付出代价。 我知道有一个地方被困在 RVDK 2.1（2002？）上，因为升级到最新版本的成本对于三个开发人员来说太高了。
我还要添加 gcc & 迂腐的方法会比我们（诚然是古老的）版本的 Kiel 更好地消除代码中的警告和错误。
Kiel 可能会提供更严格的 ARM 代码，因此保留它来进行目标构建。 否则使用 GCC。
It should be possible to structure your code to use both compilers. Attributes like "packed" can be macro'd up so the code is happy under both. Push hardware details down into lower levels, and configure hardware maps at run-time instead of compile time. If you must have separate Kiel and GCC versions of a piece of code, put them in separate files and configure which is used with the gcc make or the Kiel project file.
One problem I've yet to solve is assembler code. Kiel uses armasm, while gcc uses as. They seem to have very different source code formats. Another reason to avoid assembler if you can.
The advantage of going with GCC is that you can target non-ARM platforms - ideal for simulating your application on a platform with much better development tools (i.e. valgrind under x86 linux). In fact, this is the approach every ARM-targeted application should take. Develop on x86 first, then port to ARM.
There's also the cost of staying current with Kiel. Once place I know is stuck on RVDK 2.1 (2002?) because the cost to upgrade to the latest for three developers is prohibitive.
I'd also add that gcc & pedantic will shake out warnings and errors in your code a lot better than our (admittedly ancient) version of Kiel will.
Kiel might deliver tighter ARM code, so keep it for doing target builds. Otherwise use GCC.
如果我没记错的话，基尔现在归 ARM 所有。 ARM 编译器比 gcc 更能生成良好的代码。 我似乎记得 Keil 包括精简版或免费版或任何版本的 rvct。 所以我的问题是，当 gcc 出现并得到良好使用时，是否有更快、更干净、更好的代码值得使用商业解决方案？ 我会选择 gcc，除非您处于性能紧张的情况，并且愿意在网上免费提供的所有基于 gcc 的信息与您的商业工具之间进行心理转换。 一般来说，使用 gcc 可能是更好的路径，因为基尔的谷歌搜索框后面可能有大量信息，但基于 gcc 的解决方案的知识和信息量掩盖了这一点。
如果顾问使用一种工具为您完成项目的初始跑腿工作，然后最后他们将工作移交给您，您可能会想要一个基于 gcc 的解决方案（这并不意味着 vxworks gcc，甚至代码源） gcc，但一个通用的 gcc 解决方案），因为毫无疑问，您或您雇用的其他人将不得不选择这个质量并使用它运行，并且使用 gcc，您更有可能找到愿意且有能力的人。
If I remember right Kiel is now owned by ARM. ARM compilers are night and day better than gcc for producing good code. I seem to remember Keil including a reduced or free or whatever version of rvct. So my question is having much faster, cleaner, better code worth using a commercial solution when gcc is out there and well used? I would go with gcc unless you are in a performance crunch situation and are willing to have to mentally translate between all the gcc based information freely available on the net to your commercial tools and back again. In general going with gcc is probably the better path, granted there is probably a wealth of information behind the google search box for Kiel but the amount of knowledge and information for gcc based solutions shadows that.
If the consultants are using one tool to do the initial legwork for a project for you and then at the end they hand the work over, you probably will want to have a gcc based solution (that doesnt mean say vxworks gcc, or even code sourcery gcc, but a generic gcc solution), because no doubt you or someone else you hire is going to have to pick this mass up and run with it and with gcc you are more likely to find someone willing and able.
商业解决方案的主要好处是，如果您遇到编译器或库问题，可以为我提供支持。
当您使用主流硬件时（如果 gcc = x86），开源就很好。 编译器或库的大多数问题通常很快就会被社区修复。
如果您正在（可能是奇异的）嵌入式平台上进行开发，如果工具链出现任何问题，您很快就会感到非常孤独。
The main benefit of a commercial solution is the support for me if you run into problems with the compiler or the libraries.
Open source is fine when you are using main stream hardware (in case of gcc = x86). Most of the problems of the compiler or the libs normally will be fixed very soon by the community.
If you are developing on a (perhaps exotic) embedded platform you soon can feel pretty lonely if you have any problems with the tool chain.
我们使用 Keil 平台，对其性能和优化非常满意。 几年前我运行了一些标准基准测试，它们非常好。 另一个考虑因素是支持，到目前为止，Keil 在一些棘手问题上有很好的响应时间和相对良好的反馈。
仅供参考，如果您的项目将使用 Keil RTOS 并且您对此有任何疑问，可以购买源代码。
We use the Keil platform and are very happy with it's performance and optimization. I ran some standard benchmarks a couple of years ago and they were quite good. Another consideration is support and so far, Keil has had very good response times and relatively good feedback on some tough issues.
FYI, if your project will use the Keil RTOS and you have any questions about it, the source code is available for purchase.