FIFO的一点问题，ZLG的工程师看看，与你们的程序有关，谢谢

只看该作者 · 2008-10-15 17:32

你们的IAP应用程序升级文档（AN070701）中的UART驱动。当U0IIR&0x0E=0x04的时候超时中断，置RcvOver为1，表示程序接受完成一个包。FIFO为8字节触发。问题是：当接受的包恰好为8的整数倍的时候，是不进入04分支的，此时用定时器判断超时？在定时器中断中置RcvOver为1表示接受完成？这个时间是多少？一堆数据的最后一个包是不知道字节多少的，很有可能为8的整数倍的。你们的程序是没有这一部分的，使bug吗？

只看该作者 · 2008-10-17 10:23

您好：
  关于您提到的问题可参考如下解释，希望对您有所帮助。

A:程序中使用定时器来控制升级的时间，本程序中设定为30s（可以根据实际需要修改此时间值）。    现在主要讨论接受的包恰好为8的整数倍的情况。无论在30s内程序是否升级完毕或者成功升级，30s的定时时间到时，程序都会强行认为升级已经结束，这样可以防止由于出错而导致程序无限等待的现象。
  如果程序在30s内升级完毕，则程序依然会等到30s 的定时时间结束；
  如果升级中途出错，比如串口断开，则30s 的定时时间一到，程序也会认为升级结束。
  当然，这样并不能保证程序能正确的升级，只是提供一种思路。由于本程序属于学习版，故用户可以根据自己的需要对程序进行修改和完善，以保证程序升级的正确性。

1万 · 2008-10-17 13:51

   真的要做升级，最好先把加密的代码存在外部Flash (可选SPI接口SO8封装的，便宜)，检测代码的完整性后，再升级。

只看该作者 · 2008-10-20 11:33

包恰好为8的整数倍的情况, 按照你们的程序是没有接收到数据的.实际应用中只能避开了? 即便最后一个包不完整,也添0或FF以按完整包发过去以避免这种情况

1万 · 2008-10-23 16:19

   通讯程序必须做到接收、发送任意字节都是OK的。

   对于LPC2000系列的串口接收，(IIR & 0x0e) 值为0x0c或0x04时做相同的接收处理即可。

   对于通讯响应不要求很快的场合，有多种协议的场合，可以统一用接收队列，不用区分帧格式，全部照收。在处理任务里判断超时及扫描队列。

  例：

__inline    void   UartCls::Interrupt(void)
{
    // ......
    OverTimeCnt = 0;                  // 接收数据时，清超时计数器
    Rec.Buffer[Rec.Counter++] = rc;   // 入队
    // ......
}

void        UartCls::Task(void)
{
   //  ......
   if( (++OverTimeCnt>2)&&(Rec.Counter) )   // 通常取2~5个系统节拍
   {
       // 扫描接收队列，处理数据
   }
}

只看该作者 · 2008-10-24 16:26

赞你一个。这样的做法很好，但是数据结构及处理程序都复杂了。怎么用根据具体项目协议去做会不会更实用些？所多做的工作就是master一方在最后按完整包发数据。接受方用普通数组搞定。第一个字节就是包头，不用去扫描队列查找包头了。

只看该作者 · 2008-10-25 09:47

您好！

即使升级程序是8的整数倍，也可以处理啊，虽然RcvOver没有被置1,但是 RcvCount已经不为0了，用来判断是否升级的是RcvCount 而不是RcvOver。

其实这个教学版的IAP升级程序是很不安全的，仅作为教学使用。

1万 · 2008-10-25 22:12

我就遇到一个项目，上位机是别人搞的，协议很烂，帧头有十个八个的。

如果是单一协议，有帧头帧尾，当然在中断时里处理帧头帧尾较简单......

FIFO的一点问题，ZLG的工程师看看，与你们的程序有关，谢谢

相关下载

相关帖子

有关IAP问题

这些升级都很危险的， 不敢用......

:)

4楼的方法是不可取的

To 汽车电子

RE：ZTEnew

哈哈，5楼是在 有多种协议的场合

核心会员奖章

沉静之湖泊

以坛为家

技术奇才奖章

这些升级都很危险的，不敢用......

哈哈，5楼是在有多种协议的场合