Debated whether to start a new topic or post to the already long FlexCAN_T4 thread. Apologies if that would have been preferred.
I've been working on a project to bi-directionally forward j1939 CAN bus messages between two CAN ports. Partly this is for doing analysis purposes, so I can see what direction a message is traveling. But also I am modifying some messages as they traverse my bridge. The speed of both interfaces is 250 kbs and the bus has a fair amount of traffic on it (around 150 messages per second). I've had great success on an Arduino Due using interrupt-driven message processing and the due_can library. I am hoping to accomplish the same thing with the Teensy 4 since the Teensy has several times more processing power so I am hoping to drive a status display and do other UI things while processing the messages.
I don't think I can't use CAN filters because any and all messages have to be forwarded. I started at first principles using the BiDirectionalForward example. However this doesn't seem to be fast enough to forward all the messages. The reason I can tell this is because some of the messages on the bus are used to drive an OEM LCD data display and when messages are lost, the display is corrupted somewhat--things aren't drawn in the right place and some text is missing. There's some kind of drawing protocol that's being used. I encountered this issue with the Due but solved it by moving to interrupt-driven message processing. On the Teensy I moved to using the CAN2.0_example_FIFO_with_interrupts example code, modified to bi-directionally forward messages. However the same thing still happens (corruption on the OEM data display) and the only cause can be messages are getting lost.
Here's the code I'm testing with. There is a simple print for each message which I know is too slow for a uart, but Teensy 4's USB serial device is very fast so shouldn't be a problem (it isn't on the Due's native USB port either).
The bus traffic is around 150 extended messages per second. The Due had no problem with it with interrupt-driven processing, even when I parsed each message and printed data out to the native USB serial. No OEM display issues whatsoever. What can I do to make the Teensy 4 work? Is this just a limitation in the Teeny's CAN processing hardware? Is it a matter of the transceiver (using the SKPang board's transceivers)? I suspect it's something simple and my ignorance of how CAN FIFOs and Mailboxes work is causing me to miss something. Any clues? I've read through the README a few times and looked at the examples. And read on the long FlexCAN_T4 thread too.
I've been working on a project to bi-directionally forward j1939 CAN bus messages between two CAN ports. Partly this is for doing analysis purposes, so I can see what direction a message is traveling. But also I am modifying some messages as they traverse my bridge. The speed of both interfaces is 250 kbs and the bus has a fair amount of traffic on it (around 150 messages per second). I've had great success on an Arduino Due using interrupt-driven message processing and the due_can library. I am hoping to accomplish the same thing with the Teensy 4 since the Teensy has several times more processing power so I am hoping to drive a status display and do other UI things while processing the messages.
I don't think I can't use CAN filters because any and all messages have to be forwarded. I started at first principles using the BiDirectionalForward example. However this doesn't seem to be fast enough to forward all the messages. The reason I can tell this is because some of the messages on the bus are used to drive an OEM LCD data display and when messages are lost, the display is corrupted somewhat--things aren't drawn in the right place and some text is missing. There's some kind of drawing protocol that's being used. I encountered this issue with the Due but solved it by moving to interrupt-driven message processing. On the Teensy I moved to using the CAN2.0_example_FIFO_with_interrupts example code, modified to bi-directionally forward messages. However the same thing still happens (corruption on the OEM data display) and the only cause can be messages are getting lost.
Here's the code I'm testing with. There is a simple print for each message which I know is too slow for a uart, but Teensy 4's USB serial device is very fast so shouldn't be a problem (it isn't on the Due's native USB port either).
Code:
#include <FlexCAN_T4.h>
FlexCAN_T4<CAN1, RX_SIZE_256, TX_SIZE_16> Can0;
FlexCAN_T4<CAN2, RX_SIZE_256, TX_SIZE_16> Can1;
void can0_got_frame_teensy(const CAN_message_t &frame) {
Serial.println("0->1");
Can1.write(frame);
}
void can1_got_frame_teensy(const CAN_message_t &frame) {
Serial.println("1->0");
Can0.write(frame);
}
void setup()
{
delay(5000);
Serial.begin(115200);
Serial.println("j1939 CAN bridge.");
//Teensy FlexCAN_T4 setup
Can0.begin();
Can0.setBaudRate(250000);
Can0.setMaxMB(16);
Can0.enableFIFO();
Can0.enableFIFOInterrupt();
Can0.onReceive(can0_got_frame_teensy);
//Can0.enableMBInterrupts(FIFO);
//Can0.enableMBInterrupts();
Can0.mailboxStatus();
Can1.begin();
Can1.setBaudRate(250000);
Can1.setMaxMB(16);
Can1.enableFIFO();
Can1.enableFIFOInterrupt();
Can1.onReceive(can1_got_frame_teensy);
//Can1.enableMBInterrupts(FIFO);
//Can1.enableMBInterrupts();
Can1.mailboxStatus();
}
void loop()
{
//process collected frames
Can0.events();
Can1.events();
}
The bus traffic is around 150 extended messages per second. The Due had no problem with it with interrupt-driven processing, even when I parsed each message and printed data out to the native USB serial. No OEM display issues whatsoever. What can I do to make the Teensy 4 work? Is this just a limitation in the Teeny's CAN processing hardware? Is it a matter of the transceiver (using the SKPang board's transceivers)? I suspect it's something simple and my ignorance of how CAN FIFOs and Mailboxes work is causing me to miss something. Any clues? I've read through the README a few times and looked at the examples. And read on the long FlexCAN_T4 thread too.