Björn Quentin

There will definitely never ever be a `esp_hal.py` or something 😄 you will always be able to just do `cargo run` What I currently have in mind is a plain...

In my current POC there is really only one config file in the end looking something like this ``` [esp-hal] heap.size=37283 psram.enable=true psram.size="4" psram.type.type="octal" [esp-wifi] options.ble=true options.buffer="2" ``` (Those things...

> Additionally, I foresee another breaking change: changing the order of the trap frame to follow the x order (from x0 to x31). As far as I know, this is...

Ok let's try something even simpler ```rust #![no_std] #![no_main] use esp_backtrace as _; use esp_hal::{clock::ClockControl, gpio::IO, peripherals::Peripherals, prelude::*}; use esp_println::println; #[entry] fn main() -> ! { let peripherals = Peripherals::take();...

@szubinskik with #1315 merged it will hopefully work for you, additionally using another pin (which is not an RTC pin) should also help

> I would say we should probably support both, but would like to hear some input from others regarding this. +1 for keeping IDF bootloader support

Absolutely a nitpick but since the way to run examples changed the corresponding section in the README needs to get adapted

Is it possible to create a minimal-repro of this behavior?

Another option might be that esp-wifi could provide a Trng implementation since we know as long as Wif/BLE is enabled we produce true random numbers

There is an open PR for that already here: https://github.com/esp-rs/esp-hal/pull/1151 But it _should_ already work via a slightly different mechanism introduced in https://github.com/esp-rs/esp-hal/pull/912