Differences between Micropython ports for ESP32 and ESP8266

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
OutoftheBOTS_
Posts: 474
Joined: Mon Nov 20, 2017 10:18 am

Re: Differences between Micropython ports for ESP32 and ESP8266

Post by OutoftheBOTS_ » Sun Oct 14, 2018 8:27 pm

If TouchPad was instantiated on a platform without cap touch features - like STM - then either the API shouldn't exist for that port or, better, an exception ("Capacitive touch not present for this port") should be raised.
I like the idea of an exception being raised if the feature doesn't exist on that port. That way code is portable and if u try to use a feature the hardware doesn't have then u get an exception. The big advantage is 1 standard docs for all ports. although MP seems to be able to get contributors to write code getting contributors to write docs seems a little harder :)

User avatar
pythoncoder
Posts: 3157
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: The pyb module

Post by pythoncoder » Mon Oct 15, 2018 7:11 am

mattyt wrote:
Sun Oct 14, 2018 10:56 am
...But I don't see any good reason to leave methods in pyb that already have equivalents...
I do. It would break almost all of my code.

For all that there may be an "equivalent" in machine, they often differ in detail. Sufficiently to cause a major headache if you have a lot of code to maintain.

I'd fight any removal of features from pyb. Judging by Damien's comments on GitHub I think it's unlikely to happen.

The ideal outcome would be one where machine improves to the point where pyb can be deprecated for all but a few special STM-specific purposes.
Peter Hinch

User avatar
mattyt
Posts: 159
Joined: Mon Jan 23, 2017 6:39 am

Re: The pyb module

Post by mattyt » Wed Oct 17, 2018 1:34 am

pythoncoder wrote:
Mon Oct 15, 2018 7:11 am
mattyt wrote:
Sun Oct 14, 2018 10:56 am
...But I don't see any good reason to leave methods in pyb that already have equivalents...
I do. It would break almost all of my code.
I don't want to break anyone's code. :) I'm not suggesting removing anything, at least not in any short timeframe. The order should be: ensure there are appropriate replacement methods, mark 'old' ones as deprecated, sometime later (or maybe never) remove the old methods.
pythoncoder wrote:
Mon Oct 15, 2018 7:11 am
For all that there may be an "equivalent" in machine, they often differ in detail. Sufficiently to cause a major headache if you have a lot of code to maintain.

I'd fight any removal of features from pyb. Judging by Damien's comments on GitHub I think it's unlikely to happen.
OK, maybe I need to let go of the idea of ever removing them. I certainly don't want to fight you. :D I'm ok with leaving them in - my main concern is to a) provide new users clear guidance what to use and b) figure out how to better handle when port must diverge.
pythoncoder wrote:
Mon Oct 15, 2018 7:11 am
The ideal outcome would be one where machine improves to the point where pyb can be deprecated for all but a few special STM-specific purposes.
Agree completely.
OutoftheBOTS_ wrote:
Sun Oct 14, 2018 8:27 pm
I like the idea of an exception being raised if the feature doesn't exist on that port. That way code is portable and if u try to use a feature the hardware doesn't have then u get an exception.
I think this makes sense too. Peter, do you have an opinion?
OutoftheBOTS_ wrote:
Sun Oct 14, 2018 8:27 pm
The big advantage is 1 standard docs for all ports. although MP seems to be able to get contributors to write code getting contributors to write docs seems a little harder :)
I have a strong desire to at least create ESP32 docs based on the current documentation system, even if it is for the most part duplicates of ESP8266. This shouldn't take a huge amount of effort; it's writing and updating the docs to describe the ESP32 differences that will take more of an effort. But if I can at least put in place the stubs we can build on it...

Looking further out I would like to think we could have common documentation for all the ports with callouts where specific ports differ from the generic implementation. However this will take some time and is beyond my current commitment level.

User avatar
pythoncoder
Posts: 3157
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: The pyb module

Post by pythoncoder » Wed Oct 17, 2018 5:58 am

mattyt wrote:
Wed Oct 17, 2018 1:34 am
...
OutoftheBOTS_ wrote:
Sun Oct 14, 2018 8:27 pm
I like the idea of an exception being raised if the feature doesn't exist on that port. That way code is portable and if u try to use a feature the hardware doesn't have then u get an exception.
I think this makes sense too. Peter, do you have an opinion?
...
It's a good idea.

As is documenting ESP32.

As for ESP32 I can't take it seriously (in official or Loboris form) until this is fixed. I fail to see any practical application for a device which can't handle a WiFi outage.
Peter Hinch

danielm
Posts: 138
Joined: Mon Oct 05, 2015 12:24 pm

Re: Differences between Micropython ports for ESP32 and ESP8266

Post by danielm » Fri Nov 30, 2018 8:11 am

Hi all, based on the fact that Pycom team tends to move their focus from dev/OEM module development to consumer products (PyGo/PyLife) we are considering to build FW stack of our products on micropython.org ESP32 port. I did not follow this forum very often for more than a year. Looking at the github there are some esp32-related commits from time to time.

My questions is what is current perception of regular forum members and code contributors regarding maturity and long-term development of micropython.org ESP32 port?

User avatar
mattyt
Posts: 159
Joined: Mon Jan 23, 2017 6:39 am

Re: Differences between Micropython ports for ESP32 and ESP8266

Post by mattyt » Thu Dec 20, 2018 8:49 am

There are a couple of key issues with it but, for me, it's clear that the ESP32 port is of tremendous importance. Almost all of my 'side project' time will be spent using and, hopefully increasingly, contributing to that port.

danielm
Posts: 138
Joined: Mon Oct 05, 2015 12:24 pm

Re: Differences between Micropython ports for ESP32 and ESP8266

Post by danielm » Sat Dec 22, 2018 1:46 pm

I am glad to hear that the ESP32 port will be developed and maintained. I will start testing soon. I want to use Pycom WiPy 3.0 as a hardware because it contains very good switching regulator (LM3281) and I want to test deep-sleep currents as well. Should micropython.org port work on this board or should I expect some issues?
I also have ESP32-WROOM based devkit but I am not sure if there are some peripherals which might affect deep-sleep current measurement.

Post Reply