add some missing SPI1 pins for stm32f765

[tstellanova]

Not sure if there's a better place to inject these -- maybe in an SVD correction?

[hannobraun]

No, this should be the right place, thank you!

My main concern is whether these pins are available on all supported target (as your change makes them available everywhere), or whether we need to restrict this to some of the available targets (example).

[tstellanova]

No, this should be the right place, thank you!

My main concern is whether these pins are available on all supported target (as your change makes them available everywhere), or whether we need to restrict this to some of the available targets (example).

That's my concern as well. I just spot-checked the STM32F730x8 datasheet (DM00493485) and the STM32F722 datasheet (DS11853) and I can see that these SPI1 pins are not supported by those MCUs. If I understand correctly the SVD does not provide this info, so I guess we're stuck with manually mapping the allowed pin AFs.

Given that's the case, and since it doesn't look like the macros used in this file are composable (can't override one SPI1 declaration with another), one idea would be to split the device families further in this file. Any guidance or suggestions on how to split these up?

[tstellanova]

Based on what I see in the stm32f7 family description, I'm guessing that a good split (for SPI1 at least) might be between f7x0 + f7x2 + f7x3 and everything else.

[hannobraun]

I haven't thought about this in a while and don't have the time to look into it right now, so I can't give any guidance right now, sorry.

One thing I saw but didn't really look into is this: https://github.com/dbrgn/cube-parse
It's been used here, for example: stm32-rs/stm32l0xx-hal#87

If I understand this correctly, this generates all the correct the feature gates automatically. I don't know how hard it would be to apply that here. I guess it would be the ideal solution, if you wanted to look into that. If not, it would probably be better to merge the fix for whatever problem you're having, without trying to get it perfect for everyone.

Thoughts, @mvertescher?

[mvertescher]

If not, it would probably be better to merge the fix for whatever problem you're having, without trying to get it perfect for everyone.

Yeah, this makes sense to me. I'll merge this and create an issue to follow up on the correct pin split.

Thanks for looking into this @tstellanova!