Ah, main availability won't be until September and it looks like CubeMX (and hence the packs containing the SVD files) won't be around until then. I expect it'll appear at https://github.com/STMicroelectronics/STM32CubeU5

Update from September: the GitHub repo exists and has C headers, but no sign of an SVD file there or on st.com yet.

Seems like they heard you talking about it; available here, uploaded on the same day. 😅

Just being curious: what do you think is a typical / reasonable timeline for a dedicated crate for this MCU? :) .

I have no need for the chip now, so I won't be writing anything (unless I'm paid to do so).

I've got my hands on a STM32U575ZI (on a NUCLEO-U575ZI-Q) and would like to work on the rust support.

I've followed the steps in the "Adding New Devices" section in the README:

1. add this svd file
2. run svd/extract.sh
3. add svd patch yaml, without any patches, just the path
4. try to run scripts/matchperipherals.py, but it errors with TypeError: append() argument must be xml.etree.ElementTree.Element, not lxml.etree._Element
5. run scripts/makecrates.py devices/
6. run SVDTOOLS=svd make, but that errors with following error:

   cd stm32u5/src/stm32u5; svd2rust -m -g --strict --pascal_enum_values -i ../../../svd/stm32u5.svd.patched
   [INFO  svd2rust] Parsing device from SVD file
   [ERROR svd2rust] Error parsing SVD XML file
   
       Caused by:
           0: In device `STM32U5xx`
           1: In peripheral `TIM1`
           2: In register `TIM1_SMCR`
           3: Parsing field `SMS1` at 109654:15
           4: `EnumeratedValue error: Value 8 out of range 0..8
   make: *** [Makefile:84: stm32u5/src/stm32u5/mod.rs] Error 1
   

Any input how to solve the error? cc @adamgreig, @jonathanpallant

Thanks for trying to get it working! The error message is saying that the SMS1 field in the TIM1_SMCR register has some enumeratedValues provided by ST, including one with a value of 8, which isn't possible for a 3-bit field (only 0 to 7 is allowed). This is an error by ST, so we'll have to fix it by patching the SVD. So far our experience has been that the best way to fix this is to remote all the ST enumerated values, as they don't tend to be very useful. You can do this by adding this to the device YAML file:

_clear_fields: ["*"]

See the stm32g0b0.yaml device for an example.

The board is indeed in stock at Mouser for example at the time of writing this :) : https://no.mouser.com/ProductDetail/STMicroelectronics/NUCLEO-U575ZI-Q?qs=Wj%2FVkw3K%252BMD4hdUJJxGixg%3D%3D .

Any update? Being curious / n00b: once the pull request from @Urhengulas is merged, does it mean that there will be full support from Rust for all functionalities, or will this be only basic support, with more work needed to get different peripherals / advanced functions to work? :)

Any update? Being curious / n00b: once the pull request from @Urhengulas is merged, does it mean that there will be full support from Rust for all functionalities, or will this be only basic support, with more work needed to get different peripherals / advanced functions to work? :)

As far as I understand (which might be wrong) this repository only generates "device support crates" aka. "peripheral access crates" (PAC). After my PR lands we still needs to be build the "hardware abstraction layer" (HAL), for it to be actually useful.

Aaah, ok, many thanks for the explanation, and I guess the HAL is the more labor intensive part, right? Do you know if there are plans / ongoing work for a dedicated HAL for this chip once your PAC PR lands? :)

Aaah, ok, many thanks for the explanation, and I guess the HAL is the more labor intensive part, right? Do you know if there are plans / ongoing work for a dedicated HAL for this chip once your PAC PR lands? :)

I'd be generally interested to participate in that effort. Mainly to try out building support for a new chip. But as you can see from how long my PR is already dangling, my bandwith is currently rather limited 🤷🏾

Yes, that is very natural, and it is very kind of you to contribute so much already :) . Curious: would the HAL be on this repo too, or on another repo? If a new repo gets set up for the HAL, can you let me know? :)

Btw, @gauteh , guess this is related to what you were mentioning about quite some work needed to take the chip into use? :)

The HAL is in different repository, e.g. https://github.com/stm32-rs/stm32l4xx-hal. There is usually significant overlap between the chip families, which can be used when setting up a new HAL. But as far as I can see it is a bit hard to share code between the different families now, so keeping things consistent and fixing common issues requires a bit of effort.

What's the status of the PR right now @Urhengulas? I'm a n00b but have played with a growing variety of microcontrollers in rust so there is an outside chance I might be able to help get this across the finish line. Maybe after the PAC is in place we can get some help from this repo's maintainer on a working HAL?

Maybe after the PAC is in place we can get some help from this repo's maintainer on a working HAL?

Sounds like a plan. Due to time constraints, I couldn't test the PR yet. But I am hopeful I can do that in the following week(s).

for anyone looking to use Rust on STM32u5: embassy-stm32 already has full support.

If a crate depends on embedded-hal to work, does that mean this issue needs to finish supporting the STM32U5 family?

For example, can various driver crates such as max7219 use embassy-stm32 to solve this, or is our only option updating stm32-rs and beginning stm32u5xx-hal?

I don't mind contributing to this, just trying to build an understanding of if it's necessary.

This project provides only peripheral (register) access level crates (using SVD files as source) and it does not depend on embedded-hal. So you need stm32u5xx-hal or some other hal to be built on top of this crate.

embassy is independent project. It uses its own pacs.

@TjRichmond embassy-stm32 implements the embedded-hal traits, so you can use drivers like max7219 with it out of the box.