Stm32U5 Dev board

[jerabaul29]

We were discussing how the stm32U5 could be exciting for future developments; here it is as a test board FYI :) :

https://no.mouser.com/ProductDetail/STMicroelectronics/NUCLEO-U575ZI-Q?qs=Wj%2FVkw3K%252BMD4hdUJJxGixg%3D%3D

[jerabaul29]

@gauteh I just ordered a couple of evaluation boards, and playing around with them will join my (far too long :( ) list of things I would like to have a look at :) . Let me know if you get your hand on some similar boards / look at it. Looks like support for Rust is on its way: https://github.com/stm32-rs/stm32-rs/pull/744 .

I am starting to think (only a "dream" so far, but never know when a project with a good chunk of hours arrives) about an OpenMetBuoy-v2024 with a PCB made from scratch, this MCU, etc.

[jerabaul29]

I spoke too fast: you can only order 1 board per person per month, my order was rejected, will be a single board for me so far :) .

[gauteh]

Interesting. I have some other ideas to try out, and it would be nice with some extra speed. The Kalman-filter is quite heavy when running continuously at 200Hz.

Do you know what size and form-factor the eval board has (and does it include a hw-programmer/stlink)? Do you plan on using the eval-board or do you think you need to put the MCU on a PCB-board?

The stlink debug probes are quite cheap, but the one that works best so far is the JLink Edu Mini, but seems out of stock everywhere.

I wrote a crate for sending defmt messages over serial: https://github.com/gauteh/defmt-serial, works well on the Artemis. There is a report about it not working on a STM32 chip, and I haven't had the time to check myself yet.

I went through a similar process of adding support for the STM32L4R5 to stm32-rs (https://github.com/stm32-rs/stm32-rs/pull/703, https://github.com/stm32-rs/stm32-rs/pull/740), and now waiting to get it into the HAL crate as well. I don't think there is a HAL-crate for the STM32U-series yet. I have seen discussions about doing that, but its probably a significant job to get that started.

[gauteh]

The STM32U5 should be partially supported in https://embassy.dev/ (async framework) which might be an interesting alternative.

[jerabaul29]

I was thinking, if I do a new OMB, to use RTIC. What do you think is the trade-off between embassy Vs RTIC?

[gauteh]

I don't know, I think they do much of the same. Embassy seems more integrated, but I would prefer the one that shares HAL implementation with the classic HALs. RTIC does not seem to use the async/await syntax, and I didn't immediately find a way to yield to different tasks without returning (but that is covered by preemption / priority). I think the SFY would have reduced complexity with either embassy or RTIC, there is a lot of busy waiting with slow I2C comms with the modem that could have been used (currently this is offset to a large degree by doing most heavy computations in the RTC interrupt).

Would have to try them out!

[jerabaul29]

Sounds good!

Interesting comment regarding RTIC and async / await. Can you think about some use case? Would there actually be one 'async await layer' per priority level or something like this for async await to work well with priority?

[gauteh]

embassy has a special executor/runtime for high priority interrupts. I think that outside that (in the normal case) interrupts are used to wake up awaiting tasks, e.g.: a button change await will be awoken when an interrupt hooked up to that GPIO channel is triggered. That way the CPU will just sleep (asm::wfi/wfe) if nothing is going on. One significant difference from hosted / multi-threaded systems is that the executor is single-threaded, so tasks cannot block forever, otherwise no other tasks will be run (so it is easier to dead-lock these systems than multi-threaded runtimes).

[jerabaul29]

Ok. I will have to look into this in more details. I like quite well the RTIC framework, it maps well to my mental model of how things works on a single core MCU, so I wonder if I will try to keep using it :) .

[jerabaul29]

Looks like async await may be coming to RTIC btw:

https://github.com/rtic-rs/cortex-m-rtic/pull/646 https://hackmd.io/6ejCFNBJTuKBwnuz0O41iQ

[gauteh]

Yes, I think I prefer RTIC for this type of system as well.

[Dirbaio]

just FYI, you can use embassy-stm32 with the RTIC async executor instead of embassy-executor :)

[jerabaul29]

Not sure I am following @Dirbaio - RTIC does not have an async executor, right? So do you mean using the async executor from embassy-stm32 as the executor in an otherwise RTIC project? Or am I just missing something / confused? If you have an example that would be great :) . Sorry for the n00bness.

[Dirbaio]

Sorry, I wasn't clear enough. I meant with https://github.com/rtic-rs/cortex-m-rtic/pull/646 which essentially builds an async executor into RTIC itself.

[jerabaul29]

Nice, thanks :) . I must recognize I am still a bit confused, do you know if there is a simple "hello world working example" of combining the two? :)

[jerabaul29]

New stm32u5 chips, with up to 2.5MB RAM and 4MB flash :) .

https://www.st.com/en/microcontrollers-microprocessors/stm32u595rj.html

[jerabaul29]

(the new one with 2.5MB RAM is not released yet, I think it releases Q2 2023 or something like this, willl see if they come up with a dev board :) ).