很全面的嵌入式开发与学习的入门知识

在刚刚涉足嵌入式开发的时候，总想找到这样一本书，它可以解决我一些这样那样的疑惑。但是遗憾的是，到现在也没有这样一本书面世，而且我想永远也不可能面世了。因为我的疑惑太多太杂了。

这些疑惑在教科书中又难以寻找到答案。C 教程注重讲C的语法，编译原理注重讲语法，语义的分析。每一门教科书都是有它的注重，所以那些交叉的问题便成了三不管。市场上的那些自称为《XX 宝典》、《XX 圣经》的书却总是说一些可能连作者自己也没搞清楚的问题。于是我想，我想了解的也许是大家都想了解的吧，那么把我学到的一点东西写出来，大家也许就可以少花点时间在上面，留出宝贵的脑力资源去做更有意义的事。

语言选择，C 还是其他

刚刚涉及嵌入式开发者总是先阅读一些指导类型文章，然后就开始对开发语言的选择踌躇不决。是C还是C++?还是好像更热门的JAVA?不用犹豫，至少目前看来C还是你的选择。嵌入式开发的本质是订制开发，硬件平台林林总总，处理能力高下不同，如果想保护你学习精力投资的话，C是最好的“优绩股”。C++的优点在于它的代码重用，但是效率比C低很多，最重要的是，并非所有芯片的编译器都能支持C++。JAVA就更不用提及，在一个虚拟平台上开发的优点是不用关心具体的硬件细节，但这不是一个嵌入式开发者的作风，换一种说法，这种开发不能称之为嵌入式开发。

C被称为高级语言中的低级语言，低级语言中的高级语言，这是因为其一方面有高级语言所具有的接近于人类思想的语言体系，另一方面同时支持地址与位操作。可以方便的与硬件打交道。嵌入式开发必然要操作IO、硬件地址，没有位操作和指针你又如何方便做到?

嵌入式开发一般流程

嵌入式开发的流程与高层开发大体类似，编码——编译、链接——运行。中间当然可以有联机调试，重新编码等递归过程。但有一些不同之处。

首先，开发平台不同。受嵌入式平台处理能力所限，嵌入式开发一般都采用交叉编译环境开发。所谓交叉编译就是在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文件格式。

编译预处理

首先看看文件包含，从我们的第一个C程序Hello World!开始，我们就使用头文件包含，但是另人惊奇的是，很多人在做了很长时间的开发以后仍然对文件的包含没有正确的认识或者是概念不清，有更多的人却把头文件和与之相关联的库混淆。

为了照顾这些初学者，这里罗嗦一下，其实文件包含的本质就是把一个大的文件截成几个小文件便于管理和阅读，如果你包含了那个文件，那么你把这个文件的所有内容原封不动的复制到你包含其的文件中，效果是完全一样的，另一方面，如果你编译了一些中间代码，如库文件，可以通过提供头文件来告知调用者你的库包含的函数和调用格式，但是真正的代码已经变成了目标代码以库文件形式存在了。至于包含文件的后缀如.h只是告诉使用者，这是一个头文件，你用任何别的名字，编译器都一般不会在意。

那些对头文件和库还混淆的朋友应该恍然大悟了吧，其实头文件只能保证你的程序编译不出现语法错误，但是直到最后链接的时候才会真正使用到库，那些只把一个头文件拷贝来就想拥有一个库的人再也不要犯这样的错误了。如果你的工程中源程序数目繁多令你觉得管理困难，把他们全部包含在一个文件中也未尝不可。

另一个初学者常常遇到的问题就是由于重复包含引起的困惑。如果一个文件中包含了另一个文件两次或两次以上很可能引起重复定义的问题，但是没有人蠢到会重复包含两次同一个文件的，这种问题都是隐式的重复包含，比如A文件中包含了B文件和C文件，B文件中又包含了C文件，这样，A文件实际上已经包含了C文件两次。不过一个好的头文件巧妙的利用编译预处理避免了这种情况。在头文件中你可能发现这样的一些预处理：

#ifndef __TEST_H__

#define __TEST_H__

… …

#endif /* __TEST_H__ */

这三行编译预处理前两行一般位于文件最顶端，最后文件位于文件最末端，它的意思是，如果没有定义__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赋值的操作，你可以写一个类似下边的函数来实现：

void outb(unsigned char val, unsigned int *addr)

{

*addr = val;

}

仅仅是一句语句的函数，却要调用一个函数，如果不用函数呢，重复写上面的语句又显得罗嗦。不如用下面的宏实现。

#define outb(b, addr) (*(volatile unsigned char *)(addr) = (b))

由于不需要调用子函数，宏提高了运行效率，但是浪费了程序空间，这是由于凡是用到此宏的地方，都要替换为一句其代替的语句。开发者需要根据系统需求取舍时间与空间。