esp-rs / esp-hal

no_std Hardware Abstraction Layers for ESP32 microcontrollers

esp-hal

Bare-metal (no_std) hardware abstraction layer for Espressif devices. Currently supports, to varying degrees, the following devices:

• ESP32 Series: ESP32
• ESP32-C Series: ESP32-C2, ESP32-C3, ESP32-C6
• ESP32-H Series: ESP32-H2
• ESP32-S Series: ESP32-S2, ESP32-S3

Additionally provides limited support for programming the low-power RISC-V cores found on the ESP32-C6, ESP32-S2, and ESP32-S3 via the esp-lp-hal package.

These packages are all no_std; if you are looking for std support, please use esp-idf-svc instead.

If you have any questions, comments, or concerns, please open an issue, start a new discussion, or join us on Matrix. For additional information regarding any of the crates in this repository, please refer to the relevant crate's README.

Note

This project is still in the relatively early stages of development, and as such there should be no expectation of API stability. A significant number of peripherals currently have drivers implemented but have varying levels of functionality. For most basic tasks, this should be usable already, however some more advanced or uncommon features may not yet be implemented.

Getting Started

For information relating to the development of Rust applications on ESP devices, please first read The Rust on ESP Book.

For information about the HAL and how to use it in your own projects, please refer to the documentation.

Resources

• The Rust Programming Language
• The Embedded Rust Book
• The Embedonomicon
• The Rust on ESP Book
• Embedded Rust (no_std) on Espressif

Crates

This repository is home to a number of different packages; for more information regarding a particular package, please refer to its README.md and/or documentation.

License

Licensed under either of:

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

If you consider contributing, please make sure you have read and understood our contributing guide and API guidelines.

esp-hal's Issues

Support USB_SERIAL_JTAG serial

At least writing to it should be supported

Revise APIs ported from ESP32-HAL

Some of the APIs that just get straight ported from ESP32-HAL have a potential of being used wrong.

e.g. one could try to use ADC without ever calling enable_pin or for the (not yet merged) LEDC one could call getChannel with different pins but the same channel

In many places there are runtime checks but we can try to make use of the type-system to turn them into compile-time errors where possible

---

• ADC read currently does a runtime check if the given PIN is configured for ADC and panics if not
• it seems that one could assign pins multiple times to an RMT channel - there is a runtime error specified but it seems it's not checked
• LEDC: it's possible to create multiple instances since the constructor doesn't take the LEDC peripheral
• LEDC: it's possible to call get_channel multiple times with the same channel and different PINs

GPIO `InputSignal` and `OutputSignal` enums are not convenient to use

This needs to be addressed sooner than later, as it will only cause more pain as we continue to add peripheral drivers.
Context is available in this issue: #5

One possibility is adding the enumerated values directly to the SVDs, so that they would be included in the PACs.

cc @bjoernQ @ducktec

SPI: MISO and CS should be optional

Our SPI implementation currently expects MISO, and CS pins. Those should be optional

Documentation missing for esp32c3-hal crate

Link doesn't work for esp32c3-hal: https://docs.rs/esp32c3-hal

pulse_control should take a rate instead of the plain clock divider values

And we also need to pass in the frozen clock settings we will introduce in #44 for that - not sure if we want or should give the user the freedom to choose the clock source then

Implement the `embedded-hal-async` Traits once stabilized

I believe it's still too early to begin work on this, but once a stable release (or at the very least a more stable alpha release) is available we can revisit this topic.

---

In [email protected] the traits to implement are:

• embedded_hal_async::delay::DelayUs
• embedded_hal_async::digital::Wait
• embedded_hal_async::i2c::I2c
• embedded_hal_async::spi::SpiBus
• embedded_hal_async::spi::SpiBusFlush
• embedded_hal_async::spi::SpiBusRead
• embedded_hal_async::spi::SpiBusWrite
• embedded_hal_async::spi::SpiDevice
• embedded_hal_async::spi::SpiDeviceRead
• embedded_hal_async::spi::SpiDeviceWrite
• embedded_hal_async::serial::Write

Implement `TIMG`, `UART`, `GPIO` peripherals for all chips

As an MVP, we should have the TIMG, UART, and GPIO peripherals implemented for each chip, with working examples. Presently this is all implemented to some degree for the ESP32-C3.

The remaining chips should be able to use the TIMG and UART implementations with little to no modifications. GPIO will likely have to be device-specific.

• ESP32
  • TIMG, UART, GPIO
• ESP32-C3
  • TIMG, UART, GPIO
• ESP32-S2
  • TIMG, UART, GPIO
• ESP32-S3
  • TIMG, UART, GPIO

Timer should use a Duration not a plain U64 as timeout

We should use a Duration instead of a plain U64 for the timer timeout.
Also we should pass in the clock config from #44 to the constructor and have a way to configure the rate of the timer ticks.

Basic Support for ESP32S2

Get to the point that at least "hello_world" can be flashed and runs. Ideally also the other examples besides "blinky" (since GPIO will be a bigger task)

This includes

• partly #1
• esp-rs/xtensa-lx-rt#26

Cannot infer type of optional SPI pins

I apparently didn't test this before merging (oops), but if you attempt to initialize the SPI peripheral without providing all pins it is impossible to build. For example:

let io = IO::new(peripherals.GPIO, peripherals.IO_MUX);
let sck = io.pins.gpio7;
let mosi = io.pins.gpio6;

let spi = Spi::new(
    peripherals.SPI2,
    sck,
    mosi,
    None,
    None,
    16u32.MHz(),
    SpiMode::Mode0,
    &mut system.peripheral_clock_control,
    &clocks,
);

Results in:

error[E0282]: type annotations needed
  --> src/main.rs:41:9
   |
41 |         None,
   |         ^^^^ cannot infer type of the type parameter `T` declared on the enum `Option`
   |
help: consider specifying the generic argument
   |
41 |         None::<T>,
   |             +++++

For more information about this error, try `rustc --explain E0282`.

Add a `direct-boot` feature to `esp32s3-hal`

The ESP32-S3 also allows the use of "direct boot" mode, so we should support this like we do for the ESP32-C3.

Time types

How do we plan on handling time types in this new hal, seems currently we are just using a u32 for frequency etc (perhaps not a bad thing). Historically each hal defined its own time types, but nowadays there are a couple of external crates that will do the job.

• https://crates.io/crates/embedded-time
• https://crates.io/crates/fugit

GPIO pull-ups funky (tested on ESP32)

Example

The code in https://github.com/esp-rs/esp-hal/blob/43c8f34e5f532bf6edd5cc23fef8e27c7a60c571/esp32-hal/examples/gpio_interrupt.rs describes the following setup:

• configure GPIO0 (button) as input with internal pull-up, listening on falling edge
• enable GPIO interrupt 1, level-triggered
• enable GPIO interrupt 1 in mask
• define level1_interrupt function which clears the interrupt and prints to serial

This raises the following questions already:

• Why configure the button to listen on falling edge, but use the level-triggered interrupt 1?
• Why not use an edge-triggered interrupt then, such as interrupt 10?

I have taken the example code and tried to adapt it. However, I couldn't get it to work as I intended.

Scenario

We have the following board based on the ESP32 D1 mini module:
https://github.com/das-labor/badge-2021

This board has 4 buttons with debounce circuits each (see also the schematics, linked in README). Two are push buttons and two more are part of joysticks. They are routed to GPIOs 0, 2, 5, and 12.

Note: Those buttons work just fine with MicroPython, checking their level in a loop.

Code

I have iterated over multiple attempts, starting from the example. See das-labor/badge-2021-rs@e13aa27 and also the history before that commit.

What I expected to work:

• set up an interrupt to be triggered on any edge, setting internal pull-up
• enable interrupt 10 (edge-triggered) for GPIO on ProCpu
• enable interrupt 10 in mask
• define level10_interrupt

So far I can never see the level10_interrupt executed. However, even if not enabled, I do see the level1_interrupt executed, and it only works for one button, IO0. If listening to low level instead of listening on edge, it is constantly triggered without pressing the button.

This is all quite confusing. Any ideas would be highly appreciated. 🙏

RMT driver no longer works for some chips after updating PACs to use `svd2rust` 0.24

For whatever reason this update seems to have broken this driver for some of the chips. I have verified it still works on the ESP32-S2, but it has stopped working on the ESP32-C3 and ESP32-S3 for me. I do not have an ESP32 board with a neopixel on it so I cannot test this.

This obviously needs to be fixed.

• ESP32
• ESP32-C3
• ESP32-S2
• ESP32-S3

Add linker scripts for the ESP32-S2 and ESP32-S3

I admittedly am not well versed in linker scripts. In order to build and flash any examples for these chips, we need linker scripts. Help would be appreciated.

• ESP32-S2 (added in #12)
• ESP32-S3 (added in #14)

Implement the `embedded-hal` alpha version Traits

It should be possible for these to coexist with the existing 0.2.7 implementations. I have already begun work on this.

EDIT: This crate has been broken up into multiple crates, the task list below has been updated to reflect this. Not all new crates are included, they will be added as needed.

---

• [email protected]
  • embedded_hal::delay::DelayUs
  • embedded_hal::digital::InputPin
  • embedded_hal::digital::OutputPin
  • embedded_hal::digital::StatefulOutputPin
  • embedded_hal::digital::ToggleableOutputPin
  • embedded_hal::i2c::I2c
  • embedded_hal::pwm::SetDutyCycle
  • embedded_hal::serial::Write
  • embedded_hal::spi::SpiBus
  • embedded_hal::spi::SpiDevice
• [email protected]
  • embedded_hal::serial::Read
  • embedded_hal::serial::Write
  • embedded_hal::spi::FullDuplex
• [email protected]
  • embedded_can::blocking::Can
  • embedded_can::nb::Can

Multicore support for ESP32 and ESP32S3

We should have ways to start and run code on the second core on dual-core chips

We need a way to configure clock rates

In the first iteration it would be sufficient to just configure all clocks and freeze them

Make a decision on how to handle the direct boot feature of the ESP32-C3

Currently we are defaulting to direct booting over using a second-stage bootloader. The bootloader method can be used by enabling the normalboot feature.

1. Is this the correct default? Is there any reason not to default to direct boot when available?
2. Can we come up with a more descriptive name than normalboot?

This feature was added in #6.

Consider GPIO PU/PD workarounds as done in ESP-IDF (ESP32 only) for some special pins

see https://esp32.com/viewtopic.php?t=439

Reduce Macro Usage for GPIO Implementation

Currently we use macros nested multiple levels for implementing GPIO.

We should reduce that since it's not convenient to work with (on the implementation side).

Ideally this

• shouldn't change anything on the call-site
• reduce the macro usage to just one top level macro (or as few levels of nesting as possible)

Note: We shouldn't touch this before #55 since that one will introduce one more macro to get rid of

SmartLedAdapter.write() hangs when using more than one LED

I tried to use an led strip with my esp32c3, but it seems like there's a hang when using more than one led.

Minimal reproducible example

Take the hello_rgb example and modify it to drive two leds. Here's the diff:

diff --git a/esp32c3-hal/examples/hello_rgb.rs b/esp32c3-hal/examples/hello_rgb.rs
index a4a3b41..2ae38d7 100644
--- a/esp32c3-hal/examples/hello_rgb.rs
+++ b/esp32c3-hal/examples/hello_rgb.rs
@@ -62,7 +62,7 @@ fn main() -> ! {
 
     // We use one of the RMT channels to instantiate a `SmartLedsAdapter` which can
     // be used directly with all `smart_led` implementations
-    let mut led = <smartLedAdapter!(1)>::new(pulse.channel0, io.pins.gpio8);
+    let mut led = <smartLedAdapter!(2)>::new(pulse.channel0, io.pins.gpio8);
 
     // Initialize the Delay peripheral, and use it to toggle the LED state in a
     // loop.
@@ -81,7 +81,7 @@ fn main() -> ! {
             color.hue = hue;
             // Convert from the HSV color space (where we can easily transition from one
             // color to the other) to the RGB color space that we can then send to the LED
-            data = [hsv2rgb(color)];
+            data = [hsv2rgb(color); 2];
             // When sending to the LED, we do a gamma correction first (see smart_leds
             // documentation for details) and then limit the brightness to 10 out of 255 so
             // that the output it's not too bright.

Expected

The on-board led should show a rainbow pattern, just like before.

Actual

The led keeps the color that was active before the start of the program (no updates get through, not even the first one).

As far as I can see, the call to SmartLedAdapter.write() never returns. I haven't found the root cause for this yet.

Does anyone have an idea what could be going wrong?

More re-exports in the chip specific HALs needed

We need to re-export more of esp-hal-common since that shouldn't be used directly

Background:
When implementing https://github.com/bjoernQ/ps2keyboard-esp32c3 I discovered I need to import a few things that are actually in esp-hal-common and are not re-exported:

use esp_hal_common::{Event, OpenDrain, Output, Pin};

Implement `I2C` and `SPI` peripherals for all chips

This is a tracking issue for the remaining communication protocols. With these implemented we should be able to interact with a vast array of sensors and external peripherals.

• ESP32
  • I2C, SPI
• ESP32-C3
  • I2C, SPI
• ESP32-S2
  • I2C, SPI
• ESP32-S3
  • I2C, SPI

Add one or more `procmacros` crates

I'm specifically interested in the #[ram] and #[interrupt] attributes that are generally implemented by the procmacros crate. An example of this can be seen in the esp32-hal repository.

I imagine this may be tricky to get working for all chips, so it's possible more than one implementation may be necessary. I have not looked into this enough to know whether or not that is the case at this time.

`smartled` feature shouldn't be activated by default

Currently the feature is always activated as soon as a target is activated (which is always the case).

This feature must be controllable by a feature of the chip-specific HALs and not activated by default.

The example should not be build when the feature is not activated. That should be doable by something like this

[[example]]
name = "hello_rgb"
required-features = ["smartled"]

Basic Support for ESP32S3

Get to the point that at least "hello_world" can be flashed and runs. Ideally also the other examples besides "blinky" (since GPIO will be a bigger task)

Track peripheral driver implementations for all chips

The table below enumerates all peripherals for each chip supported by esp-hal. Support in this case does not mean a feature-complete and bug-free driver implementation, only that you are able to interact with the peripheral in some meaningful way.

If a cell contains am em dash (—) this means that the particular peripheral is not present for a chip. A check mark (✓) means that some driver implementation exists.

The table should be complete, though some minor naming changes have been made for consistency. If there are any missing peripherals or errors please comment below indicating such. Since adding support for additional devices it's possible some new peripherals have been introduced which aren't displayed below.

If you would like to contribute to this project, we ask that you please comment below "claiming" a peripheral, just to help ensure people are not stepping on each others' feet.

If you would like to request a feature for an existing peripheral driver, please open a separate issue to do so.

---

The following peripherals either have no drivers at all, or do not support all devices with that peripheral:

Peripheral	ESP32	ESP32-C2	ESP32-C3	ESP32-C6	ESP32-H2	ESP32-S2	ESP32-S3
ATOMIC	—	—	—		—	—	—
DEDICATED_GPIO	—	—	—	—	—		—
DS	—	—
ECC	—		—			—	—
EXTMEM	—				—
GPIOSD		—			—
HINF		—	—		—	—	—
HMAC	—	—
HP_APM	—	—	—			—	—
HP_SYS	—	—	—			—	—
LCD_CAM	—	—	—	—	—	—
LP_ANA	—	—	—			—	—
LP_AON	—	—	—			—	—
LP_APM	—	—	—			—	—
LP_APM0	—	—	—		—	—	—
LP_CLKRST	—	—	—			—	—
LP_I2C0	—	—	—		—	—	—
LP_I2C_ANA_MST	—	—	—		—	—	—
LP_IO	—	—	—		—	—	—
LP_PERI	—	—	—			—	—
LP_TEE	—	—	—		—	—	—
LP_TIMER	—	—	—			—	—
LP_UART	—	—	—		—	—	—
LP_WDT	—	—	—			—	—
MEM_MONITOR	—	—	—			—	—
OTP_DEBUG	—	—	—			—	—
PARL_IO	—	—	—			—	—
PAU	—	—	—			—	—
PERI_BACKUP	—	—	—	—	—	—
PMS	—	—	—	—	—		—
PMU	—	—	—		—	—	—
RTCIO		—	—	—	—
RTC_CNTL				—	—
RTC_I2C		—	—	—	—
SDMMC		—	—	—	—	—
SENSITIVE	—			—	—	—
SLC		—	—	—	—		—
SLCHOST		—	—	—	—
SOC_ETM	—	—	—		—	—	—
TEE	—	—	—			—	—
TRACE	—	—	—			—	—
TWAI0 1		—	✓				✓
TWAI1 1	—	—	—		—	—	—
UHCI0		—
UHCI1		—		—	—	—
WCL	—	—	—	—	—	—
XTS_AES	—			—	—

1: #341

---

The following peripherals have some driver implementation for all supported chips, though the drivers may not be feature-complete:

Peripheral	ESP32	ESP32-C2	ESP32-C3	ESP32-C6	ESP32-H2	ESP32-S2	ESP32-S3
AES	✓	—	✓	✓	✓	✓	✓
ASSIST_DEBUG	—	✓	✓	✓	✓	—	✓
DAC	✓	—	—	—	—	✓	—
DMA	✓	✓	✓	✓	✓	✓	✓
GPIO	✓	✓	✓	✓	✓	✓	✓
I2C0	✓	✓	✓	✓	✓	✓	✓
I2C1	✓	—	—	—	✓	✓	✓
I2S0	✓	—	✓	✓	✓	✓	✓
I2S1	✓	—	—	—	—	—	✓
LEDC	✓	✓	✓	✓	✓	✓	✓
PCNT	✓	—	—	✓	✓	✓	✓
PWM0	✓	—	—	✓	✓	—	✓
PWM1	✓	—	—	—	—	—	✓
RMT	✓	—	✓	✓	✓	✓	✓
RNG	✓	✓	✓	✓	✓	✓	✓
RSA	✓	—	✓	✓	✓	✓	✓
SARADC	✓	✓	✓	✓	✓	✓	✓
SHA	✓	✓	✓	✓	✓	✓	✓
SPI2	✓	✓	✓	✓	✓	✓	✓
SPI3	✓	—	—	—	—	✓	✓
SYSTIMER	—	✓	✓	✓	✓	✓	✓
TIMG0	✓	✓	✓	✓	✓	✓	✓
TIMG1	✓	—	✓	✓	✓	✓	✓
UART0	✓	✓	✓	✓	✓	✓	✓
UART1	✓	✓	✓	✓	✓	✓	✓
UART2	✓	—	—	—	—	—	✓
USB_DEVICE	—	—	✓	✓	✓	—	✓
USB0	—	—	—	—	—	✓	✓

A way to specify memory properties like flash size

It's very convenient that we don't need a memory.x or build.rs in binary crates using the HAL

However, we should be able to set things like flash size if it doesn't match our default.

Ideally not by providing custom linker scripts

Provide a higher level interrupt mechanism

The current interrupt implementation is quite currently low level. The PAC's we generate also generate a table of Peripheral interrupts with handlers held in static storage. We should be able to provide a higher level of abstraction such that we could declare an interrupt for a peripheral with a simple proc-macro. For example

#[interrupt] // delcare the following function as a interrupt handler for GPIO
fn GPIO() {
  // stuff
}

Xtensa

I have a good idea of how to handle this in Xtensa, as it's something we did in the original esp32-hal. The idea is that internally the hal will claim all interrupt levels from xtensa_lx_rt (here) at which point any interrupt goes to a single handler where the status is checked. From there it's easy to get the interrupt number and call the corresponding peripheral handler.

RISCV

I am less sure of the best approach on RISCV, something similar to the above could work. Perhaps we reserve 15 CPU interrupts, one for each of the priority levels and do the same approach. This then leaves the other 17 interrupts available for direct use which will result in slightly lower interrupt latency.

I am more than happy to take a stab at implementing this but I would appreciate some feedback on the design.

esp-backtrace: Custom printer feature

The stack walking code isn't specific to esp's, only the printing methods. This crate maybe useful to other chip vendors if we had a custom printing feature.

This isn't something we'll implement but maybe a good contribution from the community :).

New home for the ESP32S2/ESP32S3 ULP "mini"-HAL

There is a HAL (more of a POC actually) for the ULP RiscV coprocessor of esp32s2 and (in future) esp32s3, that lives here.

This is a "mini" HAL as it exposes a single peripheral - the RTC pins (and an impl of the embedded-hal Delay trait), but this is still quite useful as the alternative is either to use unsafe code with hard-coded memory addresses (the ones where the pin-related registers are mapped) or (a bit better but still not perfect) to use the register definitions from the upcoming esp32s2/esp32s3 PAC crates.

The need for a "mini" HAL for ULP (RTC gpio pins + a delay utility really) was recognized a bit by the ESP-IDF here in that they have something similar for C code.

Since the ULP HAL is really bare metal, I think it should either live in this crate (likely feature-gated by a ulp feature), or in a separate crate - say - esp32-ulp-hal. Any preferences?

In any case it should depend on the upcoming bare-metal PAC crates for register definitions.

Additionally, the current "mini" HAL does need a startup code in RiscV32 assembly, which also currently lives in the esp-idf-hal here, as well as a startup code in Rust, that lives here. I'm not really sure where that assembly + Rust code belongs, perhaps in some sort of "rt" crate (esp32-ulp-rt ?), but we need to find it a new home as well.

Finally, none of the above is very urgent, but ideally we should solve it sooner or later.

Handling peripheral access on multicore MCU's

Most embedded Rust HAL's only need to worry about single core access to peripherals. Even chips with dual core, such as the stm32h7 series only support one of the two cores: https://github.com/stm32-rs/stm32h7xx-hal. What does this mean? Interrupt free critical sections are not enough to guarantee mutual exclusion on multicore systems.

In the original esp32-hal, we used spin locks internally - this is also what esp-idf does too. Perhaps there is a better way, and if there isn't how can we add spin locks cleanly in this new hal.

Document all packages and peripherals

It's that job nobody wants to do!

This is a long-term project, as there's not much point documenting drivers until their interfaces are relatively stable.

Each HAL package should have top-level documentation at the very least. Peripheral drivers should additionally be documented, preferably even containing simple examples as doc tests.

---

Beginning with module-level documentation, here are all modules which are currently exported by any of the chip-specific HAL packages:

• adc
• aes
• analog
• assist_debug
• clock
• cpu_control
• dac
• delay
• dma
• efuse
• esp_riscv_rt
• gpio
• i2c
• i2s
• interrupt
• ledc
• lp_core
• macros
• mcpwm
• otg_fs
• pcnt
• peripheral
• peripherals
• prelude
• psram
• radio
• reset
• rmt
• rng
• rom
• rsa
• rtc_cntl
• sha
• spi
• system
• systimer
• timer
• trapframe
• twai
• uart
• ulp_core
• usb_serial_jtag

Generic Pin Type

The Hal currently lacks a generic pin type. Other HAL's such as the nrf-hal use a degrade method to obtain a generic pin. While working on the SpiDevice implementation the lack of a generic pin makes it so that I can't have a method take a type of pin2 and then take a type of pin3 for example. Is there a reason that a generic pin doesn't already exist?

MSRV mismatch

Hello,

the README states that the MSRV is 1.59.0. However, when compiling for esp32 from main with the 1.61.0 toolchain, I get the following error:

   Compiling esp-hal-procmacros v0.1.0 (/var/home/ahartmann/repos/mt/playground/esp-hal/esp-hal-procmacros)
error[E0658]: use of unstable library feature 'bool_to_option'
   --> /var/home/ahartmann/repos/mt/playground/esp-hal/esp-hal-procmacros/src/lib.rs:228:35
    |
228 |         (f.sig.inputs.len() == 1).then_some(Ident::new("context", proc_macro2::Span::call_site()));
    |                                   ^^^^^^^^^
    |
    = note: see issue #80967 <https://github.com/rust-lang/rust/issues/80967> for more information
    = help: add `#![feature(bool_to_option)]` to the crate attributes to enable

For more information about this error, try `rustc --explain E0658`.
error: could not compile `esp-hal-procmacros` due to previous error

And indeed this language feature was added as part of this PR and landed in Rust 1.62.0. This bumps the MSRV to 1.62.0.

Maybe it would be a good idea to add some github action that compiles the code against the MSRV mentioned in the Readme so it doesn't break along the way, or at least gets recognized automatically?

`critical_section` implementations

With the upcoming release of critical-section, default implementations for each arch are being removed. Instead, they should be implemented by the HALs/PAC on a per chip basis. This allows critical sections to be correctly implemented for dual-core chips, and or take advantage of hardware semaphores instead of spin locking.

A note on Xtensa implementations, we should not be disabling interrupts for our critical sections, this means the waiti instruction will never return. Instead, we should be raising the PS.INTLEVEL accordingly. See esp-rs/xtensa-lx#20.

The new release isn't out yet, but we should track the implementations we'll need here.

• Multicore aware Xtensa cs - esp32, esp32s3
• RISCV32 single core cs - esp32c3
• Xtensa single core cs - esp32s2

Correct the implementation of delay for Xtensa chips

This implementation is actually not correct, but was "good enough" just to get something in here. See here for details:
https://github.com/esp-rs/esp-hal/blob/main/esp-hal-common/src/delay.rs#L92-L94

This will need to be corrected at some point.

rmt peripheral / driving on-board rgb led

I've been playing around with my esp32-c3 dev board, trying to drive the on-board rgb led (WS2812) with the rmt peripheral. Some time ago, I managed to do this using esp-idf functionality (see here), but I wanted to also achieve it "bare-metal" using only esp-hal and the pac crate. After some trial and error, I now have an implementation that correctly configures the rmt peripheral to drive the on-board led. The code is here (see branch 'rmt'):

https://github.com/fkohlgrueber/esp32c3-hello-world/tree/rmt

I'd be interested to contribute a driver for the rmt peripheral and probably also the led driver to esp-hal. I'd like to use this issue to discuss the details of how this could work. Some questions off the top of my head:

• How to make the peripheral work with different clock sources? I think it'd be good to have an abstraction for clocks within the hal that could then be passed to the rmt peripheral. Looks like that's also the idea of #44.
• How about interrupts? I haven't looked into them yet, but they'd be required for things like sending more data than what fits into the rmt's ram.
• What functionality should be available for a first shot at a rmt driver? I haven't looked into carrier modulation, advanced transmission modes or receiving data yet.
• Should the implementation be common to all esp32 chips? I've only used esp32c3 and don't know whether other chips have the same peripheral.

I'm sorry for that slightly unstructured brain dump above. The main point is that I wanted to show what I did and that - if time permits - I'd be interested to work towards integrating an rmt driver into esp-hal.

Let me know what you think!

A way to place interrupt vectors and handler in IRAM

Currently we place interrupt vectors and handlers in RAM. We should have an optional feature to place them in IRAM

Remove the usage of floats

Currently we use floats in one place:

esp-hal/esp-hal-common/src/timer.rs

Lines 226 to 229 in 907d43e

	// TODO can we get this to not use doubles/floats
	let period = 1_000_000f64 / (clock.to_Hz() as f64 / divider as f64); // micros
	(micros as f64 / period) as u64

If possible we should remove that since it adds 2k of code (optimized) for ESP32-C3:

File  .text   Size                       Crate Name
0.0%  12.3% 1.2KiB           compiler_builtins compiler_builtins::float::div::__divdf3
0.0%   3.0%   292B           compiler_builtins __floatundidf
0.0%   1.6%   156B           compiler_builtins __floatunsidf
0.0%   1.4%   140B           compiler_builtins __gedf2
0.0%   1.4%   140B           compiler_builtins __gtdf2
0.0%   1.3%   130B           compiler_builtins __fixunsdfdi

How to specify dependency on esp-hal-common outside of esp-hal crate?

I wanted to play around with interrupt timers on esp32c3 and I bumped into an issue with the dependency on esp-hal-common.

Following the timer_interrupt.rs example in esp32c3-hal I need to use esp-hal-common::Timer. This example being located inside the esp-hal crate, a path dependency can be easily specified (from Cargo.toml):

[dependencies.esp-hal-common]
path     = "../esp-hal-common"
features = ["esp32c3"]

However, from my app that is a different crate, how can I specify this dependency?

Wouldn´t if make sense to have esp32c3-hal re-export esp-hal-common? The user does not need to know about the existence of esp-hal-common I guess.

Port over existing peripheral drivers from `esp32-hal`

There are a number of peripheral drivers already implemented in the esp32-hal repository. Since this crate has been published, we aren't really able to release a new version until we've roughly reached feature-parity with the previous implementation. Because of this, we should begin working on porting this drivers.

These can either just be dumped in the esp32-hal package for now, making the required changes just to get things building, or can be re-written to be compatible across all supported chips. While the latter method is preferable, the prior is likely the more realistic path forward.

The existing drivers are:

• analog/adc
• analog/dac
• clock_control see #44
• delay
• dport
• dprint
• efuse
• external_ram
• gpio
• i2c
• interrupt
• ledc (in progress)
• mem
• serial
• spi
• timer (partially complete)

TIMG timers should support period mode

Currently we only support target mode.

Period mode could be potentially useful e.g. esp-wifi currently uses period mode of SYSTIMER and since the HAL lacks that functionality it accesses the registers directly.

Explore improving interrupt latency with vectoring

Come up with better demonstrations of using the `#[ram]` attribute

Our current examples do their job in that they give us CI coverage of this feature, and provide some demonstration of how it can be used. We can likely come up with a more interesting/representative example, however.

This feature was added in #6.

Make it possible to use a PIN configured as open-drain as an input

That would reduce the PIN usage in https://github.com/bjoernQ/ps2keyboard-esp32c3 from 4 to 2

Maybe relevant

• rust-embedded/embedded-hal#31
• rust-embedded/embedded-hal#31

Also interesting:
https://github.com/stm32-rs/stm32f4xx-hal/blob/cb7cd4e4ad63a0b72e6711b720b1d29ff2db3063/src/gpio/hal_02.rs#L69-L78

`smart_leds_adapter` should take a rate instead of assuming `rmt` to be configured in a special way

Currently smart_leds_adapter assumes the pulse_control is configured to 40Mhz - easiest solution would be to take a rate which the user should have configure for the pulse_control

I2C SCL rate seems to be a bit too fast on ESP32 and ESP32-S2

But according to my logic analyzer it matches perfect on ESP32-C3 and ESP32-S3