stm32-device-signature embassy port

[goldenMetteyya]

[goldenMetteyya]

Hello,

Ok I can remove the flash size. I have too see about the stm32-data crate.

[chemicstry]

The flash size is already available in bytes through the embassy_stm32::flash::FLASH_SIZE constant.

In a similar way, the device id might also be part of the stm32-data/metapac code generation instead.

There could be use cases where you would like to get flash size at runtime, i.e. using same family binary for multiple chips with different flash sizes. Not sure how common that is though.

The device id register contains a per-chip unique id so can't be part of compile time data.

IIRC device id register can also be decoded into multiple parts: chip id, wafer number, unique serial, etc

[chemicstry]

Also note that these register addresses are present in stm32-data sources (headers) as #define UID_BASE 0x1FFF7A10UL and #define FLASHSIZE_BASE 0x1FFF7A22UL so you could avoid all cfg's. Not sure how hard it would be to expose in pac. Going by general convention, you could create UID and FLASHSIZE peripherals with their registers xml's containing just the single register. Maybe @Dirbaio has thoughts on this.

[lulf]

The flash size is already available in bytes through the embassy_stm32::flash::FLASH_SIZE constant. In a similar way, the device id might also be part of the stm32-data/metapac code generation instead.

There could be use cases where you would like to get flash size at runtime, i.e. using same family binary for multiple chips with different flash sizes. Not sure how common that is though.

The device id register contains a per-chip unique id so can't be part of compile time data.

IIRC device id register can also be decoded into multiple parts: chip id, wafer number, unique serial, etc

Those are good points! But I still think the location of the registry should be generated by stm32-data, and then the HAL can provide a way to read that for all variants without any cfg's

[Dirbaio]

• I do think the address should come from stm32-data.
  • We're already doing a "create a magic peripheral" thing for VREFINTCAL https://github.com/embassy-rs/stm32-data/tree/main/data/extra/family
  • though IMO it's better if the address came from the headers?
  • all these addresses seem to be from some kind of "factory OTP" area. Does it have a name? Is the layout documented, or just random addresses for pieces of data within it? Perhaps we should create a peripheral for the whole "OTP" instead of many for each individual value.
• Having the flash size at runtime is useful, please don't remove it!
• No need to have a Cargo feature for this, it can be enabled by default. Features are only useful if they avoid compiling some big dep when not needed, it's not the case here.

[goldenMetteyya]

• I do think the address should come from stm32-data.

Similar to the flash size we can have the address come from the stm32data, but I'm not super sure the best way todo that, still learning:)

• We're already doing a "create a magic peripheral" thing for VREFINTCAL https://github.com/embassy-rs/stm32-data/tree/main/data/extra/family
• though IMO it's better if the address came from the headers?
• all these addresses seem to be from some kind of "factory OTP" area. Does it have a name? Is the layout documented, or just random addresses for pieces of data within it? Perhaps we should create a peripheral for the whole "OTP" instead of many for each individual value.
• Having the flash size at runtime is useful, please don't remove it!

I believe you can still get it from embassy_stm32::flash::FLASH_SIZE

• No need to have a Cargo feature for this, it can be enabled by default. Features are only useful if they avoid compiling some big dep when not needed, it's not the case here.

Removed this now

[ericyanush]

I've opened a PR embassy-rs/stm32-data#181 that adds these registers for all parts.