Distributor edge generator re-anchoring stretches the CKP period ~0.2%
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 75/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- embedded-iot
Research direction
Start in src/engine.rs at EngineState::check_distributor_pulses and inspect how last_int0_cycle and cycles_per_ckp are used. Adjust the timing anchor so the CKP period preserves its remainder rather than snapping to total_cycles, while retaining the documented single pending SFR_IRQ behavior. Done means the measured CKP rate approaches the 1100/s ideal without reintroducing edge loss.
Written by the indexing model from the issue text.
Description
Carried over from the previous session's task "Fix interrupt-edge coalescing (CKP/CYP edge loss)" — the loss-causing parts are already fixed and verified; what remains is a small, bounded timing-fidelity nit.
Already fixed (no edge loss observed)
- Edges arriving while interrupts are blocked are latched, not dropped:
handle_pending_interruptsORs incoming edges intoSFR_IRQbefore checking MIE/IE (src/interrupts.rs), with regression testpending_edges_remain_latched_while_interrupts_are_blocked. Landed in 773e6ca. - CYP cannot be missed: it is delivered as a sticky transition-detector status bit (
SFR_TRNS (0x46).0,bus::signal_cyp) that the ROM read-clears in its TDC ISR. Landed in 0de4569. - Measured at steady 5500 rpm: CKP 1098/s (ideal 1100), TDC 183/s (ideal 183.3), CYP sync 45/s — no loss; CPU not interrupt-starved (92.7% main context).
Residual nit (this issue)
EngineState::check_distributor_pulses (src/engine.rs) emits at most one CKP edge per call and re-anchors last_int0_cycle = total_cycles. Since it runs once per instruction, each CKP period is stretched by up to one instruction's cycles — the measured ~0.2% shortfall (1098/s vs 1100/s). Fix is to advance the anchor by cycles_per_ckp (carrying the remainder) instead of snapping to total_cycles.
Note: two edges of the same source arriving before service still merge into one pending SFR_IRQ bit — that is faithful to the real hardware's single request flag and should not be "fixed".
- Dominant language
- Rust
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
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 VIRUXE/hondaecu-cli
-
enhancement investigation
Difficulty 5/5 Over a week Newbie friendliness 35/100
VIRUXE/hondaecu-cli#10 · 1 comment ·
-
enhancement investigation
Difficulty 4/5 3-5 days Newbie friendliness 58/100
VIRUXE/hondaecu-cli#9 · 1 comment ·
-
emulation-core enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
VIRUXE/hondaecu-cli#8 · 2 comments ·
-
bug emulation-core
Difficulty 4/5 3-5 days Newbie friendliness 45/100
VIRUXE/hondaecu-cli#7 · 1 comment ·
-
bug investigation
Difficulty 5/5 Over a week Newbie friendliness 38/100
VIRUXE/hondaecu-cli#6 · 1 comment ·
All issues in VIRUXE/hondaecu-cli
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100