K-Res的Blog https://blog.k-res.net 欢迎留言、转载请注明出处 Sat, 02 Mar 2024 07:55:18 +0000 zh-CN hourly 1 https://wordpress.org/?v=6.4.3 给退役的路由器联想y1s硬改升级64M闪存 https://blog.k-res.net/archives/2993.html https://blog.k-res.net/archives/2993.html#respond Sat, 02 Mar 2024 07:55:16 +0000 https://blog.k-res.net/?p=2993 自从去年10月换了红米AX6000后,服役快10年的y1s终于迎来了退役的日子,此后便一直待在盒子里吃灰…

直到前段时间逛恩山论坛时无意间看到了 1421890054 大佬的这篇帖子:【2022-1-22】折腾一下OpenWrt-Lenovo-newifi-y1s-R22.1.1-mt7620a-USB,意识到原来y1s是可以支持更大容量的闪存的(原配winbond 25Q128 16M,装完op后基本就装不了什么软件了…),于是又翻出了退休的y1s,准备也试着硬改升级下闪存玩玩。

由于有恩山论坛大佬的分享,也就不研究可以兼容哪些型号的flash芯片了,直接去TB买了 MX25L25645GM2IMX25L51245GMI 各两片:

一片6R,还有4R运费,我的电子元件收藏库又++了😂,由于是春节放假前购买的,所以很快就到货了,后来买编程器时赶上假期耽误了不少时间。

闪存到手后看了下,32M的型号结尾是-10G,而64M的是-08G,与论坛帖子作者提到的也是-10G的并不一致,于是又去查了下datasheet:https://www.macronix.com/Lists/Datasheet/Attachments/8745/MX25L51245G,%203V,%20512Mb,%20v1.7.pdf,可以看到对元件型号的解释是:

08和10的区别是是否支持Factory Mode,又读了下手册上面的说明,应该是工厂量产用的,对我这样随便玩玩的应该是没任何区别,于是按照帖子作者的说明,进breed,备份了eeprom,截图了MAC地址修改界面,由于是人生第一次硬改路由器闪存,所以先按提示操作,然后又备份了编程器固件:

事实证明后续操作eeprom备份和MAC地址截图这两个东西都没有用上🤣,而只用了16M的编程器固件。顺便看了下当前breed里的系统信息:

可以看到原机信息上的闪存确实是Winbond的16M的,15年时还可以了,现在看就显得略小了…

接下来,开始拆机,这个网上当年刚发售后就有拆机了,可以搜索下,过程比较简单,就是四个脚垫下面有4个十字螺丝,拧下后就可以打开底板了:

打开后就可以看到PCB了,flash就是中间偏右下那个涂了个点儿的SOP8芯片:

到这其实就已经可以拆焊芯片了(对自己技能有信心的话),不过像我这样的业余选手,还是把板子彻底拆出来把:

拆的时候要注意两根天线的连线,可以看到y1s的做工还是很可以的,无论是pcb还是上面的接插件,都很讲究,小心的解开胶布,拔掉ipex(应该是叫这个)插头,然后板子就可以取出来了,接下来就是拆焊了,我用的文宇WY815P的风枪,怕手残吹飞旁边的小元件,于是跟附近的正反面都贴上了高温胶带:

然后就怼了助焊剂,开始吹,随后拆下了芯片:

不过这里没什么经验,下边5 6 7 8脚的焊盘其实已经被手残搞脱落了,后面飞线时就掉了,早知道应该参考帖子作者的方法,用烙铁堆锡拆可能会更好一些,至少是先加点有铅锡进去中和下原厂的无铅锡。

到这一步我本来以为原机的breed引导程序是在其他存储设备(cpu自带存储之类)里,所以直接就按照恩山帖子里的SOP8与SOP16闪存芯片引脚映射关系(还查了下数据手册确认了下):

结果发现开机后无法引导,一直闪黄灯(忘了哪个位置的灯了,按住reset上电也进不了breed),这才意识到没有编程器还是不行的(据说有人这么干,用原配flash引导breed,然后带点换新flash,然后直接刷机,我怕又手残再搞爆炸,就没铤而走险),这时已在春节假期中了,大部分TB卖编程器的店都放假了,最后找了一家不打烊的店,买了个土豪金CH341A编程器(实际到手发现芯片是CH341B,据说没区别,一样的慢😂)和SOP8宽体 200 mil, 5.38 mm、SOP16宽体 300 mil,7.6 mm 的烧录座,快递寄的申通,还算给力,和正常时间几乎没差别的3天到手,这次给申通点个赞!

编程器到手后,看了店家给的资料,驱动和软件都比较老,估计我的Win11是用不了的,于是果断删除,搜索了下恩山,找到了 Alangoa 大佬一直维护支持芯片的 NeoProgrammer_2.2.0.10 烧录软件:【2024-1-31】芯片库更新 CH341A-NeoProgrammer软件添加芯片详细教程 ,软件下好后还自作多情的先装了wch官方CH341的最新驱动:https://www.wch.cn/downloads/CH341SER_EXE.html,结果发现NeoProgrammer提示“连接时出错CH341(Not found)”,设备管理器里显示的是一个叫 usb to serial 的wch设备(记不清了,好像是叫这个),反正没有黄叹号之类的,琢磨了一下,发现恩山大佬的NeoProgrammer里带了驱动程序(Drivers文件夹里,软件和驱动都配了详细的文档、截图说明,大赞啊!),而且这个驱动不是官方23年的新版,而是09年的,不知道是不是因为驱动的原因,于是卸掉了原来的驱动,装上了这版,果然,烧录软件这次可以正产工作了,设备管理器中显示如下:

标识为外部接口,名称是USB-EPP/I2C…CH341A,显然和之前装的最新版不一样,但提供商都是wch.cn,不知为何,反正现在烧录软件能正确识别编程器了,不管了:

上面是检测到的原配Winbond 16M闪存(试着读取了下,发现虽然开头一样,但是后面部分数据和breed里备份出的编程器bin并不一致,不知为何,好在也没用上)。

上面是 MX25L25645GM2I 的识别结果,不知道是不是数据库的原因,型号和实际并不一致,但是选了25673G实测可以读取,32M耗时5min左右。

最后是最终上阵的 MX25L51245GMI ,这个识别结果还是准确的,于是直接把之前breed备份出的编程器16M固件bin写进去:

写16M的数据用了不到2分钟,感觉还好,但是。。。接下来点了下校验,又试了下读取验证,em…是网上传说的ch341龟速的味道,一次10分钟😂,好在这个编程器够便宜,我也不是指刷flash吃饭的,就不要什么自行车了。顺带一提,我买的烧录座SOP16的是转DIP16的,参考上面软件里的芯片脚位提示,可以看到,SOP16的上烧录座也是只用8个脚,和上面发的映射关系一致,虽然买土豪金的时候也赔了一块SOP8和SOP16转宽窄DIP8的小板,但考虑到还需要焊接,比较麻烦,而我又有一边公一边母的杜邦线,于是自己适配了下SOP16的烧录座:

顺利完成写入,然后飞线路由器主板上,开始提到的手残导致半边焊盘脱落问题,把飞线连到附近走线位置的电阻、空焊点上了:

上电测试,直接成功进了op系统,原封不动照搬了原来16M里的东西,一切正常,接下来reset进breed,也正常,并且和论坛大佬帖子一样,正常识别出了64M的闪存:

又确认了下MAC地址也和改装前的一致,这就是前面说的eeprom和截图都没用上的原因了。接下来直接刷了帖子大佬放出的64M固件,重启后感觉开机变慢了,估计是带的软件多了,好在最后成功进入新版op系统:

可以看到还有15M左右的自由空间可以愉快的装其他软件😁,简单试了下无线、有线啥的也都正常,不过就是之前pandora的时候,大logo的呼吸灯还能亮,现在这版系统直接灭了,调了半天也没搞明白怎么点亮,倒是减少了光污染,后面有空再研究吧。

最后,也学着大佬的样子,给飞线的焊盘和flash芯片贴了个透明胶固定:

希望别有脱落、虚焊的地方,后面再返工。最后,装壳完工,和编程器一起合个影:

]]>
https://blog.k-res.net/archives/2993.html/feed 0
Systemd – Failed to reload daemon: Refusing to reload, not enough space available on /run/systemd https://blog.k-res.net/archives/2986.html https://blog.k-res.net/archives/2986.html#respond Fri, 09 Feb 2024 13:36:21 +0000 https://blog.k-res.net/?p=2986 最近在配置一台128M内存运行debian 11系统的虚拟机时,遇到了修改systemd服务配置后reload时报错的情况,提示信息如标题所写,排查后发现debian系统安装后默认配置的/run空间大小是和系统内存数成比例的,而默认分配的16M空间,在执行“systemctl daemon-reload”时就会提示上面的错误信息,还会说明类似如下信息:

Currently, XX.XM are free, but a safety buffer of 16.0M is enforced.

解决的方法就是想办法加大这个/run就可以了,修改/etc/fstab,追加如下内容:

none /run tmpfs defaults,size=64M 0 0

这里指定了64M空间用于/run,按网上的说法这样应该可以应付绝大部分情况,之后执行:

mount -o remount /run

重新挂载/run,完成后可以用“df -hT”确认下当前/run的大小,增大后再次daemon-reload即可正常操作了。

]]>
https://blog.k-res.net/archives/2986.html/feed 0
VS 2022构建boost 1.57.0时的missing argument global-setup问题 https://blog.k-res.net/archives/2974.html https://blog.k-res.net/archives/2974.html#respond Fri, 12 Jan 2024 12:14:07 +0000 https://blog.k-res.net/?p=2974 最近要用到一个库,依赖boost,于是久违的下载了需求的最低版本1.57的boost拿来build一把,结果已开具就遇到了坑…

目前用的编译器是VS 2022的toolchain,于是打开x64 Native Tools命令行,进到boost源码路径,简单看了下说明,敲了“bootstrap.bat”,提示:

Building Boost.Build engine
cl: 命令行 warning D9035 :“GZ”选项已否决,并将在将来的版本中移除
cl: 命令行 warning D9036 :使用“RTC1”而不使用“GZ”
cl: 命令行 warning D9002 :忽略未知选项“/MLd”

Bootstrapping is done. To build, run:

    .\b2

To adjust configuration, edit 'project-config.jam'.
Further information:

    - Command line help:
    .\b2 --help

    - Getting started guide:
    http://boost.org/more/getting_started/windows.html

    - Boost.Build documentation:
    http://www.boost.org/boost-build2/doc/html/index.html

接着按提示执行b2,然后问题就来了:

D:/Projects/CLion/boost_1_57_0/tools/build/src/tools\msvc.jam:1075: in configure-really
*** argument error
* rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup : default-global-setup-options : default-setup )
* called with: ( default : D:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\bin\Hostx64\x64 : D:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\bin\Hostx64 :  : i386 :  : x86 : vcvars32.bat )
* missing argument global-setup
D:/Projects/CLion/boost_1_57_0/tools/build/src/tools\msvc.jam:809:see definition of rule 'generate-setup-cmd' being called
D:/Projects/CLion/boost_1_57_0/tools/build/src/tools\msvc.jam:201: in configure
D:/Projects/CLion/boost_1_57_0/tools/build/src/tools\msvc.jam:153: in msvc.init
D:/Projects/CLion/boost_1_57_0/tools/build/src/build\toolset.jam:43: in toolset.using
D:/Projects/CLion/boost_1_57_0/tools/build/src/build\project.jam:1007: in using
project-config.jam:3: in modules.load
D:/Projects/CLion/boost_1_57_0/tools/build/src\build-system.jam:249: in load-config
D:/Projects/CLion/boost_1_57_0/tools/build/src\build-system.jam:412: in load-configuration-files
D:/Projects/CLion/boost_1_57_0/tools/build/src\build-system.jam:524: in load
D:\Projects\CLion\boost_1_57_0\tools\build\src/kernel\modules.jam:289: in import
D:\Projects\CLion\boost_1_57_0\tools\build\src/kernel/bootstrap.jam:139: in boost-build
D:\Projects\CLion\boost_1_57_0\boost-build.jam:17: in module scope

很奇怪,这么有名历史悠久的开源项目,居然会有构建问题,我用的也不是什么小众操作系统,编译器,参考下面这篇搜索出的提示,居然要手改bootstrap生成的配置文件:

https://stackoverflow.com/questions/56814269/boost-installation-missing-argument-global-setup

将project-config.jam改成如下

import option ; 
 
using msvc : 14.0 : "D:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\bin\Hostx64\x64\cl.exe";

option.set keep-going : false ; 

主要就是using msvc那行,自动生成的文件貌似没有正确识别出VS2022的cl.exe位置,改成上面这样后,再次执行b2就可以正常构建了。

]]>
https://blog.k-res.net/archives/2974.html/feed 0
关于spring框架使用websocket + stomp协议时的发消息顺序问题 https://blog.k-res.net/archives/2972.html https://blog.k-res.net/archives/2972.html#respond Sun, 10 Dec 2023 03:13:29 +0000 https://blog.k-res.net/?p=2972 还是继续上一篇stomp的问题,这次是在实际使用中又有了新发现,那就是java后端向前端发送stomp消息时,存在底层异步操作造成的消息顺序不确定性问题,如下:

    @Autowired
    SimpMessageSendingOperations messagingTemplate;

    @MessageMapping("/create")
    @SendToUser("/queue/reply")
    public ReplyDTO create(@Payload CreateDTO msg, SimpMessageHeaderAccessor accessor) throws Exception {
        String userId = getUserId(accessor);
        if (userId.isEmpty())
            return buildNotLoggedInReply(accessor);
        int createId = myService.create(userId, msg.getTypeName());
        CreateInfo ci = myService.info(createId);
        String infoStr = new ObjectMapper().writeValueAsString(ci);

        messagingTemplate.convertAndSendToUser(
                Objects.requireNonNull(accessor.getSessionId()),
                "/queue/response",
                buildOkResp(accessor),
                createHeaders(accessor.getSessionId())
        );

        return buildReply(accessor, infoStr);
    }

上面是一段很简单的stomp收发消息代码,但是在create方法内部除了常规return返回要发送消息DTO实例外,还通过SimpMessageSendingOperations单独给同一个session发送了另一个消息response,按目前看到的这部分代码我们认为,/queue/response应该先于/queue/reply消息到达前端,因为这也没有使用多线程或其他会导致顺序错乱的逻辑,而实际程序运行情况却并非如此,在比较极端的情况下,如程序跑在资源非常受限的虚拟机上时,会发现偶尔会有reply先于response的情况!

通过现象判断,spring stomp框架底层应该是有某种多线程处理上层待发送消息的机制,根据这个想法进行了一番搜索,果然在github上发现了spring项目的这个issue:https://github.com/spring-projects/spring-framework/issues/18562 Preserve order of broker messages [SPR-13989],看提问人描述的现象跟我现在遇到的问题很像,官方解释就是底层存在异步操作(有一点刚才没有明确,上面的代码里,response发送的DTO内容相对复杂,而后面的reply则相对简单),在性能不足时,就会导致调用publish的顺序与对端接收到的消息顺序不一致的问题,这点在新版本spring中给出了一种解决方案:“preservePublishOrder”,具体可以参考:https://docs.spring.io/spring-framework/reference/web/websocket/stomp/ordered-messages.html,按照官方说法,加上这个参数可以强制底层保证publish消息顺序,但会有一些性能损失。

按照调查发现,找了下,结果发现我这用的spring版本比较旧,还没加上这个preservePublishOrder,而暂时又不想升级,更不想损失一点性能,所以换了一种思路,将需要保证顺序且连续发送的消息合并为一个大消息,一次发送,这样就回避了这个顺序问题。

]]>
https://blog.k-res.net/archives/2972.html/feed 0
cannot deserialize from Object value (no delegate- or property-based Creator) https://blog.k-res.net/archives/2963.html https://blog.k-res.net/archives/2963.html#respond Sat, 04 Nov 2023 04:25:14 +0000 https://blog.k-res.net/?p=2963 最近研究springstomp协议框架,上到消息订阅、发送时一开始用的普通String,没有任何问题,都可以跑通,后来上DTO数据对象时,遇到了标题上的问题,查了下发现是框架层在调用jackson自动反序列化json为DTO对象时报的错,很久没用java,都忘记了,参考下面链接的说明

https://blog.csdn.net/weixin_39827145/article/details/89314433

意识到jackson反序列化时默认的行为是需要class的无参构造,之后再处理各个属性对应到json key的value,而出问题是的DTO class上用的lombok标记是“@AllArgsConstructor”,只生成了全成员变量参数构造,因此导致了此问题,把接收stomp请求,用于对应@Payload的class换成@NoArgsConstructor(当然,一般还要带上@Getter,用于成员变量的访问)后,问题解决,接收到stomp请求后,成功传递到了controller的对应处理方法中。小问题连带了一个小知识点,记录一下。

]]>
https://blog.k-res.net/archives/2963.html/feed 0
也记一篇关于strncpy和snprintf中n的不同之处 https://blog.k-res.net/archives/2957.html https://blog.k-res.net/archives/2957.html#respond Tue, 03 Oct 2023 03:59:04 +0000 https://blog.k-res.net/?p=2957 关于这俩c库函数的使用方法,百度上一搜能搜到很多,但是实际上用了这么多年的我有时候还是会犯迷糊,分不清哪个是处理0结尾的,哪个是没有的,因此今天趁着放假有时间,再整理记录一下。

#include <cstring>

int main(int argc, char *argv[])
{
    char sz_test1[10] = {};
    char sz_test2[10] = {};

    char sz_source[10] = "123456789";

    strncpy(sz_test1, sz_source, 10);
    snprintf(sz_test2, 10, "%s", sz_source);

    return 0;
}

上面是一段很简单的写在cpp里的c代码,纯c也差不多,主要说的是这俩c函数的区别,可以看到sz_source有9个字符,带1个结尾0凑成10字节的字符串,上面还有两个同样是10字节的char缓冲区用于测试,可以看到strncpysnprintf的n都给10的时候,sz_test1和sz_test2都是和sz_source一样的结果,包括结尾0。

接下来把两个函数的n都换成9,这时候可以看到如下结果:

test1还是和source一样,而test2变成了12345678的0结尾字符串,少了一个9,也就是说snprintf的n是包含了结尾0的处理的,也就是写的9,实际上是拷了8个字符+1个0结尾,而strncpy的n,则是指的不包含0结尾的字符数,所以写的9也好,写10也好,最后都完整拷贝了source的9个字符。继续减n到8可以看到用strncpy的test1变成了到8结束,用snprintf的test2则变成了到7结束。

接下来,修改下刚才的代码,换成一个特殊些的情况:

#include <cstring>

int main(int argc, char *argv[])
{
    char sz_test1[10] = {};
    char sz_test2[10] = {};

    char sz_source[10] = {'1', '2', '3', '4', '5', '6', '7', '8', '9', 'A'};

    strncpy(sz_test1, sz_source, 10);
    snprintf(sz_test2, 10, "%s", sz_source);

    return 0;
}

这次,source的初始化不再以0结尾字符串方式处理,而换成了直接用满10个字节的缓冲区形式,也就是说source不再是标准的0结尾字符串了,这个时候可以看到n还给10的话,结果如下:

可以看到,test1和source一样,占满了10个字节,没有0结尾,而,test2则还是个0结尾的c字符串,字符拷贝到了9!

所以从这点来看,一般我们处理这种字符拷贝的时候,会把n写成目标缓冲的大小,比如sizeof(sz_test1),也就是编译器就能确定的10,而这时,如果源缓冲不是0结尾字符串的话,就会导致strncpy得到的结果也不是0结尾,后续访问的时候处理不好就会出内存访问问题,相对来说snprintf的n也给sizeof目标缓冲大小的话,就更安全些,怎么都会加上结尾0,内容部分则会出现截断。

]]>
https://blog.k-res.net/archives/2957.html/feed 0
关于x265编码使用CBR流控码率不达标问题的处理 https://blog.k-res.net/archives/2953.html https://blog.k-res.net/archives/2953.html#respond Sun, 17 Sep 2023 03:31:13 +0000 https://blog.k-res.net/?p=2953 之前在使用x264编码时所谓的CBR流控其实是通过abr流控+vbv码率、缓冲参数设置的(vbv-maxrate,vbv-bufsize,也可以是ffmpeg的minrate,maxrate,如“ffmpeg -re -stream_loop -1 -i test.mp4 -c:v libx264 -x264-params “nal-hrd=cbr:force-cfr=1” -b:v 4M -minrate 4M -maxrate 4M -bufsize 1M -f flv rtmp://127.0.0.1/live/test,即控制了波动范围的vbr,而到了x265编码时,发现如法炮制的参数并不好使了,码率还是会有较大范围的波动,最后搜索研究了很久后发现,原来x265有这么个参数:

–[no-]strict-cbr Enable stricter conditions and tolerance for bitrate deviations in CBR mode. Default %s\n”, OPT(param->rc.bStrictCbr));

实测加上这个参数后,编码输出码率几乎就是目标码率很小范围内波动了,ffmpeg命令如下:

ffmpeg -re -stream_loop -1 -i <input> -c:v libx265 -b:v 25M -muxrate 30M -x265-params strict-cbr=1:vbv-bufsize=25000:vbv-maxrate=25000 -c:a aac -ac 2 -b:a 128k -f mpegts udp://239.3.3.3:5000
]]>
https://blog.k-res.net/archives/2953.html/feed 0
[转]将立创EDA中PCB元件封装转换为KiCad格式方法 https://blog.k-res.net/archives/2939.html https://blog.k-res.net/archives/2939.html#respond Sun, 20 Aug 2023 03:08:35 +0000 https://blog.k-res.net/?p=2939 最近在学习EDA,使用的是开源的KiCad,基本操作还是挺简单的,但是众多的电子元件符号、封装相比起来还是不如立创EDA这种web版生态完善的来的方便,好在网上找到了将立创EDAPCB元件封装导入KiCad的方法(拿来主义,哈哈),原文在这里:http://www.taodudu.cc/news/show-5505674.html?action=onClick,转过来记录一下:

在使用KiCad软件的时候,有些元器件的封装没用合适的,需要自己画。但是自己画起来比较麻烦,这时候就可以直接去立创EDA软件中下载。
  首先登陆立创网页版的EDA,网址:https://pro.lceda.cn/ 进入标准版。

然后新建一个PCB文件,在里面放入自己想要的封装。

在这里放了一个STM8和一个STM32单片机的封装。然后选择文件—导出—立创EDA

选择需要存储的路径,并修改需要保存的文件名。

接下来打开 在线转换网站 EasyEDA Files To KiCad EDA
网址:https://wokwi.com/tools/easyeda2kicad

然后点击文件上传按钮,上传刚才导出的PCB文件。

文件转换完成后就会弹出一个下载按钮,保存转换成功后的PCB文件。

这时候就可以直接用KiCad软件打开刚才转换后的PCB文件,这里没有直接转换成器件封装,如果需要封装的话,可以使用KiCad的封装导出功能。

选择文件—归档封装,可以将封装归档到当前现有的库中,也可以将封装归档到新的封装库中。

这样就可以直接在KiCad软件中直接使用立创EDA中的封装了。

PS:总的来说操作还是很简单的,关键是靠EasyEDA Files To KiCad EDA做数据文件格式转换,导入KiCad后虽然还需要做些焊盘编号调整之类的工作,但比自己照着数据手册画已经省了不少事了。目前学习了解到的知识,EDA软件的元件库主要是三大块:符号、封装和3D模型,符号个人认为比较好画,封装本次记录了导入立创EDA数据的方法,也算是省了很多事,3D模型算是锦上添花吧,百度的过程中了解到也是可以从立创导入的,后面研究明白了再来记录。

]]>
https://blog.k-res.net/archives/2939.html/feed 0
合宙AIR32使用Keil的Event Recorder实现日志查看功能 https://blog.k-res.net/archives/2916.html https://blog.k-res.net/archives/2916.html#respond Sat, 15 Jul 2023 04:02:03 +0000 https://blog.k-res.net/?p=2916 之前曾经写过一篇 魔改国产ST-LINK V2仿真器,增加SWO支持 的博文,记录了给山寨ST-LINK V2增加SWO引脚引出的方法,而今天要说的是,这个方法在合宙的AIR32系列MCU上实测并不不好用,原因在于:https://wiki.luatos.com/chips/air32f103/switchFromSxx.html#debug-sw-jtag ,这里合宙官方的文档上描述了AIR32与STM32的JTAG关断差异,简单说就是SWD和JTAG同气连枝,要开都开,要关都关,而后面又有关于SWO的描述:https://wiki.luatos.com/chips/air32f103/switchFromSxx.html#traceswo-printf,要使用SWO则必须关掉JTAG但保留SWD(这个目前我理解是SWO的printf输出依赖SWD调试),但是尴尬的是:https://wiki.luatos.com/chips/air32f103/switchFromSxx.html#jtag-jtrst,调试状态关JTAG会导致程序复位,这几个情况叠加在一起就造成了我试验时的现象:接上魔改的ST-LINK V2的SWO,一通配置Keil调试设置和代码设置(具体不写了,百度一搜一大堆),然后调试启动后确实能看到SWO的输出,但是过一小会儿,程序就重置了。。。😂于是,我又开始寻找其它方案(其实最后还是换了带串口的DAP-LINK,走UART打log了,这里记录的是研究过程),最终使用Keil的中间件(应该是这么叫吧)Event Recorder实现了既不依赖SWO,也不用串口,就SWD那几根儿线打log的功能:

首先,这个方法的官网介绍在此:https://www.keil.com/pack/doc/compiler/EventRecorder/html/er_use.html,百度上也有查Event Recorder这个关键字也能搜出不少中文教程说明,大致思路就是EVR中间件会在MCU的内存里开辟一块空间(大小用户指定,越大越不容易丢log),然后打印log的代码不断往这块内存的描述的队列里写,SWD调试不断地读(并移除),然后在IDE上的er窗口中显示出来。

在Keil的Run-Time组件管理中也可以很方便的指定上STDOUT到EVR的重定向,代码中程序入口处做好

EventRecorderInitialize(EventRecordAll, 1U);
EventRecorderStart();

初始化,后面printf就可以了,同时还支持像:EventStartA,EventStopA这类的事件型log API,可以很方便的评估某段逻辑的执行时间等。

最后记录下试验EVR时遇到的一个小坑,最开始用的5.23版本(网上号称的稳定版),死活都看不到EVR的输出,最后在一个国外网站上看到有人问类似的问题,答案说是版本问题,随后直接升级到了5.38,果然,一切正常了。。。😂

最后的最后,这只是个探索过程的记录,最后博主还是又买了一个合宙的AIR32小黑板,刷上最新的DAP-LINK固件(现在又出了个DAP-LINK专用的迷你版,略坑),接上UART的两根线,用中断方式的串口收法数据方式来调试了,毕竟是双向的,而且之前用atmega328p的arduino时也都是这样双向串口调试的,不依赖于SWD调试,可能更方便一些吧。

]]>
https://blog.k-res.net/archives/2916.html/feed 0
又换了个鼠标微动,顺便试用了下“大黑棒子”吸锡器 https://blog.k-res.net/archives/2924.html https://blog.k-res.net/archives/2924.html#respond Sun, 04 Jun 2023 10:10:35 +0000 https://blog.k-res.net/?p=2924 这次坏的是公司用的明基鼠标(具体型号不明,海贝A800键盘套装送的,用着还算顺手,也是10多年的了),这个鼠标几年前滚轮编码器坏过,当时更换编码器时还特意检查了下左右键微动,是凯华的,感觉好像还挺耐用的,就没管它,结果最近发现左键开始出现接触不良的情况,拖动窗口按着按键有时自己就松开了,严重影响各种拖拽操作,容易造成意外,于是赶紧换了个之前存货的凯华红微动

其实鼠标上的各种按键、编码器之类的都换过不少次了,这次专门博客记录下是因为这次的拆焊是用“大黑棒子”手动吸锡器完成的:

展示下我的所有吸锡器

左右两边都是SY的,左边是用了10多年的带电加热的,之前拆直插基本都用这个,原因就是右边那个手动的一直用不好,烙铁和吸锡器左右手配合有一定难度,总是吸不干净,最后还是用电热拆的,不过这个电热的控制不好火候的话容易把焊盘搞掉,另外这个电热的也有年头了,最近发现拉杆处的塑料卡子裂开了,导致密闭性变差,吸力小了不少,于是开始研究替换设备。

淘宝看了看,快克、宝工的吸锡枪不错,但是贼贵,比我的俩焊台加一块都贵,咱也不是指这个吃饭的,感觉没必要,正考虑再买个同样的这种半自动带电热的时候,看到视频网站上推了一款日本工程师SS-02的小巧金属吸锡器(感谢大数据),看着很好用,淘宝一搜,100多,也不便宜,后来发现一些技术论坛上也提到这款吸锡器,并说精髓其实在套在吸锡器头上的高温软管上,仔细想了想,感觉还挺有道理的,之前自己手动吸锡器用不好,一个是左右手配合时机掌握不好,另一个就是这个吸嘴是个硬塑料的,虽然防烫,但是不是很容易密封住要吸的焊点,而前面套个不怕烫的软管,确实很好的解决了这个问题,想明白这点后,淘宝找了个上图中间那款“大黑棒子”(选这款是因为文宇焊台群里很多焊武帝经常推荐“大蓝棒子”,而这款黑棒子号称双环气密更好,吸力更强,价格也都是十几块的东西,黑色还禁脏,想来应该更好用…),外加有配类似SS-02的高温软管。

到货后一直也没用,终于等到了这次的鼠标换微动机会,裁好软管套吸嘴上,试了一下,效果果然非同凡响,可以看上上图,一次吸净!果然精髓其实是在那个软管上,弥补了自己的手残。

PS:买吸锡器的过程中,其实还被大数据推荐了这个拆直插的小工具:

就是这个空心针,也有直接用尺寸合适的注射器针头的,这个我也买了一套,中途也试用过,怎么说呢,某些场景下确实可以用,但是普适性不强,比如元件引脚宽,过孔又窄时,无论什么尺寸的针头其实都很难插进去,适用情况不多,不过只要能把针顺着过孔插进去的话,也还是挺方便的,当然最好还得配合嘻嘻线,做好拔出元件后的过孔堵塞清理工作。

]]>
https://blog.k-res.net/archives/2924.html/feed 0