Unfortunately we cannot reliably use a whitelist of MCU ref names to detect the proper EEPROM size / address in a future-proof way. If ST releases new MCUs, this variable will be wrong and a user would need to fork and adjust the source code of the flash.rs module. We need another way to get this information that can be easily adapted to future MCUs.
This PR contains new eeprom-* Cargo features generated with cube-parse: https://github.com/dbrgn/cube-parse/ The mcu-* features contain aliases to the proper eeprom-* feature.
This way, for every currently known MCU, we can determine the correct EEPROM size. Additionally, if the HAL does not support a certain MCU yet, this functionality can be enabled by manually adding the appropriate eeprom-* feature to the HAL dependency, without needing to fork and adjust the HAL source code itself.
Alternative Designs
Instead of generating EEPROM size features, we could base the entire logic on product categories. I'm fairly certain that the io-* features map 1:1 to product categories, but I'm not 100% sure. We could use this to generate proper product-category-X features, but on the other hand I find dedicated eeprom-* features cleaner (and it doesn't break if ST all of a sudden releases a device with an EEPROM size that doesn't fit into the product category grouping).
Changes
Unfortunately we cannot reliably use a whitelist of MCU ref names to detect the proper EEPROM size / address in a future-proof way. If ST releases new MCUs, this variable will be wrong and a user would need to fork and adjust the source code of the
flash.rsmodule. We need another way to get this information that can be easily adapted to future MCUs.This PR contains new
eeprom-*Cargo features generated with cube-parse: https://github.com/dbrgn/cube-parse/ Themcu-*features contain aliases to the propereeprom-*feature.This way, for every currently known MCU, we can determine the correct EEPROM size. Additionally, if the HAL does not support a certain MCU yet, this functionality can be enabled by manually adding the appropriate
eeprom-*feature to the HAL dependency, without needing to fork and adjust the HAL source code itself.Alternative Designs
Instead of generating EEPROM size features, we could base the entire logic on product categories. I'm fairly certain that the
io-*features map 1:1 to product categories, but I'm not 100% sure. We could use this to generate properproduct-category-Xfeatures, but on the other hand I find dedicatedeeprom-*features cleaner (and it doesn't break if ST all of a sudden releases a device with an EEPROM size that doesn't fit into the product category grouping).