搜索
bottom↓
回复: 23

请教傻孩子:高波特率,大数据量时,通讯质量不好的解决方法.

[复制链接]

出0入0汤圆

发表于 2010-1-28 08:48:05 | 显示全部楼层 |阅读模式
傻孩子:
    我的程序 定时中断=12ms,中断服务程序大约执行时间=0.5ms  
    我用MODSCAN32软件读取保持寄存器,寄存器数量=125

   (1).波特率在9600,19200,38400时,通讯质量非常好,成功率100%. 但是当波特率=57600,115200时,通讯质量只达到98%左右.
    (2).当屏蔽中断服务程序中的代码,则当波特率=57600,115200时,通讯质量也非常好,成功率100%

   我实在找不出解决办法了,因为不可能在实际应用中也"屏蔽中断服务程序代码"呀!

阿莫论坛20周年了!感谢大家的支持与爱护!!

月入3000的是反美的。收入3万是亲美的。收入30万是移民美国的。收入300万是取得绿卡后回国,教唆那些3000来反美的!

出0入0汤圆

发表于 2010-1-28 09:11:38 | 显示全部楼层
大数据量时是不是按帧+检验通讯的?

出0入0汤圆

发表于 2010-1-28 09:41:57 | 显示全部楼层
所有数据需要校验的,出错的数据不用。

出0入0汤圆

发表于 2010-1-28 10:39:01 | 显示全部楼层
回复【楼主位】ba_wang_mao
-----------------------------------------------------------------------

典型的异步冲突问题。
定时器中断如果对相位不敏感(就是不要求边沿准确性),可以让位给通信中断。即:通信用中断,而定时器采用nake中断,只进行信号设置,在程序中进行处理,这样就不会打断通信函数的执行。

出0入296汤圆

发表于 2010-1-28 11:52:19 | 显示全部楼层
这就需要看你的定时器中断处理程序所做的工作是否重要了,如果不是很重要,建议
修改工作模式,即仅仅使用定时器中断处理程序来设置一个时标,在主程序中检测
时标并执行相应函数。

出0入0汤圆

 楼主| 发表于 2010-1-28 13:34:34 | 显示全部楼层
1. 通讯协议为:标准的MODBUS RTU 协议.
   2. 定时中断采用CTC模式.
      定时中断中的"服务程序"非常重要,和时间密切相关.因此我不希望中断嵌套.

   求解决方法.

出0入0汤圆

发表于 2010-1-28 13:47:48 | 显示全部楼层
计时精度和相位是两回事。

出0入50汤圆

发表于 2010-1-28 14:33:29 | 显示全部楼层
4楼正解。

俺有个应用也是这样的,虽然出错概率比楼主这个低,但是却是致命的,通过建立标志的形式,告诉主程序,实际中断服务还没完成,主程序会自动调用那段程序继续执行完,不过函数得做成可重入的。

出0入296汤圆

发表于 2010-1-28 14:44:54 | 显示全部楼层
这种应用属于时间和代码功能关联的非常严格的,我所知道的解决方法有一个:

1、分析系统,得出一个流程图,该流程图具有以下特点:
   a、能适应不同的速度
   b、可重入
   C、强壮——具有完善的出错处理和恢复机制

2、根据流程图编写伪状态机
3、实现代码

出0入0汤圆

 楼主| 发表于 2010-1-29 09:24:46 | 显示全部楼层
1.串口接收采用:
   中断+缓存  结构,因此串口中断服务程序占用时间可以忽略不计.

//串口接收中断
#pragma interrupt_handler USART1_RI_ISR:iv_USART1_RX
void USART1_RI_ISR(void)
{
        INT8U ch;
        INT8U status;

        status = UCSR1A;
        ch = UDR1;
        if (USART1_receCount < MSCOMM_BUFFER_LENGTH)
                USART1_mscomm_buffer[USART1_receCount++] = ch;
        else
                USART1_receCount = 0;
        if (status & 0x1C)
                USART1_checkoutError = 2;
        USART1_receTimeOut = 2;
}


2.串口发送采用:
  空中断+完成中断+缓存结构,因此串口发送中断服务程序占用时间可以忽略不计.

//空中断
#pragma interrupt_handler USART1_UDRE_ISR:iv_USART1_UDRE
void USART1_UDRE_ISR(void)
{
        UDR1 = USART1_send_buffer[USART1_sendPosi++];
        if (USART1_sendPosi >= USART1_sendCount)
        {
                UCSR1B &= ~BIT(5);
                UCSR1B |= BIT(6);
        }
}


//完成中断
#pragma interrupt_handler USART1_TX_ISR:iv_USART1_TX
void USART1_TX_ISR(void)
{
        USART1_checkoutError = 0;
        USART1_receCount = 0;
        RS485_RECIVE_enable();
}


3.MODBUS解析在主程序中完成
  具有超时检测功能,检测到一帧完整的数据后,立即启动<串口空中断>开始发送数据.


4.上位机MODSCAN32软件的发送间隔>理论上数据时间.
    例如:MODSCAN32要求读取从站的125个保持寄存器.当波特率=115200时,
       (1).主站的请求命令需要8个字节
       (2).从站的应答帧需要254字节
       共计254字节(11位传输),理论上传输254字节,需要25毫秒.我在MODSCAN32上设置的间隔时间=100毫秒.

       到底具体如何解决?.

出0入296汤圆

发表于 2010-1-29 09:54:32 | 显示全部楼层
定时器中断处理程序做什么的?

出0入0汤圆

 楼主| 发表于 2010-1-29 15:44:28 | 显示全部楼层
【10楼】 Gorgon Meducer 傻孩子:
    定时器中断处理程序做什么的?

  和时间密切相关的程序代码,例如:PID. 和通讯没有任何联系.

   我只想找到具体什么原因导致通讯质量不佳,以及解决方法.

出0入0汤圆

 楼主| 发表于 2010-2-1 13:07:58 | 显示全部楼层
【10楼】 Gorgon Meducer 傻孩子:
    定时器中断处理程序做什么的?  

  和时间密切相关的程序代码,例如:PID. 和通讯没有任何联系.

   我只想找到具体什么原因导致通讯质量不佳,以及具体的解决方法.

     同时我还想验证一下,通讯质量不佳是否是以下原因造成的:
       (1).从站没有及时接收到上位机发送的请求命令,导致通讯质量不佳
       (2).上位机没有及时接收到从站回复的应答帧,导致通讯质量不佳

出0入0汤圆

发表于 2010-2-1 13:14:06 | 显示全部楼层
你这个典型的是单片机没有准确的接收。在0.5ms内的数据没有收全。pc发了100条查询,你回应了98条。在0.5ms中断内开串口中断吧。把收据收全了才有可能提高通讯质量。具体跟波特率无关。modscan设超时时间为300ms。

还有可能你的响应时间在100ms以上,导致modscan认为超时。

出0入0汤圆

 楼主| 发表于 2010-2-1 15:15:11 | 显示全部楼层
1.说数据量大,其实也就是每隔150毫秒主站给从站发送8字节的请求命令后,从站给主站返回254字节的应答命令.
2.定时中断服务程序中的代码大约执行0.5毫秒.
   定时中断服务程序中的代码是和时间密切相关的程序代码,例如:PID. 和通讯没有任何联系.
3.波特率在9600,19200,38400时,通讯质量非常好,成功率100%. 但是当波特率=57600,115200时,通讯质量只达到98%左右.
   目前还无法确定是因为从站没有接收全还是主站没有接收全导致的通讯质量不佳.

出0入296汤圆

发表于 2010-2-1 15:21:43 | 显示全部楼层
看来我帮不上什么忙了……没有实际弄过……

出0入0汤圆

 楼主| 发表于 2010-2-8 09:41:39 | 显示全部楼层
1.我采用中断嵌套的方式(在定时中断中开放全局中断)虽然解决了通讯问题,但是却又引出了另外的问题

      (1).MODBUS 协议,上位机读取从站2000个线圈
      (2).从站在定时中断服务程序中读取"频率"脉冲,然后置标志,在主程序中计算"实际频率".
      (3).在定时中断服务程序中读取完"频率"脉冲后,立即SEI().
           即允许中断嵌套
       (4).串口接收中断和串口发送中断禁止中断嵌套.

  虽然保证了在115200波特率下通讯质量100%(连续通电14个小时),但是却引出了测量频率的不稳定.如何解决这个矛盾呢?

出0入296汤圆

发表于 2010-2-8 10:27:05 | 显示全部楼层
在发送完成中断处理程序中开启中断欠套,或者干脆不允许使用发送完成中断。

出0入0汤圆

 楼主| 发表于 2010-2-9 13:23:16 | 显示全部楼层
1.485通讯必须使用发送完成中断
   否则最后一字节可能还没有到达上位机时,切换到"监听"状态,会导致上位机接收不全.

出0入296汤圆

发表于 2010-2-9 13:32:43 | 显示全部楼层
那就在发送中断里面开全局中断响应看看

出0入0汤圆

发表于 2010-2-9 15:46:44 | 显示全部楼层
我用485通信时没用发送中断,最后一字节用串口监控时没有收到,我的做法是每次发一帧时多发一个字节。

出0入296汤圆

发表于 2010-2-9 17:14:32 | 显示全部楼层
to 【20楼】 FROG0007
    凑合着实现功能的做法,虽然一时管用,但是对长期积累经验和形成
好的学习习惯没有帮助。这是我的体会。
    你应该找找原因,我以前遇到过类似的问题,当时我的问题出在485发送
数据和实际发送完成是分开的。我把最后一个字节丢进缓冲以后就以为发送
完毕了,于是关闭了485芯片的EN信号……结果当然丢了。
    最后的解决方法,没有使用发送完成中断,因为通讯部分属于次要任务,
速率要求不高,同时,系统中有中断模式工作的采样程序,所以使用状态机
查询的方法来处理发送缓冲区。解决方法是把关闭485 EN型号做成一个类似
看门狗的结构,有数据就复位计数器,否则计数器倒计时到0就关闭485的EN
信号。这种方法也很适合使用继电器控制485进行远距离传输的场合。

出0入0汤圆

发表于 2010-2-9 18:28:48 | 显示全部楼层
20楼应该是 485使能收发切换引起的漏发 漏收~

出0入0汤圆

 楼主| 发表于 2010-2-10 09:09:26 | 显示全部楼层
【21楼】 Gorgon Meducer 傻孩子:
   
    那就在发送中断里面开全局中断响应看看 :我试过不行.

   (1).我不想中断嵌套
       因为通讯是次要任务,中断服务程序中的代码(和时间密切相关)才是主要任务,必须保证中断服务程序执行的连续性
   (2).如果采用马潮老师所说的在中断服务程序中置一个标志,然后在主程序中计算.
       实际运行过程中,计算的频率值会不停的波动,即采用下面的方法
     #pragma interrupt_handler TIMER2_COMP_ISR:iv_TIMER2_COMP
     void TIMER2_COMP_ISR(void)
    {
         T1_New = TCNT1;
        T3_New = TCNT3;
         time_ok_mark = TRUE;
         SEI();
         PID();
    }   

    void main(void)
   {
      while(1)
      {
       if (time_ok_mark)
       {
           time_ok_mark = FALSE;
           计算频率
        }
       }
    }

   (3).既然通讯质量不好,只能说明两个原因:
      (a).定时中断服务程序执行时间太长,导致数据接收时:正在接收时,定时中断来了,长时间打断了接收中断,导致通讯线路上后面的数据挤走了前面的数据
      (b).定时中断服务程序执行时间太长,导致数据发送时:正在发送时,定时中断来了,长时间打断了发送中断.
回帖提示: 反政府言论将被立即封锁ID 在按“提交”前,请自问一下:我这样表达会给举报吗,会给自己惹麻烦吗? 另外:尽量不要使用Mark、顶等没有意义的回复。不得大量使用大字体和彩色字。【本论坛不允许直接上传手机拍摄图片,浪费大家下载带宽和论坛服务器空间,请压缩后(图片小于1兆)才上传。压缩方法可以在微信里面发给自己(不要勾选“原图),然后下载,就能得到压缩后的图片】。另外,手机版只能上传图片,要上传附件需要切换到电脑版(不需要使用电脑,手机上切换到电脑版就行,页面底部)。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

手机版|Archiver|amobbs.com 阿莫电子技术论坛 ( 粤ICP备2022115958号, 版权所有:东莞阿莫电子贸易商行 创办于2004年 (公安交互式论坛备案:44190002001997 ) )

GMT+8, 2024-4-27 18:21

© Since 2004 www.amobbs.com, 原www.ourdev.cn, 原www.ouravr.com

快速回复 返回顶部 返回列表