写固件：组装或高的水平？ [英] Writing firmware: assembly or high level?
问题描述
相关：
- Testing firmware
- starting a microcontroller simulator/emulator
- Interpreting assembly code
如果你正在写code的微控制器是有真正的区别如果你用汇编或C或其他高级语言编写？如果你写C code，你会如何编译它？
If you are writing code for a microcontroller is there a real difference if you write in assembly or C or some other high level language? If you wrote C code, how would you compile it?
感谢
推荐答案
几点意见：
1）绝对的不可以组装除非性能或优化约束保证它。以下指标经过汇编屋顶：
1) Absolutely not assembly unless performance or optimization constraints warrant it. The following metrics go through the roof with assembly:
- 时间code将其
- 的时间来调试它
- 的时间来测试它
- 的时间来记录它
- 时间找出（1年后），它是什么，你在做当你codeD它
- 犯错误的几率
2）我的preference是C ++而不是C的命名空间的封装和放大器;其的编译时间的面向对象的做法提供便利。 C有全局变量和命名空间冲突太多的机会。 （实时Java将是很好的，但是从我的理解它的要求仍然是pretty高）
2) My preference would be C++ rather than C for its namespace encapsulation & its facilitation of compile-time object-oriented practices. C has too many opportunities for global variables and namespace collisions. (Real-time Java would be nice but from what I understand its requirements are still pretty high)
或者说C ++的一个子集：排除例外，虚函数，运行时类型识别，也动态内存分配在多数情况下 - 基本上什么剩下的未指定在编译的时候，因为它通常需要大量的额外资源在运行时。这就是C ++的膨胀。
Or rather a subset of C++: Exclude exceptions, virtual functions, run-time type identification, also dynamic memory allocation in most cases -- basically anything that's left unspecified at compile time, as it will usually require a lot of extra resources during runtime. That's the "bloat" of C++.
我都用了TI的和IAR的编译器对于C ++，为（分别）的TMS320和MSP430微控制器以及适当的优化设置，他们这样做减少了开销，你可能期望从C ++的出色的工作。 （特别是如果你来帮它通过明智地使用了在线关键字）
I have used both TI's and IAR's compilers for C++, for the TMS320 and MSP430 microcontrollers (respectively) and with proper optimization settings, they do a fantastic job of reducing the overhead you might expect from C++. (Especially if you help it out by judicious use of the inline keyword)
我有一些能促进良好的code再利用他们的编译时好处，甚至使用的模板：例如写一个单一来源$ C $ C文件处理8位，16位和32位CRC校验;和编译时多态性来允许你指定一个类的通常的行为，然后再利用这一点，但覆盖它的一些功能。此外，TI的编译器有一个非常低的开销适当的优化设置。
I have even used templates for some of their compile-time benefits which promote good code reuse: e.g. writing a single source code file to handle 8-bit, 16-bit, and 32-bit CRCs; and compile-time polymorphism to allow you to specify the usual behavior of a class, and then reuse that but override some of its functions. Again, the TI compiler had an extremely low overhead with appropriate optimization settings.
我一直在寻找一个C ++编译器了Microchip的PIC;我发现的唯一公司，生产一种是IAR。 （$$$一直是一个障碍，但我希望某个时候买一本）Microchip的C18 / C30编译器pretty不错，但他们C，不是C ++。
I have been looking for a C++ compiler for the Microchip PICs; the only company I've found that produces one is IAR. ($$$ has been an obstacle but I hope to buy a copy sometime) The Microchip C18/C30 compilers are pretty good but they're C, not C++.
3）关于编译器优化的具体警告：本品可/会使调试非常困难;通常这是不可能通过优化的C单步/ C ++ code和手表窗口可能表明有什么你觉得他们应该包含未优化code无相关变量。 （一个很好的调试器会提醒你，一个特定变量已经被优化掉的存在，或到寄存器，而不是一个内存位置。很多调试器没有。> :(
3) A specific caveat about compiler optimization: it can/will make debugging very difficult; often it's impossible to single-step through optimized C/C++ code and your watch windows may show variables that have no correlation with what you think they should contain with unoptimized code. (A good debugger would warn you that a particular variable has been optimized out of existence or into a register rather than a memory location. Many debuggers do not. >:(
也是一个不错的编译器将让你选择/选择在通过编译指示功能级优化。我只用的那些让你在文件级别指定的优化。
Also a good compiler would let you pick/choose optimization at the function level through #pragmas. The ones I've used only let you specify optimization at the file level.
4）接口C code到装配：这通常是困难的。最简单的方法是使具有所需例如签名的存根功能 uint16_t富（uint16_t一，uint32_t的B）{返回0; } ，其中 uint16_t =无符号短，通常我们作出明确位的＃。然后编译和编辑它产生的组件（只需确保离开code的开始/出口部分）和小心不影响任何寄存器没有恢复它们在完成后。
4) Interfacing C code to assembly: This is usually difficult. The easiest way is to make a stub function that has the signature you want e.g. uint16_t foo(uint16_t a, uint32_t b) {return 0; }, where uint16_t = unsigned short, we usually make the # of bits explicit. Then compile it and edit the assembly it produces (just make sure to leave the begin/exit parts of the code) and be careful not to clobber any registers without restoring them after you are done.
内联汇编通常可以有问题，除非你正在做的事情的非常的简单的像启用/禁用中断。
Inline assembly usually can have problems unless you are doing something very simple like enabling/disabling interrupts.
我最喜欢的方法是编译器内在函数/扩展ASM语法。 Microchip的C编译器是基于GNU C编译器，它有扩展ASM ，它可以让你内联汇编的code位，但你可以给它很多的提示，告诉它哪些寄存器/变量你引用，它会处理所有的保存/寄存器的恢复，以确保您的装配code中扮演好的C.与TI的编译器的TMS320 DSP系列不支持这些;它有一组有限而有一些使用内在函数。
The approach I like best is compiler intrinsics / "extended ASM" syntax. Microchip's C compiler is based on the GNU C compiler and it has "extended ASM" which lets you code bits of inline assembly but you can give it lots of hints to tell it which registers/variables you are referencing and it will handle all the saving/restoring of registers to make sure your assembly code "plays nice" with C. TI's compiler for the TMS320 DSP doesn't support these; it does have a limited set of intrinsics which have some use.
我用汇编优化资源被频繁执行的一些控制回路code或计算罪（），COS（）和反正切（）。但除此之外我从装配远离和高层次的语言坚持下去。
I've used assembly to optimize some control loop code that got executed frequently, or to calculate sin(), cos(), and arctan(). But otherwise I'd stay away from assembly and stick with a high-level language.
这篇关于写固件：组装或高的水平？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
