嵌入式软硬结合线路板设计，你知道该怎么做吗？

            嵌入式软硬结合线路板设计，你知道该怎么做吗？
     嵌入式硬件工程师的工作是为软件工程师搭建好硬件平台和必要的开发环境。 嵌入式软件工程师则是根据用户的需要完善产品的软件功能。硬件工程师就像是设计师和建筑师，负责整个建筑的设计和建设。软件工程师则是负责房间的装修，锦上添花。然而硬件设计需要一定的设计范例，这点对于软件设计却不那么适用。
嵌入式系统设计不仅要了解硬件还应该了解它与软件之间的相互影响和作用。目前国内一个普遍被认同的定义是：以应用为中心、以计算机技术为基础，软件硬件可裁剪，适应应用系统对功能、可靠性、成本、体积、功耗严格要求的专用计算机系统。形形色色的“高端产品”都离不开嵌入式技术，离不开传感器技术，离不开软件程序。
大多数嵌入式体系的硬件平台，包括两部门：
1、以通用途理器为中心的协议处理模块，用于网络控制协议的处理；
2、以数字信号处理器（DSP）为中心的信号处理模块，用于调制、解谐和数／模信号转换。
从运行平台来分，嵌入式软件可以分为：
1、运行在开发平台上的软件：设计、开发、测试东西等
2、运行在嵌入式体系上的软件：嵌入式操作体系、应用程序、驱动程序及部门开发东西
同专业的人士从各自不同的角度思索和定位嵌入式体系，以是目前对嵌入式体系的定义非常多。
嵌入式体系根据目前业界和学术界对嵌入式体系的普遍见解，因此应用为中心，以计算机技术为基础，软硬件可裁剪，适应应用体系对功效、牢靠性、成本、体积、功耗严酷要求的公用计算机体系。
那么问题来了，为什么嵌入式工程师要软硬结合呢？
其一
软硬结合，更好地实现用户需求，比如输入捕捉，如果是通过上升沿或者下降沿捕捉，加了不合适的滤波电容会造成对沿的破坏，不加滤波电容就会受困于各种空间干扰产生的杂波。
若硬件工程师搬来的是加了不合适电容的电路，搞得沿之间位宽失真，便会出现数据不正常的偶发故障，倘若硬件工程师搬来的是不加电容的电路，搞得软件工程师必须进行软件滤波，把代码搞得又复杂又难解，你说这怨谁来着？
其二
方便定位Bug。爱因斯坦曾经说过，“提出一个问题往往比解决一个问题更重要，因为解决一个问题也许仅是一个数学上的或试验上的技能而已，而提出新的问题、新的可能性、从新的角度去看旧的问题需要有创造性的想象力，而且标志着科学的真正进步。”
钻研硬件电路可以帮助软件工程师提出更多解决问题的思路，发现导致Bug的更多可能性。一般来说，当遇到Bug时，对硬件一知半解的软件工程师只在代码层面上打转转，基本不会在硬件方面提出问题，最终为了迎合蹩脚的硬件设计出别扭无比的代码，却不曾想，只要稍稍改变一下硬件设计，就可以轻松且优雅地完成代码设计。
其三
艺多不压身，求人不如求己。当我们对硬件电路设计起了怀疑，倘若自己悄没声地拿起烙铁飞个线、换个元件，验证了自己的思路，这时直起腰版、拿着板子理直气壮地去找硬件工程师，岂不是顺顺利利，又送顺水人情？
倘若直接拿着板子，心底发虚面上露怯地去找硬件工程师理论，一场唇枪舌战在所难免，腥风血雨不说，到头来硬件工程师硬着头皮给你调调电路，真是解决了问题还好说，若是自己思路错了，那不是自找苦吃？上个班，挣点钱养家糊口而已，当个老好人，和同事其乐融融多好，吵来吵去，搞得那么辛苦，何必来着？
那么如何从单纯的硬件设计过渡到硬软结合的设计，在你着手开发软件时需注意以下八个软件设计技巧。
1、设计控制流程图
工程师进行到开发软件这一步时会情不自禁地开始书写代码。这种思维定势就像在原理图还未完成之前就开始尝试画PCB。当着手开发软件时，克制写代码的冲动，取而代之的应该是软件流程结构图表的设计，这点非常重要。流程图能清晰地呈现给开发人员软件的各个需要的组成部件，正如电路图列出硬件设计所需的各种元器件一样。做到这点能很大程度上使程序整体更易于组织，而且也会减少占开发周期较长的调试工作量进而节省时间减少调试的繁琐。
2、使用状态机控制程序流程
状态机是20世纪优秀的软件发明之一。应用程序一般被分解为多个不同的状态，每一个状态控制一个特定的程序分支。状态机包括内部状态和依据不同激励所控制的状态转换。使用状态机机制设计软件能够使模块化的可维护的软件开发更加容易而且易于理解。状态机原理与算法的示例随处可见。
3、避免使用全局变量
在过去的函数式编程中，程序员使用函数编写程序，他们的唯一目标是使程序尽可能快的运行而不考虑程序的结构和重用性。这类程序风格在使用全局变量时不注意变量的作用范围引起其他函数修改的危险性。这样变量会被多次占用和重写。如今面向对象的程序设计中，成员变量被定义在最小的作用范围之内并封装起来避免被重新复值和滥用。所以建议尽量少地使用全局变量，实在需要的话，使用C语言中的关键字“extern”来修饰。
4、充分利用模块化的设计理念
如果你问一位工程师项目的哪一部分最有可能会拖延交付并超出预估时间，那答案一定是软件周期了。软件通常是复杂而且不易开发和维护的，特别是当项目应用程序集中在一个单一的文件里，或者几个结构松散的文件中时。为了便于代码重用和软件可维护并减小软件的复杂度，强烈建议发挥高级程序设计语言模块化的特性，在程序的结构中把公用的函数分离出来作为一个独立的模块。通过这种方式可以让程序员开始创建包含有常用函数和常用的声明定义，它可以很容易的被其他的代码重用，这在以后的测试阶段不仅可以节省时间代价还能提高代码的质量。
5、中断服务事件保持简练
中断服务事件是中断处理器正在执行的程序，转而去处理触发该中断的外设的请求的一种机制。处理器响应中断请求需要大量的系统开销，具体表现在保存被中断程序的状态（入栈下条指令的段地址、偏移地址和程序状态寄存器，有时还会入栈若干寄存器的值），执行中断服务程序然后恢复中断点继续执行（依次出栈各寄存器），虽然现在的处理器速度非常快但是这种系统开销仍然需要考虑。一般来说，为了避免与主程序冲突程序员总想使中断执行时间减小到最小。这就意味着中断服务事件应该短小简单。不能在中断程序中调用函数。另外，如果中断需要处理的事件特别复杂或者需要花费较长的时间，这个时候中断服务程序应该满足最小的需求，例如将数据载入到缓冲寄存器、设置标志位，而让主程序去处理读入的数据。这样处理器的工作大部分周期都在处理程序而不是中断。
6、使用处理器示例代码测试设备
对于硬件设计，在画板之前标准的测试电路有助于工程师理解电路的特性。同样可以适用于软件设计，半导体厂商通常有测试微处理器各个部分的功能的示例程序提供工程师体验各部分是如何工作的。据此可以提前组织软件的结构并且预知在设计中的问题。提前确定在设计潜在的障碍远比在产品完成前几个小时发现问题更加科学合理。而值得注意的是厂商提供的代码通常不是模块化而且不做必要的修改是很难直接用于实际的软件中的。
7、控制函数的复杂度

在工程设计中有句俗语叫“KISS”，意思是“Keep It Simple Silly”。在处理一些复杂的任务时最简单有效的方法是把它分解成若干个简单的子任务，当任务或者功能很复杂时，人们很难留意所有的细节也很难不出错。当工程师写了一个在当时能够理解的复杂函数，可一段时间后需要维护程序了还能不能清晰的呈现出当初的设计思想这是值得考虑的。有大量的技术来衡量函数的复杂度像“循环复杂度”。经验告诉我们，函数的循环复杂度应该低于10比较好。
8、详细的文档
在激烈的软件开发竞争中关注的焦点很容易就局限在代码的书写和调试而忽略文档的编写。有时迫于压力要求写文档，开发人员通常把文档安排在项目开发的最后的一个环节集中编写。然而给代码写文档应该乘在头脑里面还比较清晰的时候比较关键，这样在后续的开发或者自己阅读注释的时候能很快的回忆起当时的设计思想。