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)
