search

joukos / PaperTTY

PaperTTY - Python module to render a TTY or VNC on e-ink
942 stars 101 forks source link

EPD2in13v3 #90

Open l0d0v1c opened 2 years ago

l0d0v1c commented 2 years ago

Is there a way to add EPD2in13v3 ?

joukos commented 2 years ago

Sorry for the late reply. Basically any driver can be added by adapting the manufacturer's sample code, but it would be much preferred to also own a unit for testing that it works.

I don't happen to have one of these myself so it's unlikely I'll have a shot at it anytime soon, but PRs are always welcome. Implementing a driver is usually fairly simple, depending on the readability of the sample code.

cajuncoder commented 1 year ago

Sorry for the late reply. Basically any driver can be added by adapting the manufacturer's sample code, but it would be much preferred to also own a unit for testing that it works.

I don't happen to have one of these myself so it's unlikely I'll have a shot at it anytime soon, but PRs are always welcome. Implementing a driver is usually fairly simple, depending on the readability of the sample code.

I also just bought a waveshare 2.13" display for the sole purpose of running PaperTTY, only to find that it's not supported. I think any 2.13" display you buy these days will be v3.

How straightforward is it to write a driver? I'm not familiar with writing drivers for SPI devices or in general, nor am I familiar with the project. And, I have extremely limited free time. But if you can point me in the general direction I might like to have a go. What files should I look at in the project, and what sample code specifically are you referring to? I know, these are "lazy" questions but I could spend hours trying to make heads or tails of these things...

I'll be happy to give it a shot if I find the time and/or know where to start.

joukos commented 1 year ago

Generally it's (been) pretty easy to write a driver for some particular display because Waveshare at least has example code available usually in both C and Python at least, and they're pretty simple and straightforward, so in many cases the driver code in PaperTTY even retains the redundant "line per byte sent" approach.

To implement a driver based on the official example code basically amounts to making sure the same bytes are written in the same order in the driver code as in the example code. You could even start with a copy-paste from the official code's equivalent functions, such as drawing to the display and shave the extra so it does the same things when PaperTTY calls its draw or init etc. methods. Then it should basically work.

That said, the current implementation of drivers could be improved a huge amount.

joukos commented 1 year ago

For example, here's the https://github.com/joukos/PaperTTY/blob/master/papertty/drivers/drivers_partial.py#L265 "Waveshare 2.13" V2 - monochrome" driver - note that only thing needed there were the tables specific to that display. It could be that you only need to compare if those bytes match the example code and if there's any difference otherwise. For example in the wait_until_idle method some displays set a bit and some clear it when it's done so if that's wrong, it might just seemingly do nothing since it's sitting in the loop.