cpu: use shared Cortex-M base vector table#7535
cpu: use shared Cortex-M base vector table#7535haukepetersen merged 2 commits intoRIOT-OS:masterfrom
Conversation
|
I like this one ! |
|
merged. |
jnohlgard
left a comment
There was a problem hiding this comment.
I like the idea, and it should reduce the risk of errors in the vectors by reducing the amount of code duplication.
| &_estack, | ||
| { | ||
| /* entry point of the program */ | ||
| [ 0] = reset_handler_default, |
|
Nice one! |
|
See haukepetersen#41, haukepetersen#42 and and haukepetersen#43 for f2, f3 and f7. I think f1 is already ok. f0 and f4 will be a pain. |
74d1307 to
83272cf
Compare
|
I think I have something better: why don't we just generate these tables from the CMSIS headers directly?! -> #7553 So I tend to take the cleanup changes out of this PR and have separate PRs for each CPU family (see #7554 as example)... @aabadie: I hope this is not going against all the effort you already put in for cleaning up those definitions?! Would this approach work for you? |
No problem, I like the idea of the tool. It makes it simpler and probably more error proof than the manual update (see the STM32F4 case for example...). |
83272cf to
3ede8e9
Compare
|
rebased. Can we proceed with this PR? |
smlng
left a comment
There was a problem hiding this comment.
tested with boards remote-revb, arduino-due, and pba-d-01-kw2x (aka PhyNode) and examples/default, all still work as expected. So (semi-)tested ACK, any others tests recommended?
|
@haukepetersen feel free to merge, if you (still) think this is ready to go, no objections from me. |
|
let's go then! |
@kaspar030 and me finally found a very nice solution for sharing the Cortex-M vector table between all the Cortex-M based CPUs in RIOT. We simply split the table into chunks and add them separately to the vector table linker section, adding a numeric value as sub-section name for making sure the correct order is used.
This approach does further enable CPUs to even split up their CPU specific ISR vector table, allowing for more re-use.
Also, this approach enables to define the CPU specific vectors 'out-of-order', so that reserved fields do not have to be defined explicitly. See
cpu/stm32l4/vectors.cas example.