On a Pico W, EInkPIO may not be usable in a loop

[Cheddoleum]

There appears to be a known issue with the Pico W where some PIO instruction memory is not released; apparently for reasons relating to the wifi system. Calling the StateMachine() constructor repeatedly will result in an ENOMEM after a certain number of iterations.

These issues address a manifestation of the problem: micropython/micropython#9003 and
micropython/micropython#10652 , but mainly just fix the issue as it pertains to soft resets, e.g. in Thonny, and don't address the issue of reinitializing the state machine within a program.

I'm using your library in a remote temperature/humidity display; it checks the sensor every few minutes and if it needs to, redraws the screen. After a a given redraw it calls .sleep(). The EInkPIO object is constructed locally to this function and so is GC'd afterward.

To reinitialize the screen after a sleep it appears to be necessary to instantiate a EInkPIO object again, which constructs its ._sm StateMachine member in _pio_setup(). After a fairly small number of refreshes, the program dies with an OSError 12 on that line.

For my use case I can get around this by simply using the Eink class instead. (I'm using generated images so the speed/memory difference when rotated isn't a problem; I can just use rotated images instead.)

But without a way to restart the display after a .sleep() without instantiating a leaky-on-the-PicoW StateMachine, there doesn't seem to be a way to use EInkPIO in a loop on the W.

[phoreglad]

Can you instantiate the EinkPIO object only once, outside of any functions and use it as a 'global' object (or pass it as an argument to the function)? That would fix the problem. Other possibility is to manually release the PIO program memory at the end of the function to make sure there's space for the next run.

The issues you've linked to don't really apply here as you're not doing a soft reset between the function calls. Without the soft reset even if the StateMachine object gets deleted and collected, the program that it started still runs and takes instruction space.

[Cheddoleum]

I've tried your first suggestion, but after a sleep the EInkPIO object doesn't seem to be usable for drawing again; it just hangs when you try. Waveshare's docs says that to start using the display again after a sleep (assuming you're both referring to the same "sleep" mode) it must be reinitialized. Your lib doesn't have a public reinitialization function other than the constructor.

(I may have spoken too soon anyway -- I'm now getting a MemoryError a few iterations in [sometimes!] while using EInk, so the OSError 12 (ENOMEM) on EInkPIO instantiation failure may simply have been a symptom of running out of memory some other way) Even more strangely it's difficult to reproduce. Trying to chase it down now but the inconsistency is bothering me: this is not a complicated program at all, and one really doesn't expect memory leaks in Python in the ordinary case anyway. I'll update when I know more)

[phoreglad]

Yes, you're right about reinitialisation. I've updated the library to include a public reinit() method. After putting the screen to sleep make sure to call reinit() before next call to show().

As for the error when using EInk class it might be caused by memory fragmentation. The screen requires relatively large framebuffers, so recreating the EInk object several times and running other code in between might not leave enough contiguous memory for the buffers.

[Cheddoleum]

Thank you! I'll give it a try soon. Just traced an instance of the crash to of EInk send where it creates bytes and map objects to handle 90/270 rotated displays. (I was right in the middle implementing the ability to request a rotated image from the provider so I could stop doing that anyway.)

I'll also look into mitigation tactics for memory fragmentation as you suggest. (If all else fails I'll just soft-reset and restart programmatically in the memory exception handler -- the result shouldn't look out of the ordinary to the user. Gruesome hack though.)

[phoreglad]

If you initialise the EInkPIO at the very beginning of your program (to make sure there's plenty of free memory available) and reuse it with the help of a new reinit() method, memory fragmentation shouldn't be a problem and your program should work just fine.

Unfortunately EInk class requires quite a lot of memory to handle the rotations reasonably quickly making it more susceptible to running out of memory and fragmentation problems. The PIO variant is much better in this regard and I strongly recommend using it.

[Cheddoleum]

After implementing that, it's been running stably for several hours now, a very solid improvement. Thanks very much again.

A couple of questions when/if you have a moment?

1. Along the same lines as the above: avoiding large dynamic memory allocations in an eternal loop program on a platform with no real memory management, I'd like to be able to reuse FrameBuffers. But the only obvious way to populate a FrameBuffer with binary data (such as generated by your image-to-py conversion utility) is to do it at construct time; so I'm creating a new one every time I write a new image.* Is there a way to declare a single FrameBuffer instance globally and reuse it, writing new binary data into it? See my reply below; not a good question.

2. When blit()ing into Eink[PIO] from a 1-bit-depth framebuffer (i.e. constructed with the framebuf.MONO_HLSB arg), white pixels are treated as transparent even when key is left undefined (-1). So if doing a partial display write over an existing image, only the black pixels are written: any existing black pixels will remain on the display and won't be clobbered by the white ones. To get around this, I'm "scrubbing" the area first like so:

        epd.rect(left, top , width, height, 1, f=True)
        epd.show()
        epd.rect(left, top, width, height, 0, f=True)
        epd.show()

before blitting the new image. Nothing less than that does the job. (For example, writing a white rectangle over existing black pixels doesn't seem to accomplish it, I have to turn the whole rectangle black first.) But this feels like a hack and is visible to the user. Is there way to blit it such that it writes both white and black pixels and no source pixel is treated as transparent?

(*I've refactored your image-to-py conversion utility into a callable function, and using it on the web server that provides data to this device, generating these images dynamically from sensor data on request.)

BTW here's what it looks like. (Running instance connected only to a battery.) Yes, it's very warm here today:

[Cheddoleum]

(I'm sorry, on further consideration please ignore that first question: of course FrameBuffer is mostly a wrapper for memory that's already allocated; in this case, read from a web request and 'eval'd to turn it into a bytearray. Reusing a FrameBuffer would not help here.)

[Cheddoleum]

Thanks again.

Another question -- of the "just picking your brain" sort -- when/if you have a moment. Right now I've got it set to do a full screen refresh (non-partial write) every 24 partial writes. This is a fairly high multiple of what Waveshare suggests. But to be honest I'm really not clear on what problem one is trying to prevent by periodically doing a full rewrite every X writes. There is some suggestion of stuck pixels or something, but no real explanation of what the mechanism is or when and why it's a concern. At minimum I really only need to clobber the whole screen when the day changes (see the photo above for the application). I'm strongly tempted to eliminate the other periodic full screen rewrites entirely, as I really don't know what problem it's solving.

[phoreglad]

To be honest, the e-ink displays are a bit of a magic and it's sometimes hard to find information on them. What is called a "partial update" in this driver (and the original one, where I took the name from) should really be called a "differential update" (sometimes also called "fast update") as only the pixels that changed from the previous image are updated. From what I understand doing so multiple times without full refresh can cause the particles in the screen to stick to one another instead of moving towards the electrodes or simply the wrong voltage being applied, which may lead to visible ghosts of the previous image. The exact mechanism is dependent on the screen type, I found some helpful explanations here. I'm not totally sure if it can lead to permanent damage to the display. Still, most manufacturers recommend that the full refresh is done every few partial/differential/fast updates to avoid potential problems and that's what I would stick to.

[Cheddoleum]

Thanks for that. Interestingly, when you write a black rectangle to scrub an area, that rectangle actually briefly flashes all white first. Which suggests to me that even in partial update mode, this particular device with its particular firmware used in this particular way, does a certain amount of custodial work to clear the pixels, at least in some use cases. In any event, I'm updating one region every minute for a time display, and I've extended the "full refresh" interval to something on the order of every 3 hours. It's been running 24/7 for a few days now. So far, not a hint of ghosting.