Hi Thomas,
On 02.12.20 15:58, Thomas Wagner wrote:
Btw. I would like to ask about the naming of the flag.
CAN_ISOTP_FADDR_TX_ONLY
CAN_ISOTP_FUNCADDR_TX
CAN_ISOTP_FUNC_ADDR
CAN_ISOTP_FUNC_ADDR_TX
(?? other ideas ??)
I guess broadcast CAN_ISOTP_BROADCAST would be a more generic description, implying the 1-to-N nature where listeners might
establish a 1-to-1 connection as needed. But considering the flag would probably mainly be used with OBD/UDS functional addressing
CAN_ISOTP_FUNC_ADDR doesn't seem half bad IMO.
'BROADCAST' is a good hint!
I'll start with
#define CAN_ISOTP_SF_BROADCAST 0x800 /* 1-to-N functional addressing */
Btw. If you already have established the 8 1-to-1 sockets as described
above the ECU can also send PDUs with length >7 bytes as your socket
would do the protocol handshake.
Yes, that's the way I have been working most of the time. Even when sending functional requests to all ECUs, they will respond to those
8 1-to-1 sockets and hence I am able to receive responses that are quiet long. E.g. I can send a single functional request to make all
available ECUs identify with an ID, which is normally longer than 7 byte.
Ah, that completes my picture.
Are you currently working on a Linux 5.10-rc kernel with ISO-TP included
in the tree - or would you like the testing based on my GitHub isotp repo?
I would much prefer to work of the GitHub repo if possible, as I don't have a setup for newer kernels with CAN hardware.
Ok. Will send a notification here when the RFC code is ready to test.
Best regards,
Oliver
