retepsnikrep
- 8th October 2020, 08:09
I'm building a MITM 'Man in the Middle' CAN - CAN device to manipulate some CAN 500kbps data.
I'm happy working with pic CAN rxd and txd and am using 2 x pic18F2680 32mhz joined with hardware SPI Master/Slave 8mhz for prototype testing.
The hardware can be easily upgraded to a 64mhz 18F26K80 and 16mhz SPI bus later once I have a sensible software strategy.
Basically the hardware setup is as follows. (This all works)
CANBUS1 <<<>>> PIC18F2680 <<< SPI 8mhz >>> PIC18F2680 <<<>>> CANBUS2
Whatever is received on CANBUS1 needs to be sent out on CANBUS2 and vice versa.
There is even a Heath Robinson video of it working if you have a few minutes..
https://youtu.be/9oTvZ-2dbOk
As described this does operate quite well, but i'm dropping a few CAN packets and am after some ideas on the best/fastest software strategy..
I can poll flags or use DT Interrupts on the CAN and SPI modules.
I could add a ring buffer at both ends maybe for RX and TX.
I've read up on the CAN and SPI errata for the PIC and done a lot of reading and that all seems to be working.
The SPI is currently configured as Master & Slave...
I could add more handshaking lines between the pics as there is a lot of spare IO if that would help throughput.
Now packets on the two CAN busses might not arrive at the same time or intervals/frequency. How to deal with that?
Maybe I should join two complete ports together on the pics and clock out data a byte at a time?
I could join PIC ports A directly to each other with a 1k current limit resistor on each line to prevent direct shorts.
Would that be quicker/easier than the hardware 8mhz SPI?
Anyone have any other cunning ideas?
Basically at the moment my process is run the SPI bus as fast as possible between the PICS,
and then as data appears on the CANRX busses (poll or interrupt detected) drop it onto the SPI to clock it across to the other PIC for onward transmission.
Thanks in advance for ideas..
I'm happy working with pic CAN rxd and txd and am using 2 x pic18F2680 32mhz joined with hardware SPI Master/Slave 8mhz for prototype testing.
The hardware can be easily upgraded to a 64mhz 18F26K80 and 16mhz SPI bus later once I have a sensible software strategy.
Basically the hardware setup is as follows. (This all works)
CANBUS1 <<<>>> PIC18F2680 <<< SPI 8mhz >>> PIC18F2680 <<<>>> CANBUS2
Whatever is received on CANBUS1 needs to be sent out on CANBUS2 and vice versa.
There is even a Heath Robinson video of it working if you have a few minutes..
https://youtu.be/9oTvZ-2dbOk
As described this does operate quite well, but i'm dropping a few CAN packets and am after some ideas on the best/fastest software strategy..
I can poll flags or use DT Interrupts on the CAN and SPI modules.
I could add a ring buffer at both ends maybe for RX and TX.
I've read up on the CAN and SPI errata for the PIC and done a lot of reading and that all seems to be working.
The SPI is currently configured as Master & Slave...
I could add more handshaking lines between the pics as there is a lot of spare IO if that would help throughput.
Now packets on the two CAN busses might not arrive at the same time or intervals/frequency. How to deal with that?
Maybe I should join two complete ports together on the pics and clock out data a byte at a time?
I could join PIC ports A directly to each other with a 1k current limit resistor on each line to prevent direct shorts.
Would that be quicker/easier than the hardware 8mhz SPI?
Anyone have any other cunning ideas?
Basically at the moment my process is run the SPI bus as fast as possible between the PICS,
and then as data appears on the CANRX busses (poll or interrupt detected) drop it onto the SPI to clock it across to the other PIC for onward transmission.
Thanks in advance for ideas..