huo_hu

应该不会啊，收和发是两个独立的缓冲区，真是你说的那样不要玩了。

huo_hu

不行你换个单片机吧，应该不会有这种情况，真有的话算是大毛病了。

huo_hu

你试试这个
unsigned char rbuf[16],rpo=0,spo=0;

while（1） {
if (RI) {RI=0;rbuf[rpo]=SBUF;rpo++,rbuf[rpo]=1;rpo++;rpo&=15;}
if (spo!=rpo) {
    SBUF=rbuf[spo];sop++;spo&=15；
    while(!TI);
   TI=0；
}


}

huo_hu

最好是用中断处理,缓冲区是必须的。

bobde163

huo_hu 发表于 2016-11-11 12:27
你试试这个
unsigned char rbuf[16],rpo=0,spo=0;

while（1） {
if (RI) {RI=0;rbuf[rpo]=SBUF;rpo++, ...

这样一次发少量数据是没有问题的，但是那位网友是收到一个字节就要发送两个字节，在这种接收速度大于发送速度的情况下，就算开再大的缓冲区也是会丢失数据的，说到根本上还是要发比收快才行。
而且你上面的代码在一次发送大量数据的时候也会出错，从接收到一个字节到你开始发送一个字节中间也是要有时间消耗的，但是上位机发送数据几乎是一个字节挨着一个字节发送的，几乎不存在字节间的间隙，在一次发少量数据时，这个时间消耗累积不会导致阻滞接收的效果，一旦数据量大到一定程度时，还是会出错的

huo_hu

bobde163 发表于 2016-11-11 23:04
这样一次发少量数据是没有问题的，但是那位网友是收到一个字节就要发送两个字节，在这种接收速度大于发送 ...

收一发二，如果缓冲不够肯定无解，那还研究啥啊

bobde163

huo_hu 发表于 2016-11-11 23:59
收一发二，如果缓冲不够肯定无解，那还研究啥啊

我做这个探究目的是让那位坛友知道问题的所在和以后要注意的关键点，有做过串口开发的可能一眼就看出问题来了，所以我们还是互相之间不要太较真了，让不明白的坛友能理解想通就可以了

huo_hu

bobde163 发表于 2016-11-12 00:39
我做这个探究目的是让那位坛友知道问题的所在和以后要注意的关键点，有做过串口开发的可能一眼就看出问题 ...

言语不当之处海含

bobde163

huo_hu 发表于 2016-11-12 18:16
言语不当之处海含

版主你多虑了，你并没有什么言语不当的地方，是我自己钻牛角尖了

幻听你的温柔

bobde163 发表于 2016-11-4 19:47
当时我也怕是串口工具有问题，所以才照着那位坛友把他测试用的软件和参数都尽量保证一样，实际测出的现象 ...

大神，这个问题你是怎么解决的 （数据丢失）

bobde163

幻听你的温柔 发表于 2016-11-14 13:50
大神，这个问题你是怎么解决的 （数据丢失）

总结一点就是处理接收到的数据的速度要比接收数据的速度要快，不然就会丢失数据

幻听你的温柔

bobde163 发表于 2016-11-14 21:41
总结一点就是处理接收到的数据的速度要比接收数据的速度要快，不然就会丢失数据

可以具体点吗http://www.51hei.com/bbs/forum.p ... id=58110&pid=242906

bobde163

幻听你的温柔 发表于 2016-11-14 22:08
可以具体点吗http://www.51hei.com/bbs/forum.php?mod=redirect&goto=findpost&ptid=58110&pid=242906

大致看了一下你的程序，你利用了缓冲区在串口1的接收中断中不断地接收数据，同时使用了定时器来判断是否数据接收完成，然后才是开始使用串口2发送数据，原理上你是收到全部数据之后才会开始发送，这是没有问题的，流程上算是半双工模式，某一时刻要么在接收数据，要么在发送数据，那为什么会丢失一个数据，现在还看不出来，你最好是多测试一些长度不一样的数据串看看有没有规律，是否只是会丢失最后一个数据，二来你检查一下你使用定时器判断接收完成的机制有没有错误；第三是你的代码while(p_send<=rec1_count)//判断发送指针的值是否小于全局计数器，会让你多发一个数据，但还是有丢失数据的现象，你再认真思考一下

幻听你的温柔

bobde163 发表于 2016-11-19 01:18
大致看了一下你的程序，你利用了缓冲区在串口1的接收中断中不断地接收数据，同时使用了定时器来判断是否 ...

谢谢

cybers

学习了，谢谢！
发一串口工具，大家试用一下，请多提建议。