Add support for PCAN_HARD_RESET_STATUS in SetValue

[dafri92]

The PEAK PCAN-USB FD adapter is connected to custom electronics with no other nodes on the bus.
Sometimes the firmware resets especially during testing. If a message is sent to this single node while it reboots, the internal error counter of the PEAK adapter triggers the heavy limit and the adapter switches to passive mode.

The only reliable way to recover, without unplugging the USB cable, is setting PCAN_HARD_RESET_STATUS to PCAN_PARAMETER_ON, calling .reset() and waiting for the PEAK adapter becoming ready again.
This works on Windows 11.

Unfortunately re-initializing (without unplugging the USB cable, call .shutdown() and create a new instance of the Python CAN object) still keeps the error code 0x8 set.

For this reason support for PCAN_HARD_RESET_STATUS would be great.

Using Python 3.12.5 with python-can 4.4.2 and PCBUSB 0.13 running on MacBook Air M1 (Sonoma 14.6.1).

[mac-can]

As stated in the README file:

When a successfully initialized PCAN-USB device is physically removed from USB any subsequent call of API functions (e.g. CAN_Read) will not succeed even when the device is plugged in again. An error code will be returned in this case.

“Physically removed” also includes resets (by hardware, e.g. brownout, or requested by software).

The PCBUSB library is a user-space driver. If a USB device is unplugged or reset, it is removed from the USB device tree by the operating system and its handle and resources in the user space are invalid. Recognizing that the “same” USB device is plugged in again (perhaps in a different slot) or recovers after a reset is not trivial. The current software architecture does not allow this.

I have put this wish on the wish list, but it might take a little longer to implement.

[mac-can]

@Obrekr could you please open a new issue for the error counters behavior to keep better track of it.

[mac-can]

@Obrekr could you please open a new issue for the error counters behavior to keep better track of it.

Issue will be track as issue #19