micropython-nano-gui icon indicating copy to clipboard operation
micropython-nano-gui copied to clipboard

Published 20 hours ago • verified publisher icon peterhinch

framebuf_utils.mpy runtime error

Open fpgirard opened this issue 4 years ago • 3 comments

Hi Peter - I really admire and appreciate all of the contributions you've been making to micropython. I'm not sure if you want me to post an issue I'm having with nano-gui here or on the forum. Quite willing to cross-post if that's preferable. My issue is that I'm encountering a runtime error after cross-compiling framebuf_utils to ESP32. Here are the steps I've taken and I'm probably doing something incorrectly.

  1. Using a Lolin D32 Pro with WROVER-B, I compiled micropython with GENERIC_SPIRAM flag from source to build the latest version - MicroPython v1.13-321-gef9fde733 on 2021-01-31; ESP32 module (spiram) with ESP32 - from scratch. Installed this version on the ESP32 (see attached pic). I'm fairly confident that the WROVER-B supports SPIRAM/PSRAM and I experienced zero errors compiling and deploying it on the D32. I'm getting pretty good at doing this.
  2. If I don't install a cross-compiled framebuf_utils.mpy and thus default to the STM version (which properly ignores the framebuf_utils.mpy), your aclock and other demos work flawlessly. So does my metered 'grow.py' demo which runs indefinitely.
  3. I then edit your micropython-font-to-py/writer/framebuf_utils/Makefile to use the same micropython distribution's mpy-cross and cross-compile your latest framebuf_utils to ESP32. (ARCH = xtensawin). No errors (see attached screen grab).
  4. When I install my version in gui/core on the ESP32, the demos use the mpy executable and run for multiple iterations before crashing with the following errors:

Traceback (most recent call last): File "", line 1, in File "grow.py", line 55, in File "grow.py", line 44, in meter File "gui/widgets/meter.py", line 31, in value File "gui/widgets/meter.py", line 56, in show File "gui/widgets/label.py", line 21, in init File "gui/widgets/label.py", line 32, in value File "gui/widgets/label.py", line 44, in show File "gui/core/writer.py", line 144, in printstring File "gui/core/writer.py", line 164, in _printline File "gui/core/writer.py", line 281, in _pchfast TypeError:

I'm quite happy to help debug in any way that we need - realize, however, that you're dealing with an amateur and patience will be required. Would love to get this working as I'm really looking forward to using your light gui! Thank you. Pascal ([email protected]).

Screen Shot 2021-01-31 at 4 12 33 PM Screen Shot 2021-01-31 at 4 27 08 PM Screen Shot 2021-01-31 at 4 45 58 PM

fpgirard avatar Jan 31 '21 21:01 fpgirard

You have had more success than me.

The reason I only distribute a framebuf_utils.mpy compiled for STM rather than one for each arch is that the ESP32 build does not work. In my case it crashes on import. There is an outstanding issue regarding native C modules on ESP32. I am waiting for this to be resolved before trying again.

In the meantime you're best off only using framebuf_utils.mpy on STM.

peterhinch avatar Feb 01 '21 08:02 peterhinch

Wow. Not quite the response I was expecting but it's good to have company to join the misery. Perhaps I should get a pyboard..... In the meantime, I'm off to implement mqtt. Got PID flow control working nicely. Fun... Thanks.

fpgirard avatar Feb 01 '21 21:02 fpgirard

You should find that everything works fine without framebuf_utils.mpy. The only consequence is slower text rendering.

The ESP32 port is substantially slower than a Pyboard: I thoroughly recommend a Pyboard 1.1 or any Pyboard D.

If you need hardware interrupts, Pyboards are faster by a huge factor. In the case of the ESP32 with SPIRAM, interrupt latency can be well over 1000 times less on a Pyboard.

peterhinch avatar Feb 02 '21 07:02 peterhinch