MCP_CAN CAN(SPI_CS_PIN);does it actually have a CAN interface? not having one could quite possibly freeze/hang the sketch
could we see the whole sketch?
stephen
I know someone was investigating how to get around the problem of shared resources, but I don’t think they ever posted a solution
See this thread
I know someone was investigating how to get around the problem of shared resources, but I don’t think they ever posted a solution
See this thread
The sketch:
/ demo: CAN-BUS Shield, receive data with interrupt mode
// when in interrupt mode, the data coming can't be too fast, must >20ms, or else you can use check mode
// loovee, 2014-6-13
#include <SPI.h>
#include "mcp_can.h"
// the cs pin of the version after v1.1 is default to D9
// v0.9b and v1.0 is default D10
const byte SPI_CS_PIN = 31;
// Set CS pin
SPIClass SPI_3(2);
unsigned char flagRecv = 0;
unsigned char len = 0;
unsigned char buf[8];
char str[20];
void setup()
{
Serial.begin(115200);
pinMode(33, OUTPUT);
digitalWrite(33, HIGH);
delay(25000);
digitalWrite(33, LOW);
delay(1000);
digitalWrite(33, HIGH);
MCP_CAN CAN(SPI_CS_PIN);
START_INIT:
if (CAN_OK == CAN.begin(CAN_500KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init ok!");
}
else
{
Serial.println("CAN BUS Shield init fail");
Serial.println("Init CAN BUS Shield again");
delay(100);
goto START_INIT;
}
attachInterrupt(0, MCP2515_ISR, FALLING); // start interrupt
}
void MCP2515_ISR()
{
flagRecv = 1;
}
void loop()
{
MCP_CAN CAN(SPI_CS_PIN);
INT8U ret;
digitalWrite(SPI_CS_PIN, LOW);
SPI_3.transfer(0x02);
SPI_3.transfer(0x0D);
SPI_3.transfer(0x00);
digitalWrite(SPI_CS_PIN, HIGH);
delay(100);
for (int i = 0; i < 150; i++) {
digitalWrite(SPI_CS_PIN, LOW);
SPI_3.transfer(0x03);
SPI_3.transfer(i);
ret = SPI_3.transfer(0x00);
digitalWrite(SPI_CS_PIN, HIGH);
Serial.print(i, HEX);
Serial.print(" ");
Serial.println(ret, BIN);
delay(100);
}
if (flagRecv)
{ // check if get data
flagRecv = 0; // clear flag
// iterate over all pending messages
// If either the bus is saturated or the MCU is busy,
// both RX buffers may be in use and reading a single
// message does not clear the IRQ conditon.
while (CAN_MSGAVAIL == CAN.checkReceive())
{
// read data, len: data length, buf: data buf
CAN.readMsgBuf(&len, buf);
// print the data
for (int i = 0; i < len; i++)
{
Serial.print(buf[i]); Serial.print("\t");
}
Serial.println();
}
}
}
/*********************************************************************************************************
END FILE
*********************************************************************************************************/
<…>
i’ve just order a pair of can modules:-)
stephen
i’ve just order a pair of can modules:-)
stephen
The sketch:
/ demo: CAN-BUS Shield, receive data with interrupt mode
// when in interrupt mode, the data coming can't be too fast, must >20ms, or else you can use check mode
// loovee, 2014-6-13
#include <SPI.h>
#include "mcp_can.h"
// the cs pin of the version after v1.1 is default to D9
// v0.9b and v1.0 is default D10
const byte SPI_CS_PIN = 31;
// Set CS pin
SPIClass SPI_3(2);
unsigned char flagRecv = 0;
unsigned char len = 0;
unsigned char buf[8];
char str[20];
void setup()
{
Serial.begin(115200);
pinMode(33, OUTPUT);
digitalWrite(33, HIGH);
delay(25000);
digitalWrite(33, LOW);
delay(1000);
digitalWrite(33, HIGH);
MCP_CAN CAN(SPI_CS_PIN);
START_INIT:
if (CAN_OK == CAN.begin(CAN_500KBPS)) // init can bus : baudrate = 500k
{
Serial.println("CAN BUS Shield init ok!");
}
else
{
Serial.println("CAN BUS Shield init fail");
Serial.println("Init CAN BUS Shield again");
delay(100);
goto START_INIT;
}
attachInterrupt(0, MCP2515_ISR, FALLING); // start interrupt
}
void MCP2515_ISR()
{
flagRecv = 1;
}
void loop()
{
MCP_CAN CAN(SPI_CS_PIN);
INT8U ret;
digitalWrite(SPI_CS_PIN, LOW);
SPI_3.transfer(0x02);
SPI_3.transfer(0x0D);
SPI_3.transfer(0x00);
digitalWrite(SPI_CS_PIN, HIGH);
delay(100);
for (int i = 0; i < 150; i++) {
digitalWrite(SPI_CS_PIN, LOW);
SPI_3.transfer(0x03);
SPI_3.transfer(i);
ret = SPI_3.transfer(0x00);
digitalWrite(SPI_CS_PIN, HIGH);
Serial.print(i, HEX);
Serial.print(" ");
Serial.println(ret, BIN);
delay(100);
}
if (flagRecv)
{ // check if get data
flagRecv = 0; // clear flag
// iterate over all pending messages
// If either the bus is saturated or the MCU is busy,
// both RX buffers may be in use and reading a single
// message does not clear the IRQ conditon.
while (CAN_MSGAVAIL == CAN.checkReceive())
{
// read data, len: data length, buf: data buf
CAN.readMsgBuf(&len, buf);
// print the data
for (int i = 0; i < len; i++)
{
Serial.print(buf[i]); Serial.print("\t");
}
Serial.println();
}
}
}
/*********************************************************************************************************
END FILE
*********************************************************************************************************/
i’ve just order a pair of can modules:-)
stephen
Your library probably tries to do something with the IO pins (CS I guess) during declaration.
There are a few threads about that, but basically what happens is that your object constructor is running before the IO initialization stuff. So after your objects set this or that in the IO port, the libmaple IO initialization routine runs and reset all the ports settings.
Move any IO Pin operation outside the constructor, or you will have to do the Pin IO setup twice.
Try to do like the LCD libraries. They declare the object outside of setup or loop, but do not do any PIN setup until tft.begin() is called inside loop. At that point the libmaple init routine has already run and will not reset the IO settings.
Your library probably tries to do something with the IO pins (CS I guess) during declaration.
There are a few threads about that, but basically what happens is that your object constructor is running before the IO initialization stuff. So after your objects set this or that in the IO port, the libmaple IO initialization routine runs and reset all the ports settings.
Move any IO Pin operation outside the constructor, or you will have to do the Pin IO setup twice.
Try to do like the LCD libraries. They declare the object outside of setup or loop, but do not do any PIN setup until tft.begin() is called inside loop. At that point the libmaple init routine has already run and will not reset the IO settings.