implemented FD for Pcan

[bmeisels]

I have implemented FD support for PCAN (solving #507).
This code has been tested manually on PCAN-FD hardware.

Points to be discussed:

1. Parameters for the bit rate are passed as keyword args.
   Should this be switched to be a single string? (this is what the Pcan API accepts).
   The benefit to switching would be a simpler interface.
2. Messages with a non standard message size are padded right now with zeros.
   Should we allow for an option to configure the padding?
   What should the default padding be?

[markuspi]

Did you test receiving messages? It seems like the timestamp format is different for FD

[codecov]

Codecov Report

Merging #537 into develop will decrease coverage by 0.41%.
The diff coverage is 3.33%.

@@             Coverage Diff             @@
##           develop     #537      +/-   ##
===========================================
- Coverage    64.47%   64.05%   -0.42%     
===========================================
  Files           63       63              
  Lines         5655     5695      +40     
===========================================
+ Hits          3646     3648       +2     
- Misses        2009     2047      +38

[bmeisels]

@markuspi good catch, thanks.
I fixed according to your suggestion and also fixed another mistake which would make the code not work on python3.

[bmeisels]

@markuspi fixed. Thanks again.

[felixdivo]

Messages with a non standard message size are padded right now with zeros.
Should we allow for an option to configure the padding?
What should the default padding be?

This might be unexpected:

Errors should never pass silently.
[...]
In the face of ambiguity, refuse the temptation to guess.
-> The Zen of Python

Maybe just raise a ValueError?

[bmeisels]

Messages with a non standard message size are padded right now with zeros.
Should we allow for an option to configure the padding?
What should the default padding be?

This might be unexpected:

Errors should never pass silently.
[...]
In the face of ambiguity, refuse the temptation to guess.
-> The Zen of Python

Maybe just raise a ValueError?

A ValueError would be incorrect. I have seen multiple cases where this is intended behavior.
An explicit argument with a default value could work but it will complicate the interface.

[felixdivo]

A ValueError would be incorrect. I have seen multiple cases where this is intended behavior.
An explicit argument with a default value could work but it will complicate the interface.

@christiansandberg What do you think? I'd be okay with that silently padding, as it might indeed make some applications quite a bit easier.

Padding with zeros to the next bigger size sounds like something people would expect then, right?

[christiansandberg]

Padding is completely normal. I guess it could make sense to allow specification of other value than 0 for CRC purposes but not necessary.

[bmeisels]

After looking through some code on other interfaces i noticed that i can use the len2dlc and dlc2len functions instead of implementing them myself.

Also i think can FD message length should be validated the either by _check in Message(as of now only checks that the length is less then 64 for FD) or the send in the Interface.

[felixdivo]

should be validated either by _check in Message (as of now only checks that the length is less then 64 for FD) or the send in the Interface

You are right, the _check method should validate that as well!

Maybe all interfaces should pass check=True when reading messages? It should never cause a false alarm, if we implemented it correctly. We could also call _check() when sending a message.

But then, why don't we always check it? Performance?

[bmeisels]

Maybe all interfaces should pass check=True when reading messages? It should never cause a false alarm, if we implemented it correctly. We could also call _check() when sending a message.

If so then maybe check should default to True?

But then, why don't we always check it? Performance?

I don't think performance is an issue. I can think of reasons one would like to send a malformed message and see it rejected by the other devices.

[felixdivo]

If so then maybe check should default to True?

Why? We can simply call it and ignore the result if everything is fine.

[bmeisels]

If so then maybe check should default to True?

Why? We can simply call it and ignore the result if everything is fine.

i meant that the check parameter should default to true.
message.py:88

[felixdivo]

Ah, yes. I think that's a good idea. But I think we have already discussed it at some point ... @christiansandberg @hardbyte What do you think?

[christiansandberg]

It could be a performance issue on e.g. a RapsberryPi on a high traffic bus.

[felixdivo]

We could make it opt-out in the RC/config parameters.

[bmeisels]

As it seems that the use of check is a larger issue,
I think this PR be merged and we should consider changes to the use of check separably.
What do you all think?

[felixdivo]

@christiansandberg Could you also check if this PR shall be merged?

[hardbyte]

As it seems that the use of check is a larger issue,
I think this PR be merged and we should consider changes to the use of check separably.
What do you all think?

I agree, I'm not familiar with can-FD though so I'll defer to @christiansandberg

[christiansandberg]

Sure, just document the new arguments. Otherwise people have to study the source code to figure out what config is accepted.

[christiansandberg]

Maybe we should also standardize the various timing parameters between interfaces, but that can be done in a separate issue.

[bmeisels]

Sure, just document the new arguments. Otherwise people have to study the source code to figure out what config is accepted.

I documented the new arguments.

Maybe we should also standardize the various timing parameters between interfaces, but that can be done in a separate issue.

I think this should extended to a discussion of standardizing interface parameters in general. For example the handling of the state parameter is different between interfaces.

[christiansandberg]

Perfect!

[felixdivo]

So there are two issues we should create out of this:
(1) discussion of standardizing interface parameters in general, and
(2) discuss whether the check parameter should default to true.