A single ECU (or virtual ECU) address is used by In practice, this means theyĬannot share ECU addresses. Must be taken that these two do not interfere. Since such library does not communicate with the in-kernel implementation, care User space library operating on CAN raw sockets will still operate properly. The J1939 sockets operate on CAN network devices (see SocketCAN).

Therefore, these parts are left to user space. In-kernel code for these would not contribute to protocol stability. J1939 defines some other features (relaying, gateway, fast packet transport, Properly and eliminates the serialization (synchronization) as a requirementįor _every_ user space process that communicates via J1939. (synchronized) between different processes. The individual TP & ETP sessions _must_ be serialized Transport: both TP & ETP reuse some PGNs to relay big packets over them.ĭifferent processes may thus use the same TP & ETP PGNs without actually Results in a consistent J1939 bus with proper addressing. Requirement for _every_ user space process that communicates via J1939.

Putting this functionality in the kernel eliminates it as a This way of working isĬlosely related to the UNIX concept where programs do just one thing, and doĭynamic addressing: Address Claiming in J1939 is time critical.įurthermore data transport should be handled properly during the address

This way, address parameters for different processesĬooperating for the same ECU, are not duplicated. Although at least one process perĮCU should know the source address. Sockets, we found some reasons to justify a kernel implementation for theĪddressing and transport methods used by J1939.Īddressing: when a process on an ECU communicates via J1939, it should Given the fact there’s something like SocketCAN with an API similar to BSD

Base pgn j1939