SeeedBus: Allow setting hardware filter/mask during Bus Init
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 55/100
- Tipo de issue
- Funcionalidade
- Clareza
- Claramente especificada
- Status de atividade
- Estagnada
- Stack de tecnologia
- python
- Domínio
- embedded-iot, networking
Direção de pesquisa
Comece em SeeedBus.init e no caminho interno init_frame() descrito na issue. Rastreie como filter_id e mask_id são atualmente inicializados e enviados ao hardware e, em seguida, verifique se os valores opcionais configuram o filtro durante a construção, enquanto os valores omitidos preservam o comportamento atual sem filtro.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- Python
- Estrelas
- 1.6k
- Forks
- 697
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de hardbyte/python-can
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
hardbyte/python-can#2103 ·
-
bug
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 78/100
hardbyte/python-can#2077 · 1 comentário · 1 reação ·
-
bug
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 68/100
hardbyte/python-can#1922 · 1 reação ·
-
enhancement
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 30/100
hardbyte/python-can#2102 ·
-
bug
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 68/100
hardbyte/python-can#2092 ·
Todas as issues de hardbyte/python-can
Issues semelhantes
-
area: harness bug status: needs-triage
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
Human-Agent-Society/reef#625 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 80/100
learningequality/kolibri#15351 · 2 comentários ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
Name consistency Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
eellak/triplestore#65 · 1 comentário ·