hardbyte
Add notes/kvaser support for non-iso support
Some older devices in the wild use non-iso CAN FD (Bosch). Some hardware supports choosing the mode in the driver, others are configurable during install or with a separate application. Kvaser is in the canlib API. PCAN requires either socket-can driver or the Windows GUI. Socket-CAN is an initialization flag.
Add documentation and hooks for kvaser. Relatively unintrusive. It didn't fit nicely with the bit-timings concept as it's purely associated with CRC calculation and stuffing.
Fixed the test that was failing the black formatting check. The unit test that was failing appears to be intermittent and unrelated to these changes
@lumagi What do you think about adding
CanProtocol.CAN_FD_NON_ISO?
Although it is very specific to this interface, I generally don't see any reasons against it. The enum already has multiple values so there's no real harm in one more. And it would certainly do away with the mess of book flags.
What value would there be in tracking this in bus's protocol property? For all use cases I've seen ISO and Non-ISO CANFD should behave identically at the app layer - the only difference is some bits in the header change but that's at a layer below python-can. A bus can't mix/match frames between the two types and I don't see any interesting uses of protocol outside of the bus implementations.
Ultimately you still need a kwarg for the Bus init, there's no way to guess if it's ISO or not from say bittimings or other flags.
I agree that it's unfortunate that more drivers don't expose this in a way that python-can can exploit.
I can update the docs per the recommendations later.
Fixed the black issue -would be nice if that was in the default workflow but oh well.