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.