Hello,
I am planning to use Beaglebone black and implement either a CAN CAPE or a CAN transceiver to be able to send and receive messages for our project. The machine I would like to send messages to uses CAN FD . Is BBB compatible with CAN FD as well and where would I begin since I am very new to this.
Where would I be writing my script to send messages over CAN?
Please help
The Black is not CAN FD compatible.
This link is old and since the Beagle world is like Microsoft Windows likely no longer compatible if it’s more than a few years back.
http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/
But there might be enough to get you going at whatever the latest flavour of the month (week?) is for the BBB OS. (Sarcasm intended!)
Once you have the hardware enabled:
This gets you access from the command line to CAN messages.
And then there’s this:
https://github.com/linux-can/can-utils
@gurpreety Most new micros these days that have CAN, come with CAN FD. However more often than not these are just sending stand CAN 2.0B messages. CAN FD is backwards compatible, If your machine is not actually making use of the newer CAN FD functionality, then the BBB will be able to talk with it.
If you really need CAN FD then you will need the BeagleBone AI-64 which has around 11 CAN-FD buses available on the header, depending on what else you are using. You will of course need to provide CAN transceivers .
Programming CAN is very simple. you can use the can-utils commands from the command line for simple scripting. If you want to write your own software then search for SocketCAN.
It is pretty simple to use in C and you can also get a socketcan module for python (never used this) if you prefer that.
I’m not sure that’s generally true. For example, with ST I believe you have to go up to the STM32G7 or STM32H7 series to get CAN-FD. CAN 2.0 is widespread, but I haven’t found the same to be true of CAN FD.
Of course, I don’t know every microcontroller family, so if someone has better knowledge, please feel free to correct me as I’ve got a couple of customers moving to 10BASE-T1S and CAN-FD might be a useful intermediate point for a couple of them. However, given the cost of the microcontrollers, they’re overall better off going straight to Ethernet with a much cheaper micro and a relatively expensive PHY (10BASE-T1S) rather than the interim jump which would be a lot more expensive micro and a slightly cheaper PHY (CAN-FD) .
Thanks.
You are correct. Possibly each of the latest and greatest processors out there now do have CAN-FD but I’m still using processors like the PIC30F5011 and the PIC30F4012 for example. Both those have CAN and both have only CAN 2.0B.
Another processor that I have to eventually let go is the M9S12. It has 5 CAN channels and 512K flash. But it’s old. The IDE still runs on WIN-10 but there haven’t been any changes to the compiler etc. for a long time. It ran this via USB commands. http://www.autoartisans.com/rings/Barge1a.jpg and reported temperatures of each lamp. http://www.autoartisans.com/rings/BargeRingsTemperatures.JPG The lamps had PIC18F devices with one CAN 2.0B.
It all depends on who you are designing writing the code for. A project like the one above that is for one year of operation can take the latest and greatest that is changing every 3 months.
But other customers have a much longer term view. They may need something that runs for 20 years and they don’t want constant change. They may not even be allowed constant change.
I don’t think CAN 2.0B will ever go away anymore than that we still use UARTs at 9600 baud. After all the BBB has UARTs and CAN 2.0B. More than adequate for 99% of the projects that need CAN.
@jcdammeyer Cool photos, was that the Vancouver Winter Olympics ? Must have been an interesting project.
I agree CAN2.0 is not going away anytime soon. There are millions of cars out there using it that are going to be around for at least the next 10 years and will need to be supported.
Existing chips that only have CAN 2.0 will stay that way. But I believe new chip designs will incorporate CAN-FD modules rather than CAN 2.0 It is a bit of a chicken and egg situation. While there is little need for CAN-FD there will be little choice of chips that support CAN-FD. For most purposes CAN 2.0 is good enough. If you need larger data/higher speeds then there may be better options.
Incidentally the dsPIC33’s have CAN FD.
Yes. 2010 Winter Olympics. As far as I know it’s still has the record for the largest CAN network. Two M9S12 with 5 CAN channels and two USB interfaces into WIN-XP and display software written in Delphi 6.0.
Each ring had 150 lamps with a PIC18F for each channel on the 9S12. So 1500 nodes for the dual sided rings which were almost 5 stories high. (Not small). Not only that the update rate was at the CINE camera frame rate of 24 frames per second so that there wouldn’t be moving bars when filmed with either CINE, NTSC or PAL.
The PIC32MK1024MCM064, which I’ve laid out as a replacement for my ELS project, has CAN FD. On the original ELS the X axis step/dir were optionally CAN. The PIC32 can keep step/dir and there’s a second CAN device with driver on the board. And like some of the ST series processors, this device has 4 CAN channels.
You must have been pushing the limits on bus length for that. Did you use any sort of CAN repeater ?
Good question actually. Limit of nodes on a CAN 2.0B is 120 devices. When we were first asked to design this the target was the Lions Gate Bridge and at that distance Airy Disk Effect calculations said 100 lamps per ring were adequate.
However I took a trip to Vancouver and looked at where the unveiling would be and how the lamps would be visible and hold out a penny at arms length and it would cover the entire set of rings.
So YVR airport popped in with a suggestion on where to mount the single set of rings. But now the unveiling and camera location meant we had to increase to 150 lamps per ring. And do another production run. This all happened over Christmas and New Years which is why we couldn’t use a COTS product. Nothing was available in time.
Anyway, a bit of research turned up a CAN bridge with a CANopen port for diagnostics and configuration. They came from TKE in Finland and used an M9S12 inside so they were able to run our firmware to verify the bridges would do the job. They supplied 5 in short order. One for each ring. Our M9S12 protoboard connected to 5 of the bridges, one for each ring, one for each channel. The bridges split the messages out to 3 ports and by good fortune the mechanical construction of these giant rings was such that 50 lamps were on each section.
That’s where a measurement error occurred and the 1MBPS was a tad too fast for the outermost sections. Ultimately we had 1MBPS and 500KBPS sections. The Bridges handled that easily. Each lamp had a DS1822 temperature sensor and serial number device. So we could address a lamp with the same ID as another and set the ID to a unique one by addressing with the serial #.
What made the entire project unique and special was that from 05DEC2008 to the unveiling on 05MAR09 over Christmas and New Years we built 750 custom lamps in sets of 500 and 250 and used a 9S12 demo board to create an awesome display. The mounting of the lamps on the rings happened mid February for the March unveiling. The extra month was because we had to add 250 lamps and the bridges.
