2.2 branch doesn't work on v2.2 display

[richterlevania3]

The code executes, but nothing happens on the display. I deleted the old branch and cloned this one. Maybe I'm doing something wrong?

EDIT: got this error>

epd.config loaded Traceback (most recent call last): File "/home/writer/zerowriter1-waveshare_2.2/e-Paper/RaspberryPi_JetsonNano/python/examples/main.py", line 23, in <module> from zerowriter import ZeroWriter File "/home/writer/zerowriter1-waveshare_2.2/e-Paper/RaspberryPi_JetsonNano/python/examples/zerowriter.py", line 3, in <module> import qrcode ModuleNotFoundError: No module named 'qrcode'

[zerowriter]

hi! i forgot to add -- you need to install the qrcode library via terminal (pip install qrcode) like the other installs

If you get that module error for something else, it probably needs a pip install

[richterlevania3]

Well, installed qrcode and yagmail (it was a PITA because I had to increase SWAP to 1gb to get it to install).

Now it's stuck on this epd.config loaded starting data server...

[zerowriter]

edit --

[zerowriter]

trying a build myself now, I had the same problem occur. I'll figure it out and update thread. Thanks!

[richterlevania3]

Ok, I rebooted just to make sure. Started the program again, same thing happened. Control-C, saw the screen refreshing while it stopped. Started again, this time it looked like it worked, but the text is mirrored on the horizontal axis.

Weird.

Rebooted, started again. Nothing. Started once more and now it works, but the mirroring problem persists. Tried to write something and it looks like it's working, albeit mirrored, until it reaches end of line. Then it copies the entire line 5 or 6 times instead of scrolling. There is some wonky thing happening.

In conclusion, there are 3 problemns right now: it needs to start two times to work, it's mirrored on the X axis and text scrolling doesn't work.

[zerowriter]

Try forcing refresh a few times -- CTRL + R

For some reason, mine worked after a few forced refreshes. Not entirely sure what is going on there. Will keep trying some stuff.

[richterlevania3]

Tried forced refresh. It worked and it fixed the mirroring. Weeeird. But, the scrolling problem persists and now there is another problem: when the screen is full it stops scrolling and the text goes out of bounds. Pressing enter to save the file to cache refreshes the screen and resets the line. But, once that line reaches the end, it goes out of bounds and stop refreshing.

I'm gonna give it a go tomorrow, thanks for the help.

[zerowriter]

It looks like it is something to do with the screen initialization script not executing properly -- it should flash after loading epd.config. I am having similar issues so I will probably push a fix when I figure out the root problem.

The initialization will cause all kinds of craziness if it isn't handled cleanly, like everything you are describing... so there must be some conflict I missed on my other setup, but a fresh one is also having the issues you reported.

Anyway, thanks -- I will sort :)

[zerowriter]

Just in case someone sees this and wants to take a stab at it. I'll work on it more over the weekend.

On startup, and when forced for refreshes, we run:

self.epd.init()
self.epd.Clear()

# these basically serve us a clean screen, but also run some of the waveshare stuff that gets the display working as intended -- runs some setup-type stuff, gets it ready for updates, etc. if the init() fails or isn't handled as expected, it can cause weird artifacting, unresponsiveness, off-centered text, all sorts of weirdness.

For some reason, we are misfiring one or both of these. My development SD card works without a problem, but there probably has been some SPI-related update to something that has got it out of whack. Maybe something in spidev has changed.

Anyway, It could be the state of epdconfig. I was trying some whacky values to see if I could find any differences.

        self.SPI.open(0, 1)
        self.SPI.max_speed_hz = 99999999#90000000
        self.SPI.mode = 0b11 #0b00 originally 0b00 trying 0b11

Reverting these might solve issues if they are SPI timing related.

And if that doesn't resolve it, it probably means adjusting some of the code in the epd4in2_V2.py file.

[zerowriter]

just pushed a fix to the branch. It was the epd.config file that was the culprit, and the fix should resolve this. just reintroduced the sleep in the line above:

def delay_ms(self, delaytime): time.sleep(delaytime / 1000.0)

which was commented out in my other unit (and working fine, oddly enough). Anyway, this will get things running smoothly and reliable.

[richterlevania3]

Just to be sure, I removed the cloned folder I had and downloaded the .zip file of the v2.2 branch. Unziped, started main.py and everything that happened before, happened again. To clarify, text is nice and clear and is reasonably speedy. But, once it reachs end of line, it covers the entire screen with the same line, top to bottom. Then, instead of scrolling text, once the text gets to end of the line it goes out of bounds. Pressing Enter refreshes the screen, fixing this. But, it happens again when I reach end of line again.

Ah, it also doesn't start right away to first time. I either have to kill the process and start it again to get something on the screen, or I need to CTRL-R to refresh it.

In other words, at least on my end nothing is fixed.

[zerowriter]

I'm trying some different builds today to try to reproduce.. could you let me know if you are running a pi zero 2w with 32bit lite bookworm? If not, I would suggest reflashing a SD card with that install and working from there.

From what you are describing, it sounds like memory issues.. I have seen that kind of corruption happen when my unit is tapped out of memory. But more often in the 64bit or desktop installs on a pizero2w, or on an original pi zero.

Also could be something in my code causing memory leaks.

Anyway, it could be memory issues... or something else entirely. I'm trying a fresh install on 64bit lite just to see.

edit: also, I get display corruption like that if I push my overclock settings too far. Not sure if you are overclocking or just running stock, but worth mentioning here in case anybody else takes a look.

[holmesha]

Testing the 2.2 code now and it works pretty well for me! The only thing I couldn't get to work was the arrow keys, but maybe I'm misunderstanding the directions.

[richterlevania3]

I'm trying some different builds today to try to reproduce.. could you let me know if you are running a pi zero 2w with 32bit lite bookworm? If not, I would suggest reflashing a SD card with that install and working from there.

From what you are describing, it sounds like memory issues.. I have seen that kind of corruption happen when my unit is tapped out of memory. But more often in the 64bit or desktop installs on a pizero2w, or on an original pi zero.

Also could be something in my code causing memory leaks.

Anyway, it could be memory issues... or something else entirely. I'm trying a fresh install on 64bit lite just to see.

edit: also, I get display corruption like that if I push my overclock settings too far. Not sure if you are overclocking or just running stock, but worth mentioning here in case anybody else takes a look.

Sorry for the delay. I'm using the Rpi Zero 2 W with Raspbian 32bit lite. It has 1gb of swap file, so I'm pretty sure memory is not an issue. I will update the clone today and see if it improved.

[zerowriter]

Testing the 2.2 code now and it works pretty well for me! The only thing I couldn't get to work was the arrow keys, but maybe I'm misunderstanding the directions.

The arrow keys are working on my unit, but they don't compensate for the latency of the 2.2v display very well and are a bit unresponsive because of it. I will clean that up.

But the arrow keys only work for reviewing "pages" of your file. Think of it like 1 page = 1 screen. The arrow keys don't work for editing / cursor navigation.

[zerowriter]

I'm trying some different builds today to try to reproduce.. could you let me know if you are running a pi zero 2w with 32bit lite bookworm? If not, I would suggest reflashing a SD card with that install and working from there. From what you are describing, it sounds like memory issues.. I have seen that kind of corruption happen when my unit is tapped out of memory. But more often in the 64bit or desktop installs on a pizero2w, or on an original pi zero. Also could be something in my code causing memory leaks. Anyway, it could be memory issues... or something else entirely. I'm trying a fresh install on 64bit lite just to see. edit: also, I get display corruption like that if I push my overclock settings too far. Not sure if you are overclocking or just running stock, but worth mentioning here in case anybody else takes a look.

Sorry for the delay. I'm using the Rpi Zero 2 W with Raspbian 32bit lite. It has 1gb of swap file, so I'm pretty sure memory is not an issue. I will update the clone today and see if it improved.

Thanks! Same as my config then. bookworm?

I think IF your unit is using swap file, that could be causing some issues.. because the swap file from SD card speeds might be too slow for the speed of the SPI driver. But I don't think your pi will be using swap in any case, your setup should be fine with plenty of memory to spare. So maybe this is not a memory issue after all.

but, just for comparison, here is my "sudo free -m" when zerowriter is running:

               total        used        free      shared  buff/cache   available
Mem:             426          68         181           0         176         304

using 0 swap

[richterlevania3]

I'm trying some different builds today to try to reproduce.. could you let me know if you are running a pi zero 2w with 32bit lite bookworm? If not, I would suggest reflashing a SD card with that install and working from there. From what you are describing, it sounds like memory issues.. I have seen that kind of corruption happen when my unit is tapped out of memory. But more often in the 64bit or desktop installs on a pizero2w, or on an original pi zero. Also could be something in my code causing memory leaks. Anyway, it could be memory issues... or something else entirely. I'm trying a fresh install on 64bit lite just to see. edit: also, I get display corruption like that if I push my overclock settings too far. Not sure if you are overclocking or just running stock, but worth mentioning here in case anybody else takes a look.

Sorry for the delay. I'm using the Rpi Zero 2 W with Raspbian 32bit lite. It has 1gb of swap file, so I'm pretty sure memory is not an issue. I will update the clone today and see if it improved.

Thanks! Same as my config then. bookworm?

I think IF your unit is using swap file, that could be causing some issues.. because the swap file from SD card speeds might be too slow for the speed of the SPI driver. But I don't think your pi will be using swap in any case, your setup should be fine with plenty of memory to spare. So maybe this is not a memory issue after all.

but, just for comparison, here is my "sudo free -m" when zerowriter is running:

               total        used        free      shared  buff/cache   available
Mem:             426          68         181           0         176         304

using 0 swap

Sorry for the delay. I'm using a 1Gb swap file now, but it was the default 100Mb before.

Just checked again and nothing changed for me. Still the same issues as before. Just to be sure, I deleted everything on the Rpi and downloaded again. I'm attaching a picture of how it looks like.

[zerowriter]

Hmm. I will re-image one myself tomorrow and see if I can reproduce.

You could try replacing the modified driver with the defaults from waveshare’s GitHub page… (Also epdconfig). I think you could just drop them in and rename them. This would mean a slower display but possibly more reliable if something in my driver isn’t agreeing with your setup.

I’d also suggest trying on a new SD card just to rule that out, too.

On Wed, Feb 21, 2024 at 8:16 PM richterlevania3 @.***> wrote:

I'm trying some different builds today to try to reproduce.. could you let me know if you are running a pi zero 2w with 32bit lite bookworm? If not, I would suggest reflashing a SD card with that install and working from there. From what you are describing, it sounds like memory issues.. I have seen that kind of corruption happen when my unit is tapped out of memory. But more often in the 64bit or desktop installs on a pizero2w, or on an original pi zero. Also could be something in my code causing memory leaks. Anyway, it could be memory issues... or something else entirely. I'm trying a fresh install on 64bit lite just to see. edit: also, I get display corruption like that if I push my overclock settings too far. Not sure if you are overclocking or just running stock, but worth mentioning here in case anybody else takes a look.

Sorry for the delay. I'm using the Rpi Zero 2 W with Raspbian 32bit lite. It has 1gb of swap file, so I'm pretty sure memory is not an issue. I will update the clone today and see if it improved.

Thanks! Same as my config then. bookworm?

I think IF your unit is using swap file, that could be causing some issues.. because the swap file from SD card speeds might be too slow for the speed of the SPI driver. But I don't think your pi will be using swap in any case, your setup should be fine with plenty of memory to spare. So maybe this is not a memory issue after all.

but, just for comparison, here is my "sudo free -m" when zerowriter is running:

           total        used        free      shared  buff/cache   available

Mem: 426 68 181 0 176 304

using 0 swap

Sorry for the delay. I'm using a 1Gb swap file now, but it was the default 100Mb before.

Just checked again and nothing changed for me. Still the same issues as before. Just to be sure, I deleted everything on the Rpi and downloaded again. I'm attaching a picture of how it looks like.

WhatsApp.Image.2024-02-21.at.22.10.06.jpeg (view on web) https://github.com/zerowriter/zerowriter1/assets/12630253/0cc8a990-092c-4b7e-bbdf-3cb4e6970138

— Reply to this email directly, view it on GitHub https://github.com/zerowriter/zerowriter1/issues/10#issuecomment-1958486604, or unsubscribe https://github.com/notifications/unsubscribe-auth/BEN2POUYBCQXFM25Q4DQTALYU2MAHAVCNFSM6AAAAABDLJGJQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJYGQ4DMNRQGQ . You are receiving this because you commented.Message ID: @.***>

[richterlevania3]

After some weeks I got to tinker with it again. Cloned the repo and the same issue persists. This time I made a video to make it clear how it's happening. See it here

Just to see if this contributes to the issue, I must say that I power my RPi through the data USB port. The power-only port got fried because of a bad USB cable. I am pretty sure this issue was already present before I fried that port, though.

Thanks for the hard work and cya.