移植DAPLink (二) 速度测试
SWDIO时序
这里我使用了JLink的SWDIO时序和空闲电平态，因此和CMSIS-DAP标准定义的并不一样，实测下来Jlink的时序更加适合硬件SPI，兼容性也更好。
//todo
KEIL-MDK 下载速度测试
这里的下载速度不完全取决于WiFi或USB传输速度，还取决于目标板Flash的擦除/编程速度，因此得到的结果是一个综合因素的速度值。
- 目标芯片：GD32F303RCT6 Flash:256K SRAM:48K
ESP8266：NONOS-SDK3.0.5，主频80MHz，SWD Clock: 10MHz
ESP32-S2：ESP-IDF4.2，主频160MHz，icache:16K，dcache:16K，TickRate:1000
| 固件大小 | 扇区擦除 | 编程 | 校验 | 耗时 | 平均速度 | 备注 |
|---|---|---|---|---|---|---|
| 254KB | √ | √ | √ | 32.16s | 7.898KB/s | 无 |
| 254KB | x | √ | x | 22.35s | 11.36KB/s | 已提前擦除芯片 |
ESP8266：NONOS-SDK3.0.5，主频160MHz，SWD Clock: 10MHz
ESP32-S2：ESP-IDF4.2，主频160MHz，icache:16K，dcache:16K，TickRate:100
| 固件大小 | 扇区擦除 | 编程 | 校验 | 耗时 | 平均速度 | 备注 |
|---|---|---|---|---|---|---|
| 254KB | √ | √ | √ | 32.23s | 7.881KB/s | 无 |
| 254KB | x | √ | x | 20.42s | 12.439KB/s | 已提前擦除芯片 |
ESP8266：NONOS-SDK3.0.5，主频160MHz，SWD Clock: 10MHz
ESP32-S2：ESP-IDF4.2，主频240MHz，icache:16K，dcache:16K，TickRate:100
| 固件大小 | 扇区擦除 | 编程 | 校验 | 耗时 | 平均速度 | 备注 |
|---|---|---|---|---|---|---|
| 254KB | √ | √ | √ | 31.26s | 8.125KB/s | 无 |
| 254KB | x | √ | x | 20.44s | 12.427KB/s | 已提前擦除芯片 |
小结：
提升ESP8266的主频到160MHz，降低ESP32-S2系统心跳时间为10ms能稍微提升点性能，ESP32-S2主频提升到240MHz对性能改善不大。
- 目标芯片：STM32F072RBT6 Flash:128K SRAM:16K
ESP8266：NONOS-SDK3.0.5，主频160MHz，SWD Clock: 10MHz
ESP32-S2：ESP-IDF4.2，主频160MHz，icache:16K，dcache:16K，TickRate:100
| 固件大小 | 扇区擦除 | 编程 | 校验 | 耗时 | 平均速度 | 备注 |
|---|---|---|---|---|---|---|
| 127.65KB | √ | √ | √ | 20.97s | 6.087KB/s | 无 |
| 127.65KB | x | √ | x | 12.79s | 9.980KB/s | 已提前擦除芯片 |
JLINK-V9对比
Jlink-V9配置信息，全速USB@12MHz，SWD Clock: 10MHz。
- 目标芯片：GD32F303RCT6 Flash:256K SRAM:48K
| 固件大小 | 扇区擦除 | 编程 | 校验 | 耗时 | 平均速度 | 备注 |
|---|---|---|---|---|---|---|
| 254KB | √ | √ | √ | 18.69s | 13.590KB/s | 无 |
| 254KB | x | √ | x | 9.14s | 27.790KB/s | 已提前擦除芯片 |
DAPLink HID模式对比
使用STM32F103C8T6制作的DAPLINK_V2.0，全速HID模式，USB单包64字节，1ms/包。
有线传输，SWD Clock: 10MHz。
- 目标芯片：STM32F072RBT6 Flash:128K SRAM:16K
| 固件大小 | 扇区擦除 | 编程 | 校验 | 耗时 | 平均速度 | 备注 |
|---|---|---|---|---|---|---|
| 127.65KB | √ | √ | √ | 16.72s | 7.634KB/s | 无 |
| 127.65KB | x | √ | x | 10.56s | 12.088KB/s | 已提前擦除芯片 |
调试模式对比
有线的Jlink-V9和DAPLink单步运行时都十分跟手，点一下单步能立即执行。
无线DAPLink单步运行时返回结果有500ms左右的延时，
KEIL-MDK 批量传输数统计
在CMSIS-DAP的传输命令中，通过DAP_TransferBlock命令对批量的传输进行了支持
DAP_TransferBlock Command:
| BYTE | BYTE *****| SHORT**********| BYTE *************| WORD *********|
> 0x06 | DAP Index | Transfer Count | Transfer Request | Transfer Data |
|******|***********|****************|*******************|+++++++++++++++|
和DAP_Transfer一收一发不同的是，主机使用DAP_TransferBlock会通过USB连续发包，DAPLink调试器需要先缓冲当前USB数据并且立即准备接收下一包，等到缓冲区满或主机静默一定时间后，再解析每一包数据，通过SWD接口读/写目标板。
在数据传输方面，如果使用UDP，还需要自行处理丢包重发或找个基于UDP的可靠传输协议，经过实际测试下来，2.4G无线网环境还是比较恶劣的，UDP丢包相比于有线的以太网概率高了很多。因此这里就直接使用TCP协议， TCPIP-v4单包1460字节，USB单个传输事务为64字节，因此一个TCP包最大容纳22个USB分组包。
在DAP_config.h文件的宏定义DAP_PACKET_COUNT声明DAPLink设备支持缓冲的USB包数量，主机在一次连续发包时，不会超出该数量的限制。
#define DAP_PACKET_COUNT 22u
当DAPLink调试器完成对目标板的操作后，产生同样数量的返回数据包，可以连续的发给主机。主机收到完整数量的响应包后，进行解析和处理，并准备下一次的批量传输。
以下是实测KEIL-MDK使用DAP_TransferBlock的最大传输数，可以看到下载操作时，由于USB单个微帧只能传输19包数据，KEIL-MDK也没有发起多次USB传输操作，因此只能连续发19包，没有用完缓冲区造成一定浪费，这里可以直接将DAP_PACKET_COUNT设置为19，以避免因缓冲区不满额外的等待主机静默的时间。
| 操作类型 | 设备缓冲区 | KEIL-MDK实际发包 |
|---|---|---|
| 下载 | 22 | 19 |
| Debug | 22 | 22 |
