cpu/esp8266: fix compilation problems if module esp_wifi is not used

[gschorcht]

Contribution description

This PR fixes a minor compilation problem caused by the changes in PR #10862. The problem occurs only if module esp_sdk or esp_sw_timer is used without module esp_wifi.

Background

If one of the modules esp_sdk, esp_sw_timer or esp_wifi is enabled, the Espressif SDK must be used. The SDK has to be linked against its own version of the lwIP library, which requires a lot of resources. However, since this version of lwIP is unusable with RIOT, a dummy lwIP was introduced in PR #10862 which overrides all lwIP functions called during system initialization with dummy functions. These dummy functions have no real functionality and leave the lwIP of the SDK uninitialized so that it does not consume any resources.

The dummy lwIP function approach works as long as module esp_wifi is enabled. However, if only module esp_sdk or esp_sw_timer is used, a number of multiple definition errors occur during linking.

Solution

This PR defines an initialization function of the dummy lwIP which is called during system start independent on whether module module esp_wifi is used or not.

Initially, I planned to provide this fix as part of PR #9917. However, since the changes in this PR fix a compilation problem and PR #9917 is still not reviewed, I provide them as aseparate PR.

Testing procedure

Compile test/periph_time with module esp_sw_timer. Compilation should succeed with the PR but should fail without the PR.

USEMODULE=esp_sw_timer make -C tests/periph_timer BOARD=esp8266-esp-12x

Issues/PRs references

Compilation problem was introduced with PR #10862.

[gschorcht]

@smlng I there any chance to get this bug fix merged before code freeze?

[smlng]

sure, however it doesn't fail for me on current master, so where is the problem? maybe because #9917 is merged?

[gschorcht]

@smlng Sorry, my fault. I was completely confused with all the different branches and which change is based on which. When I opened this PR, I still supposed that PR #9917 will be delayed further. I said in description:

Initially, I planned to provide this fix as part of PR #9917. However, since the changes in this PR fix a compilation problem and PR #9917 is still not reviewed, I provide them as aseparate PR.

Of course, since #9917 is already merged, this PR seems to be obsolete. Sorry for the confusion

[gschorcht]

@sming Thank you for trying to review 😎