[M5Paper] Ideas/recommendations for a revision or V2 model
We can also replace the MCU IT8591 with a low power MCU as STM32L0 or STM32L4 family and keep le SPI bus.
felmue last edited by
currently the INT line from the touch IC is connected to GPIO36 of the ESP32. This is a poor choice for two reasons:
- GPIO36 is an input only GPIO, but to put the touch IC into sleep mode the ESP32 needs to be able to drive and control the touch INT line.
- GPIO36 (and GPIO39 for that matter) produce 'ghost' inputs if used as interrupts and WiFi is in use with a power save mode enabled. (This is a hardware limitation / bug of the ESP32.)
Thank you for listening.
@bricox yep, did some research and realised how the shift register can be used in place of the controller. Not sure if it's a definitely better solution. However I like your idea of using a smaller, more power-efficient MCU, especially if it has some deep sleep mode with quick wake.
I was also wondering - the IT8951 schematic shows that internally, it's a RISC-V microcontroller with a bunch of attachments (USB, I2C, SPI and SDMMC host interfaces). It also supports (apparently) firmware upgrades. I could not find any sources unfortunately, but, in theory, if we had those sources... Would it be possible to write a more optimised version of this firmware, one that would reduce the power usage? Obviously we don't even know what kind of RISC-V core it has, if it has any low power modes (though the fact that a "sleep" mode is supposedly implemented in it would suggest that it is capable of some sort of sleep mode, the data sheet even details what is powered and how in which state), and so on. Sadly the only documentation we have on this chip comes from an early draft (v0.2.x.x, from Waveshare), and even M5Stack decided not to attach this datasheet to the documentation. I can't help but wonder if they even got the firmware source and build environment, even if under an NDA.
fonix232 last edited by fonix232
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.
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.
In my professional activity, I use the STM32L476.
Its average power consumption is 15-20mA at 80 MHz.
I use "Stop 2" mode to reduce consumption => 2.3µA (5µs wake-up with many sources).
In addition, it has its own RTC with calendar and the ADCs are most linear than ESP32.
USB-TYPEC/NC is not a real USB port because no bridge.
The connector is USB-C but the line is UART only.
@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)?
My apologies, I don’t know how I made that big mistake ... ;>)
You’re right, it’s definitely a native USB.
The red symbol is, for me, that printfoot USB-C connector is on the pcb but not welded.
This part of the schema is not completely greyed out as J10 because the 2 resistors R1 and R60 are welded.
The Google search with this image did not succeed.
You’d have to look in the symbol library of the design software, I think it’s Altium...
@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).
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?
@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.