Should the MicroPython interpreter for Inky Frame set HOLD_VSYS_IN high?

Discussion
1

There’s now a dedicated Pimoroni MicroPython version for the three Inky Frames. The first thing a MicroPython program has to do is to set HOLD_VSYS_IN to an output in high state to ensure the program continues running if it’s on battery power. It takes some time for this part of the code to run even if it’s placed first in a program. This is particularly noticeable with button presses to wake the device where overly long, awkward presses are needed when asleep.

If HOLD_VSYS_IN (GP2) was set to a high output in the dedicated Inky Frame MicroPython interpreter as early as possible then this would make the Inky Frame appear far more responsive to button presses in a deep sleep. It would also reduce the minimum length of the pulse required on EXTERNAL_TRIGGER to wake the device. I don’t think there would be any side effects from this? The program could, of course, change it back to an input later when it wanted to go to sleep on battery power.

2

Strange thing is, this seems to actually happen (if I read the board-init code correctly). And for CircuitPython I know for sure that it happens because I know the code and in CP I don’t have to set this pin high.

Nevertheless, even with CP it really takes a very long time for the system to come up. So there must be additional reasons for that.

3

This is good news, I hadn’t realised this feature had appeared. I agree it looks like it was added in 43ef76b (a comment in the code about what it’s doing would be helpful here):

void runtime_user_init(void) {
    gpio_init_mask(PICO_WAKEUP_PIN_MASK);
    gpio_set_dir_masked(PICO_WAKEUP_PIN_MASK, PICO_WAKEUP_PIN_DIR);
    gpio_put_masked(PICO_WAKEUP_PIN_MASK, PICO_WAKEUP_PIN_VALUE);
}

I’ve just tested by tapping a button really quickly on an Inky Frame 4" and it does respond to it.

The second issue here is the need to read the button state early on too. By the time the MicroPython program runs it can no longer see which button was pressed for a brief press. Is anyone aware of any discussions about this? It just needs to read the state from the shift register early on, store that value somewhere and make it available to the MicroPython program somehow.

A third issue is it would be nice to be able to determine which Inky Frame is in use to be able to write code to set up the display for any of the three models automagically. I think this can be done with some testing for the external resistors with internal pulls on SWITCH_LATCH (GP9) and I2C_INT / PSRAM_CS (GP3). Would be nice to do that early on safely and hide the murky detail from application programmers.

4

I think second issue might be dealt with by use of get_shift_state in wakeup in inky_frame.py. I think I spotted some bugs in there too: GitHub: pimoroni/pimoroni-pico: Some inky_frame functionality looks broken due to bit order confusion

I’ve coded up some pull down tests to determine the Inky Frame model automagically and will share code after some more testing. Pasted the code into What's best way to determine Pimoroni product from MicroPython? - #5 by kjw