I would like the ESP32 version of MicroPython to allow selection of PWM channels, because currently I cannot have two PWM pins use different frequencies.

Is that so? The documentation for ESP32 is extremely skimpy, do all pins use the same frequency?

Yes indeed. That's how I found this repo in the first place, it's AFAIK the only uPython implementation where PWM frequency can be changed per-pin.

For convenience I've put up a repository that just has a README in which we can capture things people think are important. I'll add PWM to the list, thanks!

Yes, PWM on mainline MicroPython for the ESP32 currently only uses one channel - so only one base frequency. However Loboris' API for PWM is different from the other MicroPython ports; not ideal.

The main reason I haven't addressed this in MicroPython (apart from lack of time!) is that the PWM API is under discussion and may well change to be more flexible across ports. See #4237.

If we were to extend the current API to support multiple channels I would want to do it transparently; with each creation of a PWM object a new channel would be allocated. Then, if further control is required (to share channels or allocate them manually), we would provide extension methods in the esp32 module to allow more fine-grained control.

Doing it that way sounds like a great idea, but I am concerned. Things may be done in the future that are better than what we see in this repository, and the matter is already under discussion. And there is not really enough time to do it.

I hope this is not the way things will go.

I would like the ESP32 version of MicroPython to allow selection of PWM channels, because currently I cannot have two PWM pins use different frequencies.

Is this true!? @zrecore Maybe that's why my RGB driver didn't work.

This needs fixing. This needs testing.

mDNS, threading extentions (https://github.com/loboris/MicroPython_ESP32_psRAM_LoBo/blob/fede6f610c9952c7242fc309c2bb4efc9afb0919/MicroPython_BUILD/components/micropython/py/modthread.c) and the ability to create the custom file image would be great to have!
@carterw What's your schedule? Will you create a new fork? Can anyone help you?

I love the build system which allows you to do a $ make menuconfig to add or remove features to Micropython build.

I like the build system too, very convenient. I'm having discussions with some MicroPython contributors on Slack. They seem open to the idea of either bringing in or re-implementing some features of the loboris fork, but a sticking point seems to be agreement upon uniform class signatures for things like PWM, ADC, etc. They realize that the various hardware platforms have different features that developers will want to access, but not clear on the best way to expose the features while retaining some conformity.

Also, apparently there is a 'version 2' of MicroPython under way so that complicates matters.

+1 for make menuconfig

I always build my linux kernel, and this is the really killer feature for using Lobo fork.

make menuconfig += make menuconfig # for me too!

The very fast SPI TFT class loboris implemented would be a very nice addition to Micropython. That and the discrete PWM channels brought me here in the first place.
Also +1 for the menuconfig and network services.

For me the most useful feature is "make menuconfig" allowing configuring ESP-IDF features easily.

The SPIFFS based filesystem is really nice too as it's really quite a bit better than FAT.

@carterw any updates from the main micropython devs on bringing the loboris enhancements to the main branch?

Best bet is to check out the open issues on MicroPython. Though there are a lot of them. We welcome improvements in the spirit of MicroPython.

The biggest issue is that this port is ESP32 centric and we don't have that luxury in main line. There is improved spiffs/spiflash functionality coming and a few other improvements that are similar to this port.

If you want something in particular from this port in mainline. Raise an issue and we will see what we can do

Some progress is being made (though perhaps never as fast as we'd like!): _thread (video) has been in since 1.10, littlefs support has just been merged, there's an open PWM PR (which has stalled somewhat - anyone want to inject some life into it?), and I've got an open RMT PR that I'm hoping to sneak in before the next release to at least provide basic transmit functionality.

As for the build system, I'd strongly suggest we wait until IDF4 has stabilised before making any changes. Espressif are changing their build system (moving to CMake) and it's been a little disruptive.

I've had a number of good discussions with some of the contributors to main line on Slack. In general I see a willingness to consider bringing over features and some appears to have taken place. One obstacle is that Damien George (the benevolent dictator for life of Micropython) does not participate in the discussions and he has his own agenda.

There are some differences in philosophy, and some of this derives from the fact that Micropython supports multiple hardware platforms whereas the Loboris port is ESP32-specific. Some people want to see a homogeneous API across all platforms. This is at odds with the effort here which seems have been aimed at providing access to as many ESP32 features as practicable. I use some of those features in my projects and I suspect other people do too, otherwise they would just stick with mainstream. I am advocating having some coding convention for reaching hardware-specific features of things like ADC and PWM that aren't present on other hardware. No resolution on it yet, but then I am just one voice there and not easy to influence the consensus.

Also there have been some 'who cares' questions; why do people want to build their own custom firmware, most people just use the generic binaries we provide online. And then there is CircuitPython from Adafruit which is tailored for the casual tinkerer. So lots of different viewpoints, slow going.

There are some differences in philosophy, and some of this derives from the fact that Micropython supports multiple hardware platforms whereas the Loboris port is ESP32-specific. Some people want to see a homogeneous API across all platforms. This is at odds with the effort here which seems have been aimed at providing access to as many ESP32 features as practicable. I use some of those features in my projects and I suspect other people do too, otherwise they would just stick with mainstream. I am advocating having some coding convention for reaching hardware-specific features of things like ADC and PWM that aren't present on other hardware. No resolution on it yet, but then I am just one voice there and not easy to influence the consensus.

I didn't see a problem here: Any features that are ESP32-specific can land in esp32 module, isn't it?

Is anybody working to backport missing features to mainline micropython?

I still use this port for anything with Neopixels. The RMT usage is an issue - perhaps. But on the other hand: The HSB/HSL routines, addressing of the pixels - it works great and I see the standard uP implementation as too simple.
Many coders don’t like the pixels - but as a matter of fact: Other creative people really like using them (all types) in pieces of art.

I still use this port for anything with Neopixels. The RMT usage is an issue - perhaps. But on the other hand: The HSB/HSL routines, addressing of the pixels - it works great and I see the standard uP implementation as too simple.
Many coders don’t like the pixels - but as a matter of fact: Other creative people really like using them (all types) in pieces of art.

At some point I was even thinking of using three-dimensional lighting control. Color/light is three dimensional, per definition by Johannes Itten, and it should be accessible in this way. Hence the routines in this port are valuable, I wonder what master Boris was up to, what made him make such „a fuss“ of the Neopixels..

Is anybody working to backport missing features to mainline micropython?

I recently saw one of the contributors mention on Slack that he is trying to work up a PR that would at least have a working example of how to implement platform-specific features.

I found damien's statement about merging code here: micropython/micropython#4942 (comment)

So in the end it must be re-implemented :(

I also start a form thread here: https://forum.micropython.org/viewtopic.php?f=18&t=7603

Can't use code from this repository because it might have been "influenced by GPL code"? You could say that about any code anywhere. Sad to see this.

I've commented on the MicroPython forum thread that @jedie started.

In short, I'm not convinced that the GPL concern is still valid (though it really was a problem). But it probably doesn't matter unless people are going to actually port the features. Further, port them without rewriting. In my opinion many of the features need significant work.

I still use this port for anything with Neopixels. The RMT usage is an issue - perhaps. But on the other hand: The HSB/HSL routines, addressing of the pixels - it works great and I see the standard uP implementation as too simple.
Many coders don’t like the pixels - but as a matter of fact: Other creative people really like using them (all types) in pieces of art.

At some point I was even thinking of using three-dimensional lighting control. Color/light is three dimensional, per definition by Johannes Itten, and it should be accessible in this way. Hence the routines in this port are valuable, I wonder what master Boris was up to, what made him make such „a fuss“ of the Neopixels..

Dear all, I know this is off-topic. But there may be others like me, that use the Neopixel implementation of this fork. I have found an alternative - it's Arduino-IDE-based for ESP8266/07/12 and the ESP32, there are apps available for remote control via wifi - this is what I was working on, but thanks to the work of someone else I can concentrate on the part I'm good at:
https://github.com/Aircoookie/WLED

Thank you very much to everyone working on this - it's your free time, and I know there isn't that much "gain" coming out of it. Thank you very, very much.

Seeing as how this fork now appears to be dormant it would be nice to preserve whatever the users here are finding most valuable. Also getting bug fixes and more enhancements into the code would

the most valuable for me is PWM module with splitted timers. The hardware PWM of ESP32 - is the main reason for me to prefer for ESP32 than more cheapy ESP8266.

Hello,
EVE display driver would be amazing!!