8000 esp32: esp-idf version thoughts -- v3, v4.0, v4.1 · Issue #5830 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

esp32: esp-idf version thoughts -- v3, v4.0, v4.1 #5830

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
tve opened this issue Mar 28, 2020 · 5 comments
Closed

esp32: esp-idf version thoughts -- v3, v4.0, v4.1 #5830

tve opened this issue Mar 28, 2020 · 5 comments
Labels
port-esp32

Comments

@tve
Copy link
Contributor
tve commented Mar 28, 2020

What is the plan WRT supported esp-idf versions? I have only used v4 personally and have been happy. V4.0 is released. V4.1 just entered beta.

Motivation: I've just spent ~2 hours tracking down why tests/net_inet/test_tls_sites.py is broken in v1.12 for api.telegram.org. It produces error 113. That seems to be EHOSTUNREACH according to MP's mperrno.h and linux's errno.h. But truth is that esp-idf v4.0 uses newlib's errno.h and there 113 is ECONNABORTED, hmmm. EHOSTUNREACH is 118, which has sent others into a loop (cf mqtt_as.py).
Why does esp-idf use newlib's errno.h when it has its own that is properly posix compliant? Probably because other esp-idf components also use errno.h, like bluetooth.
How to fix? I could add more error code mappings into various MP esp32 libs, but esp-idf v4.1 no longer has newlib's sys includes so moving to that probably fixes the issue (I haven't tried).

Questions I have:

  • Would a PR to add esp-idf v4.1 support be accepted? Or are 3 supported versions too much?
  • What is needed to be able to remove v3 support?
@tve tve mentioned this issue Mar 28, 2020
Closed
@tve
Copy link
Contributor Author
tve commented Mar 28, 2020

Update, I found an easy fix for the LwIP error codes and will produce a PR. However, this doesn't help any other modules that use EXXX error constants. Dunno what bluetooth uses, etc.

@carstenblt
Copy link

An upgrade to 4.1 when it's released would be great, there still is espressif/esp-idf#2892

@dpgeorge
Copy link
Member

Would a PR to add esp-idf v4.1 support be accepted? Or are 3 supported versions too much?

Once the port moved to support v4.1 (when v4.1 is officially released, not just beta) then v4.0 support would be dropped. I don't see any reason to have both, too much effort to maintain.

What is needed to be able to remove v3 support?

Support for v4 was added to get Nimble support. But that is now also working in v3, hence not much effort has been put in to making v4 the default.

To make v4 on par with v3 requires getting network.LAN and network.PPP working on v4.

@tve
Copy link
Contributor Author
tve commented Apr 14, 2020

Interesting... LAN and PPP... not sure how think about that. I don't have HW to even try LAN, not sure how PPP gets used, over serial? In any case, it seems to me that must be <1% of user base? So we have to put the burden on everyone to maintain v3 for those few? Why isn't the burden on those few to submit PRs to upgrade to V4?

@dpgeorge
Copy link
Member

not sure how PPP gets used, over serial?

Yes, usually through a cellular module, which is very useful. And LAN use also seems to be relatively popular.

So we have to put the burden on everyone to maintain v3 for those few? Why isn't the burden on those few to submit PRs to upgrade to V4?

It's not that hard to maintain v3, and it's well tested. And we can't just have useful features disappear.

@tve tve closed this as completed Apr 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
port-esp32
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tve @dpgeorge @carstenblt
0