Integrating Loboris port back to official uP ESP32 port

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
chMK
Posts: 4
Joined: Sat Mar 30, 2019 5:59 pm

Re: Integrating Loboris port back to official uP ESP32 port

Post by chMK » Mon Apr 08, 2019 6:51 am

I think we‘d need to vote on some requirements (for example display).

Does anyone have a use-case for the RMT peripheral that isn‘t just driving Neopixels?

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

Re: Integrating Loboris port back to official uP ESP32 port

Post by mattyt » Mon Apr 08, 2019 8:22 am

chMK wrote:
Mon Apr 08, 2019 6:51 am
Does anyone have a use-case for the RMT peripheral that isn‘t just driving Neopixels?
Yes; a friend wants to use it for comms to his radio transmitter to control his quadcopter. It's a timing sensitive one-wire protocol.

The Loboris port also uses RMT to implement DHT and 1-wire protocols.

I believe that if we can present a reasonable API to RMT it could be used for a number of tasks. Note that it can also be used to measure pulses.
Roberthh wrote:
Mon Apr 08, 2019 5:25 am
Display is a good example of a function which can as well be implemented in Python, maybe at slower speed, and therefor a port is not necessary. If at all, only modules should be ported which cannot be implemented in python, like slave SPI/I2C modes, RMT, etc.
It's possible parts of Display could be implemented in Python but I suspect fairly significant chunks of it will need to be implemented in C. A lot of it - drawing circles, manipulating bytes, font management etc - require high levels of performance to be usable. Measure first, of course, but a display driver is certainly performance sensitive.

OutoftheBOTS_
Posts: 847
Joined: Mon Nov 20, 2017 10:18 am

Re: Integrating Loboris port back to official uP ESP32 port

Post by OutoftheBOTS_ » Mon Apr 08, 2019 8:30 pm

It's possible parts of Display could be implemented in Python but I suspect fairly significant chunks of it will need to be implemented in C. A lot of it - drawing circles, manipulating bytes, font management etc - require high levels of performance to be usable. Measure first, of course, but a display driver is certainly performance sensitive.
I agree. I started to write my own SPI TFT driver in python and speed is radially different compared the Lobo low level C driver.

Can the display module be made generic across all ports of uPython?? because a fast capable SPI TFT driver is super useful as a UI for MCUs and certainly would be a value to uPython in general.

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

Display drivers and GUIs

Post by pythoncoder » Tue Apr 09, 2019 5:14 pm

We already have several uasyncio-based GUI type display drivers and a MicroPython optimised way of converting industry standard font files to bitmaps and storing the result as frozen bytecode.

There is a touch GUI for the official Pyboard display here, font storage here and a generic non-touch GUI for displays whose drivers are based on the framebuf module here - these include the Adafruit OLED displays. These are written in Python. Some have been tested on ESP32. I see no reason why the official display shouldn't work with ESP32 - it uses standard interfaces - but I haven't tested this.

A glance at the wiki and a forum search will yield other examples.
Peter Hinch
Index to my micropython libraries.

OutoftheBOTS_
Posts: 847
Joined: Mon Nov 20, 2017 10:18 am

Re: Integrating Loboris port back to official uP ESP32 port

Post by OutoftheBOTS_ » Tue Apr 09, 2019 9:19 pm

Python drivers work at an ok speed providing the SPI screen is very low res but when using larger SPI displays like 320 X 240 it is a huge noticeable speed difference in LoBo display module.

OutoftheBOTS_
Posts: 847
Joined: Mon Nov 20, 2017 10:18 am

Re: Integrating Loboris port back to official uP ESP32 port

Post by OutoftheBOTS_ » Wed Apr 10, 2019 7:12 am

I think in the end Lobo has written a lot of high performance code for uPython that he has made MIT license. He hasn't received any finical gain and a number of commercial operators have used his port for their finical gain e.g. M5Stack. This is a big contribution to the community.

Being MIT license means main line uPython can use his high performance code to improve main line uPython, I am surprised there is such a resistance to use Lobo code.

Turbinenreiter
Posts: 288
Joined: Sun May 04, 2014 8:54 am

Re: Integrating Loboris port back to official uP ESP32 port

Post by Turbinenreiter » Wed Apr 10, 2019 7:34 am

I think it's hard to decide what should go into the "core" and what should not. What is the state of loadable C-modules? I think the display driver would be a good candidate for a loadable C module, while RMT sounds like a hardware capability of the board that could go in the core.

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

Re: Integrating Loboris port back to official uP ESP32 port

Post by mattyt » Wed Apr 10, 2019 8:07 am

I agree, Boris has made a huge contribution!

I'm certainly not resisting using the Lobo codebase - I'm not sure anyone is? - but there are reasons that it hasn't been absorbed upstream. Boris was able to develop rapidly because he was able to focus solely on his ESP32 port - he also didn't have to go through any design reviews. ;) We don't have those luxuries in mainline. It's just a matter of figuring out how best to pull in his changes.

The Display module is different (to the ESP32 features). It's a large, stand-alone module and many (including me) will argue that it shouldn't be in mainline. Hence my hope that it can be built as a native module...

kevinkk525
Posts: 969
Joined: Sat Feb 03, 2018 7:02 pm

Re: Integrating Loboris port back to official uP ESP32 port

Post by kevinkk525 » Wed Apr 10, 2019 10:32 am

I agree, the display module would be perfect for a standalone module with the upcoming c-file support.
Only the device level driver implementations should be added to mainline. Like using the RMT module for all hardware precision timings.
Kevin Köck
Micropython Smarthome Firmware (with Home-Assistant integration): https://github.com/kevinkk525/pysmartnode

User avatar
tuupola
Posts: 54
Joined: Sun Sep 17, 2017 12:10 am
Contact:

Re: Integrating Loboris port back to official uP ESP32 port

Post by tuupola » Sun Apr 14, 2019 6:52 am

FWIW I use Loboris fork for my M5Stack based projects and I love it. However most of the new features, like the display module IMO do not belong to Micropython core. Core should stay lean. They should be able to easily be added to custom build though.

The main reason for me to use Loboris fork was psRAM support. This now seems to be supported by vanilla version too (although only up to 4MB). Features I still would like to see backported into core are: hardware I2C and I2C slave support, RMT, Micropython as esp-idf module support for easy customising.

TL;DR What I would like to see is lean core but an easy way to make customised builds for devices like M5Stack.

Post Reply