@m5stack it's been 3 weeks, without even a confirmation that you've read the issue. Could we please get an update? Or maybe @Zontex, you could bug someone at M5 HQ, since you seem to be more active.

This does not need a "revision" or "V2" model, it's a simple software addition. And you can already load your own fonts if needed.

A reset will trigger a power cycle, which in turn resets the SPI connection to the e-ink display. The display has a controller built-in, which at this point is also power cycled, and most likely runs the initialisation of the screen. So when you press the reset button, the display thinks it needs to get into a "ready for new data" state, which is why it "fades".

If you want to work this around, I'd recommend storing the screen contents every time you write to the screen, to storage that is preserved during a power cycle (basically, dump that 200x200 4b array onto the flash), and make sure that your startup handling "updates" the screen with that content immediately after the device is initialised.

Recommendation: use GitHub (or similar) to host your code, not Google Drive :) It makes things easier to read through quickly, plus people can make pull requests to improve the code.

Okay, so ITE came back to me regarding the IT8951 things. Unfortunately they do not offer the source code directly to developers, only to business partners - and that's M5Stack themselves. @m5stack could you please give us some details, or if the NDA allows, release parts of the IT8951 firmware?

@bricox The same red symbol appears on the Waveshare schematics for the IT8951 Pi HAT, in the same place (although the M5Paper schematics have the symbol on both the IT8951 and the USB port side, whereas the Waveshare one only has it on the USB port). And based on the second page of that PDF that shows the exact traces, there's nothing between the IT8951's pins and the USB port, just the trace. No resistors, capacitors, nada.

Nonetheless, in my opinion, that USB port could be "easily" soldered in (by someone who knows how to solder properly, i.e. not me), and used to directly communicate with the IT8951, and power the device in the process (the voltage line of this port is also hooked up to the PMIC, just like the main USB port).

@bricox based on the documentation, it should be possible to set the touch panel in a gesture recognising mode - would be nice to be able to offload that from the ESP32, alongside the interrupt-instead-of-poll change. This would certainly improve battery life.

@bricox are you sure about that USB-C port? Because according to the schematics, it goes to the USB lines of IT8951 (IT_DBG_P and IT_DBG_N, pins 52 and 51 on the IT8951, which matches the official IT8951 documentation - the Waveshare adapter board also connects those pins to its USB interface), while the UART lines of it connect to a grayed out (presumably not in the final design?) 4-pin port called J10. As the IT8951 has a built in USB interface, and the default firmware (at least on Waveshare panels) even provides a UMS interface with custom, I believe SCSI, commands similar to the SPI protocol.

There's a red symbol on both the M5Paper and the Waveshare IT8951 driver board's schematics where the IT8951 pins 51 and 52 connect to the USB port, which I do not know the meaning of. Could you enlighten me?

@m5stack could we please get some information on the IT8951? Of course within your NDA limitations. Things like changes you've managed to its firmware (apart from the display specific things like resolution, waveform generation, etc.). Is it possible to modify this firmware to reduce power consumption, introduce the SLEEP mode that is apparently missing, and to update it without hardware modifications (i.e. is there a firmware update solution via SPI, or only USB)?

A kinda related, but strange question - could you please release the source code for the drivers of the various bits of hardware found in the UIFlow firmware? UIFlow is built upon MicroPython, and I would personally prefer to run a clean MicroPython build on a few devices of mine, however the lack of drivers makes it a bit harder than expected. I'm not interested in the UIFlow-related parts, just the low level Core/Unit/Module support drivers (e.g. for M5Paper, a driver for IT8951, a driver for the PMIC, SHT30, GT911). It would allow the community to build MicroPython images without proprietary code, and possibly result in faster updates as well. Plus, you could merge back community fixes into the official UIFlow firmware easily.

Also, my TTGO T5 4.7 arrived, finally. Overall, a nice piece, although a bit rough around the edges compared to the M5Paper. Overall, the PCB seems to be better designed, everything is nicely sectioned apart. But, LilyGO did bum it up, the EPD connector is just sliiiiightly further from the edge than the ribbon itself, which results in some twisting of the cables, and I'm not sure I'm comfortable with it...

One thing I'm extremely unhappy with is the battery connector. I opted for the 18650 model (the difference is literally just the connector soldered - with a J2 female connector and 5 minutes of soldering I could convert it easily, but I want to use it with 18650 batteries for easy battery swapping), and the metal wings are outrageously bad quality. They are too rigid, and the edges were not finished properly, and I managed to cut open the wrap of one of my cells on the first insert. This was with great attention paid to the insertion process, and ~3 hours spent on filing down the connector edges (don't worry, I covered the rest of the board with painter's tape, and blasted it with some compressed air to make sure no metal fragments linger around). I think once I have a finalised 3D printed case for it, I'll remove the connector and replace it with a homemade spring-loaded version.

Another, interesting thing I noticed while digging around in the guts of the M5Stack... Apparently, there's a second, unpopulated USB-C port on the board. None of the schematics mention it, and I can't really trace it, since the components are too tightly packed:

It's right next (or, in the orientation of the above picture, below) the SD card slot. I'm not sure if it's meant to be a power port only (though the fact the data lines are labeled makes me think it isn't), or if it's directly connected to the IT8951 (which would make sense, since that MCU has a built in USB interface, which allows controlling and even updating the controller).

On another note, I reached out to ITE and requested the release of the source code + dev environment for the IT8951 firmware. With any luck, we should have the sources soon, and maybe we can put together a better, less resource-hungry one, just to make the M5Paper that tiny bit better.

EDIT:

I've been going through the M5Paper schematic to check that USB port and also the USB hookup of the IT8951... First thing I noticed is that the schematic says the M5Paper is supposed to have the IT8951E-64, yet we only have the regular IT8951E.

However, I've found the unpopulated Type-C port on the schematics - no idea how I missed it the first time around. It's J8, labeled USB-TYPEC/NC, and its data pins are connected to the IT8951's USB OTG pins, plus the VUSB rail. Meaning that with a quick solder job, one could add a secondary USB-C port that would allow direct communication with the IT8951. With a custom firmware, we could coax that MCU to act as, well, any kind of USB peripheral. And who knows, maybe other stuff could be also offloaded to it. IF we can get the source code for the damn controller. And that's a very big if.