MicroPython Forum (Archive)

Apart from die hard micropython pyboard fans, most hobbyists would operate on a lower cost budget.
Pyboard D, in comparison is very expensive. There are many more advanced hardware SOC modules with Linux and full version of Python at much lower cost than pyboard D, but they don't run micropython on bare metal. Again, looks like pyboard D is aimed at micropython fans.

Don't forget that ESP32 is also more versatile if you don't want to use micropython firmware. C with native RTOS, Arduino C++, etc.

https://www.aliexpress.com/wholesale?ca ... evelopment

The esp32 is a reasonable board for dealing a little bit with external sensors, displays and doing WiFi/Bluetooth communication. And at the prices called fro them you can buy two or three to get one which works reliably. It fails badly at everything needing e.g. precision timing, fast ISR, good ADC/DAC, properly designed GPIO, .... So it's up to the use case which board to go for. Yes, the Pyboard is expensive compared price tags for cheap Chinese products, but that's the calculation of the vendor, taking into account the different development and production costs between China and Europe/Australia.
There are other boards with an STM32 you can use, like the ones form STM, which are sold for a low price. So you have a choice.

I also bet that the Pyboard D will be available from china in the future for half the price. Same happend with the original Pyboard. But -of course- the hardware quality will be on chinese level and they will use cheaper parts. Mostly not so effective LDOs.

So after this little "side-talk" about prices and justification for the esp32 it would be nice to get back to the goal of this thread.
I hope everyone now understands that the ESP32 has its place among micropython devices and can't just be replaced by the pyboard D (unless there will be a variant that only costs ~15€ )

But of course there won't be many developers that will implement esp32 specific features because the focus lays on the pyboard D.

Therefore features like hardware i2c are nice but not that important.

The Pyboards are expensive because they finance Damiens work. The price difference of an ESP32 and a Paboard D comes from the money the devloper needs to make sure the firmware supports all hardware features. The ESP32 is not an interesting target for anyone to support, because there is no money to be made from hardware sales.

Generally, there are a couple of ways to get a good MicroPython port for a target:
Community - Just like Mike Teachman described, the work has to be done by volunteers, with a community manager channelling all the power in the right direction.
Company - GeorgeRobotics sells Pyboards to support development of the core and the stm32 port, Adafruit sells boards to support the ATSAMDx1 ports, ...
Pay for development - Similar to the Kickstarter for the ESP8266 port, you can try to finance development directly - your company could hire a developer to work on MicroPython, you could hire a Freelancer, you could run a Kickstarter.
Foundation - Establishing a foundation and finding sponsor for it could be a viable way to raise money for MicroPython.

The company approach, where hardware sales pay for development is probably not achievable for the ESP32 - there is too many cheap alternatives.

I think we all understand that but not everyone can afford to support the good work Damien does by buying those expensive pyboard D boards. Many are hobbyists and doing small projects. And here the esp32 is mostly perfect.

If you are buying boards for a company or a commercial product, I'd always try to use the pyboard D of course.

The changes asked for in this thread are obviously not in the general interest of micropython development as they are specific to the esp32 hardware (or maybe esp-idf, hopefully) therefore the need for volunteers.
I would however appreciate it, if people don't come to this thread to discredit the esp32 platform and any efforts to improve it. It's a valid platform with lots of users and support. We are just looking for possibilities and volunteers to implement features, that have already been developed, just on a different fork. Some changes might be easy to port, others might be very difficult and will be dropped.

Sorry, I didn't mean to discredit the ESP32 or the community around it. Just wanted to point out the situation, the problems, the options.

You are doing the right thing - building up the community to support the ESP32 target!

Great to see so many responses to my humble question. Please - let‘s stick to the ESP32 here, going off-topic just doesn‘t help anyone.
Of course there are alternatives, and they are plentiful. Yes, HW sales support Damien and that‘s they way it should be.
Having uP ports for multiple MCU families with (as far as feasible) equal functionalities in the uP environment makes uP popular!
There are alternatives and they aren’t even that bad. Hence the work for the cheap ESP family also pays off in the long run by enlarging the community.

I‘m happy with not implementing everything on the uP level and keeping more in C(++) modules.

It is correct that it needs proper coordination and volunteers. But before that it needs a good old „URS“.
Well, I‘ll start the wish list:

- Display
- Multithreading
- Neopixel
- RMT seperated from Neopixel

I also vote for display.
I've been using several ESP32 boards with ILI9341 display with Loboris's port for my random projects and they work really great except for the multithread+gc bug.

I want to try pyboard D (or maybe pyboard 1.1) if they support large displays as well.
it's going be even nicer if display rendering somehow works with uasyncio.

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.