欢迎留言、转载请注明出处
本博主的主要乐趣所在！
Qt GUI程序封成动态库方式，供其他非Qt程序加载使用时，遇到一个GUI初始化并显示时，大概10s后程序崩溃的问题，调用栈显示崩溃在主线程的NSPersistentUIRequiresSecureCoding函数调用中，如下图所示：
经过排查以及互联网搜索，发现了Qt论坛上有人问到了类似问题：https://forum.qt.io/topic/159548/building-a-dll-on-macos-for-a-non-qt-application/7，原来Qt GUI在以库方式加载使用时，还要设置额外的初始化标识：
1 2 | QGuiApplication::setAttribute(Qt::AA_PluginApplication);QGuiApplication::setQuitOnLastWindowClosed(false); |
主要是上面的Qt::AA_PluginApplication，看来Qt内部有针对这种plugin方式使用的特殊处理逻辑，加上这个attribute后，再次测试，就不再崩溃了。
最近在测试Xcode原生Mac Cocoa GUI应用中直接调用Qt GUI时遇到了一个报错找不到native plugin的问题。先记录下操作系统是：macOS 13.4，Xcode版本是：Version 14.3 (14E222b)，Qt版本是：6.8.0。用法是在Xcode中新建一个App，interface选的xib（但应该没关系，因为根本没用任何xcode GUI编辑功能），然后在生成的的代码项目中手动加入各种依赖的Qt Framework，并设置好include，lib，rpath等各种路径。代码也是从网上搜到的很简单的创建Qt空间后，通过winId的方式（这是Qt6新改的，以前的Qt5及旧版本需要使用QMacNativeWidget）挂到NSView下，如下：
1 2 3 4 5 6 7 8 9 | - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { // Insert code here to initialize your application QPushButton* btn = new QPushButton("testtttttttttttt"); NSView* viewBtn = (__bridge NSView*)((void*)btn->winId()); [self.window.contentView addSubview:viewBtn]; btn->show(); [viewBtn setNeedsDisplay:YES]; [self.window makeKeyAndOrderFront:self.window];} |
需要注意的是开了ARC后的winId返回到NSView*的cast，c cast，c++ cast直接用都不行，查了半天才找到这种__bridge cast配合强转void*的可行方式。
然后运行，发现了标题中的报错信息：
Continue reading…最近在研究基于STM32F103CBT6单片机的USB HID鼠标设备实现，电路部分主要抄自各开源实现，今天要记录的主要是单片机软件方面的问题：测试阶段发现如果在开机前先插好USB鼠标，再开机，有一定概率出现鼠标操作没反应的情况！并且这个现象在我的笔记本（联想thinkbook 14+，支持关机USB充电）上要比台式机（技嘉X570+5700x，前置USB）上出现几率高不少，基本上开3次就能有1次出现这种情况。
先说明下，MCU软件部分主要基于ST的“STM32F10x, STM32L1xx and STM32F3xx USB full speed device library (UM0424)” https://www.st.com/en/embedded-software/stsw-stm32121.html USB库实现，里面有HID实现的例子，基本都是照抄的，改了下Joystick例子的USB描述符，报文相关参数（3按键+1滚轮+XY移动，1ms轮询）。电路部分，一开始实验的时候用的是合宙的AIR32F103，对比STM32F103，支持USB DP的内部1.5k上拉，自己画板制作的时候由于STM32F103没有内部DP上拉，于是简单做了个固定1.5k到3.3v的上拉，做这个设计的过程中已经查到过有些资料参考ST-LINK的设计，应该使用一个GPIO口，通过加NPN开关三极管方式驱动这个1.5k上拉，用于遵守USB 2.0规范约定的设备可枚举信号，同时也根据这个wiki的描述：https://stm32world.com/wiki/STM32_USB_Device_Renumeration ，实测这种通过将DP端口改为PP输出，并拉低50ms左右的非标准做法，也可以实现控制枚举、软件重枚举的功能。于是就没做类似ST-LINK的设计，所以一开始发现标题问题时，以为是这种非标准的USB枚举初始化导致，但是后来通过观察出现问题时的串口日志发现USB初始化枚举都正常，只是在等待轮询取上报数据时出现了问题！
研究了一番后，找到了一个简单的解决方法，加了个超时重置标识变量的方法，如下：
Continue reading…还是先说下环境，系统是CentOS 7.9（怕玩坏了，用的docker，官方镜像centos:centos7.9.2009），配合ARM官方的linux工具链gcc-arm-8.3-2019.03-x86_64-aarch64_be-linux-gnu.tar.xz（这里： https://developer.arm.com/downloads/-/gnu-a），解压到了 /usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu，使用环境变量：
exportAR="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-ar"exportAS="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-as"exportCC="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc"exportCXX="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-g++"exportRANLIB="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-ranlib"exportSTRIP="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-strip"exportPATH="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin:$PATH"
来指定交叉编译工具链，依赖的libsamplerate库版本是：0.2.2，报错信息如下：
Continue reading…/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/bin/ld: /usr/lib64/libm.so: error adding symbols: file in wrong format
首先，简单说明下问题情境，一共三个代码文件，一个主执行程序，两个动态库程序，结构与之前写的弱符号，weak symbol一致：
1 2 3 4 5 6 7 8 9 10 11 12 13 | #include <string>std::string g_name;void init_name_lib1(){ g_name = "lib1";}const char* get_name_lib1(){ return g_name.c_str();} |
1 2 3 4 5 6 7 8 9 10 11 12 13 | #include <string>std::string g_name;void init_name_lib2(){ g_name = "lib2";}const char* get_name_lib2(){ return g_name.c_str();} |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | #include <iostream>void init_name_lib1();void init_name_lib2();const char* get_name_lib1();const char* get_name_lib2();int main(){ init_name_lib1(); init_name_lib2(); std::cout << "name from lib1: " << get_name_lib1() << std::endl; std::cout << "name from lib2: " << get_name_lib2() << std::endl; return EXIT_SUCCESS;} |
首先说明下代码结构：一共三个源码，两个动态库so的源码：lib1.c和lib2.c，各导出一个库函数（gcc编译时默认导出，不像windows的msvc要明确指定导出dllexport），一个主执行程序源码：main.c，调用两个动态库的导出函数，如下：
lib1.c
1 2 3 4 5 6 | #include <stdio.h>void lib1_func(const char* from){ printf("lib1 func from %s\n", from);} |
lib2.c
1 2 3 4 5 6 | #include <stdio.h>void lib2_func(const char* from){ printf("lib2 func from %s\n", from);} |
main.c
1 2 3 4 5 6 7 8 9 10 11 12 | #include <stdio.h>void lib1_func(const char* from);void lib2_func(const char* from);int main(){ printf("hello from main\n"); lib1_func("main"); lib2_func("main"); return 0;} |
最近在搞一个依赖了开源库fftw（写此文时用的官网最新发布版3.3.10，https://www.fftw.org/fftw-3.3.10.tar.gz）的代码，项目使用cmake构建，fftw依赖以子项目的方式引入：
1 | add_subdirectory(dep/fftw-3.3.10) |
测试后发现调用代码使用的是float版的接口，也就是需要通过设置“ENABLE_FLOAT”这个选项来编译fftw，参见：
1 2 3 4 5 6 7 8 | set (FFTW_VERSION 3.3.9)set (PREC_SUFFIX)if (ENABLE_FLOAT) set (FFTW_SINGLE TRUE) set (BENCHFFT_SINGLE TRUE) set (PREC_SUFFIX f)endif () |
由于这个是调用代码的刚需，所以不想通过cmake命令行传递此设置，于是想到了再add_subdirectory前临时设置下这个选项，如下：
Continue reading…事情的起因是想通过W801实现检测到gpio电平变化后，通过telegram发送bot通知消息，结果在调用自己的tg api反代（caddy v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=）接口时，串口日志提示标题上的ssl握手0x7780错误。
代码是直接抄的SDK示例中的demo\wm_https_demo.c代码，报错的函数是在握手时，也就是调用HTTPWrapperSSLConnect的时候，如下：
1 2 3 4 5 6 7 8 | wm_printf("step 1: ssl connect to...\r\n");ret = HTTPWrapperSSLConnect(&ssl_p, fd, (const struct sockaddr *)&server, sizeof(server), HTTPS_DEMO_SERVER);if (ret < 0){ wm_printf("https connect error\r\n"); close(fd); break;} |
开始的时候只是能看到串口输出step 1: ssl connect to…，然后报了个0x7780的错误，接下来https connect error，请求失败返回，研究了下内部使用的mbedtls库，发现其实还有更详细的调试日志，要在SDK的\src\app\mbedtls\include\mbedtls\config.h中打开“define MBEDTLS_DEBUG_C”这行宏定义（并且需要确保makefile项目的lib目标重新构建，如果是参考我之前的CLion IDE用法，就是在构建的configuration里选择lib，然后rebuild），打开后就能看到类似：https://forums.mbed.com/t/error-0x7780-during-handshake/6883 这里提到的错误信息：
Continue reading…最近在Mac系统下尝试编译FFmpeg源码，虽然由于都是nix系的系统，比Win下编译方便很多，但还是遇到一些由于系统差异导致的问题。首先是依赖库libxml2编译时，提示：
-bash: libtoolize: command not found
这个问题，简单调查后发现是由于Mac系统已经存在libtool这个工具，但是功能不同，而相同功能的工具程序换了个名字，叫glibtool，可以通过brew安装，参考这个地址：https://stackoverflow.com/questions/15448582/installed-libtool-but-libtoolize-not-found
glibtool可用后，增加个符号链接，或者改下libxml2的构建脚本，就可以build成功了。
第二个要记录的问题是FFmpeg在编译时，由于使用的是Xcode命令行工具安装的clang，无法识别gcc的“-Wl,rpath=”链接命令，用于指定rpath。
这个问题参考这个github上的issue描述：https://github.com/klee/klee/issues/591，将指定rpath链接参数的写法换成“-Wl,-rpath xxx”即可，多个rpath路径时可以参考下Xcode项目设置里增加rpath后生成的编译链接命令写法。
之前9块钱促销买了块海凌科（Hi-Link）的W801开发板HLK-W801-KIT-V1.1：
到手后看了各种资料用CDK IDE搭起了开发环境，简单试了试灯，还踩了个Upgrade Tools上传程序的坑：W801开发板Upgrade Tools上传程序失败问题，那之后这块板就吃灰了😂，最近因为发现网口WOL网络唤醒在电脑完全断电恢复后无法使用的问题（试了自己和朋友的几台电脑，华硕的x370主板、技嘉的x570主板、公司的技嘉z390主板都不行，网上看有人说自己的电脑可以掉电后WOL，介绍的各种设置方法也基本都试了个遍，无果）, 打算研究个IoT远程开机功能，嘉立创的开源平台上一搜能搜到很多，但大都基于ESP的MCU，于是又想起了这块W801…不过用惯了VS、Xcode、CLion的我对之前使用CDK的体验着实不怎么样，在联盛德的官方论坛上也看到有人基于VSCode搭建了开发环境，有win下配msys的，也有走远程linux编译的，由于本人实在是对cgywin，mingw这类windows下移植linux环境的工具不感兴趣，所以这回打算尝试下远程linux编译的方式再次搭建下W801的开发环境，同时使用最近经常用的CLion IDE（我用的Nova版，写此文的时候还处于EAP状态，已经进入RC状态了，下载2024.1 RC版（设置中高级里启用ReSharper 引擎，重启后就是Nova办了），但实际测试并没发现什么严重问题，理论上稳定版对远程linux开发支持应该也是一样的），另外，多说一句，虽然说的是remote linux，其实WSL，或者本地虚拟机也都是一个道理，那下面我就记录下这样搭环境的主要步骤。