Describe the bug
When using a config_context loaded from can.ini for the pcan driver just uses the bitrate parameter, and
ignores all other details for bus timing, which causes it to use whatever default timing happens to be
in PCAN_BITRATES for the given bitrate.
This makes it impossible to define specific timings other than the defaults if you want to use can.ini
for configuration.
To Reproduce
- Create a can.ini file with a specific timing setup
[pcan_125_kbit_50_perc]
interface = pcan
channel = PCAN_USBBUS1
f_clock = 8000000
brp=8
tseg1 = 3
tseg2 = 4
sjw = 2
- Load the config context and initialize the bus.
can_config_def : can.typechecking.BusConfig = can.util.load_config(context='pcan_125_kbit_50_perc',
path='can.ini')
self.bus = can.Bus(state = can.BusState.ACTIVE, **can_config_def)
- Check actual timing configured either by debugging inside PcanBus.init() or by opening the device in PCAN-View, and see that actual timing is 125 kBit 85%
Expected behavior
I expected the timing parameters for a BitTiming() object to be honoured when loading from can.ini
Additional context
OS and version: WIndows 11
Python version: 3.12.10
python-can version: 4.6.1
python-can interface/s (if applicable): pcan
Describe the bug
When using a config_context loaded from can.ini for the pcan driver just uses the bitrate parameter, and
ignores all other details for bus timing, which causes it to use whatever default timing happens to be
in PCAN_BITRATES for the given bitrate.
This makes it impossible to define specific timings other than the defaults if you want to use can.ini
for configuration.
To Reproduce
Expected behavior
I expected the timing parameters for a BitTiming() object to be honoured when loading from can.ini
Additional context
OS and version: WIndows 11
Python version: 3.12.10
python-can version: 4.6.1
python-can interface/s (if applicable): pcan