oxidecomputer / oxidecomputer/hubris
monitoring fault/alert nets
@hawkw is already working on this.
Since Apr 4, 2024.
- Dominant language
- Rust
- Stars
- 3.6k
- Forks
- 239
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 23
Description
After merging #1691 and #1693, we now have the ability to receive interrupts from STM32 GPIO pin changes. The motivation for implementing this was mostly to handle the MAX5970 PWR_CONT1_VCORE_TO_SP_ALERT_L line and record that part's state in the ringbuf with a higher time resolution when that pin is asserted (see #1546). However, it occurred to me that we have several more EXTI slots left, and that there are probably other alert/fault nets routed to the SP. If we're not using most of the 16 EXTI slots, it seems to me that we may as well be monitoring as many fault/alert lines as we can get our hands on. In the short term, we can just count these, so that you can look at `em in Humility, but eventually it would be nice to wire them upstack (maybe through the Sensor task or something).
Because of the way that EXTI works, it's possible that some pins will be mutually exclusive --- each pin number can have a single interrupt, which can be assigned to any one port. So, we couldn't have an interrupt for both PC14 and PC14, for example. So, there will likely be a need to prioritize which lines should be monitored in this way. I don't have a great sense for what lines we'd be the most interested in recording, so I would love input from others on that.
Contributor 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.
Assessment
This issue has not been assessed yet.