M-Labs/zynq-rs
11
0
Fork 15
Code Issues 6 Pull Requests Releases Wiki Activity

libcortex_a9: added interrupt_handler macro #77

Merged
sb10q merged 1 commits from pca006132/zynq-rs:master into master 2024-08-17 17:37:18 +08:00
Conversation 0 Commits 1 Files Changed 5 +39 -11
pca006132 commented 2021-01-28 11:06:14 +08:00
Contributor
Copy Link

Addresses #73.

The concern is that, normal functions require prologue before the actual function body, which push and pop from the stack, and function calls would modify the stack pointer. When those interrupts are called, the stack pointer should be 0, and I'm not entirely sure why the program works.

This commit added interrupt_handler macro. It would setup a interrupt handler to setup the stack pointer and jump to the actual interrupt handler, running normal rust function with C calling convention. The stack pointer location can be customized, but defaults to __stack0_start and __stack1_start for core0 and core1 respectively.

Due to limitation of rust macro, a name2 has to be provided to name the actual interrupt handler. (concat_idents is really useless as it can't be used in function definition...)

Addresses #73. The concern is that, normal functions require prologue before the actual function body, which push and pop from the stack, and function calls would modify the stack pointer. When those interrupts are called, the stack pointer should be 0, and I'm not entirely sure why the program works. This commit added `interrupt_handler` macro. It would setup a interrupt handler to setup the stack pointer and jump to the actual interrupt handler, running normal rust function with C calling convention. The stack pointer location can be customized, but defaults to `__stack0_start` and `__stack1_start` for core0 and core1 respectively. Due to limitation of rust macro, a `name2` has to be provided to name the actual interrupt handler. ([`concat_idents`](https://doc.rust-lang.org/std/macro.concat_idents.html) is really useless as it can't be used in function definition...)
sb10q reviewed 2021-01-28 11:17:32 +08:00
libcortex_a9/src/lib.rs Outdated
@ -38,0 +40,4 @@
/// - `name` is the name of the interrupt, should be the same as the one defined in vector table.
/// - `name2` is the name for the actual handler, should be different from name.
/// - `stack0` is the stack for the interrupt handler when called from core0, default to
/// `__stack0_start`.
sb10q commented 2021-01-28 11:17:32 +08:00
Owner
Copy Link

I don't get this. Won't it make interrupt handlers overwrite the main program's stack?

I don't get this. Won't it make interrupt handlers overwrite the main program's stack?
pca006132 commented 2021-01-28 11:19:36 +08:00
Author
Contributor
Copy Link

For the interrupts that we use now, they would never return to main program, so it does not matter.

If we need to avoid this later for some interrupts, we can provide two dedicated stacks for interrupts (1 for each core), and arguments can be provided to the macro to override the stack pointer location.

For the interrupts that we use now, they would never return to main program, so it does not matter. If we need to avoid this later for some interrupts, we can provide two dedicated stacks for interrupts (1 for each core), and arguments can be provided to the macro to override the stack pointer location.
sb10q commented 2021-01-28 11:30:07 +08:00
Owner
Copy Link

Okay I see. It is a very niche use case that we have, and it shouldn't be the default for the more general-purpose zynq-rs crate.
We may not even need to support this optimization since a few kilobytes of dedicated interrupt stack is nothing compared to the size of the SDRAM. And it avoids creating any confusion during debugging if we ever examine the main stack after the ISR has run.

Okay I see. It is a very niche use case that we have, and it shouldn't be the default for the more general-purpose zynq-rs crate. We may not even need to support this optimization since a few kilobytes of dedicated interrupt stack is nothing compared to the size of the SDRAM. And it avoids creating any confusion during debugging if we ever examine the main stack after the ISR has run.
pca006132 force-pushed master from 4ff5d16691 to 06c646e61f 2021-01-28 11:41:38 +08:00 Compare
sb10q reviewed 2021-01-28 11:44:18 +08:00
libsupport_zynq/src/abort.rs Outdated
@ -5,3 +5,1 @@
#[link_section = ".text.boot"]
#[no_mangle]
pub unsafe extern "C" fn UndefinedInstruction() {
interrupt_handler!(UndefinedInstruction, undefined_instruction, __stack0_start, __stack1_start, {
sb10q commented 2021-01-28 11:44:18 +08:00
Owner
Copy Link

I think we probably want to inspect the main stack when this happens... so it should not get mangled.

I think we probably want to inspect the main stack when this happens... so it should not get mangled.
sb10q reviewed 2021-01-28 12:24:50 +08:00
experiments/src/main.rs Outdated
@ -56,3 +58,1 @@
#[link_section = ".text.boot"]
#[no_mangle]
pub unsafe extern "C" fn IRQ() {
interrupt_handler!(IRQ, irq, __stack0_start, __stack1_start, {
sb10q commented 2021-01-28 12:24:50 +08:00
Owner
Copy Link

Still the main stack?

Still the main stack?
pca006132 commented 2021-01-28 12:33:26 +08:00
Author
Contributor
Copy Link

sorry I forgot this one, fixed.

sorry I forgot this one, fixed.
pca006132 force-pushed master from 8dd68d262d to 78d58d17ec 2021-01-28 12:33:09 +08:00 Compare
sb10q merged commit 78d58d17ec into master 2021-01-28 12:34:14 +08:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/zynq-rs#77
No description provided.
Delete Branch "pca006132/zynq-rs:master"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?