触摸屏AI编程260525工作记录

触摸屏AI编程

  继续进行触摸屏编程工作，查找之前的记录，触摸屏断电重启之后丢失了我们编程的界面，请修复

Jarvis

我先按之前的记忆从 I:\AI 找基线/部署记录，再检查触摸屏当前文件；修复前会先把工作内容存到今天日期目录。
问题找到了：程序和 Web 文件还在，MD5 也对，但开机脚本 /etc/init.d/S99mcgs_app 仍然启动的是出厂 demo_app，所以断电重启后界面回到出厂程序。现在我备份启动脚本到 I:\AI，然后改成开机启动 /root/start_iba_pda.sh 并立即拉起我们的程序。
刚才脚本传上去了但 BusyBox 对 Windows CRLF 换行解析出错，我马上换成 Linux LF 格式重传，并把 stop 也改成会杀掉 demo_app。
还有一个关键点：设备根分区是 overlay，/etc/init.d 修改后当前生效，但我需要确认它是否能跨下一次断电保存；否则只是“临时修好”。我继续查启动持久化位置，避免重启又丢。
我现在做一次软件重启验证。目的就是确认不是“当前进程修好了”，而是断电/重启后也会自动进入我们的界面。
已修复。
原因不是我们编的程序丢了，而是开机脚本还在启动出厂程序：
/root/iba_pda 还在，MD5 正确：c847ef51075cb2f86db0f75b05805cb5
/VFD/web/index.html 还在，MD5 正确：d64173a7d796c910ae543a40cca0a051
但 /etc/init.d/S99mcgs_app 原来写死启动 demo_app，所以断电重启后自动回到出厂界面。
我已做的修复：
备份原启动脚本和页面文件到本地：
I:\AI\work\2026-05-25\touchscreen_boot_repair
修改触摸屏开机脚本：
/etc/init.d/S99mcgs_app
现在开机启动：
/root/start_iba_pda.sh
并会先停止 demo_app，再启动我们的：
/root/iba_pda -qws -display LinuxFb:/dev/fb0 -mouse Tslib:/dev/input/event0 -nomousecursor
已立即拉起新程序，当前进程确认是：
/root/iba_pda ...
已执行一次软件重启 reboot 验证，重启后仍自动进入我们的程序，demo_app 没有再运行。
修复记录已保存：
I:\AI\work\2026-05-25\touchscreen_boot_repair\summary.md
现在断电/重启后应该不会再丢我们编程的界面。
这条和上一条是同一个问题，我已经处理完成了：开机脚本原来仍启动出厂 demo_app，所以断电重启后回到出厂界面。
现在已改为开机启动我们的 /root/iba_pda，并做过一次 reboot 验证：
重启后运行的是 /root/iba_pda
demo_app 未运行
Web 页面文件 /VFD/web/index.html 也还在
修复记录已保存到：I:\AI\work\2026-05-25\touchscreen_boot_repair\summary.md
所以现在断电/重启后应该会保留我们编程的界面。

触摸屏AI编程

故障log记录不能正常运行，请检查

Jarvis

我来查故障 log 链路：先看设备当前进程、配置、已有 fault_logs、运行日志，再对照 5/23 的记录找差异。
初查结果：设备现在没有任何故障文件，fault_logs 目录是空的；配置和程序都在，但需要确认串口是否还在收帧、触发条件是否还匹配。接下来我直接看源码里的故障触发逻辑和设备串口状态。
现在设备上没有 /dev/ttyACM* 或 /dev/ttyUSB*，所以程序根本收不到串口帧，故障记录自然不会触发。我要继续查是 USB/串口设备没起来，还是启动顺序/驱动问题。
关键原因基本明确了：当前程序只扫描 /dev/ttyACM*、/dev/ttyUSB*，但触摸屏内核启动信息显示实际接收串口是 /dev/ttyS2（rec device is /dev/ttyS2）。所以重启后程序没打开真实串口，故障 log 不可能生成。现在我从 1650 基线分支改源码，把串口候选加入 /dev/ttyS2，更新版本号后编译部署。
编译机连接参数写法不兼容，我查一下之前记录里的 hostkey 再继续。
编译虚拟机现在连不上。我先不等它，直接对当前 1650 基线二进制做安全补丁：只替换串口候选字符串和界面版本号，不改其它逻辑；这样能尽快恢复故障 log。
已恢复打开真实接收串口 /dev/ttyS2。现在程序能开串口了，但还要看是否持续收到有效帧、故障触发有没有进来；我等几十秒检查调试日志和长期记录是否增长。
串口已能打开，但 35 秒内没有收到一帧有效数据：调试日志只有 open serial /dev/ttyS2，没有 frame #...。这说明现在问题从“没开串口”变成“串口没有数据/波特率或端口不对/外部设备没发”。我继续做低风险探测：查串口配置代码和设备节点计数。
我发现 /dev/ttyACM0 现在已经出现了，之前那版程序启动太早时没等到它；我刚才把 /dev/ttyS2 放到首选后，虽然能打开串口，但这个口没有数据。现在改为更稳妥的策略：优先打开 /dev/ttyACM0，同时把开机启动脚本延迟几秒，让 USB 串口先枚举出来。
现在已恢复串口收帧，长期记录也开始写新文件了。我再做一次重启验证，确认断电/重启后也会等待 USB 串口枚举并自动打开 /dev/ttyACM0。
已检查并修复故障 log。
问题原因：
早上修复开机界面后，程序启动太早，USB ACM 串口 /dev/ttyACM0 还没枚举出来，iba_pda 启动时扫描不到真实数据串口，所以没有接收帧，也就不会生成故障 log。
我做了这些处理：
检查发现一开始：
/VFD/vfd_logs/fault_logs 为空
/tmp/iba_pda_vfd_debug.log 只有 serial thread start
没有 read、没有 frame
说明程序没收到数据
试过 /dev/ttyS2，能打开但没有数据；实际有效数据口仍是 /dev/ttyACM0。
修复启动脚本：
/root/start_iba_pda.sh
增加启动延时：
sleep 8
让 USB ACM 串口先枚举完成，再启动 /root/iba_pda。
更新程序显示版本号为：
20260525_0830
已重新部署并执行 reboot 验证。
验证结果：
重启后 /root/iba_pda 自动启动
/dev/ttyACM0 存在
调试日志持续收到有效帧：
frame #... ok=1
长期记录已生成新文件：
/VFD/vfd_logs/run_logs/log_run_260525-082453.csv
故障记录也已生成：
/VFD/vfd_logs/fault_logs/260525-082428.dat
故障文件大小：
438582 字节
当前部署文件：
/root/iba_pda MD5：d586602a061e775585aedf6a73749412
/root/start_iba_pda.sh MD5：d533a40a29b3c9e699406d5e14e58480
/etc/init.d/S99mcgs_app MD5：7d5dc366e411d5564d531f910d34d67c
修复记录保存到了：
I:\AI\work\2026-05-25\fault_log_acm_bootdelay_fix_20260525_0830\summary.md
现在故障 log 写入链路已经恢复。

触摸屏AI编程

现在记录功能是正常的，请保存为基线版本

Jarvis

收到。我把当前正常记录功能版本保存为新的本地基线，只在 I:\AI 保存，不往触摸屏留额外备份。
已保存为新的基线版本。
基线路径：
I:\AI\baseline\touchscreen_recorder_iba_pda_20260525_0830_recording_ok
已保存内容包括：
/root/iba_pda
/root/start_iba_pda.sh
/etc/init.d/S99mcgs_app
/VFD/web/index.html
/VFD/config/recorder_settings.ini
/VFD/config/recording.conf
当前设备验证日志
MD5 校验文件
BASELINE.md 说明文件
当前基线关键状态：
记录功能正常
/dev/ttyACM0 数据接收正常
长期记录正常生成
故障 DAT 正常生成
开机后等待 8 秒再启动程序，避免 USB 串口未枚举导致记录失效
版本号：20260525_0830
同时已更新：
I:\AI\baseline\LATEST_TOUCHSCREEN_RECORDER_BASELINE.txt
后续如果继续修改，会从这个基线分支开始。

触摸屏AI编程

在滚动条上加入串口状态诊断，显示串口正常与否的信息

Jarvis

我从刚保存的基线分支继续，先确认当前底部滚动条文字位置，然后加入更直观的“串口正常/等待/异常、帧数、校验错误、丢帧”等诊断信息。
当前滚动条里已有很短的 SER OK/F/CE/LF，但不够直观。我会改成更明确的诊断文字：串口正常/等待/异常、帧数、校验错误、丢帧、故障次数，并更新版本号后部署。先尝试用编译虚拟机；如果虚拟机仍连不上，就先做可逆的二进制文字补丁。
编译虚拟机现在 ping 不通，我先采用可逆的二进制文字补丁方式改当前正常基线：把滚动条里的 SER OK F... CE... LF... 改成更直观的 SER OK Frames... Err... Lost...，同时版本号更新，部署后验证。
已加入串口状态诊断并部署。
现在底部滚动条里的串口信息从原来的短格式：
SER OK F... CE... LF...
改成更直观的：
SER OK Frames... Err... Lost...
含义：
SER OK：串口已打开，状态正常
Frames：已解析的有效帧数量
Err：校验错误计数
Lost：丢帧计数
同时版本号已更新为：
20260525_0835
已部署到触摸屏：
/root/iba_pda
MD5：3db03ce99cd8b5b1f81bbc254dd8e089
验证结果：
程序正常运行
串口持续收到有效帧：frame #... ok=1
记录功能没有被破坏
启动脚本和开机脚本保持原状态
记录保存到：
I:\AI\work\2026-05-25\scroll_serial_diag_20260525_0835\summary.md
注意：QT4 编译虚拟机 192.168.25.128 当前连不上，所以这次先用了可逆的二进制字符串补丁完成部署。后续虚拟机恢复后，建议再从源码正式重编一版。

触摸屏AI编程

虚拟机现在可以连通了，现在显示lost丢包与Frames数字相差不大，请检查

Jarvis

我先检查这个 Lost 数字的来源。看起来很像程序把固定不变的 seq 字段当作递增序号了，导致每帧都误判丢包；我会用现在已连通的虚拟机从源码正式修复并重编。
我这边到 192.168.25.128 仍然超时，可能虚拟机 IP 变了或桥接网络刚恢复。我先查局域网和 PuTTY 连接；同时这个丢包问题的原因已经能从日志判断：seq 一直是固定值 41157，程序却按“每帧递增 1”来判断，所以几乎每帧都被误算为 Lost。
虚拟机已连通。现在我从 0830 正常基线源码正式改：滚动条保留诊断，但不再用这个固定 seq 误判丢包；只有真正可判断时才累计 Lost。版本号更新后编译部署。
已检查并修复。
原因确认了：不是实际丢包，而是程序误判。
运行日志里有效帧一直正常，例如：
frame #... ok=1 ... seq=41157 page=123 type=0
但原程序把 words[65] 当成“每帧递增的序号”来判断丢包。现场实际这个值长期固定为 41157，不是递增序号，所以程序几乎每帧都认为丢了一包，导致 Lost 和 Frames 差不多。
我已做的修改：
保留滚动条诊断：
SER OK Frames... Err... Lost...
移除基于固定 seq=41157 的错误丢包判断
在没确认真正协议序号字段之前，Lost 不再误递增
版本号更新为：20260525_0840
已用虚拟机正式重新编译，不再是二进制补丁
已部署到触摸屏：
/root/iba_pda
MD5：d64938ab8f347d9ac7023078021a0923
验证结果：
程序正常启动
串口持续接收有效帧
frame #... ok=1 正常
启动脚本和开机脚本未改动
修复记录保存到：
I:\AI\work\2026-05-25\serial_lost_fix_20260525_0840\summary.md
现在滚动条上的 Lost 应该不会再跟着 Frames 一起快速增长。