FireBLE(3)——工程架构及源代码移植的说明

例程的工程架构

今天抽些时间学习了工程的结构，对于已经把底层什么都写好的工程，只需在其上面添砖加瓦就可以构造自己的程序。感觉目前自己学习这开发板完全有点像盲人摸象，好久没碰这些东西，真的没那么快容易上手。

今天学习的参考资料，就是官网上的：http://wiki.t-firefly.com/index.php/FireBLE/Source_code_port

工程是如何构成的

下载的源码有两个文件夹，一个是BLE，一个是Driver。其中BLE文件夹存放的是各种跟BLE有关的工程例程，以pri_xxxx出现，还有一个src子文件夹，存放的是跟这些例程都有关系的代码。Driver文件夹存放的是底层驱动，比如GPIO，UART等。
选择一个prj_xxx工程打开，结构如下：

对于这种结构，解释如下：

对于主机设备来说，我们更多的是在app目录下做开发；对于从机设备来说，我们更多的在usr目录下做开发。

源代码的移植

参考教程中的一段原话来理解为何宏定义CFG_FireBLE，FireBLE_platform。

现在我们来看，为什么在定义QN_9021_MINIDK之前要定义CFG_9021_MINIDK，这不是多次一举吗？不然，其实这正是为了更好的维护代码，分隔代码相关性。

app_config.h是属于公共配置文件，存放在多个工程公用的src文件夹中的app文件夹内，每一个工程使用的都是同一份代码。从理论上来说，为了代码的移植性考虑，我们希望只要修改工程内的usr_config.h就能实现对开发平台不同的切换并且不影响到其他开发平台的使用。也就是说，在不这样设计的情况下，如果我在A工程中使用的是FireBLE，B工程中是用的是QBlue 9021 MINI DK,如果我因为要在B中使用QBlue 9021 MINI DK，我需要在app_config中关闭了FireBLE_platform的宏定义，开启QBlue 9021 MINI DK，那么，A工程就无法正常运行了，反之，则两个工程十分独立，完全无影响。

另外附上该FireBLE开发板的参数说明：

总结

前人建好的工程架构是为了让后来者更加快速的开发，忽略掉底层的一部分东西（驱动已经有了，只需要知道怎么使用）。但是对自己来说，也会让自己没有了底（以前自己写硬件程序都是从底层一步步摞起来的），不过这也是好事，现在注重开发效率，产品注重开发进度。不可能有那么多时间让你一步步构建起来一个工程应用。自己要渐渐习惯这种模式。