嵌入式开发杂谈
|
0
推荐
在刚刚涉足嵌入式开发的时候，总想找到这样一本书，它可以解决我一些这样那样的疑惑。但遗憾的是，到现在也没有这样一本书面世，而且我想永远也不可能面世了。因为我的疑惑太多太杂了。这些疑惑在教科书中又难以寻找到答案。C 教程注重讲C 的语法，编译原理注重讲语法，语义的分析。每一门教科书都是有它的注重，所以那些交叉的问题便成了三不管。市场上的那些自称为《XX 宝典》、《XX 圣经》的书却总是说一些可能连作者自己也没搞清楚的问题。于是我想，我想了解的也许是大家都想了解的吧，那么把我学到的一点东西写出来，大家也许就可以少花点时间在上面，留出宝贵的脑力资源去做更有意义的事。杂七杂八，不成体系，固命名为杂谈。基于共享精神，本篇文档保留版权，但可以允许非商业目的任意复制、拷贝，商业用途需经本人同意。 2 语言选择，C 还是其他 刚刚涉及嵌入式开发者总是先阅读一些指导类型文章，然后就开始对开发语言的选择踌躇不决。是C 还是C++？还是好像更热门的JAVA？不用犹豫，至少目前看来C 还是你的选择。嵌入式开发的本质是订制开发，硬件平台林林总总，处理能力高下不同，如果想保护你学习精力投资的话，C 是最好的“优绩股”。C++的优点在于它的代码重用，但是效率比C低很多，最重要的是，并非所有芯片的编译器都能支持C++.。JAVA 就更不用提及，在一个虚拟平台上开发的优点是不用关心具体的硬件细节，但这不是一个嵌入式开发者的作风，换一种说法，这种开发不能称之为嵌入式开发。C 被称为高级语言中的低级语言，低级语言中的高级语言，这是因为其一方面有高级语言所具有的接近于人类思想的语言体系，另一方面同时支持地址与位操作。可以方便的与硬件打交道。嵌入式开发必然要操作IO、硬件地址，没有位操作和指针你又如何方便做到？ 3 嵌入式开发一般流程 嵌入式开发的流程与高层开发大体类似，编码——编译、链接——运行。中间当然可以有联机调试，重新编码等递归过程。但有一些不同之处。 首先，开发平台不同。受嵌入式平台处理能力所限，嵌入式开发一般都采用交叉编译环境开发。所谓交叉编译就是在A 平台上编译B 平台上运行的目标程序。在A 平台上运行的B 平台程序编译器就被称为交叉编译器。一个初入门者，建立一套这样的编译环境也许就要花掉几天的时间。 其次，调试方式不同。我们在Windows 或者Linux 上开发的程序可以马上运行察看运行结果，也可以利用IDE 来调试运行过程，但是嵌入式开发者却至少需要作一系列工作才能达到这种地步。目前最流行的是采用JTAG 方式连接到目标系统上，将编译成功的代码下载运行，高级的调试器几乎可以像VC 环境一样任意的调试程序。 再者，开发者所了解层次结构不同。高层软件开发者把工作的重点放在对应用需求的理解和实现上。嵌入式开发者对整个过程细节必须比高层开发者有更深的认识。最大不同之处在于有操作系统支持的程序不需要你关心程序的运行地址以及程序链接后各个程序块最后的位置。像Windows，Linux 这类需要MMU 支持的操作系统，其程序都是放置在虚拟地址空间的一个固定的内存地址。不管程序在真正RAM 空间的地址位置在哪里，最后都由MMU映射到虚拟地址空间的一个固定的地址。为什么程序的运行与存放的地址要相关呢？学过汇编原理，或者看过最后编译成机器码程序的人就知道，程序中的变量、函数最后都在机器码中体现为地址，程序的跳转，子程序的调用，以及变量调用最后都是CPU 通过直接提取其地址来实现的。编译时指定的TEXT_BASE 就是所有一切地址的参考值。如果你指定的地址与最后程序放置的地址不一致显然不能正常运行。但也有例外，不过不寻常的用法当然要付出不寻常的努力。有两种方法可以解决这个问题。一种方法是在程序的最起始编写与地址无关的代码，最后将后面的程序自搬移到你真正指定的TEXT_BASE 然后跳转到你将要运行的代码处。另一种方法是，TEXT_BASE 指定为你程序的存放地址，然后将程序搬移到真正运行的地址，有一个变量将后者的地址记录下来作为参考值，在以后的符号表地址都以此值作为参考与偏移值合成为其真正的地址。听起来很拗口，实现起来也很难，在后面的内容中有更好的解决办法——用一个BootLoader 支持。另外，一个完整的程序必然至少有三个段TEXT （正文，也就是最后用程序编译后的机器指令）段、BSS（未初始变量）段DATA（初始化变量）段。前面讲到的TEXT_BASE 只是TEXT 段的基址，对于另外的BSS 段和DATA 段，如果最后的整个程序放在RAM 中，那么三个段可以连续放置，但是，如果程序是放置在ROM 或者FLASH 这种只读存储器中，那么你还需要指定你的其他段的地址，因为代码在运行中是不改变的，而后两者却不同。这些工作都是在链接的时候完成，编译器必然为你提供了一些手段让你完成这些工作。还是那句话，有操作系统支持的编程屏蔽了这些细节，让你完全不用考虑这些头痛的问题。但是嵌入式开发者没有那么幸运，他们总是在一个冷冰冰的芯片上从头做起。CPU 上电复位总是从一个固定的地址去找程序，开始其繁忙的工作。对于我们的PC 来说这个地址就是我们的BIOS 程序，对于嵌入式系统，一般没有BIOS 支持，RAM 不能在掉电情况下保留你的程序，所以必须将程序存放在ROM 或FLASH中，但是一般来讲，这些存储器的宽度和速度都无法与RAM 相提并论。程序在这些存储器上运行会降低运行速率。大多数的方案是在此处存放一个BootLoader，BootLoader 所完成的功能可多可少，一个基本的BootLoader只完成一些系统初始化并将用户程序搬移到一定地址，然后跳转到用户程序即交出CPU 控制权，功能强大的BootLoad 还可以支持网络、串口下载，甚至调试功能。但不要指望有一个像PC BIOS 那样通用的BootLoader 供你使用，至少你需要作一些移植工作使其符合你的系统，这个移植工作也是你开发的一个部分，作为嵌入式开发个入门者来讲，移植或者编写一个 BootLoader 会使你受益匪浅。没有BootLoader 行不行？当然可以，要么你就牺牲效率直接从ROM 中运行，要么你就自己编写程序搬移代码去RAM 运行，最主要的是，开发过程中你要有好的调试工具支持在线调试，否则你就得在改动哪怕一个变量的情况下都要去重新烧片验证。继续程序入口的话题，不管过程如何，程序最后在执行时都是变成了机器指令，一个纯的执行程序就是这些机器指令的集合。像我们在操作系统上的可运行程序都不是纯的执行程序，而是带有格式的。一般除了包含上面提到的几个段以外，还有程序的长度，校验以及程序入口——就是从哪儿开始执行用户程序。为什么有了程序地址还需要有程序的入口呢？这是因为你要真正开始执行的代码并非一定放置在一个文件的最开始，就算放在最开始，除非你去控制链接，否则在多文件的情况下，编译器也不一定将你的这段程序放置在最后程序的最顶端。像我们一般有操作系统支持的程序，只需在你的代码中有一个main 作为程序入口——注意这个main 只是大多数编译器约成定俗的入口，除非你利用了别人的初始化库，否则程序入口可以自行设定——即可。显然，带有格式的这种执行文件使用更加灵活，但需要 BootLoader 的支持。有关执行文件格式的内容可以看看ELF 文件格式。
这三行编译预处理前两行一般位于文件最顶端，最后文件位于文件最末端，它的意思是，如果没有定义__TEST_H__那么就定义__TEST_H__同时下面的代码一直到#endif 前参与编译，反之不参与编译。多么巧妙的设计，有了这三行简洁的预处理，这个文件即使被包含几万次也只能算一次。 我们再来看看宏的使用。初学者在看别人代码的时候总是想，为什么用那么多宏呢？看得人一头雾水，的确，有时候宏的使用会降低代码的可读性。但有时宏也可以提高代码的可读性，看看下边这两段代码：
1） #define SCC_GSMRH_RSYN 0x00000001 /* receive sync timing */ #define SCC_GSMRH_RTSM 0x00000002 /* RTS* mode */ #define SCC_GSMRH_SYNL 0x0000000c /* sync length */ #define SCC_GSMRH_TXSY 0x00000010 /* transmitter/receiver sync*/ #define SCC_GSMRH_RFW 0x00000020 /* Rx FIFO width */ #define SCC_GSMRH_TFL 0x00000040 /* transmit FIFO length */ #define SCC_GSMRH_CTSS 0x00000080 /* CTS* sampling */ #define SCC_GSMRH_CDS 0x00000100 /* CD* sampling */ #define SCC_GSMRH_CTSP 0x00000200 /* CTS* pulse */ #define SCC_GSMRH_CDP 0x00000400 /* CD* pulse */ #define SCC_GSMRH_TTX 0x00000800 /* transparent transmitter */ #define SCC_GSMRH_TRX 0x00001000 /* transparent receiver */ #define SCC_GSMRH_REVD 0x00002000 /* reverse data */ #define SCC_GSMRH_TCRC 0x0000c000 /* transparent CRC */ #define SCC_GSMRH_GDE 0x00010000 /* glitch detect enable */ *(int *)0xff000a04 = SCC_GSMRH_REVD | SCC_GSMRH_TRX | SCC_GSMRH_TTX | SCC_GSMRH_CDP | SCC_GSMRH_CTSP | SCC_GSMRH_CDS | SCC_GSMRH_CTSS; 2） *(int *)0xff000a04 = 0x00003f80;
这是对某一个寄存器的赋值程序，两者完成的是完全相同的工作。第一段代码略显冗长，第二段代码很简洁，但是如果你如果想改动此寄存器的设置的时候显然更喜欢看到的是第一段代码，因为它现有的值已经很清楚，要对那些位赋值只要用相应得宏定义即可，不必每次改变都拿笔再重新计算一次。这一点对于嵌入式开发者很重要，有时我们调试一个设备的时候，一个关键寄存器的值也许会被我们修改很多次，每一次都计算每一位所对应得值是一件很头疼的事。 另外利用宏也可以提高代码的运行效率，子程序的调用需要压栈出栈，这一过程如果过于频繁会耗费掉大量的CPU 运算资源。所以一些代码量小但运行频繁的代码如果采用带参数宏来实现会提高代码的运行效率，比如我们常常用到的对外部IO 赋值的操作，你可以写一个类似下边的函数来实现：
仅仅是一句语句的函数，却要调用一个函数，如果不用函数呢，重复写上面的语句又显得罗嗦。不如用下面的宏实现。
最后大家看一段将宏用到炉火纯青者的代码，此段代码来自于Das U-boot，这一段代码用7 个简单的宏实现了6 个类似功能的函数！
最后，我们再来看几个巧妙利用预编译和宏的例子。 I 大段代码注释 在程序调试中，我们往往需要临时注释掉一大段代码，如果这段代码中已经有很多注释，那么用/* */这种方式注释会遇到匹配问题，很难一下将整段代码注释掉，// 这种注释很多编译器不支持，即使支持，把几十行代码用这种方式注释也要花掉你很多时间，有好的编辑器倒是支持用这种方式注释掉大段代码，但并非每个人都有用这样的编辑器。如果用预编译很容易处理这个问题，在你需要注释的代码前和代码后分别加：
一段代码立马从编译器视线中消失，如果再想临时加入，只需要将0 改为1 即可。是不是很方便？ II 行调试 在调试一段代码出现错误时我们往往需要确定错误出现在哪一行，像我们懒于使用仿真器而习惯于用printf 来观看运行过程的人来说，往往首先为自己的平台编写一个类printf 的函数可以输出格式化的字符串，在熟练使用编译器宏之前我们往往喜欢加上一些这样的代码：
__DATE__, __TIME__这两个宏会在编译过程中替换为目前日期和时间的字符串。所以不妨在你的程序开头中加入这样的语句：
这样，程序子每次运行的时候就会打印出其最后编译的日期和时间，再也不用疑惑是否烧错程序版本了。 I volatile
一般的编译器都带有优化功能，那么这段代码被优化会是什么结果呢？编译器认为前面循环半天都是废话，对最后的结果毫无影响，因为最终只是将output 这个指针赋值为9，所以编译器最后给你编译的代码结果相当于为：
II cache 我们都知道Intel 的PII 以后的CPU 都有一款与之对应得赛扬CPU。其唯一不同就是少了一些cache 的容量。事实上，大多数的微处理器或微控制器都带了cache， cache 是价格与性能的一种折衷方案。因为一般CPU（为描述方便，不论微处理器或微控制器，本文中都将称之为CPU）的速度都比现行体系的RAM 快，CPU 对内存的访问降低了其运行的整体速度。为与CPU 的速度匹配，CPU 都在内部集成了一定容量的cache。cache 运行周期一般于CPU 相匹配，但其价格较高，很难大量采用。cache 的使用是基于计算机中的一个有名的“局部原理”，即计算机在某一段时间内无论对代码还是数据都局限在一定的范围内。这个原理是严谨而好事的计算机科学家的猜想加大量统计的结果。想想也是，我们程序中有大量的循环代码，这些代码不就是一遍一遍的执行一些固定区域的语句吗，同样循环中的数据操作不也是对一些固定区域的数据如数组操作吗！基于这种理论，CPU 在执行代码时同时将此代码所在块的内容全部读入指令cache，读取数据时把此数据所在块的内容全部读入数据cache，在余下时间里，只要执行的代码未超出此范围，则CPU 无需在外部RAM 中再行访问代码，数据同样如此。写操作相同，如果某一个块内存正好被装入cache，那么，CPU对此内存块的写操作也只在cache 中进行。但是要注意的是，cache 的容量是远远小于外部RAM 的，CPU 在访问新的代码和数据时如果不在cache 内部就发生缺失，专业术语称之为“未命中”，反之称之为“命中”，在未命中的情况下，CPU 会将现有cache 中的某一个块基于某种算法用新的内容替换。正是这种命中与未命中却给我们的嵌入式开发初入门者带来如同volatile 一样的困惑。以CPU 为核心看，我们将CPU 直接参与的事件称之为同步事件，CPU 未直接参与的称之为异步事件。cache 的操作都是同步的，但是如果你在写一个外部设备的驱动，而且为了减少CPU 的参与你用了DMA 来搬移数据，那么DMA 搬移数据这个事件便是异步事件。
看看我设计的（未加求证是否首创或独创，如有前人，多有冒犯）一个算法:
第一个算法最接近人类思想，也是初学者一般的容易想到的算法，但是用到了if 判断语句，效率不高，程序也显冗长。第二个算法有进步简化了代码，但是用到CPU 不善长的取余运算，不过此算法的优点是不仅仅适合双缓存体系，也可以适合多缓存体系。第三种算法专门针对双缓存设计，即没有费时的判断，也没有取余运算，用一个简单的减法运算实现了双缓存切换。
此算法的思想是这样的，如果任务B 是“开始运行”状态，那么在接到一个数据缓存的情况下不做处理，继续等待第二个缓存数据的到来，然后把这两个缓存数据连续地给真正的数据处理函数。如果不是“开始运行”状态则收到一个缓存就交给处理函数一个缓存。这个算法的问题在于任务是无限循环运行的，但仅仅因为判别是否为第一次运行就必须每次循环都执行一次判断语句。看看一个改进的算法。taskA 不做改动，taskB 改为：
因为msgRecv 这类消息接收都是阻塞式的，所以开始运行的时候如果数据未到任务B 就阻塞在数据接收上，直到接收到两个缓存数据在开始交给处理数据，和算法改进前的执行效果是完全相同的。仅仅是结构调整就避免了每次循环都做一个无谓的判断。 |