Taking inspiration from the D-PDU API, It is probably best to convert the Passthru ISO-TP methodology to software driven.
Currently, Passthru device opens a dedicated ISO-TP channel at a hardware level. This is good for performance, but it means that a dedicated CAN Channel cannot be opened at the same time as they conflict one another.
One down side to this method is it means it is impossible for the tester to send keep alive CAN messages to other ECUs in a vehicle whilst trying to maintain an ISO-TP channel with a target ECU.
Therefore, it is best to create a software ISO-TP channel, which uses a PT CAN channel to operate on. This will allow both ISO-TP messages and regular CAN messages to be exchanged at the same time.
Taking inspiration from the D-PDU API, It is probably best to convert the Passthru ISO-TP methodology to software driven.
Currently, Passthru device opens a dedicated ISO-TP channel at a hardware level. This is good for performance, but it means that a dedicated CAN Channel cannot be opened at the same time as they conflict one another.
One down side to this method is it means it is impossible for the tester to send keep alive CAN messages to other ECUs in a vehicle whilst trying to maintain an ISO-TP channel with a target ECU.
Therefore, it is best to create a software ISO-TP channel, which uses a PT CAN channel to operate on. This will allow both ISO-TP messages and regular CAN messages to be exchanged at the same time.