Misc hardware notes

[jamesmunns]

Here's a list of things that I've found while doing (a little bit weird) bringup for supporting my mnemos project.

• The display VCOM toggle pin is connected to the Pi Zero, not the RP2040. This means that the RP2040 cannot persist the image on the display while the Pi is off. Being able to drive the display AND the VCOM from the RP2040 would be good, but at least with just VCOM, the RP2040 could persist the last drawn image from the Pi during deep sleep. Sharp's documentation, the "VCOM" section discusses this
• There appears to be parasitic draw to the Pi Zero even when Q1 "Pi Power" mosfet is disabled. I believe this is caused by the 2x4.7k and 1x10k 3v3 pull-ups on the i2c bus. This could cause a few mA of draw, and probably isn't great for the attached hardware to be idling at a few volts (1.7v seen on the 5v0 rail on an MQ-Pro). This could be fixed by adding another mosfet between the 3v3 rail and the pullup resistors, so this could be cut with the same signal as is used for Q1 today.
• The FDX0019B1 "pogo" pins are not compatible with some boards, such as the MQ-Pro. I needed to design an adapter board to handle this. I could not find a datasheet for these, but it seems that 1.0mm PTH diameter works well (and the MQ-Pro must be smaller than this). It would be nice to use "real" spring loaded pogo pins in the future, for better compatibility.
• There have been issues with the TPS boost regulator failing short. It might be good to put a 1.0/1.5/2.0A polyfuse on the input power (between battery + vusb and the TPS)

[jamesmunns]

The first item is somewhat important to address:

When designing with a memory LCD panel, a decision must be made as to how VCOM will be generated. VCOM is an alternating signal that prevents a DC bias from being built up within the panel. If this DC bias is allowed to accumulate, it will eventually reach the point where the state of the liquid crystals in the panel cells cannot be changed by the panel electronics and the cells will no longer change state.

They aren't super clear if this is a "physically damages the panel" or "needs a power reset to clear the stuck pixels"

[markatlnk]

The Raspberry Pi Raspian OS supports a real time clock. The DS1307 is cheap, I would put in a separate 3.3V regulator for it directly off the battery. Power consumption would be really low. Even if you decide not to populate it, it should work fine off the I2C buss. It would need a 32,768 crystal and a couple of caps. Next spin of the board could put the pads on there at no extra cost and let people populate it if they wanted to.