Micropython version update

[Jean Bon]

Hello,

Is pycom plan to upggrade micropython version in the pycom port ?

V1.11 is quite old now and V1.11 is not compatible with ulab libray for exemple...

Have a good day,

[Sean O'Rear]

I second this inquiry. Is this on the roadmap?

[rcolistete]

See :
Pycom firmwares with single/double precision and ulab module

Yeah, I need to update the firmwares with ulab (new version).

[Gijs]

For the beta / development firmwares (like 1.20.3.b0 and on) we're looking to update the micropython (and IDF) version.

[Jean Bon]

Hi @rcolistete

Thank you for your link but it's not suitable for my application, ulab and pycom firmware are too old in your repo.

[Jean Bon]

@Gijs

Thank you for your reponse,

Is a page existe somewhere presenting a clear roadmap about the pycom developpement ? maybe with planned release date and content ?

IMHO it's difficult to developpe a product with a pycom board inside if no clear project path is defined by your compagny.

Best regards,

[Basit Mustafa]

Is PyCom still a going concern? Solvent? Any plans to update to even a remotely useful/update-to-date version of MicroPython?

[Basit Mustafa]

@Gijs - to be less dogmatic and more practical, here's my concerns:

1. Lack of attention to the codebase is not inspiring confidence in choosing PyCom as a platform (HW or SW)

2. The lack of attention to keeping even a remotely recent version of PyCom (the most recent beta even is only at 1.13, which was released Sept 02 2020, nearly 10 months ago now). 1.14 brought in Cmake and some new symbols, so things like display drivers which are well-maintained actually don't even build against the fork or only do so with a lot of work (try building the ST7789 driver against the current production firmware, which has an MP version so old that mp_raise_msg_varg and the MP_ERROR_TEXT symbols don't even exist, and even the build process for pre-1.14 MP doesn't work with that driver because even if you use the non-Make path, the symbols needed [which are not new, BTW, they were introduced in 1.12] don't even exist in 1.11, so, sure "beta" is on 1.13, but now, even the "bleeding edge" version of PyCom's fork doesn't even have CMake and holds us back from getting the most out of the MP platform/community. Do you see how this is a problem for developers building on the platform? Isn't MicroPython's value prop speed & agility (partially)? If I'm spending time having my team hack through build incompatibilities, is that really providing any more value than just picking Zephyr, FreeRTOS, or whatever other platform where we aren't left wondering what is and isn't supported and if the company leading the platform is even solvent anymore?

3. MP is at 1.16 - and has been for a month now, which isn't too long in microcontroller lifecycles, but PyCom's "bleeding edge" is still at 1.13 - do you see how crazy that is?

4. Is mesh ever going to be a thing or has PyCom abandoned that? It was in development in 2018, should we stop holding our breaths and just throw nrf52s into our designs and use Thread?

Yes, we could all just do this ourselves, maintain our own fork, etc, but isn't the whole value prop of buying into the PyCom platform that we'll not have to and we can focus on shipping & building product?

Can you provide us with a statement on the status of the company and its dedication (or not) to keeping its fork of MP viable?

[Gijs]

Hi,
Pycom is still very much going on, now collaborating with Murata and 1nce as well.

To answer your questions / concerns:

1. Not sure what you mean here. We have several developers working on the firmware codebase every day. Let me know if you can elaborate here
2. We try to keep our firmware up to date with the micropython firmware as well, though in the past we made it harder for ourselves to merge a later version of micropython into our repository. In the new beta / alpha firmwares, we're working on improving that. Next to that, we're working on updating to the next esp-idf version (4.1 / 4.2) as well.
3. I understand your concern here
4. Again, I understand your concern. It is hard for us to keep active on all fronts, while developing new products as well and we're lacking a bit of manpower to bring PyMesh to the next level, but I feel like the project is not abandoned yet, and still operational.

You're correct in your last remarks. While we continue to actively maintain our branch of Micropython, we should step up with the latest version of Micropython and keep that more up to date.

Let me know if that answers your concerns!

Gijs

[jcaron]

@Gijs I think it's a concern of many users that Pycom is spreading resources thin by working on too many new products which never see the light of day while not following up enough on the existing products.

Let's just consider this list of Pycom vapourware:

• PyGo 1/2 + PyLife : first announced 25/09/2018 (soon to be 3 years ago).
• PyNode range: announced 25/06/2020
• PyNode Touch: announced 06/07/2020
• Expansion board V4: announced 14/10/2020
• M.2 format boards: announced 17/11/2020
• ESP32-S3-based boards: announced 01/02/2021
• PyNode+ range: announced 08/02/2021

I know time-to-market can be essential in this industry but this is getting a bit out of hand...