Roadmap?

[peterhinch]

It would be good if there were a roadmap for planned developments over the next year or so. The following are topics of interest to me, but others might want to comment with their own areas of interest.

Hardware

Chips are now more widely available. Is there any plan to restart manufacture? In particular:

1. Pyboard 1.1.
2. Pyboard D variants.
3. LCD160CR display.

Asyncio

The following enhancements have been discussed:

1. Non-allocating writes from a memoryview to a StreamWriter. Important for some classes of application.
2. Task groups.
3. Asynchronous generators.

[Tico06]

I think it could be valuable if somewhere contributors (and users?) could suggest orientations for Micropython. And submit to votes to have the community driving some directions.

Would a Github Feature Release project fit with this ?

[scruss]

@peterhinch — I remember a comment from Damien saying that there is a key component of the Pyboard-D series that is discontinued (power controller, maybe?) that is blocking manufacture.

@Tico06 — MicroPython features haven't generally been based on a popularity contest. Monetary support from project sponsors does, though.

[Tico06]

Well, I fully understand the monetary supports, but should be aligned with a roadmap. How to agree/decide on a merge if no plan exists. The Micropython is getting more and more popular and to keep the community engaged, I guess contributors (at least) should advise on future directions. Of course a kind of board management to moderate.

[rkompass]

I have the feeling the following won't be a roadmap, but these might be issues that are worth to be solved in the not far future.

1. A way to allow mpy with compiled C code involve floating point computations would be nice. That way ULAB could be added to the existing binaries without custom recompilation. Think of other libraries with pattern recognition / neural network stuff too.
2. After doing the asm_xtensa instruction exploration I noted that they are quite similar to asm_thumb instructions. And they should/could be adapted for universality. For example: The registers could be rearranged/renamed so that R0 is always first argument / result. Also the RISC instructions of esp32C are similar. It should be possible to unify these assembler emitters to have something like @asm_univ with the common instruction set.
   That would allow to use assembler code in the micropython libs which is at present not possible due to the fragmentation of the different platforms. A first step would be to enable asm_xtensa for esp32 (problem is the usage of the register window iiuc).
   Is asm_x86 usable a the moment?

[peterhinch]

My OP referenced features which had already been the subjects of PR's and so might actually be on a roadmap.

It's hard to plan projects when future developments are unclear.

[Tico06]

Fully aligned with you. I believe GitHub provides the tools to organise a roadmap, but from my point of view a project governance should be defined first at all, if not already existing.

[gretel]

may i jump in to kindly ask for this issue to be considered? this is the sole one issue keeping me from doing actually useful stuff with micropython. regards

[scruss]

are you using an ESP8266? If so, it's unlikely to be fixed, because the only SSL library small enough to fit into its limited memory can't handle some common encryption methods. See SSL/TLS limitations.

If possible, try a board with more RAM

[gretel]

thanks but it should work as documented. if it's not possible to work reliably on some platform it should render an error, not something obscure and hard to debug up to frustrating. my point is about the accessibility of this project, probably even more of a documentation concern.

[scruss]

But it does render an error (if not an understandable one: remember, MicroPython is smol, so there's not much room for hand-holding) and it's documented. It's amazing that the ESP8266 can be used for any network things with the tiny amount of RAM it has.

[gretel]

not asking to work against hardware limitations but i get the idea - assumption is user should be very smart and experienced or go arduino 😄