8000 Discuss and prepare for MicroPython v2.0 release · Issue #2486 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

Discuss and prepare for MicroPython v2.0 release #2486

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.

Sign up for GitHub

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

Jump to bottom
Closed
dpgeorge opened this issue Oct 7, 2016 · 25 comments
Closed

Discuss and prepare for MicroPython v2.0 release #2486

dpgeorge opened this issue Oct 7, 2016 · 25 comments

Comments

@dpgeorge
Copy link
Member
dpgeorge commented Oct 7, 2016 •
edited
Loading

This is a ticket to collect ideas about, and prepare for, v2.0 of MicroPython. It won't be at least until Jan 2017 that this version will be released.

Changing a major version means that we are allowed to "break" compatibility. Although this is not something to aim for it would be a good chance to resolve the following issues (one way or another):

It would also be nice to have Python 3.5 "compatibility" (see #1329) by v2.0.
@dpgeorge dpgeorge mentioned this issue Oct 7, 2016
Closed
@kamikaze
Copy link
Contributor
kamikaze commented

is it going to be released with a new PyBoard version? )

@dmazzella
Copy link
Contributor

Add embeddable MicroPython component? #2122

@hoihu
Copy link
Contributor
hoihu commented Oct 10, 2016

revive #2093 and come to a conclusion (also about the structure within the drivers directory)?

@dpgeorge
Copy link
Member Author

is it going to be released with a new PyBoard version? )

Maybe! There are definitely plans for PYBv2.0.

Add embeddable MicroPython component? #2122

@dmazzella We already merged examples/embedding. What more is needed?

revive #2093 and come to a conclusion

That should be done sooner than 2.0, much sooner. It's next on my list.

@dmazzella
Copy link
Contributor

@dpgeorge Embedding under windows?

@stinos
Copy link
Contributor
stinos commented Oct 11, 2016

But in what form? What will you (or anyone else) use it for? Does it make sense just adding it for the sake of it being there?

I was rather thinking of reusable embeddable components, pretty sure this has been discussed before.
The embedding example is nice in that it shows what's needed but in the end it's just copy-paste-bandwagon work, both in code and in the makefile. Just like I made my embedding using copy-paste most of unix' main. And if anyone else is using embedding, he/she will also be copy-pasting from the current example or from a port's main.c. So yeah that's a lot of copy-pasting, which could be partly avoided by extracting some functions. But it's hard to see which functionality is needed by 'everyone'. Afaik that's how the discussion once ended: not clear in what form embedding is needed so no consensus in what would be really useful to do.

@nickovs
Copy link
Contributor
nickovs commented Oct 13, 2016

Getting TLS support stable and on by default in all ports would be a "good thing". In 2017 nobody should have their Internet connected Things making or receiving connection over the Internet without encryption. If we are going to do this then we should do it properly (i.e. not using the same axtls/ssl/private_key.h on every device!)

@mcauser
Copy link
Contributor
mcauser commented Oct 14, 2016

PYBv2.0 "BB edition" - in a breadboard-friendly format? eg. Feather Huzzah / Maple Mini.

I saw #if MICROPY_PY_BTREE in the code - it seems some of the modules can be toggled on make.
Could all of the modules be toggleable, so we can pick and choose which features to support, to save precious memory? Looking at you NeoPixel, APA102, DHT.

It would also be nice to know how roughly much space they each take up, to help decide which are unnecessary for your minimal custom build.

@mcauser
Copy link
Contributor
mcauser commented Oct 14, 2016

Will the PYBv2.0 have Bluetooth LE, like the micro:bit?
We have WebREPL. What about BtREPL?

It would be nice if REPL and WebREPL could be configured to either use independent buffers.
So I could use a UART device on the ESP8266 port (eg. a GPS), but still control to the board using WebREPL. Or perhaps SoftwareSerial would be more useful?

@peterhinch
Copy link
Contributor

@mcauser Pyboards are breadboard friendly if you fit stackable headers. As for toggling modules off in the build, this will reduce the size of the firmware image in flash. As I understand it, it won't affect RAM usage as a module only uses RAM when imported.

@kamikaze
Copy link
Contributor

@peterhinch are you sure that pyboard is breadboard friendly? as I've tried it's not because of perpendicular rows

@mcauser
Copy link
Contributor
mcauser commented Oct 15, 2016

I was mainly talking about moving the bottom pins to the sides and squishing the board to fit a 400 point breadboard.

Rearranged a pybv1.0 to make it fit a 26 x 7 pin format. The components might not make sense where they are, just wanted to see if it would fit.
pybv20-thin

@peterhinch
Copy link
Contributor

@kamikaze The perpendicular rows can be addressed with socket headers. The point is that you connect to the Pyboard using the socket headers, with the stackable headers being used purely for physical attachment. Arguably a long thin layout is better, but the Pyboard is eminently usable with a breadboard.

@chrismas9
Copy link
Contributor

@dpgeorge

Changing a major version means that we are allowed to "break" compatibility. Although this is not something to aim for it would be a good chance to resolve the following issues (one way or another):
#293 clean up macro names
#704 change mp_ prefix
#2401 move all ports to a subdirectory
It would also be nice to have Python 3.5 "compatibility" (see #1329) by v2.0.

I think v2.0 should herald the maturity of MicroPython and a change of status from "in development" to "stable, being enhanced".

There has been a tremendous amount of development to date and especially after the Network and IOT development for the ESP8266 KS. I think MicroPython id very close to being a mature, stable platform ready to take on the world. Many thanks to Damien, Paul and everyone that has contributed the project.

The one thing I would like to add to your list before v2.0 release is the Hardware API. Pyboard still has pyb and most other ports have machine. Ports using machine miss out on useful things in pyb. A change from pyb to machine later will break a lot of applications, libraries and tutorials.

I think it is time to "break compatibility" and deprecate pyb something like this:

  1. Keep machine for core, pin and bus drivers only, eg Reset, Power, GPIO, SPI.
  2. Migrate missing functionality from pyb into machine, eg Quadrature encoder mode for timer.
  3. Create a periph library for each port that contains the useful higher level drivers that support specific devices, eg LED, SERVO & ACCEL. These functions are very useful because they just work on any port. The user doesn't have to map the on board peripherals to MCU pins. Board tilting, blinking LED type hello world tutorials should run on any platform out of the box.
  4. I will leave it up to the experts as to where things like 1-wire, LCD, etc should go.

MicroPython is expanding. There are already ports underway for ESP32, Microchip/Atmel, NXP/Freescale and Embed. Stabilising the Hardware API will enhance portability between platforms and allow for periph and a wide range of peripheral libraries to run on all platforms on top of the common machine library.

@peterhinch
Copy link
Contributor

By all means deprecate pyb. But please don't remove it until all its functionality has been available elsewhere (and documented) for a substantial period of time. Give us hapless users time to port code.

@chrismas9
Copy link
Contributor

I agree. I have designed pyboard into a commercial product and the company wouldn't want to be forced into a quick changeover, or have to code around missing functions.

@deshipu
Copy link
Contributor
deshipu commented Oct 21, 2016

Should we think about removing the whole drivers directory and putting the drivers in separate repositories where possible (so that they can have their own docs and setup.py file and so on), or incorporating them in extmod where not (because they contain some C code)?

@dpgeorge
Copy link
Member Author

Should we think about removing the whole drivers directory and putting the drivers in separate repositories where possible

Yes that's reasonable. They could even go in micropython-lib.

@pfalcon
Copy link
Contributor
pfalcon commented Oct 21, 2016

I was surprised to recently find a C code in drivers/ . extmod/ was created (quite some time ago) to exactly host code which doesn't fit anywhere else, without looking to create a new dir (and originally drivers/ contained just py code).

@askvictor
Copy link

Implementing a debugger/pdb would be my most wanted item. Embedded development generally lacks a debugger unless you go for an expensive hardware-based debugger, which is out of the reach of most hobbyist and learners. micropython, particularly through the micro:bit and esp platforms, has the potential to re-invigorate computational education (having a 'thing' you can interact with makes it a lot more concrete and interesting), but a debugger makes it a lot more useful for teaching problem solving skills.

@peterhinch
Copy link
Contributor

One merit of Python is that its interactive nature reduces the need for a debugger. It offers debugging techniques unavailable in compiled languages, such as using cut and paste at the REPL to test code fragments or to interact directly with hardware. The REPL can also be used to probe program state after an exception is thrown. A debugger would be nice, but I've yet to encounter a situation where I actually bewailed its absence.

@chrismas9
Copy link
Contributor
chrismas9 commented Oct 25, 2016 •
edited
Loading

+1 lots of times for a debugger, but not for V2.0. It's a big job, lots of questions and choices. I wouldn't want it to delay v2.0.

A debugger would be nice, but I've yet to encounter a situation where I actually bewailed its absence.

When I work with our embedded programmers its usually debugging systems, not code bugs. Finding the once a day, week, month or year malfunctions. They are usually caused by an unusual, unanticipated sequence of events or values, an omission or error in the system (machine) spec, hardware faults, etc. We use JTAG / gdb / eclipse with breakpoints, data watchpoints and backtrace to work out the unusual sequence of events that cause a failure. I have tried to introduce MiroPython to these embedded C / gdb guys but they are not interested in losing their debug capabilities.

Then there are the questions:

  1. Lightweight debugger with breakpoint and single step in VM? Works over serial port with Eric, Pymakr, mu?, etc over serial port. Won't work with frozen (compiled) code.
  2. Can it work OTA like WebREPL?
  3. Arm hardware debug engine / JTAG-SWD / gdb / eclipse beast? Great for low cost frozen (compiled) targets. This would appeal to commercial embedded people. 128k ARM is $1.30 in volume, 384k is $3.50. Having a MicroPython compiler / debugger for a $1.30 target opens up a lot of commercial prospects.

But too big for v2.0. I would like to continue this discussion later.

@stinos
Copy link
Contributor
stinos commented Oct 25, 2016

Similar story here. We found being able to tell uPy to halt upon reaching a certaing function location (we do this manually by inserting a 'debugbreak()' call which makes the attached C debugger halt) is indispensible. I can't imagine this, or something similar like dropping to REPL, wouldn't be useful for others.

@white-gecko white-gecko mentioned this issue Oct 25, 2017
Closed
@dpgeorge dpgeorge mentioned this issue May 29, 2019
Open
17 tasks
@dmazzella
Copy link
Contributor

A state context that's not global is very nice to have. #2122 amalgamate uPy source into a single .c and .h file build option may be useful, but not essential. the status is very useful.

@kdschlosser kdschlosser mentioned this issue Jan 15, 2024
Closed
@jonnor
67E6 Copy link
Contributor
jonnor commented Jul 27, 2024

I believe this issue can be closed in favor of #4821

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
0