DataSheet for Inky pHAT


#1

Hi,
I have one of the Inky pHAT and I want to use it on a NON Raspberry Pi, SBC and I cant use Python,

I need to get the Data sheets for the display to write my own c based driver for it. Can you supply the links from where I can Down load it from , I have looked at the e-ink website and the display they have seems slightly different.

I can probably reverse engineer the Python code but …
If you can point me to a ready made c library that would be even better but not critical.
Just the data sheets "Should " be enough

Thanks
William


#2

The driver IC is somewhat generic, so without knowledge of the specific settings and sequences used to make the display go you wont get anywhere with the datasheet, even with the best of intentions the permutations of possible settings are basically insurmountable.

Trust me when I say, that this is the most comprehensive and concise reference you could work from: https://github.com/pimoroni/inky-phat/blob/master/library/inkyphat/inky212x104.py

Note: While the data output stages look complex, they’re not so bad. I’d say you should ignore everything related to partial updates since they’re virtually useless (albeit you might think otherwise!).

These lines:

        buf_red = numpy.packbits(numpy.where(region == RED, 1, 0)).tolist()
        buf_black = numpy.packbits(numpy.where(region == BLACK, 1, 0)).tolist()

Are basically just finding every pixel that’s RED or BLACK, grabbing a 2d array with them set to 1 (on) or 0 (off) and then packing that into 8bit integers where each bit represents a pixel.

Note: the 8bit integers run along the shorter (104 pixel) axis of Inky pHAT. Each “column” (actually a row in Inky pHATs perspective) is 13 bytes wide, and the whole display is 212 columns.

I’m probably not explaining this well, but if you try and pack a 212x104 buffer into bytes without first rotating it you’re going to see really weird things on the display.

In the Python library the buffer starts off as a 212x104 2d array of ints, where each int can be wither WHITE, BLACK or RED. It’s then translated by the above into a 104x212 bit array, and packed into bytes.

In C, I’d probably store two buffers (one for RED, one for BLACK) of type uint8_t and have my set_pixel() method set or clear the correct bit so I didn’t have to do any transformation of the data.

What’s the SBC you’re using, by the way?


#3

Hi Phil,
Thanks for getting back to me so quick.

I have worked on similar displays in the past and what I was really concerned about was just as you mentioned the “Startup or initialization” sequence. And it is the _display_init() code that will help.

We are using a PSoC 4 chip from Cypress as the MCU and it is generally quite easy to port most things over.
I would like to get more information from the data sheets as to things like how far I can push the Partial refresh which I know will sow ghosting effects if a full refresh is not done at some point especially as on part of the display I would like to show the time ( including Seconds)
Also you wouldn’t know the Current draw difference between a Full refresh and a Partial refresh ( I assume the partial refresh current will depend on the area {number of pixels] being updated??? )

If you can let me know what Driver IC they are using it probably will help as I have most likely worked with it already .

Thanks again for you help.