Closed YuhanLiin closed 2 years ago
Looks good to me, I'm accepting this as soon as I get clarification on the #[no_mangle]
change.
The main and ISR signatures used to have the export_name
attribute, which explicitly set the names of the signatures to main
and #ident_s
. My change makes those exported names into the names of the actual functions, and I use no_mangle
to ensure that those function names actually get exported.
When testing, I got an error like so:
Compiling msp430g2553-quickstart v0.1.0 (C:\msys64\home\William\Projects\MSP430\msptest\msp430g2553-quickstart)
error[E0308]: mismatched types
--> examples\blinky.rs:65:1
|
65 | #[interrupt]
| ^^^^^^^^^^^^
| |
| expected `!`, found `()`
| implicitly returns `()` as its body has no tail or `return` expression
|
= note: expected type `!`
found unit type `()`
= note: this error originates in the attribute macro `interrupt` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0308`.
error: could not compile `msp430g2553-quickstart` due to previous error
It seems to be caused by the !
on line 300 in the macros crate:
#unsafety fn #hash<'a>(#cs_param) -> ! {
I'm not sure how to use quote!
to "inject -> type
if a type was provided on the interrupts signature, otherwise inject nothing". Can this be done using what syn::parse
returns, or will I need to match on whether a return type was provided and generate two different pieces of code depending on the type?
Hold on interrupts shouldn't even return !
. Before they just returned nothing. That's an oversight on my part.
@YuhanLiin Well, it should be fine for now- I allow returning nothing or !
. If this ends up being a bug, we can fix it later.
Are there any cases where returning !
from interrupts makes sense? That means the code gets stuck inside the interrupt right?
cortex-m-rt
uses !
for certain faults that you can't recover from. I don't remember offhand if MSP430 has a dedicated vector for e.g. "illegal memory access" or if it just goes back to NMI.
Well it doesn't hurt to have the option (and it's not a footgun since users have to write out the return type explicitly).
Related to https://github.com/rust-embedded/msp430/pull/9.
bare-metal
version 1.0 introduces a lifetime param onCriticalSection
and requires that lifetime to be constrained so that it's not static. This change places such constraints on theCriticalSection
s provided bymain
and ISRs.