SeeedBus: Allow setting hardware filter/mask during Bus Init
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 55/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bien especificado
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- embedded-iot, networking
Línea de trabajo
Comienza en SeeedBus.init y en la ruta interna init_frame() descrita en el issue. Traza cómo se inicializan actualmente filter_id y mask_id y cómo se envían al hardware; después, verifica que los valores opcionales configuren el filtro durante la construcción, mientras que los valores omitidos mantengan el comportamiento actual sin filtrar.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Main Problem
I don't like that the SeeedBus interface does not allow for the configuration of the hardware acceptance filter and mask during the bus initialization.
My use case involves a bootloader flasher client that communicates with a device over the CAN bus. The client sends a message with one CAN ID and needs to listen only for a response on another specific CAN ID. To achieve this efficiently, I need to use the hardware filter. The current implementation forces me to create the bus object, then manually change its internal attributes (filter_id, mask_id), and then re-call the internal init_frame() method. This workflow is not intuitive and feels like a workaround.
Current Alternative
The only alternative at the moment is to manually re-configure the bus after it has been created. This involves the following steps:
import struct
# 1. Create the bus with default (disabled) filters
bus = can.interface.Bus(interface='seeedstudio', channel='/dev/ttyUSB0')
# 2. Manually overwrite the internal attributes
bus.filter_id = struct.pack('<I', 0x456 << 21)
bus.mask_id = struct.pack('<I', 0xFFFFFFFF)
# 3. Call the internal init_frame() method again to send the new config to the hardware
bus.init_frame()
This is not an ideal solution because it is recalling init_frame() method again after it is called in init, and is little more complicated.
Want to change Like this
I would like to have filter_id and mask_id added as optional keyword arguments to the SeeedBus.init method. This would allow the hardware filter to be configured cleanly and directly when the bus is created.
Example of the desired usage:
Python
# Initialize the bus to only accept messages with ID 0x456
bus = can.interface.Bus(
interface='seeedstudio',
channel='/dev/ttyUSB0',
bitrate=500000,
frame_type='STD',
filter_id=0x456,
mask_id=0xFFFFFFFF
)
# The bus is now ready to use with the hardware filter active.
msg = bus.recv()
Note: If the filter_id and mask_id arguments are not provided, they will default to 0x00. This maintains the current behavior where the filter is disabled and all CAN IDs are received, ensuring the change is fully backward-compatible.
# Initialize the bus
# Filter ID, Mask ID here defaults to 0x00 so no filtering of can messages
bus = can.interface.Bus(
interface='seeedstudio',
channel='/dev/ttyUSB0',
bitrate=500000,
frame_type='STD',
)
# The bus is now ready to use with the hardware filter active.
msg = bus.recv()
This feature request originated from my work on a project using a Waveshare USB to CAN Adapter (Model A). This device works perfectly with the seeedstudio interface as it uses the same serial protocol. The lack of an initial filtering mechanism was the primary challenge I faced.
Adding this feature would be a significant improvement for any application that needs to use hardware filtering with Seeed Studio or compatible devices. I am currently working on this feature by cloning the repo, making the changes, and am prepared to submit a pull request to resolve this issue.
- Lenguaje dominante
- Python
- Estrellas
- 1.6k
- Forks
- 697
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de hardbyte/python-can
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
hardbyte/python-can#2103 ·
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
hardbyte/python-can#2077 · 1 comentario · 1 reacción ·
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
hardbyte/python-can#1922 · 1 reacción ·
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
hardbyte/python-can#2102 ·
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
hardbyte/python-can#2092 ·
Todos los issues de hardbyte/python-can
Issues similares
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
canonical/paas-charm#368 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
tech debt
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
addition to tracking list Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
StevenBlack/hosts#3256 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
qualcomm/qai-appbuilder#275 ·