Am 12.10.2010 12:53, schrieb Michal Sojka: > On Mon, 11 Oct 2010, Wolfgang Grandegger wrote: >> On 10/11/2010 05:01 PM, "Müller, René" wrote: >>> Now we have two cases, one with missing frames and one without: >>> Case 1: >>> - candump -l -s2 can0 -> logging in an file which is stored in RAM >>> - we get all messages in the logfile >>> >>> Case 2: >>> - candump -l -s2 can0 -> logging in an file which is stored on an >>> CompactFlash-card >>> - the CF-card is connected via the IDE-interface without DMA (we don't get >>> DMA working with the CF-card, unfortunately it only works with harddrives) >>> - we are loosing messages: >>> - every 35s we are missing messages in blocks, never we are missing 1 >>> message, always 5-6 at once >>> >>> Anyone had similar problems? Any hints? >> >> Sounds like a receive buffer overrun when the application is not able to >> read messages fast enough. You could use setsockopt(... ,SOL_SOCKET, >> SO_RCVBUF, ....) to increase the buffer size. It's also possible to >> detect dropped CAN frames as described here: > > I'm not sure whether this is receive buffer overrun. AFAIK 5200 has some > problems with ATA. People using 5200 with CF complain about hudge > latencies caused by ATA interrupts. I do not know whether this is > related to using DMA or not. >
This sounds like our problem. As I wrote in the other mail, we only loose frames, if we have IDE-traffic. Do you know anyone with an solution to the high latencies caused by IDE interrupts? > The CAN controller on 5200 has hardware buffers only for 2 messages. The > driver reads the received messages in soft-irq so if the soft-irq is > delayed you loose the mesasges because of hardware buffer overruns. I > gess this is very likely especially if you use CF. > I don't think so. If we use candump with the '-d' option it reports dropped frames. These frames are dropped of the buffer in the kernel, so the frames are already read out of the hardware buffers. Maybe I'm wrong on this, but this is how I understand it. > We were able to avoid losing messages by reading them in hard-irq > context (with lincan driver), but I'm not sure whether this will help if > you use CF (we do not use it). What's this lincan driver? I found it on sourceforge, but it seems to lack MPC5200-support. In addition we are happy with socketcan, but if we are stuck with bad hardware (MPC5200), we are open to every chance... Thanks, René _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
