Micropython support

[askvictor]

Add support for Micropython for compatible boards (e.g. esp8266 family)

• Digi Xbee3 Board Support https://github.com/platformio/platformio-core/issues/2863
• Raspberry Pi (https://github.com/platformio/platformio-core/issues/3937)

[TravisJoe]

I would also like to see this.

For any boards that you can connect and get a REPL, one of the key Micropython developers built a tool that is useful and could be used as part of the interface or as a example on how to integrate Micropython into PlatformIO https://github.com/dhylands/rshell

I am also using the Pycom modules which has a fork of Micropthon. These boards include wifi, bluetooth 4.0, and soon cellular. All their newer boards are based on the ESP32 modules.

[gjlawran]

There is also an Atom package called pymakr that can provide access to both Serial and Web - REPL. It is supposed to syncronize (upload/download) files too - but this feature does not appear to be working in the latest release

[gjlawran]

Another useful source to consider in building Micropython suppport into https://github.com/nickzoic/mpy-utils

[idesignstuff]

As I have been moving more toward Python lately, I miss the integration that Platformio/Atom had achieved. Is there anyone out there working on integrating micropython tools into Platformio?

[TravisJoe]

Probably the most universal and straightforward way of doing this is by integrating, or doing something similar to rshell. This relies on the REPL which is a pretty universal method on connecting to Micropython devices. https://github.com/dhylands/rshell

Pycom does something similar with their Atom plugin, but they are focused solely on their products, so even if other devices work, they are not truly supported. https://atom.io/packages/pymakr

[ShakataGaNai]

I do a bunch of Micropython on Wemos D1 units (ESP8266) so I really love the idea of support for this. Since it hasn't been linked elsewhere in the thread: MP ESP8266 Docs & Firmware Download

[ivankravets]

Some feature requests: https://www.reddit.com/r/arduino/comments/9bk3mk/massive_release_of_platformio_ide_for_vscode/e53vu14/

[Niko-La]

Is there a timeline for micropython on platformio?

[TravisJoe]

Based on how I have used Micropython and VScode what would cover most use cases is

• Sync to mounted drive (like rsync)
• Sync using serial (like rshell)
• Sync using ftp? (like webREPL)

Then being able to open open a reply using one of the methods as well.

For now I write a small script that uses rsync and a file to list what needs to be copied over. I use the standard pyboard based implementations (USB) most of the time so it is mounted as a VCP and a mountable drive through the same connection. I have a pretty quick edit and deploy processes now.

Uploading lower level firmware is so uncommon for me that I don't think that needs to be initially supported.

[Niko-La]

@TravisJoe rshell be used to get the devices repl from remote network over the internet? I would like debug my micropython script using something like that.

[TravisJoe]

@Niko-La rshell is designed for serial or virtual com port interactions with a micropython device. For connecting over a network you will want something more like this https://github.com/micropython/webrepl

I think Adafuits tool also can do over network https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy

[Tylersuard]

Micropython plz. I like Atom.

[Niko-La]

+1

[SantiPerti]

Platform.io + Micropython. Pretty please!!

[anderl80]

+1

[DjianR]

+1

[ysazak]

+1

[pingf]

+1 for vscode

[iBobik]

Hey folks, could you please stop writing comments "+1"? Here are "likes" emoji for that. Comment will send notification to all subscribed users.

Jan Pobořil https://honza.poboril.cz/

17. 7. 2019 v 4:06, Makefile君 [email protected]:

+1 for vscode

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ivankravets]

Hi all,

Could you explain about classic workflow how you do programming using Mycropython? To be honest, I don't understand what should be done from our side.

I would be thankful if you explain what you expect from PlatformIO.

Thanks!

[cselti]

Dear Ivan! My opinion, that the micropython (mp) support doesn't differ from the other supported ~~platform~~ framework . The plaformio downloads the mp's code, builds it with the mp's tool, flashes the firmware and upload the app specific code. The mp has a package handling tool called upip (after the Python pip). The plarformio IDE should support the mp REPL - it can be usable on the connected microcontroller flashed with mp. I think the debugging could be solved with mp also - but I haven't used the debugging yet, because the REPL very usable tool for testing codes directly on the microcontroller. I'm only little experienced with mp, but the micropython developers can provide more detailed information and maybe can help in the implementation. The mp forum (https://forum.micropython.org/) and/or github repo (https://github.com/micropython/micropython) could be easiest way to contact with the mp gurus.

I hope I can help. Regards, Adrian

[iBobik]

I understand MP is too different to support it in Platformio easilly.

My current workflow is to have Makefile for compiling all possible code as frozen modules (compiled and included in firmware) and after flashing copy custom main.py and config to filesystem.

MICROPYTHON_VERSION=v2.11.0.2
FLASHING_PORT=cu.usbserial

run-docker:
    docker run -it --rm -v ${PWD}:/app registry.gitlab.com/janpoboril/micropython-docker-build/pycopy/esp8266:$(MICROPYTHON_VERSION) make build-firmware

build-firmware:
    cp -R lib/* src/modules/* /micropython/ports/esp8266/modules
    cd /micropython/ports/esp8266 && make
    mv /micropython/ports/esp8266/build/firmware-combined.bin /app

install: firmware-combined.bin
    esptool.py -p /dev/$(FLASHING_PORT) erase_flash
    esptool.py -p /dev/$(FLASHING_PORT) -b 115200 write_flash 0 firmware-combined.bin
    mpfshell -o $(FLASHING_PORT) -c lcd src; put main.py; put config.py; put networks.json; put webrepl_cfg.py

30. 8. 2019 v 10:27, cselti [email protected]:

Dear Ivan! My opinion, that the micropython (mp) support doesn't differ from the other supported platform. The plaformio downloads the mp's code, builds it with the mp's tool, flashes the firmware and upload the app specific code. The mp has a package handling tool called upip (after the Python pip). The plarformio IDE should support the mp REPL - it can be usable on the connected microcontroller flashed with mp. I think the debugging could be solved with mp also - but I haven't used the debugging yet, because the REPL very usable tool for testing codes directly on the microcontroller. I'm only little experienced with mp, but the micropython developers can provide more detailed information and maybe can help in the implementation. The mp forum (https://forum.micropython.org/ https://forum.micropython.org/) and/or github repo (https://github.com/micropython/micropython https://github.com/micropython/micropython) could be easiest way to contact with the mp gurus.

I hope I can help. Regards, Adrian

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/platformio/platformio-core/issues/728?email_source=notifications&email_token=AAEV6WAITAPAMNFC5YSWHQTQHDKVXA5CNFSM4CKSOZU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5Q6V7A#issuecomment-526510844, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEV6WGSTKBW3UPPP3C4EIDQHDKVXANCNFSM4CKSOZUQ.

[cselti]

@iBobik - As far as I know, the platformio works the following in an application project (RTOS, Arduino)

1. downloads the platform (FreeRTOS, Arduino) core and compilers, tools etc
2. downloads the board specific (Atmel, Arm cortex-M, ESP, ..) compiler, tools
3. builds the the app project with 1+2 compilers
4. and flash the board with created binary
5. connects the boards to UART interface and shows the output of the running app

In case of micropython (because python's dynamic nature) the 3 usually necessary once and upload (which is simplified flashing) only the app specific micropython files. Except when the project has native code, that is interfaced to micropython, the 3. steps should repeat in every new project build+upload.

My point of view, that the difference is maybe between in your project's workflow and the platformio worklow - but I think your workflow can be divided to the 1,2,3,4 steps also too.

And in case of micropython (because the Python's REPL) the platformio IDE should support to connect the REPL through UART separately.

But the Pycom (creates ESP32 boards with micropython support) created an VS Code based IDE - the Pymakr (https://github.com/pycom/pymakr-vsc/). The Pymakr supports their boards only, it's doesn't works different ESP32 board, but it can be useful example how it's upload the applications files and connects the REPL on UART.

[Tylersuard]

Hi all,

Could you explain about classic workflow how you do programming using Mycropython? To be honest, I don't understand what should be done from our side.

I would be thankful if you explain what you expect from PlatformIO.

Thanks!

Hello @ivankravets , I think what everyone is looking for is similar functionality to uPyCraft IDE. Flashing, uploading, REPL, running software, etc.

[TravisJoe]

I use Micropython almost exclusively for commercial projects. Because of how Micropython is designed and used there are many ways that IDE could help, and there is a pretty clean path to building up functionality on PlatformIO to improve the use with Micropython.

One thing to make sure is clear, the devices has an interpreter on it, so compiling code is not required before hand. Adding cross compiler functionality can get into OS specific tools, Micropython version specific tools and could make things complex quickly. My suggestion is to focus first on the development cycle which usually includes a lot of writing code and synchronizing files to the device so they can be debugged.

The three main ways I can think of to synchronize files are

• USB mass storage (I use rsync similar to the rshell project)
• Serial connections (Using the raw REPL features, similar to the rshell project)
• Wireless/network ( I believe this is mostly socket communication)

If you can get the files over to the device the next thing is having a reliable REPL connection. This again mainly one of three methods.

• USB VCP that is usually used with the USB mass storage functionality
• Serial over a normal serial connection
• Wireless/network communication using sockets

Once you have a quick way you can get files over to the device and reliable REPL for the embedded python interpreted you have covered a majority of the needs for most development.

I personally wrote a script that synchronizes files based on a manifest file in my project using rsync to the USB mass storage device. This runs in a terminal tab in vscode, then I have a serial terminal as well for the REPL.

Once you get past that, the next thing I would find useful is a cross platform DFU utility to program the device, which could use one or more of the main communication methods.

Again once you get into Micropython cross compiling and DFU firmware builds, this suddenly opens up a lot of possibilities. I build custom boards so my micropython repo is customized for those boards, then I need backwards compatibility for clients so I also have multiple micropython versions. The cross compiler would be nice, but is version specific (or at least can be) so you have to match your cross compiled code with your micropython implementation.

One bonus feature is having files that mimics or provides standard library definitions in it so that the linter does not have as much issues.

[ivankravets]

Thanks all for the useful comments! I also did some research. I found 2 popular micro Python frameworks (virtual machines):

• https://github.com/micropython/micropython
• Fork of MicroPython by @adafruit @ladyada https://github.com/adafruit/circuitpython

Do you use other/own VMs?

What I found

1. All exiting docs and manuals force users to flash the target device with VM before. It is clear.
2. User personally manages *.py files and external modules/packages
3. User has a few options on how to "flash/deploy" code to a target device.

My proposal

1. We keep the same PlatformIO's philosophy with a "framework" option. You will be able to control which VM and version to use
2. No need to bother with VMs because we know everything about your hardware board =... and we can cross-compile true VM for the specific device directly on the user's host machine. And, yes, we can flash this device with Python VM
3. I see there is a tool called mpy-cross. I think we can use it to compile raw Python code to bytecode *.mpy, similar to *.pyc on desktop machines.
4. We can do uploading of *.mpy files. Yes, the *.mpy files should be compiled with the same VM which resides on the target device.

I think we can start with the official MicroPython. It covers a lot of hardware https://github.com/micropython/micropython/tree/master/ports

Libraries

I found a list of useful libraries/packages by @adafruit => https://github.com/adafruit/Adafruit_CircuitPython_Bundle/tree/master/libraries

It would be great to have them in our registry and do the same what we do with C/C++ libraries. So, extend PlatformIO Library Dependency Finder automatically deploy dependent libraries via cross-compilation depending on a VM type.

Example of workflow

1. Create a new PlatformIO project:

pio init -b esp32dev --project-option="framework=python"

Why python? There a lot of types: MicroPython, CircuitPython, Zerynth

2. Place project Python source code to src folder

3. Build a project or deploy firmware

# first time it will build VM 
pio run 
# flash
pio run -t upload

And yes, no need to install any tools, compilers, dockers, etc. Just "upload" and see how board blinks.

Comments are welcome.

[iBobik]

There is also fork of MP's original author @pfalcon: https://github.com/pfalcon/pycopy

[TravisJoe]

My personal thought is that the generic development cycle is much more important for user experience than the firmware deployment cycle (which is much less frequent).

My assumption, and based on my experience, most people start with a development board that already has a version of firmware on it. Or they use a pre-built stable firmware for a specific board. The only reason I started building my own firmware instead of using the stable builds is because I make custom boards with custom board definitions.

An efficient "write code, deploy code, test code" cycle is what is missing for me and I have written scripts to aid in this. I would guess most users both experienced and not would benefit from the focus on this as well.

Cross compiling is rarely a requirement because of how the VM is setup. Only once my projects are tested do I cross compile or freeze my code. Having the files in .py format aid in debugging as tracebacks can literally say which line number is causing the issue.

My personal suggestion is keep it simple for now. I rarely need to build new firmware, maybe every couple of months, and I use Micropython nearly every day for work and projects.

[ivankravets]

What to do with 3rd party packages/libraries?

• https://github.com/pfalcon/pycopy-lib
• https://github.com/adafruit/Adafruit_CircuitPython_Bundle/tree/master/libraries
• etc

Do you use them? Are they compatible between all these micro Python implementations?

[TravisJoe]

I have used some libraries, but few. And to make it more complex is that some libraries are port specific and some are not. I would say that external libraries (non-standard) are pretty use-case specific and most of the time I am writing my own or using the standard libraries.

I do agree that having a unified library and dependency system would help. Micropython has been working on and improving their "Machine" library to abstract more interfaces to help with making code and libraries cross port. But overall this is pretty rare for me. Once I get the library into my source folder (I cannot or do not use upip on my projects)

Micropython is close enough to python 3.5 some desktop libraries even work without editing.

For micropython's list of libraries look here as well https://github.com/micropython/micropython-lib