https://yafengabc.github.io/tags/%E4%B8%B2%E5%8F%A3/index.html Hugo zh-cn Sat, 19 Sep 2026 16:30:07 +0800 https://yafengabc.github.io/cnblogs/p18581812/index.html Mon, 02 Dec 2024 14:13:00 +0800 https://yafengabc.github.io/cnblogs/p18581812/index.html 昨天测试串口助手，发现高速数据流对串口数据压力很大，经测试，压力主要来自windows的组件的接收字串并渲染的速度。 测试代码如下： byte result; while(true) { while(serial.IsOpen && serial.BytesToRead>=0) { byte_to_read=serial.BytesToRead; result = (byte)serial.ReadByte(); rev_bytes_counter++; rev_frame_counter=rev_bytes_counter/15; } System.Threading.Thread.Sleep(1); } } 现在是15个字节一个帧，结果如下： 现在接收速率是47KByte/s，3167帧/s，传输速率是427743bps，做到了实时接收，如果加一句显示的代码： while(serial.IsOpen && serial.BytesToRead>=0) { byte_to_read=serial.BytesToRead; result = (byte)serial.ReadByte(); rev_bytes_counter++; textBox1.AppendText(result.ToString("X2")+" "); rev_frame_counter=rev_bytes_counter/15; } 速度立刻就炸了，每秒钟只能显示32个帧，然后大量的数据呆在串口缓冲区出不来，最后就boom…… 后来我想，应该就是windows的textbox刷新太慢了，我一次写入大量数据，不就能缓解这个问题了？ 改成如下代码： byte[] toview = new byte[256]; while(true) { while(serial.IsOpen && serial.BytesToRead>=256) { byte_to_read=serial.BytesToRead; serial.Read(toview,0,256); textBox1.AppendText(BitConverter.ToString(toview).Replace("-"," ")); rev_bytes_counter+=256; rev_frame_counter=rev_bytes_counter/15; } 也就是一次往textbox里边扔256个字节，测试如下： https://yafengabc.github.io/cnblogs/p18580397/index.html Sun, 01 Dec 2024 21:36:00 +0800 https://yafengabc.github.io/cnblogs/p18580397/index.html 书接上回，我不是搞了两块INA226的小板子么，下位机调通了，当然下一步就是上位机搞起，祭出C#+winforms三下五除二……如下图： 好吧，丑是丑了点，winforms默认就是这B样。不就是玩玩么，玩的就是多快好省……巴拉巴拉…… 回正题，我们先算了算，INA226最快的转换时间是140us，需要读2个数据，就是电压、电流。也就是最快140+140=280us，加上处理，发送的时间，算他300us吧，也就是1ms的时间能够采集3+次，那一秒就得收3000+个数据。 简单算一下：32*3000=96000也就是96K，常用串口的115200波特率勉强够用。另外还有USB通讯，现在的单片机一般支持USB2.0全速通讯，也就是12Mbps/s。串口的话一般CH340也能达到1M左右，基本是毫无压力。基于简单通用考虑 当然是选串口了，另外这些单片机带的VCP是很快的，起码有3M/s的速度。 问题出在windows上。众所周知，windows/linux这些OS都不是实时的。一个时间片通常是1ms，但是这不是固定的，有时也会10几ms不等，所以windows下接收数据需要缓冲区也就是高速设备发来的数据，我windows底层先收着，存在一个区域。 等你程序来了一次性拿走就行了，所以即使windows能保证精确的1ms让你读一次串口，1毫秒也能读到3组数据。何况他根本保证不了，所以每次从串口读到的都是一堆数据并且因为发送的不是一个字节啊，还会出现读一半的情况。比如发送的一帧长度是20字节，你读上来30字节，前20字节是一完整的数据帧，后边10个字节是半个数据帧，还要跟后续读取的10个字节组成完整的数据帧。所以得想办法解决粘包的问题。还有一个就是时间问题，假设一次读到10个数据帧，这10个数据帧是同一个时间读到的，就不知道每个数据产生的具体时间了。 先说说时间问题，前一阵子研究怎么给FNB58写一个客户端当时考虑过，FNB58是USBHID接口，这个接口最大的好处就是免驱，插上电脑就能用，并且如果早知道PID/VID的话可以写死在程序里，软件打开可以直接连接，不用选端口（串口就不行了，你插上他不一定是串口几了，需要自己选一下）USBHID的话是1ms一个64字节的数据帧，也就是500Kbps的样子，比串口慢，但是够用。他是1帧发送四组数据。平均10ms一个点，也就是大约40ms上报一个数据帧（其实我就是嫌它慢才会自己搞INA226）。因为当时参考了github上一个项目https://github.com/baryluk/fnirsi-usb-power-data-logger里边是这么处理的： 每次读到数据后，比如100ms读一次，读到了10个点，那么我把10个点平均分配到这100ms之内就可以了，其实这样的话慢速还行，因为windows的实时性能保证40ms读一个数据帧，基本时间误差比较小。但是速度上去后，时间偏移就会比较大，另外一个稍微理想的方案就是上传的数据自带时间戳，这样就比较好了，我无论一次读到多少数据，反正自带时间，稍微处理下就能当时间用。然后问题又来了：你单片机时钟准吗？你如何保证现在单片机的时间是UTC（或者localtime）时间？时间戳精度够用吗？MD越来越复杂了…… 其实windows（或者安卓等其他设备）的时钟也是靠一个晶振产生的，其实也是不准的，但是架不住他们用网络对时，只要有网，他会每隔一段时间从网上获取时间对一下时间，所以windows（或者安卓之类）的时间是比较准的。后来嘛，我发现我想的有点多……你晶振再不准，也不会一天差一个小时吧……也就是差几分钟的精度，我又不记录那么长时间的记录，真要计那么多数据，那一般也不会需要那么高的采样率了（因为我试过给数据记log，开几十秒能记几兆的数据，时间长的话还不得把硬盘塞满……）。再就是时间戳精度问题，因为数据采集时间时低于1ms的，所以需要精确到us，那么32位的时间戳多少时间溢出呢1.19小时……要是记录手机充电的话，还真不怎么够，好在最快140us才一个点，精确的到10us的话就能11.9小时，100us的话就是119小时。足够了（当然可以用64位的时间戳，那样时间就是天文数字了，用32位是为了节省点通讯带宽）。经过一番思考，决定把协议弄成这个样子： AA FF+XXXX XXXX（时间戳UINT）+XXXX XXXX（电压FLOAT）+ XXXX XXXX（电流FLOAT）+55，也就是15字节，其实还可以简化，比如包头只有AA，包尾也可以去掉，电压电流可以传16位的整型那样9字节就够了。之所以搞成这样，原因比较复杂，因为我一会儿想在单片机上标定电流，一会儿想在上位机上，所以频繁的改协议，后来想想干脆浮点数算了，先定下来再说。 至于字头为啥用了两个，这个说出来丢人，因为一开始吧为了解决粘包问题，我用了两个线程+一个队列，一个线程收，收到后扔到队列，一个线程解析协议从队列取值（网上这么教我的），后来发现，频繁的解包出错甚至在包头AA FF正确的时候，收到的电压电流乱跳，后来又加了个包尾，才能保证每次读到的数据都正确（但是通过记录失败的次数，每秒都有大量的错误次数）直到我意识到我用的队列是线程不安全的……开始是换了C#自带的ConcurrentQueue，错误立刻就降到了0，后来嫌CPU占用率高，想到虽然队列线程安全，但是肯定会在锁上竞争，把接收跟解包放到了一个线程，再到后来想到系统的串口缓冲区其实也是一个队列，所以就干脆把队列取消了……代码如下的样子： byte Dequeue; if (serial.IsOpen && serial.BytesToRead>0) {while(serial.BytesToRead>=15) { Dequeue=(byte)serial.ReadByte();; if (Dequeue==0xAA) { Dequeue=(byte)serial.ReadByte(); if (Dequeue==0xFF) { for(int i=0;i<=11;i++) { result[i]=(byte)serial.ReadByte(); } Dequeue=(byte)serial.ReadByte(); if (Dequeue==0x55) { timestamp = BitConverter.ToUInt32(result,0); voltage = BitConverter.ToSingle(result,4)*1.25/1000; current = BitConverter.ToSingle(result,8)*2.24/100; power = voltage*current; rev_frame_counter++; } else { err_frame_counter++; } } } } } 首先判断串口缓冲区是不是大于等于15个字节（因为协议是15字节），如果有足够的字节数，就先读一个字节，判断是不是帧头（0xAA），为啥用了俩字头呢，因为数据里也可能有0xAA这个数据啊，如果检测到0xAA就直接读剩下的14字节，最后发现不对就至少丢掉两个帧的数据，数据里AA FF这样的可能性就很小了，当然也可以AA BB，都无所谓，验证帧头正确然后读12个字节的数据，一个整数(时间戳)，两个浮点数（电压，电流），至于功率就是电压x电流，最后验证字尾是不是正确。 如果不对就丢掉，对的话就解码。 可以看到没有用队列（利用了串口缓冲区自己就是队列的特点）。 这样可以做到0出错，0丢包（当然排除串口传输出错的情况）。当然帧尾可以用校验和，或者CRC之类的代替固定值，那样能更大限度的保证数据的正确性。我没这么干主要是嫌CPU占用率高。 回到最开始的图，每秒只能接收1200帧数据，也就是每ms一个多一点的数据，是因为这个单片机我用的RP2040（以前从来没用过，只是看到这个板子能焊到我做的PCB上，就直接买了），硬件I2C针脚跟我的板子不兼容，所以只能用软件I2C协议 读的比较慢，得300多us才能读一个值，1200帧/秒已经是极限了。这时候我电脑CPU占用率10%左右。 https://yafengabc.github.io/cnblogs/p18573354/index.html Thu, 28 Nov 2024 00:05:00 +0800 https://yafengabc.github.io/cnblogs/p18573354/index.html 这几天买个两块INA226自己搞了个简易功率计（C表），如下图： 当时画板子就考虑兼容的板子多一点，支持Mini跟Super Mini类型的板子，一块搞了一个ESP32 C3（左），当时看RP2040-Zero便宜，就手贱又买了片RP2040-zero（右）。 一开始RP2040是刷Micropython用的，测试很成功，功率计能正常读到电压电流。后来嫌micropython慢，所以打算换到Arduino平台重写一下，这一换不打紧，踩了两个大坑。 我用的IDE是VScode+PlatformIO插件，支持巨量的板子，并且C++补全（Arduino）做的非常好，强烈吐血推荐： 看里边也有RP2040的支持，新建一个，从串口调起，下边代码： #include <Arduino.h> void setup() { // put your setup code here, to run once: Serial.begin(115200); } void loop() { // put your main code here, to run repeatedly: Serial.println("Hello im from RP2040"); sleep_ms(1000); } 这算是Arduino的Hello world了，没理由跑不起来…… 然后…… 编译成功，下载失败…… 看了看Arduino生成的文件，有uf2，那就好说了，按住BOOT->按住RESET->松开RESET->松开BOOT，U盘出来了。把uf2丢进去，板子重启了，这时候出现一个串口，用串口助手连上去，咦？啥都没有？ 这就抽象了……难道……USB串口不是默认的Serial，是Serial1或者Serial2？然后去翻官方文档： Arduino-Pico 核心使用 USB ACM-CDC 模型实现基于软件的串行 USB 端口，以支持各种各样的操作系统。 Serial是 USB 串行端口，虽然Serial.begin()允许指定波特率，但由于它是基于 USB 的，因此会忽略该速率。（还请注意，此 USBSerial端口负责在上传过程中重置 RP2040，遵循 Arduino 标准 1200bps = 重置为引导加载程序）。 RP2040 提供两个基于硬件的 UART，具有可配置引脚选择。 Serial1是UART0，且Serial2是UART1。 这这这这……没错啊，就是默认的Serial……