-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Comments
Fix all open uasyncio issues and add all Cpyhon primitives (which @peterhinch already programed)? |
Provide a means of reducing I/O latency in |
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. |
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. |
@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? |
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>
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>
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... |
esp32: interface to the WIFI power save functions of ESP-IDF#6774 |
F-Strings, please! They are so much nicer, faster and becoming the standard... |
is there any plans for CAN bus support for the esp32? |
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. 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 ? |
port-rp2 So long and Thanks for all the fish! |
Documentation for the rp2 port would be good to have for v1.15, see #6855. |
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. |
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. |
ping @aivarannamaa so he can update the UF2 used by Thonny. |
@lurch, thanks! Updated now. |
Hi @dpgeorge, How can add a new board in the port |
@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. |
@Krasn4ck , I found your fork. There are two problems. If I change
|
You don't need to add |
@Krasn4ck & @chrismas9 I wonder if your discussion ought to be split off into a separate issue? 🙂 |
Yes, I'm sorry @lurch 😄 and at enveryone . |
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>
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>
just asking but why is this still open? Arent we in 1.16. already? |
@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" ? |
In that case: Please implement extended slicing - it is still missing, even in 1.16:
When porting code from any other Python platform this is always a stumbling block... |
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 |
I just checked: That is true - Lists, Tuples and Ranges support extended slicing, Strings don't. |
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. |
For sure this can be closed now @dpgeorge ? |
Three plus years on, the best place to track next release progress is probably GitHub Milestones: |
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:
The text was updated successfully, but these errors were encountered: