Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Ed,

You are correct in that utilizing the hardware filtering features of the mcp2515 is not supported by SocketCAN.

I've attached a patch for the changes we have made in the past to support hardware filtering, though it requires the hardware filter setup to occur at module load time via module parameters. I'm not sure if this will meet the requirements of your project, but it should at least function as a working example.

Regarding your question of other known pitfalls for operating CAN at a high bit rate, this depends on what kind of real-time response to CAN messages you are expecting of your L138 application. If you have tight requirements for response times to CAN messages that are intended for the L138 you may need to consider the Linux Real-Time kernel patches or Xenomai. We have experience with the Real-Time patches exactly for this reason and were able to get our CAN response times to 3-5 milliseconds, though it took a bit of custom work and configuration. (Note that these kernel mods are still considered a work in progress, so we have not pushed this branch to our support site yet).

Let me know if you have any other questions.

Thanks,
\Greg

Hi Greg

The patch looks very useful. I need to set the mcp2515 as a module with menuconfig, correct? But I don't see that .ko being generated when I run make for the modules.
I have made Raw CAN Protocol a module, although I have just found CAN Device Drivers ---> Microchip MCP251x. Is that what I need to modularise?

Verify in your .config file that CONFIG_CAN_MCP251X=m

Are you running make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- modules?

I have the patched kernel and modules built and installed now.

Now, connecting a USB-CAN PC logger I see multiple messages in the log, very closely spaced for each one sent by cansend on the l138.

I have a script that runs at startup which just calls
modprobe mcp251x

to load the module with no arguments, for no filtering. I cant see anything in the patch that would affect outgoing messages. Any ideas much appreciated.

Indeed it is not an issue with the patch, if I use git checkout to revert the patch and rebuild the kernel with the mcp251x driver built in, I still see the multiple messages. I will look into what kernel changes have been made from mitydsp-linux-v3.2.

Interestingly, it is only zero data length messages which are repeated such as the sync.

Interesting, let us know what you find. I don't think we have tested zero length messages.

Was going through kernel patches for can and noticed this patch in mainline. Maybe its related to your repeated frames.
https://www.spinics.net/lists/netdev/msg209551.html
can: mcp251x: avoid repeated frame bug

Note that if you built the kernel from branch mitydsp-linux-v3.2 of git://support.criticallink.com/home/git/linux-davinci.git this patch has previously been applied. See https://support.criticallink.com/gitweb/?p=linux-davinci.git;a=commit;h=bae5c92f45af71f247345e7eb6a1456b79bffb56 for details.

Thanks,
\Greg