Kurt Van Dijck wrote:
> IMHO, your proposal violates these 2 major points you mentioned earlier
> with API design (with special regard to dynamic addressing, since static
> addressing will does not suffer this):
> * Easy to learn
> * Easy to use, even without documentation.
>
> I think I would prefer documenting that 'name == 0 means static
> addressing used'.
Hi Kurt,
this night i had a much better idea :-)
The problem is that the PGN is encoded inside the CAN-ID and therefore it was
seen as an address element so far. This leads to a wrong abstraction and wrong
thoughts about addressing in sockaddr_can.
Indeed the PGN is no address information but a data description identifier.
Comparing this to the commonly used ISO15765-2 the PGN has to be treated
analogue to the UDS SI (service identifier) of the data content that's
following in the same (UDS) ISOTP PDU.
Therefore the __u16 PGN should be the first data in the PDU that's written
into the socket - as we do with the SI in ISO15765-2. We also have the CAN-ID
in the CAN_RAW socket in the skb->data and the first element in the PDU we get
from the socket. The fact that the PGN is encoded inside the CAN-ID is a J1939
specific fact that is independent(!) from dynamic/static addressing in J1939.
This leads to the following suggestions:
- the PGN is always the first __u16 in the PDU that's read/written from/to the
socket.
- We introduce two types of CAN protocols (supported by _one_ can-j1939.ko)
- CAN_J1939 for static addressing
- CAN_J1939DA for dynamic addressing
- CAN_J1939 and CAN_J1939DA have different address structures (of course)
- when sending PDUs the PGN is given inside the PDU
- when receiving PDUs the PGN is given inside the PDU
- on the receiver side the PGNs can be filtered analogue to the CAN-ID filters
configured by sockopts - if needed.
This approach clearly separates the different J1939 addressing from the
content that's defined by the PGNs.
The CAN header definitions could change like this then:
--- include/socketcan/can.h (Revision 1160)
+++ include/socketcan/can.h (Arbeitskopie)
@@ -70,7 +70,9 @@
#define CAN_TP20 4 /* VAG Transport Protocol v2.0 */
#define CAN_MCNET 5 /* Bosch MCNet */
#define CAN_ISOTP 6 /* ISO 15765-2 Transport Protocol */
-#define CAN_NPROTO 7
+#define CAN_J1939 7 /* J1939 protocol w/o dynamic adressing */
+#define CAN_J1939DA 8 /* J1939 protocol with dynamic adressing */
+#define CAN_NPROTO 9
#define SOL_CAN_BASE 100
@@ -86,6 +88,21 @@
union {
/* transport protocol class address information (e.g. ISOTP) */
struct { canid_t rx_id, tx_id; } tp;
+ struct {
+ __u8 addr;
+ } j1939;
+ struct {
+ __u32 identity:21,
+ mfcode:11;
+ __u8 ecu_instance:3,
+ func_instance:5;
+ __u8 function;
+ __u8 reserved:1,
+ vsystem:7;
+ __u8 vsystem_instance:4,
+ industry_group:3,
+ arb_addr:1;
+ } j1939da;
/* reserved for future CAN protocols address information */
} can_addr;
Alternatively 'j1939da' could be named 'j1939name' or something like that.
What do you think about that approach?
For me it's the first definition that makes clear what needs to be done by the
application to send PGNs to specific ECUs at first sight.
Regards,
Oliver
> We coud so reduce the application choice between static &
> dynamic addressing to just choosing between j1939.name & j1939.addr, rather
> than choosing between API calls.
> Yes, this choice can be made wrong. When j1939.name is set, but not
> used, users might experience problems. I bet this will occur much
> sooner if they would need to get the name elsewhere (via cmsg()).
>
> The biggest challenge with documenting this j1939 approach IMO is learn
> typical CAN/J1939 users to think in terms of local & remote addresses in
> a BSD socket compliant way, rather than combining local & remote address
> in 1 can_id (as I also did when I started 10 years ago, I'm not blaming
> anyone here).
> The dynamic thing is minor challenge in documenting the api, given that
> using it is not too difficult.
>
> Regards,
> Kurt
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
