Using the teensy on can bus

Status
Not open for further replies.
I do small projects for the automotive market but one thing that is certain is that soon somebody will want me to interface with a can bus. I understand the basics of how can bus works but setting up can bus hardware on a chip seems quite complex and a higher level environment would be very welcome. How much support for can bus is there on the teensy environment?
 
What do you mean by transceiver chip? Do you mean the driver chip? So basically does the can work fully if a transceiver (line driver) chip is put between the microcontroller and the can bus. What sort of libraries are there. The one you linked to seems to be different from can? Or is this just a different library to do the same job on can bus. I only ask because it is called Flex can and I know there is a similar bust technology called Flex Ray so I'm just wondering if we are talking about the same technology here.
 
that library is to use the built in can controller on the teensy which can receive but not transmit without an additional transceiver chip. if your looking to monitor only the car's canbus traffic you dont need the transceiver chip
 
I just got the MCP2562 transceiver working with the CAN hardware on the Teensy 3.2. I have not hooked it up to a car yet, but plan on it soon. It is really easy, just make sure to read the Flexcan library documentation on Github by Collin80 (here: https://github.com/collin80/FlexCAN_Library). The previous Flexcan library handles things slightly differently.
 
I just got the MCP2562 transceiver working with the CAN hardware on the Teensy 3.2. I have not hooked it up to a car yet, but plan on it soon. It is really easy, just make sure to read the Flexcan library documentation on Github by Collin80 (here: https://github.com/collin80/FlexCAN_Library). The previous Flexcan library handles things slightly differently.

The MCP2562 is a chip that does the lvel shifting ect to allow the can protocol controller to receive and send messages on the physical bus, I can't see how you can receive without one.
 
you can receive without a transceiver. i did it with a teensy on a car logging the network.
i also did it with teensy 3.5 with no transceiver and a mega2560 with canbus shield sending data over a single link no issue. your not writing to the cars network your reading it and you DONT need a transceiver to see the data. i doubt you tested it though considering your only 3 posts, anyways, i did and it works.
 
Last edited:
its not that, its just on a canbus per vehicle standards your not the one to acknowledge the receipt of a packet thats meant for the other devices, for your own canbus network, its okay, but a transceiver is not needed for monitoring only, especially if packets are not for it to acknowledge. the reason the transceiver is there is to prevent the packets from being repeated until they get an acknowledgement from the client, if you test locally you will see the packets keep repeating because no clients respond to it with an ack, on a car its different, whereas they are not, more or less repeated repetitively the same packet, but instead a live streaming data with single packet output and next packet is new info and it just cycles at 500kbps
 
Last edited:
Right, but I thought that any CAN device woud aknowledge any message, if the device your expecting to respond is not connected and you don't get an aknowledgement you assume it was not received, try a few times more and then shut down as each device assumes it is the faulty one.
 
if this happened on a vehicle the network would be even more so overflooded with packets, imagine resending the same RPM packets if the cluster was taken out, that means youll have old and new packets flooding endlessly holding back the buffers of the ecu while the network is congested, makes no sense and if you log the data with the canbus device detached (cluster,abs, etc) you will not see this happen as theres only 1 packet being poured in and every cycle its a new value, not repeat the old
 
i do believe you can do this too not sure if library suppirts just single shot packet without ack but i read it somewhere on the forums here
 
My, albeit limited understanding of the can bus is that every message is acknowledged by every device. In this way at least something is going to acknowledge the message any other device sent out. If the message is not acknowledged the sender could keep sending the message continually overloading the bus. So if just something acknowledges the receipt of a valid message whether or not it was the intended recipient the sender knows that it did good. If it does not receive any acknowledgement from anything it attempts a number of times to resend that message and then gives up and shuts down to prevent overloading the bus.
 
i know, but disconnect a component and you will see the packet for it is still transmitted but not same values each cycle
overflowing/building a buffer in a network for an automobile to repeat the same data is not how it works

you are right to say that a transceiver is needed, but not for vehicles where the packets must remain updated and not stale.
in the library (not sure if collin has it) you can probably set your own timeout and mimic live values instead of repetitive stale packets, or add a timeout to end repetitive transmissions of stale packets, i seen it happen when i did mega2560&shield to teensy, yes there were repeats, but when i was reverse engineering the canbus stream on the car, it wasnt the same principle
 
besides your not telling the ecu you acknowledged a cluster packet :)
if you want to talk to the ecu on the network, you can add a transceiver then, but its useless for the traffic on there as it is
 
ok well I am a novice at CAN and can only go by what one person tells me.

So does this library work with the arduino style environment ? I'm hoping to make an easier entry into more powerful microcontrollers and not have a headache while doing that so that I can concentrate on things like learning CAN bus.
 
wait.. so i am brooding over how to soldering and circuit FT LS-CAN transceiver which is only available as SOP14 SMD and you telling me i can connect car to teensy straight with nothing at all?

buyed that semiconductor but no clue how to drive. should i just try to run it naked only with STP+EN+BAT+VCC short circuited and let rest floating, or do i need some capacitors/resistors on the other pins?

there is mentionend 3V interfacing with microcontroller possible with TJA1055T/3 does it mean i can use teensy 3.3V pin as power source?
https://www.nxp.com/docs/en/data-sheet/TJA1055.pdf
 
no you need a transceiver, you can use 3.3v transceivers, or "some" 5v transceivers *that communicate* at 3.3v logic levels
 
wondering how people got this work because cannot find any breakout board for that. MCP2515 shipped with TJA1050 which is not compatible anyway some people claim it works..

edit: except PCAN-TJA1054 is the only solution without SMD soldering so far. they terminated with 5.66 k resistor

edit2: btw many thanks for clarifying FlexCAN_T4.h together with isotp.h is exactly what i was looking for :)
 
Last edited:
so i got this TJA1055 work on 3.3V but i see no serial data. do i have to cross TX RX with Teensy or not? I get signal on RXD but don't how to debug. i use 83300 baud






this is the scetch i use



Code:
#include <FlexCAN_T4.h>
FlexCAN_T4<CAN0, RX_SIZE_256, TX_SIZE_16> Can0;

void blink(int pin, long on, long off)
{
  int blinkPhase = millis() % (on + off);
  if (blinkPhase < off)
    digitalWrite(pin, LOW);
  else
    digitalWrite(pin, HIGH);
}

void setup()
{
  Serial.begin(115200);
  delay(1000);
  Serial.println("Teensy 3.2, FlexCAN module CAN0 pins: 3 4, PWM pin: 6");
  Can0.begin();
  Serial.println("baud rate: 83300");
  Can0.setBaudRate(83300);
  Can0.setMaxMB(16);
  Can0.enableFIFO();
  Can0.enableFIFOInterrupt();
  Can0.onReceive(canSniff);
  Can0.mailboxStatus();
  analogWriteFrequency(6, 400);
  pinMode(LED_BUILTIN, OUTPUT);
}

void canSniff(const CAN_message_t &msg)
{
  Serial.print("MB "); Serial.print(msg.mb);
  Serial.print("  OVERRUN: "); Serial.print(msg.flags.overrun);
  Serial.print("  LEN: "); Serial.print(msg.len);
  Serial.print(" EXT: "); Serial.print(msg.flags.extended);
  Serial.print(" TS: "); Serial.print(msg.timestamp);
  Serial.print(" ID: "); Serial.print(msg.id, HEX);
  Serial.print(" Buffer: ");
  for ( uint8_t i = 0; i < msg.len; i++ )
  {
    Serial.print(msg.buf[i], HEX); Serial.print(" ");
  } Serial.println();
}

void loop()
{
  Can0.events();

  blink(LED_BUILTIN, 100, 1900);
  
  // PWM duty cycle 70% ON
  analogWrite(6, 180);
  
  // PWM duty cycle 30% OFF
//analogWrite(6, 80);
}
 
Last edited:
should be TX to TX and RX to RX for CAN, i guess it's a custom baudrate you are running? or it's the specs of the device you're connecting to?
 
it should be CAN_83K3BPS Mercedes-Benz Comfort CAN-B i am pretty sure i have connected the right connector X30/6 but i also tried 500.000 no success. maybe i am using wrong teensyduino version or should i overclock? currently i am running 72 MHz
 
btw that is some TJA1055T/3 breakout board where:

- VCC + BAT + WAKE are short-circuited to +5v and buffered with 100nF
- STB, EN set to HIGH with 10k (each) to +5v
- RTH, RTL 5.6k (each) termination (allowed: 500 < 6k)
- CANH, CANL 150 pF (each) capacitor

EVERYTHING ON BOARD
(will update link soon)

so all it needed was some additional pull-up resistors (3.3k ~ 4.7k) for RXD and ERR against +3.3v for the logic level according to page 18 datasheet
 
Status
Not open for further replies.
Back
Top