Closed katyo closed 2 years ago
Hmm, weird. I'm not sure why Peripherals
isn't being re-exported properly. When I've used stm32ral with rtic, I have:
#[rtic::app(device=stm32ral::stm32f1::stm32f103, peripherals=true)]
which seems to work fine, and I don't touch the Peripherals
struct myself at all. I'll try and figure out where Peripherals is going but it's not obvious at first glance...
Incidentally, you almost certainly want the rt
feature enabled as well.
@adamgreig Of course, thanks :+1:
I figured out the cause of this issue; both stm32ral::cortex_m::arm7m
and stm32ral::stm32f1::stm32f103
(for example) export a Peripherals
type, so the glob import somehow ends up importing neither and just says Peripherals
isn't available. Inside a single module it detects this ambiguity and throws an error, but when it's an external crate it seems it doesn't know how to tell you about it. I didn't have much luck finding an actual reference for this behaviour.
Ultimately this probably needs a different generation of the cortex-m shared peripherals (e.g. how some things name them CorePeripherals and DevicePeripherals) but for now I think your best bet is to refer to it by the full path or use it from stm32ral::stm32f1::stm32f103
as you've done.
How about re-exporting things via submodules like a stm32ral::core::Peripherals
and stm32ral::device::Peripherals
?
This is now fixed in v0.8.0 by renaming the cortex-m peripherals to CorePeripherals, thanks for the report!
If I understand correct when device feature is used ("stm32f103" in my case) the types from corresponding submodule (i.e. from
stm32f1::stm32f103
) is available from crate's root. But seems something went wrong in my case:My manifest looks like:
I generated doc to see the re-exports. It looks as expected:
Import from
stm32f1::stm32f103
works fine.