[ESP32] Add ESP-IDF 3.3 support #567
Conversation
-- Removed reference to deprecated ESP AES function. -- Changed logic around definition of LWIP_DNS_FOUND_CALLBACK_TYPE in DNSResolver code. Previously, the logic surrounding the definition of LWIP_DNS_FOUND_CALLBACK_TYPE was written with the presumption that the define existed in later versions of LwIP, and therefore only needed to be declared in versions < 2. However LWIP_DNS_FOUND_CALLBACK_TYPE has *never* been a feature of stock LwIP. Rather, it appears to be a Nest-ism intruduced in an internal fork of LwIP. This change corrects the definition logic such that DNSResolver works with the LwIP version included in ESP-IDF 3.2. -- Ignore -Wdeprecated-declarations warnings when calling esp_wifi_get/set_auto_connect(). Later versions of ESP-IDF mark esp_wifi_get_auto_connect() and esp_wifi_set_auto_connect() as depricated, leading to compilation errors. Unfortunately, no obvious alternative exists, and the comments and commit message provide no guidence. A inquiry has been made to the Expressif team. Pending their answer, the decision has been made to continue using the existing APIs.
|
|
||
| # Always remove archives after built, the timestamp of the archive might not change | ||
| # sometimes if not do so, then the image built will using outdated code. | ||
| $(OUTPUT_DIR)/libopenweave.a : $(OPENWEAVE_STATIC_ARCHIVES) |
There was a problem hiding this comment.
Please make libopenweave.a depend on the input libraries directly so that it is only updated when one of the inputs changes. As part of this, you can eliminate the use of the .d directories entirely and extract the contents of the input libraries into a temporary directory directly within this rule.
Note that there is a separate bug that causes the timestamps of the input libraries to change on every build, which results in the application being rebuilt every time. This will be fixed later.
There was a problem hiding this comment.
I tried to rewrite this in the new commit, PTAL.
erjiaqing
force-pushed
the
esp-3.3
branch
2 times, most recently
from
8c1efca to
492d0b5
Compare
erjiaqing
force-pushed
the
esp-3.3
branch
2 times, most recently
from
f5b1cc6 to
4cb37fa
Compare
|
I have added some compile time checks to let CI with esp-idf 3.0 happy, these can be removed if CI is upgraded to esp-idf 3.3 |
erjiaqing
changed the title
Codecov Report
@@ Coverage Diff @@
## master #567 +/- ##
===========================================
+ Coverage 54.14% 69.90% +15.76%
===========================================
Files 331 483 +152
Lines 57655 86731 +29076
===========================================
+ Hits 31218 60632 +29414
+ Misses 26437 26099 -338
Continue to review full report at Codecov.
|
erjiaqing
force-pushed
the
esp-3.3
branch
3 times, most recently
from
200b957 to
d33baaa
Compare
robszewczyk
requested review from
bukepo,
gjc13,
jwhui,
kghost,
lanyuwen and
librasungirl
After patched ESP-IDF 3.2, these updates is required by ESP-IDF 3.3
- Update component.mk to build libopenweave.a
ESP-IDF 3.3 assumed that lib(componentname).a is built
- dns_getserver now returns const ip_addr_t*
Change-Id: I74b37cfdb11a306a7a7e1b3a539d0031b112749b
I would suggest to focus on esp-idf 3.3 so that these compile time checks could be removed. |
True, I would suggest create 3 prs
|
I think we can simply move on to support esp-idf 3.3 directly. We don't have to make CI happy all the time - especially when we want to upgrade the toolchains. @robszewczyk thoughts? |
|
@erjiaqing Can you explain the detailed step to direct upgrade to esp-idf 3.3. How many repos and how many PRs are involved, are they all ready or not. |
|
@robszewczyk PTAL, this PR won't break the master. and it has been ready for a long time, I'd like to merge this PR as soon as possible. One concern is whether to use the ESP 3.3 macros, I guess we can submit a PRs to update the CI in esp32-demo and so we can remove these if needed. |
This PR cherry picks
f70c83bto master.After patched ESP-IDF 3.2, these updates is required by ESP-IDF 3.3
component.mkto buildlibopenweave.aESP-IDF 3.3 assumed that
lib(componentname).ais builtconst ip_addr_t*Testing this PR requires openweave/openweave-esp32-demo#14 and its lwip submodule should be checked out to openweave/openweave-esp32-lwip#2
Tested features:
reset-configfrom WDM