前段时间在大话硬件交流群看到有朋友问如何看原理图？今天想结合21年我在小组内带新员工成长的过程，聊聊这个话题——看原理图。
我自己在画原理时主要用了两款软件，一款是Altium Desinger ，另外一款是OrCAD Capture。在本科时最开始接触就是AD这个软件，一直到毕业也没怎么用过OrCAD Capture。毕业后发现公司使用的软件是OrCAD Capture——Cadnece。
现在两款软件基本都能熟练使用，毕竟只是个用来辅助我们画原理图的工具，这两者无论是在建封装，还是在画原理图时，相差都不是很大，本质都是对电气信号的连接和固定规则的使用。所以，我们在刚开始学习时，不需要纠结目前使用的是哪款软件，选定一款先用起来，等熟练之后，迁移到另一款软件上也会很快。
因此，看原理图时，应用软件不应该成为我们看懂原理图的绊脚石。那到底是什么因素会干扰我们看懂原理图呢？结合我自身和身边同事的工作，我想可能有两个方面的因素会影响我们对复杂原理图的阅读：
整体上，没有使用结构化的
框架细节上，没有掌握模块化的逻辑
整体上没有使用结构化的框架，就好像是房间里面的东西乱放，找起来就比较费劲，可想而知，我们画出来的原理图肯定阅读性也不是很好。对部分人来说，可能还非常费力。而细节上如果没有使用模块化的逻辑，就不知道哪两个模块或者哪几个模块之间存在联系，会把无关的信息也带入进来，多种干扰因素的加持导致原理图理解困难。
看下面这个原理图，整体上看起来就比较结构化，FPGA，DDR，AD_DA都单独作为一个page，这样的原理图看起来就像是房间里面的东西进行了分门别类的摆放，找起来非常容易，理解起来也就相对轻松。
下面这个原理图是不是看起来就要费劲很多。
所以这就要求我们在画原理图的时候，使用结构化的框架来画原理图，别人看起来也比较方便。
上面说的是我们在画原理图的时候，要使用结构化的框架，比较常用的方法是使用Block Diagram，在原理图的第2页呈现单板的整体框架，比如下面这个单板的原理图，在Top层就提供了系统的原理框图。
如果我们拿到单板的原理图没有使用结构化的框架，根据上面两个单板的命名就可以发现，明显是具有结构化的原理图更容易被人理解。所以我想这应该是造成很多人认为原理图比较难懂的原因之一。
那假设我们真的拿到了没有结构化框架的原理图，是否有什么手段可以帮助我们理解呢？答案是——结构化。对，没有错，别人画的十几页的原理图即使没有结构化，我们也可以自主添加，自主划分。在划分的时候，可以使用下面的框架:
任何一个原理图，无论是有框架还是没框架，我们都可以把原理图分为上面这5个类型来看。
电源类
电源类比较简单，一般是电源拓扑，或者电源树，复杂的原理图一般会涉及到多路电源，电源之间具体是如何连接的，暂且可以不做详细的分析，但是把同类型的电源模块划分在一起，会大大降低电源对其他部分的干扰。
比如，在上面的原理图中，可以把下面四个page都看成是电源类。在看其他方面的原理图时，可以不用太在意电源模块，甚至是不看都可以。除非是单独研究电源拓扑，才来对每一个page进行分析。
协议类
协议类主要是常见的像UART，IIC，SPI，RS232，RS485，USB等，这些协议包含的原理图部分我们不需要弄懂协议是怎么工作的，不需要管协议外设之间的时序。比如IIC和SPI哪个先工作，两者之间是否有逻辑联系，这些都不用管，只需要知道每个协议有几根线，协议上的器件哪个是主机，哪个是从机，能分辨出来就行。
比如下面Flash模块，我们只需要知道这四根数据线，片选和时钟连到哪个器件就可以，至于工作时的CLK频率，看懂原理图后再去了解，顺序不能搞反了。
如果在这个模块纠结，为什么平时我见到的SPI是两根数据线，这里是4根线，就会越看越迷茫，越看越困惑。而这些可以在了解整体原理图的功能以后，再考虑对细节的把握，是属于第二步。
系统类
系统类的原理图，画PCB的时候比较复杂，但是对FPGA或者SOC这样的核心控制器，最小系统其实相对固定，所以原理图看起来并不困难。常见的结构是，FPGA+DDR+Flash，SOC+DRR+eMMC，SOC+DRR+Flash。系统类的原理图看到SOC或者CPU之类的主控，就要想到缓存和存储，这是系统类必备的三要素。
普通类
普通类在原理图上，基本上都是比较简单的。一般用少量的几个GPIO来驱动，比如像蜂鸣器，按键，LED，这样比较单一的外设，相对来说，看起来本身也比较轻松。
因此，对于普通类的原理图，只需要知道这个外设是由哪个MCU控制就行，至于是什么时候拉高，什么时候拉低，这些都可以暂且不考虑，在后期可以结合软件业务理解，这样会更清楚。
附加类
附加类指的是对整个原理图的说明。复杂单板在原理图的开始会说明整个单板原理图有多少页，每页的名字是什么。在原理图的最后会加上一页用来记录原理图什么时候建立，改版的信息等等，方便日后查看。
这些附加信息可以加快我们对单板原理图的理解，但不需要把时间花在这些附加的信息上面。
无论是什么样的原理图，都可以用上面的逻辑框架来拆解。整体上会对单板的原理图有结构上的认识，知道这个单板包含哪些模块，包含几个CPU，有哪些协议类的器件等等。
在我带的新员工入职5个月的时候，她这边分配了一个小项目，需要画3块单板。项目开始的时候，她跑过来问我，师傅，这个项目有3块板子，原理图需要怎么画？我建议她说，你现在不用着急画原理图，先把这三块单板之间的框架分析清楚，然后再把每块单板内部模块之间的关系分析清楚，画出框架图再画原理图吧。然后她就按照我给的建议，用Visio把三块单板的框架画出来了。前段时间3块单板都打样回来了，目前测试都正常。
使用结构化的思维来看原理图有个比较明显的好处，能在整体上做到不重复，不遗漏，对核心的功能可以掌握的比较好。但是这样方法也有个弊端，会容易忽视一些局部的细节。
上面分析了结构化是影响我们理解原理的一个的因素，还有一个原因是太过于纠结细节。其实对于一幅有SOC的原理图，是需要软件才能工作起来，而有软件，就存在逻辑设计。比如，我们在完全不了解NXP这个demo板的功能时，单纯地看这个电路，是不是也很难看懂。
虽然我们能通过查数据手册知道这个芯片的核心功能，但是对上面这些信号到底是怎么样工作的，什么时候拉高拉低，如果对具体的应用场景不了解，可以说是很难看懂。所以，在不了解具体应用场景和业务逻辑时，太过于纠结细节就会影响我们对原理图的理解。
这就是上面说的第二点，在细上没有使用模块化的逻辑。其实我们只需要知道，这个器件实现哪些控制就可以，至于细节方面到底如何实现，可以不需要特别在意。再比如，我们看下面ADC信号链的原理图。
无论这种原理图怎么变化，只要是ADC信号链的电路，我们脑子里面就要浮现出模块化的框架如下图所示
可能不是每个模块都在原理图中呈现，像有些ADC器件内部就集成了滤波器之类的功能电路，但是模块化后，就是三个部分，传感器，信号调理，ADC。
再比如，上面提到的Flash原理图，看起来和平时的不一样。
这就是对具体器件的使用不熟悉，影响了我们对细节的理解。Flash有X1，X2，X4三种数据传输模式，即标准，双路，四路SPI。如果能提前掌握这些知识，那在细节上也不会过多纠结。如果没有掌握，其实只要我们把这6根线看成是Flash模块，也会降低对原理图的理解。
总结一下，在画原理图的时候，我们需要用结构化框架来规划单板原理图，这样做既方便于自己理解，也方便于他人理解。当我们拿到复杂且毫无逻辑框架的原理图时，无论它多么复杂，我们都可以用5类的框架来划分原理图，降低理解和阅读的障碍。使用这种方法，可以在整体上较快帮助我们掌握原理图的核心功能，再结合细节上使用模块化的逻辑，能进一步降低我们对部分信号的困惑。
在整体上和细节上对原理图进行拆解，看原理图其实也不是那么复杂，你说是不是？