请教：怎么让上位机精确1ms串口发送一帧数据
本帖最后由 chinaboy25 于 2022-7-13 19:27 编辑请教：怎么让上位机精确1ms串口发送一帧数据？
现在Windows平台下 的 消息机制大概是15ms正负5ms左右触发一次，请问有方法做到1ms 触发一次，
之前听别人说 labwindows 好像可以做到。 不知道有办法能用C++写出来不？或者linux 下可以做到不？ 这需求，最好是另找一台单片机发送 楼上说的对
电脑干不了这事，哈哈， 本帖最后由 dukelec 于 2022-7-13 20:08 编辑
你要先說說你能接受的最壞情況下的時間誤差是多少
普通電腦用 rt-preempt 實時 linux 用戶空間做到 100us 以內誤差問題不大（最壞情況）
在 linux 內核空間或者其它實時 linux 方案可以更低 常规的Windows肯定不行,linux或者Windows RT这类带实时机制的可以 rclong 发表于 2022-7-13 20:07
常规的Windows肯定不行,linux或者Windows RT这类带实时机制的可以
(引用自5楼)
听说labwindows可以
dukelec 发表于 2022-7-13 20:06
你要先說說你能接受的最壞情況下的時間誤差是多少
普通電腦用 rt-preempt 實時 linux 用戶空間做到 100us...
(引用自4楼)
1ms就差不多了 要付出很大代价,cpu也基本废了 上位机精确1ms串口发送一帧数据？
单片机的事情了{:titter:} 做不到，看看有没有大神做到{:lol:} 不能，具体发出去是由驱动决定的，上位机1ms的延时都是不准的。。。真不如单片机 labview和TWinCat都可以，这些软件本质是把x86多核cpu的分一个核出来当实时内核用，或者说是当单片机用来保证实时性。 1. Windows 7 以上，采用高精度定时器，勉强可以做到1ms. 如果系统无过多任务的话。但相对单片机而言误差仍然非常大。
2. Linux 可以做的精度更高些。95%接近1ms
所以，真正的高精度 另外一个单片机发送，才是正解 媒体定时器可以1ms以下分辨率 楼主描述不清，误差需要控制到多少，比如1ms±100us 本帖最后由 feibagezib 于 2022-7-14 09:47 编辑
短时间，主动传输办法还是有的，自定义delay函数，自定义循环N次；
//定义延迟函数
public void delay(long delay_Time)
{
long stop_Value = 0;
long start_Value = 0;
long freq = 0;
long n = 0;
QueryPerformanceFrequency(ref freq);//获取CPU频率
long count = delay_Time * freq / 1000000; //这里写成1000000就是微秒，写成1000就是毫秒
QueryPerformanceCounter(ref start_Value); //获取初始前值
while (n < count)
{
QueryPerformanceCounter(ref stop_Value);//获取终止变量值
n = stop_Value - start_Value;
}
}
private void button23_Click(object sender, EventArgs e)
{
。。。。
for (dl_count = 0; dl_count < Change_i; dl_count++)
{
。。。
sentParam(0xfff, 0, 0, 0xf9);
delay(Change_tempA);
}
} Windows平台下可以用多媒体定时器，发送程序一定要精简 同问，1ms做不到，能否开个线程独占一个CPU核，当单片机用？
mcu5i51 发表于 2022-7-14 09:27
媒体定时器可以1ms以下分辨率
(引用自14楼)
不是定时器分辨率的问题是消息机制的问题，消息机制延时有15ms左右 搜索“how to make windows application more real time "，结果第一条就是这篇，看看有没有用：
https://docs.microsoft.com/en-us/windows/iot/iot-enterprise/soft-real-time/soft-real-time-application
本帖最后由 chinaboy25 于 2022-7-15 09:00 编辑
Rabbitoose 发表于 2022-7-15 08:08
搜索“how to make windows application more real time "，结果第一条就是这篇，看看有没有用：
https://d ...
(引用自20楼)
试试看，我之前在任务管理器里面把任务优先级设置成实时，估计和这个效果是一样的，然而并没什么用，主要是串口底层驱动机制的问题，底层驱动机制是基于消息的，现在延时主要是在消息的延时上；
也不是说一点用都没有，偶尔有10ms的5ms的延时出来同样的也有20多ms的延时出来； chinaboy25 发表于 2022-7-15 08:59
试试看，我之前在任务管理器里面把任务优先级设置成实时，估计和这个效果是一样的，然而并没什么用，主要 ...
(引用自21楼)
谁说串口底层是基于消息的？
读写串口和读写文件是一样的函数，用阻塞式的读写就行了。io操作本身的耗时肯定是低于毫秒级别的 chinaboy25 发表于 2022-7-14 19:08
不是定时器分辨率的问题是消息机制的问题，消息机制延时有15ms左右
(引用自19楼)
多媒体定时器是不用消息的，采用回调方式，本质就是软中断 chinaboy25 发表于 2022-7-14 19:08
不是定时器分辨率的问题是消息机制的问题，消息机制延时有15ms左右
(引用自19楼)
悄悄告诉你，有些CNC软件是用PC并口直接控制步进驱动器的，可以精确输出100K分辨率控制信号；另外当初测试过，直接控制并口用时是1us（总线用时），如果底层没有改变，这就是极限了； mcu5i51 发表于 2022-7-15 11:11
悄悄告诉你，有些CNC软件是用PC并口直接控制步进驱动器的，可以精确输出100K分辨率控制信号；另外当初测 ...
(引用自24楼)
这个有点牛了， mcu5i51 发表于 2022-7-15 11:11
悄悄告诉你，有些CNC软件是用PC并口直接控制步进驱动器的，可以精确输出100K分辨率控制信号；另外当初测 ...
(引用自24楼)
竟然能切换到底层，谢谢提供的信息 redroof 发表于 2022-7-15 09:06
谁说串口底层是基于消息的？
读写串口和读写文件是一样的函数，用阻塞式的读写就行了。io操作本身的耗时 ...
(引用自22楼)
就是用的阻塞函数另开线程一直读串口，通过打印接收时间发现，没有间隔低于15ms的收数据的时间， mcu5i51 发表于 2022-7-15 11:03
多媒体定时器是不用消息的，采用回调方式，本质就是软中断
(引用自23楼)
我试试看，之前看到过，我现在用的是c++的std库的定时器 chinaboy25 发表于 2022-7-15 12:53
就是用的阻塞函数另开线程一直读串口，通过打印接收时间发现，没有间隔低于15ms的收数据的时间， ...
(引用自27楼)
是不是你之前设了读超时？
或者一次只读一个字节看看。
还有，取时间的函数用rdtsc，这个可以精确到你的cpu周期 可以试下用多媒体定时器来做 不懂上位机, 借楼请教大师, 像做modbus接收, 3.5个字符分包, 上位机是用超时做分包的吗? 还是远超了3.5个字符了 ddcour 发表于 2022-7-15 15:31
不懂上位机, 借楼请教大师, 像做modbus接收, 3.5个字符分包, 上位机是用超时做分包的吗? 还是远超了3.5个字 ...
(引用自31楼)
没法保证。请不要依赖这一点，靠程序自己识别数据内容才保险。
ddcour 发表于 2022-7-15 15:31
不懂上位机, 借楼请教大师, 像做modbus接收, 3.5个字符分包, 上位机是用超时做分包的吗? 还是远超了3.5个字 ...
(引用自31楼)
上位机做主机的话接收分包时间几十毫秒都可以，反正就你一个主机，一切都在你掌控中 redroof 发表于 2022-7-15 13:05
是不是你之前设了读超时？
或者一次只读一个字节看看。
还有，取时间的函数用rdtsc，这个可以精确到你的c ...
(引用自29楼)
应该是底层驱动做限制，并不是每个字节到来就通知你程序，而是要等到串口总线空闲再通知你程序，你程序读串口没有数据被阻塞，等串口数据到了，在唤醒你的的线程，这里面就涉及到了消息机制， redroof 发表于 2022-7-15 16:13
没法保证。请不要依赖这一点，靠程序自己识别数据内容才保险。
(引用自32楼)
多谢大师!
现在学习用c#做了个小工具, 也是这么做的, 根据返回的长度, 结束接收.
现在想收到一个包,并通过CRC校验了, 再产生一个事件, 让屏幕刷新显示, 还没用用起来, 不会使用事件{:titter:} modbus 发表于 2022-7-15 16:22
上位机做主机的话接收分包时间几十毫秒都可以，反正就你一个主机，一切都在你掌控中 ...
(引用自33楼)
虽然这样说也没错, 但是如果从站多了, 这样轮询周期就边长了 ddcour 发表于 2022-7-16 08:18
多谢大师!
现在学习用c#做了个小工具, 也是这么做的, 根据返回的长度, 结束接收.
现在想收到一个包,并通 ...
(引用自35楼)
C#一毫秒是不可能做到的，datareceived事件速度超慢，即使单独开个线程接受，1ms的线程切换延时也是不可靠的，
根据数据长度结束接受也是不可靠的，因为会有粘包半包等等问题，不可能刚好是想要的数据，
有的不可靠的时候帧头多个0xFF的都有。。。，最后导致接受完全错乱，还是要根据协议来，具体问题具体分析。 1.
发数据，难道不进行数据的消息传递？UI的呈现？
收数据，难道不进行数据的消息传递？UI的呈现？
这些才是最耗时的。
2.
主板原生并口，可以进行真IO的低延时传输，问题是现在有多少电脑带主板原生并口?
ddcour 发表于 2022-7-16 08:21
虽然这样说也没错, 但是如果从站多了, 这样轮询周期就边长了
(引用自36楼)
想要快的话可以用多媒体定时器分包，5ms的分包间隔还是没问题的
页:
[1]