Hi Ohtake, On 10/12/2010 09:09 AM, Masayuki Ohtake wrote: > Hi Wolfgang, > > We have implemented our CAN driver with FIFO mode, and > We are testing our CAN driver with FIFO mode. > However, we have found Our CAN hardware spec is different from our > anticipated. > Our CAN HW FIFO is not common FIFO. > Using FIFO mode, there is possibility received packets are out-of-order. > > e.g. > Recv packet-A from NW and set to FIFO. > |A| > > Recv packet-B from NW and set to FIFO. > |A|B| > > Recv packet-C is about to set to FIFO > |A|B|(C)| > > Userspace Copies A from Driver
OK, let's say the CPU or software starts processing the message FIFO. > Userspace Copies B from Driver > | | |(C)| > > packet-C set to FIFO (C is not head.) > Recv packet-D from NW(Next packet is set to head) > |D| |C| > > Userspace Copies D from Driver The software could continues searching the FIFO for valid messages. Then it would find C first. > Userspace Copies C from Driver > Userspace raceived packet order is like below > A-B-D-C I'm still optimistic that it could be handled properly by software, it might be tricky though. > So, I think normal-mode is better than FIFO-mode. To be clear. Out-of-order reception is not allowed! > I will revert like the following spec. > Rx 1 Message Object > Tx 1 Message Object > > Could you agree the above ? See above. I agree if the software cannot assure in-order reception. But it's not yet obvious to me that it cannot be achieved. I will have a closer look to the manual. Just one RX message object without any further buffering is really bad as message losses are likely to happen. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
