Struggling with my Plasma 2040

Hello, @alphanumeric- with a “minimal” diagnostic print(trailer) statement, the code runs fine (with NUM_LEDS = 144). But if I change this to print(i, trailer) the code fails when i = 143 and trailer = 16. I am now more convinced that the cause of my problem is my use of print() statements which, ironically, I’m using to try to track the progress of my code. See also @dBerriff 's comment below!

Hello, @dBerriff - I would agree with you regarding what I’m struggling with- MicroPython rather than the Plasma 2040. My past experience has been that, the more diagnostic messages are output, the buggier the code issuing them is, and my code is certainly an example of this! The excessive debug messages are to try to identify where my code has failed.
I acknowledge, and greatly appreciate your comments about trusting the technology and reviewing my methodology- this is very much a learning experience for me, and I’ve previously looked to see if I can change the name of my original post to something more appropriate, in line with my struggles with code rather than the device.
I have, however, tried to develop my code in a more modular fashion than it might appear; it contains two loops for i in range(NUM_LEDS): and I’ve found that, if I comment one or the other, the uncommented loop runs without a problem but when I attempt to run both, I have a failure; my instinct is then to add a diagnostic print() to show whether I have calculated values correctly. Adding the print() then changes the behaviour further!
I am hoping for an “Ah-ha” moment where all my errors become obvious to me, but at this point, I greatly appreciate your suggestions, and those of @alphanumeric.

User Error- code addressed a LED outside the valid range.

1 Like

That’s what I was thinking might be happening. My best guess as it were. Nice to know you finally sorted it out. Now you can go back to having some fun with your Plasma. I have a Plasma 2350 sitting here on my desk. The plan is to swap it in place of my Plasma 240. I just have to find my round 2it. ;)

1 Like

Thanks for all of your help, @alphanumeric. Have fun with the 2350!

Print statements are invaluable.

I would try to use functions more. Try to use them in purist sense. Also do not worry if a function does not do much. The point is to organise and then test the building blocks of your code.

Pass in values through the parameters and use the return statement to deliver the output. You have some powerful data structures in Python and you could, for example, use a list or dictionary if you have lots of values to move around. The return statement returns a tuple in any case.

There is always an overhead to using a function but it is better to do something slowly and right. Once your code is working you can always go back and tidy it up if necessary.

The way MicroPython works with these strips is to load the 32-bit pixel “colour” values (24-bit colour plus a white-value, even if not used) into a byte-array, and then use very precise timing to write out the array to the strip. I know how I have implemented it (PIO instructions) but I do not know how the Pimoroni library has been implemented (I now limit my hours sat at a computer!). If print statements upset the code then they must be interfering with the timing in some way.

So start with simple elements, test and correct the code, then save as reusable functions (or class methods if you use classes). What you are aiming for is a structure where you trust each element.

There are still “gotchas”. Example: pixel strips require a few microseconds delay between writes. When I took out a print statement I suddenly had corrupted output from my carefully tested function. The code was now running too fast. Adding a 1ms sleep restored order.

The Pimoroni library appears to avoid this possibility by updating the pixel strip at fixed intervals.

The RP2040 chip running MicroPython is a very capable and productive platform. The Pimoroni boards bring everything together into impressive, focussed solutions. Sorry for rambling on but I just get carried away by my enthusiasm.

1 Like

@dBerriff, thank you for this very sound advice, and also for the description of the (potential) timing issues- the latter certainly fits with some of my attempts to get code working where a short sleep really helped. With regard to my printing of heaps, I was trying to see if there was an indication of an overwrite… but, of course, I had no idea of what I was looking at, or for! Similarly, my original running of the gc.collect seemed entirely excessive and I’m very happy to take your other advice- trust the technology.
Thanks again.

Running gc.collect() is usually worth doing as you are then in control of when garbage collection happens. If there is a pause (sleep) in the top-level code then that is a good point. Better this than a large clear-out when it has not been planned.

1 Like