# Rust Team Sync-up

## 2023-05-02

### esp-hal

- [JB] Need to publish new HALs soon, anything we want to merge first?
- [JB] When should be consider `esp32h2-hal` ready to merge into `main`?
- I'd like to do this as soon as possible
- Once Kirill finishes `WDT` I think we're okay?
- [JB] I would like to re-visit the idea of HAL configuration
- https://github.com/esp-rs/esp-hal/issues/42
- I think this is an important consideration for using the HAL in "real" projects
- Can we come up with a list of values which should be configurable?
- How do we want to accomplish this?
- Cargo package metadata?
- Configuration file?
- Environment variables? (not a fan, but included for completeness)
- Other?
- [JB] ADC calibration status?
- Is each chip going to be unique or is the process generally the same?
- Can we get some progress tracking in the issue?
- [JB] Let's make a push to implement the remaining `embedded-hal-async` traits?
- `I2c` is a bit tricky due to lack of DMA and use of FIFO/interrupts instead
- `SpiDevice`, `SpiDeviceRead`, and `SpiDeviceWrite` hopefully won't be too bad?
- `serial::Write` (haven't looked into it)

### esp-wifi

- [JB] Can we make a list of items which need to be completed before we publish a release?
- As I've stated previously, I think it's important to have something published for various reasons

### espflash

- [JB] There are still (unfortunately) a number of issues which need resolving
- Some of these I am not able to reproduce
- I am emotionally drained from working on this project (mostly alone) for so long and am struggling to find motivation to work on this project

## 2023-03-09

## esp-hal

- Discuss configuration of various parameters which have open issues
- https://github.com/esp-rs/esp-hal/issues/42
- https://github.com/esp-rs/esp-hal/issues/378
- [Jesse] I'm concerned we're approaching "feature hell"
- This is less of a problem now, but something to think about if we do want to unify the HALs
- We're having increasingly more features for various things, and I'm worried it's going to become difficult to use these packages. Setting all the correct features may be a frustrating process.
- I'm hesitant to introduce any sort of configuration file, but maybe this is needed?
- Maybe we can re-use some of the macros from other build scripts to better verify the selected features, though this seems more reactive than proactive
- [Scott] Maybe if most of the build scripts are the same we can move it out of each hal and use https://doc.rust-lang.org/cargo/reference/manifest.html#the-build-field to share them
- No immediate action required, but something to think about
- How do we want to handle `CHANGELOG`s? Per package? Just one?
- https://keepachangelog.com/en/1.1.0/
- Per-HAL changelogs seem like a maintenance headache
- We can deviate from the traditional format and have sub-sections for each package, maybe?
- If we unify the HALs this issue goes away
- Clean up `FIXME` and `TODO` comments (there are a lot of them :) ), triage issues
- [Scott] Our linker script situation is a bit of a mess. I think we should try and find a way to simplify and reuse parts across chips where we can, atleast for bootloader mode.
- [Bjoern] Wouldn't it make sense to add `log` to esp-hal?
- during chip bring-up we usually temporarily add esp-println as a dependency and remove it afterwards
- by using the right feature flags we can make it zero-cost for normal builds
- [Bjoern] I feel like we should move things like modem power-up, phy power-up etc. from esp-wifi to esp-hal (and make it look less hacky)
- but in esp-wifi we use a lot of registers that are not in the SVDs/PACs - I wouldn't like to add it that way to esp-hal
- [Bjoern] We wanted to get rid of the smartleds adapter (i.e. the whole utils module) and move it to it's own util crate.
- I still think we should do that. Other opinions?
- What else would be worth to have in such a crate?
- Maybe a convenience function to hide the usual boiler-plate code we usually have in `main`?
- Do we actually care about the remaining issues for `esp32c6-hal`, or should we just try to get something published?

## espflash

- Sergio will be helping with this project moving forward
- Goal at this point is to get a stable release out; hopefully not much else required for this
- [Jesse] Sergio and I spoke and I think we have a reasonbly clear path forward
- If you have any breaking requests (ie. not just _adding_ functionality) then please let us know ASAP!

## Other

- What other projects do we want to prioritize next quarter?
- [Bjoern] Probably continue and improve esp-wifi and ieee802.15.4 driver (at least it's one of my personal priorities)
- [Scott] Is there anything we can do to split the work here? Initial bring up is mostly a single person job, but perhaps the next steps can be split. FYI I bought one of those sniffers, so at the very least I can validate
- @Mabez would it be possible to have a quick presentation/tutorial on using `probe-rs` before the end of the month?
- No pressure, we're all busy :) We've just been wanting to do this for awhile now
- [Sergio] Book overhaul
- We have support from the documentation team. Kirill Chalov will be helping us for a month.
- [Sergio] Ferrous System update
- Once the examples are update we will need to update the book to match the updated examples