Design Meeting - Notes

[jessebraham]

On Monday, March 28th we will hold a meeting discussing some design details of esp-hal. I will update this post prior to the meeting with my notes when they have been completed, but as of now the high-level topics I plan on covering are:

---

MSRV

• My personal opinion, and based on what I've seen over the years in Matrix, VERY few people care about this at all.
  • I still think it's important to explicitly state our stance on this, though
• I think we should try to support the oldest version practical, bumping as needed, which should be at least stable - 1
• This is slightly complicated by the fact that there are two Rust compilers (mainline and fork)
  • For the mainline compiler, 1.56.x is as old as we can go because of the 2021 edition; let's use this (or whatever the oldest working version is)
  • For the forked compiler, probably either just latest or latest - 1
• Thoughts?

Decision: Xtensa latest - 1, RISC-V 1.56.x

Time Unit Types

• See this issue for some context: Time types #24
• The plan as of now is to move forward with using fugit
  • https://github.com/korken89/fugit
  • Evaluated embedded-time as well but wanted to avoid any runtime costs
• fugit looks good overall, but this is slightly annoying: short functions which return fixed types korken89/fugit#26 (comment)
• Any objections? Other suggestions?
  • If we're happy with this, I'll prepare a PR adding it in to the existing code base.

Decision: move forward with using fugit

embedded-hal Versions

• https://github.com/rust-embedded/embedded-hal
• Current stable version is 0.2.7, unstable is 1.0.0-alpha.7
• The 1.0.0 release channel has been stuck on alpha for a long time, but it seems to be inching closer to a stable release
• When and how do we want to handle this?
  • It would be beneficial to support both from a user experience perspective, but would be more work for us
  • The alpha release channel has made numerous breaking releases, which adds to our workload

Decision: wait until 1.0.0 release stabilizes before implementing

async

embedded-hal-async

• https://github.com/rust-embedded/embedded-hal/tree/master/embedded-hal-async
• API is still experimental, breaking changes expected to be coming

embassy Support

https://github.com/embassy-rs/embassy

Decision: implement async traits for a peripheral as PoC

Multi-core / Multi-tasking

• Handling peripheral access on multicore MCU's #28
• rp-hal has some multi-core examples:
  • https://github.com/rp-rs/rp-hal

Clock Control

• How are we going to handle this?

---

Meeting minutes will be posted here following the conclusion of this meeting.

[jessebraham]

Maybe for RtcCntl we could just define a number of Traits in esp-hal-common, and implement them in the chip-specific packages? This doesn't solve the issue of ensuring correct clock configuration, but does allow us to abstract functionality in an ergonomic way. I'm sure there is some common functionality which could be implemented as default members as well.

[bjoernQ]

Sounds good!

Also: Could we go the easier way to freeze the clocks at startup for now and later think about the more complicated dynamic case? Would be make that future change harder if we do so?

Like it's done here: https://docs.rs/stm32f1xx-hal/0.9.0/stm32f1xx_hal/rcc/struct.Clocks.html

[bjoernQ]

Regarding MSRV: I remember there are currently problems building the HAL with the esp toolchain 1.58. I think the problems was in one of the dependencies but not too sure