#79,008 in Electronics
Use arrows to jump to the previous/next product

Reddit mentions of XCSOURCE 3pcs MCP2515 CAN Bus Module TJA1050 Receiver SPI for Arduino 51 MCU ARM Controller Development Board TE534

Sentiment score: 0
Reddit mentions: 2

We found 2 Reddit mentions of XCSOURCE 3pcs MCP2515 CAN Bus Module TJA1050 Receiver SPI for Arduino 51 MCU ARM Controller Development Board TE534. Here are the top ones.

XCSOURCE 3pcs MCP2515 CAN Bus Module TJA1050 Receiver SPI for Arduino 51 MCU ARM Controller Development Board TE534
Buying options
View on Amazon.com
or
Supports CAN V2.0B specification, the communication speed 1Mb/s.0 to 8-byte data field. With standard frame, expand the frame and remote frame.5V DC power supply module, SPI interface protocol control.120 ohm termination resistors. With impedance matching, ensures the drive capacity, long-distance data transmission against signal radiation.Working current: 5mA (1 microamp standby current. Except the power indicator).
Specs:

idea-bulb Interested in what Redditors like? Check out our Shuffle feature

Shuffle: random products popular on Reddit

Found 2 comments on XCSOURCE 3pcs MCP2515 CAN Bus Module TJA1050 Receiver SPI for Arduino 51 MCU ARM Controller Development Board TE534:

u/clee781 ยท 3 pointsr/FSAE

CAN is a very simple protocol. So simple, in fact, that it is basically useless on its own. CAN is a low-level data-link layer that allows you to send frames of eight bytes to a bus. If you want to send messages of more than eight bytes, you need to come up with a way to stitch multiple frames together. If you want node to node communication, you need to decide how each device is addressed and how transactions take place between them. CAN is at the bottom of the protocol stack. For anything useful to happen, you need to add a couple more layers on top of it. Some examples of these higher level protocols include CANopen, DeviceNet, and many others. As an example specific to automotive, ISO-15765-2 is a transport layer that is implemented using a CAN bus. This ISO standard defines how to combine multiple eight byte CAN frames into messages of up to 4095 bytes. Still, ISO-15765-2 is not so useful on its own either. On top of this transport layer sits ISO-15765-3 and ISO-15765-4, and then finally, we arrive at OBDII. Traversing the stack the other way, we can see that the high-level OBDII protocol can be implemented using many sub-protocols, not just ISO-15765. OBDII information can also be carried using SAEJ2284 CAN, UART, and some others.

​

If you want to learn to CAN, I wouldn't recommend starting with literature. You should decide what your goal is first. Do you want to be able to talk to your ECU which is already speaking in some higher level protocol? Do you want to build some custom sensors where you get to decide how the protocol stack looks? Do you want to buy a bunch of ready-to-go CANopen slaves and just implement a master to control those? I would make a couple decisions about what you are trying to accomplish first, then you can take it step by step and visit the specific piece of literature that will help you clear whatever the next hurdle is.

​

In any case, you may want to play around with some hardware just to familiarize yourself with the protocol. If you ever thought about buying this CAN Arduino Shield, don't. Just buy a bunch of these MCP2515 Breakouts that use the exact same hardware and are much cheaper. Hook them up a couple Arduinos and use the MCP2515 library to send some frames back and forth. Once thats done, take those Arduinos and put them into the garbage. Buy a bunch of $2 STM32F103C8T6 Blue pills, a bunch of $2 ST-Link V2 knockoff debuggers, some TJA1050 CAN transceivers, and have an MCU with a built in CAN peripheral that is a magnitude more powerful than an Arduino UNO for a fraction of the cost. Download System Workbench or Atollic TrueStudio and you can open hundreds of example projects and step through the code line by line as it runs in real time on the microcontroller. You can program these blue pills through the Arduino IDE also, but I really encourage serious engineers to move away from the Arduino ecosystem.

u/XirallicBolts ยท 2 pointsr/Justrolledintotheshop

shits and giggles: now trying to create my own Sync 3 'lockpick' to allow me to view the front camera while driving. It'd theoretically also allow shenanigans like 'view a side camera when the turn signal is on'.

a couple super-cheap canbus modules connected between the car and the radio. instead of just spamming 'Reverse' signals (man on the side attack), it'll actually intercept the messages and replace them with Reverse signals (man in the middle attack).

I'll have to wire it in tomorrow, but the test code I have so far is


// CAN_VEH: canbus module on VEHICLE side
// CAN_APIM: canbus module on RADIO side

if(!digitalRead(CAN_VEH_INT))
{
CAN_VEH.readMsgBuf(&message_ID, &message_LENGTH, message_DATA);
if(message_ID == 0x109 and message_DATA[2] == 0x41)
{
Serial.println("Car in S, replacing message to APIM");
message_DATA[0] = 0x09; // RPM is low
message_DATA[1] = 0xE3; // RPM is low
message_DATA[2] = 0x11; // Gear is REVERSE
message_DATA[4] = 0x00; // Speed is low
message_DATA[5] = 0x2E; // Speed is low
}
CAN_APIM.sendMsgBuf(message_ID, 0, message_LENGTH, message_DATA);
}

// Forward all messages coming FROM APIM back to the car

if(!digitalRead(CAN_APIM_INT))
{
CAN_APIM.readMsgBuf(&message_ID, &message_LENGTH, message_DATA);
CAN_VEH.sendMsgBuf(&message_ID, 0, &message_LENGTH, message_DATA);
}
}