Add serial VCOM inversion for Nice! View

[galaxyeden]

PR check-list

• Branch has a clean commit history
• Additional tests are included, if changing behaviors/core code that is testable.
• Proper Copyright + License headers added to applicable files (Generally, we stick to "The ZMK Contributors" for copyrights to help avoid churn when files get edited)
• Pre-commit used to check formatting of files, commit messages, etc.
• Includes any necessary documentation changes.

This is as requested by @petejohanson in zmkfirmware/zephyr#54 and will resolve the DC biased state Nice! View displays were previously in. VCOM inversion thread priority is set to 11 to keep priority below most other threads and prevent latency. Command interval is set to 17ms as a rough approximation of the 60 Hz VCOM toggle frequency recommended by Sharp in the display datasheet for the similar LS013B7DH05.

cc// @Nicell
edit history – changed interval because I'd misunderstood the datasheet

[petejohanson]

@Nicell Can you please test and report results before I merge?

[Nicell]

I’d like to test this locally to see how it impacts power usage. Have you done any tests? I can get back with my results.

[galaxyeden]

@Nicell – I've done some testing, but on an nRF5340 and with a larger Sharp memory display. The power consumption increase is noticeable but still in the tens of uA – this is Sharp's recommended setting, thus why I used it, so it should be within datasheet spec.

Higher values will reduce power consumption some but result in noticeable flicker, so I'd recommend sticking with Sharp's datasheet recommendations, with a note that the value can be increased to lower power consumption or decreased to reduce flicker.

[Nicell]

Here's my test results with nordic PPK2 set to 3.8V powering a nano through VBAT rail on a connected peripheral Lily58:

All in average draw across ~30 seconds

ZMK v0.3: ~110uA
ZMK main: ~170uA
This branch: ~210uA
1000ms interval: ~170uA
17ms interval: ~250uA

The datasheet for the display used on the nice!view calls for a 60Hz inversion frequency resulting in a 30Hz COM frequency, so technically 17ms is the correct value if I understand the driver change correctly (interval of flips, not COM frequency). Under the test conditions above looks like each additional interval Hz, we spend on average ~1.3uA more.

I'm going to sleep on it and will come back with the direction I personally think we should go.

I also think it may be worth investigating what is causing the power usage increase from v0.3 to main. Curious if anyone might know? I haven't kept up with things recently but happy to dig in on that.

[galaxyeden]

Hi @Nicell that looks very similar to what I remember from when I did this – that's about a 40uA increase and I remember it being in 10s of uA. I think my results were a bit lower, likely due to the nRF5340 being slightly more power efficient.

Looking at the datasheet for the LS013B7DH05, the display my keyboard uses, you're completely correct to say 60 Hz – I don't know why I had remembered 30. I can see arguments two ways on this:

• Increasing the interval saves power but increases flicker. Since balance will be maintained over time, it's unlikely to be harmful – and certainly is far less harmful that the current state most people are in of constant DC bias that will lead to early failures + reduced contrast and image retention. Given @MickiusMousius did some testing where they were able to reverse visible loss of contrast and image retention on panels that were in use for many months, I believe that as long as it's being inverted roughly equally it should be "fine". On this basis, I'd keep 33 ms or, if the flicker was objectionable to too many, consider 22ms (about 45 Hz, which is the longest I've found the flicker is hard to notice except in direct light).
• The other argument is use 17ms to stick to the datasheet. People can change it to save power if they want.

I think anything longer than 33ms is too objectionable in flicker to save 10s of uA unless someone really wants to push battery life.

[Nicell]

I think 33 is a good compromise to merge for now. Thanks for the thoughts!

[galaxyeden]

Have force pushed back to 33 @Nicell

[joelspadin]

I think this should be LS0XX_VCOM_THREAD_PRIO?

[Nicell]

I fixed this on my tests in the above comment, although it's probably not very relevant for power usage.

[galaxyeden]

oops, I'll fix that – I didn't have a Nice! View to test and I typoed it – to explain, I had a different Kconfig symbol name in my own driver before I PR'd it to Zephyr with a more descriptive name, and I guess my brain autocompleted that!

[galaxyeden]

And that's fixed, sorry about that!

[galaxyeden]

Force pushed to 33ms inversion interval, this is half the Sharp recommended rate so will have a slight flicker, but is the compromise discussed above with @Nicell

[galaxyeden]

I've actually just ran into another issue testing this, if the bus isn't available in time, the driver will drop the frame, but combined with the low priority it's possible for a screen update to simply get missed since ZMK isn't constantly sending new frames. I think this is a minor issue compared to the risk of not running VCOM inversion, but I'm trying to think of the best option – if there is a constant flow of new frames, as in an animation, letting a frame get dropped is better than a backlog of updates.

The likely best option is to make it configurable in Zephyr how long to wait for the bus before dropping a frame, and if combined with lowering the thread priority, increase the value. Higher thread priority than 11 may make sense, but it definitely needs to stay below the default input priority of 5 to prevent latency in any config. I'm going to test with a priority of 7 and report back.

Update after further testing – a 33ms inversion time makes this happen extremely rarely. Increasing the bus wait doesn't actually help, when this does happen something else seems to give up first. Most likely a true fix would be looking at the ZMK display code to ensure a frame can't get lost when there's bus contention, but for now this is sufficient – it prevents a potentially hardware damaging issue at the cost of possible occasional glitches due to lost frames.