Electronic – Using an MCU with built-in CAN controller vs. external CAN controller

armcancortex-mmicrochip

I'm planning to use the Atmel ATSAMC21J18A microcontroller in an automation project which has a built-in CAN controller. The CAN bus network may contain 32 devices, each generating data packets in 1 second intervals. There will be 16 such CAN bus networks connected to a single gateway node which has an NXP LPC1768 MCU (Cortex M3).

  1. What are the factors and parameters that should be considered when deciding whether to use the built-in CAN controller or an external CAN controller?
  2. Are there any pros/cons/constraints while using the built-in CAN controller?
  3. Since the CAN gateway node will be handling traffic from all 16 networks, would it be a good idea to use an external CAN controller to avoid buffer overflows?

Note that I'm anyway planning to use an external isolated CAN transceiver.

Best Answer

  1. An external CAN controller is similar to the internal CAN controller, but connected over a slower bus (higher latency, slower bit rate). There is no reason to use an external when you have a capable CAN controller on-chip (SAM C21):

    • Support for CAN-FD
    • Up to 64 dedicated receive buffers and up to 32 dedicated transmit buffers
    • Direct Message RAM access for the CPU
  2. With some chips, using the CAN peripherals reserves a chunk of SRAM. But there isn't a real downside to using an on-chip variant. Only maybe when you need more than two controllers it would make sense, for software design point of view, to get many external controllers. But you'll have extra latency since the frames will not be memory mapped. Direct memory access is a big advantage of on-chip CAN with 32 bit controllers.

  3. If your gateway has to connect to 16 independent CAN buses, yes. Otherwise, if it's only one bus, no. The LPC1768 should have plenty of memory. Looking at your story you'll be having an average of 512 messages per second. Which is achievable at 100 kbit/s.

The only catch in this is that you can't have two identical IDs within a short period, else there will be an overrun in the messagebox. But the higher level protocol you're using should already have rules regarding the minimum time between two frames of the same ID.

The only thing to look for in on-chip controller is the hardware FIFO. If you only have a three-deep hardware FIFO, as on most STM32 controllers, you can overrun the buffer with a short burst of frames with too much interrupt latency. You'll have to add an additional software FIFO on top.

If the gateway is to connect to a PC, please don't reinvent the wheel. Get something from Kvaser or IXXAT.