Alignment between ESP32 and ESP8266 library

Question

Alignment between ESP32 and ESP8266 library

pjsg opened this issue 3 years ago · comments

Philip Gladstone commented 3 years ago

Expected behavior

Functions like file.getcontents ought to be available (and behave the same) on both ESP32 and ESP8266 branches.

Actual behavior

file.getcontents isn't available on the dev-esp32-idf4 branch.

This is just one example of the differences -- the wifi module is different as well. It isn't clear which is the path forward -- it would be nice to align some of this stuff. I suspect that the esp8266 stuff has progressed and left the esp32 stuff behind, but I'm not sure.

Thoughts?

Marcel Stör · Answer 1 · Tue Oct 19 2021 21:27:52 GMT+0800 (China Standard Time)

Even the partial list from 2018 is daunting and discouraging: https://github.com/nodemcu/nodemcu-firmware/wiki/ESP8266---ESP32-Compatibility

I believe when @jmattsson created the ESP32 port he considered the shortcomings of the initial API and improved it.

Philip Gladstone · Answer 2 · Tue Oct 19 2021 21:42:02 GMT+0800 (China Standard Time)

I'm happy if we say that the ESP32 versions are the way forward, but I suspect that much of the 8266 interface is actually an improvement.

Philip Gladstone · Answer 3 · Wed Oct 20 2021 05:37:26 GMT+0800 (China Standard Time)

Maybe we should just decide on what to do on a module-by-module basis. The two of interest to me (at the moment) are:

file https://nodemcu-firmware.readthedocs.io/en/dev-esp32/modules/file/ vs https://nodemcu-firmware.readthedocs.io/en/master/modules/file/
wifi https://nodemcu-firmware.readthedocs.io/en/dev-esp32/modules/wifi/ vs https://nodemcu-firmware.readthedocs.io/en/master/modules/wifi/

I propose that the esp8266 interface is better than the current esp32 interface and we should migrate forwards.

Any contrarians?

Jade Mattsson · Answer 4 · Wed Oct 20 2021 15:51:08 GMT+0800 (China Standard Time)

I'm in the process of deprecating most of the file module in favour of the standard Lua io module on the ESP32...

Also keep in mind that the underlying SDKs are utterly different between the 8266 and the 32, both in terms of structure and in terms of features.

Marcel Stör · Answer 5 · Fri Oct 22 2021 04:02:30 GMT+0800 (China Standard Time)

I feel that whatever we do on the ESP32 side we should leave the ESP8266 APIs as is. On the ESP32 side we have complete freedom IMO as we never officially released anything.

Jade Mattsson · Answer 6 · Fri Oct 22 2021 04:58:30 GMT+0800 (China Standard Time)

I feel that whatever we do on the ESP32 side we should leave the ESP8266 APIs as is.

I agree. The API there is the way it is for good reason (well, mostly at least). Trying to shoehorn an ESP32-based view onto it makes as little sense as shoehorning the 8266isms onto the ESP32.

Philip Gladstone · Answer 7 · Fri Oct 22 2021 05:30:19 GMT+0800 (China Standard Time)

I think that there are cases where the APIs have diverged and there is no reason to maintain the divergence. For example on esp8266 you call wifi.setmode(blah) to set the mode, whereas on ESP32 it is wifi.mode(blah) I think it will be useful to add pages in the documentation that explain where old modules have gone -- e.g. the pwm module is now replaced by the ledc module.

…

On Thu, Oct 21, 2021 at 4:58 PM Johny Mattsson ***@***.***> wrote: I feel that whatever we do on the ESP32 side we should leave the ESP8266 APIs as is. I agree. The API there is the way it is for good reason (well, mostly at least). Trying to shoehorn an ESP32-based view onto it makes as little sense as shoehorning the 8266isms onto the ESP32. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3470 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALQLTPDBEVSR3O2MAB7JWLUIB5IFANCNFSM5GH67YZQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

Jade Mattsson · Answer 8 · Fri Oct 22 2021 08:05:21 GMT+0800 (China Standard Time)

I'd quite like to have us settle on some sort of standard naming convention. It's all a bit of a mess at the moment.
Something like

Functions consisting of multiple words should (or should not) contain underscores between the words (or camel case even?)
Setters are (or are not) prefixed with "set", while getters are (or are not) prefixed with "get".
Module constants are in upper case, with underscores between words (I think this is one that's mostly followed?)

I'm really not too fussed about which way we lean, as long as we're consistent about it. Right now on the esp32 we have wifi.sta.setip() but eth.set_ip() for example, which is a bit confusing.

Terry Ellison · Answer 9 · Fri Oct 29 2021 16:16:28 GMT+0800 (China Standard Time)

I'm in the process of deprecating most of the file module in favour of the standard Lua io module on the ESP32...

@jmattsson, there are pros and cons this approach, so perhaps it is worth thinking through and discussing the implications.

I realise that file library was a bit of an interim botch by zeroday as his original intention was to introduce a proper io implementation at some point. It has also evolved in a somewhat uncontrolled manner, and now includes elements of os and other convenient methods. A lot of ESP Lua developers have now written code for the ESP8266 implementation, and this is quite a break that will force them to do a lot of recoding to migrate to ESP32, and this could be significantly mitigated by keeping (possibly) a subset library which is essentially a wrapper around the io implementation.