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 On Sun, Sep 9, 2018 at 10:26 PM Patrick Menschel <menschel.p@xxxxxxxxx> wrote: > > Hi, > > would you mind describing your usecase a little further. > I see you're using UDS to broadcast "read local ID". > > Why don't you broadcast "tester present" to find out the ECUs on the bus > and then sequentially do "read local ID" from each ECU. > > That workes around the misery with the address specific flow control frame. > > Regards, > Patrick > > > > From programmers 'using' perspective i think must be exactly like UDP, > > with appropriate MASK can get responses from all available ECU. > > From implementation perspective things are more complex. > > On Sat, Sep 8, 2018 at 5:40 PM Zahari Zahariev <harryzz@xxxxxxxxx> wrote: > >> > >> DISCUSSION FROM GITHUB: > >> > >> ==>harryzz commented 7 hours ago > >> Ok. thanks. > >> And what about BROADCAST messages. Is possible to handle and what is right way? > >> like this with broadcast address 0xDF: > >> > >> 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 > >> can1 610 [8] F1 22 00 09 00 00 00 00 > >> can1 610 [8] F1 23 00 00 00 06 00 00 > >> can1 610 [8] F1 24 04 52 02 0B 1E 08 > >> can1 610 [8] F1 25 00 00 04 53 02 0B > >> can1 610 [8] F1 26 3C 08 00 00 04 54 > >> can1 610 [8] F1 27 02 05 04 01 00 00 > >> can1 610 [8] F1 28 01 B4 00 C4 00 FF > >> > >> can1 640 [8] F1 10 54 62 F1 01 01 01 > >> can1 6F1 [8] 40 30 0F 02 00 00 00 00 > >> can1 640 [8] F1 21 00 08 12 07 10 8A > >> can1 640 [8] F1 22 8F 71 01 00 00 01 > >> can1 640 [8] F1 23 23 00 00 01 00 00 > >> can1 640 [8] F1 24 00 07 05 00 02 02 > >> can1 640 [8] F1 25 00 00 02 EB FF FF > >> can1 640 [8] F1 26 FF 06 00 00 07 4B > >> can1 640 [8] F1 27 06 00 08 08 00 00 > >> can1 640 [8] F1 28 07 4F 06 06 14 08 > >> can1 640 [8] F1 29 00 00 07 4D 06 06 > >> can1 640 [8] F1 2A 14 08 00 00 07 4E > >> can1 640 [8] F1 2B 06 06 14 08 00 00 > >> can1 640 [8] F1 2C 07 4C 06 06 14 05 > >> can1 640 [8] F1 2D 00 00 00 0F 05 13 > >> can1 640 [8] F1 2E 05 FF FF FF FF FF > >> > >> can1 672 [8] F1 10 4C 62 F1 01 01 01 > >> can1 6F1 [8] 72 30 0F 02 00 00 00 00 > >> can1 672 [8] F1 21 00 07 13 02 07 8B > >> can1 672 [8] F1 22 00 24 00 00 00 00 > >> can1 672 [8] F1 23 00 00 00 01 00 00 > >> can1 672 [8] F1 24 0D 10 01 00 01 06 > >> can1 672 [8] F1 25 00 00 05 15 0D 03 > >> can1 672 [8] F1 26 00 08 00 00 05 13 > >> can1 672 [8] F1 27 0D 03 23 08 00 00 > >> can1 672 [8] F1 28 05 14 0D 03 23 08 > >> can1 672 [8] F1 29 00 00 05 12 0D 03 > >> can1 672 [8] F1 2A 23 08 00 00 05 11 > >> can1 672 [8] F1 2B 0D 03 28 05 00 00 > >> can1 672 [8] F1 2C 01 2F 0C 06 16 FF > >> > >> ==>hartkopp commented 5 hours ago > >> The point is, that broadcast messages fit into one CAN frame - which > >> does not need a "transport protocol". > >> So the idea is to perform broadcast PDUs with a CAN_RAW socket - and > >> whenever you need a segmented PDU transfer you use the CAN_ISOTP > >> socket. > >> E.g. you may open an isotp socket which is listening on a specific > >> connection (two CAN IDs) but trigger some function with a CAN_RAW > >> socket via broadcast. > >> > >> ==>harryzz commented 4 hours ago > >> Ok. If i understand you correctly: for my case i need to open up to 240 > >> sockets to handle response from broadcast and find available ECU (i don't > >> know how many ECU have installed)? > >> > >> ==>hartkopp commented 2 hours ago > >> Formally yes. The problem is, that you would have to deal with all > >> that possible back channels (and its communication channel CAN ID > >> pairs) anyway, right? How would you do that with another approach? In > >> any case you would formally need to create 240 state machines that > >> could react on answers of a broadcast request - or am I missing > >> anything here? > >> ps. Thanks for the discussion. Most people just fork and use the isotp > >> module without giving feedback. And I would like to push it into > >> mainline Linux, so feedback is really appreciated. > >> > >> ==>harryzz commented an hour ago > >> I don't need to have all the time opened all 240 sockets. I send > >> broadcast and then collect available ecu's and returned data and close > >> all connections. After this diagnostic is in normal way peer-to-peer. > >> I know i can make this also with can_raw and assemble data in > >> user-space .... > >> what you think about implementation of 'listen' and 'accept' > >> functionality - this will fix issue and will be more flexible? > >> > >> ==>hartkopp commented an hour ago > >> how would you think this could look like from a programmers perspective? > >> Can we continue this discussion on the linux-can mailing list please? > >> Github is not the best place for these kind of discussions as the CAN > >> community is more active on the mailing list (and it is archived there > >> too)
