Wrong CAN_PARAM_MAP Mapping for SlCan although configuration file OK

[SaxElectronics]

Hi @christoph2 ,

I discovered an issue while trying to update my project to the latest pyxcp master.

The issue is happening here, when passing the parameters for Python Can Wrapper: self.can_interface = PythonCanWrapper(self, self.interface_name, config.timeout, **parameters) However the actual problem is in:

get_interface_parameters

My configuration is:

#
# Configuration file for pyXCP.
#
c = get_config()  # noqa

# ------------------------------------------------------------------------------
# Transport configuration
# ------------------------------------------------------------------------------

# Choose one of the supported XCP transport layers.
c.Transport.layer = "CAN"

# Alignment border.
c.Transport.alignment = 8

# raise `XcpTimeoutError` after `timeout` seconds if there is no response to a command.
c.Transport.timeout = 3.0

# Record time of frame reception or set timestamp to 0.
c.Transport.create_daq_timestamps = False

# ------------------------------------------------------------------------------
# General configuration
# ------------------------------------------------------------------------------

# Ignore missing response on DISCONNECT request.
c.General.disconnect_response_optional = False

# ------------------------------------------------------------------------------
# Application configuration
# ------------------------------------------------------------------------------

# Set the log level by value or name.
c.Application.log_level = "DEBUG"

# ------------------------------------------------------------------------------
# Transport.Can configuration
# ------------------------------------------------------------------------------

# CAN interface supported by python-can
c.Transport.Can.interface = "slcan"

# Enable self-reception of sent messages.
c.Transport.Can.use_default_listener = True

# Channel identification. Expected type and value is backend dependent.
c.Transport.Can.channel = "COM5"

# CAN bitrate in bits/s (arbitration phase, if CAN FD).
c.Transport.Can.bitrate = 500000

# CAN-ID master -> slave (Bit31= 1: extended identifier)
c.Transport.Can.can_id_master = 0x04

# CAN-ID slave -> master (Bit31= 1: extended identifier)
c.Transport.Can.can_id_slave = 0x03

# Auto detection CAN-ID (Bit31= 1: extended identifier)
c.Transport.Can.can_id_broadcast = 0xF4

# Master to slave frames always to have DLC = MAX_DLC = 8
c.Transport.Can.max_dlc_required = False

# One CAN identifier per DAQ-list.
c.Transport.Can.daq_identifier = [0x5, 0x6, 0x7]

# Bus timing value tseg1 (arbitration, TSEG1 if CAN classic).
c.Transport.Can.tseg1_abr = 8

# Bus timing value tseg2 (arbitration, TSEG2, if CAN classic)
c.Transport.Can.tseg2_abr = 4

# Bus timing value sample jump width (arbitration, SJW if CAN classic).
c.Transport.Can.sjw_abr = 4

However the CAN_PARAM_MAP for SlCan maps these config parameters to None, and therefore PythonCanWrapper is receiving "None" Parameters and failing.

 CAN_PARAM_MAP = {
        "sjw_abr": None,
        "tseg1_abr": None,
        "tseg2_abr": None,
        "sjw_dbr": None,
        "tseg1_dbr": None,
        "tseg2_dbr": None,
    }

[christoph2]

@SaxElectronics No, this is expected behaviour: CAN_PARAM_MAP contains the "usual" CAN parameters, but they may not supported by every driver, like slcan; s. here I.e. only if the value is not None, the parameter is passed to the CAN driver.

[SaxElectronics]

I understand the parameters are not supported by slcan, but they have been passed in my case to PythonCanWrapper and this one failed....which does not make a lot of sense. From my point the expected behavior should be: if the user defines these parameters for slcan, then either should

• through an error, that these parameters are NOT ok for slcan.
• or it should filter them out properly.

Perhaps good to double check? Have you tested with slcan and with the above configuration?

I.e. only if the value is not None, the parameter is passed to the CAN driver. ==> exactly this is the issue, if the value is NOT None, this is passed. and this is not ok. If the user defines a value then he should be informed slcan does nto support this configuration OR pyxcp should filter not relevant parameters on its own.

[christoph2]

@SaxElectronics OK, now there's a name and value (double-)checking.

[SaxElectronics]

great!