Arduino UNO R4 CAN Bus Guide: Transceivers, Wiring and ArduinoCAN

The Arduino UNO R4 WiFi and UNO R4 Minima both contain a hardware CAN controller inside the Renesas RA4M1. That is a major improvement over the classic UNO R3, which normally needed an external CAN controller such as the MCP2515 as well as a CAN transceiver.

On the R4, the controller is already inside the MCU. You still need one important external component: a CAN transceiver.

The complete signal path is:

This guide explains the correct pins for both UNO R4 boards, suitable transceivers, bus wiring, termination, the built-in Arduino_CAN library, sending and receiving frames, standard and extended identifiers, common bit rates and the faults that usually stop a new CAN network from working.

UNO R4 CAN Bus at a Glance

Feature	UNO R4 Support
CAN controller	Built into Renesas RA4M1
CAN standard	CAN 2.0A / CAN 2.0B
Classic CAN	Yes
CAN-FD	No
Standard IDs	11-bit
Extended IDs	29-bit
Maximum payload	8 bytes per classic CAN data frame
External CAN controller needed	No
External CAN transceiver needed	Yes
Official Arduino library	Arduino_CAN.h
Official preset bit rates	125, 250, 500 and 1000 kbit/s
UNO R4 WiFi CAN pins	D10 CANTX, D13 CANRX
UNO R4 Minima CAN pins	D4 CANTX, D5 CANRX

Important: UNO R4 WiFi and Minima Use Different CAN Pins

This is one of the easiest details to get wrong.

UNO R4 WiFi

Arduino pin	CAN function
D10	CANTX
D13	CANRX

UNO R4 Minima

Arduino pin	CAN function
D4	CANTX
D5	CANRX

The current Arduino Renesas core confirms the Minima mapping as D4 for CAN TX and D5 for CAN RX, while current UNO R4 WiFi documentation maps CAN TX to D10 and CAN RX to D13.

Do not copy a wiring diagram for one R4 model directly onto the other.

Why You Still Need a CAN Transceiver

The RA4M1 contains the digital CAN protocol controller, but it does not directly generate the differential electrical signals used on the physical bus.

CANTX and CANRX are logic-level signals.

A transceiver converts:

Without a transceiver, two UNO R4 boards cannot communicate over a normal CANH/CANL bus.

Suitable CAN Transceivers

For a straightforward 5 V UNO R4 system, common choices include:

• MCP2562 — modern CAN transceiver with separate VIO pin; useful when you want explicit logic-level control.
• TJA1051 family — modern high-speed CAN transceivers, with exact logic-voltage behaviour depending on variant.
• TJA1050 — older but common 5 V high-speed CAN transceiver.
• MCP2551 — older 5 V CAN transceiver found on many modules.

The most important requirement is not the brand. It is that the transceiver’s logic-side voltage and input tolerances are compatible with the UNO R4’s 5 V GPIO.

Do not assume that every 3.3 V CAN module is safe with a 5 V MCU input/output.

Avoid Blindly Using SN65HVD230 Modules

The SN65HVD230 is a popular 3.3 V CAN transceiver and appears on many cheap development boards.

It is a good match for 3.3 V MCUs such as ESP32, but the UNO R4 uses 5 V logic.

If a module is built around a 3.3 V-only transceiver, check its TXD/RXD voltage limits before connecting it directly to R4 GPIO.

For the simplest R4 design, use a transceiver intended for 5 V logic or a device with a dedicated VIO pin configured appropriately.

MCP2562 Example

A useful modern arrangement is an MCP2562-class transceiver with:

• VDD connected to 5 V;
• VIO connected to the required MCU logic voltage;
• TXD connected to UNO CANTX;
• RXD connected to UNO CANRX;
• CANH and CANL connected to the bus;
• common ground connected to the UNO ground.

For UNO R4’s 5 V logic, VIO would normally also be tied to 5 V.

Basic UNO R4 WiFi CAN Wiring

For UNO R4 WiFi:

Basic UNO R4 Minima CAN Wiring

For UNO R4 Minima:

Two-Node Test Network

The simplest useful test is two CAN nodes:

Add one 120 Ω termination resistor at each physical end of the bus.

CAN Bus Termination

A normal high-speed CAN bus uses 120 Ω at each end of the trunk.

The two 120 Ω resistors appear electrically in parallel when the system is powered off.

So if you measure resistance directly between CANH and CANL on a correctly terminated two-end bus, you should normally see approximately:

This is one of the fastest diagnostic checks you can perform.

Do Not Put 120 Ω on Every Node

Termination belongs at the two physical ends of the bus, not on every ECU or Arduino.

For example, a four-node bus should look like:

If every node has its own 120 Ω resistor, the bus becomes heavily over-terminated and communication can fail.

Bus Topology

CAN is designed around a linear trunk with short stubs.

Good:

Less desirable:

A large star creates reflections and becomes increasingly problematic as bus speed and cable length rise.

Use Twisted Pair

CANH and CANL should run as a twisted pair.

Twisting helps external noise affect both conductors similarly, allowing the differential receiver to reject much of it.

For short bench tests, almost any neat wiring may appear to work. For longer cables or noisy environments, use proper twisted-pair cable.

Connect Ground as Well

CAN is differential, but the transceivers still have a permitted common-mode voltage range.

For a simple non-isolated test bench, connect the grounds of the CAN nodes together.

For long industrial systems with ground-potential differences, consider isolated CAN transceivers rather than simply forcing remote grounds together.

Classic CAN, Not CAN-FD

The RA4M1 CAN peripheral on UNO R4 supports CAN 2.0A and CAN 2.0B.

That means:

• 11-bit standard identifiers;
• 29-bit extended identifiers;
• up to 8 data bytes per frame;
• classical CAN bit rates up to 1 Mbit/s.

It does not turn the UNO R4 into a CAN-FD controller.

A CAN-FD-capable transceiver can often carry classic CAN signalling, but the R4 controller itself still sends classic CAN frames.

Installing Arduino_CAN

The current UNO R4 board package includes the Arduino_CAN library.

Your sketch begins with:

No MCP2515 library is required because the CAN controller is inside the RA4M1.

Starting the CAN Controller

The standard preset rates are:

For example:

Every node on the same CAN network must use the same nominal bit rate.

Common CAN Bit Rates

Bit rate	Typical use
125 kbit/s	Longer industrial/vehicle buses, lower data rate
250 kbit/s	Common industrial and vehicle networks
500 kbit/s	Very common automotive and robotics rate
1 Mbit/s	Shorter high-speed classic CAN networks

You cannot simply choose a faster rate on one node. The bit timing has to match the existing bus.

Basic CAN Transmit Example

The following sketch transmits an 8-byte standard-ID frame every second:

Why CAN.write() Can Fail on a One-Node Bus

Normal CAN transmission expects another active node to acknowledge a valid frame.

If your UNO is the only powered CAN controller on the network, it may repeatedly fail to receive an ACK.

So this setup:

The library’s CanMsg object contains the identifier, payload length and data bytes.

Reading the Message ID and Data

You can inspect received frames directly:

Standard CAN IDs

Classic CAN standard frames use an 11-bit identifier.

The valid range is:

Create one using:

The identifier is not a destination address in the Ethernet sense.

It describes the priority and meaning of the message.

Extended CAN IDs

CAN 2.0B also supports 29-bit extended identifiers:

A current CanMsg can be built using:

Extended frames are common in protocols such as J1939.

CAN Arbitration

CAN is a multi-master bus.

Several nodes can begin transmitting at approximately the same time without corrupting the network.

The lower numerical identifier wins arbitration because dominant bits override recessive bits.

So:

has higher arbitration priority than:

This is why CAN IDs should be designed as part of the communication architecture rather than assigned randomly.

Maximum Payload Is 8 Bytes

Classic CAN frames carry up to eight payload bytes.

This is enough for many sensor and control messages but not for large data blocks.

If you need to send a larger structure, split it across several messages or implement a higher-level transport protocol.

For example:

Design the Payload Explicitly

Do not transmit a C structure blindly unless both ends explicitly agree on:

• byte order;
• type width;
• alignment;
• scaling;
• signedness.

A robust CAN protocol often defines values manually.

For example:

Using CAN for Automotive Projects

UNO R4 is attractive for automotive experiments because the controller is built in.

Possible projects include:

• instrument displays;
• data loggers;
• bench ECU communication;
• CAN gateways;
• custom dashboards;
• motorcycle instrumentation;
• diagnostic tools.

However, a vehicle CAN network is not a harmless logic bus.

Production automotive electrical systems can contain:

• load-dump transients;
• ESD;
• reverse battery conditions;
• ground offsets;
• electrical noise.

A bare hobby transceiver board is not equivalent to a properly protected automotive interface.

Use Protection in Vehicle Installations

For a permanent automotive design, consider:

• automotive-qualified CAN transceiver;
• TVS protection;
• proper input power protection;
• reverse-polarity protection;
• fusing;
• common-mode choke where appropriate;
• EMC-conscious PCB layout;
• galvanic isolation when required by the application.

Industrial CAN

The same principle applies in industrial environments.

Long cables, large motors, inverters and separate power cabinets can create significant common-mode and surge problems.

For laboratory development, a basic non-isolated transceiver is fine.

For installed equipment, consider isolated CAN if ground-potential differences are possible.

UNO R4 as a CAN-to-Wi-Fi Gateway

UNO R4 WiFi is particularly interesting because the RA4M1 can handle CAN while the onboard ESP32-S3 handles Wi-Fi.

A gateway could:

This is useful for:

• remote machine monitoring;
• vehicle telemetry;
• robotics;
• industrial dashboards;
• CAN sensor gateways.

If you are choosing between R4 and native ESP32 hardware for this kind of job, see our UNO R4 WiFi vs ESP32-S3 DevKitC comparison and UNO R4 WiFi vs ESP32-C6 comparison.

UNO R4 WiFi CAN Pin Conflict with SPI

On UNO R4 WiFi, the CAN pins overlap with standard SPI pins:

This means you cannot blindly use the same pins for normal SPI and CAN simultaneously.

If your shield assumes D10 and D13 are available for SPI, check the design before enabling CAN.

This overlap is one reason the exact board pinout matters.

UNO R4 Minima CAN Pin Conflict

On Minima:

D5 is also one of the familiar PWM-capable Arduino pins.

Once CAN owns those pins, treat them as dedicated CAN logic signals rather than general-purpose outputs.

Troubleshooting: CAN.begin() Fails

If CAN.begin() returns false:

• confirm you selected the correct UNO R4 board;
• update the Arduino UNO R4 board package;
• use a supported bit rate;
• check that another library has not claimed the same peripheral resources;
• restart after changing board/core versions.

Troubleshooting: Frames Send but Nothing Is Received

Check these in order:

1. Both nodes use exactly the same bit rate.
2. CANH connects to CANH.
3. CANL connects to CANL.
4. Node grounds have a valid common reference for a non-isolated bus.
5. The correct CAN TX/RX pins are being used for your R4 model.
6. The transceiver supply and logic voltage are correct.
7. The bus has proper termination.
8. At least two active CAN nodes are present.

Troubleshooting: Measure 60 Ω First

Turn the system off and measure resistance between CANH and CANL.

Typical results:

Measured resistance	Likely interpretation
~60 Ω	Two 120 Ω terminators present
~120 Ω	Only one terminator present
~40 Ω	Three 120 Ω terminators present
Very low resistance	Short or severe over-termination
Open circuit / very high	No termination or broken wiring

This test catches a surprising number of CAN problems immediately.

Troubleshooting: Reversed CANH and CANL

If CANH and CANL are swapped, communication normally fails completely.

Do not rely on wire colour alone. Trace or measure the actual connections.

Troubleshooting: Wrong Bit Rate

A 500 kbit/s node cannot decode a 250 kbit/s bus.

When connecting to an existing vehicle or machine, first determine its actual bit rate.

Do not guess based only on the connector type.

Troubleshooting: No ACK

CAN requires another active controller to acknowledge a valid transmitted frame.

If there is only one active node:

• the frame is not acknowledged;
• the controller retries;
• error counters can increase;
• the application may report a write error.

Add a second active node or use a CAN analyser during testing.

Troubleshooting: A Cheap Module Has a Termination Jumper

Many CAN transceiver modules include a permanent or jumper-selectable 120 Ω resistor.

If you connect several such modules and leave every terminator enabled, the network can become over-terminated.

Inspect the module rather than assuming the resistor is absent.

Using a USB CAN Analyser

A USB CAN analyser is extremely useful when developing a new R4 CAN application.

It lets you:

• verify the bit rate;
• see transmitted IDs;
• inspect payloads;
• send test frames;
• confirm that the Arduino is actually reaching the bus.

For debugging, one UNO R4 plus one known-good CAN analyser is often easier than debugging two new Arduino nodes simultaneously.

Internal Loopback Testing

The current Renesas CAN implementation contains internal loopback support.

This can be useful for testing the CAN controller and software without a complete external bus.

Loopback confirms that:

• the CAN peripheral starts;
• message creation works;
• transmit and receive logic works internally.

It does not prove that:

• your transceiver is wired correctly;
• CANH/CANL are correct;
• termination is correct;
• the external network can communicate.

Standard vs Extended IDs

Use standard 11-bit IDs unless the protocol you are implementing requires extended IDs.

Standard identifiers provide:

• shorter arbitration field;
• slightly lower bus overhead;
• simple debugging;
• compatibility with many conventional control networks.

Extended identifiers are useful for protocols that encode more information into the identifier itself.

CAN Bus Load

A CAN network should not be designed to run permanently at 100% utilisation.

Every frame consumes more bus time than just its payload because it also includes:

• identifier;
• control bits;
• CRC;
• ACK;
• inter-frame spacing;
• bit stuffing.

If many nodes transmit continuously, arbitration delays become significant.

Send messages at a rate that matches how quickly the information actually changes.

Example Message Rates

A practical machine might use:

There is little value in broadcasting a slowly changing temperature 1000 times per second.

Use a Message Counter

For important cyclic frames, include a rolling counter in the payload.

This lets the receiver detect:

• missed frames;
• stale data;
• unexpected resets;
• duplicated application data.

A simple 4-bit or 8-bit counter is often enough.

Add Timeouts at the Application Layer

CAN itself does not guarantee that a particular application message continues arriving forever.

A control system should detect missing messages.

For example:

This is especially important in robotics and machine control.

Arduino_CAN vs MCP2515 Libraries

Do not install an MCP2515 CAN library for the R4’s built-in CAN controller.

They solve different hardware architectures.

UNO R4 Built-In CAN

MCP2515 Module

An MCP2515 still works as an external CAN solution if you deliberately want another CAN controller, but it is unnecessary for the R4’s primary CAN channel.

Does UNO R4 Support CAN-FD?

No.

The RA4M1 CAN peripheral is a classic CAN 2.0 controller.

If your application requires:

• CAN-FD data phase;
• payloads larger than 8 bytes;
• CAN-FD bit-rate switching;

you need different controller hardware.

Do not confuse a CAN-FD-capable transceiver with a CAN-FD-capable controller. Both parts of the system must support FD for a true CAN-FD node.

When UNO R4 CAN Is a Good Fit

UNO R4 CAN is particularly useful for:

• automotive experiments;
• motorcycle instrumentation;
• robot motor networks;
• industrial sensor nodes;
• CAN data loggers;
• CAN-to-Wi-Fi gateways;
• machine-control prototypes;
• education around CAN arbitration and messaging.

Final Thoughts

The UNO R4 makes CAN dramatically easier than it was on the classic UNO R3 because the Renesas RA4M1 already contains the CAN 2.0A/2.0B controller.

You do not need an MCP2515 for the main CAN channel. You only need a suitable physical-layer transceiver, correct wiring and proper bus termination.

The most important board-specific detail is the pin mapping:

From there, the recipe is straightforward:

1. choose a 5 V-compatible CAN transceiver;
2. connect TX, RX, ground, CANH and CANL correctly;
3. terminate only the two physical ends of the bus with 120 Ω;
4. use twisted pair for CANH/CANL;
5. set every node to the same bit rate;
6. initialise Arduino_CAN;
7. send and receive CanMsg frames.

For quick troubleshooting, power the bus off and measure between CANH and CANL. Approximately 60 Ω is the classic indication that both end terminators are present.

With the physical layer correct, the UNO R4 is a very capable classic-CAN platform for automotive, robotics and industrial prototypes.