search

open-morphs / morph-v1-esp32-fw-rs

An experimental Rust-based embedded firmware for the Morph InfiniConnect earbuds' smart case.
MIT License
0 stars 0 forks source link

chore(deps): update esp-idf-hal requirement from 0.39.1 to 0.40.0 in /variants/esp32 #11

Closed dependabot[bot] closed 1 year ago

dependabot[bot] commented 1 year ago

Updates the requirements on esp-idf-hal to permit the latest version.

Changelog

Sourced from esp-idf-hal's changelog.

[0.39.3, 0.39.4] - 2022-12-09

Minor doc fixes; Clippy fixes; CriticalSection will panic on FreeRTOS mutex lock/unlock failures.

[0.39.1, 0.39.2] - 2022-11-21

Patch releases to fix compilation errors under no_std.

[0.39] - 2022-11-01

Release 0.39 is a backwards-incompatible release where almost all drivers were touched in one way or another.

Major Changes

The main themes of the 0.39 release are:

  • Restore drop semantics for all drivers
  • Simpler driver types (little to no generics)
  • Unified naming
  • Public API
  • Completely revamped GPIO metaphor
  • Timer driver
  • Support for the critical-section crate by providing a CriticalSection implementation
  • Support for the embassy-sync crate by providing two types of raw mutexes
  • Support for the edge-executor crate
  • Modem and Mac peripherals
  • SPI driver rework

Major changes elaboration

Restore drop semantics for all drivers

  • The release() method is now retired everywhere
  • Just dropping a driver will make it stop functioning
  • If peripherals need to be reused after the driver is dropped, this is achieved by passing the peripherals to the driver constructor via &mut references, e.g. I2cMasterDriver::new(&mut peripherals.i2c1, &mut peripherals.pins.gpio10, &mut peripherals.pins.gpio11, &mut peripherals.pins.gpio12)

Simpler driver types

  • All peripheral generics are removed from all drivers' types; e.g., the I2C master driver now has the following type signature: I2cMasterDriver<'d>
  • The lifetime - 'd from above designates the lifetime of the peripheral (e.g. I2c) that is used by the driver
  • In the most common case where the peripheral is just moved into the driver (and no longer accessible when the driver is dropped), 'd = 'static, or in other words, the type signature of the driver becomes I2cMasterDriver<'static> and can even be type aliased by the user as in pub type SimpleI2cMasterDriver = I2cMasterDriver<'static>;
  • When the peripherals are passed to the driver using &mut references, 'd designates the lifetime of the &mut reference
  • Note that the constructor of each driver is still generic by the peripherals it takes, but these generics are "erased" from the type of the driver once the driver is constructed, as we only need to "remember" whether the peripheral is moved into the driver, or used via a &mut reference and can be reused after the driver is dropped. This semantics is captured by the 'd lifetime

Unified naming

  • Each driver is named <Peripheral>Driver, where <Peripheral> is the name of the peripheral. E.g. the driver for the Uart peripheral is named UartDriver, the driver for the Adc peripheral is named AdcDriver and so on
  • The one exception is the GPIO subsystem, where the driver is not named GpioDriver, but the simpler PinDriver instead, even if the concrete peripheral struct type might be e.g. Gpio12
  • In case there are multiple drivers per peripheral - as in - say - a master and a slave protocol driver - only the Slave contains itself in its name, as in e.g. SpiDriver and SpiSlaveDriver
  • NOTE: We are NOT fond of still using offensive terms like "master" and "slave". Unfortunately, the embedded industry itself has not yet agreed (to our knowledge) on a good replacement for these terms, hence they are still around

... (truncated)

Commits


Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
dependabot[bot] commented 1 year ago

Superseded by #14.