Atomvm for ADC ESP32

Hello @Winford , I was trying to use atomvm_adc but it turns out that all its functions were deprecated for versions higher than 5 of the espressif sdk, so I took a while to make a new compatible nif, I am new to this, I have just learned how to use it, I did a nif for nerves but it was easier. I need to include documentation and examples of use. But I have this error when compiling, let’s see if you can help me.

This is the repository. GitHub - joserp93/atomvm_adc


Linking CXX executable atomvm-esp32.elf
/Users/joserodriguez/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/../lib/gcc/xtensa-esp-elf/13.2.0/../../../../xtensa-esp-elf/bin/ld: unrecognized option '--whole-archive /Users/joserodriguez/atomvm/atomvm-v0.6.0/src/platforms/esp32/build/esp-idf/atomvm_adc/libatomvm_adc.a -Wl'
/Users/joserodriguez/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/../lib/gcc/xtensa-esp-elf/13.2.0/../../../../xtensa-esp-elf/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status
make[2]: *** [atomvm-esp32.elf] Error 1
make[1]: *** [CMakeFiles/atomvm-esp32.elf.dir/all] Error 2
make: *** [all] Error 2

This is the repository. GitHub - joserp93/atomvm_adc

Hello, is this Fred’s codebase?

Hi, Yes, I took Fred’s code as a base.

So before I go digging to deep, let me be sure I understand what you are doing. Is this code for IDF v5.x compatibility?

That’s right, I read the IDF v5.x documentation and made it compatible.

Take a look at atomvm_adc/CMakeLists.txt at master · atomvm/atomvm_adc · GitHub

You might need to update the LINK_OPTIONS arguments, try:

LINK_OPTIONS "-Wl,--whole-archive;${CMAKE_CURRENT_BINARY_DIR}/lib${COMPONENT_NAME}.a;-Wl,--no-whole-archive"

If you get it to work on IDF v5.x, I’d suggest you create a PR to the official repo instead.

1 Like

I don’t have access to push the new branch.

Ok, I started to work on IDF v5 compatibility, but got a bit waylaid working on some issues in the VM core. I plan on getting back into to it as soon as I finish working on some enhancements for the esp32 network driver.

If you want to work on this, be sure you are aware of all the breaking changes, the v5.x ADC driver and configuration bears almost no resemblance with the 4.x version. Now there are a lot of handles that need to be kept track of, so a simple nif implementation will not work. The driver will either need to be implemented as a gen_server, or as a resource based nif. Resource based nifs are fairly new in AtomVM but give you the ability to maintain some resources in memory and have a handle to access them from a nif (basically giving you the ability to maintain State without a full blown gen_server). This was the approach I was working on.

I would be happy to help you answer any questions you have if you want to continue working on it. If you don’t get it figured out, I was planning on getting back to this, hopefully by the middle of May. Since the APIs are completely different I was planning on submitting the IDF v5 ADC driver directly to AtomVM as a core component. Version 4.4.x of the ESP-IDF will be retired this summer and we do release builds from v5.x, so anyone needing a v4.4 could still build their own with the standalone atomvm_adc.

Same here, I tried to adjust the official ADC driver but changes were too deep and I’m not using v4.x anymore. I also have a PoC of a resource based NIF for ADC1/2, from scratch, but it needs more testing. @Winford maybe we can sync up and come up with a better one? :smiley:

Yes, you can look at the link options from the esp32 CMakeLists.txt files to see how to link with v5.x.

Absolutely!!! We should collaborate and submit a PR to AtomVM core, the only reason ADC isn’t there yet is because we don’t yet support v5.x.

…and ADC unit2 is buggy in atomvm_adc, It can only be used if WiFi is stopped, and the esp32 network driver was not stopping the network, only the controlling gen_server when network:stop is used. I have a PR in right now under review to fix that problem.

Adding the ability to put the WiFi driver to sleep while using unit_2 would be sufficient, so the network can be brought back up quickly with a resume… This is on the list of previously mentioned enhancements I’m working on.

My apologies, I responded before finishing my coffee! I repeatedly used gen_server when I mean to say port driver. A regular nif won’t work. The implementation needs to be either a port or a resource based nif.