Nothing displayed on E-paper

[mgpepe]

Hi,

I am trying to display a test code on my new e-paper, but nothing comes through. Can someone help me?

I have the 10.3" with the driver board.

There is no code for python, so I am using the epd_7in5_test.py to dislpay something, but nothing comes up. Debug logging shows all logs pass through until the end, so I know we don't get stuck somewhere on the busy signals.

Also, the display updates with IT8951 example C code. So it is well connected and it works.

Any help will be greatly appreciated!

[Duologic]

I was stuck on this problem too, the symptom is running the epd_7in5_test.py program and getting stuck on e-Paper busy.

For me it turned out to be a hardware problem, the connection of the flat cable was not in the right order, the blue sides need to go up from the pHAT to the adapter and the adapter needs to face up to the front of the screen. See photo for reference.

Referencing related issues to get this solution out there: #29 #30 #42 #76 #80

[dankarlin]

hey @mgpepe were you able to solve this? I have the 10.3 too, working great in C but getting good looking logs and no display changes with Py code.

[aming]

Finally, I workaround it by connecting the HAT to Pi board with the 8pins.

[kiasarecool]

I am having the same issue on a 7.5" V3 Red/Black/White e-paper display, I tried the cable flipped as you suggested but still no luck, the driver board I have is Rev. 2.2

[madscientist42]

If you're using a HAT edge, try using the breakout lines/cable. Odds are good that the issues are the same ones as described in the following link: https://www.martinhubacek.cz/blog/waveshare-epaper-hat-issues/.

They wired 5V to the wrong places and it's very clearly a 3.3v edge config if you look at the breakout header lines. It will sit in Busy indefinitely on at least PART of their product line. It's very clearly a FUBAR on their part with the 2.13" monochrome panels.

While HATs are nice, they seem to have botched at least the V3 configuration and BADLY at that. Was pulling out bald spots on my head trying to figure out WTF was going on. Once I saw the linked, had a small batch of foul language come forth, and then hooked up the breakout cable's pins to the PI GPIO lines...the demos at least work now.

Will hesitate on their products. I'll be making actual framebuffer kernel drivers for the chipsets I've figured they've done here, but I'm going to be...cautious...with purchases from them going forward. (Why framebuffer drivers...? Consistent interface that spans the panels properly...)

[kiasarecool]

If you're using a HAT edge, try using the breakout lines/cable. Odds are good that the issues are the same ones as described in the following link: https://www.martinhubacek.cz/blog/waveshare-epaper-hat-issues/.

They wired 5V to the wrong places and it's very clearly a 3.3v edge config if you look at the breakout header lines. It will sit in Busy indefinitely on at least PART of their product line. It's very clearly a FUBAR on their part with the 2.13" monochrome panels.

While HATs are nice, they seem to have botched at least the V3 configuration and BADLY at that. Was pulling out bald spots on my head trying to figure out WTF was going on. Once I saw the linked, had a small batch of foul language come forth, and then hooked up the breakout cable's pins to the PI GPIO lines...the demos at least work now.

Will hesitate on their products. I'll be making actual framebuffer kernel drivers for the chipsets I've figured they've done here, but I'm going to be...cautious...with purchases from them going forward. (Why framebuffer drivers...? Consistent interface that spans the panels properly...)

Think it could be fried? I just tried with the gpio wiring and still no lick. I Tried 3-line spi and 4-line spi with both config options 3r and .47r

[madscientist42]

It's probably fried. I went and moved to the GPIO wiring and my Linux framebuffer driver code even works. Make sure you look on the board side of the display. Should be a sticker on there. It will tell you which "version" the product is. Right now, if you're using the wrong "version" it won't work right at all either.

The plus with what I'm doing is that hopefully, we can normalize at least the Linux support around something clean. What Waveshare did with all of this is heinous and didn't need to be so. You can have a SINGLE version of library code that isn't the way they did things there. This is primitive. Novice programmer primitive. It won't initially help the Python users unless they're on Linux (Just use a normal FB library in your Python code, then...) but it should hopefully provide a crib-sheet for normalizing this mess when I'm done.

Right now, I'm supporting full update operations against a framebuffer correctly (Deferred I/O support ROCKS. It lets me schedule a render pass that happens number of seconds into the future of the FB ops, so you don't do more updates than you need to and it is kind of transparent to your application code.)- working on partial updates now. Once done, I'll try for multi-color (red or yellow support would rock.)) In the end, there should be rather one set of code for each class of part. The reason for this is that the device has roughly the same part for the EPD control. It's a Solomon Systech SSD1680 or a close enough clone of it to count. In the large, it's all really timing differences between the versions. That means just a different LUT and a few other table driven things. Why you'd do this mess they did is beyond me- and worse, it equates to major code changes regardless of which environment (Arduino/Baremetal or Linux) that you're using. Many complaints on Amazon about them quietly moving to a V3 model and not telling people and needing to change "drivers" because of these. As it stands, once I get a few more things done and clean up the work (It's got their hard-codes in the mix without explanations...it took an Engineer looking at their code, the two failed attempts at making a good driver, and scrounging through vendor IC spec sheets to spot the real details there. There's surprisingly few vendor ICs in the EPD space...) Since all of the EPD devices in this space basically use Solomon Systech parts, it's going to be easier to basically fix the problems and have mostly a one-stop shop. Where it's not a Solomon Systech part, the other vendor is USUALLY stated (Adafruit's good about this...) and a driver/library can be done for it as well.

Once you have a driver that understands the timings, including the LUT, which is another timing behavior specification, and handles those, the chips are the...heh...same. So, very, very many of these can really be a one-stop shop.

On Thu, Sep 1, 2022 at 4:56 PM kiasarecool @.***> wrote:

If you're using a HAT edge, try using the breakout lines/cable. Odds are good that the issues are the same ones as described in the following link: https://www.martinhubacek.cz/blog/waveshare-epaper-hat-issues/ http://url.

They wired 5V to the wrong places and it's very clearly a 3.3v edge config if you look at the breakout header lines. It will sit in Busy indefinitely on at least PART of their product line. It's very clearly a FUBAR on their part with the 2.13" monochrome panels.

While HATs are nice, they seem to have botched at least the V3 configuration and BADLY at that. Was pulling out bald spots on my head trying to figure out WTF was going on. Once I saw the linked, had a small batch of foul language come forth, and then hooked up the breakout cable's pins to the PI GPIO lines...the demos at least work now.

Will hesitate on their products. I'll be making actual framebuffer kernel drivers for the chipsets I've figured they've done here, but I'm going to be...cautious...with purchases from them going forward. (Why framebuffer drivers...? Consistent interface that spans the panels properly...)

Think it could be fried? I just tried with the gpio wiring and still no lick. I Tried 3-line spi and 4-line spi with both config options 3r and .47r

— Reply to this email directly, view it on GitHub https://github.com/waveshare/e-Paper/issues/79#issuecomment-1234823162, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKF6CK2AYRU2EYMAT67ENLV4EQ7NANCNFSM4N5FMUZA . You are receiving this because you commented.Message ID: @.***>