Hi, I get your point but there are a few problems to solve. 1. If no rx canid is given, the protocol must guess what received answer is isotp and it is very likely that there is a testcase where this results in garbage. 2. I think switching from Broadcast 0xDF to the specific address 0x10 violates the protocol. It would be logic to use broadcast in the flow control frame as well. >>>> can1 6F1 [5] *DF* 03 22 F1 01 >>>> >>>> can1 610 [8] F1 10 34 62 F1 01 01 01 >>>> can1 6F1 [8] *10* 30 0F 02 00 00 00 00 >>>> can1 610 [8] F1 21 00 04 11 01 11 8B ... I observed something similar in a j1939 implementation of EDC17, where a TP.CM is sent to broadcast while TP.DT is sent to the specific destination address of the requesting device. The j1939 conform terminal application at test subsequently dropped every TP message as there was no data for the PGN and no PGN for the data respectively. Should mean, if broadcast is handled by isotp, it should not violate the standard. 3. This change may cause problems with other programming language implementations. I recently moved to python3.7 that basically does isotp with a 2-liner and build-in bytes object as I/O stream, somewhat like a serial port. A broadcast implementation would need to change the user interface to (rx-canid,bytes) tupples for example. I hope this counts as a programmers point of view ;-) . Regards, Patrick > Hi > > My use case is because of already existing diagnostic software that > using this functionality. > In general - when this exist i think should be made simple to use and > then will be used from programmers. > Otherwise - with limited functionality everybody will make own implementation. > > Regards, > Zahari
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
