关于LPC17xx系列的CAN的使用总结

本帖最后由 micao 于 2013-1-25 22:23 编辑

LPC1768有CAN1和CAN2，每个CANx有3个Tx Buffer。在绝大多数网上download的demo几乎都这样处理CAN的发送，分别去读取3个buffer中是否释放了，然后将数据copy到已经释放的buffer中。看似合理，却是有个很大的Bug。假设现在有100个字节需要发送，这100个数据都是发向同一个CAN ID，那可以负责的告诉你，实际上这100个数据绝对不是按照你的预想按顺序发送出去的。几乎第一个字节是最先发送的，然后后面的数据发送的顺序不知道打乱成什么样子。那到底是什么原因呢？
      原因是，CAN的Buffer有个优先级竞争。原理：当没有设置逻辑优先级时，若3个Buffer中是数据是按照ID来确认优先级的，ID越低，优先级越高，该报文最先发送出去。但是我们这里是同一个ID，所以这种优先级并不能处理我们的问题。此时发送的数据是相当混乱的。
     有人肯定会想到，我们人为来按顺序处理，比如第一个报文（每个报文发送8字数据）用buffer1，第二报文用buffer2，第3个报文有buffer3，然后第4个报文用buffer1，如此循环。呵呵恭喜你想法是好的，但是发送出来的数据还是混乱的。why？cpu将报文copy到buffer中的速度是远远大于CAN发送的速率的（CAN的波特率去250K），即使你提供CAN的波特率，效果亦无多大改善。
    LPCxxxx有个特性，当3个buffer全部都有数据时，且他们具有相同的优先级，则Buffer1优先发送，Buffer2次之，buffer3的数据最后发送。这就解释了上述问题的原因。当您将第4个报文copy到buffer1的时候，可能buffer2（或者buffer3）的数据还没开始发送，这样buffer1中的报文4必优先报文2（或报文3）发送，这样实际发送出去的数据根本不是按照你所设想的方式发送出去。那改如何解决呢？有没有解决的办法，有，3钟解决办法，有好有坏，可自己权衡。
    1. 每发送一个报文，做一个延时，延时的时间根据CAN的波特率，自己慢慢测试吧，总能找到一个合适的时间，当波特率改变时，这个延时的时间亦需要跟着调整，移植性极差，且效率很低。
    2. 在每个报文发送前，查看CAN1GSR的TBS位是否释放（TBS位表示所有 3 个发送缓冲器都可以供 CPU 使用），若释放，则copy下一个报文到buffer，这样解决了问题，可移植性和效率都比方法1高了那么一点点。这样等于你只用到1个buffer，另外2个buffer都是空着的，没有充分利用已有硬件资源。
    3. 重点来了，呵呵。copy报文前，查看buffer1，buffer2，buffer3是否释放，只要有一个buffer释放，就将报文copy到该buffer中，但依然会出现高优先级的buffer中的报文抢先低优先级的buffer中的报文。此时就需要设置CAN的发送模式为逻辑优先级发送。将CAN1MOD的TPM位置1，然后为每个报文设置发送优先级。CAN1tiFx的bit[7..0]中定义了改buffer中存储报文的优先级，该场域中的数据越低，优先级越高，报文越先发送出去。只要为每个报文设置逻辑优先级，变可按照我们预想的顺序发送了。
   呵呵，不好意思，方法3你可能会遇到一个比较难的bug，你会发现，即使你用了方法3，你也不能安装你的预想发送数据。原因在，你如何设置CAN1MOD，CAN1MOD必须在CAN禁能下，才能改变。翻遍LPC的UserMannual也没发现有地方特别说明了这个特性。然后我就在CAN1复位后，改变CAN1MOD值，实际发送出去的数据仍然是混乱的，debug模式下单步，才知道CAN1MOD中的值根本就没改变。到这里，再次鄙视下LPC（不是第一次了，好像有点抱怨的味道，呵呵），功能比STM32差很多，手册写的亦是非常不仔细。另外网上传的很经典的中文版的usermannul错误实在太多，大家还是看英文原版的吧，我采用了个折中的办法，中英文结合按。
呵呵，至此，对LPCxxxx的CAN才有了个比较深刻的认识。有待继续学习。