MCP2515 hardware masks are too strict
Maintainers usually reply within 1 day
A pull request for this has already been merged.
- #61 by @Tichael — merged
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- rust
- Domain
- embedded-iot
Research direction
Read compute_mcp_masks in boards/esp/src/can.rs around line 617 and the two_filters_ored_into_mask0 test. Check how masks are combined and written for standard IDs, then update the calculation and test for the stated extended-ID fallback. Done means the test covers the corrected behavior and hardware masks no longer reject frames accepted by the software filter.
Written by the indexing model from the issue text.
Description
compute_mcp_masks (boards/esp/src/can.rs:617) still ORs the per-filter
masks; its doc comment describes AND. OR makes the hardware reject frames the
software filter accepts: 0x100/0x700 + 0x200/0x0FF → 0x7FF, so only two
exact IDs pass. The test two_filters_ored_into_mask0 locks in the bug.
Extended IDs aren't handled either (masks are written as standard IDs).
Fix: AND the masks (a bit must match only if every filter in that buffer cares
about it). Fall back to accept-all hardware masks when any filter is extended
(the software filter still applies). Update the test.
- Dominant language
- Rust
- Stars
- 1
- Forks
- 0
- Avg merge
- 10h 56m
- Merged PRs (30d)
- 15
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenCarControls/firmware
-
Clean up E-GMP leftoversPossibly taken @Tichael claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
OpenCarControls/firmware#34 ·
Maintainers usually reply within 1 day
-
BLE: send the current state when the app subscribesPossibly taken @Tichael claimed this today. Open
Difficulty 3/5 1-2 days Newbie friendliness 35/100
OpenCarControls/firmware#58 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
OpenCarControls/firmware#55 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
OpenCarControls/firmware#54 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 55/100
OpenCarControls/firmware#53 ·
Maintainers usually reply within 1 day
All issues in OpenCarControls/firmware
Similar issues
-
Difficulty 1/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
area:sim good first issue kind:feature
Difficulty 2/5 1-3 hours Newbie friendliness 87/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
bitcoindevkit/bdk#2432 ·
Maintainers usually reply within 3 days
-
The demo's interval button and chart legend keep the previous interval after an interval changeOpenbug ui
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
userFRM/egui-charts#670 ·
Maintainers usually reply within 1 day
-
docs good first issue
Difficulty 1/5 1-3 hours Newbie friendliness 84/100
Usenova-Labs/usenova-backend#35 ·
Maintainers usually reply within 1 day