一、测试电源的效率
效率是电源测试中十分常见的测试项，高效的电源表现是众多厂家一直追求的目标。在芯片的规格书中，一般会提供几种常见输入输出应用下的效率曲线。当我们实际的应用范围与规格书上不同，或者在demo板的基础上我们进行了其他改动时，就需要重新进行效率测试。本文就来讲一讲如何进行效率测试以及一些注意事项。欢迎指正与补充。
1. 测量值
根据效率的计算公式可知
在测效率时，需要测得Vin、Vout、Iin、Iout这四个值（或者Pout和Pin），进行计算，即可得到最终结果。
2. 四表法
最常见的效率测量方式是四表法，即用四个万用表来测得以上四各参数。常见的万用表都是同时具有电流档和电压档的。
连接示意图如下：
tips：
- 使用电流档时，需将万用表串联在电路中，注意电流流向；使用电压档时，则是并联，注意正负极。
- 使用电流档时，一开始要用安培档，若是显示位数不够精确时，再更换至毫安档进行测试。用毫安档进行测试的情况下，调高负载电流时，要注意是否超过毫安档量程（一般在400mA）。若是不小心超过量程，会导致万用表内保险丝烧毁，更换保险丝后，才能继续使用毫安档进行测试。
- 两个电压表都接在板端，且连接线尽量短。不要接在电源端和负载端去读取数据，这样会较多地计入连接线上的产生的损耗，影响测试结果。
- 若想用电子负载直接读取输出部分的数据，可以用圆环连接线，圆环端直接焊在demo板上，另一端连接至电子负载。这样测试产生的损耗比直接用夹子连接产生的少。但一般还是会比用万用表测得的效率低些。
- 若是遇到超过万用表量程的情况，可以用电子负载读数，也可以用量程范围较大的功率计直接测量输出功率。
3. 测试步骤
以简单的BUCK电路为例，效率测试的步骤大致如下：
（1）确定需要测试的条件：输入输出电压以及输出电流。在轻载电流部分，需要多取几个点；重载部分，取点间隔可以稍大。例如，Iout=0-6A，测试点可取：0A, 0.1A, 0.3A, 0.5A, 0.8A, 1A, 1.5A, 2A, 2.5A, 3A, 3.5A, 4A, 4.5A, 5A, 5.5A, 6A。
（2）确认测试板在测试条件下工作正常，输入输出电压正确，观察SW波形，在轻载和重载时SW波形都正常，无啸叫和异常发热。
（3）断电，按照上述示意图，将四个万用表接入电路，电流表置于安培档位。连接完成后，重新上电。
（4）上电后，即可按照测试条件，慢慢调整负载电流，需要等万用表上数值稳定后，再记录测试数据。输入电压可能会随着负载电流的上升有所下降，低于测试条件。此时，需要适当抬高输入电压，尽量保持测试输入电压的万用表上的数据与测试条件一致。
4. 报告形式
除了将测试到的Vin Vout Iin Iout 填入表格，得到相应的计算结果。为了更直观地表现结果并与其他芯片做对比，一般会画出效率曲线。
如下图，是MP4581在Vin=24V/36V/48V, Vout=12V, Iout=1mA-800mA情况下测得的效率结果：
一般DCDC电源的效率在轻载时较低，最高效率点出现在较重载的时候。效率曲线较为平滑，如果画出的效率曲线出现突然上冲或者下落的点，可以重新测试那一点的效率，确认数据的正确性。
效率测试得到的结果有时并不尽如人意，当效率没有达到预期值时，可以用哪些方法来进行优化呢？此处列出以下几种，以供参考，也欢迎补充和指正。
1. 更换器件
在基础的DCDC电路中（此处依旧以BUCK 电路为例），有不少器件上都会产生损耗，从而影响效率：
a. 电感DCR ：指的是电感的直流电阻（即线圈的电阻），可将其与普通电阻一样视为耗能元件，在流过电流时，会产生损耗。故选择DCR更小的电感，可以达到减小损耗，提升效率的效果。
b. 电容ESR ：由于所有的器件都不是理想元件，实际的电容都具有寄生参数ESR（等效串联电阻）。当电流流过，ESR越大，则电阻损耗的功率越大，不仅会对效率有影响，还会影响电容寿命。故降低电容ESR也可以达到提高效率的效果。也可以采用多个电容并联的方式来降低ESR。
c. MOSFET ：目前常用的同步DCDC变换器中，都有MOSFET的存在。Rdson指的是晶体管的导通阻抗（可在器件规格书上找到），这一规格直接决定了MOSFET的功率效率。小的Rdson 值有利于减小器件导通期间产生的损耗。
除了导通损耗，会影响效率的还有器件的开关损耗。开关损耗的产生来自于器件开关瞬间，其电流与电压曲线的交叠面积（如下图）。故提高MOS管的开关速度和驱动速度也能提高效率。
如今，由于对高集成度的追求，很多的电源芯片都将开关管集成在了芯片内部，此时就不存在对MOS管单独选型的问题，而是对电源芯片的直接选择。
2. 降频
开关损耗的降低，不仅可以通过提高开关管的速度，也可以通过降频来达到。轻载时，开关损耗几乎不变，由于输出功率较低，所以效率下降很多。
电源输出轻载电流时，工作在PFM（pulse-frequency modulation）模式；在输出重载时，工作在PWM（pulse-width modulation）模式。
二、TCP协议基础知识
TCP 是互联网核心协议之一，本文介绍它的基础知识。
#1、TCP 协议的作用
互联网由一整套协议构成。TCP 只是其中的一层，有着自己的分工。
图片说明：TCP 是以太网协议和 IP 协议的上层协议，也是应用层协议的下层协议。
最底层的以太网协议（Ethernet）规定了电子信号如何组成数据包（packet），解决了子网内部的点对点通信。
图片说明：以太网协议解决了局域网的点对点通信。但是，以太网协议不能解决多个局域网如何互通，这由 IP 协议解决。
图片说明：IP 协议可以连接多个局域网。）IP 协议定义了一套自己的地址规则，称为 IP 地址。它实现了路由功能，允许某个局域网的 A 主机，向另一个局域网的 B 主机发送消息。
图片说明：路由器就是基于 IP 协议。局域网之间要靠路由器连接。路由的原理很简单。市场上所有的路由器，背后都有很多网口，要接入多根网线。路由器内部有一张路由表，规定了 A 段 IP 地址走出口一，B 段地址走出口二，......通过这套"指路牌"，实现了数据包的转发。
图片说明：本机的路由表注明了不同 IP 目的地的数据包，要发送到哪一个网口（interface）。
IP 协议只是一个地址协议，并不保证数据包的完整。如果路由器丢包（比如缓存满了，新进来的数据包就会丢失），就需要发现丢了哪一个包，以及如何重新发送这个包。这就要依靠 TCP 协议。
简单说，TCP 协议的作用是，保证数据通信的完整性和可靠性，防止丢包。
#2、TCP 数据包的大小
以太网数据包（packet）的大小是固定的，最初是1518字节，后来增加到1522字节。其中， 1500 字节是负载（payload），22字节是头信息（head）。
IP 数据包在以太网数据包的负载里面，它也有自己的头信息，最少需要20字节，所以 IP 数据包的负载最多为1480字节。
图片说明：IP 数据包在以太网数据包里面，TCP 数据包在 IP 数据包里面。
TCP 数据包在 IP 数据包的负载里面。它的头信息最少也需要20字节，因此 TCP 数据包的最大负载是 1480 - 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息，所以 TCP 负载实际为1400字节左右。
因此，一条1500字节的信息需要两个 TCP 数据包。HTTP/2 协议的一大改进， 就是压缩 HTTP 协议的头信息，使得一个 HTTP 请求可以放在一个 TCP 数据包里面，而不是分成多个，这样就提高了速度。
图片说明：以太网数据包的负载是1500字节，TCP 数据包的负载在1400字节左右。
#3、TCP 数据包的编号（SEQ）
一个包1400字节，那么一次性发送大量数据，就必须分成多个包。比如，一个 10MB 的文件，需要发送7100多个包。
发送的时候，TCP 协议为每个包编号（sequence number，简称 SEQ），以便接收的一方按照顺序还原。万一发生丢包，也可以知道丢失的是哪一个包。
第一个包的编号是一个随机数。为了便于理解，这里就把它称为1号包。假定这个包的负载长度是100字节，那么可以推算出下一个包的编号应该是101。这就是说，每个数据包都可以得到两个编号：自身的编号，以及下一个包的编号。接收方由此知道，应该按照什么顺序将它们还原成原始文件。
图片说明：当前包的编号是45943，下一个数据包的编号是46183，由此可知，这个包的负载是240字节。
#4、TCP 数据包的组装
收到 TCP 数据包以后，组装还原是操作系统完成的。应用程序不会直接处理 TCP 数据包。
对于应用程序来说，不用关心数据通信的细节。除非线路异常，收到的总是完整的数据。应用程序需要的数据放在 TCP 数据包里面，有自己的格式（比如 HTTP 协议）。
TCP 并没有提供任何机制，表示原始文件的大小，这由应用层的协议来规定。比如，HTTP 协议就有一个头信息Content-Length，表示信息体的大小。对于操作系统来说，就是持续地接收 TCP 数据包，将它们按照顺序组装好，一个包都不少。
操作系统不会去处理 TCP 数据包里面的数据。一旦组装好 TCP 数据包，就把它们转交给应用程序。TCP 数据包里面有一个端口（port）参数，就是用来指定转交给监听该端口的应用程序。
图片说明：系统根据 TCP 数据包里面的端口，将组装好的数据转交给相应的应用程序。上图中，21端口是 FTP 服务器，25端口是 SMTP 服务，80端口是 Web 服务器。
应用程序收到组装好的原始数据，以浏览器为例，就会根据 HTTP 协议的Content-Length字段正确读出一段段的数据。这也意味着，一次 TCP 通信可以包括多个 HTTP 通信。
#5、慢启动和 ACK
服务器发送数据包，当然越快越好，最好一次性全发出去。但是，发得太快，就有可能丢包。带宽小、路由器过热、缓存溢出等许多因素都会导致丢包。线路不好的话，发得越快，丢得越多。
最理想的状态是，在线路允许的情况下，达到最高速率。但是我们怎么知道，对方线路的理想速率是多少呢？答案就是慢慢试。
TCP 协议为了做到效率与可靠性的统一，设计了一个慢启动（slow start）机制。开始的时候，发送得较慢，然后根据丢包的情况，调整速率：如果不丢包，就加快发送速度；如果丢包，就降低发送速度。
Linux 内核里面设定了（常量TCP_INIT_CWND），刚开始通信的时候，发送方一次性发送10个数据包，即"发送窗口"的大小为10。然后停下来，等待接收方的确认，再继续发送。
默认情况下，接收方每收到两个 TCP 数据包，就要发送一个确认消息。"确认"的英语是 acknowledgement，所以这个确认消息就简称 ACK。
ACK 携带两个信息。
- 期待要收到下一个数据包的编号
- 接收方的接收窗口的剩余容量
发送方有了这两个信息，再加上自己已经发出的数据包的最新编号，就会推测出接收方大概的接收速度，从而降低或增加发送速率。这被称为"发送窗口"，这个窗口的大小是可变的。
图片说明：每个 ACK 都带有下一个数据包的编号，以及接收窗口的剩余容量。双方都会发送 ACK。注意，由于 TCP 通信是双向的，所以双方都需要发送 ACK。两方的窗口大小，很可能是不一样的。而且 ACK 只是很简单的几个字段，通常与数据合并在一个数据包里面发送。
图片说明：上图一共4次通信。第一次通信，A 主机发给B 主机的数据包编号是1，长度是100字节，因此第二次通信 B 主机的 ACK 编号是 1 + 100 = 101，第三次通信 A 主机的数据包编号也是 101。同理，第二次通信 B 主机发给 A 主机的数据包编号是1，长度是200字节，因此第三次通信 A 主机的 ACK 是201，第四次通信 B 主机的数据包编号也是201。
即使对于带宽很大、线路很好的连接，TCP 也总是从10个数据包开始慢慢试，过了一段时间以后，才达到最高的传输速率。这就是 TCP 的慢启动。
#6、数据包的遗失处理
TCP 协议可以保证数据通信的完整性，这是怎么做到的？
前面说过，每一个数据包都带有下一个数据包的编号。如果下一个数据包没有收到，那么 ACK 的编号就不会发生变化。
举例来说，现在收到了4号包，但是没有收到5号包。ACK 就会记录，期待收到5号包。过了一段时间，5号包收到了，那么下一轮 ACK 会更新编号。如果5号包还是没收到，但是收到了6号包或7号包，那么 ACK 里面的编号不会变化，总是显示5号包。这会导致大量重复内容的 ACK。
如果发送方发现收到三个连续的重复 ACK，或者超时了还没有收到任何 ACK，就会确认丢包，即5号包遗失了，从而再次发送这个包。通过这种机制，TCP 保证了不会有数据包丢失。
图片说明：Host B 没有收到100号数据包，会连续发出相同的 ACK，触发 Host A 重发100号数据包。
三、用示波器测量串口波特率
如何确定时基
假如要测量的波特率为9600, 则每一比特位的时间为：1/9600 ≈ 104 μs，一般示波器横向上每个大格子里5个小格子，要想看清一比特位一般需要一个小格子就够了，则时基为：104 μs * 5 = 520 μs, 也就是说时基要500 μs。
注意：测量时选择的耦合方式为直流，边沿类型为下降沿，所测串口的电平为TTL 电平，该电平的串口在不传输数据时电平为高，靠拉低判断起始位。
下图是测9600波特率，所发数据为0x55:
所用示波器为 汉泰的 IDSO1070。从光标测量可以看出AB之间的时间为107.422 μs，和计算的104 μs 差不多。下图为波特率9600，所发数据为0x00， 因为数据位全部是0，所以看到一直是低电平:
如何用示波器测串口波特率
前提：需要能从信号中找出一个比特位位来。
已知发送数据位0x55020000，0x55 的2进制位为10101010。
如图任意选取一比特位，用光标测量可得，时间为1.074us，频率930.909kHZ，最接近的波特率为921600, 所以所测信号的波特率为926100。
四、单片机Hex文件
玩单片机的朋友都会使用hex文件作为烧录文件。那么当我们写一个在线升级软件要支持hex文件的升级，就需要通过hex文件转成bin文件进行传输，那么hex文件的格式和知识就必不可少了。
Intel HEX文件是由一行行符合Intel HEX文件格式的文本所构成的ASCII文本文件。在Intel HEX文件中，每一行包含一个HEX记录。这些记录由对应机器语言码和/或常量数据的十六进制编码数字组成。Intel HEX文件通常用于传输将被存于ROM或者EPROM中的程序和数据。大多数EPROM编程器或模拟器使用Intel HEX文件。
1 Hex文件记录格式
以行为单位，每行以冒号开头，内容全部为16进制码，以ASCII码形式显示。
在HEX文件里面，每一行代表一个记录。记录的基本格式为如表所示：
Start code 一个字符，ASCII冒号：。
Byte count 两个十六进制数字（一个十六进制数字对），表示数据字段中的字节数（十六进制数字对）。最大字节数为 255 (0xFF)。16 (0x10) 和 32 (0x20) 是常用的字节数。
Address 四位十六进制数字，表示数据的 16 位起始内存地址偏移量。数据的物理地址是通过将此偏移量添加到先前建立的基地址来计算的，从而允许内存寻址超出 16 位地址的 64 KB 限制。默认为零的基地址可以通过各种类型的记录进行更改。基地址和地址偏移量始终表示为大端值。
Record type 两个十六进制数字，00到05，定义数据字段的含义。参考下文
Data 一个由n个字节组成的数据序列，由 2n 个十六进制数字表示。一些记录省略了这个字段（n等于零）。数据字节的含义和解释取决于应用程序。
Checksum 两个十六进制数字，一个可用于验证记录没有错误的计算值。计算校验和前所有16进制码的累加和。
2 数据记录格式
Intel HEX文件由任意数量以回车换行符结束的数据记录组成.
数据记录外观如下:
[：10246200464C5549442050524F46494C4500464C33]
其中：
10是这个记录当中数据字节的数量。
2462 是数据将被下载到存储器当中的地址。
00是记录类型(数据记录)。
464C…464C是数据。
33 是这个记录的校验和的补足码。
3 扩展线性地址记录格式(HEX386)
扩展线性地址记录也叫作32位地址记录或HEX386记录。这些记录包含数据地址的高16位。扩展线性地址记录总是有两个数据字节。
外观如下：
[：02000004FFFFFC]
其中：
02是这个记录当中数据字节的数量。
0000是地址域，对于扩展线性地址记录,这个域总是0000。
04是记录类型 04(扩展线性地址记录)。
FFFF是地址的高16位。
FC是这个记录的校验和的补足码。
当一个扩展线性地址记录被读取，存储于数据域的扩展线性地址被保存，它被应用于从Intel HEX文件读取来的随后的记录。线性地址保持有效，直到它被另外一个扩展地址记录所改变。
通过把记录当中的地址域与被移位（16位）的来自扩展线性地址记录的地址数据相加获得数据记录的绝对存储器地址。
以下的例子演示了这个过程：
来自数据记录地址域的地址 2462
扩展线性地址记录的数据域 FFFF0000
---------------------
绝对存储器地址 FFFF24624 标扩展段地址记录(HEX86)
扩展段地址记录也叫HEX86记录，它包括4-19位数据地址段。扩展段地址记录总是有两个数据字节。
外观如下：
[：020000021200EA]
其中：
02 是记录当中数据字节的数量。
0000是地址域，对于扩展段地址记录,这个域总是0000。
02是记录类型 02(扩展段地址记录)。
1200是地址段。
EA是这个记录的校验和的补足码。
当一个扩展段地址记录被读取，存储于数据域的扩展段地址被保存，它被应用于从Intel HEX文件读取来的随后的记录。段地址保持有效，直到它被另外一个扩展地址记录所改变。
通过把记录当中的地址域与被移位（4位）的来自扩展段地址记录的地址数据相加获得数据记录的绝对存储器地址。以下的例子演示了这个过程：
来自数据记录地址域的地址 2462
扩展段地址记录数据域 1200
-----------------
绝对存储器地址 000144625 文件结束记录(EOP)
Intel HEX文件必须以文件结束(EOF)记录结束。这个记录的记录类型域的值必须是01。EOF记录外观总是如下
[：00000001FF]
其中：
00是记录当中数据字节的数量。
0000是数据被下载到存储器当中的地址。在文件结束记录当中地址是没有意义被忽略的。0000H是典型的地址。
01是记录类型01(文件结束记录)。
FF是这个记录的校验和的补足码。
6 Intel Hex 完成例子
下面是一个完整的Intel HEX文件的例子：
：10001300AC12AD13AE10AF1112002F8E0E8F0F2244
：10000300E50B250DF509E50A350CF5081200132259
：03000000020023D8
：0C002300787FE4F6D8FD7581130200031D
：10002F00EFF88DF0A4FFEDC5F0CEA42EFEEC88F016
：04003F00A42EFE22CB
：00000001FF看了这个例子，我自己也打开了之前写的51单片机的hex文件：
:2000000002000E75210675225B75230200267B007C00900090758140758901758CF1758A45
:2000200028D28C75A882758CF1758A280BBBFA157B00EC75F00A8485F020F5210CBC64027A
:200040007C00120051C0E0C0D0120051D0D0D0E032E52193F580D2A2C2A27580FED2A3C29C
:20006000A3120087E52093F580D2A2C2A27580FDD2A3C2A3120087227D327E287FF81151AA
:1A008000DFFEDEF8DDF4227E047FF8DFFEDEFA223F065B4F666D7D077F6FBC
:00000001FF五、合并BootLoader固件与APP固件的方法
嵌入式固件一般分为BootLoader和App，BootLoader用于启动校验、App升级、App版本回滚等功能，BootLoader在CPU上电第一阶段中运行，之后跳转至App地址执行应用程序。
因此，在发布固件的时候，会存在BootLoader固件和App固件；此时我们期望是将BootLoader固件和App固件合并成为一个固件，这样在量产时只需烧录一次即可。
传统方式
一些传统的方法都是“土办法”，没什么毛病，但比较繁琐。项目种类增加，或者版本发布频繁时更加体现出繁琐性，且易出错，操作稍微失误可能导致固件不完整；烧录不完整的固件，机子变“砖头”。
- 烧录两次，分别烧录BootLoader和App固件
- 烧录固件到芯片后，再从芯片读取固件，另存为hex文件
- 手动复制、合并固件
- BootLoader支持App固件传输功能的，只烧录BootLoader，后期再升级App
高效方式
我们目标是通过自动化脚本合并生成一个发布固件，提高效率和确保固件的完整性。
1 合并文件
Linux下的脚本我们用得很多，其实Windows的脚本也非常优秀，利用Windows的脚本可以快速实现增、删、查、改文件。常用Windows脚本命令如下。
- 合并两个文件：copy /b
- 重命名文件：ren <source_file> <dect_file>
- 删除文件：del
很显然，我们利用其合并命令，只需一条指令即可将BootLoader和App文件合并。
「例子：」
假设当前目录存在Boot.bin和App.bin文件，合并后文件命名为Firmware.bin。
copy /b .\Boot.bin + .\App.bin Firmware.bin注：Windows的目录路径为反斜杠，与Linux不同。
2 bin转hex
我们知道，二进制（bin）文件是不存在地址信息的，cpu上电执行并不一定是从地址0开始执行代码，如STM32芯片起始执行地址为0x8000000。
因此不能通过串口工具烧录bin文件，只能通过J-link或者ST-link烧录，并且在烧录前指定存储起始地址。因此，将bin文件转换为hex文件是有必要的。
「bin转hex方式：」
- 使用jflash工具，把合并后的bin文件，使用jflash打开，另存为hex格式文件
- 将bin文件烧录置芯片，读取出来，另存为hex文件
- 自己动手写一个bin转hex工具
- 借助第三方bin转hex工具
前两者太繁琐，效率低下；第三个比较灵活，但需要花点时间；如果使用优秀的现成工具是最快捷的办法。推荐使用“srec_cat.exe”工具，可以结合Windows脚本一起使用。
3.2.1 srec_cat工具
srec_cat一个功能非常强大的文件合并、转换工具，支持功能众多，包括：
- 文件合并
- 文件分割
- bin转hex
- hex转bin
- 数据填充
- CRC校验
此外，还存在srec的系列工具，文件比较工具 srec_cmp.exe和文件信息查看工具 srec_info.exe，可以从文章后面官方网站下载使用。
「文件合并」
命令格式：
srec_cat.exe <源文件0> <文件类型> <源文件1> <文件类型> <目标文件> <文件类型>例子：
srec_cat.exe source0.bin -Binary source1.bin -Binary -o merge.bin -Binary
srec_cat.exe source0.hex -Intel source1.hex -Intel -o merge.hex -Intel如果BootLoader和App生产的文件为hex格式，可以直接使用该命令合并为一个hex文件，注意地址的连续性。
「bin转hex」
命令格式：srec_cat.exe <bin源文件> <-Binary> <-offset> <偏移地址> <-Output> <hex目标文件> <-Intel>
例子：
将Boot.bin和App.bin合并的Firmware.bin转换为hex格式文件。
srec_cat.exe Firmware.bin -Binary -offset 0x8000000 -o Firmware.hex -Intel0x8000000，是STM32的起始执行地址。
更多的srec应用和工具下载详见官方网站：
http://srecord.sourceforge.net/download.html
3 完整示例
第一步，在需要生成固件目录新建一个txt文件。
第二步，键入如下内容(Boot固件和App固件可以指定目录)。
copy /b .\Boot.bin + .\App.bin Firmware.bin
srec_cat.exe Firmware.bin -Binary -offset 0x8000000 -o Firmware.hex -Intel
del Firmware.bin第三步，重命名txt文件为".bat"后缀文件，即是Windows可执行脚本的文件类型。
第四步，双击运行脚本，即可生成目标文件。
出现任何目标文件生成失败的情况，检查相关源文件是否存在，路径是否正确。
4 举一反三
以此类比，存在多个App文件的情况，可以通过该方式分别进行合并出一个固件。另外，实际项目中，经常会使用内部flash空闲扇区保存一些设备参数信息，如校准系数、设备地址、序列号等信息。
我们可以将参数信息保存为一个bin文件，通过该方式和固件合并，这样量产时将参数和固件一并写入，提高生产效率！
