Track peripheral driver implementations for all chips

[jessebraham]

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	—	—	—	—	—	✓	✓

[bjoernQ]

working on I2C

[ducktec]

I'm working on supporting the RMT peripheral. This should add support for driving many RGB LEDs and I have some implementation already from my work on esp32c3-hal to build upon.

[jessebraham]

I have an RNG implementation complete which I will PR soon, waiting on PACs to be updated.

Edit: added in #26

[bjoernQ]

I will start implementing embedded_hal::spi::FullDuplex

[fkohlgrueber]

@ducktec I just saw that you're working on supporting the rmt peripheral too right after I opened #52. Are you still working on the topic? If yes, we could probably join forces.

[ducktec]

@fkohlgrueber I'm already pretty far with the implementation of the OutputChannel functionality (I'm not planning to support the input functionality as part of my PR so far).

For better visibility I have just created #53. The PR so for includes the ESP32-C3 and ESP32-S2 variants. The ESP32 and ESP32-S3 variants are still WIP. The ESP32-S3 variant is missing the RMT peripheral in the SVD altogether right now.

The challenge is that all variants have a sightly different RMT feature set and register structure. This makes bringing them all together into generic implementation a lot of fun. 😆

[JurajSadel]

I will start working on LEDC.

[bjoernQ]

I'll start working on DAC

[bjoernQ]

Going to look into ADC

[gustavonihei]

RTC Watchdog Timer has been implemented and validated on #134 and #139 for all currently supported chips.

The RTC driver itself has been improved as part of those tasks, but some pieces are not yet implemented, e.g. configuration for sleep modes.

[alexbohm]

Working on the TWAI and the associated embedded_hal::can::Can traits.

[liebman]

This is missing MCPWM? or is that PWM{0,1,2,3}?

[jessebraham]

@liebman I think that's what those were supposed to be, I honestly don't even remember where I generated this list from at this point 😁 Thanks for pointing that out. I've updated the table to use MCPWM instead though, as based on the cells which were blocked out it seems to fit.

[bjoernQ]

I will start looking into GDMA on ESP32-C3. Maybe I can extend it to support for ESP-S3 later but DMA on ESP32 and ESP32-S2 is fundamentally different - so this would be a very first step

[jessebraham]

ADC is supported on all chips now that #217 is merged.

[bjoernQ]

Going to implement USB (device) for ESP32-S3 and S2 - starting with S3

[jessebraham]

We now have some level of DMA support for all supported chips.

[bjoernQ]

Going to implement first steps to get I2S support (starting with ESP32-C3 / ESP32-S3 - then ESP32 and ESP32-S2, just TX for the start and only supporting standard I2S - we can improve that later but we need something to start with)

[dimpolo]

Working on MCPWM

[dimpolo]

Do I understand correctly that the ESP32-C2 is secretly an ESP8684? (what's up with espressif's chip names? 😅 )

If so, the first table seems to be missing some — for the ESP32-C2.

[i404788]

Looking into implementing SHA

[jessebraham]

Do I understand correctly that the ESP32-C2 is secretly an ESP8684? (what's up with espressif's chip names? 😅 )

If so, the first table seems to be missing some — for the ESP32-C2.

@dimpolo My understanding regarding the device names is that the ESP8684/ESP8685 are variants of the ESP32-C2/C3 respectively with flash memory integrated into the package. I'm not aware of any other differences, though that's not to say they don't exist.

You are correct though, seems I updated one table's column but not the others' when I added the C2. I will get that fixed shortly!

[raiker]

I'd like to tackle USB serial on the ESP32-C3. I'm going to start by fleshing out the USB_SERIAL_JTAG so it looks and feels a bit more like a UART (Rx, interrupts, etc).

[jessebraham]

Preliminary I2S support added in #262

[MabezDev]

They were marked as off-topic because they are off-topic for a tracking issue thread. Many people are subscribed to this issue and don't want to be spammed with off-topic questions.

Please open a discussion thread/issue or join the matrix channel to ask questions like these, we are more than happy to answer them :).

[akashlama1998-icloud]

Ok.. I'll do so..

[matrixhead]

i would like to work on AES in esp32

[i404788]

Does anyone from espressif have documentation on LCD_CAM? I would like to work on implementing it but I can't find much of how it works outside of the pacs/registers.

EDIT (to not ping): Thanks @liebman, it didn't have the LCD_CAM peripheral in the technical reference document I had, it seems to be an old version, the latest works.

[liebman]

Download the technical reference manual for the chip in question, it will have a section on each peripheral.

[jessebraham]

PCNT added in #328

[liebman]

I think that HALL_SENS peripheral should be remove from the list. Justification: PCN20221202

[MabezDev]

I would agree, we also removed it from esp-idf-hal (from v5 onwards).

[jessebraham]

AES support added in #348

[jessebraham]

I've regenerated the tables in the first comment from the current PACs, and filled in each cell by hand.

There are a number of new peripherals in the first table now, however I'm not sure if all of them actually require peripheral drivers. I trimmed this down already from the generated version, but will need to spend some time in the TRMs to figure out which other rows can be eliminated, if any.

If you see anything in the first table that does not belong there please let me know so I can remove it.

When ESP32-C6 support is added over the new few weeks, I will update these tables again to include the new peripherals.

[matrixhead]

working on RSA in esp32

[jessebraham]

ESP32-C6 support was added in #392, and the tables have been updated. However, there are a number of new peripherals which have not yet been added; I'll do this at some point.

[nabilmerk]

I'm willing to work on ECC and HMAC driver but I would need some time for testing as I need to order some boards.

[matrixhead]

@nabilmerk yes i'm still working on it and i'm more than happy to discuss this with you.
this is my matrix handle @mhead:matrix.org

[jessebraham]

@nabilmerk that would be great, thank you for offering! There's no rush at all, grateful for any contributions 😁

[nabilmerk]

@jessebraham the basic function for computing HMAC are ready for testing but in order to use the HMAC, efuse must be programmed, even for upstream mode. Looking at the efuse module, I think I will also write the HAL for this module except if someone is on it?

[jessebraham]

@nabilmerk thanks for the offer, that'd be great. I don't believe anybody is working on anything EFUSE related, all we really have in the repo is a function to read the MAC address, so go nuts.

[bjoernQ]

I'm looking into half-duplex SPI including dual and quad SPI

[nabilmerk]

After digging around with EFUSE, I came to the conclusion that the EFUSE is a peripheral that we should set only in 'factory' environment. If someone's look at ESP-IDF, they actually don't ship software for writing EFUSE but they ship software for programming them when the board is attached to the PC.
Except if someone really needs EFUSE driver, I would finally propose that the driver should not be implemented, at least, for writing datas. What do you think ?

[MabezDev]

I would finally propose that the driver should not be implemented

I agree, we shouldn't have write access to EFUSE on chip. We already have some read-only access in the soc/$chip/efuse.rs modules, whether this is enough to mark them it as complete or not is a different question.

[bjoernQ]

I started to look into ASSIST_DEBUG

[jessebraham]

I think this issue has outlived its usefulness, and is just becoming more of a burden than anything else. So, I'm going to close it! 😁

[AnthonyGrondin]

I was looking for it 5 minutes ago to see what still needed to be implemented and what has been implemented. Haha