新增优化使用体验需求

[jiezhuo]

比j-scope好用多了，为了更高的速度特地买了jlinkpro，使用过程中存在体验不佳的情况，希望未来可以更新，优先级如下

1. 符号搜索/过滤功能：elf的符号太多了，每次需要找很久，特别是通过文档知道变量名不知道位置的情况
2. 观测列表排序功能
3. 观测列表组功能：符号多了之后相当于给很多符号分类，方便切换任务
4. 示波图多图模式：图的数量和布局可设置

期待更新，谢谢

[SummerFalls]

1. 目前由于 ELF 解析引擎速度不佳，所以解析并不是载入 ELF 后就全部解析，而是当鼠标单击树节点后才触发解析节点内的成员，所以这也带来了一个问题：无法做符号搜索、过滤的功能，所以需要后续改进 ELF 解析引擎，增快解析速度后才能实现符号搜索
2. 观测列表排序功能已经在 Todo 清单中，只是看似简单的排序涉及到很多改动，所以实现不会很快
3. 观测列表组功能是个很好的想法，或许不久的将来我会加入（看实现难度）
4. 多图模式目前只能固定两行三列总共6个，后续会考虑开放自定义子图数量和布局

新的 v0.1.0.0 版本已经上线，新增 HSS_DataVisualizer Pro 专业版，可以尝鲜下，加入了 Ribbon 菜单、Advanced Docking System 自由停靠系统

[SummerFalls]

@jiezhuo 下一个版本将带来革命性的体验提升和性能优化：

1. AXF/ELF 符号文件的解析引擎重构已经完成了，解析速度将有极大提升
2. 得益于符号文件解析引擎的性能提升，现在变量选择页面的展开模式不再是以前的懒加载，而是全量加载，同时得益于此，变量搜索/筛选功能也加上了，现在搜索变量、添加变量、在线改值将会变得很丝滑
3. 优化了采样链路、内存策略、数据结构，使得长时间采样的稳定性、采样速率上限获得了很大提升，解决了多个潜在的崩溃问题，比如内存 OOM 导致崩溃的问题
4. RTT 模式下：MCU 高频发包时，对于低端 JLink 的丢包情况进行了特殊处理（这个处理 JScope 竟然没有做），比如 JLink OB、JLink V9 等低端 JLink，让MCU直接在主循环按最高频率写RTT缓冲，会有很多封包出错（JLink OB 测试了下 RTT 极限速度好像就是在 134 KB/s 不过这个速度已经比较容易产生错误数据），所谓特殊处理，其实指的就是如果发生丢字节的情况，为了防止数据错乱，失去对齐导致采样值出现极大值、极小值的问题，目前的策略是将丢了字节的那一包整包丢弃，如下图所示，被丢弃的数据点会被填充为0。特殊处理前后对比如下：

丢包发生时，HSS_DataVisualizer/UNI_DataVisualizer 针对丢包进行特殊处理前、后的示波截图：

特殊处理前：

特殊处理后：

丢包发生时，JScope 的示波图截图：

可以看到很多极大值、极小值充斥了整个波形界面

[jiezhuo]

@SummerFalls 这么快，期待体验！特别是对丢包的特殊处理真的很棒，因为丢包后的波形太有迷惑性了。

顺带问问一些问题

1. 全量加载后的内容是否有持久化，以便在软件或电脑重启后可以快速恢复工作状态
2. 关于另外一个issues提到的无法索引二级指针的问题新的解析引擎是否能够覆盖？
   我目前的解决方法是用JScope解析elf（似乎它没有这个问题），拿到那个变量的名称和地址，然后在HSS里面随便添加一个变量，再手动改为JScope获得的信息。并且后续在HSS中是可以手动更新的（那么问题又来了为什么能更新却不能索引，有点奇怪）
3. 未来考虑开源或者旧版本部分开源吗，想加快一下开发进度和自己搞点小工具玩玩，非常感谢你的好用软件

[SummerFalls]

1. 不是很懂这个“全量加载持久化”的意思，软件重启后，如果你要采样前添加变量、采样时实时修改变量值，那你肯定是需要执行一次“刷新（解析符号文件）”，不过新版本的解析速度对于大部分嵌入式工程几乎是 1秒 以内便可完成解析，另外就是如果你的工程代码有变化、新增、删除或修改了全局变量，那肯定也是要重新执行一次“刷新（解析符号文件）”的。
2. 指针指向的地址是运行时确定的而不是编译时确定，所以不管是二级指针还是一级指针，解析 ELF 是解析不到指针指向的地址的，你只能解析到指针自身的地址，这是在编译时就确定的，我看了下JScope也是一样的情况。 二级指针数据无法解析 #2 的描述有一个错误，就是 htim2 实际应该是个实际的结构体类型的变量而非指针，里面的 instance 则是指向结构体类型的指针，所以先输入 htim2.instance 可以读到这个指针指向的对象的地址，之后再根据这个地址进行相应的偏移就能得到里面的成员变量的地址了（也就是 htim2.instance.cnt 的地址）

这里引申出 2 个问题：
Q1：那为什么 GDB 或 Keil 的 Watch 界面能根据指针读取到指向的变量的值呢？
A1：因为 GDB / Keil 在进入调试会话后，是通过读取被调试程序的内存来知道指针指向的地址的，而不是从 ELF 中推导出来的，也就是通过读取这个指针所处的地址上面存储的数据（这个数据就是指向的那个变量的地址）来得到所指向的变量的地址并通过那个地址读取变量值的，而 #2 中所描述的步骤其实就是 GDB / Keil 自动干的活，由他来手动干一遍，这就又引申出下一个问题 Q2：

Q2：为什么 HSS_DataVisualizer / UNI_DataVisualizer 没法像 GDB / Keil 那样自动解析指针指向的变量呢？
A2：因为 GDB / Keil 只是采取的轮询的方式对变量的最新结果进行显示，并不需要存储整个调试会话周期内观测变量的所有采样点数据，所以它们可以调试时添加变量、调试时通过指针反推实际的变量；而 HSS_DataVisualizer / UNI_DataVisualizer 是整个调试会话周期内都要采样并存储采样点数据，所以需要采样的变量以及对应的地址必须在开始采样前（MCU程序运行前）就确定下来，所以就没办法像 GDB / Keil 那样在调试会话期间去添加运行时才能确定地址的变量

3. 由于用到了一些商业库不允许公开源代码，所以目前没有开源计划。不过如果你想搞点小工具玩玩，我可以推荐你看下这两个项目：
   MisakaMikoto128/j-link-rtt-viewer-pyqt
   Square/pylink

4. 另外其实 JScope 的 ELF 解析也存在一些问题，比如它对多维数组解析处理，会把多维数组解析成一维数组：

[SummerFalls]

@jiezhuo 新版本 v1.0.0.0 已经发布了