让 CMSIS-DAP DAPLink 功能和性能上升到新高度

llinjupt · 2021-12-21 23:15:45

折腾了一段时间，总算有所成果，随写随贴... 抛砖引玉，先分析当前能够见到的DAPLink的问题。

1.当前DAPLink产品存在的问题

1.1 烧写速度
如果有细心的人尝试比较过市面上的DAPLink和STLinkV2，那么可以发现DAPLink的烧写速度要慢于STLinkV2。

如果目标芯片的FLASH比较小，例如网红芯片STM32F103C8T6，只有64KB，那么对比烧写速度是不明显的，但是要烧写FLASH大小为512KB，甚至1M的MCU时，速度差距就非常明显。

这并不意味着DAPLink做不到更高的速度，或者硬件方案不能满足，实际上当前的DAPLink硬件解决方案和STLinkv2的硬件解决方案通常都是基于XX32F103C8/BT6实现的。由于近段时间原厂STM32芯片的价格大幅上升，目前基于原厂STM32的方案很少(或者用拆机回收芯片)，大部分进行了国产替代。但是无论哪种硬件，速度上是完全可以满足SWD协议需求的，后面会分析为什么。

在metro的大作中将CMSIS-DAP移植到了增强型C51单片机CH558 上，并实现了下载到目标芯片STM32F407的速度70KB/s。这个速度实际上已经可以比肩STLinkV3(注意，不是V2)的速度了。也就是说72M主频的STM32方案是完全可以做到更高速度的。

这里简单分析下制约当前市面上DAPLink下载器下载速度的瓶颈，主要归结为两种：

原因1：HID协议
大部分产品都是基于CMSIS-DAP HID协议的。CMSIS-DAP提供了两种USB通信协议版本，早期的HID协议版本(DAPLink v1)和最新的Bulk版本(DAPLink v2)。HID和Bulk均是USB协议中的通信实现方式。HID是针对人机交互设备的，例如平时使用的鼠标，键盘，游戏手柄等，这类设备通信数据量很小，但是要保证最小时延。由于USB2.0协议通信是需要主机发起的，也即设备不能主动通告，HID规定最小时间间隔为1ms，PC会轮询一次设备来读取信息。 USB2.0最大支持的包长为64字节，这就意味着HID最理想的通信速率是64/1ms = 64KBps，这看起来还不错。但是CMSIS-DAP协议是Ping-pong模式的，也即需要发一个命令请求，然后等待响应，然后继续发下一个命令，这样就导致，即便在理想情况下发送64字节至少需要2ms，直接速率打对折，极限速度只能到32KBps。

原因2：SWD/JTAG实际频率远远未达到10MHz
通过Keil等上位机可以设定DAPLink调试协议的工作频率，通常默认就是最高频率10MHz，这比STLinkV2的工作频率要高一倍(STLinkv2的SWD频率官方宣称为4MHz，实测大约在4.3MHz)。

而市面上的大部分DAPLink虽然设置了10MHz，然而实际测试发现，工作频率只有600-700KHz。这相当于实际工作频率只有标称频率的10分之一都不到。

SWD实际工作频率测试方法很简单，调试器连接目标芯片，Keil下载程序然后进入调试模式，此时只要将SWCLK接示波器探头，GND接示波器探头地，然后选择下降沿触发即可看到波形，测试某产品在选择10MHz时的实际工作频率：

实际工作频率

令人感到意外的是，笔者使用过3种不同硬件，不同包装方式（亚克力外壳版本，仿STLinkV2铝壳版以及TypeC接口的裸板版本），每一种使用的芯片都不同，另外这些产品的序列号是不同的，也即基本可以确定不是使用的同一固件，但是却得到了相同的工作频率，这就可以猜测，这些厂商都是直接拿ARM开源社区的源码进行了简单移植，也即直接编译的。并没有针对特定的硬件平台进行时序的调整。

所以这类固件即便将USB协议切换为Bulk也是无法提高烧写速度的。

1.2 CDC虚拟串口卡死
基于USB协议的虚拟串口通常有2种实现方式：VCP和CDC，最主要的区别就是VCP是需要安装厂商定制驱动的，例如基于CP2102芯片方案的USB转TTL小板就是VCP方案。由于厂商的驱动针对自身硬件方案进行了特殊优化，通常情况下VCP的性能更好。

CDC是USB协议提供的通用串口虚拟方案，各类操作系统自带驱动, 无需再安装驱动，使用方便，但是性能通常没有VCP的好。但是对于只用于打印调试信息的调试器来说，CDC方案已满足这种需求，并且提供了即插即用的便利性。

但是目前测试发现，所有被测的三款产品都会出现CDC卡死问题，特别是在下载和调试时，如果同时使用虚拟串口打印，那么很容易出现卡死现象，并且只能重新插拔才能继续使用。目前看是DAPLink基于STM32F103的开源方案在处理UART接收上有问题，否则不可能所有的厂商都犯相同错误。

手头有类似调试器的朋友可以使用串口测试工具，例如UartAssist.exe来测试下串口吞吐量，直接将RX/TX短接，然后关闭数据回显，间隔时间调整到最低，每次发送64-256字节的数据包，基本上几分钟就会卡死。从现象看应该是典型的Cortex-M方案的UART ORE上溢错误。这类错误一旦出现如果不清0相应寄存器，则UART硬件模块就不再接收新数据，现象为串口卡死。

1.3 不支持软复位
软复位是SWD协议特有的针对Cortex-M芯片实现的无需RST硬件连线就可以实现复位的功能。

DAPLink调试器在收到上位机的软件复位命令时，会在RST管脚生成一个复位脉冲（低电平），与此同时在SWDIO数据口发出一段复位序列，Cortex-M芯片中的DAP调试模块收到该序列后就会复位芯片，起到和连接RST相同的作用。

可惜的是这些调试器都没有适配该功能，查看了ARM开源社区的源码后，发现也没有实现该功能，这就解释了为何大部分厂商没有（似乎也不知道如何）适配该功能。

1.4 不支持JTAG
之所以不支持JTAG，理由似乎也和不支持软复位一样，原开源代码中只实现了JTAG协议，但是没有实现USB数据到JTAG数据的对接。

JTAG协议是相比于SWD更通用的调试协议，对于具有DIY精神的朋友，如果了解了JTAG协议和OpenOCD或者pyOCD，那么通过DAPLink的JTAG协议就可以做出烧写其他芯片的方案，当然实现调试要困难一些。

此外通过JTAG协议还可以实现边界扫描，对于了解目标MCU的芯片设计有很大帮助。有国外网友通过JTAG破解XXX，有兴趣的可以了解下。

SWD提供了普通用户的调试和烧写需求，而JTAG则为更富DIY精神的Geek们提供了了解MCU内部硬件结构的大门

1.5 其他小问题
遇到有一家的DAPLink的所有产品都是使用的开源代码中写死的A0000xxx序列号，也就是说你一台PC只能插入一个调试器，如果需要同时调试多块板子，或者一块板子上有多个MCU需要同时调试，那么只能换一台PC，因为上位机只能识别出一个调试器。对于这种低级错误只能无语了。

有些产品没有提供5V供电接口。

有些只是使用串接小电阻的方式兼容3.3V和5V，实际上这很容易引起电流倒灌，导致调试器工作不稳定，长时间使用引起元器件失效。

大部分产品提供了自恢复保险丝，可以在5V短路时有效保护电脑USB主板。但是如果3.3V供电口不小心碰到地，或者触碰到5V端子上，LDO可能直接损坏，固件丢失，或者电压输出不在正常范围之内，导致调试器工作异常。（这里提醒手头有这类调试器的网友不要做此类实验，山寨的STLinkV2也不要做，否则很可能瞬间损坏，笔者进行过故意接错实验，发现丢固件现象，几乎必现，毕竟STM32芯片不支持5V供电，所以“易耗品”的名头很可能是此原因导致的）。

2 现有产品亮点
目前看能在官方DAPLink上能有所创新，功能有所增强的很少，大部分的做法都是（有意或者无意）在软件功能和硬件上做减法。对于普通的消费者这是好事，但是能够购买到更快更稳定的产品也是终端用户的需求。

但是这并不意味着所有厂商都只奔money，而是有所创新，无论是在外观上还是功能上。MuseLab家做的DAPLink是可以支持JTAG和软复位的，必须点赞。

有的厂家适配了TypeC接口，这样更小巧精悍。实际上笔者并不认同必须使用TypeC（micro USB口也一样，对于DIY来说更易焊接），因为根本就使用不到USB3.0，但是它的意义在于可以将USB通信端延长，而缩短调试线的长度，这样SWD/JTAG通信距离变短，更加稳定。此外不得不承认TypeC接口更美观。

使用USB A口（STLinkV2的USB口）的调试器，如果用在台式机上，那么由于A口只能直接插在主机上，那么调试线就要很长，否则开发板必须放在主机旁边，很不方便。这一点深有体会。或者使用A口的延长线，但是没有TypeC和micro USB口的延长线常见，基本上买手机或者其他电子产品都会附送这类USB传输线。

相比于STLinkV2的单一铝壳封装，可以找到各种封装的DAPLink，为喜欢DIY的人提供灵感。笔者最开始看到的是透明亚克力外壳，看起来比较精致，这种外壳原本是用于一些USB电流电压表，后来被用于改造DAPLink。缺点也很明显，容易刮花，个头大，实际上高度可以压缩一半，体积也可以做得更精致，但是需要定制，量不大的话无疑增加成本。另外A口调试接延长线不是很方便。

DAPLink同样也有类似STLinkV2的铝壳封装，这种封装比较小巧，但是只开一个孔，电源灯和信号灯都是通过该孔观察，算个小缺陷。不知道为何当初STLinkV2的山寨厂商不多打一个孔？而且固执得坚持这种外壳形式很多年，变得只是上面的丝印和LOGO（说一个有趣的事情，曾在某宝评论区看到某用户发此评论：本来是要买ST原厂的，发的竟然不带ST的Logo。所以也可以看到ST公司对山寨厂商们的容忍程度，竟然让终端用户以为打了ST的Logo的STLinkV2就是原厂的，不过固件确实都是原厂的）。另外，同样地A口接延长线不方便。（也正因为有铝壳，STLinkV2版本各类“奇异”芯片神出鬼没，只要能兼容原厂固件即可。）

裸奔，这种类似开发板发售的形式成本最低，硬件底板形状随意，功能扩展容易，不会受到底板大小的限制，所以为何只做呆板无趣的长方形？完全可以充分发挥想象力，做个卡通形象，例如紫色佩奇，增加亮点吸引小小开发者:-）。正因裸奔，不用考虑外壳的限制，可以衍生出TypeC版本。缺点也很明显，裸奔就意味着有被咸猪手触碰的风险，使用的时候很容易触碰到裸露的金属点，造成调试器异常，甚至烧毁芯片，此外也不防水防潮。所以为何不加个透明的外衣热缩管，来点诱人的朦胧美？使用裸奔的方式，一般不会遇到打磨芯片，因为是找骂，没人会尝试。

3 笔者尝试的DIY
基于以上罗列的现有产品问题和特点，总结前人经验，目前做了两种版本的硬件，经过一段时间的使用，现在使用最频繁的是加了透明外衣的TypeC版本（原谅看着脏兮兮，一直在服役），桌子上放几块开发板也不会显得很乱。身材娇小，异次元着装，一眼望去满桌子的科技感（电路板）。

人肉焊接工程样机

首先感谢metro 的帖子和 ljbfly的帖子，以及参与讨论的众多高手。这些信息给了笔者很多启发。但是很可惜没有看到metro把东西做完善。因为从他的测试效果来看，如果测试环境都没问题的话，速度已经比肩STLinkV3（不是V2）了，也即和V3一样都达到了目标芯片支持的烧写算法的上限。最最令人惊讶的是他采用的是一颗主频只有56MHz的增强型C51单片机 CH558，最开始看到这个帖子的时候笔者没有太多留意，直到后来发现手头的类似调试器性能很差，和帖子中达到的速率相差甚远，外加ARM开放了DAPLink的源码，这才重新回过头来，结合源码来仔细分析SWD和JTAG协议和时序，最终在性能和功能上有所增强。

实际上软件移植工作在8月底就完成了，但是不想做一个不稳定的东西出来，不然徒然浪费时间，没有什么实用意义，功能强但不稳定，是不能进行大面积使用的。所以近来几个月都在公司内部大面积测试使用，发现并解决了一些小问题，整体上达到了高速和稳定并举的状态。双串口+烧写/调试同时并行使用，非常稳定。

如果有细心的网友仔细观察上图中的排针，就会发现和市面上的其他DAPLink的区别，也即是2X6而不是2X5。目前达到的功能和性能：
1.经过高度优化的基于Bulk协议的DAPLink V2让性能达到STLinkV3 80%-90%，远远超过STLinkv2。烧写STM32H743，1M FLASH只需15s.(不同性能的PC对速度略有影响，但是不大。后附有完整的针对Cortex-M0+/3/4/7的各样例芯片的实测结果和用例)。
2.支持Bulk版本的DAPLink V2的同时，支持HID 版本的DAPLink V1，只需要简单切换模式即可。有效兼容老版本的开发和下载软件。
3.支持双路虚拟串口，这就是为何排针使用2X6的原因。双路虚拟串口可以单独设置波特率，互不影响，支持常见的固定波特率9600到230400，相当于两个USB转TTL小板，远远满足日常调试打印需求。
4.同时支持SWD和JTAG协议。
5.支持SWD软复位，使用SWD下载时，无需连接RST线。
6.支持虚拟U盘的升级和模式切换，无需安装驱动和软件。支持升级时意外掉电防变砖。
7.支持3.3V和5V供电输出，带自恢复保险丝，3V3和5V不小心接地短路不会对调试器电路造成损害。双LDO，输出3V3和MCU的3V3由独立的LDO供电，更稳定，互干扰更小。3V3可稳定对外输出150mA。5V输出由USB协议供电决定，也即500mA去掉MCU自身供电，大约40mA。(上图中是最初版本，硬件未支持双LDO)
8.UART硬件兼容5V和3V3电平。
9.支持STC的免冷启动下载功能。

下载速度的提升，对比较大的项目可以节约大量的下载等待时间，对于一个开发组更可观，在公司层面效率提升就更显著了，目前在调试基于STM32H743芯片的项目上下载效率提升明显。

另外为何要做双UART呢？一开始打算实现SWO协议，但是发现SWO需要占用一路UART，但是SWO并不是所有的Cortex-M都支持，它依赖于芯片内部的ITM模块，但是Cortex-M0/0+没有内置该模块，此外ITM打印过多时会丢数据，基于以上考虑，去掉SWO功能，改成更实用的两路UART，这样对于调试多UART口的MCU时更方便，不需要借助其他USB转串口小板。

支持STC免冷启动下载是他人提出的功能，感觉很有用，就加了上来。这对于初学者，比如在校生，爱好者或者同时需要开发ARM和STC单片机的开发者无疑带来了方便：抽屉里一堆下载器，找的时候又常常不见所踪。

总结，1个ELF DAPLink = 普通DAPLink+BULK高速下载+1USB转TTL小板+1STC免冷启动下载器。体积小巧，携带方便。之所以给它取名字叫ELF，意为小精灵，但人小鬼大，一个顶仨。

先唠叨这么多，看起来成长篇大论了，后面贴性能对比图，外加加速思路，分析和实现。

最近编辑记录 llinjupt (2021-12-21 23:35:10)

llinjupt · 2021-12-22 21:06:55

4 性能对比
4.1 测试环境和方法
这里性能主要对标的是ST原厂的STLinkV2和STLinkV3MINI，STLinkV3MINI功能上比STLinkV3有所简化，但是SWD协议性能上是一致的，SWD的实际工作主频可达24MHz。

测试环境：
PC WIN10 64bit
Keil uVision 5.29.0
OpenOCD 0.11.0-rc2+

注意不要使用虚拟机测试，也不要将调试器通过USB HUB连接到测试主机。

调试器均升级到较新固件本版，并选择最高支持的SWD工作频率，这里需要注意只有Selected后面显示的频率才是实际的工作频率。而DAPLink没有该项，所以DAPLink的工作频率只能靠示波器来查看。

STLinkV2 V2J37S7 4MHz
STLinkV2 配置

STLinkV3MINI V3J9M3 24MHz
STLinkV3 配置

ELF DAPLink V2 10MHz

Keil性能测试方法，由于Keil无法单独打印烧写速度，只能通过统计时间来预估，这里通过在上一次烧写完毕后直接按F8进行下一次烧写，然后统计时间间隔。该时间是包含擦除，烧写和校验的，如下图打钩Verify。所有被烧写的程序都使用接近FLASH大小的bin文件，也即64KB的FLASH使用接近64KB的bin文件。

使能校验

上一次下载即将结束时按住（尽量减小两次下载的间隔）F8键立即进行下一次下载，统计时间间隔48-38=10s，然后取三次间隔的均值：

目标芯片的IDCODE查看方法，因为某些丝印为STM32的芯片使用的是国产打磨后重印的芯片，所以这里给出测试芯片的IDCODE，以防遇到这类情况。通常情况下厂商间的IDCODE是不同的。
idcode

4.2 测试结果

result
(0) OpenOCD 烧写SAMD21脚本报错，待解决
(1) 无法发现目标MCU，尝试降频同样失败
(2) W表示写入速度，V表示验证速度
(3) 尽管设置了最大频率24MHz，但是OpenOCD进行了降频使用

需要说明的是以上数据均是多次测试的结果，对于明显违背于知觉的测试数据，使用另一台PC进行了交叉验证，可以保证以上数据的客观，可重现，具有代表性。这里对测试结果进行简单的分析归纳。

这一组数据是很有趣的，有些还出乎笔者意料，看起来有很多矛盾的地方。例如DAPLink在Keil上的表现要远远好于OpenOCD，经分析OpenOCD的源码，它没有针对DAPLink的缓冲队列进行优化，而Keil的驱动层明显是使用该优化的（通过USB抓包可以看到在烧写时，每次发送DAP_PACKET_COUNT个请求）。而OpenOCD每次只发送一个请求然后等待响应。

在某些芯片上，比如M3/4系列上，ELF DAPLink可以微弱反超STLinkV3。在高性能MCU上，ELF DAPLink和STLinkV3在Keil上都达到了烧写算法的上限，但是在OpenOCD上，明显STLinkV3更优，ELFLink大约慢了20%，OpenOCD上位机针对DAPLink还有很大的优化空间（为什么这么说，因为Verify的速度是一致的，速度瓶颈并不在DAPLink这边）。

在内置较小FLASH的MCU上性能对比不明显，因为烧写前的准备工作所下发的命令数是相同的，比如设置SWCLK的频率，初始化GPIO端口，LED状态设置，这样速率平均下来就变慢了。就像车子只行驶几米的速度也要算上启动时间一样。

不过发现STLinkV3M在使用24MHz工作情况下，不太稳定，因为V3 MINI是高度集成的，而MCU的主频很高，与此同时SWCLK工作在基本达到调试接口可以支持的最大24MHz，EMI干扰较大（可以观察波形，明显劣化），连接目标板时，调试线要尽量短，并且地线要紧靠目标MCU的GND，否则很容易报错，其他网友也有此反馈，应该不是个例。

SAMD21G18A这颗MCU，STLinkV3M完全发现不了，很是奇怪。有带该MCU的开发板的小伙伴，并且手头有STLinkV3的可以帮助验证下。

这里提出一些看似反常的问题，后面会尝试详细分析为何会有这样的对比结果。STLinkV3M相对于STLinkV2的最高4MHz工作频率，性能有大幅提升，但是相对于它的硬件配置，似乎并没有完全发挥出来：
1.STLinkV3是USB High Speed，也即USB可以达到480Mbps的通信速率，为何烧写速度对比优化过的ELF DAPLink没有明显优势？
2.STLinkV3的SWCLK可达24MHz，对比优化过的工作在10MHz的ELF DAPLink为何没有明显速度优势？

最近编辑记录 llinjupt (2021-12-23 09:51:08)

llinjupt · 2021-12-23 13:48:54

4.3 STLinkV3可能不兼容他家MCU
参考 https://pyocd.io/docs/debug_probes.html

Recent STLink firmware versions will only allow access to STM32 targets. If you are using a target from a silicon vendor other than ST Micro, please use a different debug probe.

意为最新的STLink对目标MCU进行了限制，猜测是内置了ID寄存器，用于辨识是否为原厂。笔者进行了部分验证，使用两款国产替代IC，测试发现STLinkV3确实不能发现，更不用说烧写和调试了。与此同时，STLinkV2没有此问题，也许以后升级也可能会被限，所以不要随便升级。感兴趣的小伙伴可以测试更多的非ST原厂MCU，看看是否完全不能使用。

不知道ST原厂为何会做这种限制，实际上这样做根本无法阻止替代，反而给人以作茧自缚的感觉，也难怪STLinkV3不像V2那么被大众接受了，价格是一个原因，更大的原因应该是从开放走向了封闭。

不过如果属实，从另一面考虑，倒可以使用STLinkV3鉴别IC是否为原厂，成为一个FAKE芯片的识别工具。

最近编辑记录 llinjupt (2021-12-23 14:30:57)

llinjupt · 2021-12-23 15:07:22

@iamseer

感谢提供的测试思路，简单测试了下：

F:\DOSUN\Openocd\openocd-win64\release\openocd-w64-new>pyocd flash -t STM32H743VITX STM32H743.bin -f 10m
0002279:INFO:load_cmd:Loading F:\DOSUN\Openocd\openocd-win64\release\openocd-w64-new\STM32H743.bin
[==================================================] 100%
0023668:INFO:loader:Erased 1048576 bytes (8 sectors), programmed 1048576 bytes (1024 pages), skipped 0 bytes (0 pages) at 47.93 kB/s

F:\DOSUN\Openocd\openocd-win64\release\openocd-w64-new>pyocd flash -t STM32H743VITX STM32H743.bin -f 24M
0002218:INFO:load_cmd:Loading F:\DOSUN\Openocd\openocd-win64\release\openocd-w64-new\STM32H743.bin
[==================================================] 100%
0031080:INFO:loader:Erased 1048576 bytes (8 sectors), programmed 1048576 bytes (1024 pages), skipped 0 bytes (0 pages) at 35.51 kB/s

该速度是包含擦除烧写和校验的，所以要比OpenOCD的要慢，可以将烧写时间和Keil对比，但是结果明显不对，后来用示波器测试发现STLinkV3工作在4.8MHz，也即-f参数对STLinkV3不起作用，已提交给社区，等解决后再比对。

ISSUE: https://github.com/pyocd/pyOCD/issues/1276

最近编辑记录 llinjupt (2021-12-23 15:28:07)

llinjupt · 2021-12-23 15:09:55

echo 说：

用相同的序列号，其实是为了换设备或者换USB接口的时候不重新装驱动，大多数时候一台PC只带一个调试器，重新装驱动很烦的。

WIN7需要装驱动，并且只需要装一次。WIN10自带驱动，无需安装，第一次插上设备后就自动匹配驱动，几秒s就可以使用了。序列号本身的用途就是用于唯一区分设备的。

ARM 关于DAPLink的USB设备配置有如下描述：
https://www.keil.com/pack/doc/CMSIS_Dev/DAP/html/group__DAP__ConfigUSB__gr.html

Update String Settings - Product String to indicate the Debug Unit. Note that "CMSIS-DAP" must be part of that string to allow identification by debuggers (or part of interface string for USB composite device).
设备的产品描述符中或者IF描述符中必须包含 CMSIS-DAP字符串。

Optionally each Debug Unit may provide a unique Serial Number String. If the String Settings - Serial Number String is not provided, only one Debug Unit can be connected at the same time to a host computer since it is impossible to identify multiple Debug Units.
每一设备可以提供唯一的序列号，否则同时只能接入一个调试器，因为无法区分多个调试器。

最近编辑记录 llinjupt (2021-12-23 15:33:12)

llinjupt · 2022-01-14 13:23:47

最近要做的工作好多，但是楼主绝不弃楼，先上图：

ELF家族

前段时间突发奇想，是否可以做到让 DAPLink 完全兼容 STLinkV2，毕竟有些时候需要开发STM8，那么就需要 SWIM，
另外一点就是支持最新的 STM32CubeProgrammer 升级. 现在在软件和硬件上已经得到了初步验证。

现在忙于规模稳定性测试，文档书写，备料，外加继续新增 AVR ISP 支持，感兴趣的可以参考开源项目 LUFA，速度比普通 USBAsp 不在一个级别，
并且完全支持官方最新开发环境 ATMEL Studio 7。AVR在国内 DIY 中不像 ST和STC流行，但是在国外用户众多，所以打算加进来，这样就不需要一堆下载器了。不过要进行完全移植还需要时间。

等折腾完了，将部分功能源码开放，并把整个优化思路贴出来。

llinjupt · 2022-01-22 00:08:43

ifree64 说：

强帖，串口CDC在win10以上系统是不是不用装驱动？我在arm windows虚拟机里没有ch340的驱动，没有串口用，重金买回来的m1 macbook成了摆设。

WIN10 上集成了很多通用的 USB 驱动，例如 CDC 和 WINUSB，所以这类设备均无需安装驱动，对于 WINUSB 设备需要在 USB 描述符中提供 GUID 字段，系统会自动匹配驱动。

据我所知，CH340应该不是 CDC，而是类似CP2102的 VCP，需要安装厂商的私有驱动才能工作。
在虚拟机中使用USB设备，速度会大受影响，少量数据通信可以，不能用于测试评估用。

MacOS好像不支持 CDC 类设备，这和 Linux 不同，Linux 天生支持的很好。

llinjupt · 2022-01-24 11:14:55

@ifree64

PC 到串口的流程：

PC上位机 --------- USB 驱动 ---- USB EPs ----- TX/RX ----- 目标 MCU

VCP 和 CDC 的区别就只在于 PC 上位机使用的驱动不同，其他没有区别，所以基本和 CDC 没有关系，注意 CDC 没有准确（或者说是很多上位机没有完全遵守CDC的规范下发 DTS 命令）提供 DTS 功能，STC下载的关键点是进入冷启动，所以要模拟 DTS 信号，然后让芯片彻底进入冷启动状态。

实际上STC完全可以做到非冷启动下载，可能是为了兼容以前的产品，原厂才一直保持这种很诡异的下载方式。

最近编辑记录 llinjupt (2022-01-24 11:16:34)

llinjupt · 2022-01-25 14:08:49

@ifree64

你说的现象很奇怪，因为手动操作上下电就和DTS没有关系了，我没有出现这样操作下载不成功的情况，
不知道你的目标MCU是什么型号？老型号只支持到9600波特率，并确保输出的波特率和设置的是一致的，有些CDC做得不好，实际并没有配置正确的波特率，
可以使用逻辑分析仪抓取 RX/TX信号，看看波特率是否正确，并确认目标MCU有回应。

最近编辑记录 llinjupt (2022-01-25 14:10:46)

llinjupt · 2022-01-25 14:43:45

实际上 STC-ISP 支持 CDC 还有更大的问题，也即序号只能到 255，实在是很扯的一件事，所有其他串口终端程序都可以直接列出来可用的串口，唯独它枚举出来所有的COM0-255，找要找半天，而CDC序号是没有限制的，完全可以超过255，此时STC-ISP扫描串口的时候，就死在那了，然后重启程序直接死掉。

不过普通用户倒是不用担心，因为平时不会在一台电脑插入如此多的CDC设备，所以通常不会遇到这类问题。而我因为测试的原因，会插入很多不同序号的CDC设备，每次端口会被预留，这样很快就超过255了。该问题已反馈给STC，看他们怎么解决吧。

llinjupt · 2022-01-26 11:48:06

手头正好有类似的片子，测试结果：

正在检测目标单片机 ... 
  单片机型号: STC8A8K64D4
  固件版本号: 7.4.2U

当前芯片的硬件选项为:
  . 系统ISP工作频率: 24.074MHz
  . 内部IRC振荡器的频率: 11.064MHz
  . 掉电唤醒定时器的频率: 34.675KHz
  . 振荡器放大增益使能
  . P3.2和P3.3与下次下载无关
  . 上电复位时增加额外的复位延时
  . 复位引脚用作普通I/O口
  . 检测到低压时复位
  . 低压检测门槛电压 : 2.00 V
  . 上电复位时,硬件不启动内部看门狗
  . 上电自动启动内部看门狗时的预分频数为 : 256
  . 空闲状态时看门狗定时器停止计数
  . 启动看门狗后,软件可以修改分频数,但不能关闭看门狗
  . 下次下载用户程序时,将用户EEPROM区一并擦除
  . 下次下载用户程序时,没有相关的端口控制485
  . 下次下载时不需要校验下载口令
  . 内部参考电压: 1188 mV (参考范围: 1100~1300mV)
  . 内部安排测试时间: 2021年11月1日

  单片机型号: STC8A8K64D4
  固件版本号: 7.4.2U

开始调节频率 ...			[0.922"]
调节后的频率: 11.064MHz (0.043%)

正在重新握手 ... 成功			[0.141"]
当前的波特率: 115200
正在擦除目标区域 ... 完成 !		[0.657"]
芯片出厂序列号 : F7F4C63909E07A
正在下载用户代码 ... 完成 !		[0.031"]
正在设置硬件选项 ... 完成 !		[0.015"]

更新后的硬件选项为:
  . 系统ISP工作频率: 24.074MHz
  . 内部IRC振荡器的频率: 11.064MHz
  . 掉电唤醒定时器的频率: 34.675KHz
  . 振荡器放大增益使能
  . P3.2和P3.3与下次下载无关
  . 上电复位时增加额外的复位延时
  . 复位引脚用作普通I/O口
  . 检测到低压时复位
  . 低压检测门槛电压 : 2.00 V
  . 上电复位时,硬件不启动内部看门狗
  . 上电自动启动内部看门狗时的预分频数为 : 256
  . 空闲状态时看门狗定时器停止计数
  . 启动看门狗后,软件可以修改分频数,但不能关闭看门狗
  . 下次下载用户程序时,将用户EEPROM区一并擦除
  . 下次下载用户程序时,没有相关的端口控制485
  . 下次下载时不需要校验下载口令
  . 内部参考电压: 1188 mV (参考范围: 1100~1300mV)
  . 内部安排测试时间: 2021年11月1日
芯片出厂序列号 : F7F4C63909E07A

  单片机型号: STC8A8K64D4
  固件版本号: 7.4.2U

  . 用户设定频率: 11.059MHz
  . 调节后的频率: 11.064MHz
  . 频率调节误差: 0.043%


操作成功 !(2022-01-26 11:46:09)

建议对照官方文档中的下载电路，在TX上反串二极管再测试，很可能是电流通过TX灌入导致的。

最近编辑记录 llinjupt (2022-01-26 18:17:38)

llinjupt · 2022-02-07 22:33:10

posystorage 说：

欢迎探讨
开源CH551/2实现的汇编优化高速DAP-Link (CMSIS-DAP v2)
https://whycan.com/t_7786.html

首先支持开源，不过个人觉得高速DAP-Link说法欠妥，因为ARM官方的DAPLink v2版本也没有冠以HS的说法，况且真正可以算 “高速”的 STLINKv3 也没有提 HS。从CH552的工作频率上看，下载速度在目标芯片未形成瓶颈时，不会超过 STLinkV2（4.4MHz），优点在于CH552价格便宜，当板载的MCU FLASH不是很大时，用于板载还是划算的。

llinjupt · 2022-02-07 22:57:56

avr

新年新消息，原本打算过段时间，有大突破了再更，先来张图吧，支持ARMCortexM/STC/AVRISP 的 DAPLink 出炉，外加支持 STLinkv2/STM8 的板子还在路上。AVRISP 协议版本太多，目前为了方便使用 ArduinoIDE，移植的是ArduinoISP(也即STK500v1，ATMEL Studio可以通过扩展工具支持)，不过要支持更高速的MKII方案（ATMEL Studio 直接支持，这样就为后序继续集成PIC MCU的烧写铺平了道路），移植还需时日！

最近编辑记录 llinjupt (2022-02-07 23:00:19)

llinjupt · 2022-02-18 11:30:58

taotieren 说：

会支持 rs-flash 吗？

不知您说的是不是 probe-rs，如果是的话，支持，因为本身它就是使用rust语言写的openocd，只不过功能上有所区别。
只要是兼容CMSIS-DAP标准协议的DAPLink，该工具都是可以支持的。

llinjupt · 2022-04-16 16:12:30

ELF/ELF+

物流耽搁了半个月，拿到PCB开焊。
目前支持功能根据目标芯片分四种：

1)ARM-CortexM0/0+/M3/4/7 全系列：

CMSIS-DAP v1/v2 SWD/JTAG 软复位，SWD性能目前测试Keil下不输StlinkV3。（保留V1是因为苹果机对V2支持不好）
STLinkV2 SWD/JTAG/SWO 支持Cube升级固件，支持串口（目前没有看到能在STLinkV2支持STM8且支持虚拟串口的固件）
目前最普遍流行的铝管版，均不支持SWO和JTAG，也没有虚拟串口。

2) STM8 只要是STLinkV2支持的型号全支持

3) STC 支持全系列免冷启动下载

4) AVR全系列下载
经典协议: ICSP
最新协议: UPDI （Microchip收购后的单线下载调试协议）
其他协议：PDI/TPI

至于一些小功能：救砖时钟，MCU RC校准，只要目前标准开放的功能全支持，不再罗列。

支持Arduino IDE 和 AtmelStudio (AVRStudio)。对于DIY完全够用了。性能优化部分再跟帖详述。

最近编辑记录 llinjupt (2022-04-16 19:33:45)

llinjupt · 2022-05-03 11:29:37

宁. 说：

@llinjupt
楼主，最新这个用的什么主控呀？目前进度怎么样了？想复刻一个。
开源的话能现在就把代码扔到gitee或者github吗？迫不及待了=D

开始使用的是C51方案，进行功能验证和性能评测，不过51的FLASH通常比较小，想做比较多的功能可能不够，最后使用RISIC-V方案量产，目前已进入最终产品线，所以暂不方便全面开源，不过解决方案帖子里都已经阐述，只是需要根据硬件平台适配调整。整个优化过程会详述，希望对他人有参考意义。

最近编辑记录 llinjupt (2022-05-03 11:29:49)

llinjupt · 2022-05-03 11:42:18

1.优化思路概述

整体上描述下优化思路。这里将数据流和水流做比，那么数据在不同设备间的传输（搬移）就像水流通过一段一段串联起来的水管。很明显，水流从源头到目的地的最大流速由这些串联起来的水管中最细的一根决定，如果想要增大流量，最直接的办法就是换掉这根最细的水管。但是数据通信中的环节瓶颈通常不是那么显然的。

DAPLink 整个通信流程大体分为以下几个步骤。

(USB)
PC<------------>MCU(缓存)<--------->MCU(解码)<------->SWD/JTAG(时序)<------->目标 MCU

要知道通信瓶颈，最好的办法就是针对每一部分进行单独测试，找出问题的根因，对症下药，这样就不会无的放矢，效果不明显。下面尝试解释USB HS为何不能大幅提升烧写速度（和优化过的ELF DAPLink FS相对比，而不是和没有优化过的开源方案相比）。

最近编辑记录 llinjupt (2022-05-03 11:43:58)

llinjupt · 2022-05-03 12:40:35

2. USB通信速率
USB传输分为interrupt传输，bulk传输，iso传输。这里只讨论DAPLink2.0 bulk传输的通信速率。

尽管名义上FS速度为12Mbps，HS速度为480Mbps，这个是最终的物理层面的波形速率，也就是算上了所有控制字段，校验字段等。并且不考虑发送和接收端的等待时间，就像公路上排满了车，前后距离达到极限，每辆车都能以相同高速行驶，这样计算公路的运量显然是不合理的。但是最终有意义的数据是静荷，必须把那些控制字段去掉。USB是相对复杂的协议，采用计算的方式可能和实际测试结果相差甚远。实测才有真正意义。

USB2.0 5.11.3 有一个公式，其中有一个传输因子2.083，个人理解就是，理论速度/2.083就是实际设备可以达到的极限静荷速度。对于12Mbps的极限速度就是12M/8/2.083/8=720KB/s 。这样就有了一个参考，如果实际测试结果和该值相去甚远，那么应该考虑测试方法问题。

这里测试USB吞吐量时有几个注意点：
1.不要通过HUB，也不要使用虚拟机，这将大大影响性能
2.其他同一总线上的USB口也不要接入其他设备（同一总线上的USB速度是设备共享的）。
3.读写操作调用usb_write/read(这里上位机使用libusb-1.0)时一次发送/接收尽量大(MB)的数据，OS底层会自动处理。
4.下位机中不要做任何打印，复制，统计等处理操作，直接ACK
5.下位机编译都应打开-O3和-Otime或-Ofast，并且开启I/Dcache（如果有）

这样就可以得到USB在特定MCU上读和写的实际速度。笔者测试的单向写的数据如下：

len:64 clk ms: 3302, 520.993347 KBytes/s
len:64 clk ms: 3306, 520.982483 KBytes/s
len:64 clk ms: 3309, 521.129028 KBytes/s
len:64 clk ms: 3312, 521.275391 KBytes/s

双向速率如下：
len:64 ms: 1382, 380.109985 KBytes/s
len:64 ms: 1728, 379.851837 KBytes/s
len:64 ms: 2076, 379.314056 KBytes/s
len:64 ms: 2433, 377.528992 KBytes/s
len:64 ms: 2779, 377.689819 KBytes/s
len:64 ms: 3127, 377.573395 KBytes/s

实际上后来测试数据还有提升，因为没有记录结果，这里只是作为参考，这样就得到了USB的实际理想速度。但是由于DAPLink采用Ping-pong方式，那么就要根据实际的情况来模拟这种行为，也就是发64，收64字节，看看吞吐量如何。

作为目标速度PK的参照，ST-LINKV3的实际烧写速度也只有90KB/s左右，换算成双向，也只有180KB/s。MCU处理USB均是使用DMA方式，MCU自身并不需要消耗太多CLK来处理USB通信，结论是通信瓶颈不在USB上。在这里优化就像使用更粗的水管替换已经够粗的水管，效果很差。

llinjupt · 2022-05-03 13:46:10

3. SWD速率

分析完入口，分析出口部分。在Keil上位机上设置调试器选项页有一个Max Clock参数，最大值为10MHz，它设置的就是SWCLK的频率，而不是SWD的通信速率。实际的通信速率要结合SWD的协议分析。这里不再单独贴图，可以结合metro的帖子。

静荷速率大约是 (8+32)/(8+5+32+1)≈87%，这样结合10MHz的计算，那么理想情况应该在 10MHz/8*0.87 = 1.1MB/s，这个数据是惊人的，也就是目标MCU可以提供的灌入/读取速度可以达到如此高的速度。实际上查看ARM官方的数据，其SWD模块可以最高支持到24MHz。STLINKV3就是使用的该频率，然而频率越高，噪声越大，抗干扰能力也越差，对外部排线长度和质量都有更高要求，反而得不偿失。

笔者第一次拿到某DAPLink的时候，尝试与STLINKV2比较，发现STLINKV2的SWCLK频率在4.xMHz，那么显然应该比STLINKV2要快，然而事实和预期恰恰相反，后来通过示波器查看波形才有了帖子开头上贴的那张图。如果使用那张图上的实际频率来计算，大约最高静荷速率为700K/8*.87=76.125KB/s。

即便是糟糕的76.125KB/s和STLINKv3的实测速率应该也不差，但是注意这里是双向的速率，毕竟SWD是半双工，收发交替进行，另外这里的静荷速率是指GPIO一刻不停地TOGGLE，事实上MCU解码/编码数据会占用大部分时间。此时整个波形平静如一，没有任何数据通信。

可以参考 Vllink Lite 作者 le062 的帖子 CMSIS-DAP兼容调试器，其中有相关的时序图。

结论：如果实际的SWCLK是10MHz，那么完全满足需求，因为单向就是 1.1MB/s / 2 =550KB/s，所以在GPIO出现瓶颈时，USB那边会首先成为瓶颈，问题是笔者测试的DAPLink的时钟为何如此之低，当看到 ARM 官方的源码时，这个结果在意料之中。

最近编辑记录 llinjupt (2022-05-03 13:49:37)

llinjupt · 2022-07-01 16:18:32

速度比较一定要使用相同的目标MCU，相同的上位机，相同的SWCLK设置下，进行比较。同样是128KB，Cortex-M7的MCU写入速度要比Cortex-M3快很多。希望能在相互PK中不停推动开源DAPLink的发展.

最近宣称高速的DAPLink有不少，抽个时间挨个评比下。

笔者最后量产的是N合一的调试器，也即1个硬件直接在N个Link间切换模式，XXLINKv2/2.1/DAPLink/AVRISP/AVRMKII，希望能给大家带来一点惊喜，价格国内亲民，主打海外。

最近编辑记录 llinjupt (2022-07-01 16:36:12)

llinjupt · 2022-07-01 16:37:58

@上海航芯市场
这个邮费18高了点，个人建议推广期还是含邮30以内比较有优势。笔者的N合1版本指导价也不高，目前只对经销商，电商，外贸等批量客户进行OEM生产。

最近编辑记录 llinjupt (2022-07-01 16:49:22)

llinjupt · 2022-07-05 16:56:01

后面陆续测试下当前市面上的各类DAPLINK。看看性能如何。

PWLINK2Lite，第一个选它，就是因为便宜，推广期9.9顺丰包邮，限购2个，GD32F303CCT6主控，买回来拆芯片也划算，还要什么自行车。

HID版本，所以基本上性能不会太高，事实也是如此，基本和STLinkV2的烧写速度一致。特地使用示波器看了下SWCLK，可以接近8MHz，相信如果采用V2版本，速度定能提升不少。
另外虚拟串口短接测试吞吐量，波特率230400时丢包，波特率再往上丢包严重，且和单次发送数据长度无关。难道基本功能未测试？

优点：硬件设计优良，内有热缩管保护套（实际上氧化铝本身就是高度绝缘的，可能是为了安装更牢固），发烧友上的产品售价不及半颗芯片，老板是赚是亏？对硬件有详细分析。
和其他产品不同，它的铝壳塑料件是定制款，比较紧实，看来老板是想做好产品的。
疑问：OB21的稳压管最高支持700mA的输出电流，而FS的USB最大只能输出500mA，采用这种设计的目的是为了冗余？

实际上笔者感兴趣的倒不是它的硬件，而是商业模式，敢在某个很窄领域运用互联网思维进行操作，定是艺高人胆大，期待后续发展。

最近编辑记录 llinjupt (2022-07-05 17:06:57)

llinjupt · 2022-07-05 21:38:29

Gentlepig 说：

合宙的air32f103cbt6开发板也是9.9元，出厂是daplink固件。
这个片子好像可以超到200M.

是的，当初还发过1个帖子讨论这个5.8的裸片，M4的内核，文档中主频最高216MHz，实际测试可以超频到240MHz。

最近编辑记录 llinjupt (2022-07-05 23:31:57)

llinjupt · 2022-07-06 09:28:17

@Gentlepig
看芯片的IDCODE 0x2BA01477，这个是ARM核心ID，芯片厂商改不了。

llinjupt · 2022-07-12 11:44:40

Gentlepig 说：

合宙的air32f103cbt6开发板也是9.9元，出厂是daplink固件。
这个片子好像可以超到200M.

刚刚拿到的这个板子，内置的也是HID V1版本的DAPLink，有点失望，貌似直接拿的开源固件烧进去的。毕竟是主推开发板，用于方便调试。按照这个芯片的超频能力，理论上稍微优化就有不错的性能。

最近编辑记录 llinjupt (2022-07-12 11:48:41)

llinjupt · 2022-07-15 12:08:11

Gentlepig 说：

llinjupt 说：
@Gentlepig
看芯片的IDCODE 0x2BA01477，这个是ARM核心ID，芯片厂商改不了。
在合宙air32Q群里问过这事，他们给的回复是就是M3核，没有依据说明0x2BA01477就是M4，应该是较新版本的M3？

可以看下同规格MH32F103A宣传页，里面的BUG描述和移植手册一模一样。我是根据IDCODE和该芯片确定是M4的。不过合宙官方说是M3，也不用纠结。

llinjupt · 2022-08-27 14:33:02

wefinger 说：

@llinjupt
不知楼主的link是否已经量产发售，很感兴趣。

第一张图对应本帖子所说的多功能DAPLink。
第二张图是多模STLinkV2/2.1/DAPLink/BMP，模式自由切换，支持官方升级。
第三张图是CKLink+WCHLink，模式自由切换，支持官方升级。

感谢关注，目前只做国外市场和国内批量，上方是某客商定制的烧写器上附带的接线卡，因为左下角是客商LOGO，避免广告嫌疑，打了MARK。之所以目前不做国内零售市场基于以下原因考虑：
1.国内愿意为性能买单的开发者很少，除非是专门做电商，否则基本无利可图，研发费用都不够。
2.国内某电商也谈过，但是因为老款的库存较多，这一系列一推出，基本上原库存没法出，留一线，好相见。
3.国内主要针对批量客户，像公司团够，培训机构，学校社团，定制客户LOGO。
4.等原库存出差不多了，就交给国内电商推。我们这边还是只做好自己的事：设计，研发，测试和生产。

这个东西成本主要还是在研发和测试，测试还占了大头。不在众多环境中验证，个人DIY下，根本没法批量出货，就简单的比如串口通信，做过环流压力测试的都很少。我们这边的最终目标也不是做调试器，是为了下一阶段用于全自动化流水线上的PCB烧写，测试，验证的产品做铺路。

最近编辑记录 llinjupt (2022-08-27 14:59:59)

llinjupt · 2022-08-27 14:58:16

@posystorage
他们家的模式还是很清晰的，低价圈市场，拿风投。人家目的真不是赚烧写器产品自身的钱，而是看市场占有率找风头估价，那个东西硬件我批量也是做不到9.9，更别说包邮。我疑惑的地方是敢于把固件上传到第三方的公司或者个人有几个？另外这个市场很窄。但也许真的是新的商业模式呢？乐见其成吧。

最近编辑记录 llinjupt (2022-08-27 15:00:34)

llinjupt · 2022-12-05 14:33:40

foric 说：

DAPLink支持M33内核的SWM34SVE芯片吗？

看了下M33的说明，支持JTAG和串行线调试端口，所以DAPLink是支持的。

llinjupt · 2022-12-05 14:36:56

@iamseer
下载器没法知道上位机的下电指令，所以要重写上位机才行。或者通过抓包来获取，但是需求量很小，我这边下载WCH的片子也是自己写了个程序额外下电，然后间接控制沁恒的上位机。

llinjupt · 2022-12-06 13:52:09

@iamseer
你说的是WCH的私有下载协议，这种通过串口或者USB的协议，无需使用下载器，只需要外挂一个小模块来控制上下电即可，用个单片机实现USB转虚拟串口，然后内部处理下串口数据，根据指令控制某个PIN的I/O口，根据功率需要用它对外控制一个MOS管，或者继电器。

llinjupt · 2023-03-22 12:19:46

@huy666, 不用着急，功能无限版，暂命名为 iLINK Infinity，二季度国内上市，支持多种模式无缝切换，不丢固件，
支持 DAPLINK的V1/V2版本，全功能支持JTAG.SWD,SWO，
支持 STLINKV2 ，支持SWIM模式下带串口功能，原厂ST也无此功能，全功能支持JTAG,SWD,SWO
支持 STLINKV2.1，所有版本均支持原厂最新软件 STM32CubeProgrammer, 国内套壳的很多不支持该软件；全功能支持JTAG,SWD,SWO
支持 BLACK Magic Probe，用于开源环境的gdb调试
最最重要的是，支持官方固件升级。

支持 JLINK OB，该模式如果Segger官方有意见，可能会拿掉。

支持 AVRISP，全协议: ICSP,UPDI,PDI,TPI，上位机采用Arduino使用的开源AVRDUDE(最近替它的maintainer干了不少活，开源确实需要一种精神)
支持 AVRMKII，全协议，支持官方Atmel Studio.
支持 USBASP，该模式除了烧写AVR芯片以外，支持SPI/25/45 FLASH和I2C的 EEPROM烧写。

支持STC免按键烧写
支持 ARDUINO optboot/urclock 模式烧写
支持供电脚开关，有些芯片烧写需要先下电，这样用户可以直接通过命令控制电源通断。

最最最重要的是，该硬件平台是开放的，提供DIY模式和硬件电路，用户可以自己开发调试器/烧写器固件，当然也可以开发任何自己喜欢的东西。
直接将固件拖入虚拟U盘即可。所以您只要知道目标芯片/设备/LCD/模块等的协议，就可以自己DIY。
而DIY的时候也不用担心丢失已有DAPLINKV1/2/STLINKV2/2.1/JILINKOB/BMP等等所有出厂所带模式，直接从DIY模式切换回来就可以了。

开放支持 PIC/MSP430的烧写，因为Microchip/TI的条款限制比较严格，所以这类芯片的烧写，提供DIY上位机和固件源码示例，自己根据Datasheet折腾吧。
如果愿意分享，他人也可以使用该固件直接在DIY模式升级固件，这样全球每一个愿意DIY的人都可以人人为我，我为人人。

其他芯片的烧写也采用这种方式，提供开放的源码和上位机（如果有开源的上位机，就优先考虑已经存在上位机和通信协议）模板示例，自己去折腾吧。

通过以上方式，基本解决了开放协议的(Datasheet可以查询到烧写算法时序)芯片、模块等等设备的开发者自由DIY的困境。不用总是就为了偶尔烧写某一型号芯片就要去不停采购编程器，最后一堆，不用了就成了电子垃圾。

MCU采用的就是软件生态环境非常成熟的F103CBT6，开发起来资源很多，个人根据提供的开源框架，增加新芯片型号的支持并不困难。所以命名为无限的意思也就在于，一是自带功能非常强，再是用户可以DIY自己的调试器/编程器，即便最终不用了，您也可以写个固件让它闪个多彩的LED给孩子把玩(:-D)，不会沦为电子垃圾。如果用户愿意开放自己DIY的源码，或者固件，其他人也可以受益。

最终产品还是采用经典款铝壳，没错就是这么小小的铝壳(个人非常喜欢这个花花绿绿的彩壳，铝壳生产时比塑壳要麻烦，要调垂直)，做到功能“无限“”，而最终价格定令人难以拒绝。

最近编辑记录 llinjupt (2023-03-22 13:08:10)

llinjupt · 2023-04-07 09:47:35

Copper 说：

@llinjupt
这个上市的时候会支持比如GD32VF103这种risc-v芯片的下载调试么？另外lz有什么淘宝店之类的么？

国内很多RISC-V芯片调试下载机制都是基于开源的DAPLink魔改的，但是又没有开放协议（因为DAPLink毕竟是ARM开源出来的，但是RISC-V又是直接对手，所以...），所以需要进行协议分析并实现，但是目前看国内的这类芯片协议还不够稳定，一直在更新，而ARM的SWD/JTAG都是统一稳定的，每家芯片厂商只要采用ARM架构，那么就不需要重复实现这套协议；但是国内的RISC-V芯片厂商每家都有自己的一套私有协议，所以需要花很多时间进行协议分析和再实现，并且厂商更新后并不会说明更新部分，可能导致已发布固件无法工作，影响用户体验，得不偿失，至少目前阶段不会花时间支持，除非厂商合作或者开放协议。

刚刚看了下GD32V系列手册，好像是使用的原生的 RISC-V 标准配置和链状连接的 TAP 控制器来实现的。调试功能集成在 RISC-V 内核中。调试系统支持 JTAG 调试。这样看使用JLINK或者DAPLink，上位机直接采用Openocd是直接支持的，有个前提：DAPLink必须支持JTAG协议，市面上有些DAPLink可能没有实现JTAG协议。

最近编辑记录 llinjupt (2023-04-07 15:06:40)

llinjupt · 2024-07-24 19:49:31

cyj6588 说：

你好，大佬，请问如何解决的不支持SWD软复位的问题，能分享下经验吗，多谢！

// NVIC: Application Interrupt/Reset Control Register
#define NVIC_AIRCR     (NVIC_Addr + 0x0D0C)
#define VECTKEY        0x05FA0000  // Write Key

void swd_set_target_soft_reset()
{
  swd_write_word(NVIC_AIRCR, VECTKEY | 0x7);
}

此函数放在 DAP_SWJ_Pins 中检查 DAP_SWJ_nRESET 的分支中，这样无论Keil设置的是哪种复位都会同时进行软/硬复位：

  if ((select & (1U << DAP_SWJ_nRESET)) != 0U){
    if((value >> DAP_SWJ_nRESET) == 0)
      swd_set_target_soft_reset();
    PIN_nRESET_OUT(value >> DAP_SWJ_nRESET);
  }

最近编辑记录 llinjupt (2024-07-24 19:52:02)

WhyCan Forum(哇酷开发者社区)

楼主 # 2021-12-21 23:15:45 分享评论

让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #3 2021-12-22 21:06:55 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #6 2021-12-23 13:48:54 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #9 2021-12-23 15:07:22 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #10 2021-12-23 15:09:55 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #12 2022-01-14 13:23:47 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #15 2022-01-22 00:08:43 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #17 2022-01-24 11:14:55 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #19 2022-01-25 14:08:49 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #20 2022-01-25 14:43:45 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #22 2022-01-26 11:48:06 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #24 2022-02-07 22:33:10 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #25 2022-02-07 22:57:56 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #29 2022-02-18 11:30:58 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #31 2022-04-16 16:12:30 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #34 2022-05-03 11:29:37 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #35 2022-05-03 11:42:18 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #36 2022-05-03 12:40:35 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #37 2022-05-03 13:46:10 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #44 2022-07-01 16:18:32 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #45 2022-07-01 16:37:58 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #47 2022-07-05 16:56:01 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #49 2022-07-05 21:38:29 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #51 2022-07-06 09:28:17 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #53 2022-07-12 11:44:40 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #55 2022-07-15 12:08:11 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #59 2022-08-27 14:33:02 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #60 2022-08-27 14:58:16 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #64 2022-12-05 14:33:40 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #65 2022-12-05 14:36:56 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #67 2022-12-06 13:52:09 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #72 2023-03-22 12:19:46 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #75 2023-04-07 09:47:35 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

楼主 #90 2024-07-24 19:49:31 分享评论

Re: 让 CMSIS-DAP DAPLink 功能和性能上升到新高度

页脚