I’ve had a pico explorer since launch. Everything I tried before was working fine. Even when I did things outside the box for a few experiments.
I upgraded the pico to the latest and greatest pimoroni-pico-micropython release version (v0.1.1).
When I run the balls_demo (from github pimoroni-pico/micropython/examples/pico-explorer) it locks up the entire pico. I have to hard reset (pull the USB cable) and start again.
All the other demos run fine on the latest micropython without any issues, but they don’t create hundreds of ball objects.
It’s not a Thonny file transfer problem, or something like that. If I save to main.py then it locks up on boot and I can’t rescue the pico until I downgrade the micropython version! Do not try this at home!
I have to go all the way back to pimoroni-pico-micropython v0.0.6 alpha to make the balls_demo work again. I don’t change the balls_demo code at all, I just install a different micropython uf2 version and run balls_demo.py again.
On the 0.0.6 micropython I can run the balls_demo and even have up to 500 balls crawling around the full 240x240 display with no absolutely no problems.
With 0.1.1, if I define 5 (five) balls, it will show them moving for a couple of seconds and then locks up. Larger numbers doesn’t show anything at all.
I have another pico with a pico display, I haven’t tried if that has exactly the same problem. I suspect it will do something similar, the balls demo code is virtually the same, apart from the display size.
To the causal observer it looks like a massive micropython memory management problem.
Now I’ve found this issue, which seems to match what I’m experiencing:
Can anyone else please confirm this behaviour and/or suggest how to fix it on the latest pimoroni-pico-micropython?
Did you ‘nuke’ it to remove all the memory items, like font files and library modules, before changing the UF2s?
I’ve had a similar problem at the bottom of my Explorer screen - random noise in the bottom few rows of pixels when running a 300+ lines program. All rather annoying
I didn’t nuke or erase anything in the micropython file system. I just loaded different release uf2 files.
I have precisely one library of my own in the file system for 5x5 LED matrix breakouts, which is not involved here at all. It also works without problems.
All the other explorer demo programs work on all the different micropython releases, so I don’t really see what nuking the internal file system would solve.
It’s not corrupting the file system, it’s nuking itself in RAM. This is now beginning to worry me as, to the uninitiated, it looks like a fundamental object memory regression error somewhere between 0.0.6 and 0.0.7.
I’ve now gone back to the original balls_demo.py code.
With 100 balls on v0.1.1, it definitely shows memory corruption. It actually fails with a curious error:
(angled brackets removed for posting)
File “stdin”, line 50, in module
AttributeError: ‘int’ object has no attribute ‘x’
Line 50 is:
ball.x += ball.dx
When I go into the REPL and look at the balls object. It is not, as expected, “a load of balls”, it has been nuked in memory by something and micropython thinks it’s an int object.
When I only append 5 or 10 Ball objects instead of 100, then it tries to work (at least they are Ball objects on the explorer display). But it then locks up after a second or so,
Using exactly the same code on release version 0.0.6, I can allocate 500 Balls and it just has a problem to update them all smoothly, everything works ok.
I can now get 100 Balls staggering around the explorer display using v0.1.1, any more gives a memory error (which I can understand).
Over to the experts…
P.S. If anyone dares to use the ‘classic’ excuse that “Hey, it’s difficult to properly manage a linked list of arrays of pointers to pointers”, or something similar, then I will never use micropython ever, ever again!
Is it really using the extra bytes across the whole array from the start or just creating a large safety buffer which takes much long to get corrupted and show up?
Allocating a larger display buffer just moves everything around in memory, I realise that.
The balls list of Balls objects doesn’t seem to get corrupted like before, so the code runs. I left it going for hours and it doesn’t show any problems at all.
By the way, this had been described as a graphical glitch, see the github issue I posted above. I don’t see anything graphically strange at all. But if it’s actual destroying other objects or anything else by overwriting the wrong RAM addresses then, in my opinion, it’s potentially much more serious than spurious glitches when it accidentally marches through the display buffer with other objects. It could be overwriting nothing or anything in memory, depending on what’s going wrong.
I fear that the Pimoroni forums are probably not the best place to expect a useful reply!
Sorry, but that’s my experience.
I’m happy that on github @gadgetoid is aware of the problem. But Phil might still think it’s just a graphical flicker and it doesn’t really matter.
I don’t just want a fix (after 2 months). I want an explanation as to why lots of development has gone on without first stopping to fix this problem and an explanation of what has actually gone wrong.
It’s NOT Thonny. When I save my script to main.py it doesn’t work with v0.1.1. If all I do is reload pimoroni-pico-micropython v0.0.6 and it starts working fine at boot, how can it be a Thonny issue? Stop looking for a scapegoat.
Time to fire up the Pico C SDK and ignore micropython, or try to fathom out CircuitPython on the Pico with Pimoroni hardware and see what’s working there instead!
The I2C and SPI sensors and graphics support is better with CircuitPython but Adafruit cannot cope properly with interrupts, both cores or PIOs. I really hate the wait while C/C++ and Arduino IDE compiles. (I’m a bit of a one-small-step-at-a-time and test-it-properly programmer who is having problems getting to grips C/C++, even on a Raspberry Pi. I, and I suspect many others, could do with a slow and simple video on how to get going with Visual Studio and the C/C++ SDK.)
I think Pimoroni are trying to do too many things at the same time and are having difficulty keeping all their balls in the air. 32Blit on Kickstarter (where are the tutorials?) and the launch of the Pico at the same time has stretched the elastic a little too far.