- 首页
- » 搜索
- » llinjupt 发表的帖子
页次： 1
#1 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2024-07-24 19:49:31
你好，大佬，请问如何解决的不支持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);
}#2 Re: Cortex M0/M3/M4/M7 » Keil 通过 DAPLink 连结 STM32F411 时，不发送 JTAG-to-SWD 序列。。 » 2023-07-05 14:48:12
#12 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2023-04-07 09:47:35
@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协议。
#13 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 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的源码，或者固件，其他人也可以受益。
最终产品还是采用经典款铝壳，没错就是这么小小的铝壳(个人非常喜欢这个花花绿绿的彩壳，铝壳生产时比塑壳要麻烦，要调垂直)，做到功能“无限“”，而最终价格定令人难以拒绝。
#15 Re: DIY/综合/Arduino/写字机/3D打印机/智能小车/平衡车/四轴飞行/MQTT/物联网 » 怒开新坑，自制低成本高速USB分析仪（随缘更新） » 2023-02-28 09:58:56
#22 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-08-27 14:33:02
@llinjupt
不知楼主的link是否已经量产发售，很感兴趣。
第一张图对应本帖子所说的多功能DAPLink。
第二张图是多模STLinkV2/2.1/DAPLink/BMP，模式自由切换，支持官方升级。
第三张图是CKLink+WCHLink，模式自由切换，支持官方升级。
感谢关注，目前只做国外市场和国内批量，上方是某客商定制的烧写器上附带的接线卡，因为左下角是客商LOGO，避免广告嫌疑，打了MARK。之所以目前不做国内零售市场基于以下原因考虑：
1.国内愿意为性能买单的开发者很少，除非是专门做电商，否则基本无利可图，研发费用都不够。
2.国内某电商也谈过，但是因为老款的库存较多，这一系列一推出，基本上原库存没法出，留一线，好相见。
3.国内主要针对批量客户，像公司团够，培训机构，学校社团，定制客户LOGO。
4.等原库存出差不多了，就交给国内电商推。我们这边还是只做好自己的事：设计，研发，测试和生产。
这个东西成本主要还是在研发和测试，测试还占了大头。不在众多环境中验证，个人DIY下，根本没法批量出货，就简单的比如串口通信，做过环流压力测试的都很少。我们这边的最终目标也不是做调试器，是为了下一阶段用于全自动化流水线上的PCB烧写，测试，验证的产品做铺路。
#32 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-07-05 16:56:01
后面陆续测试下当前市面上的各类DAPLINK。看看性能如何。
PWLINK2Lite，第一个选它，就是因为便宜，推广期9.9顺丰包邮，限购2个，GD32F303CCT6主控，买回来拆芯片也划算，还要什么自行车。
HID版本，所以基本上性能不会太高，事实也是如此，基本和STLinkV2的烧写速度一致。特地使用示波器看了下SWCLK，可以接近8MHz，相信如果采用V2版本，速度定能提升不少。
另外虚拟串口短接测试吞吐量，波特率230400时丢包，波特率再往上丢包严重，且和单次发送数据长度无关。难道基本功能未测试？
优点：硬件设计优良，内有热缩管保护套（实际上氧化铝本身就是高度绝缘的，可能是为了安装更牢固），发烧友上的 产品售价不及半颗芯片，老板是赚是亏？ 对硬件有详细分析。
和其他产品不同，它的铝壳塑料件是定制款，比较紧实，看来老板是想做好产品的。
疑问：OB21的稳压管最高支持700mA的输出电流，而FS的USB最大只能输出500mA，采用这种设计的目的是为了冗余？
实际上笔者感兴趣的倒不是它的硬件，而是商业模式，敢在某个很窄领域运用互联网思维进行操作，定是艺高人胆大，期待后续发展。
#41 Cortex M0/M3/M4/M7 » 有趣的F103家族新添"不限量税后5.8" AIR32F103 和 MH32F103A » 2022-06-08 22:16:51
- llinjupt
- 回复： 59
AIR32F103 是主打LuatOS软件平台的上海合宙推出的，不限量税后5.8RMB。另有不知名公司推出的 MH32F103A，可以确定是同一芯片，采用CortexM4，主频216MHz，128KB FLASH，还有6.3RMB的256K CCT6可选。不只是谁为谁代工，不过这并不重要。自从STM32F103涨价以来，国产替代型号层出不穷，价格也开始回归，面对5.8RMB的税后价，各位大佬有何感想？
个人近半年多来也评估了十多种替代方案，因为核心相同，生产工艺相同，除了外设设计区别外，性能区别并不大，核心功能没有发现大问题，当然有大问题也不可能量产，有些也可能是同一厂商直接OEM的。不知道大家对税后5.8RMB的AIR32F103是持何种态度？
#44 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 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 官方的源码时，这个结果在意料之中。
#45 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 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上。在这里优化就像使用更粗的水管替换已经够粗的水管，效果很差。
#46 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-05-03 11:42:18
1.优化思路概述
整体上描述下优化思路。这里将数据流和水流做比，那么数据在不同设备间的传输（搬移）就像水流通过一段一段串联起来的水管。很明显，水流从源头到目的地的最大流速由这些串联起来的水管中最细的一根决定，如果想要增大流量，最直接的办法就是换掉这根最细的水管。但是数据通信中的环节瓶颈通常不是那么显然的。
DAPLink 整个通信流程大体分为以下几个步骤。
(USB)
PC<------------>MCU(缓存)<--------->MCU(解码)<------->SWD/JTAG(时序)<------->目标 MCU
要知道通信瓶颈，最好的办法就是针对每一部分进行单独测试，找出问题的根因，对症下药，这样就不会无的放矢，效果不明显。下面尝试解释USB HS为何不能大幅提升烧写速度（和优化过的ELF DAPLink FS相对比，而不是和没有优化过的开源方案相比）。
#48 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-04-16 16:12:30
物流耽搁了半个月，拿到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完全够用了。性能优化部分再跟帖详述。
#50 Re: ST/STM8/STM8S/STM8L » 谁能拒绝在自己的项目中添加终端工具用于调试呢？ » 2022-04-02 19:29:59
这玩意我也写过一套，汗;
另外，GITHUB 上这兄弟也写了一套，感兴趣的可以看看，
https://github.com/NevermindZZT/letter-shell
这种CLI以前在交换机上很多，后来都被GUI替代了，以前的嵌入式开发者对这类应用很熟悉，后来基本被Shell取代，大约十几二十几年前，CISCO，LINKSYS的gateway上都是这种，看起来很神秘高科技的东西，一个时代的渐行渐远。
那时候的CLI可以做得很炫，有些还带动画,ASCII码图，多种颜色，看了 letter-shell 好像也不支持对参数的帮助，只提示命令的 desc帮助。
ping [A.B.C.D/URL] 会提示单个参数的格式等等，记不太清楚了，很有趣的应用，所以想写一套针对单片机的寄存器任意位操作的CLI，并给出位段的功能提示，相当于一套内嵌的实时的datasheet，这样对于diy来说，可以在最底层验证寄存器的功能，可惜一直没空弄。
#54 Re: Cortex M0/M3/M4/M7 » 有没有大神用过CH32V103/20x/30x系列的片子 » 2022-03-31 12:06:47
air105这个和stm32f03开发区别大吗？没看过air105的库呢。
没usb和can是挺可惜的。还有qfn手工焊接有点难度。
-------------------------
额，是有usb的。
QFN要多焊几次，找找手感，另外推荐用热风枪+BGA助焊剂+锡膏（劣质的锡膏和助焊剂就不要考虑了，完全是浪费时间），
其他方式个人经验，手工各种问题，良率很低。
QFN的最大问题是焊接后无法直接通过万用表测试引脚通断，只能测试相邻脚是否短路，这对于普通爱好者
可是头大的很，个人用的是JTAG 边界扫描方式测试通断，不过没有JTAG口的片子就不行了，通常对于PIN脚较多芯片都会提供JTAG接口。
这对于BGA封装的片子同样适用。
#55 Re: Cortex M0/M3/M4/M7 » 有没有大神用过CH32V103/20x/30x系列的片子 » 2022-03-29 11:38:48
事实证明一分钱一分货。CH573的性能不给力，配了个内置的SPI FLASH，代码只能在RAM中才能达到相应主频的性能，但是RAM只有18KB，需要一定的技巧。另外GPIO切换只支持bit clear，不支持bit set，有意为之？果断拿出吃灰中的AIR105，FLASH 4M+640K SRAM，204MHz的CortexM4核，使用C+ASM开发，真是信马由缰，自由奔腾。2/30x系列外设有所不同，High USB+CAN， AIR105没有，PK下性能会如何？ 真是一个困难选择症状的美好时代。
简单总结：
CH573=>性能不要太强的需求，但是要大FLASH的应用
AIR105 => 性能+FLASH+RAM平衡需求，QFN
CH3XX => HighSpeed USB+CAN
#58 8051/STC8/AT89C51/N76E003 » 针对51的代码压缩方法，榨取FLASH空间浅谈 » 2022-03-20 13:03:05
- llinjupt
- 回复： 6
这几天遭遇了头疼的事，就是功能增加太多，每个子功能调通后，开心地合并代码时傻眼了，代码超出了大约8KB，
这可不是超过一星半点，并且写程序的时候也已经相当注意数据类型的使用，所以到底能不能搞定，还真是头疼，
经过几天的“奋斗”，终于塞进去了。
把相关方法总结下，方便他人参考，也算抛砖引玉。
通常代码大小和代码速度存在矛盾，为了兼顾速度，而同时保持代码较小的目标，可以从以下方面考虑：
1.优先使用单字节类型
双字节和四字节大大增加处理代码，如果可以转化为单字节类型可以明显减小代码。这对于51单片机绝对是优化利器。如果想深入了解为什么，可以对比生成的汇编代码。
1.1 变量优先使用单字节
1.2 返回值优先使用单字节
1.3 如果bit类型够用，那么优先使用bit
2. 宏定义转为函数
宏定义存在多分拷贝，如果宏比较大，而又不是用在关键路径上，可以转换为函数。此法效果明显，但是要注意不能是性能关键路径。
3.优先使用data类型
data存储类型处理时对应的指令代码要比xdata和code的类型小得多。指针同样适用，优先使用特殊指针，而不是通用指针。
4. 查表法使用的表数据使用算法初始化
查表法可以大大提高程序执行效率，但与此同时将大大增加FLASH占用，那么可以在程序启动的时候初始化该表，这样RAM占用不变，FLASH只占用初始化的算法，而且不影响程序性能。
因为程序中有3比较大的表，两个CRC表，奇偶校验表，一下子解决2K空间，此法优化神速，但是对于没有采用查表法的程序基本无用。
5.打印字符串使用错误码
如果整个系统错误码不超过256个，那么一个错误码只需要占用1个字节，但是一行打印却要占用数十个字节，所以在调试时可以使用错误码转换函数，当正式版时不要编译该转换函数和错误字符表，而只打印错误码。这样可以通过源码的错误表，来解读错误信息。1个中型项目大约可以解决数K甚至数十K的FLASH空间。
不同的子系统也可以定义独立的错误码，那么基本可以保证使用单字节就可以完成整个系统的错误码定义了。
7. 如果不在意性能，那么使用size优先编译选项，通常可以压缩个好几K
8.超级武器
汇编
9.终极武器
$，$$，$$$，当然还有您的卓见。欢迎分享优化大法。
#64 Re: Cortex M0/M3/M4/M7 » 说说航顺的M0--优秀的国产替代 » 2022-02-18 11:41:01
那些国产山寨ST的MCU 多多少少都会有些问题。
实际上说所谓兼容，都是有限兼容，不可能做到完全兼容，除非拿到ST的版图，不过就算拿到，也不会有人冒着这个风险去生产，
否则只要开盖就能被原厂发现，那是卖多少赔多少，人还得进去。另外ST对各大厂商的仿制芯片，也是睁只眼闭只眼，毕竟现在主推G系列了。
实际上如果是自有源码的软件，根本不需要非采用这个型号，其他类型的片子功能已经做得相当强大，移植起来也不会有太大困难。只是国内替代芯片因为没有经过长时间的实际应用，在某些细节方面多多少少有些问题，不过这个过程过个三五年会有很大改善。目前最大的问题是国内有些厂商对问题遮遮掩掩，只有碰到了才会定向提供解决方案，这无疑给大家增加了很多试错成本，实际上产品的成熟单靠MCU厂商自身的有限测试是不足的。举这个例子，国内大部分的替代MCU多少都有安全隐患，大部分系列的固件可以在很短时间（分钟级）破解出来，安全这些部分还需要很大加强。
#66 Re: Cortex M0/M3/M4/M7 » 自己做的一个STM32开发板 » 2022-02-08 18:51:45
#68 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-02-07 22:33:10
欢迎探讨
开源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不是很大时，用于板载还是划算的。
#70 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 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灌入导致的。
#75 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-01-22 00:08:43
强帖，串口CDC在win10以上系统是不是不用装驱动？我在arm windows虚拟机里没有ch340的驱动，没有串口用，重金买回来的m1 macbook成了摆设。
WIN10 上集成了很多通用的 USB 驱动，例如 CDC 和 WINUSB，所以这类设备均无需安装驱动，对于 WINUSB 设备需要在 USB 描述符中提供 GUID 字段，系统会自动匹配驱动。
据我所知，CH340应该不是 CDC，而是类似CP2102的 VCP，需要安装厂商的私有驱动才能工作。
在虚拟机中使用USB设备，速度会大受影响，少量数据通信可以，不能用于测试评估用。
MacOS好像不支持 CDC 类设备，这和 Linux 不同，Linux 天生支持的很好。
#76 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2022-01-14 13:23:47
最近要做的工作好多，但是楼主绝不弃楼，先上图：
前段时间突发奇想，是否可以做到让 DAPLink 完全兼容 STLinkV2，毕竟有些时候需要开发STM8，那么就需要 SWIM，
另外一点就是支持最新的 STM32CubeProgrammer 升级. 现在在软件和硬件上已经得到了初步验证。
现在忙于规模稳定性测试，文档书写，备料，外加继续新增 AVR ISP 支持，感兴趣的可以参考开源项目 LUFA，速度比普通 USBAsp 不在一个级别，
并且完全支持官方最新开发环境 ATMEL Studio 7。AVR在国内 DIY 中不像 ST和STC流行，但是在国外用户众多，所以打算加进来， 这样就不需要一堆下载器了。不过要进行完全移植还需要时间。
等折腾完了，将部分功能源码开放，并把整个优化思路贴出来。
#77 Re: Cortex M0/M3/M4/M7 » DAPLink添加WINUSB支持。。 » 2022-01-13 21:35:15
#78 Re: Cortex M0/M3/M4/M7 » DAPLink添加软件复位功能。。 » 2021-12-26 16:09:01
#79 Re: Cortex M0/M3/M4/M7 » DAPLink添加软件复位功能。。 » 2021-12-26 10:18:44
#80 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2021-12-23 15:09:55
用相同的序列号，其实是为了换设备或者换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.
每一设备可以提供唯一的序列号，否则同时只能接入一个调试器，因为无法区分多个调试器。
#81 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 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不起作用，已提交给社区，等解决后再比对。
#82 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 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芯片的识别工具。
#83 Re: Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 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
STLinkV3MINI V3J9M3 24MHz
ELF DAPLink V2 10MHz
Keil性能测试方法，由于Keil无法单独打印烧写速度，只能通过统计时间来预估，这里通过在上一次烧写完毕后直接按F8进行下一次烧写，然后统计时间间隔。该时间是包含擦除，烧写和校验的，如下图打钩Verify。所有被烧写的程序都使用接近FLASH大小的bin文件，也即64KB的FLASH使用接近64KB的bin文件。
上一次下载即将结束时按住（尽量减小两次下载的间隔）F8键立即进行下一次下载，统计时间间隔48-38=10s，然后取三次间隔的均值：
目标芯片的IDCODE查看方法，因为某些丝印为STM32的芯片使用的是国产打磨后重印的芯片，所以这里给出测试芯片的IDCODE，以防遇到这类情况。通常情况下厂商间的IDCODE是不同的。
4.2 测试结果
(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为何没有明显速度优势？
#84 Cortex M0/M3/M4/M7 » 让 CMSIS-DAP DAPLink 功能和性能上升到新高度 » 2021-12-21 23:15:45
- llinjupt
- 回复： 88
折腾了一段时间，总算有所成果，随写随贴... 抛砖引玉，先分析当前能够见到的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，意为小精灵，但人小鬼大，一个顶仨。
先唠叨这么多，看起来成长篇大论了，后面贴性能对比图，外加加速思路，分析和实现。
#85 Re: Xilinx/Altera/FPGA/CPLD/Verilog » FT4232H可用的Xilinx FPGA JTAG调试器EEPROM分享 » 2021-10-13 13:42:14
@llinjupt
用 FT2232HL 实现，也是 dump 原厂的固件。
使用 FTDI 的 FT_Prog 程序就可以 dump 到 EEPROM 的固件，但是烧录不了的，会丢失一半的数据。有 256 字节的数据，FT_Prog 默认烧录成 0xFF。
我记得Xilinx 的Vivado就只用了其中的一些字段判定是否是Digilent的固件，这个CH552方案，应该要完全模拟相关上位机的请求，并反馈相同应答，如果这个方案真实存在，（网上说是打磨芯片，不确定是否是WCH），那么逆向工程做的还挺有趣的，因为它还模拟了FT_Prog的一套请求，也即USB这一套指令，应该使用了内部FLASH做EEPROM，这种模拟确实很新奇，可以推广用于模拟其他USB方案的芯片，这样成本就大大降低了
#86 Re: Xilinx/Altera/FPGA/CPLD/Verilog » FT4232H可用的Xilinx FPGA JTAG调试器EEPROM分享 » 2021-10-09 21:47:18
#88 Re: Xilinx/Altera/FPGA/CPLD/Verilog » FT4232H可用的Xilinx FPGA JTAG调试器EEPROM分享 » 2021-10-03 10:48:58
#91 Re: DIY/综合/Arduino/写字机/3D打印机/智能小车/平衡车/四轴飞行/MQTT/物联网 » 捡了个便宜的高级ZYNQ XC7Z010 开发板玩玩 » 2020-12-21 19:02:25
你们都太给力了，注意去原系统密码一定要模拟nand，实际测试用使用 mtdram是不能成功的。
# modprobe jffs2
# modprobe mtdblock
# modprobe nandsim first_id_byte=0x20 second_id_byte=0xa2 third_id_byte=0x00 fourth_id_byte=0x15 # 64Mb，由于rootfs大小为64Mb，这里必须设置为64Mb，其他大小参考：http://linux-mtd.infradead.org/faq/nand.html
# mtdinfo /dev/mtd0
mtd0
Name: NAND simulator partition 0 # 确保模拟出的是nandflash
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB # 必须和FLASH芯片规格保持一致
Amount of eraseblocks: 512 (67108864 bytes, 64.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 512 bytes
OOB size: 64 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true
破了原系统密码，就可以使用passwd设置新密码，这样ssh就可以进去了， 不用SD卡槽，不用串口，如果感兴趣可以改改原系统和硬件，自己生产矿机了，
原机web的登录名和密码都是admin和admin
页次： 1
- 首页
- » 搜索
- » llinjupt 发表的帖子