自己写的一个软件设计框架，写的不好，欢迎拍砖
软件框架设计说明
软件底层及代码编写
软件框架设计说明
1.*.c 和 *.h
每一个.c文件需要对应一个.h文件（除去包含主函数的文件）。
例如：PLL.c和PLL.h。
2.*.h文件内容
*.h文件主要是声明一些宏定义、一些全局变量，并且这些变量是否可以被外部使用，以及函数的声明，在头文件的开头需使用自锁的机制，防止头文件重复包含。
如：#ifndefPLL_H
#definePLL_H
/* put your own code here */
…
#endif
3.*.c文件的内容
*.c文件的内容定义函数接口以及函数的实现，并且需要包含与其对应的*.h文件。
4.注释编写
在每个文件的开头都需要编写注释，注释的主要内容有：文件名、作者、日期、版本、版权等信息，
例如：/*!********************************************************
* @file *.c
* @brief 源文件
* @authorXXX
* @version X.X
* @date2010-8-18
* @warning
* (c) Copyright 2011,
* All Rights Reserved
*
*********************************************************/
在定义每个函数之前也需要编写注释，主要内容有：函数名、实现功能、返回值、参数、注意事项等，
如：/*!********************************************************
* @fn void Mcu_Init_v_s (void)
* @brief 单片机硬件资源相关部分初始化函数
* @param void
* @return void
* @note
* - 包含片内片外所有模块
*********************************************************/
5.设计软件结构
再设计底层软件需要遵循层次结构，这样使得软件的编写变得更加清晰。
如：
硬件层：主要是CPU芯片寄存器定义，内存的分布，以及端口的使用方法。
硬件驱动层：主要是初始化各个模块寄存器，并且给出各个模块使用的接口函数，提供给上层使用。
嵌入式操作系统：基于驱动层，建立一个基本时序，通过切换不同的任务来完成主要的功能。
嵌入式应用层：通过添加任务来完成特定功能，其特点是不再需要软件编写者关心硬件，主需要使用函数接口即可完成任务。
暂时先写这些，再想想有什么要写的！！！
建议注释参考Doxygen的规范，这样可以自动生成文档。 netawater 发表于 2013-1-25 15:46 static/image/common/back.gif
建议注释参考Doxygen的规范，这样可以自动生成文档。
谢谢，我会参考的，不过这是公司规定，我自己写代码，还是比较倾向Linux代码规范！！！ 写得不错……不过缺乏更多细节……因为从目前的内容看来，看不出这是个构架，应该说楼主公布
的内容只是成为一个构架最基础的东西，甚至不包含形成构架的关键内容——就一个模块来说，
需要有三部分内容：环境、配置的输入机制、接口的输出机制。目前从楼主公开的内容来看，环境
和配置的部分缺失，而接口的输处机制也很模糊。
我们期待更详细的内容。
最后，我想说，作为一种不同的风格，我不赞成.c包含自己的.h，也就是比如usart.c不要包含自己的
usart.h。 Gorgon_Meducer 发表于 2013-1-26 16:17 static/image/common/back.gif
写得不错……不过缺乏更多细节……因为从目前的内容看来，看不出这是个构架，应该说楼主公布
的内容只是成 ...
以前写C一直这样用，还真不知道这样包含有什么不好的地方。麻烦好孩子指点哈 一般会建一个总的.h文件，如config.h，在里面去包含所有的.h文件，然后所有的.c文件去include config.h 我一般是模块h文件中包含所需要的h文件，然后在c文件中包含自己的h文件。
想听听傻孩子详细讲一讲。 一般会有一个hal层，隔离驱动和应用，另外自己写着玩的时候会弄一个configure.h把所有的头文件都包进去。。。虽然也知道不好。。。但是快。。。 北小斗 发表于 2013-1-26 16:40 static/image/common/back.gif
以前写C一直这样用，还真不知道这样包含有什么不好的地方。麻烦好孩子指点哈 ...
我没说不好，而是说他没说什么实质性的东西……你不觉得楼主说的内容几乎是大家都知道的事实么？ error_dan 发表于 2013-1-26 17:35 static/image/common/back.gif
一般会有一个hal层，隔离驱动和应用，另外自己写着玩的时候会弄一个configure.h把所有的头文件都包进去。。 ...
先不说这个configuration.h包含全部的.h好还是不好，这至少提供了一个 输入配置信息、接口输出 以及 环境配置
三要素综合在一起的方案——虽然缺点就是没有把三个职能分开——但好歹不缺。我还是期待楼主能在这个方向上
提供更多信息——因为他没说，也看不出他没有。
大家都加油~我觉得这个帖子有潜力。 N多头文件 用一个 inlude 其他C再去inlude它当项目比较大，C文件比较多 稍微改动下h文件，编译就可以去悠哉悠哉倒水 Gorgon_Meducer 发表于 2013-1-26 18:12 static/image/common/back.gif
我没说不好，而是说他没说什么实质性的东西……你不觉得楼主说的内容几乎是大家都知道的事实么？ ...
之前没仔细看楼主的帖子，现在看看确实是很基本的东西，谈不上软件框架，更像是一个代码规范。 跟框架有什么关系，没什么新东西嘛………… Gorgon_Meducer 发表于 2013-1-26 16:17 static/image/common/back.gif
写得不错……不过缺乏更多细节……因为从目前的内容看来，看不出这是个构架，应该说楼主公布
的内容只是成 ...
感谢傻孩子，我之所以把它贴出来就是希望找出些问题，非常感谢，我会继续写更多的东西出来，希望大家都提提意见！！！ 生命在于折腾。 qufuta 发表于 2013-1-26 22:49 static/image/common/back.gif
感谢傻孩子，我之所以把它贴出来就是希望找出些问题，非常感谢，我会继续写更多的东西出来，希望大家都提 ...
期待你把它完善，最重要的是把为什么那么做写出来。也许别人有更好的做法，但那是别人的，不妨碍你拥有
自己的构架方式。我也有很好的设计理念，但这不会成为我轻视任何一个人尝试的理由。欢迎出来交流！ Gorgon_Meducer 发表于 2013-1-27 00:15 static/image/common/back.gif
期待你把它完善，最重要的是把为什么那么做写出来。也许别人有更好的做法，但那是别人的，不妨碍你拥有
...
谢谢，但是我想在继续写下去之前，请问傻孩子，能不能和我说说，关于你所说的，"环境、配置的输入机制、接口的输出机制"具体是指什么，能不能举个小小例子，比如，环境是指编译的环境吗？配置的输入机制是类似端口配置的机制吗？？？不好意思，我以前做单片机，总是先写代码，很少写文档，但是现在感觉，这些东西很重要，你提出的问题，我在网上查过，自己也思考过，但是我不能确定，你指的是什么，希望傻孩子能指点下，问题问的也许比较菜鸟，但是还是还是问了，谢谢，当然在你没回答我之前，我自己在思考下！！！ 顶楼主，希望楼主写出更多好东西。
学习了。 期待楼主，期待高手 1.先来说说模块吧，模块有两个部分组成，接口和实现，当我们设计一个一个模块时，必须要设计对应的实现其功能的函数，我认为这样的函数就能称为接口，说白了函数接口就是指明了模块要做什么，他声明了一些标示符、类型、变量，而实现则是表明如何完成其接口所要求功能的代码，其实说白了，接口我们是看不到这函数的实现代码的，也就是大家常说的“黑盒子”。
如：我要设计一个A/D模块，那么这个模块当中就会有两个文件，一个是*.h的头文件和对应的*.c的源文件，一般在我的头文件中会有一个
#ifdef AD_GLOBALS
#defineAD_EXT
#else
#defineAD_EXTextern
#endif
这个宏是表示是否需要将变量或者函数声明为外部可用，如果要是使用，则需要在对应*.c文件开头定义一个宏，例如：#define AD_GLOBALS。
并且我将头文件分成三个区域：宏定义区、变量声明区、函数声明区。
2.在我的软件中，往往会有一个“Includes.h”这个头文件不对应任何源文件，而是每个源文件都会包含这个头文件，这个头文件包含了所有模块对应*.h的文件，当然这点也有个坏处，就是如果你的模块很多，并且代码量很大时，也许只是改动了“Includes.h”很小的一部分，但是几乎所有原文件都要编译一遍，时间会比较长。
3.一般每个模块都会有初始化函数接口，这些函数接口一般都设计为对寄存器的一个初始化，没有输出也没有输入，
如：
暂时写这些东西，写的不好，希望多给出意见，也希望其他人能分享下其他的嵌入式软件的框架，希望傻孩子能说说他的软件框架！！！ xymxym 发表于 2013-1-26 16:58 static/image/common/back.gif
一般会建一个总的.h文件，如config.h，在里面去包含所有的.h文件，然后所有的.c文件去include config.h ...
工程大了你就知道问题来了 qufuta 发表于 2013-1-29 11:05 static/image/common/back.gif
1.先来说说模块吧，模块有两个部分组成，接口和实现，当我们设计一个一个模块时，必须要设计对应的实现其功 ...
我的框架在很多地方都说了，《深入浅出AVR精要》14章有比较详细的谈起。
我的另外一个帖子里面还有培训PPT http://www.amobbs.com/thread-3912026-1-1.html
其实更详细的方法我计划在新书里面用整整一章展开，估计可以写五六十页吧——到不是有多复杂，
而是我想把我的推理和思考也写进去，真正的东西，浓缩下来，估计半个小时就讲清楚了。 Gorgon_Meducer 发表于 2013-1-29 12:20 static/image/common/back.gif
我的框架在很多地方都说了，《深入浅出AVR精要》14章有比较详细的谈起。
我的另外一个帖子里面还有培训PP ...
非常感谢，学习了，先看下你的思路，我再接着写下去，感谢！！！ 4.标准数据类型定义
如：typedef unsigned charBOOLEAN;
typedef unsigned charINT8U; /* Unsigned8 bit quantity */
typedef signed charINT8S; /* Signed 8 bit quantity */
typedef unsigned int INT16U; /* Unsigned 16 bit quantity */
typedef signed int INT16S; /* Signed 16 bit quantity */
typedef unsigned longINT32U; /* Unsigned 32 bit quantity */
typedef signed longINT32S; /* Signed 32 bit quantity */
typedef float FP32; /* Single precision floating point */
typedef double FP64; /* Double precision floating point */ 学习了 标记下 不太懂C，正在学，用汇编5年了，写些比较简单的程序，一直也没注意规范，现在换公司了才开始意识到框架这些问题 本帖最后由 onepower 于 2013-1-30 10:46 编辑
楼主的想法很好, 这个是早就应该做的事情, 但是有一些不足:
1. 缺乏总纲思想, 使得细节表达能力太弱, 缺乏细节;
例如: 楼主代码中的 PLL.c和PLL.h, #ifndefPLL_H, Mcu_Init_v_s, 为什么PLL.h中的h是小写, PLL_H中的H是大小?? PLL为什么是全部都大写, 而Mcu为什么只有第一个字母是大写呢?? 那INT16U这个为什么要全大写呢?
2. 缺乏论证, 很多地方知其然而不知所以然;
提出一个问题: 这么多的 数据类型定义 byte, BYTE, byte_t, uint8, u8, u8_t, uc, uchar, c8, UINT8, INT8U, b, 到底哪个最好? 为什么!
3.缺乏范式思想: 设计软件结构基本合适, 但为什么一定是嵌入式系统呢??
在提一个问题: 大家都知道系统的进化, 前后台->协助式->嵌入式; 这系统的进化中间是由什么去牵引的呢? 3大方式中间有什么东西是一直不变的呢??? 有没有想过这3大方式中间还有很多不同的方式呢? 提两个例子: 一个是PT, 一个是分散式加载
4.H文件的include问题
那到底是 把所有的h文件include到一个大的h文件为好呢? 还是 用啥include啥的方式好呢?
模块的c文件include对应的h文件好呢? 还是不include好呢??
那为什么不把C文件和H文件合在一个文件中不是更好吗?
这个都不能只听人家的一面之词, 得去论证才知道 onepower 发表于 2013-1-30 10:43 static/image/common/back.gif
楼主的想法很好, 这个是早就应该做的事情, 但是有一些不足:
1. 缺乏总纲思想, 使得细节表达能力太弱, 缺乏 ...
感谢提出意见，我会认真考虑的，你说得对，我还会继续把他完善下去，谢谢！！！ 1.PLL.h中宏#ifndef PLL_H 之所以大写，因为宏定义，一般用宏定义，我比较习惯用大写（个人习惯），Mcu_Init_v_s用小写，这是因为这是函数定义，顺便说些，这个也是一个设计函数命名方法，一般用宾语+_+动词+_+返回值类型第一个字母+_函数适用范围（extern或者static），这个就是一种习惯而已。
2.到底哪个好，我想是要根据你个人觉得那个定义的让你觉得一眼看到就能知道其类型，并没有那个好或者不好之分。
3.进化是随着功能的增多，或者控制的复杂性而变得复杂，人类社会的进化不也是这样的吗？一切都是根据需要而进化的。
4.之所以要把以模块分为*.h和*.c 是为了屏蔽函数实现的细节，避免调用者更改源代码，这是最主要的原因吧，至于你说的要不要包含所有Include，我想找个是需要根据不同的工程来进行试验的，这个世界上肯定没有一样东西能够通用。
再次感谢你提出的意见，有什么问题我们在交流，如果觉得我说的不好，你可以直接问问傻孩子，他是我学习的对象，呵呵！！！
4. 用config.h包含所有的.h，然后所有的.c去包含config.h有个弊端，就是一些不使用的也被包含进来，而且，对于ucos，ucgui，lwIp等比较大的工程这样搞也容易出现重复定义，有的宏定义重复是不会被编译器报错的，但是运行必然出错~ 楼主既然是设计一个软件框架, 居然不把 "全局,统一,论证,范式,策略"等一些软件思想包含进去, 只凭自己的"习惯"去设计, 那估计这样的软件框架也走不远~~~~ 要么就只能自己用用, 要么就只能在个小库里用用了; onepower 发表于 2013-1-30 15:08 static/image/common/back.gif
楼主既然是设计一个软件框架, 居然不把 "全局,统一,论证,范式,策略"等一些软件思想包含进去, 只凭自己的"习 ...
感谢，有时很犀利的评价，不过我觉得说的的却很有道理，软件框架设计这条路，我还有很长时间要走，你说的那些概念，我都会一一的去学习，我还会继续把他完善，然后说出自己的理由，再次感谢，来到这里提高很多，欢迎多拍砖！！！ onepower 发表于 2013-1-30 15:08 static/image/common/back.gif
楼主既然是设计一个软件框架, 居然不把 "全局,统一,论证,范式,策略"等一些软件思想包含进去, 只凭自己的"习 ...
顺便说句，onepower 能推荐几本书加强我这方面的技术吗？？？谢谢
我来细讲一下:
讲之前先补充两句, 就是在一个人写代码的情况下, 我说的几个问题都是些细节问题, 用与不用影响不大, 但细节体现的是大纲思想,和合作精神,细节处见功力; 1. 对于问题1
我先说变量和函数的书写方式, 一般有4种, 我定义几个名称
(1)大车卡: ABC_DEF_GHI, 全大写字母加下划线组成;
(2)小车卡: abc_def_ghi, 全小写字母加下划线组成;
(3)大驼峰: AbcDefGhi, 单词首字母大写其余小写;
(4)小驼峰: abcDefGhi, 单词首字母大写(第一个字母除外)其余小写;
其他的可以是看作这几种的变型或组合;
再提出一个细节: 对于缩写组成的名称,你是全大写呢?还是首字母大写? 例如:PLL,Pll;
现在转到正题:
楼主位的代码: PLL.c和PLL.h, PLL_H, Mcu_等, 其实楼主心里已经有一个概念, 那就是模块, 而这三个地方同样表达模块这个概念的地方,是一时用全大写表示,一时用首字母大写表示; 这正如 一些函数用车卡式命名,一些函数用驼峰式命名,楼主你会接受吗?
看楼主的回答是这样的, 因为一个是文件名,一个头文件编译开关,一个是函数名; 那这样说, 在程序中到底是"模块"这个概念重要呢? 还是文件名,头文件编译开关,函数名重要呢? 很明显"模块"是程序结构的最基本单位,那用到模块名的地方为什么不统一起来呢??
这里也纠正楼主的一个概念,void Mcu_Init_v_s (void), 中的Mcu_,它其实不是宾语, 而是模块名(即不是主语也不是宾语); 按楼主的这种命名函数的方法, 我推荐使用 "模块名_动宾驼峰"的方式, 这是种车卡和驼峰的混合体, 车卡做划分, 驼峰做描述; 而返回类型和静态属性的描述, 这两点在C和H的结构中已经可以清晰的表达, 所以其实是种冗余描述, 建议去掉;
还有一点是, 函数名称中有一个要素是需要突显出来和关注的, 那就是函数的使用条件和场合, 这也是你告诉别人你的函数怎么用的关键, 所以推荐函数名称扩展为"模块名_动宾驼峰_条件驼峰"; 2. byte, BYTE, byte_t, uint8, u8, u8_t, uc, uchar, c8, UINT8, INT8U, b, 并不是习惯这么简单;
楼主你把数据类型定义为 INT8U, INT16U,... 而不是定义为 BYTE, WORD, DWORD...呢?
这其实主要体现两个问题
(1)数据类型的核心是什么? 符号,和空间, 其他的都是冗余信息....
(2)BYTE是什么数据类型呢? 那也就是问 它是"符号,和空间"是什么, 所以 用BYTE的话, 就存在"二次思维"的问题, 先把BYTE转换出"符号,和空间"才知道他的数据类型;
好了, 根据这两点, byte, BYTE, byte_t,这类的名称有"二次思维"的毛病, UINT8, INT8U,中的INT其实也是冗余信息, u8, u8_t, U8这类就符合要求了;
这是一个很多人都不以为然的细节, 回答的一般都是"用习惯了,什么都行!", 好,那我就问了,这是程序中最常用的东西,你都不把冗余去掉,不避免二次思维的习惯; 你能保证在复杂的应用逻辑中不出现吗? 3.范式这东西太长篇, 其实不管使用什么样的系统, 在应用层里, 都会出现一种程序结构模式, 这就是所说的范式;
复杂的功能是引导系统产生的原因, 但可不是系统结构构建的方式, 不同的系统, 他内在的构建都是耦合和内聚这两个思路的作用,系统的进化很大程度是耦合和内聚的程度的进化,知道这一点,就可以幻变出多种形式的系统出来; 4..H文件的include问题, 其实各种include方式各有各的用处, 只要把他们的优点和缺点都列出来, 就很明显的看出,什么地方用什么方式, 这就是最简单的论证方法; 我只想补充一点：
每个人都有自己的编码习惯。但是请记住：在一定范围内强制推行的编码习惯称为编码规范。
编码规范本质上是编码习惯，但习惯这个东西并不是说可以随意的，也是有道理可循的，这里
我想说一个现象，叫做技术的客观性：
所谓技术客观性是指处于不同背景，彼此没有联系的人，在解决相同范围的问题时，经过足够
长的时间，他们会在解决问题的关键方法和原则上分别导出相同的技术结论。
对于这类拥有客观性的技术或者说习惯来说，即便不同的人认为这是自己的习惯，实际上也是
遵循着某些客观规律的。
由此可以给楼主一个大体的概念：市面上很多流行的做法，不是一拍脑袋就决定的，而是有深
层次道理的，只要经过足够长的时间和思考，你也会得出相同的结论。
虽然有人给你提出了不同的意见，但是我的看法是：如果你没有理解到，没有体会到现有做法
的缺点，就不要轻易改变自己的方式——学习讲究体会到才是学到。 onepower 发表于 2013-1-30 17:22 static/image/common/back.gif
3.范式这东西太长篇, 其实不管使用什么样的系统, 在应用层里, 都会出现一种程序结构模式, 这就是所说的范 ...
既然提到了范式，推荐网易公开里面的《编程范式》 很详细，很具体。 onepower 发表于 2013-1-30 17:23 static/image/common/back.gif
4..H文件的include问题, 其实各种include方式各有各的用处, 只要把他们的优点和缺点都列出来, 就很明显的 ...
关于.c和.h的作用，有很多说法，这些说法彼此之间没有绝对的优劣，基于这种认知，我想说说我对.c和.h的看法：
很简单：
.c是模块本题或者本题的一个组成部分，换句话说模块是由一个或多个.c组成的。极端情况下一个.c就是一个class（OOPC技术）
.h是模块的接口。
--------------------------
以上纯属个人YY，在我的代码空间里面，我是这么定义的，并不代表说这就是.c和.h存在的意义……
其实在某些人的习惯里面.h甚至是另外一个脚本语言。详细情况参考帖子http://www.amobbs.com/thread-5512140-1-3.html
希望有助讨论~ qufuta 发表于 2013-1-30 09:45 static/image/common/back.gif
4.标准数据类型定义
如：
推荐用stdint.h里面的定义……如果你没有想清楚，又不想多口舌，就用stdint.h 一直都在用周立功的代码规范~ onepower 发表于 2013-1-30 17:23 static/image/common/back.gif
4..H文件的include问题, 其实各种include方式各有各的用处, 只要把他们的优点和缺点都列出来, 就很明显的 ...
学习了，看来我之前的学习确实有漏洞，需要加强，多交流啊，感谢！！！ Gorgon_Meducer 发表于 2013-1-30 19:22 static/image/common/back.gif
既然提到了范式，推荐网易公开里面的《编程范式》 很详细，很具体。
傻孩子一直是我学习的对象啊，一直在看你发的帖子，每次都会有新的想法，多交流！！！ 反复看了几位牛人的回复，感觉对自己还是有提高，尤其是对于变量、函数、模块命名来说，感觉之前的确有些模糊不清的问题，现在需要注意把他搞清楚，不知道还要不要继续写下去，还有什么可以写的呢，框架这个水挺深的，真的想把这些软件框架，OOPC等这些多学习下，成为自己的东西，还是多看书吗，多练习！！！ qufuta 发表于 2013-2-1 16:36 static/image/common/back.gif
反复看了几位牛人的回复，感觉对自己还是有提高，尤其是对于变量、函数、模块命名来说，感觉之前的确有些模 ...
不要在命名规则这种事情上浪费时间，对他的理解是受到你综合素质的影响的，换句话说，只有
你其他能力提升了，他才会追随着你的平均水平而提升。
你需要花更多精力在你现在欠缺的东西上。比如数据结构啊，操作系统的简单原理啊，OOPC技术啊
之类的…… Gorgon_Meducer 发表于 2013-2-2 21:38 static/image/common/back.gif
不要在命名规则这种事情上浪费时间，对他的理解是受到你综合素质的影响的，换句话说，只有
你其他能力提 ...
好的，多谢傻孩子指点，之后我会发一些我做的一些东西，请大家多指教，谢谢！！！ mark。学习一下。 好久不来了，跟大家讨论个问题，大家对于嵌入式子系统设计、嵌入式层次框架设计等，最近对这个很感兴趣，不知道大家对于这个有没看法，当然，希望傻孩子能作为我们的老师多指点我们，我希望和大家交流的是，这几个问题：
1.嵌入式子系统设计
2.嵌入式系统接口设计
3.嵌入式软件层次框架设计
关注中！！！ 学习一下。 mark 本帖最后由 Gorgon_Meducer 于 2013-3-18 16:37 编辑
qufuta 发表于 2013-2-20 19:50 static/image/common/back.gif
好久不来了，跟大家讨论个问题，大家对于嵌入式子系统设计、嵌入式层次框架设计等，最近对这个很感兴趣，不 ...
你这是嵌入式典型的三明治结构。一般的裸机构架都是这样的。
其中，最底层叫做硬件抽象层（Hardware Abstract Layer），主要是处理硬件和处理器的细节
为上层系统提供一个硬件无关的平台。一般来说，硬件抽象层内部还有三个较为细致的分层，
一般是构件层（Component），板级支持包（BSP），外设驱动层（Driver）。
中间 的层次一般都是一些纯粹硬件无关的的服务，因此又叫服务层（Service Layer）。比如
数据结构的服务程序啊，各类协议栈啊，各类基础的通用算法啊，调度器啊什么的，都属于
服务层。
最上层，就是所谓的应用层（APP Layer）。一般来说用户代码就在里面了。
其实，APP Layer，也就是用户的应用程序也是可以分层的，这个我就不具体说了。
一般来说，接口设计都是基于"黑盒子封装原则"。模块之间的调用关系也是有成熟的规范的。
大体总结如下：
黑盒子封装原则：
1、每一个模块由一个实现功能的黑盒子，以及外界调用黑盒子的接口组成。前者是.c或者
内部的子模块，后者是一个与模块同名的头文件构成。推荐黑盒子本身不包含这个接口
头文件。
2、黑盒子是一个双向约定，即：服务的使用者不想知道实现的细节，只关心结果；同时，
黑盒子的实现方不想向外界公布自己的实现细节，只关注接口约束。
3、黑盒子系统只在接口头文件中公开调用黑盒子所必须的最小信息。
模块间调用原则主要有三条：
1、所有调用基于接口头文件——就是前面说的每个模块都提供的接口头文件。这个调用原则
上应该由具体的.c模块来包含对应的接口头文件来实现（不提倡由本模块的接口头文件来
包含目标模块的接口头文件。）
2、跨部门调用原则：如果要调用一个别的模块（部门）的子模块（子部门），则只能通过
包含（include）别的部门的顶级接口（部门）来实现，不允许越级调用（增加了耦合度）
3、平级调用原则：如果要调用同一个大模块（同一部门）下另外一个平级部门（模块）下
属的子部门（子模块），则只能通过调用同级别的部门（平级模块）来实现。
以上2、3两条可总结为：调老大原则。
希望这些信息对你有所帮助。这一技术就是现在流行的面向接口开发（Interface Dependent
Development / Interface Based Development）
Gorgon_Meducer 发表于 2013-3-18 16:22
你这是嵌入式典型的三明治结构。一般的裸机构架都是这样的。
其中，最底层叫做硬件抽象层（Hardware Abst ...
我现在就在思考这些问题，想把这些架构变成基于单片机操作系统的一个架构！可以有很好得移植性，做一个简单得操作系统！水平不高！希望多请教大家！之后有时间上个代码！更实在！ qufuta 发表于 2013-3-19 11:18 static/image/common/back.gif
我现在就在思考这些问题，想把这些架构变成基于单片机操作系统的一个架构！可以有很好得移植性，做一个简 ...
我的经验是：无论别的东西多好，构架这种东西，一定要自己设计。除非你是
在一个拥有系统构架师任职的团队里面效力。 很详细，很具体。 一般到了公司都有公司的编程规范，不允许个人在来一套的！{:tongue:}
页:
[1]