Search:

the error info has been added there if you check the source file, as per another user request, it has it's own callback

yes it can be done dynamically the baudrates

well it does support self-recovery, you could just set the baudrates in listen-only mode and check if the callback fires. callbacks only fire for valid receptions

i can only assume the neopixels temporarily disable interrupts, which would interfere with simuletaneous transfers

that's only if you define the pin in the wdt config, otherwise no.
it's purpose is to hold the line till the main processor resets if teensy is a sub processor, where after the main resets the power...

you can disable and reenable fifo by default it'll accept all
then filter afterwards as needed

I see you setting K bus filter but not setting up the K bus, unless you posted partial code, can't help much. the filters are only updatable while the bus is deactivated, so that is fine and does as...

you can bitshift the unsigned bytes then cast as needed
for example
RPM:
byte 4 and 5
int value = buf[4] << 8 | buf[5];

I have FIFO running on 3 busses at same time without loss. Are you using interrupts or loop method or polling?

FIFO clears when all messages are read

31035
programming resistor on haltech


also if you're asking about a custom configuration, there should be max 2 resistors in a bus 120ohms each furthest device. if you do remove the 120 ohm...

you'll need to check your haltech if it has resistors built in, and if it does they should have a way to disable it in programming

The CAN lines are on the OBD port, yes they go thru a gateway too. Could be 1 or 2 other busses that's on. You have also a body CAN bus, which is nice, because it has data available while the vehicle...

you wont slow them down unless you're flooding the bus, even at 50ms gaps you should be fine, but recommend you be lenient

there should be 2x 120 ohm on that PCB
```This tiny Teensy add-on board features dual CAN-Bus transceiver circuits, including termination resistors```
1x 120 ohm per bus, most likely the ones on...

that is a cool trick, but extra latency you wouldn't physically notice in the loop() 🙂

dont add terminations in a vehicle, the vehicle is already terminated.

if devices you have added have resistors, remove their resistors.

if your cluster goes limp, your CANL & CANH lines are...

1000kbps with no terminations? that'll never work. MAYBE at 125kbps, MAYBE, but definately nothing will work at >125kbps without terminations.

last update only supports SPI, not SPI1, so currently no support is implemented in last update

yup you are correct the tdie bit on the 1062 is used because there was an issue using the rdie. i dont remember what but it took a long time to work out the kinks and qwirks just to get it stable...

try enabling the interrupt at the end. whenever you set a MB the filters and interrupts reset.

you already posted this as an issue on github. Don't set a filter then configure the mailbox. That is backwards. also post what mailboxStatus() shows

just load master on one and slave on the other, if you dont see communication try swapping the MISO/MOSI lines around

make sure Teensy 4.1 is selected in arduino if not already done for that error

also do not use the GND pin located next to pin 0, you need to have both 4.1s connected with the GND pin located next...

1) it should provided the payload is 6 bytes or less, provided the first 2 bytes are passes as an isotp header. if you prefer not receiving those single frames whivh can exist during debugging, i...

yes send both as normal frames, the isotp is there just to assemble messages in stream

you need to send that frame, then send the flow control after, if you don't send the flow control frame the ecu will not send out the full isotp frame, and if the full isotp frame is not sent out you...

effectively that writes the 8 bytes as a payload in isotp format (2 frames for payload)

so, 8 bytes as payload plus isotp header
to send that just as a frame itself use Can1.write(msg)

this is just an example of sending and receiving, you can change it up to your purpose as needed

the hardware retransmits automatically, even if you call an abort on the mailbox it may or may not transmit a garbage frame, and if your code is retransmitting over a loop you'll just be enabling it...

have you tried swapping around the MISO and MOSI wires?

can you try SPI_MSTransfer_T4 library example, that should work just for sanity check, because if it doesn't, it's most likely a connection or cross-wire issue.
check if the demo works on both your...

yes that will work, you could also just send it 10ms after the request

isotp server acts same way like ecu

ahh i see. the way the library handles isotp between teensies is it sends the complete isotp frames. So for reception that is not complete, an isotp first frame is discarded if overridden as needed...

isotp plugin doesn't use mailboxes specifically, as the data comes in it from the controller goes to the background reassembly queue until it is complete, until which it it then fires the user...

the isotp is an addon, you can use both as needed in same sketch

well thats for isotp.

for pid requests you can just use the following (edited as needed)



CAN_message_t msg;
msg.id = random(0x1,0x7FE);
for ( uint8_t i = 0; i < 8; i++ )...

it all depends on how long your interrupts are, and the speeds of the SPI obviously especially when pushing data. if the slave interrupt is not ready to receive because of another interrupt you may...

this library setups only one LPSPI as slave. Even if you managed to setup 2 or more slave on LPSPI you'd need to be able to manage the 2 ports simuletaneously, and if interrupts are involved, good...

that wouldnt be possible, u cant have 2 masters talking to one slave,

2 slaves? use 1 or 2 SPI ports on master should work, the slave is fixed only to one bus

its one byte/word at a time, not grouped. if you want the slave to send more data you need to basically send dummy bytes/words to push the data out of the slave, so you need to handle that as needed

yes but the master end *should* work on any other arduinos, you'd have to test as it uses the standard SPI library for master. The slave end is only working for the Teensy 3.x/LC/T4.x end. The patch...

SPI_MSTransfer_T4 is a 2-way daisy-chainable data transfer utility. It includes the slave and master headers and source files, with simple examples.

if you prefer to keep a teensy4.x as master...

if you are using a T4.x master there is a slight bug in the DSE gpio bits, which is fixed in SPI_MSTransfer_T4. Other master controllers don't seem to have this issue. Also for your common ground...

what i always do (my own preference of course) is setup a scoped millis() near the action you want to do, so in the loop i would put:



void loop() {
static uint32_t coolant_timer = millis();...

you shouldn't need to strip mailboxes down to one using msg.seq = 1, it will only output to the absolute first mailbox. also you don't need events() in loop if you want direct firing interrupts, but...

are you using pins 0 & 1 for CAN2?
are you using level shifters? teensy is 3.3v
is the Rs pin driven low?

only thr t4.x masters needs specific dse bits set, other masters work fine

the master 4.x need a patch for the DSE bits, check out the commits for SPI_MSTransfer_T4, this only affects the master, just make sure your ground is the one next to the 5v pin (not near pin 0)