Re: j1939

[David Jander <david@protonic.nl>]

On Tue, 4 Oct 2016 19:54:30 +0200
Patrick Menschel <menschel.p@posteo.de> wrote:

> >> Recently, someone on this list was confronted with an engine ECU that
> >> dropped TP that had the last packet not 8 bytes long.
> >> And I believe I've encountered an issue a long time ago where this
> >> happened on all PGNs.
> >> So I introduced this option, having 3 possibilities:
> >> * no padding
> >> * padding for TP
> >> * padding for all PGN.  
> > How to switch between padding for TP only and padding for all PGN?
> >
> > Marc
> >  
> 
> I'm working with J1939 regularly and programmed J1939 in Python3 a while
> ago.
> 
> From my experience, message construction is responsibility of the user
> program.

I agree.

> There are numerous SPNs to be implemented in a message while
> unimplemented bits are to be padded with ones.
> It may be possible to pad all messages with 0xFF but that doesn't solve
> the non implemented bits in front of the padding.

I think the kernel should never modify packets from user-space in such a way.
I think we should limit this option to chose between:

 0: (default) Strictly standards compliant (i.e. pad TP messages) and
 1: Not pad TP messages (may break standard).

> I think it's best practice to fulfill the requirements by creating a
> j1939 message with 8 Bytes of 0xFF and then replace the bits for a
> specific SPN.

That may be true for many standard PGN's, but not for all, and certainly not
for proprietary messages. Again, IMHO, the kernel should not mess with
user-space messages.

> This would be in user space when calling the J1939 message constructor.

Precisely.

> BTW many j1939 descriptor files types such as the PCAN ".sym" files,
> define SPNs as a bit offset and a length (additionally with type, factor
> and offset as compu_method), so no need to invent the wheel again.

Don't know exactly what you mean, but this sounds user-space specific to me.

> Regards,
> Patrick
> 

Best regards,

-- 
David Jander
Protonic Holland.