Page 1 of 4

Integrating Loboris port back to official uP ESP32 port

Posted: Sat Mar 30, 2019 6:06 pm
by chMK
Hi

The Loboris port seems dormant. Boris has done a great job further customizing uP to the ESP32. It would be a shame if the progress would be lost.

Dear uP team - what is your opinion of integrating it in the official ESP32 port?

The differences are substantial and it is well customized to the ESP32 MCU. Looking forward I hope Espressif will release new MCU‘s with the possibility of porting whats used today.

Re: Integrating Loboris port back to official uP ESP32 port

Posted: Mon Apr 01, 2019 9:57 am
by pidou46
I think you are right, LOBORIS seem's to be focussed on Kendryte K210 port now.

And yes, it would be nice to have the work done by LOBORIS merged back in the official ESP32 port. But my understanding is that, each project have somehow diverged and copy /paste from one project to the other is not a option.

But some work have already be done tougth (PSRAM support is the most significant to me, but also ULP coprocessor, ect...)

Maybe we can build a hierarchized list of what would be usefull to merge back ?

Re: Integrating Loboris port back to official uP ESP32 port

Posted: Mon Apr 01, 2019 10:03 am
by kevinkk525
pidou46 wrote:
Mon Apr 01, 2019 9:57 am
Maybe we can build a hierarchized list of what would be usefull to merge back ?
That's probably a good idea. This way the developers could decide if those features are worth trying to integrate without knowing every feature the loboris port has.

One feature I'd like to see is the integration of the hardware I2C interface.

Re: Integrating Loboris port back to official uP ESP32 port

Posted: Mon Apr 01, 2019 2:31 pm
by mattyt
pidou46 wrote:
Mon Apr 01, 2019 9:57 am
Maybe we can build a hierarchized list of what would be usefull to merge back ?
I started this last night - but it's quite a list! For each feature there's a non-trivial bit of information to collect.

For example, RMT. The RMT module of the ESP32 provides some pretty neat features. However the Loboris port doesn't implement it in a way that's as useful as it could be; or at least the way I would consider appropriate for mainline. My opinion is that it would be better as a module accessible to MicroPython directly. The Lobo port implements it such that it can only be used from C - and then built implementations of Neopixel and other one-wire devices on top of that, also in C. So the RMT implementation isn't particularly useful IMO. (I'm trying to find time to work on an RMT implementation...)

Having I2C Slave capabilities would be great - currently only the PyBoard has this feature and it's buried in the pyb module - but the API presented in the Lobo port hasn't been designed with other ports in mind. It's unlikely to be accepted upstream. Really, first, 3935 needs to be resolved.

HW I2C would be helpful but does it offer many benefits? Maybe not, probably still nice-to-have. (at least for @kevinkk525!) :)

Mainline has improved support for PSRAM, PWM and _thread. But we'll need to take a closer look to see if there's anything further that the Lobo port adds for those features that could be integrated.

I fear Display will be difficult to merge upstream. MicroPython is lacking such a library but the implementation seems complex and difficult to extend; adding a new display driver wasn't intuitive to me. But maybe it warrants more attention? Regardless, until it can be implemented across multiple ports it's a tough sell...

There's a lot of important detail - and that's less than half of the headings I've started listing. Very few features easily merge upstream though with all of them it will be useful to use the Lobo port as a reference.

Maybe we should start a document...?

Re: Integrating Loboris port back to official uP ESP32 port

Posted: Mon Apr 01, 2019 2:58 pm
by Mike Teachman
Loboris did the ESP32 community a great service to bring the value of the ESP-IDF to the ESP32 port. I agree that now is time to see that work brought back into the mainline (even if Boris resumes work on his port). The ESP32 uPy port has so much more potential that is not being realized.

To me, the challenge of this idea is mostly organizational and project management, and less technical.

I wonder:
1. Who would organize the technical volunteers to bring LoBo features into the ESP32 port? Does the lead architect and maintainer Damien George have the time to do this? Surely Damien's time to work on the ESP32 port is limited by the work on all the other ports, not to mention the new PyBoard D initiative.
2. Who decides what ESP32 features volunteers will work on? How can we avoid duplication of work?
3. Who organizes peer reviews of the proposed implementations and code PRs?

What if, the ESP32 port had a dedicated volunteer project manager, who:
1. collaboratively made decisions on what features go into the ESP32 port.
2. organized technical volunteers to develop and port features (not limited to LoBo features)
3. organized small teams of peer reviewers
4. regularly communicated the status of this work back to the uPy community.
5. worked closely with Damien to integrate those features into the ESP32 port, with Damien maintaining absolute veto and architect oversight.
6. made sure everyone worked respectively together, in spite of egos, and technical disagreements

Sometime this year Espressif is going to release a new device, which will likely have native USB. Will the uPy community have the organization structure in place to quickly develop a highly featured uPy port? That is my dream !

Again, I'm convinced that the greatest challenge is organization and leadership. Unfortunately, some process is needed for this effort to be successful. Can this challenge be solved?

The best use for people's skills?

Posted: Mon Apr 01, 2019 4:54 pm
by pythoncoder
In my view the Pyboard D is a vastly superior solution compared to ESP32, being a baremetal MicroPython port with the WiFi offloaded to a separate chip. The ESP32 has sluggish response times owing to its underlying RTOS. By contrast the Pyboard D properly decouples WiFi operations from the MicroPython VM. There are also indications that the Pyboard D is much more power efficient, although I haven't yet measured this properly.

Of course people are free to develop whatever inspires them, but I reckon efforts put into the Pyboard D will be more rewarding. A similar wishlist could be compiled for that platform...

Re: Integrating Loboris port back to official uP ESP32 port

Posted: Mon Apr 01, 2019 5:12 pm
by Roberthh
PYBD: With USB & WiFi @120MHz about 28 mA
PYBD: With USB & WiFi @216MHz about 50 mA
ESP32: With USB/UART Bridge & WIFI @240MHz: about 50 mA

but the PYBD feels much more responsive, even at 120 MHz. And the runtest.py script that circulated recently runs faster on a PYBD, even at 120 MHz, but surprisingly not in all tests faster than Pyboard 1.1 at the same frequency. The differences are however small. And I tested with the '722 chip.
When ordering, i did not see the other devices. And when I noticed them, they were already gone. So I have to wait for the next batch.

Re: Integrating Loboris port back to official uP ESP32 port

Posted: Mon Apr 01, 2019 5:15 pm
by ThomasChr
I totally agree. But I would like to mention the vast price difference between a cheap ESP32 and the Pyboard D...

So I think that the ESP32 also has his applications. Sometimes you just need cheap...

Re: Integrating Loboris port back to official uP ESP32 port

Posted: Mon Apr 01, 2019 5:39 pm
by kevinkk525
ThomasChr wrote:
Mon Apr 01, 2019 5:15 pm
I totally agree. But I would like to mention the vast price difference between a cheap ESP32 and the Pyboard D...

So I think that the ESP32 also has his applications. Sometimes you just need cheap...
That's exactly the point here. If we all had the money, we'd happily buy the pyboard D.
But the pyboard D costs >45€ while the ESP32 without PSRAM can be bought for about 7€ and is still a very powerful platform.

Re: Integrating Loboris port back to official uP ESP32 port

Posted: Mon Apr 01, 2019 8:24 pm
by OutoftheBOTS_
I fear Display will be difficult to merge upstream. MicroPython is lacking such a library but the implementation seems complex and difficult to extend; adding a new display driver wasn't intuitive to me. But maybe it warrants more attention? Regardless, until it can be implemented across multiple ports it's a tough sell...
The display driver is 1 of the biggest reason that I use Lobo port. These little SPI screens are really the goto UI for MCUs and the LoBo display module is about 1 of the best drivers I have used.