project:
i want to install another gauge cluster in my car. due to some can bus messages comming from the cluster causing the cars transmission control unit to go into emergency mode, and also the fact, that several messages (speed, tachometer, water temp, nearly all warning indicators are based on different can bus messages, i decided to go for 2x separate can bus and "translate" the datas from CAN0 and send them to CAN1. so my thought.
the picture differs a bid cause i´m not using the MCP2515.
i have also an arduino uno with can bus shield, using to send can bus messages.
my code (based on Can-SendingTest sample code): //Reads all traffic on CAN0 and forwards it to CAN1 (and in the reverse direction) but modifies some frames first.
// Required libraries #include "variant.h" #include <due_can.h>
//Leave defined if you use native port, comment if using programming port #define Serial SerialUSB
void setup()
{
Serial.begin(115200);
// Initialize CAN0 and CAN1, Set the proper baud rates here
Can0.begin(CAN_BPS_500K);
Can1.begin(CAN_BPS_500K);
if (Can0.available() > 0) {
Can0.read(incoming);
Can1.sendFrame(outgoing);
}
}
problem:
when there is a code reading on CAN0 it should trigger CAN1 to send the "outgoing CAN_frame), but it did not.
if i change "Can1.sendFrame(outgoing);" to "Can1.sendFrame(incoming);", it send the can message from CAN0 to CAN1.
so there is an error in my section with the outgoing frame.
here is the modified code: //Reads all traffic on CAN0 and forwards it to CAN1 (and in the reverse direction) but modifies some frames first.
// Required libraries #include "variant.h" #include <due_can.h>
//Leave defined if you use native port, comment if using programming port #define Serial SerialUSB
void setup()
{
Serial.begin(115200);
// Initialize CAN0 and CAN1, Set the proper baud rates here
Can0.begin(CAN_BPS_500K);
Can1.begin(CAN_BPS_500K);
currently testing a bid, using my arduino uno with can bus shield for sniffing and trying to just send can bus messages through my arduino DUE.
turns out, that there is difference between these librarys which are for arduino uno #include <Canbus.h> #include <defaults.h> #include <global.h> #include <mcp2515.h> #include <mcp2515_defs.h>
and the librarys which is for arduino DUE...
#include "variant.h" #include <due_can.h>
... in view to writing the can bus message. while writing this message.id = 0x60D; //formatted in HEX
message.header.rtr = 0;
message.header.length = 8; //formatted in DEC
message.data[0] = 00;
message.data[1] = 0x66;
message.data[2] = 00;
message.data[3] = 00;
message.data[4] = 00;
message.data[5] = 00;
message.data[6] = 00;
message.data[7] = 00;
for arduino uno, it sends directly the message i want...
ardunio Due library with this message...
outgoing.id = 0x60D;
outgoing.extended = false;
outgoing.priority = 4; //0-15 lower is higher priority
outgoing.data.byte[0] = 00;
outgoing.data.byte[1] = 0x66;
outgoing.data.byte[2] = 00;
outgoing.data.byte[3] = 00;
outgoing.data.byte[4] = 00;
outgoing.data.byte[5] = 00;
outgoing.data.byte[6] = 00;
outgoing.data.byte[7] = 00;
did send an empty can bus message.
once adding outgoing.data.high = 0xDEADBEEF; it throws out this can bus message on the serial monitor...
ID: 60D, Data: 80 66 0 0 EF BE AD DE
so... what i see is that the DEADBEAF comment throws out the reverse readed bits 5, 6, 7 and 8, which are "EF BE AD DE".
so i googled it and try to understand what "hexspeak" is and what its used for, but i don´t understand to be honest.
another point is, that is throws out "80" instead of "00" for the first bit.
if there is someone who could explain me this, it would be awesome.
the first byte seams to have 128 decimal and output this as hex 80. if i write
" outgoing.data.byte[0] = 11;" for example, it throws out hex 8B, which is in decimal 139.
so 139-11=128
thanks. i will read how to add the code correctly.
i solved the problem now. unbelievable stupid mistake
there was an error in the sample sketch of the arduino uno spark fun library, for reading codes..., called CAN_Read_Demo.
someone forgot to let space between data lenght and first byte. so the showed "80" which i read as 80 for the first byte, but in fact it was "8" byte lenght and "0" for first byte. testing the "11" decimal on first byte did not causes to display "8B" (which would be 139), but "B", which is 11 in decimal. so 80 which is 128decimal and 8B which is 139decimal (=128-11), was just a stupid coincidence. found out the problem once send the 11 as 0x11, which caused to display "811" in serial monitor, which brought me the idea of this stpid mistake.
