@bricox while I like the idea of using a smaller package, I think the ESP32-S3 is a better choice - it's basically the same as the ESP32-S2, however, with added bits that would be quite important for some of the possible applications of the M5Paper, including: SDIO (the S2 has no SDIO interface according to the docs), secure boot and flash encryption, and of course the S3 is dual-core instead of single-core, has larger internal memory (S2 has 320kB SRAM, S3 comes with 512kB), Bluetooth (the S2 is WiFi only)... Overall the S3 is a better package for a solution that needs to provide a bit higher performance and wider range of applications.

Also, the package you're quoting has considerably smaller flash and PSRAM. The M5Paper comes with 16MB of SPI flash, and 8MB PSRAM - 4x as much as the quoted package. I think it's a good trade-off for slightly less space on the board, and a handful less pins. The LilyGO T5 4.7 made the display work with a shift register, while still having the necessary pins available for external ports.

The reason why I'd like to see an update to the M5Paper is simply because of this revision's design faults. An ESP32-S2 would be a massive downgrade, and it's not something I'd like to see in a revised, upgraded version that fixes a number of issues, only to bring in a handful of limitations and setbacks.

Looks good so far!

If you want a full UI framework, though, I think MicroPython is the better option, for the simple fact that you can push "apps" (technically Python applets) without the need of reflashing the device. I think the Odroid guys did some weird hackery with the Odroid GO where they use the OTA partition layout, have a "launcher" firmware on factory, and put the ROM/app to be run in ota_0 and ota_1, set the boot flag, and reboot. But with MicroPython you don't even need to do that - you can run the scripts from SPIFFS, or from an SD card, without much trouble.

MicroPython has the downside of having no generic UI library available, whereas for C/C++ you have plethora - there's GxEPD2 (which already has a base IT8951 implementation! One just needs to make a copy of that, change the pins, VCOM voltage, and it's good to go), LittlevGL, and of course Adafruit's TFT library. All of them are much, much better options than the hacked-together M5EPD base, unfortunately.

After spending about a month tinkering with the M5Paper, a handful of shortcomings in the design have become apparent. This wishlist is what I would like to see in a future iteration of this otherwise great little device.

The first point I'd like to address is the core being used. While the ESP32 module used is fine for most purposes, Espressif has announced the ESP32-S3, which, among the upgraded cores, brings a few new features, most prominent being the built in USB stack. This would allow dropping the serial adapter chip, and using the MCU directly for USB functionality, including flashing, and even allowing the device to act as a USB peripheral (or host, for e.g. a keyboard, though power supply could be an issue).

The second point is power management. I don't want to 💩 on your work, but the M5Paper clearly received a less favourable treatment than the other M5 cores. Power supply is unnecessarily overcomplicated, and the design results in very little control over the power systems, and down the line, massive power drains unless the developer implements drastic limitations. Even the deep sleep mode of the ESP32 is drawing too much power, due to the choice of eink and touch driver (well, with the touch driver, the main issue is not having a separate power switch). Due to this, I'd like to see the return of the AXP192, which was proven quite capable in the M5Stack Core and M5Stick series. It's managed over I2C, provides better power management of components, better battery support (not to mention proper reporting of charging/discharging state and battery voltage/life reporting), and overall a better option for the overall power management. I believe it also provides drip charging, which would be crucial to extend the battery life when it's mainly mounted to a continuous power supply.

Third point is the eink driver. While the IT8951 is very capable, it was not designed with battery operated systems in mind. I've read multiple reports, not just on the M5Paper, but on various Waveshare units that also use the IT8951, that its low power/hibernate modes are unusable - the chip actually draws more power hibernated than it does in standby, and it's not a negligible amount (around 120-130mA). While this is fine for a mains powered project like a Raspberry Pi, it won't work well in the M5Paper. If I understand it right, the IT8951 basically obfuscates the waveshape messaging part of the eink protocol, providing a more manageable solution, at the price of considerably higher power usage.

The touch driver, that I'm actually happy with. The only negative I can say is that it has no separate power management, and such it cannot be disabled when not needed. With the AXP192, that should be doable, though.

Fourth point is the temperature/humidity sensor. Its unfortunate placement makes it practically useless - the proximity to the battery and the rest of the board makes temperature readings unreliable when the ambient temperature is lower than the internal temperature, unless the device was freshly powered on. The humidity sensor works, but due to the restricted airflow, which opens from the back, makes its use quite limited. Instead, I'd recommend replacing it with a combined 9DoF sensor (accelerometer, gyroscope, and magnetometer), which could provide better everyday usage, for example, for screen rotation. Though the built-in magnet might interfere.

And if we're talking about power, I think a similar POGO pin connector as the one on the M5Stack FIRE's charger base would be beneficial. A four pin connector, with I2C exposed, and the power lines connected to the PMIC, would allow for custom docking bases (e.g. a wall mount with an I2C temperature/humidity sensor, for a tear-away smart home control panel and thermostat, or a desk mount for a ticker style display for e.g. temperature). The M5Paper is clearly meant to be a semi-permanent mounted solution - most of the time it would sit in a dock, but the battery would allow for temporary mobility, such as the previously mentioned tear-away console, which mostly sits in a wall mount, but allows the user to pull it off and use it e.g. as a smart home remote.

Also another power point - a separate coin battery for the RTC. I understand that the current solution uses barely any power, however I'd feel safer if the RTC had a separate power supply in the form of a replaceable coin battery. If designed well, this would provide years of supply for the RTC (a standard CR2032 easily runs a ZigBee motion sensor for 6 to 12 months), and separate the power concerns.

Last, but not the least, the side buttons. The current solution is, honestly, quite bad. I'd rather have either three separate buttons, or a button and a full rotary encoder, or practically any other solution that provides 3-4 inputs (one of them being an interrupt/wake signal for the PMIC and the ESP32).

Otherwise, the form factor and size are perfect. LilyGO came out with a similar board around the time the M5Paper was released, same eink display but different driver, similar touchscreen, and support for both 2-pin Li-Ion, and 18650 batteries (as two "separate" model - the only difference is the connector soldered onto the board). I'll be grabbing one soon, at least to compare it to the M5Paper. The fact that the touchscreen is only available separately, and it isn't packaged as nicely as the M5Paper makes it a harder sell, but I can see the advantage of the different design.

So, to list the overall changes recommended:

• ESP32-S3 instead of the current MCU
• Replace SLM6635 (ideally with AXP912)
• Replace IT8951 with a better option (maybe just a simple shift register, similar to how the LilyGO T5 4.7 solves it)
• Connect external components (eink, touch, each external port separately) to the PMIC for separate control of power
• Replace SHT30 with IMU
• Add a POGO pin connector for power/I2C, similar to M5Go
• Replace side button with a different implementation (either three separate buttons or a rotary dial and a button)
• Replaceable coin battery for BM8563

Have you tried installing the CP210x drivers from SiliconLabs?

@felmue that definitely sounds like a massive design issue - I wonder, maybe that's why the M5EPD library doesn't have any touchscreen power-off calls?

There was also a post on the M5Stack twitter recently, showing a blurred out image of upcoming devices, with a device eerily similar to the M5Paper taking up a large chunk of the photo: https://twitter.com/M5Stack/status/1357559621389479940/photo/1

I wonder if the design team realised these small issues and made a new board that is more fit for general usage purposes. It happened with the M5Cores (the Basic model had no PSRAM and the first units only had 4MB storage, which later got expanded to 16MB, then the Grey kit came with an MPU, then the Fire kit also included a microphone and PSRAM, among other changes), though the speed is much faster - I think there was almost a year between the Basic and Grey M5Cores, whereas the M5Paper was only recently released.

It does feel like a slap in the face for us who already bought multiple M5Paper units though - we've received a device that has a handful of obvious faulty design choices, and now we have to buy the new, updated model to get functionality that should've been working in the first iteration. Don't get me wrong, I'm happy for the updated design, I just hope there will be some discount for those who've already got units on their hands.

@felmue then how do you explain that charging voltage is 4.35V until the battery reaches 4.2V, when the charging voltage drops to 4.2V as well?

@felmue

I think the touch screen interrupt already is connected to the ESP32, eg. TOUCH_INT which is connected to GPIO36 of the ESP32 according to the schematics. Or am I missing something?

It is, but once the M5Paper goes to deep sleep via power cut (M5.shutdown()), the touch panel is disabled, thus it cannot wake the device up. I see now why my comment might have been slightly misleading.

@rahulthakurms Are you running the FactoryTest firmware? If yes, go to the test page while charging and watch the battery item - it should show ~4.25V while charging. Then unplug the charger and check what the voltage drops to. Around 3.5-3.6V the battery is basically discharged completely. The percentage calculation of this firmware is quite simplistic (linear relation between voltage and percentage, which is mostly incorrect - you'll see that under the same load, the first 10% drop, i.e. 100% to 90%, will take roughly twice as long as, say, 30% to 20%).

@Zontex I hope all these issue reports are logged for future reference for a V2 of the M5Paper. We definitely need a better charging IC, and a simplified circuit of voltage regulators to reduce power consumption in deep sleep mode. Possibly even a switch to a PMU that supports digital control. And of course better power control of the components (e.g. turning off the touch screen, or at least hooking it up to an interrupt on the ESP32). The current implementation of the M5Paper feels a bit rushed and untested, closer to a v0.4-0.5 than a v1 release.

You could use the EEPROM to store the state in - e.g. last time the device went to sleep, last time NTP sync happened, etc. - and use that to decide which path of logic you need to follow.

For example, this could be the full flow:

setup():

1. Get EEPROM, extract last NTP sync (last_ntp_sync), last boot time (last_boot), and last requested sleep length (sleep_duration)
2. Get RTC time (rtc_time)
3. If last_ntp_sync is empty, go to first_boot()
4. If last_boot is empty, go to first_boot()
5. If rtc_time - last_boot < sleep_duration (maybe add some wiggle room here, 1-2s should be fine), go to manual_wakeup()
6. Otherwise, go to rtc_wakeup()

first_boot():

1. Connect to WiFi
2. Request date and time from NTP = new_rtc_time
3. Update RTC with new_rtc_time
4. Update EEPROM's last_ntp_sync and last_boot_time
5. Proceed to draw_clock()

rtc_wakeup():

1. Check if last_ntp_sync is not too old (e.g. you'd probably want to sync with NTP daily)
2. If last_ntp_sync is too old, go to a method that syncs RTC time
3. Update EEPROM's last_boot_time
4. Proceed to draw_clock()

manual_wakeup():

1. Do the whole NTP check dance again (probably worth organising into a separate method)
2. Do whatever you want to do if the device wakeup happened due to the button press
3. Proceed to draw_clock()

Obviously extend it to your liking, but by storing these values, you can compare the last stored date with the RTC time, and act accordingly. It's not as elegant as e.g. having a proper boot reason, but it works.

@sambartle the battery voltage increase is actually because of the charging - the PMIC reports the charging voltage, and without the load of running the M5Paper from battery. Just by using the battery instead of an external power source, voltage can drop by 0.1-0.3V as well. The PMIC in this device is incredibly dumb, and some of the features (e.g. the charging/charged indicators) aren't even hooked up.