initial board definition for inky frame 7.3

[dearmash]

This doesn't work (yet) on my inky frame.

I've verified via the printf below that the startup commands match what's being sent in my micropython branch (which does work). I even went so far as to partially properly implement the busy pin that's hooked up via a shift register. It only affects the send command, I hope to eventually be able to change the other busy checks to support the new callback structure to remove all the "dumb timeout" refresh blocks.

Another thing, this display takes ~ 40s to refresh. It might be sensible to control whether or not _clear is called prior to _refresh. This way when the display does actually work, it doesn't take an unreasonably long time to display.

The board is implemented identically to the inky frame 5.3 that I branched from with the single difference of 7.3 adding PSRAM to the mix (replacing the i2c interrupt pin).

https://cdn.shopify.com/s/files/1/0174/1800/files/inky_frame_5_7_schematic.pdf?v=1664452062
vs
https://cdn.shopify.com/s/files/1/0174/1800/files/inky_frame_73_schematic.pdf?v=1677857184

[dearmash]

@tannewt Here's where I got so far with comment. Not sure what I'm getting stuck on.

[tannewt]

Here is the CircuitPython level driver I did with the waveshare breakout for the 7": https://github.com/adafruit/Adafruit_CircuitPython_ACeP7In/blob/main/adafruit_acep7in.py

I see a couple little differences in the sequences but it is mostly the same.

[dearmash]

Yea, the only difference is setting the screen rotation 0 (this) vs 180 (adafruit_acep7in). I'm not convinced that it's the sequence.

I'm a SW guy and only occasionally HW. I don't have scopes which would be ideal. I can only thing to add some printf debugging to the SPI / fourwire classes to make sure the pin and their settings are as expected. Just comparing more things from my MP fork that works vs the CP that doesn't.

Other than that, I'm really not sure what else there is to check, I'm sadly at a loss. Even to get this far has taken quite a bit of my "free" time. If you have thoughts for other ways to debug / pitfalls, lmk.

*edit I guess the one reasonable thing I could try is to load the vanilla picow CPY uf2 and load the adafruit_acep7in library in python land to try that out. I'll do that next to see where I get.

[tannewt]

I'm a SW guy and only occasionally HW. I don't have scopes which would be ideal.

Do you have any other RP2040 boards? You could try pysigrok to use them as a logic analyzer. https://github.com/pysigrok/hardware-raspberrypi-pico You may need to help me with the software though. :-)

[bablokb]

It might be sensible to control whether or not _clear is called prior to _refresh. This way when the display does actually work, it doesn't take an unreasonably long time to display.

That is exactly what we are currently discussing in #7797. The _clear itself is not the problem, but the wait (for what?) after the clear. You have 8s in the constructor, I use 2s and that works fine.

You might also want to integrate the parts of my PR that deal with the frozen modules and the keys and the power-control logic. Not pulling the power-control GP high in board.c prevents the system from coming up when in battery mode.

[dearmash]

I still think that the clear at least should be optional. There's really no reason to clear the display prior to displaying the desired image, except that it takes twice as long as it needs to.

BTW, re: the busy pin, I would also suggest that we consider the method override here. I have another eink display, it has a busy pin, but it's only set as a result of sending a "busy check" command. i.e:

is_busy():
  send_command(busy_cmd)
  digital_read(busy_pin)

[dearmash]

not convinced these should be in this order

[dearmash]

Here is the CircuitPython level driver I did with the waveshare breakout for the 7": https://github.com/adafruit/Adafruit_CircuitPython_ACeP7In/blob/main/adafruit_acep7in.py

I see a couple little differences in the sequences but it is mostly the same.

I tried the py library, it worked, so took the changes into the board.c and it's working just fine now. I'm not sure if it was the rotation, or moving the PON command. Don't care at this point, hard to argue with success.

I'm still motivated to get the epaper busy signal wired up properly. I'm not sure if in this PR or a follow up, but I'd like to try and expose the "keypad" as the shift register keys from the CPP side of things. I know @bablokb had already looked in to doing the keypad part in board.c but I'm not sure if there were any issues.

[tannewt]

I still think that the clear at least should be optional. There's really no reason to clear the display prior to displaying the desired image, except that it takes twice as long as it needs to.

I'm ok if you want to add a kwarg to make it optional. The code I was modelling after for Good Displays says it is needed so I did that here and think we should by default.

[bablokb]

I'm ok if you want to add a kwarg to make it optional. The code I was modelling after for Good Displays says it is needed so I did that here and think we should by default.

I would support this. I am running an InkyImpression (with the same display as the InkyFrame 5.7") for years now without the initial clear (update is once a day). The visual appearance does improve with a clear, but this can be done e.g. once a week from application code as well.

[dhalbert]

@dearmash is this stalled?

[dearmash]

As it stands, this does technically work.

Things that still need to be done:

• The busy pin is technically being read, but iirc it wasn't working as expected.
• There's PSRAM for this board that I didn't end up figuring out how to use, memory is really limited without it.
• Lists are best in threes, but I'm forgetting what else I wanted to do.

edit: With that being said, I'm not quite sure how worth it is to submit right now, "minimally viable" is where it's at.

[dhalbert]

Superseded by #8896. Thanks @dearmash!