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 的定时时间一到，程序也会认为升级结束。   当然，这样并不能保证程序能正确的升级，只是提供一种思路。由于本程序属于学习版，故用户可以根据自己的需要对程序进行修改和完善，以保证程序升级的正确性。

发表于 2008-10-17 13:51

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

发表于 2008-10-20 11:33

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

发表于 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&gt2)&&(Rec.Counter) )   // 通常取2~5个系统节拍    {        // 扫描接收队列，处理数据     } }

发表于 2008-10-24 16:26

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

发表于 2008-10-25 09:47

您好！ 即使升级程序是8的整数倍，也可以处理啊，虽然RcvOver没有被置1,但是 RcvCount已经不为0了，用来判断是否升级的是RcvCount 而不是RcvOver。 其实这个教学版的IAP升级程序是很不安全的，仅作为教学使用。

发表于 2008-10-25 22:12

我就遇到一个项目，上位机是别人搞的，协议很烂，帧头有十个八个的。    如果是单一协议，有帧头帧尾，当然在中断时里处理帧头帧尾较简单......

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

相关帖子

有关IAP问题

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

:)

4楼的方法是不可取的

To 汽车电子

RE：ZTEnew

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

浏览过的版块

核心会员奖章

沉静之湖泊

以坛为家

技术奇才奖章

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

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