search

espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.62k stars 7.28k forks source link

AMP(Asymmetric Multi-Processing) Support (IDFGH-8999) #10410

Closed 5ami closed 1 year ago

5ami commented 1 year ago

Is your feature request related to a problem?

Yes. It could be a problem depending on the application, as there is no official support for BareMetal programming in esp-idf.

Describe the solution you'd like.

For now, We would like to Have AMP (i.e., running FreeRTOS on one core and a bare metal/other OS on the other).

Describe alternatives you've considered.

I considered this online article, https://hackaday.io/project/174521-bare-metal-second-core-on-esp32, but the implementation is highly experimental and not reliable especially in esp32s3.

Additional context.

image

igrr commented 1 year ago

Hi @5ami, The AMP solution for Espressif chips will be offered based on Zephyr project. You can check this example watch the DevCon video for more background. For bare metal development for Espressif chips you can consider https://github.com/esp-rs/esp-hal.

At this time, we are not planning to add AMP support to ESP-IDF.

5ami commented 1 year ago

Hi Igrr, thank you for the reply. **Is there a way around prevent freeRTOS during startup from starting on the app_cpu ?

**for https://github.com/esp-rs/esp-hal, I tried to consider Rust, but As far as I know, for safety-critical markets, such as automotive, there is currently no safety-certified Rust toolchain.

igrr commented 1 year ago

Is there a way around prevent freeRTOS during startup from starting on the app_cpu ?

In ESP-IDF, there isn't a straightforward way of doing this while still using the 2nd CPU to run some code. ESP-IDF is written under assumption that either the 2nd CPU is also running FreeRTOS, or the 2nd CPU is not used at all. This is especially a problem for ESP32 where various silicon bug workarounds require cooperation between the code running on both CPUs. Even for ESP32-S3, several aspects of the code (watchdogs, panic handling, cache & flash operations) assume that when CONFIG_FREERTOS_UNICORE is set (i.e. FreeRTOS runs on 1st CPU only) the 2nd CPU is not running any code.

I tried to consider Rust, but As far as I know, for safety-critical markets, such as automotive, there is currently no safety-certified Rust toolchain.

Have you looked at https://www.adacore.com/ferrocene? If not, I would recommend contacting AdaCore.

I would also recommend contacting Espressif via business support channels and discussing your application scenario, if you haven't already.

5ami commented 1 year ago

I will contact Espressif via business support channels after discussing with my team.

For zephyr project it seems a good option to explore regarding our automotive application, but it seems that it is not completely there yet for the esp32s3. Is there any updates regarding its status on esp32s3? as our hardware is already built around it.