Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable EXTI interrupt dispatch support in stm32xx-sys #1691

Merged
merged 2 commits into from
Mar 29, 2024

Conversation

cbiffle
Copy link
Collaborator

@cbiffle cbiffle commented Mar 28, 2024

This adds code to sys to multiplex the frustratingly limited STM32 EXTI peripheral and provide arbitrary pin change interrupts to other tasks.

We're doing this in support of a Gimlet racktest debugging operation, and so this version is deliberately a bit limited. It will, in practice, only build in gimlet or sidecar, and will only watch PI14, and will only post a specific notification to the power task. @hawkw is working on making all that stuff configurable in parallel to my work.

For this to be useful, the power task needs to follow the instructions in the Theory Of Operation comment I've added to drv/stm32xx-sys/src/main.rs.

drv/stm32xx-sys/src/main.rs Outdated Show resolved Hide resolved
Comment on lines 105 to 244
// It's really tempting to try and not do this test on every
// loop iteration, isn't it? Too bad, these registers all
// have totally distinct types because of the PAC.
match register {
0 => syscfg.exticr1.modify(|_, w| match slot {
// Safety: field modeled incorrectly in PAC
0 => unsafe { w.exti0().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
1 => unsafe { w.exti1().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
2 => unsafe { w.exti2().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
_ => unsafe { w.exti3().bits(port as u8) },
}),
1 => syscfg.exticr2.modify(|_, w| match slot {
// Safety: field modeled incorrectly in PAC
0 => unsafe { w.exti4().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
1 => unsafe { w.exti5().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
2 => unsafe { w.exti6().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
_ => unsafe { w.exti7().bits(port as u8) },
}),
2 => syscfg.exticr3.modify(|_, w| match slot {
// Safety: field modeled incorrectly in PAC
0 => unsafe { w.exti8().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
1 => unsafe { w.exti9().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
2 => unsafe { w.exti10().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
_ => unsafe { w.exti11().bits(port as u8) },
}),
_ => syscfg.exticr4.modify(|_, w| match slot {
// Safety: field modeled incorrectly in PAC
0 => unsafe { w.exti12().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
1 => unsafe { w.exti13().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
2 => unsafe { w.exti14().bits(port as u8) },
// Safety: field modeled incorrectly in PAC
_ => unsafe { w.exti15().bits(port as u8) },
}),
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this whole block of code really makes me feel very positively about the PAC :/

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

YOU AND ME BOTH

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fortunately if we want to fix how the fields are modeled, all we have to do is construct a YAML file describing a diff we want to apply to another YAML file derived from an XML file that isn't checked into the repo.

@cbiffle cbiffle force-pushed the cbiffle/sys-exti-pi14-hack branch 2 times, most recently from 6be55f3 to 659f006 Compare March 28, 2024 21:53
@cbiffle cbiffle marked this pull request as ready for review March 28, 2024 21:53
@cbiffle cbiffle force-pushed the cbiffle/sys-exti-pi14-hack branch 2 times, most recently from 8fbb9ba to 8eadfde Compare March 28, 2024 22:21
@cbiffle
Copy link
Collaborator Author

cbiffle commented Mar 28, 2024

Sooooo I'm honestly kind of shocked that this didn't blow size allocations on the stm32g0 builds, but it does not appear to have done so.

I think this is ready for review.

Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, looks great! I had a few small nitpicks

drv/stm32xx-sys/src/main.rs Show resolved Hide resolved
drv/stm32xx-sys/src/main.rs Outdated Show resolved Hide resolved
drv/stm32xx-sys/src/main.rs Outdated Show resolved Hide resolved
drv/stm32xx-sys/src/main.rs Outdated Show resolved Hide resolved
drv/stm32xx-sys/src/main.rs Outdated Show resolved Hide resolved
drv/stm32xx-sys/src/main.rs Show resolved Hide resolved
idl/stm32xx-sys.idol Show resolved Hide resolved
@cbiffle
Copy link
Collaborator Author

cbiffle commented Mar 29, 2024

Rebased and applied requested fixes. Also expanded the docs a bit. (Still want to put docs somewhere other than the driver source code, but haven't done that yet.)

This adds a slightly-hacked-up EXTI driver for STM32H7. It is currently
statically configured to deliver interrupts from one pin to one task,
because that's what we initially needed. We are going to improve this.
@cbiffle cbiffle enabled auto-merge (rebase) March 29, 2024 18:38
@cbiffle cbiffle merged commit 4f29df0 into master Mar 29, 2024
103 checks passed
@cbiffle cbiffle deleted the cbiffle/sys-exti-pi14-hack branch March 29, 2024 19:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants