Macros are not portable when supporting more than one board/cpu

[rtic-rs]

Macros are not portable when supporting more than one board/cpu

[japaric]

Resources should only be declared in the final application crate. This is specially required for Peripherals because only one ceiling value must be assigned to each peripheral. That "this doesn't work" means that the peripherals! macro is doing its work correctly. If what you are trying to do was safely allowed then you would be able to potentially create Peripheral instances to the same physical peripheral instance (e.g. GPIOA) with possibly different ceiling values; that would break RTFM invariants and allow data races.

Board Support Crates should not depend on the cortex-m-rtfm crate; they should directly work with the register block types defined in the device crates. Just like the led::init and the other functions do.

[hmvp]

Yes I see how a different structure will lead to this not happening. In this case I wanted to move as much as possible to the BSP modules since the application was way smaller than the 'boilerplate' to set it up. I maybe should not have used the rtfm crate since I had only one task/function. But this was what the examples said and so I didn't try without rtfm.
Keeping it in the application crate should not be a problem for larger applications.

Do note that the peripherals I defined did not conflict. They used different 'svd crates' eg:

peripherals!(stm32f3x4, {
    GPIOA: Peripheral {
        register_block: Gpioa,
        ceiling: C0,
    },
}

and

peripherals!(stm32l4x6, {
    GPIOA: Peripheral {
        register_block: Gpioa,
        ceiling: C0,
    },
}

in the same crate will conflict even though they are for different cpus an will never be built into the same binary. Thus you cannot create a crate that builds the same app for two cpus. You always have to split it out into different crates.

Changing the macro to:

#[macro_export]
macro_rules! peripherals {
    ($device:ident, {
        $($PERIPHERAL:ident: Peripheral {
            register_block: $RegisterBlock:ident,
            ceiling: $C:ident,
        },)+
    }) => {
        $(
            #[allow(private_no_mangle_statics)]
            #[no_mangle]
            static $device_$PERIPHERAL:
                $crate::Peripheral<::$device::$RegisterBlock, $crate::$C> =
                    unsafe { $crate::Peripheral::_new(::$device::$PERIPHERAL) };
           // To be able to use the non prefixed name within this file
           use $device_$PERIPHERAL as $PERIPHERAL;
        )+
    }
}

(note the parts with $device_$PERIPHERAL)
might work and still be save (not tested, not even sure if it compiles)

[japaric]

Do note that the peripherals I defined did not conflict.

Those should be properly cfg-ed so that only one of them is visible when compiling for one device OR for the other. Otherwise your application would be able to use the GPIOA of one device and the GPIOA of the other device at the same time, which makes no sense.

In this case I wanted to move as much as possible to the BSP modules

The ceiling value varies per application if you move a resource into a dependency you have to pick a value beforehand and that limits the number of applications that dependency can be used for.

[TeXitoi]

This issue looks really outdated. @japaric closing it?