Presto PicoVector Issue

Support
1

I was playing with PicoVector API on the Presto and have come across an issue. Before I submit a bug report, could some see if this code works for them. It just draws a few arcs, but seems to sometimes lock the Presto requiring a reset to get it back to life. A couple of times not even a reset worked and it needed to be re-flashed.

from presto import Presto
from picovector import PicoVector, Polygon, Transform, ANTIALIAS_FAST

# Setup for the Presto display
presto = Presto(layers = 1, full_res=False, ambient_light=False)
display = presto.display

vector = PicoVector(display)

vector.set_antialiasing(ANTIALIAS_FAST)

WIDTH, HEIGHT = display.get_bounds()

# Couple of colours for use later
BLACK = display.create_pen(0,0,0)
BLUE = display.create_pen(0,0, 202)
RED = display.create_pen(200,0,0)
WHITE = display.create_pen(255, 255, 255)
GREEN = display.create_pen(0,255,0)
YELLOW = display.create_pen(0,255,255)



def draw_arc(x,y,r,q,c):
# x,y = centre, r = radius, q = quadrant, c = circle position
# if centre of flow at x,y, then calculate co-ord for arc centre
# and start and end angles
    if q == 1:
        xpos = x-r
        ypos = y-r
        astart = 0
        aend = 90
    elif q == 2:
        xpos = x+r
        ypos = y-r
        astart = 0
        aend = -90
    elif q == 3:
        xpos = x+r
        ypos = y+r
        astart = 180
        aend = 270
    elif q == 4:
        xpos = x-r
        ypos = y+r
        astart = 90
        aend = 180
    arc_a = Polygon()
    arc_a.arc(xpos,ypos,r, astart, aend, 3)
#    arc_a.circle(xpos,ypos,r,3)
    
    vector.draw(arc_a)
 

# Clear the screen and use blue as the background colour
display.set_pen(BLUE)
display.clear()
display.set_pen(WHITE)
xpos=120
ypos=100
radius = 75
sc = 0.7

for i in range(10,12):
    display.set_pen(BLACK)
    display.clear()
    display.set_pen(RED)
    draw_arc(xpos,ypos,radius,1,i)
    display.set_pen(BLUE)
    draw_arc(xpos,ypos,radius,2,int(i/2))
    display.set_pen(GREEN)
    draw_arc(xpos,ypos,radius,3,int(i/5))
    display.set_pen(YELLOW)
    draw_arc(xpos,ypos,radius,4,int((i*5) % 90))
    presto.update()
2

At what point does it lockup? Your code does not have an infinite loop so once

for i in range(10,12):

completes no further drawing will occur

3

It’s difficult to tell exactly where - I’ve tried putting print statements to monitor the process, but the run extent varies. I’m running it from Thonny, so when it completes, it should go back to the REPL prompt, but it often doesn’t and I need to press reset. This is a typical execution output from Thonny:

>>> %Run -c $EDITOR_CONTENT

MPY: soft reboot
signal core1
core1 returned
malloc self
set fb pointers
m_new_class(ST7701...
launch core1
launched core1
core1 returned
PROBLEM IN THONNY'S BACK-END: Exception while handling 'Run' (ConnectionError: device reports readiness to read but returned no data (device disconnected or multiple access on port?)).
See Thonny's backend.log for more info.
You may need to press "Stop/Restart" or hard-reset your MicroPython device and try again.


Process ended with exit code 1.

As I said, usually a reset gets it back (and that’s what I did in that run after it stalled ) but sometimes it needs to be power cycled and a few times I’ve had to reflash it.

I’ve just run the program with some print statements included - it seems to get the two times through the code and then never returns to the REPL prompt.

However, I’ve run the same program using minicom instead of Thonny and it completes every time. So now I’m confused!

4

…could alse be a USB power issue with Presto as it draws quite some power from the USB port.
I also experienced a frozen Thonny app and have USB current monitoring, so I figured it out.

I now have connected Presto to a dedicated more powerful USB port and now it works without issues…

5

It’s on a USB-C power delivery port, so I would hope it’s not an issue, and I’ve just connected a USB power monitor and it doesn’t take any more than about 0.2A

6

Same with me, Presto was connected to a USB-powered hub, but for some reason it was not able to supply all connected devices properly.
In the moment I connected Presto directly to one of the computer‘s USB ports it worked since then without problems… give it a try…

7

The USB-C port is on the computer its self. I’ve just changed to a USB-A port and it is behaving the same.

Basically the issue is this:

  • Running PicoVector arc code via Thonny there is an issue.

  • Things not containing PicoVector arc code are OK

  • Running it in any other way is fine.

I just get this feeling that something in the firmware is affecting the USB connection when the board is in FS mode.

I’m trying to find some consistent way of reproducing the error. Below is the code I’m currently using. Under Thonny the code will run fine the first time through all 99 iterations; the second time I run it, it only does 2 iterations of the loop then stops producing any output.

Changing the Polygon from an arc to a circle and it’s OK.

The bottom line is, is this a bug and repeatable on other devices, or is it something strange with my setup?

from presto import Presto
from picovector import PicoVector, Polygon, Transform, ANTIALIAS_FAST

# Setup for the Presto display
presto = Presto(layers = 1, full_res=False, ambient_light=False)
display = presto.display

vector = PicoVector(display)

vector.set_antialiasing(ANTIALIAS_FAST)

WIDTH, HEIGHT = display.get_bounds()

# Couple of colours for use later
BLACK = display.create_pen(0,0,0)
BLUE = display.create_pen(0,0, 202)
RED = display.create_pen(200,0,0)
WHITE = display.create_pen(255, 255, 255)
GREEN = display.create_pen(0,255,0)
YELLOW = display.create_pen(0,255,255)



def draw_arc(x,y,r,q,c):
# x,y = centre, r = radius, q = quadrant, c = circle position
# if centre of flow at x,y, then calculate co-ord for arc centre
# and start and end angles
    if q == 1:
        xpos = x-r
        ypos = y-r
        astart = 0
        aend = 90
    elif q == 2:
        xpos = x+r
        ypos = y-r
        astart = 0
        aend = -90
    elif q == 3:
        xpos = x+r
        ypos = y+r
        astart = 180
        aend = 270
    elif q == 4:
        xpos = x-r
        ypos = y+r
        astart = 90
        aend = 180
    arc_a = Polygon()
    arc_a.arc(xpos,ypos,r, astart, aend, 3)
#    arc_a.circle(xpos,ypos,r,3)
    
    vector.draw(arc_a)
 

# Clear the screen and use blue as the background colour
display.set_pen(BLUE)
display.clear()
display.set_pen(WHITE)
xpos=120
ypos=100
radius = 75
sc = 0.7

for i in range(1,100):
    print(i)
    display.set_pen(BLACK)
    display.clear()
    display.set_pen(RED)
    print("arc 1")
    draw_arc(xpos,ypos,radius,1,i)
    display.set_pen(BLUE)
    print("arc 2")
    draw_arc(xpos,ypos,radius,2,int(i/2))
    display.set_pen(GREEN)
    print("arc 3")
    draw_arc(xpos,ypos,radius,3,int(i/5))
    display.set_pen(YELLOW)
    print("arc 4")
    draw_arc(xpos,ypos,radius,4,int((i*5) % 90))
    presto.update()
8

…have you really updated to the latest firmware image from December? Pay attention that files could be completely wiped off…backup your source code first, then flash the image…

If yes, I still doubt that it depends on the arc calculations itself, but still indirect it affects the freeze.
I believe the calculation simply draws more peak current and this conflicts with your USB port…
The whole behaviour reminds me to my experience and changing the port was the solution…

I don’t believe your code is the problem, whereas the calculation algorithm in any of the libraries could be (which in contrast would not explain that the arc calculation passes 2 times without any problems).
In addition, you could change the sequence of imported libraries this way, that own (non-system) libraries comes first to definitively use the maths algorithms of the systems libraries which comes last and this overrides any previous and possibly faulty code (I would assume system libraries to be most accurate or else every other developer would have the same problems)…

9

Maybe try the following:

Is the problem with aborting the second run (just 2 passes of the for loop) the same when you hit the reconnect button in thonny first and then run the code the second time?

Next try would be to reset the Presto prior to starting the program again…

Another root cause could be a memory issue/buffer overrun as you play around with polygons…I cannot argue about the memory consumption of the polygon function.

Maybe you should implement memory clean-up strategies…

10

I’ve tried multiple USB ports, all direct computer ports, i.e. no hubs involved, and it has made no difference. It’s still drawing 0.2A which is well within any of the USB standards.

Yes, the firmware is the correct/most recent image:

MicroPython feature/presto-wireless, presto v0.0.5 on 2024-12-18; Presto with RP2350 here

The only things I’m importing are from Presto and PicoVector. I’m not using any of the Transform functions so I removed that from the import list - it failed even sooner and won’t even run through two full iterations ever.

Resetting the Presto before doing a second run allows the program to run as if it is the first run (which it effectively is!).

As for memory management & cleanup - how?! I’m no python expert, but surely the memory management will reclaim the memory allocated to the variables when it exits the function; there’s no explicit function to release memory.

I tried moving the ‘arc_a = Polygon()’ to outside the loop so it doesn’t keep being allocated - now it reaches about 11 iterations through the loop and then dies with the screen messed up - the execution gets progressively slower as well. It certainly seems to point to some memory management issues somewhere in the PicoVector code.

I’ll file a bug on Git and see what they say.

11

…have you also seen this thread about somebody also arguing about drawing arcs using the library picovector?
This smells like there could actually be an error in the library…

12

So it was actually a bug in the arc code that resulted in a memory corruption. See Lockup using PicoVector arc function with Thonny · Issue #41 · pimoroni/presto · GitHub - it will be included in v0.0.6

1 Like
13

I’ve jus run your code on my PRESTO. I am powering from a PC USB-A socket. It runs perfectly the first time to the end. If I then run it again it dies with a narrow segment inside curve of the red arc and dies like this:

MPY: soft reboot
signal core1
core1 returned
malloc self
set fb pointers
m_new_class(ST7701...
launch core1
launched core1
core1 returned
1
arc 1
arc 2
arc 3
arc 4
2
arc 1
arc 2
arc 3
arc 4

Not spent much time with vectors yet - on the wish to know list.

There does appear to be something wrong here. Best wishes

14

Yes, there is/was a bug in the arc code. It’s fixed in the most recent (v0.0.6) release