ESP32-C3 doesn't support pattern of #include "rom/uart.h" (IDFGH-4758)

[pjsg]

Problem Description

The system provided header file rom/uart.h cannot be found when configured for esp32c3

Fix

Change the INCLUDE line in sdk/esp32-esp-idf/components/esp_rom/CMakeLists.txt to

INCLUDE_DIRS include/${target} include "${target}"

[Alvin1Zhang]

Thanks for reporting.

[projectgus]

Hi @pjsg,

Thanks for the clear issue report. In this case, it may be counter-intuitive but this behaviour is by design.

When ESP-IDF only supported ESP32, there was a lot of code like #include "rom/blah.h". Which was fine because we only supported one chip, and there were no differences to cause ROM incompatibilities.

However, each Espressif chip's ROM is different and APIs that work on ESP32 may not compile, or they will compile and then not work the same, on other chips. For this reason, when we added ESP32-S2 support (and now ESP32-C3) we changed the method for including ROM headers.

If you #include "rom/uart.h" on ESP32 with a recent version of ESP-IDF (v4.0 or newer) then a warning will be printed like this:

rom/uart.h is deprecated, please use esp32/rom/uart.h instead

This deprecation warning is intended to not break compatibility for ESP32 users, but it will be removed in a major release in the future (maybe ESP-IDF v5.0).

There are some alternatives possible for when you need to use ROM functionality:

1. We've extracted common ROM APIs for functions which run on all target SoCs. For example, you can include esp_rom_uart.h and find the ROM UART functions that will work on all targets.

2. If you only need your code to work on ESP32-C3, you can of course #include "esp32c3/rom/uart.h". If someone tries to build this for a different target then they'll get a compiler error rather than possibly slightly different behaviour due to some API change.

3. If you find some functionality that isn't in a chip-agnostic header, but you're using it on more than one target SoC, then you can use #ifdefs like this. We use this pattern for some internal support code where the ROM behaviour actually is different between chips. It's also pretty ugly so if you've found common functionality between SoCs that isn't exposed in the "for all targets" headers, then please open a feature request for us to support them in those headers.

If you've found some Espressif-provided code or example that includes #include "rom/uart.h", please let us know and we'll update it.

[pjsg]

Thanks for this -- it certainly gives me direction to go in. My problem is that I'm porting the nodemcu-firmware (the lua interpreter/environment) and it has to work on regular esp32 as well as the c3. (The esp8266 version is essentially completely separate and runs in the legacy environment).

[projectgus]

Hi @pjsg, ah I see!

Having a peek at nodemcu/nodemcu-firmware#3397, it looks like this involves updating from ESP-IDF V3.x with GNU Make to V4.x with CMake - so there a few differences, but hopefully you can get past them smoothly. If you're updating NodeMCU to use ESP-IDF V4.3 or V4.4 for both ESP32 and ESP32-C3 then it shouldn't be too hard to get code that runs on both with minimal target-specific #ifdefs but it may require some changes - like the ROM headers.

As a first step, suggest looking to see if the thing(s) NodeMCU uses from rom/uart.h have equivalents in esp_rom_uart.h, and change to those functions if possible.

[pjsg]

@projectgus Thanks -- some of these are easy. How about rom/spi_flash.h. These are the matching files:

./sdk/esp32-esp-idf/components/esp_rom/include/esp32c3/rom/spi_flash.h
./sdk/esp32-esp-idf/components/esp_rom/include/esp32/rom/spi_flash.h
./sdk/esp32-esp-idf/components/esp_rom/include/esp32s3/rom/spi_flash.h
./sdk/esp32-esp-idf/components/esp_rom/include/esp32s2/rom/spi_flash.h
./sdk/esp32-esp-idf/components/esp32/include/rom/spi_flash.h

The last file says just to use esp32/rom/spi_flash.h. For the esp32c3 which file should I be using? Can I just use the esp32/rom/spi_flash.h or do I have to use the esp32c3 flavor? I have a number of these cases to go through (after I backed out the change that I made to the CMakeLists.txt).

Thanks

[projectgus]

Hi @pjsg,

Which functions is nodemcu using from the ROM SPI flash headers? Suggest not calling ROM SPI flash functions from ESP-IDF apps at all if possible (I think all of these headers have warnings to this effect), call the relevant ESP-IDF APIs instead:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/storage/spi_flash.html

(To answer the general question, on esp32c3 you would need to use the esp32c3/rom/xyz.h flavor and not the esp32/rom/xyz.h flavor - as the two chips have different ROM contents.)

[pjsg]

By aggressively commenting out features, I have the basic command input/interpret/output loop running. Now on to get the network stack up and running.....

…

On Thu, Feb 18, 2021 at 9:43 PM Angus Gratton ***@***.***> wrote: Hi @pjsg <https://github.com/pjsg>, Which functions is nodemcu using from the ROM SPI flash headers? Suggest not calling ROM SPI flash functions from ESP-IDF apps at all if possible (I think all of these headers have warnings to this effect), call the relevant ESP-IDF APIs instead: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/storage/spi_flash.html (To answer the general question, on esp32c3 you would need to use the esp32c3/rom/xyz.h flavor and not the esp32/rom/xyz.h flavor - as the two chips have different ROM contents.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6561 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALQLTNQVPZGU4UKZRHYNJTS7XF2TANCNFSM4XZM4KAA> .