写了个具有扩展功能的串口软件,大家帮忙提提建议
本帖最后由 lcofjp 于 2017-10-25 20:12 编辑这个软件是开源的,GitHub地址是:https://github.com/lcofjp/visual-serial,欢迎各位坛友提出宝贵意见,能参与进来更是求之不得。这个软件我写了20多天,基本架子终于搭起来了,于今日发布了v0.0.1版本。我暂时给他命名为visual-serial。
visual-serial基于electron、 node-serialport等开源软件项目进行搭建。 electron是一个使用HTML、CSS和JavaScript/Node.js开发跨平台应用的框架,因此,visual-serial理论上会支持windows(>=window7版本)、macOS以及部分Linux系统,重要的事需要强调一遍: 不支持windows XP系统,因为electron已经放弃了对这款古老系统的支持。
为什么选择HTML、CSS和JavaScript开发
1. HTML开发界面简单明了,CSS控制样式功能强大
2. JavaScript是脚本语言,易于扩展,不需要编译,人人都可以根据自己的需求修改或者增加功能(JavaScript有多难?肯定没有C++难!)
visual-serial的诞生受express和函数式编程的影响,把中间件和数据流的概念应用于串口数据流处理, 因此便有了下面的框图:
图1. visual-serial的构思图
图2. visual-serial主界面
中间件及其分类:
中间件的本质就是一个函数,数据以参数的形式传入函数,函数对数据进行预处理和加工,然后传递给下一个中间件进行处理,其形式如:
function entry(buf, serial, next) {
// 对buf进行处理
// 传递给下一个中间件的buf可以是一个新生成的buf,也可以把输入的buf原封不动传给下一级
next(buf, serial);
}
在串口通讯应用中,串口数据往往具有一定的格式和晦涩难懂的二进制数据,调试起来会比较麻烦,不过有了中间件做翻译的话,一切问题将迎刃而解。 根据应用,中间件大概分为三类:
1. midddleware:
通用中间件,对数据进行转换,处理
2. protocol:
本质上与通用中间件没什么区别,主要是用来处理数据帧的封装,其包含两个方法:encode和decode,在发送数据的时候,调用encode对数据进行打包,例如对数据进行转义,加入校验等功能, 在接收数据的时候调用decode,功能与encode相对。
3. widget:
窗口部件,用来扩展UI界面完成特定交互以及数据可视化的呈现
中间件的数量没有限制,可以一个没有,也可以有多个,根据中间件插入的位置,可以分为三类:
[*]前置中间件
[*]后置中间件
[*]发送中间件
这个分类与功能无关,只是用来设定其所处的位置。 中间件的位置很重要,所有中间件最终组成链式调用,前一个中间件对数据进行处理后,会传给下一个中间件,正如图1所示。
中间件示例介绍
介绍中间件,最直观的方法当然还是举例说明,下面的几个中间件是visual-serial附带的几个中间件,附带这几个中间件并不是说它常用和通用,仅是作为用户自己编写中间件的参考。
FF-protocol
假设有某数据格式规定:数据帧以0xFF开头、0xFF结尾,数据中出现的FF转义为FE 01,FE转义为FE 00,数据末尾增加异或校验和。 decode方法完成的工作包括:检测起始的FF字节,然后开始接收数据并进行转义和计算校验和,直到接收到尾部的FF,此时如果校验和正确,则把数据传给下一个中间件。 encode方法就是对数据增加头尾FF、转义和加入校验和,然后传给下一个中间件。示例:
56 A2 D3 91==encode==>FF 56 A2 D3 91 B6 FF
FF 56 A2 D3 91 B6 FF==decode==>56 A2 D3 91
timeout
如果数据帧没有具体的格式,无法判断数据的头尾,可以用超时时间来粗略判断帧的结束。如果等待设定的毫秒数内未再收到数据,则把已经收到的数据传给下一个中间件。 注意:计算机的计时并不准确,尤其是计算机任务繁重的时候,因此选择这个中间件是个下策。
savetofile
把经过这个中间件的数据保存到文件中,并继续传递数据至下一个中间件。
characterEncoding
完成字符串编码的转换,支持多种编码,如UTF8,UTF16,GB18030,因此数据发送和接收可以支持各种字符编码。 软件默认的接收和发送采用UTF8编码,UTF8兼容ASCII,如果数据中包含ASCII之外的字符,则需要注意编码转换问题。
发送:(因为论坛不支持这些字符,导致这些字符及其后面的内容不能显示,现在删除)
以上这些中间件都仅仅是一个js文件,代码都在100行之内,位置在app/middleware下面
drawgraph
这是一个窗口扩展,可将数据按特定类型提取,并画出变化曲线。其中BE为设置大端模式,min和max设置绘制曲线时的最小和最大取值范围,不设置为自适应范围。
图3. drawgraph显示单片机传过来的三轴加速度传感器数据
widget是app/middleware中的一个文件夹,其中包括html、css和JavaScript文件,html文件是必须的。
其他功能介绍
数据显示
数据显示,也就是图1中的display部分,用来做基本的数据显示,其有4种显示方式
RAW-HEX: 把接收到的数据以十六进制的形式显示
RAW-STRING: 把接收的数据作为字符串显示
ITEM-HEX: 以十六进制条目的形式显示数据,如果前面有protocol中间件或者timeout,则每帧数据显示为一条。
ITEM-STRING:以条目的形式显示字符串
还有一个NOT-DISPLAY选项,在数据显示没有重要意义的时候,可以不予显示以提高软件性能。
数据发送
数据发送主要有字符串和十六进制发送两种方式。这些功能比较基础没有可介绍的,值得一提的是,以十六进制发送的时候,可支持多种十六进制格式以及宽松的判断,例如:
{0x45, 0x56, 0x89, 0xAB, 0xF2} => 45 56 89 AB F2
08H 58H 9AH BCH => 08 58 9A BC
0x120x560x8a 9F7C62 3 B 5 => 12 56 8A 9F 7C 62 03 0B 05
loopback
环回功能,数据不通过串口发送出去,而是传递给接收部分。便于调试。
------------------------------------------------------------------------------------------------------------------------
编辑原因:因为帖子内容包含表情文字,导致后面的内容被吃掉,把表情文字删除,补充后面内容。 很牛,我搞不懂
是不是可以在LINUX下用 好东西 ztrx 发表于 2017-10-25 20:15
是不是可以在LINUX下用
部分linux系统是可以的,一会我试试看,由于时间关系,我还没在linux上试,如果可以我也打个包 太强了
这个很实用啊,拓展性很强
去看看 不错,是个很好的项目,这就是各个主流tcp,http server 框架的设计思路。 其实楼主device 后面的可以作为一个独立数据流处理和显示模块。这个模块和device中间加封装一层驱动标准接口。
就可以适应 各种设备调试,串口,以太网,蓝牙,等待。 semonpic 发表于 2017-10-25 20:54
不错,是个很好的项目,这就是各个主流tcp,http server 框架的设计思路。 其实楼主device 后面的可以作为 ...
嗯,是的,以后有往这方面发展的意图 感觉很强大,支持一下 r看起来非常的强大啊 扩展串口,mark一把,:-)。 我理解是像音效插件一样,很棒,也就是可以翻译成中文来看也没问题{:hug:} 能歪一下楼请教楼主一个问题吗,当然有其他人也帮回答一下,就是,好多年来,都发现用串口调试助手一类的工具时候,不是有一个间隔多少ms发送的那个吗,发现太不准确,最好示波器发现只要是时间在20ms以内样子,间隔基本上都是15.625ms左右,也就是说设置间隔1ms实际上却是15.625ms(这里肯定不是因为发送数据时间太长,这点不用质疑了),试了很多电脑,高档配置的以及低档配置的几乎都是这样,当然操作系统测试的少一点,以xp为主,win 2000,win7都也试过几台,大致是这个意思,有没有朋友给科普科普 1a2b3c 发表于 2017-10-25 22:13
能歪一下楼请教楼主一个问题吗,当然有其他人也帮回答一下,就是,好多年来,都发现用串口调试助手一类的工 ...
我就知道windows系统不是实时系统,所有定时类的都不会太准,而且每个任务是有时间片的,程序不是随时都能执行,具体细节我就一点不清楚了,为啥是16ms多 ztrx 发表于 2017-10-25 20:15
是不是可以在LINUX下用
Linux 64位版我已经传到网盘了,在楼主位GitHub页面有下载地址。
我用的Ubuntu 16.04测试可用,不过要用系统权限运行,要不然没有权限打不开串口,具体原因我不清楚。
electron官方验证能在下列系统中使用:
[*]Ubuntu 12.04 and later
[*]Fedora 21
[*]Debian 8
帮顶起来 不错的设计,特意上 github 给点了个 star {:victory:} memstone 发表于 2017-10-26 00:01
不错的设计,特意上 github 给点了个 star
多谢支持,有精力的话可以参与进来,共同开发 很久之前我也想做一个类似的,可以随便解析特定格式的数据,也可以选择曲线显示!也许能力不太够,或者没时间,一直
没有做,楼主这个好像做的很好,佩服! 框架很好,可以适应不同应用,有空学习学习 这个开源项目和ScriptCommunicator有什么不同? 如果能实现发送和接收都脚本化就很有价值。 好棒,支持一下 高大上,帮顶 1a2b3c 发表于 2017-10-25 22:13
能歪一下楼请教楼主一个问题吗,当然有其他人也帮回答一下,就是,好多年来,都发现用串口调试助手一类的工 ...
因为windows的普通定时器的精度是15ms,即使用sleep(0),一样是15ms,这类软件一般调用的是普通定时器api,不会用到内核定时器或者多媒体定时器,大概是这个原因吧 第一次听说 electron,关注一下,不明觉厉。
谢谢楼主! 本帖最后由 lcofjp 于 2017-10-26 11:06 编辑
ro321 发表于 2017-10-26 08:58
这个开源项目和ScriptCommunicator有什么不同? 如果能实现发送和接收都脚本化就很有价值。 ...
我以前寻找可以扩展的,或者功能比较强大的串口助手,但是没找到,但是不一定代表不存在,你说的ScriptCommunicator我还是第一次听说,功能确实强大,不过我觉得这个实现过于复杂了,不太适合电工日常使用。
脚本收发通过中间件来做是可以实现的,脚本发送的功能已在规划中。 有个 串口猎人 软件,里面有些功能也挺不错的,可以参考一下 loveavr999 发表于 2017-10-26 10:36
因为windows的普通定时器的精度是15ms,即使用sleep(0),一样是15ms,这类软件一般调用的是普通定时器a ...
那这样的话,定时一秒钟也是极为不准的了?我一直就认为和电脑没有什么关系,应该是操作系统底层提供的定时函数本身就不对,如果你这样解释的话那倒是完全对的了,实际ms定时器步进是15625us。
另外就是,usleep()也是不准确的吗?如果有这个函数的话,微秒级定时 关注一下,谢谢楼主! 1a2b3c 发表于 2017-10-26 13:14
那这样的话,定时一秒钟也是极为不准的了?我一直就认为和电脑没有什么关系,应该是操作系统底层提供的定 ...
WINDOWS的时基还是DOS时的18.2mS,一直没有变化,也就是一般编程使用的话,时间是以18.2mS的间隔计时或产生延时的, 除非采用一些多媒体或其它定时器操作,才有更高的分辨率。 cocom 发表于 2017-11-11 09:16
WINDOWS的时基还是DOS时的18.2mS,一直没有变化,也就是一般编程使用的话,时间是以18.2mS的间隔计时或产 ...
哦,原来的确是这么个由来。
但是这个18.2ms感觉有点不对呢,我个人认为是15.625ms这样恰好是1秒钟64分频的结果,这也非常符合传统的一些方式,示波器测试的结果也非常吻合,18.2ms就感觉不知道怎么得到的了,哈哈不过这个是个题外话另当别论了。
但你说的多媒体这类的非常重要,是不是底层上面使用了另外的一个时机系统的概念?还望赐教,虽然我不懂这些,但是应该能够在别人做上位机软件时间给予协助或者提示
页:
[1]