8000 Roadmap to next release v1.15 · Issue #6832 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content

Roadmap to next release v1.15 #6832

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dpgeorge opened this issue Feb 2, 2021 · 33 comments
Closed

Roadmap to next release v1.15 #6832

dpgeorge opened this issue Feb 2, 2021 · 33 comments

Comments

@dpgeorge
Copy link
Member
dpgeorge commented Feb 2, 2021

This ticket is to discuss the work to do up to the next release, tentatively v1.15. See previous discussion for v1.14 at #6397 .

A two-month release cycle puts the next release in the first week of April 2021.

Current plan:

  • make esp32 port use cmake natively
@dpgeorge dpgeorge pinned this issue Feb 2, 2021
@kevinkk525
Copy link
Contributor

Fix all open uasyncio issues and add all Cpyhon primitives (which @peterhinch already programed)?

@peterhinch
Copy link
Contributor

Provide a means of reducing I/O latency in uasyncio.

@DWiskow
Copy link
DWiskow commented Feb 3, 2021

Incorporate machine.RTC for Raspberry Pi Pico - mechanism for setting RD2040 RTC is detailed in #6833 and has already been implemented as a work around in rshell . . . there is / is likely to be a big audience for uPython on the Pico and this is important but missing functionality.

@MaureenHelm
Copy link
Contributor
  • make esp32 port use cmake natively

The Zephyr port should be ready to go with native cmake too. It's been stalled waiting for the Zephyr v2.5.0 release, due on 12 Feb.

@UnexpectedMaker
Copy link
Contributor
UnexpectedMaker commented Feb 3, 2021

@dpgeorge Can we please look at getting the PWM module re-work across all of the ports you've been taking about done so we can look at finally implementing the seperate PWM timers in the ESP32 port in v1.15?

Also, was there any further progress with the discussion on adding f-strings?

@lurch
Copy link
Contributor
lurch commented Feb 7, 2021

RD2040 RTC is detailed in #6833

RP2040 😉 And I suspect you meant to link to #6831 ?
(feel free to delete this comment after @DWiskow 's comment has been fixed)

kadamski added a commit to kadamski/micropython that referenced this issue Feb 18, 2021
Initial support for machine.RTC on rp2 port. It only supports datetime()
method and nothing else. The method gets/returns a tuple of 8 items,
just like esp32 port, for example, but the usec parameter is ignored as
the RP2 RTC only works up to seconds precision.

The Pico RTC isn't very useful as the time is lost during reset and
there seems to be no way to easily power up just the RTC clock with a
low current voltage, but still there seems to be use-cases for that, see
issues micropython#6831, and a thonny issue micropython#1592. It was also requested for
inclusion on v1.15 roadmap on micropython#6832.

Signed-off-by: Krzysztof Adamski <k@japko.eu>
kadamski added a commit to kadamski/micropython that referenced this issue Feb 19, 2021
Initial support for machine.RTC on rp2 port. It only supports datetime()
method and nothing else. The method gets/returns a tuple of 8 items,
just like esp32 port, for example, but the usec parameter is ignored as
the RP2 RTC only works up to seconds precision.

The Pico RTC isn't very useful as the time is lost during reset and
there seems to be no way to easily power up just the RTC clock with a
low current voltage, but still there seems to be use-cases for that, see
issues micropython#6831, and a thonny issue micropython#1592. It was also requested for
inclusion on v1.15 roadmap on micropython#6832.

Signed-off-by: Krzysztof Adamski <k@japko.eu>
@mattytrentini
Copy link
Contributor

It would be helpful to merge mpr (#6375) since it's an awfully useful tool that dramatically improves the development workflow. Though it may need a little more attention under Windows...

@maro48m
Copy link
maro48m commented Mar 3, 2021

esp32: interface to the WIFI power save functions of ESP-IDF#6774

@GHPS
Copy link
GHPS commented Mar 6, 2021

Also, was there any further progress with the discussion on adding f-strings?

F-Strings, please! They are so much nicer, faster and becoming the standard...

@samiul-hoque
Copy link

is there any plans for CAN bus support for the esp32?

@pidou46
Copy link
pidou46 commented Apr 7, 2021

Full ESP32 features support: pcnt, rmt receive, esp_now, mesh, OTA.

It is in v1.11 -> v2.0 roadmap, but I would like to see it in V1.15 rather than V2.0 thought.

C libraries are available, but it has been stated that they should not be included in main firmware, instead a way to load them dynamically would be used.
I understand this point of view, but despite the good willing of contributors, the PRs (#5682, #5653, #5711, #6767) to implement this mechanism. They haven't received much interest from maintainers. Consequently, the features still not available.

There is no much features to add, and RMT is already half included. Should it be reconsidered to add them in firmware ? maybe as an optional build like spiram version ?

@kevindawson
Copy link

port-rp2
missing documentation - https://docs.micropython.org/en/latest/library/rp2.html
#7093, #6933, #6938
eg. enough extra info to enable the user to do: The idea is that for the 4 sets of pins ( in , out , set , sideset , excluding jmp ) that can be connected to a state machine, there’s the following that need configuring for each set: #7117
nb. StateMachine frequency #7025 #7033

So long and Thanks for all the fish!

@aallan
Copy link
aallan commented Apr 14, 2021

Documentation for the rp2 port would be good to have for v1.15, see #6855.

@dpgeorge
Copy link
Member Author

v1.15 was tagged in 321d189!

Development time over the past couple of months was unfortunately dominated by #7110 and #7111. And since my main aim was to get a release done in early April (almost made it...) there was not enough time to address all the good suggestions above. At least the original item -- esp32 using cmake -- was completed!


Thank you everyone for the above suggestions and thumbs-up/hearts on the suggestions. That is very helpful to know what to concentrate on for the next release. I agree with everything suggested, it's just a matter of priority.

@aallan
Copy link
aallan commented Apr 19, 2021

v1.15 was tagged in 321d189!

Since https://micropython.org/download/rp2-pico/rp2-pico-latest.uf2 now points to v1.15 I'll update link on the RP2040 Getting Started pages to point to that now rather than the unstable nightly we'd been pointing at before.

@lurch
Copy link
Contributor
lurch commented Apr 19, 2021

ping @aivarannamaa so he can update the UF2 used by Thonny.

@aivarannamaa
Copy link

@lurch, thanks! Updated now.

@Krasn4ck
Copy link

Hi @dpgeorge, How can add a new board in the port stm32 for the next release?
What're the requirements?

@chrismas9
Copy link
Contributor

@Krasn4ck , which board do you want to add? Is the MCU already supported?

@Krasn4ck
Copy link

@Krasn4ck , which board do you want to add? Is the MCU already supported?

@chrismas9 the board call OPHYRA and is based STM32F407 the files of board I have in my fork of micropython.

PD. Only have a problems with stm32f4xx_hal_conf_base.h because this board not use some libs, but rest is OK.

@chrismas9
Copy link
Contributor

@Krasn4ck , I found your fork. There are two problems. If I change mpconfigboard.mk to use stm32f405.ld and stm32f405_af.csv (same as OLIMEX_E407) it compiles. Problems are:

  1. There are quite a few differences between stm32f405_af.csv and your stm32f407_af.csv . I have not analysed them all but there are extra AFs that don't exist (eg I2S2_WS on PB6), extra S in some clocks, etc. One of the differences is causing compile to fail. You can use stm32f405_af.csv unless you want Ethernet. If so stm32f407_af.csv should be identical to stm32f405_af.csv except for the Ethernet functions.
  2. In stm32f407.ld you hard coded _heap_end = 0x2001c000; /* tunable */. The heap is overlapping the stack because the stack does not start at 128K. There is estack_reserve above the stack. You should restore _heap_end = _sstack;. The way the linker script works is that you tune the stack size and the heap is automatically allocated all spare memory.

@chrismas9
Copy link
Contributor

You don't need to add stm32f407.ld as it is identical to stm32f405.ld . Normally a new linker script is only added if it is different to an existing one, either because the MCU archirtecture is different, or you want a different memory layout.

@lurch
Copy link
Contributor
lurch commented Apr 27, 2021

@Krasn4ck & @chrismas9 I wonder if your discussion ought to be split off into a separate issue? 🙂

@Krasn4ck
Copy link

@Krasn4ck & @chrismas9 I wonder if your discussion ought to be split off into a separate issue? 🙂

Yes, I'm sorry @lurch 😄 and at enveryone .

kadamski added a commit to kadamski/micropython that referenced this issue May 23, 2021
Initial support for machine.RTC on rp2 port. It only supports datetime()
method and nothing else. The method gets/returns a tuple of 8 items,
just like esp32 port, for example, but the usec parameter is ignored as
the RP2 RTC only works up to seconds precision.

The Pico RTC isn't very useful as the time is lost during reset and
there seems to be no way to easily power up just the RTC clock with a
low current voltage, but still there seems to be use-cases for that, see
issues micropython#6831, and a thonny issue micropython#1592. It was also requested for
inclusion on v1.15 roadmap on micropython#6832.

Signed-off-by: Krzysztof Adamski <k@japko.eu>
dpgeorge pushed a commit that referenced this issue Jun 12, 2021
Initial support for machine.RTC on rp2 port. It only supports datetime()
method and nothing else. The method gets/returns a tuple of 8 items, just
like esp32 port, for example, but the usec parameter is ignored as the RP2
RTC only works up to seconds precision.

The Pico RTC isn't very useful as the time is lost during reset and there
seems to be no way to easily power up just the RTC clock with a low current
voltage, but still there seems to be use-cases for that, see issues #6831,
and a Thonny issue #1592. It was also requested for inclusion on v1.15
roadmap on #6832.

Signed-off-by: Krzysztof Adamski <k@japko.eu>
@veni-vidi-code
Copy link

just asking but why is this still open? Arent we in 1.16. already?

@lurch
Copy link
Contributor
lurch commented Jul 1, 2021

@veni-vidi-code I think that not everything in this discussion got implemented yet, so I guess it's now more of a "general wishlist" ?

@GHPS
Copy link
GHPS commented Jul 2, 2021

I guess it's now more of a "general wishlist" ?

In that case: Please implement extended slicing - it is still missing, even in 1.16:

MicroPython v1.16 on 2021-06-18; ESP module with ESP8266
Type "help()" for more information.
>>> a='dlroW olleH'
>>> a[::-1]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NotImplementedError: only slices with step=1 (aka None) are supported

When porting code from any other Python platform this is always a stumbling block...

@lurch
Copy link
Contributor
lurch commented Jul 2, 2021

NotImplementedError: only slices with step=1 (aka None) are supported

Curious. https://github.com/micropython/micropython/blob/master/tests/basics/list_slice_3arg.py suggests that it works for lists, but https://github.com/micropython/micropython/blob/master/tests/basics/string_slice.py implies that maybe it doesn't work for strings?

I did a bit of searching and found #59 (which is a bit old), which says "Only 2-argument (start, stop) is supported" 🤷

EDIT: Ah, 5fd5af9

@GHPS
Copy link
GHPS commented Jul 3, 2021

suggests that it works for lists, but implies that maybe it doesn't work for strings?

I just checked: That is true - Lists, Tuples and Ranges support extended slicing, Strings don't.

@UnexpectedMaker
Copy link
Contributor

I think it's past time to close this @dpgeorge - maybe open a new 1.18 one?

@AltoRetrato
Copy link

I think it's past time to close this @dpgeorge - maybe open a new 1.18 one?

1.16, 1.17 and 1.18 are already in the rearview mirror.

@dpgeorge dpgeorge unpinned this issue Feb 2, 2022
@jonnor
Copy link
Contributor
jonnor commented Jul 3, 2024

For sure this can be closed now @dpgeorge ?

@projectgus
Copy link
Contributor

Three plus years on, the best place to track next release progress is probably GitHub Milestones:
https://github.com/micropython/micropython/milestones

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0