Internal API¶
Here we document the odds and ends that are more helpful for creating your own interfaces or listeners but generally shouldn’t be required to interact with python-can.
BusABC¶
The BusABC class, as the name suggests, provides an abstraction of a CAN bus.
The bus provides a wrapper around a physical or virtual CAN Bus.
An interface specific instance of the BusABC is created by the Bus
class, see Bus for the user facing API.
Extending the BusABC class¶
- Concrete implementations must implement the following:
send()to send individual messages_recv_internal()to receive individual messages (see note below!)set the
channel_infoattribute to a string describing the underlying bus and/or channel
- They might implement the following:
flush_tx_buffer()to allow discarding any messages yet to be sentshutdown()to override how the bus should shut down_send_periodic_internal()to override the software based periodic sending and push it down to the kernel or hardware._apply_filters()to apply efficient filters to lower level systems like the OS kernel or hardware._detect_available_configs()to allow the interface to report which configurations are currently available for new connections.state()property to allow reading and/or changing the bus state.
Note
TL;DR: Only override _recv_internal(),
never recv() directly.
Previously, concrete bus classes had to override recv()
directly instead of _recv_internal(), but that has
changed to allow the abstract base class to handle in-software message
filtering as a fallback. All internal interfaces now implement that new
behaviour. Older (custom) interfaces might still be implemented like that
and thus might not provide message filtering:
Concrete instances are usually created by can.Bus() which takes the users
configuration into account.
Bus Internals¶
Several methods are not documented in the main can.BusABC
as they are primarily useful for library developers as opposed to
library users.
- abstractmethod BusABC.__init__(channel, can_filters=None, **kwargs)[source]¶
Construct and open a CAN bus instance of the specified type.
Subclasses should call though this method with all given parameters as it handles generic tasks like applying filters.
- Parameters:
- Raises:
ValueError – If parameters are out of range
CanInterfaceNotImplementedError – If the driver cannot be accessed
CanInitializationError – If the bus cannot be initialized
- BusABC.__iter__()[source]¶
Allow iteration on messages as they are received.
for msg in bus: print(msg)
- BusABC.__weakref__¶
list of weak references to the object
- BusABC._recv_internal(timeout)[source]¶
Read a message from the bus and tell whether it was filtered. This methods may be called by
recv()to read a message multiple times if the filters set byset_filters()do not match and the call has not yet timed out.New implementations should always override this method instead of
recv(), to be able to take advantage of the software based filtering provided byrecv()as a fallback. This method should never be called directly.Note
This method is not an @abstractmethod (for now) to allow older external implementations to continue using their existing
recv()implementation.Note
The second return value (whether filtering was already done) may change over time for some interfaces, like for example in the Kvaser interface. Thus it cannot be simplified to a constant value.
- Parameters:
- Returns:
a message that was read or None on timeout
a bool that is True if message filtering has already been done and else False
- Raises:
CanOperationError – If an error occurred while reading
NotImplementedError – if the bus provides it’s own
recv()implementation (legacy implementation)
- Return type:
- BusABC._apply_filters(filters)[source]¶
Hook for applying the filters to the underlying kernel or hardware if supported/implemented by the interface.
- Parameters:
filters (Sequence[CanFilter] | None) – See
set_filters()for details.- Return type:
None
- BusABC._send_periodic_internal(msgs, period, duration=None, autostart=True, modifier_callback=None)[source]¶
Default implementation of periodic message sending using threading.
Override this method to enable a more efficient backend specific approach.
- Parameters:
period (float) – Period in seconds between each message
duration (float | None) – The duration between sending each message at the given rate. If no duration is provided, the task will continue indefinitely.
autostart (bool) – If True (the default) the sending task will immediately start after creation. Otherwise, the task has to be started by calling the tasks
start()method on it.
- Returns:
A started task instance. Note the task can be stopped (and depending on the backend modified) by calling the
stop()method.- Return type:
- static BusABC._detect_available_configs()[source]¶
Detect all configurations/channels that this interface could currently connect with.
This might be quite time consuming.
May not to be implemented by every interface on every platform.
- Returns:
an iterable of dicts, each being a configuration suitable for usage in the interface’s bus constructor.
- Return type:
Sequence[AutoDetectedConfig]
About the IO module¶
Handling of the different file formats is implemented in can.io.
Each file/IO type is within a separate module and ideally implements both a Reader and a Writer.
The reader extends can.io.generic.MessageReader, while the writer extends
can.io.generic.MessageWriter, a subclass of the can.Listener,
to be able to be passed directly to a can.Notifier.
Adding support for new file formats¶
This assumes that you want to add a new file format, called canstore. Ideally add both reading and writing support for the new file format, although this is not strictly required.
Create a new module: can/io/canstore.py (or simply copy some existing one like can/io/csv.py)
Implement a reader
CanstoreReaderwhich extendscan.io.generic.MessageReader. Besides from a constructor, only__iter__(self)needs to be implemented.Implement a writer
CanstoreWriterwhich extendscan.io.generic.MessageWriter. Besides from a constructor, onlyon_message_received(self, msg)needs to be implemented.Add a case to
can.io.player.LogReader’s__new__().Document the two new classes (and possibly additional helpers) with docstrings and comments. Please mention features and limitations of the implementation.
Add a short section to the bottom of doc/listeners.rst.
Add tests where appropriate, for example by simply adding a test case called class TestCanstoreFileFormat(ReaderWriterTest) to test/logformats_test.py. That should already handle all of the general testing. Just follow the way the other tests in there do it.
Add imports to can/__init__py and can/io/__init__py so that the new classes can be simply imported as from can import CanstoreReader, CanstoreWriter.
IO Utilities¶
This module provides abstract base classes for CAN message reading and writing operations to various file formats.
Note
All classes in this module are abstract and should be subclassed to implement specific file format handling.
- class can.io.generic._IoTypeVar¶
type parameter used in generic classes
MessageReaderandMessageWriteralias of TypeVar(‘_IoTypeVar’, bound=
IO[Any] |TextIOWrapper|BufferedIOBase)
- class can.io.generic.MessageWriter(file, **kwargs)[source]¶
Bases:
AbstractContextManager[MessageWriter],Listener,ABCAbstract base class for all CAN message writers.
This class serves as a foundation for implementing different message writer formats. It combines context manager capabilities with the message listener interface.
- Parameters:
- class can.io.generic.SizedMessageWriter(file, **kwargs)[source]¶
Bases:
MessageWriter,ABCAbstract base class for message writers that can report their file size.
This class extends
MessageWriterwith the ability to determine the size of the output file.
- class can.io.generic.FileIOMessageWriter(file, **kwargs)[source]¶
Bases:
SizedMessageWriter,Generic[_IoTypeVar]Base class for writers that operate on file descriptors.
This class provides common functionality for writers that work with file objects.
- Parameters:
file (_IoTypeVar) – A path-like object or file object to write to
kwargs (Any) – Additional keyword arguments for specific writer implementations
- Variables:
file – The file object being written to
- class can.io.generic.TextIOMessageWriter(file, mode='w', **kwargs)[source]¶
Bases:
FileIOMessageWriter[TextIO|TextIOWrapper],ABCText-based message writer implementation.
- Parameters:
file (_IoTypeVar) – Text file to write to
mode (OpenTextModeUpdating | OpenTextModeWriting) – File open mode for text operations
kwargs (Any) – Additional arguments like encoding
- class can.io.generic.BinaryIOMessageWriter(file, mode='wb', **kwargs)[source]¶
Bases:
FileIOMessageWriter[BinaryIO|BufferedIOBase],ABCBinary file message writer implementation.
- Parameters:
file (_IoTypeVar) – Binary file to write to
mode (OpenBinaryModeUpdating | OpenBinaryModeWriting) – File open mode for binary operations
kwargs (Any) – Additional implementation specific arguments
- class can.io.generic.MessageReader(file, **kwargs)[source]¶
Bases:
AbstractContextManager[MessageReader],Iterable[Message],ABCAbstract base class for all CAN message readers.
This class serves as a foundation for implementing different message reader formats. It combines context manager capabilities with iteration interface.
- Parameters:
- class can.io.generic.FileIOMessageReader(file, **kwargs)[source]¶
Bases:
MessageReader,Generic[_IoTypeVar]Base class for readers that operate on file descriptors.
This class provides common functionality for readers that work with file objects.
- Parameters:
file (_IoTypeVar) – A path-like object or file object to read from
kwargs (Any) – Additional keyword arguments for specific reader implementations
- Variables:
file – The file object being read from
- class can.io.generic.TextIOMessageReader(file, mode='r', **kwargs)[source]¶
Bases:
FileIOMessageReader[TextIO|TextIOWrapper],ABCText-based message reader implementation.
- Parameters:
file (_IoTypeVar) – Text file to read from
mode (OpenTextModeReading) – File open mode for text operations
kwargs (Any) – Additional arguments like encoding
- class can.io.generic.BinaryIOMessageReader(file, mode='rb', **kwargs)[source]¶
Bases:
FileIOMessageReader[BinaryIO|BufferedIOBase],ABCBinary file message reader implementation.
- Parameters:
file (_IoTypeVar) – Binary file to read from
mode (OpenBinaryModeReading) – File open mode for binary operations
kwargs (Any) – Additional implementation specific arguments
Other Utilities¶
Utilities and configuration file parsing.
- can.util.check_or_adjust_timing_clock(timing, valid_clocks)[source]¶
Adjusts the given timing instance to have an f_clock value that is within the allowed values specified by valid_clocks. If the f_clock value of timing is already within valid_clocks, then timing is returned unchanged.
- Parameters:
timing (T2) – The
BitTimingorBitTimingFdinstance to adjust.valid_clocks (Iterable[int]) – An iterable of integers representing the valid f_clock values that the timing instance can be changed to. The order of the values in valid_clocks determines the priority in which they are tried, with earlier values being tried before later ones.
- Returns:
A new
BitTimingorBitTimingFdinstance with an f_clock value within valid_clocks.- Raises:
CanInitializationError – If no compatible f_clock value can be found within valid_clocks.
- Return type:
T2
- can.util.deprecated_args_alias(deprecation_start, deprecation_end=None, **aliases)[source]¶
Allows to rename/deprecate a function kwarg(s) and optionally have the deprecated kwarg(s) set as alias(es)
Example:
@deprecated_args_alias("1.2.0", oldArg="new_arg", anotherOldArg="another_new_arg") def library_function(new_arg, another_new_arg): pass @deprecated_args_alias( deprecation_start="1.2.0", deprecation_end="3.0.0", oldArg="new_arg", obsoleteOldArg=None, ) def library_function(new_arg): pass
- Parameters:
deprecation_start (str) – The python-can version, that introduced the
DeprecationWarning.deprecation_end (str | None) – The python-can version, that marks the end of the deprecation period.
aliases (str | None) – keyword arguments, that map the deprecated argument names to the new argument names or
None.
- Return type:
- can.util.load_config(path=None, config=None, context=None)[source]¶
Returns a dict with configuration details which is loaded from (in this order):
config
can.rc
Environment variables CAN_INTERFACE, CAN_CHANNEL, CAN_BITRATE
Config files
/etc/can.confor~/.canor~/.canrcwhere the latter may add or replace values of the former.
Interface can be any of the strings from
can.VALID_INTERFACESfor example: kvaser, socketcan, pcan, usb2can, ixxat, nican, virtual.Note
The key
bustypeis copied tointerfaceif that one is missing and does never appear in the result.- Parameters:
path (str | PathLike[str] | None) – Optional path to config file.
config (dict[str, Any] | None) – A dict which may set the ‘interface’, and/or the ‘channel’, or neither. It may set other values that are passed through.
context (str | None) – Extra ‘context’ pass to config sources. This can be used to section other than ‘default’ in the configuration file.
- Returns:
A config dictionary that should contain ‘interface’ & ‘channel’:
{ 'interface': 'python-can backend interface to use', 'channel': 'default channel to use', # possibly more }
Note
Nonewill be used if all the options are exhausted without finding a value.All unused values are passed from
configover to this.- Raises:
CanInterfaceNotImplementedError if the
interfacename isn’t recognized- Return type:
BusConfig
- can.util.load_environment_config(context=None)[source]¶
Loads config dict from environmental variables (if set):
CAN_INTERFACE
CAN_CHANNEL
CAN_BITRATE
CAN_CONFIG
if context is supplied, “_{context}” is appended to the environment variable name we will look at. For example if context=”ABC”:
CAN_INTERFACE_ABC
CAN_CHANNEL_ABC
CAN_BITRATE_ABC
CAN_CONFIG_ABC
- can.util.load_file_config(path=None, section='default')[source]¶
Loads configuration from file with following content:
[default] interface = socketcan channel = can0
- can.util.time_perfcounter_correlation()[source]¶
Get the perf_counter value nearest to when time.time() is updated
Computed if the default timer used by time.time on this platform has a resolution higher than 10μs, otherwise the current time and perf_counter is directly returned. This was chosen as typical timer resolution on Linux/macOS is ~1μs, and the Windows platform can vary from ~500μs to 10ms.
Note this value is based on when time.time() is observed to update from Python, it is not directly returned by the operating system.