CAN Shield Issue


I am using a v1.0 CAN SHIELD attached to a UNO R3

using IDE 1.0.5, I have uploaded the receive_check program which compiles and uploads correctly. I don’t have any other device to read the CAN off at this stage (long story which ill probably post in a separate thread).

When i try to upload the send program however, it will not compile. Nor will it compile in v1.0 of the IDE either.

The same message appears in both

// demo: CAN-BUS Shield, send data
#include <mcp_can.h>
#include <SPI.h>

MCP_CAN CAN(10); // Set CS to pin 10

void setup()


if(CAN_OK == CAN.begin(CAN_500KBPS))                   // init can bus : baudrate = 500k
    Serial.println("CAN BUS Shield init ok!");
    Serial.println("CAN BUS Shield init fail");
    Serial.println("Init CAN BUS Shield again");
    goto START_INIT;


unsigned char stmp[8] = {0, 1, 2, 3, 4, 5, 6, 7};
void loop()
// send data: id = 0x00, standrad flame, data len = 8, stmp: data buf
CAN.sendMsgBuf(0x00, 0, 8, stmp);
delay(100); // send data per 100ms"

The error I get is this:

send.cpp: In function ‘void loop()’:
send:29: error: no matching function for call to ‘MCP_CAN::sendMsgBuf(int, int, int, unsigned char [8])’
/Users/MH/Documents/Arduino/libraries/CAN_BUS_Shield_master/mcp_can.h:102: note: candidates are: byte MCP_CAN::sendMsgBuf(long unsigned int, byte, byte, byte, byte*)

Now I’m new to Arduino & programming, but am I right in thinking the IDE is telling me that function sendMsgBuf, needs to have five elements rather than the usual four for a can signal?

In testing this, the sketch compiles if I add an additional digit, for example:

CAN.sendMsgBuf(0x00, 0, 8, 0, stmp);

This then uploads fine, but the TX & RX red lights are on solid, and the serial monitor doesn’t display anything apart from INIT OK, although i guess thats expected as nothing is telling stmp to print to serial.

Could anyone help with why the TX & RX lights are on solid, and how I could test that this board is actually outputting any signals once per second, back to the serial monitor?


It looks like someone tried implementing remote request frames and that got merged into the library… … a9b22b0ca2

As for the LEDs, that is probably because you do not have two active CAN nodes, just one, which means that the protocol controller is trying to send that message and there is no other node to acknowledge that it was sent so the controller retransmits it again, and again waiting for the acknowledge. If you take the bit rate down to 5KBPS, there might be some noticeable flashing.