Hello 1. This will be additional functionality that will be used when and where it is needed. Already used in some car diagnostics testers. 2. "Functional addressing (1-to-n communication) shall only be supported for Single Frame communication" - this i found on some old ISO document and i think this is for 'tx' only. I do not have access to all current ISO documents. But in reality this implementation is used in the testers for bmv and vw may be others also. 3. About other languages bindings this can be make easy - look 1. :) (driver will continue to work in old way and when is necessary with option will be switched in broadcast mode) Regards, Zahari On Mon, Sep 10, 2018 at 6:04 PM Patrick Menschel <menschel.p@xxxxxxxxx> wrote: > > 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 >
