search

nodemcu / nodemcu-firmware

Lua based interactive firmware for ESP8266, ESP8285 and ESP32
https://nodemcu.readthedocs.io
MIT License
7.64k stars 3.12k forks source link

Alignment between ESP32 and ESP8266 library #3470

Open pjsg opened 2 years ago

pjsg commented 2 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?

marcelstoer commented 2 years ago

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.

pjsg commented 2 years ago

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.

pjsg commented 2 years ago

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?

jmattsson commented 2 years ago

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.

marcelstoer commented 2 years ago

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.

jmattsson commented 2 years ago

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.

pjsg commented 2 years ago

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 https://github.com/nodemcu/nodemcu-firmware/issues/3470#issuecomment-948997391, 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.

jmattsson commented 2 years ago

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

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.

TerryE commented 2 years ago

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.