search

embassy-rs / stm32-data

75 stars 109 forks source link

Missing implementation of SAI for sai1_v1_2 #367

Closed Cryowatt closed 9 months ago

Cryowatt commented 9 months ago

I'm working with an STM32F723 which supports SAI, but the version is v1_2. If I'm following the logic of how the stm32-metapac is created, there should be a matching entry in the PERIMAP, as seen here: https://github.com/embassy-rs/stm32-data/blob/6d4ee04c7d5fd26638c520a0377614dc25339abb/stm32-data-gen/src/chips.rs#L275-L279

I have a few questions around the implementation here. First is the SAI versions (V1 through V4). Are these completely unrelated to the STM implementations? The mapping of sai1_v1_0 -> v1 and sai1_v1_1 -> v2 but sai1_v2_0 -> v1? From the semver standpoint, none of this makes sense. Second, the cubedb file has sai1_v1_2 for my target MCU, does anyone know if STM publishes the changelist for what v1_2 would include? If it's actually just a minor revision, then I'd be happy with adding a mapping to v2(?) to get the basic functionality I need. If it's not just a minor revision, then I suppose I'd have to add a V5 implementation here?

Dirbaio commented 9 months ago

First is the SAI versions (V1 through V4). Are these completely unrelated to the STM implementations?

yes, the v1-v4 are set by this project. Usually higher number is chronologically newer, but sometimes higher number is more features but chronologically older.

The mapping of sai1_v1_0 -> v1 and sai1_v1_1 -> v2 but sai1_v2_0 -> v1? From the semver standpoint, none of this makes sense

we don't follow semver. if the registers are different, the version number gets incremented by one. I don't know what logic ST follows to name their versions, but I wouldn't be surprised if it was non-semver nonsense too.

Also note ST's versions in cubedb are more like "C HAL versions", or "version of the #defines they have to generate to configure the HAL", since stm32cube mostly concerns itself with C project generation. Often different chips have different cubedb version but the registers are identical. stm32-data only concerns itself about the registers, so we mark them as the same version even if they're different in cubedb.

does anyone know if STM publishes the changelist for what v1_2 would include?

sometimes ST publishes version overviews in appnotes, such as this one for SPI. there may or may not be one for SAI, the version numbers may or may not match the cubedb ones... :(

If it's actually just a minor revision, then I'd be happy with adding a mapping to v2(?) to get the basic functionality I need. If it's not just a minor revision, then I suppose I'd have to add a V5 implementation here?

follow the steps in the readme to extract SAI register yamls from all the SVDs. Then diff them between themselves. If you're lucky you'll find the SAI registers in F7 are identical to another family that we already have registers for, in which case you can add an entry mapping the F7 version sai1_v1_2 to that version. If not you'll have to add a new version, yes.

Cryowatt commented 9 months ago

Good news, sai_v1_2 was identical to the sai_v1_1 (V2) implementation.