How to use mpy_cross with emit=native for ESP32?

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
stanely
Posts: 40
Joined: Fri Jan 17, 2020 5:19 am
Location: Ohio, USA

How to use mpy_cross with emit=native for ESP32?

Post by stanely » Wed Feb 26, 2020 7:11 pm

I'm trying to speed up some code using the 'native' feature of the MicroPython cross compiler. So far, no luck.

The ESP32 uses an xtensa processor, and "mpy_cross" has two architecture options that mention the xtensa,
  • xtensa
  • xtensawin
I tried both with the following commands. Both times I got the "OSError: 2" message as shown below.

Code: Select all

K>python -m mpy_cross st7789py.py -march=xtensawin -X emit=native
This results in a crash dump.

Code: Select all

K>python -m mpy_cross st7789py.py -march=xtensa -X emit=native
This gives the message, "ValueError: incompatible .mpy arch"

From the MicroPython docs at, https://docs.micropython.org/en/latest/ ... files.html and https://docs.micropython.org/en/latest/ ... atmod.html, I think I'm supposed to use the windowed xtensa architecture. It's intended for the ESP32. That's why I'm getting the 'incompatible .mpy arch' error with the 'xtensa' architacture which is intended for the ESP8266.

Don't know where the crash-dump is coming from, though.

User avatar
jimmo
Posts: 1440
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: How to use mpy_cross with emit=native for ESP32?

Post by jimmo » Wed Feb 26, 2020 10:16 pm

stanely wrote:
Wed Feb 26, 2020 7:11 pm
I'm trying to speed up some code using the 'native' feature of the MicroPython cross compiler. So far, no luck.
Does it work if you use the @native decorator just in the Python code. .mpy files aren't really a huge benefit on their own unless you also freeze them into your firmware, or if you're very tight on flash space (which on ESP32 you probably aren't).

In fact, using -X emit=native is probably not what you want as it'll just use more RAM (as the generated code for all functions will now be 2x larger). Better off selectively adding @native to the functions that need the performance.
stanely wrote:
Wed Feb 26, 2020 7:11 pm
xtensawin
Yup -- ESP32 is xtensawin. xtensa is for ESP8266.
stanely wrote:
Wed Feb 26, 2020 7:11 pm
K>python -m mpy_cross st7789py.py -march=xtensawin -X emit=native
I think this means that you're running the version from pip/pipy? Can you confirm the version number? What firmware image do you have installed (i.e. what's the filename?)

Code: Select all

K>python -m mpy_cross --version
I guess you could try buying mpy-cross from source (just run make in micropython/mpy-cross), but if both the firmware and mpy-cross is 1.12 it should work.

It seems more likely that the versions match etc and something is wrong with the generated code. Are you able to share st7789py.py so I can test it out here?

stanely
Posts: 40
Joined: Fri Jan 17, 2020 5:19 am
Location: Ohio, USA

Re: How to use mpy_cross with emit=native for ESP32?

Post by stanely » Wed Feb 26, 2020 11:08 pm

I have plenty RAM to burn so it doesn't matter that MPY files are bigger. I am hoping to get a performance improvement.

I haven't tried @native. st7789py.py is devbis's code and has many functions. I don't understand it well enough to know which one is slow, so just wanted to speed up the whole module. It is the ST7789 display driver located here, https://github.com/devbis/st7789py_mpy.

I'm pretty sure I have the latest version of mpy_cross. It says,
MicroPython v1.12 on 2019-12-21; mpy-cross emitting mpy v5
My TTGO says the following in softboot,
MPY: soft reboot
MicroPython v1.12-167-gf020eac6a on 2020-02-14; ESP32 module with ESP32
I have plenty of flash space too, but am hoping to avoid installing and learning the build process. If I did that, I would just use the C driver that devbis has posted.

Everything I've done with MicroPython on the ESP32 has been plenty fast. I have my code running on the Heltec ESP32 WiFi Kit with the SSD1306 display and it's a burner. I was trying to port it to the LILYGO TTGO ESP32. This is the first thing I ran into that's dog slow.

Developing with MicroPython on the ESP32 has been a mind-blowing experience. The ease of use and speed of development is unbelievable.

User avatar
jimmo
Posts: 1440
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: How to use mpy_cross with emit=native for ESP32?

Post by jimmo » Thu Feb 27, 2020 12:07 am

stanely wrote:
Wed Feb 26, 2020 11:08 pm
I have plenty RAM to burn so it doesn't matter that MPY files are bigger. I am hoping to get a performance improvement.
Well as a quick test it might be worth just adding @micropython.native to each function in the .py file and try using that instead.

(The result will be almost the same in terms of memory used compared to the .mpy).

Looking at that driver, I can see why it's slow. As it has no external dependencies though, it might be a good candidate for the new dynamic native module support (i.e. you can compile the C version into an .mpy file).

stanely
Posts: 40
Joined: Fri Jan 17, 2020 5:19 am
Location: Ohio, USA

Re: How to use mpy_cross with emit=native for ESP32?

Post by stanely » Fri Feb 28, 2020 3:32 am

jimmo wrote:
Thu Feb 27, 2020 12:07 am
(i.e. you can compile the C version into an .mpy file).
I think I found how to do that here, https://docs.micropython.org/en/latest/ ... atmod.html, but this effort's gonna have to wait.

stanely
Posts: 40
Joined: Fri Jan 17, 2020 5:19 am
Location: Ohio, USA

Re: How to use mpy_cross with emit=native for ESP32?

Post by stanely » Fri Feb 28, 2020 3:45 am

It looks like the, "@micropython.native", did some good. It took 6.57 seconds to fill the screen with "Hello!"s previously, now it takes 4.11 seconds. That's a 37.5% reduction! There was one more module where I added the "@micropython.native" line. I also increased the SPI baud rate to the max that would run, from: 'baudrate=30000000" to: "baudrate=33000000".

I think that's good progress, but the T-Display is still too slow. It also lacks support for Peter's neat Writer class. That's is a death knell in itself. :)

Post Reply