最近完成的项目

最近闭关主要在做这个 数据采集卡DAQ 的尝试，但是最终做成了虚拟示波器的样子。

设计宗旨是即插即用、即开即用

即开的 DAQ 主页，展示最关注的内容。12路可输入可输出的模式配置，以配置文件方式自动保存和同步。

还有令人满意的丝滑示波器。

以及采集卡本体(原型)

技术栈

• 采集卡本体：经典嵌入式C
• 通信后端：python-flask
• 显示前端：原生html+js，完全由 chatGPT 生成

这算构思已久的现代设备与 SoftPanel 的技术栈，这个实验性项目终于整体完成了，在高速实时示波的情况下验证可行性。

由于我完全不懂前端，所以与狗屁通 (GPT的爱称) 沟通了三个小时：最终做成大概什么样子；到底是原生 html 还是使用框架；这整个项目技术上的可行性。

其中大部分我都有一定预期，主要是让狗屁通完全理解我的技术水平，不要使用超出我认知的技术栈，或者实现我无法确定实现的功能。

使用的 vscode github pro——GPT5-Codex，试用下来比较符合个人习惯。

初步落地，狗屁通在前端上实在”太强了“相比我的话，大部分前端内容都能在两到三次迭代下完成需求，虽然这个项目的需求相对很简单，但是我依然觉得是了不起的能力。特别是”将示波器做的不卡“这件事上，他能在五次我的反馈和更新下做到当前示波器的样子，我是搞不定的，没错，这个示波器页我太满意了！

但是反观啊反观，嵌入式C以及后端部分，狗屁通就有些不尽人意了。

在C语言侧高速-低速混合处理，无论让他迭代多少次我都不太满意，而且有bug，最终还是手动编写。他总是喜欢在高速侧过度包装，对于不可模块化的代码模块化，以致抽象包含了无意义逻辑，高速代码是尽可能不要有无意义逻辑的，否则后续会带来维护和迭代问题。

在后端部分，他总是有些处理不好进程间的异步问题，导致实际物理USB的数据挤压最终丢包，这部分狗屁通也是无论如何都改不好。

总的来说就是狗屁通无法正确处理代码与实际物理层的相互掣肘问题，在网络层有良好基础建设的情况下，可以做到高带宽猛IO没有问题。但是经常不考虑实际上没有良好的基础建设，处理硬件或者驱动本身的限制上始终无法让人满意。

主要收获

证明了在超越200kB/s的数据流下，python后端依然能够完成良好解析+部分计算，浏览器界面依然可以丝滑运行不卡。

这个速率基本足够目前所有的单机应用了。

应该不是极限吧，但是懒得测试了，足够应用就行。

仍然存在的问题

• USB采用CDC_ACM枚举，固然可以免驱，但依然带来了少量的信道损失，以及难以大通道直接通信，我认为再提高采样率就会大量丢包了。
• 后端的通信流解析以线程形式寄生在socketIO进程中，应该以独立进程形式管理每一个通信流，这样后续才可正确支持USB外的其他通信接口(例如组网单一监控的可能)。
• 前端使用狗屁通生成的单html文件，可以说是天书鬼都看不懂，后续加功能时重构让狗屁通给我弄个看得懂的框架吧。

这些是技术上，如果是功能上...emm如果真有人用再说吧。