Which uC/manufacturer for CAN bus?

[mc]

If you were starting a new project requiring CAN bus, what manufacturer/microcontroller would you choose?

I'm looking at project that basically involves receiving/sending 32 inputs/16 outputs from an 8 bit databus, and recreating them upto several meters away.
I had briefly considered serial modbus, but after running basic calcs, it's definetly not fast enough.
I'm aiming for sub 180uS refresh for all the inputs/outputs, so am looking at a 5.6Khz refresh rate, which using something bidirectional needs 267kpbs for just the databits before even thinking about start/stop/validity etc.

The other option is TCP modbus, however it wouldn't be quite as straight forward, and doesn't really have the required timing guarantees.

At the moment I'm thinking something 32bit/Arm and already have a couple ST Discovery boards with CAN capable chips, but am wondering if ST is a good choice.

[nctnico]

I'd take a look at NXP's ARM microcontrollers.

[Scrts]

We use Freescale in our company. The microcontrollers are used for devices, that goes to top-end cars like Mercedess, Jaguar, Porsche, etc...

[jancumps]

The TI Hercules range (TMS570x, ARM Cortex R family) is for automotive use and has CAN peripherals embedded.
If your application requires certification, I'd look into automotive specific ?Cs.

[matkar]

You intend to put quite a load on CAN bus. "Normal" bus load should not exceed 30% load. You can go over that is just that all serious protocols avoid higher loads.
With 1Mbps bitrate you will have roughly 25% load. Bear in mind you can not have a bus length more than 50m with 1Mbps.

[Andreas]

With 1Mbps bitrate you will have roughly 25% load.

You forget that it is bi-directional and there will be at least 2 message headers.
So in one direction about 70-80 us the other in 55-65 us. (depending on stuffing bits).
So together with the necessary idle time its roughly 100% bus load for 2 bus participants.

with best regards

Andreas

[matkar]

Can you tell us something more about your project?
Why such a fast update rate?
Are there some security reasons you need to address with it?

Eventually you can reduce the load with shortening the packets as much as possible. Use standard ID instead of extended, if you don't need all bits for address purposes you could use a portion of ID to put data in it...
For example if you know you will have only 8 devices on the bus, you could use higher 3 bits of the 11 bit standard CAN ID for device address and lower 8 bits to put one byte of data, supposing all packets look the same.

[mikeselectricstuff]

Why not RS485?

[mc]

The project is expanding IO on a CNC controller, as the current expansion board option has very limited cable length due to it using a parallel databus and I need quite a bit of IO on the opposite side of the machine from where the controller gets mounted. I'm probably looking at 3-4 metres of cable between the two points.
The update speed of the current board is 180uS, and I quite fancy the challenge of seeing if I can match/beat that, however in reality, 1kHz refresh rate will be more than enough. I'd need to run some calcs to check that though, as there are a couple time critical pulses that could possibly be missed if the refresh rate is too low.

Mike, I never thought about checking the speed of RS485. I'd only checked the usual Modbus standard speeds for RTU, and they're all sub 100kbps, however now I've checked, RS485 is probably a better option than CAN.

[matkar]

.... however now I've checked, RS485 is probably a better option than CAN.

If you are after reliability, CAN beats RS485 anytime.

[mikeselectricstuff]

.... however now I've checked, RS485 is probably a better option than CAN.

If you are after reliability, CAN beats RS485 anytime.

Without context, that is a nonsensical statement.

[mikeselectricstuff]

The project is expanding IO on a CNC controller, as the current expansion board option has very limited cable length due to it using a parallel databus and I need quite a bit of IO on the opposite side of the machine from where the controller gets mounted. I'm probably looking at 3-4 metres of cable between the two points.
The update speed of the current board is 180uS, and I quite fancy the challenge of seeing if I can match/beat that, however in reality, 1kHz refresh rate will be more than enough. I'd need to run some calcs to check that though, as there are a couple time critical pulses that could possibly be missed if the refresh rate is too low.

Mike, I never thought about checking the speed of RS485. I'd only checked the usual Modbus standard speeds for RTU, and they're all sub 100kbps, however now I've checked, RS485 is probably a better option than CAN.

Typically the first limit you hit is UART speed and/or ability to deal with data fast enough, which will generally be the case whatever the interface. 4mbits/sec over tens of metres is easily doable very cheaply and with negligible protocol effort.  For your application you probably don't even need anywhere near that high a rate.

[matkar]

Without context, that is a nonsensical statement.

I agree.
My claim is valid when looking at plain hardware specifications.
Now I feel like I'm explaining something all of you already know, but still:
-CAN has hardware bus collision and arbitration during sending. The packet with higher priority gets normally through in case of collision.
-Successful reception of the packet is conveyed back to the sender from all receivers when the sender is still sending the packet. Receivers don't need to confirm the reception separately.
In my opinion these are very powerful features. Once sent you don't need to worry if the packet made it to its destination.

On the other hand RS485 allows higher baudrates, so you can provide safety features in software to compensate for potential data losses.

[mikeselectricstuff]

Without context, that is a nonsensical statement.

I agree.
My claim is valid when looking at plain hardware specifications.
Now I feel like I'm explaining something all of you already know, but still:
-CAN has hardware bus collision and arbitration during sending. The packet with higher priority gets normally through in case of collision.
-Successful reception of the packet is conveyed back to the sender from all receivers when the sender is still sending the packet. Receivers don't need to confirm the reception separately.
In my opinion these are very powerful features. Once sent you don't need to worry if the packet made it to its destination.

On the other hand RS485 allows higher baudrates, so you can provide safety features in software to compensate for potential data losses.

I don't know much about CAN but I use 485 a lot. The one major functional difference is the lack of hardware collision detect, and in practice it can be very difficult to reliably detect and test, so the usual strategy is to design the protocol to not ever produce collisions in normal use. Either by having a master polling slaves individually, or by a timeslot system.
It's not ideal for systems where you need to have nodes randomly sending data with low latency -in this case CAN would probably be better.
Stuff like acknowledge, CRCs etc. can be added easily if needed.
Unless you need the specific featires of CAN, 485 is going to be simpler, easier & cheaper. e.g. the ability to use a standard serial monitor/analyser/terminal for debug, and have plenty of choice of off-the-shelf 485 to <pretty much anything> interfaces.
 

[fcb]

Why CAN? Is it an automotive application - what are your constraints that have made you consider CAN???

I recently ditched CAN bus on a VERY complex project I was working on in-favour of RS485 (half-duplex) and a custom protocol (which was the reason I considered CAN in the first place...)

[dgtl]

CAN is good when you need a shared bus with prioritized messages. As I understand, you are just going to send data to another chip (or broadcast some data to multiple chips); this does not benefit from using CAN, because this is not random-access traffic with different priorities. CAN can be difficult at high speeds and longer distances and it just adds complexity. (you may benefit a little from error detection and ACKing of the messages).
The easiest way would be just using two unidirectional RS422 (or whatever serial) links. Just send the state of the pins with some simple framing protocol to know what's what and that's it. One very simple way would be to send one framing bit and 7 data bits in one packet, for first packet set the framing bit high and for the rest set it low (1ddddddd 0ddddddd 0ddddddd 0ddddddd etc). Of course, there are many alternative options.
When you need guaranteed timing, fault-tolerance, error detection/correction etc it gets somewhat more complicated.
When using NXPs uC CAN controllers at high data rates, take care of getting data frame ordering correct. For both the CANB and CANC controllers it is easy to mess up the order of the frames when receiving or transmitting a lot of data with same can ID. On your case, you'll probably just transmit the one can ID one way and another the other way without FIFO's, so probably it is not a problem.

[Bassman59]

Why CAN? Is it an automotive application - what are your constraints that have made you consider CAN???

CAN is used on the high-end MIDAS live sound mixing consoles.

[fcb]

Why CAN? Is it an automotive application - what are your constraints that have made you consider CAN???

CAN is used on the high-end MIDAS live sound mixing consoles.

It is certainly used in applications outside of automotive (I first encountered it in about '95 used on an Austrian built system that was definitely not automotive).  My question was designed to get at the reasons WHY the OP wants to use CAN.

[mc]

As I breifly mentioned in my earlier reply to Mike, it was because I never bothered checking the speeds for the various serial standards.
Initially I had considered using Modbus in RTU (serial) form as interfacing to a PLC could be useful, but it's usually limited to 56kbps, which is no where near fast enough. I did briefly look at Modbus TCP (ethernet), which has more than enough speed, however it seemed overkill for what I'm trying to achieve, so my next thought was CAN bus. It's designed to be tolerant of external noise, but now having checked the speeds for the other differential serial options, RS485 with a custom protocol looks ideal.

I don't need multiple nodes on the same bus fighting to send a message, as there will always be a master, so even if I do go for multiple slaves, RS485 should have enough speed.

Anyway, thanks for the replies everyone.

[David Hess]

If I was going for reliability over a short distance with a point to point link, I would use full duplex RS-422 which neatly solves the collision issue.  If galvanic isolation is required, then I would use a full duplex current loop with optical isolation on each end similar to the old MIDI standard.  Either can achieve 10 Mbits/second or more easily and inexpensively.

Since there will be plenty of speed, sent data may be echoed for easy error detection.

Lack of collision issues allows deterministic updates if necessary.

[DavidMenting]

If you're still planning to go for CAN: the NXP LPC11C24 is a nice part (http://www.nxp.com/products/microcontrollers/cortex_m0_m0/lpc1100/LPC11C24FBD48.html)

It has a built in CAN controller and transceiver, so you can hook it up straight to the CAN connector without using an external transceiver IC.