分层与模块设计：头文件
做“平台”的简单思路：
------------------------------------------------------------------------------------------------------------------------------------
\include
-- config.h //平台配置文件
-- type.h //平台基本类型定义文件
-- api.h //平台接口及数据类型定义
-- all.h //平台对外头文件，包括以上三个文件。这四个文件可以合并成1个或2个。
\level1
-- level1.h //level1层公用头文件
-- \mod_1a
-- mod1a.c //all.h, level1.h, mod1a.h, mod1b.h(if necessary)
-- mod1a.h
-- \mod_1b
-- mod1b.c //all.h, level1.h, mod1b.h, mod1a.h(if necessary)
-- mod1b.h
\level2
-- level2.h //level2层公用头文件
-- \mod_2a
-- mod2a.c //all.h, level1.h, level2.h, mod2a.h, mod2b.h(if necessary)
-- mod2a.h
-- \mod_2b
-- mod2b.c //all.h, level1.h, level2.h, mod2b.h, mod2a.h(if necessary)
-- mod2b.h
------------------------------------------------------------------------------------------------------------------------------------
说明：
1、平台通过config.h定制，平台编译宏需满足产品预期（非完全一致）
1）平台基本数据类型是自洽的，通过编译宏规避重复定义的问题。（此时，平台编译宏和产品不一致）
2）平台cpu、os、大小端等类型定义，需和产品保持一致
3）平台规格定义。建议定义为最大规格，而产品规格通过定制参数传递给平台。
2、逻辑上level1调用level2，level1是抽象层，level2是实现层，因此需要引入DIP（依赖倒置）策略，只允许level2调用level1，通过回调函数即可实现。
level1.h的目的有两个：level1层公用头文件，提供给其他层次的头文件。
3、模块间可能存在互相调用接口的情况（应避免引起全局变量），所以可能互相包含对方的头文件。这个时候，要避免形成头文件的依赖。
（有依赖说明模块划分或数据结构设计不合理）。如mod1a.h, mod1b.h不允许存在依赖关系，mod2a.h, mod2b.h同样如此。