port from esp-idf to zephyrproject, to make this usable on a wider range of embedded hardware

[pinkit-cwa]

@Lurkars can you please share sdkconfig.h and the file containing your CONFIG_* macros? otherwise I need a lot of guessing., e.g. CONFIG_ENA_TEK_ROLLING_PERIOD: number of intervals (144) or number of seconds per day?

[pinkit-cwa]

zephyr builds on esp-idf. This makes things quite easy for me - I do not need to pert anything, as I can just continue to use the esp-idf implementation for BT etc. for now from withing zephyr. Once it compiles, I will send a first pull request.

After that, I can continue to replace esp-idf API by zephyr API. In the end, we should have a product that compiles on nRF52 etc.

[Lurkars]

@pinkit-cwa The default values can be found here https://github.com/Lurkars/esp-ena/blob/main/components/ena/Kconfig.projbuild
It is from the esp-idf build system, where those values are generated into sdkconfig.h with CONFIG_ prefix. So you should be able to see the values there. Since the sdkconfig.h is generated automatically on build, it is a file I should not provide here.

[pinkit-cwa]

OK, I'm trying.

idf.py build just failed due to not cofigured bluetooth support. So I enabled that using idf.py menuconfig. Do you have hints what I should also enable / change to be able to compile and link using esp-idf?

[Lurkars]

have a look at https://github.com/Lurkars/esp-ena#configure-the-project
In menu config you also see (and can change) all the params you're asked about in sdkconfig.h. They can be configured there. You should also enable "Erase Storage" in Exposure Notification API -> Storage for first start. I also recommend to change the main.c to remove all full device features, so the simple main should just look like this:
void app_main(void) { ena_start(); while (1) { ena_run(); vTaskDelay(1000 / portTICK_PERIOD_MS); } }
of course your system timestamp will be 0, so you can set a hard-coded timestamp if you don't have RTC for now
struct timeval tv = { }; settimeofday(&tv, NULL);

[Lurkars]

I think it won't be possible to just run the esp-idf code in zephyr, because it depends on FreeRTOS. I'll also take a look at the port myself next days.

[pinkit-cwa]

I changed this plan a bit. It seems like there are many platform-specific development environments including their own APIs (e.g. arduino, esp-idf, zephyr). Most (if not all) IDEs are usable from within PlatformIO.

To make this code usable on as many of these as possible, I think it would be good to have a wide variety of implementations of the same functionality ("internet access", "sending/receiving EN beacons", "display", "realtime clock") on different API and hardware.

#7 makes this project compile both in PlatformIO as well as esp-idf. It also includes two different implementations of connecting to WIFI, for ESP-IDF API version 4.0 and 4.1. This is needed because PlatformIO has not yet switche to "current" ESP-IDF, which is 4.1.

Next step is to add (not replace by) implementations of bluetooth etc. for nRF52, based on the stuff implemented in CovidBracelet. My goal would be that you can (for now) continue to use esp-idf, until you find time to have a look at PlatformIO.

I see some issues with PlatformIO, though. It uses multiple CMakeLists.txt and Kconfig* for each directory. That is because the original IDEs have different ideas about what should be placed where, and PlatformIO seems to have to stay close to these expectations to keep the complexity lower. But, this makes things more complex for projects that strive to compile and link in multiple development environments, as these must maintain multiple "almost-copies" of these files. Must think of some way to improve this situation. Maybe it would be good to separate these files (build environment) from the sources, but this also make things more complex and probably even harder to maintain.

[pinkit-cwa]

It was helpful that you already put wifi.c into a separate component directory. But maybe we should call it someting like "internet connection" , and probably we should also include the configuration stuff there, as this is highly WIFI-specific. Some implementations might want to do this via other means than wifi.

[Lurkars]

I want to create a new branch for zephyr development not to break current status.