peter madsen-mygdal

Yeah, I cooked this up (from some of your code): **src/platforms/esp32/components/libatomvm/CMakeLists.txt** ``` if (CMAKE_SYSTEM_NAME STREQUAL "Generic") if (CONFIG_IDF_TARGET_ARCH_XTENSA) set(CMAKE_SYSTEM_NAME "xtensa") elseif(CONFIG_IDF_TARGET_ARCH_RISCV) set(CMAKE_SYSTEM_NAME "riscv32") endif() endif() if (CMAKE_SYSTEM_PROCESSOR STREQUAL "") if...

demo running circuits_i2c with AtomVM_backend https://github.com/petermm/circuits_i2c

believe this can be closed by https://github.com/atomvm/AtomVM/pull/1514

this happens after https://github.com/atomvm/AtomVM/pull/1546 - seems related to network_driver callbacks - reverting the PR change makes everything green.. but as @pguyot said it's most likely some other error, being surfaced.....

> Let's check if this crash is related in any manner to the previous error: timestamps;-) this error is after the crashing starts, and only happens due to the restarts..

> This should not be used in the sim test. What you get is the equivalent of an Ethernet interface, there is no wireless signal strength to be measured. sim...

this looks to be resolved by #1603

The whole nif/component situation is confusing DX. The remaining nifs https://github.com/atomvm/atomvm_lib/blob/master/nifs/atomvm_lib.c are extremely few and most if not all have atomvm implementations.. so I suggest we remove the nifs and...

this happens due to a crash and restart(from other test), which means this line which is expected to be catch'ed and return ok, returns the actual rtc_slow https://github.com/atomvm/AtomVM/blob/bafd18b7869e319165a92f2f91b1901811d07cc9/src/platforms/esp32/test/main/test_erl_sources/test_rtc_slow.erl#L30 eg. this...

Can't test (no pico) but LGTM.. Maybe I would depend on the hex release instead of github tag, but total nitpick.