Fix bitrate calculation for PCAN interfaces

[Finwood]

The existing PCAN interface implementation disregarded the configured bitrate preferences, and used static magic-numbers instead. This PR changes the timing calculation by utilizing can.BitTimingFd.from_sample_point(), which leads to a cleaner implementation.

I am unsure regarding the target sample point location: my setup works well with 87.5%, and does not work with 75%, but that might be an edge case (low clock precision). Does anyone have recommendations on sample point location?

[coveralls]

coverage: 93.896% (+0.009%) from 93.887%
when pulling aa1b088 on Finwood:fix-pcan-bitrate-calculation
into 9514f24 on OpenCyphal:master.

[pavel-kirienko]

I am unsure regarding the target sample point location: my setup works well with 87.5%, and does not work with 75%, but that might be an edge case (low clock precision). Does anyone have recommendations on sample point location?

Could be caused by long wiring, or large uncompensated transceiver delays, if we're talking about CAN FD. This might or might not be relevant: https://forum.opencyphal.org/t/on-can-bus-topology-and-termination/1685

EDIT: Sorry I cited an old document here; disregard that. I can only say that CiA 1301 recommends 80% for the arbitration phase, and for the data phase the value depends on the bitrate, going toward lower values with higher bit rates.

Here's a relevant chart from Holger Zeltwanger's presentation, although it's not CANopen-specific:

[pavel-kirienko]

Please bump the patch version in __version__.py

[Finwood]

@pavel-kirienko, is there anything that prevents this PR from being merged?

[pavel-kirienko]

@Finwood I don't think so. A CI has failed for a non-code-related reason so I restarted it; I am going to enable auto-merge now. In the future it is best to request a new review explicitly so that I know when it's ready.