istokm wrote: ↑

Sun Jan 17, 2021 1:16 am

Oh I thought that ESP32_RTC_CLK_SRC also applies to the ULP..

You're right, it does. I assumed you were using 150khz internal. Ignore that part.

Cycles for all instructions are included here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/ulp_instruction_set.html read the RTC_TIME registers at the very beginning, then reading them at the very end of the program, and using the difference to alter the ULPs sleep timer? ...

It's not clear where ULP variable offsets are coming from (eg. debounce_max_count). Maybe I missed something. The xxx->ulp_xxx pattern is only used when compiling ULP assembly. You can't do it that way with legacy macros. See here for an alternative with macros (and ulp_var_t in HULP examples for an...

It's not clear where ULP variable offsets are coming from (eg. debounce_max_count). Maybe I missed something. For RTCIOs 0-15, you would want RTC_GPIO_IN_NEXT_S to RTC_GPIO_IN_NEXT_S+15. For the upper two you want RTC_GPIO_IN_NEXT_S+16 to RTC_GPIO_IN_NEXT_S+16+1. RTC_CNTL_RDY_FOR_WAKEUP -> RTC_CNTL_...

Keypads like this work by toggling column pins output low sequentially, reading the state of each row pin for each column. In case 2, GPIO 35 is used as a column pin yet it is not output capable, so the row pins are always pulled high. 34-39 should only be used as row pins here (with external pullup...

I_RD_REG(RTC_GPIO_IN_REG,RTC_GPIO_IN_NEXT_S,16), All of these need a look. I_RD_REG is defined as I_RD_REG(reg, low_bit, high_bit) (ie. last arg is *high* bit, not *num bits*). I'll also give https://github.com/boarchuz/HULP a plug. There might be some useful bits in there (it will also support the...

Yeah there's a lot more to it. A lot of the Arduino stuff is precompiled so making changes there won't achieve much.

If you're really motivated and you only need simple IO, you might look at ESP-IDF to learn how to initialise and read/write using the registers directly.

I would pick a different pin!

You might still run into problems if any drivers check the validity of the pin (eg. pinMode(20, OUTPUT) -> error?).

Something like this will make the compiler stop complaining but don't expect correct functionality:
#define GPIO_NUM_20 ((gpio_num_t)(20))

Using a different pin for now would be best.

See section "3.3 Compatibility with ESP32­PICO­D4" of PICO-V3 datasheet: https://www.espressif.com/sites/default/files/documentation/esp32-pico-v3_datasheet_en.pdf If GPIOs 18 and 23 are defaults for any of the Arduino functionality (eg. I2C bus) then you might have issues with libraries that expect...

Try: