I'm a little late on this discussion but since I have lots of CAN experience and I'm also working on getting CAN working on my Beagle so I thought I'd jump in. I bought the Logic Supply CBB_Serial with the on board CAN driver. I followed the instructions on page 14 of their Serial Cape Manual with the only exception that I had to change to git clone https://github.com/linux-can/can-utils.git from the git://gitorious.org site.
I've always suggested when working with CAN in embedded systems the easiest solution is to have on hand one working functional CAN module. Ideally something like a CANUSB from Lawicel or one of the other dongles. The ability to generate well formed correctly timed messages can save you hours of time. Since I had a working system I set the bit rate up to 250kbps becauseI was attaching to a CANOpen system. I'd done the ip link command at the start of the instruction sheet and now had to first ifconfig can0 down then redo the bit rate ip link set can0 up type can bitrate 250000 finally ifconfig can0 up Imagine my surprise when I got a dump of the correct messages after running candump can0. Next step was to attach onto a project with custom CAN messages running 1Mbps. Same process but with 1000000 for bit rate. In this case the host sends a block of messages for RGBW LED Lamp intensity to nodes 2 through 96 in even ID# increments because the odd node also receives the even node message and uses the second 4 bytes of each message for LED information. Once every loop it waits a bit, then sends out a request to one specific node for node status; like temperature and bus voltage. Then starts the whole refresh cycle again. The example from candump is below. root@beaglebone:~# candump -t d -n 12000 can0 >logfile_can.txt root@beaglebone:~# nano logfile_can.txt (000.000124) can0 290 [8] FC D3 40 FF FC D3 40 FF (000.000126) can0 294 [8] FC D3 40 FF FC D3 40 FF (000.000113) can0 298 [8] FC D3 40 FF FC D3 40 FF (000.000110) can0 296 [8] FC D3 40 FF FC D3 40 FF <-- last node polled (000.001741) can0 446 [1] 28 <-- Command for lamp status. (000.008456) can0 546 [8] 28 D3 28 02 00 00 77 70 <-- Reply from lamp 0x46 (000.020936) can0 202 [8] FC D3 40 FF FC D3 40 FF <-- polling starts again. (000.000085) can0 204 [8] FC D3 40 FF FC D3 40 FF (000.000140) can0 208 [8] FC D3 40 FF FC D3 40 FF However, I'm running into problems that completely crash the beagle. I run candump continuously rather than for a set number of messages. The 4 leds freeze. A power cycle is the only solution. This happens when I use PuTTY from my WIN7 PC and the USB port and after a while the messages stop and it locks up. That could be a Windows problem since the USB port interface could lock up the beagle. Next step was hard wired Ethernet to 192.168.0.125 and PuTTY. Now it appears to run without issues messages streaming by. But, if I try to open any other session into the beagle via web and Cloud 9 I can get in but at some point the system locks up and freezes. Especially if I close the browser. My first guess is I shouldn't be running candump as root since the cloud 9 also logs in as root. Can it be as simple as that? But why would the system lock up? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
