■　BSP（Board Support Package）：BSP介于主板硬件和操作系统间，其功能与PC主机板上的BIOS相类似，主要功能为完成硬件初始化，并切换到相应的操作系统。

■　BSP是相对于操作系统而言的，不同的操作系统会对应于不同定义形式的BSP。例如，某一CPU上的VxWorks BSP和Linux BSP，尽管实现的功能一样，但写法和接口定义是完全不同的。

■　BSP单纯只支持某个硬件板子的配置，无法用于其他板子、CPU或操作系统。举例来说：微软定义BSP是由Boot-loader、OAL（OEM Adaptation Layer）、Device Driver及Run-Time Image Configuration File这几个组件所构成。

Step01：定义HAL的规模（Scope）。根据产品特性，分析上层的系统与应用程序需要哪些硬件功能，这些需求就是HAL必须要包含的基本模块，然后再根据硬件配置，分析是否仍有目前系统没用到的硬件功能，这些功能可能在下一代产品就会被用到，我们可为其设计相应HAL模块的API，但在本项目内可先不implement。

Step02：定义HAL API。如果可以的话，最好从硬件到应用程序的开发小组，都要派人员参与HAL设计工作，否则至少要有资深的系统与固件工程师参与，不能仅由一个部门闭门造车。一般定义HAL API步骤为：
    □　系统工程师说明系统需求，包含系统对硬件事件的处理方式。
    □　固件工程师根据硬件功能，提供第一版的HAL API定义文件。
    □　系统工程师协同固件工程师，逐一review HAL API。
    □　在HAL API立项前，必须针对项目中的所有软件工程师做详细报告，收集建议，并做必要的修正。

Step03：由固件工程师负责实现所有HAL的功能，并执行每个模块的单元测试。

Step04：固件工程师release第一版HAL library，由系统工程师负责整合测试，若有需要。各个部门随时可以提出对HAL API增修的建议。

■　往前兼容（新版HAL的API可以变多，但不能变少）。

■　HAL旨在对硬件做抽象化，不应与任何系统有直接关系。若OS对driver有特殊的需求（如Linux有制式的driver写法），应由系统团队根据需求自行在HAL之上，再往上包一层high level driver。

■　Driver模块化，尽量降低driver之间的耦合程度。这个原则相当重要，因为我们设计HAL的主要目的之一，就是未来项目的硬件配置可能改变，而我们只要切换驱动程序即可。若driver间耦合度过高，则系统的可移植性与HAL的优势将大打折扣。

■　每个driver分别设计，但章节内的结构必须保持一致，应该包含以下信息。
    □　数据结构
    □　API
    □　控制流程或状态机
    □　会产生的硬件事件，以及事件传递流程
    
■　每个driver模块应该尽量包装出以下的API，以保持所有driver模块的API风格一致，使得系统在使用HAL API时，比较不会发生误用的状况。  
    □　Open（）：执行该设备的初始化工作（包含硬件初始化、取得driver所需之buffer、数据结构或配置的设定）。
    □　Enable（）：driver开始运行。
    □　Disable（）：driver暂停运行。
    □　Close（）：关掉硬件设备，还回已配置的buffer，重设（Reset）driver的数据结构或配置。
    □　Set_Power_mode（）：设定该设备的power mode（如full run、idle、sleep mode），即便有些设备无法实现这么多种的power mode，甚至有些设备根本不需做电源管理，HAL设计者还是可以考虑为此设备包出空的Set_Power_mode（）函数，以保持所有driver API的一致性。
    
■　driver与power manager的配合：driver仅提供电源管理的mechanism，而电源管理的policy由系统的power manager统一管控，即HAL中的每个driver模块都必须配合power manager的需求，例如都必须实现Set_Power_mode（）这样的API。

■　HAL的每个driver模块都必须遵守共同命名规则与API style。

■　统一定义HAL的系统配置（Configuration）：这些配置必须开放给系统使用，使得本项目不需要的driver模块或功能不会被link进来.

■　HAL API：系统可以直接调用HAL开放的API。

■　ISR & Hardware Event：当硬件产生中断时，相应的ISR会被执行；当ISR处理完毕后，可将硬件事件抽象化，包装成硬件事件，往上层系统传递。以低电压事件为例，驱动程序自硬件读取的是AD值，必须将其换算为电压值（此举即为抽象化），并对上层传递此硬件事件。
    □　驱动程序可以把一个全局变量当作flag，当上层程序发现此flag的值改变了，即表示发生了某硬件事件。这种做法的时效性较差，且必须注意Critical Section的保护。
    □　在ISR内调用系统的功能，如send_message（）、wakeup_task（）等，这种做法是比较普遍的做法，但此举破坏了HAL必须与上层系统无关的规范。
    □　较好的做法是HAL不决定传递硬件事件的机制，改为提供API，让系统可‘注册’用以传递硬件事件的函数（称为callback function），ISR会在适当时机调用这些callback function，至于系统如何处理硬件事件，ISR并不会知道。

■　Callback：HAL提供注册callback function的API，并明确说明调用此callback function的时机。系统只要传入function pointer，HAL即会在上述时机调用这些callback function。例如上面所说的实时处理硬件事件，或是当HAL准备关机时，会去调用系统预先注册的callback fimction，让系统有机会做一些处理（如存储重要信息或目前的执行状态）。

■　可了解电路设计的主体，在设计阶段就可发现固件编写时必须特别注意的项目。

■　若对某外部设备的控制方式不是很有把握，可以在电路设计时，请硬件人员预留其他设计方案（举例来说，驱动程序可以用SPI接口控制SD卡，也可以外接一颗SD card Controller。前者电路简单、成本低、速度慢；后者则刚好相反。在设计阶段，系统工程师不见得有把握使用SPI接口就可以符合产品应用的需求，此时可以请硬件工程师将两个方案都做到target board上）。

■　不仅仅只有硬件工程师才可与硬件原厂联系，固件工程师也应该尽可能寻求原厂的协助，并多与硬件工程师交换意见。

■　事前的讨论，胜过事后的争执。

1. 烙铁： 焊板子
2. 看懂电路图： 电路图是一种语言，它沟通的方式是利用简单的线段和符号去叙述组件之间的关系，电路图里包含各个组件及其PIN脚的名称，及所有组件之间的连接关系。
3. 电源供应器： 这你得会用吧
4. 三用电表： 高中物理就用过
5. 示波器： 大学物理有用过。 
trigger（触发）功能是使用示波器一定要会用的技巧，示波器预设一直从探针中收集信号，即便探针没有点在有意义的测点也一样，一旦启动了示波器的Trigger功能，其设定决定了当信号发生某种变化时，示波器才会再开始显示波形，并记录一段时间内的波形变化。

■　CPU Internal SRAM——CPU 内部有两块 RAM，分别是 40K Bytes 与 16K Bytes。作为LCD控制器的Video RAM，或用来加速程序模块的执行性能。

■　外部NOR Flash——1M Bytes。用来放置程序与data，且程序可以在NOR Flash中直接执行，这块存储器也可以用Mask ROM取代。

■　外部SRAM——512K Bytes。执行时期放置程序的所有变量（data段与bss段）、程序执行时所需的Stack Memory、以及动态配置存储器（Dynamic Allocation Memory）或缓冲区（Buffer）。

■　SD Card。我们的系统可支持SD Card，额外的大批数据可以存储在SD Card中。

■　放置在rodata区（Read-Only Data Section）,程序中只要用数组的名称即可操作这批数据。

■　如果上述数组不定义为const，则这批数据会被连接到data区（有初值的全局变量）。data区的数据也会占据可执行文件的空间，在执行时期会被复制到RAM中，所以程序可以改变这个数组的值。这个方法会加快操作这批数据的性能（RAM速度一定比Flash快），缺点是执行时期时同一批数据分别在RAM与Flash占据一份空间。如果没有改变内容与加速的需求，这么做实在是浪费空间。

■　当NOR Flash或Mask ROM空间所剩不多，但RAM的空间还充裕时，有时候我们会考虑将这批数据压缩。

■　程序段（text段与rodata段）：可直接在ROM或Flash中执行，也可将某个模块传输到速度较快的RAM里执行。

■　有初始值的全局变量（data段）：会占据可执行文件空间，执行时期必须将其从ROM或Flash传输到RAM。

■　没有初始值的全局变量（bss段）：不会占据可执行文件空间，执行时期必须将该区段的内容全部设为0。

■　Stack（堆栈）。

■　在执行“call”指令时，会将返回地址存储（Push）到目前SP寄存器指到的位置（SP始终指到Stack的顶端）。

■　当执行“ret”（Return）指令时，会自目前Stack的顶端取回（Pop）返回地址。

■　当中断产生时，中断控制器会将发生中断的地址（返回地址）以及PSR（状态寄存器）存储（Push）到Stack里。

■　当ISR执行“iret”（Interrupt Return）指令时，CPU会从目前Stack顶端Pop出PSR与被中断的地址。

■　我们都知道Stack这个数据结构特性就是先进后出，CPU提供“push”与“pop”指令供程序员操作Stack，最常见的用途就是暂时将某些存储寄存器的值存在Stack中，在某些动作后，再‘依次’取回这些寄存器的值。此外，“push”与“pop”的动作必须是对称的，push多少东西到Stack，就必须记得依次pop多少东西出来，否则下次存取Stack时就数据就会乱掉。

■　Local变量会存储在Stack中，如果应用程序工程师不知道可以用的Stack有多大，一不小心就会把Stack用爆了。此外还要注意的是，用于嵌入式系统的编译器通常不会产生‘将局部变量的值设为0’的code，也就是说，一旦程序员没有明确指定局部变量初值的话，局部变量的初值可能是任何的值。如果程序员疏忽将没给初值的局部变量拿来使用，则结果自然是无法预测的.

■　函数调用时，返回地址当然会根据目前SP寄存器，存储在Stack中，这是CPU的机制，C语言的函数自然也是如此运行。

■　函数调用时参数的传递可以通过寄存器，也可以通过Stack，端视编译器的策略而定。通常如果参数个数不多的话，编译器会倾向用寄存器来传递参数，反之，则把参数存在Stack 中。

1. Keil C compiler 会分析每个函数之间的调用关系，使用stack的大小等等，，在编译完成后会生成*.M51文件，里面会告诉你stack还剩下多少空间

2. 将函数的局部变量配置到外部固定RAM中（通过外接一个RAM解决）。
甚至会把没有调用关系的函数的局部变量，配置到同一处空间中，这个方法叫做**data overlaying**

3. 高级的Keil C版本会把没有被调用的函数自动省略掉

■　First-Fit：自Memory Pool中存储器队列的开头往下找寻，直到寻得第一块空间大于或等于N的可用存储器区块。

■　Best-Fit：寻遍整个存储器队列，选择一块空间最接近N的可用存储器区块。

■　Worst-Fit：选择一块空间最大的可用存储器区块。有时采用此法的原因是size最大片的存储器区块段使用了一部分后，仍可供其他程序使用，减少小片段存储器区块的产生。

■　取一适当常数n，若配置后剩下的存储器size小于等于n，则整块存储器都分配给要求配置存储器的程序，这样可以减少小块存储器区块的产生。

■　将存储器队列构建成环状队列，每次搜寻可用存储器区块都自队列的不同点开始搜寻，使得小块存储器可以尽量均匀分布在整个队列中。

■　程序归还存储器区块时，系统必须检查该存储器区块的邻边是否也是空闲区块。如果是的话，必须将其合并为较大的一块存储器区块。

■　allocate 了一块存储器，当不使用后却没有归还，这样就会产生一个垃圾碎片。如果这个有问题的模块一再被执行，系统累积的垃圾碎片就会越来越多，最后终于导致程序要不到任何存储器可以用。

■　负责allocate动态存储器的程序与负责free的程序属于不同的模块，这也是碎片产生的原因之一。主要是因为不同模块的设计逻辑、设计理念与负责工程师可能都不相同。实际上，这种设计方式确实经常造成有些存储器区块没有被free，应该尽量避免这样的设计。

■　连size很小的存储器区块（如一个short int）都要向系统allocate。这样的程序风格未免有点矫枉过正了，无谓增加Memory Pool中的区个数，对动态存储器管理系统的性能自然会有所影响。

■　因为动态存储器管理程序会把邻接的未使用的存储器区块merge成一块，所以工程师在配置与free存储器区块时要稍微考虑一下顺序，有时候稍微改变一下顺序就可以避免碎片的产生。

Step01 ：将Binary File转换成烧录器控制程序可接受的格式，如HEX或S-Record，这些都是标准的格式，通常烧录器或编译器套件中都会包含相关的转换工具。

Step02：载入欲烧录的文件。

Step03：擦除（Erase）存储器芯片的所有内容。有些存储器芯片不能用控制的方式，必须先经过紫外线照射，才能擦除存储器芯片内的所有内容.

Step04：将欲烧录的内容写入Program存储器芯片。

Step05：自烧录完毕的存储器芯片中读出内容与原始数据比较（Verify），确认烧录的正确性。

■　虚拟存储器（Virtial Memory）:要让程序认为自己有足够大的虚拟存储器空间可使用，通过CPU所提供之虚拟地址与物理地址的转换机制，暂时没用到的存储器内容可以存储在Secondary Storage （如硬盘、NAND Flash）中，当程序access到相应的虚拟地址时，CPU会产生硬件事件（Page Fault），通知系统从Secondary Storage置换存储器内容。而这一切对应用程序来说都是透明的。

■　动态载入：并非所有的CPU都会提供虚拟存储器的功能，但系统仍可使用Secondary Storage当主存储器的缓存区，只有在需要某个程序或数据区段时，才将其载入主存储器的特定位置。因为这个方案没有CPU介入，系统或应用程序必须做较多的处理。

■　Banking： 8 bit MCU的寻址空间只有64 KB，对较复杂的应用远远不足，就算使用较大的物理存储器也无法突破MCU既有的硬件限制。一般的解决方案为系统可利用GPIO模拟地址线，扩充寻址空间，使得系统可以使用大于64 KB的存储器。大部分Compiler都会提供banking的支持，即系统只要提供操作模拟地址线之GPIO的程序，Compiler会处理相关寻址的工作。对应用程序而言，寻址空间扩充也完全是透明的。

■　虚拟地址：以32 bit的CPU来说，应用程序会认为其有完整的4 GB空间可用，但物理存储器当然不会那么大，所以应用程序可使用的空间称之为虚拟存储器空间，而应用程序指令送出的地址都是虚拟地址。

■　物理地址：顾名思义，物理地址就是实体RAM的地址。CPU里的MMU （存储器管理单元）和操作系统要做的事情，就是将应用程序传来的虚拟存储器转换为物理地址，并将正确的内容放到这个物理地址。

从软件来看，应用程序与操作系统用的都是虚拟地址，但操作系统必须维护虚拟与物理地址的对应表，因为地址对应的基本单位为Page （Page Size乃基于CPU的设定），所以称此表格为Page Table。

在存储器的特定地址中保留空间给动态载入模块使用，则这些模块在编译/连接阶段都可以连接到这个已知地址，从而避开了动态连接的麻烦。

解决了动态载入模块的寻址问题后，另一个麻烦是因为要被动态载入的程序段并未与系统程序连接，所以无法直接调用系统功能。有几种做法可以解决这个问题，一种是用Software Interrupt指令，利用寄存器或Share Memory传送系统功能编号与参数（例如，规定系统功能os_draw_pixel（x, y）为第5号功能），而系统可以从Software Interrupt ISR启动动态载入模块所需的系统服务。举例来说，嵌入式系统操作系统free-DOS就是利用硬件中断（Software Interrupt）来提供系统服务。
并不是所有的CPU都有提供Software Interrupt指令，此时，系统必须设法让动态载入模块可以取得每个open API的实际地址，最简单的方式就是建一个表格，并放置在存储器的特定地址。图12-18所示是一种实现方法的流程。
这个范例的系统配置为：系统与内部API烧在NOR Flash内，动态载入的模块则存储在SD card内，这些程序段都被寻址到SRAM中固定的地址。当动态载入的模块调用了system_call1()这个系统函数，其实是执行了下图所示的步骤3、4，而这些动作对该模块而言都是透明的。

■　有两块64 KB的ROM。
■　当GPIO #1为High时，CPU的地址线与chip select都接到第一块ROM。
■　当GPIO #1为Low时，CPU的地址线与chip select都接到第二块ROM。

■　函数与变量位置配置优化。
■　应用程序只管直接做函数调用，不需要处理Bank-Switch相关工作。