M5Paper e-ink device for DIY

[stevenaleach]

Originally Posted by hobnail

Yes, they do a good job. I'm still thinking about making something using a waveshare e-ink display.

I just got another ESP-32 board from Amazon yesterday [Lolin D32 PRO, Micro-SD slot, 4MB PSRAM, battery management, lots of GPIOs] that will one-day power a larger screened companion for my M5Paper (if and when DigiKey ever delivers the dern Paper).

Since the pandemic has drastically reduced my work hours and cut my expendable income, I'm waiting on Congress to weigh in on exactly *which* Waveshare screen I end up using (the 7.8" versus the 10.3" one, both at 1872×1404) and how soon I get to order it ;-)

I'm seriously considering including a solar panel on the rear and an Adafruit solar battery charger, though that might be overkill (the Lolin board has *very* low deep-sleep current draw and will spend most of its time sleeping, being woken to turn the page every now and then).. but the idea of a nice reader that will always just work and NEVER need to be charged is quite appealing.

[hobnail]

I'm puzzled about the PSRAM on the Wrover. From what I can find on the internet it's only usable as data storage; i.e., you malloc it and shove stuff into it. At first I was guessing that it's nonvolatile ram but that doesn't seem to be the case.

[andyh2000]

How easy it is to read a JSON REST API and display it on the M5Paper with UIFlow (not my project, from https://twitter.com/simonvc/status/1363249199689715726)



Andrew

[stevenaleach]

Originally Posted by hobnail

I'm puzzled about the PSRAM on the Wrover. From what I can find on the internet it's only usable as data storage; i.e., you malloc it and shove stuff into it. At first I was guessing that it's nonvolatile ram but that doesn't seem to be the case.

It's just ram - the ESP32 has 520K internal ram, but can support up to 4MB external PSRAM. Consider that the M5Paper's display is 960x540 = 518,400 pixels.. so even at two pixels per byte, a single screen-buffer would take half the internal memory - so the extra ram's nice. Just like the main memory, it's lost in deep-sleep, but you've also got some RTC memory that is maintained in sleep (8K I believe?).

[stevenaleach]

Originally Posted by stevenaleach

It's just ram - the ESP32 has 520K internal ram, but can support up to 4MB external PSRAM. Consider that the M5Paper's display is 960x540 = 518,400 pixels.. so even at two pixels per byte, a single screen-buffer would take half the internal memory - so the extra ram's nice. Just like the main memory, it's lost in deep-sleep, but you've also got some RTC memory that is maintained in sleep (8K I believe?).

And if you're using Micropython, it's even more important. I've got an M5Faces (M5Core Grey) without any additional ram, and a Lolin D32 with 4MB PSRAM - There's about 64K of available memory on the M5Faces after booting Micropython, versus just over 4MB on the Lolin - which is a heck of a difference - without the extra memory, I don't think I'd consider Python practical - anything I end up doing with the M5Faces, I'll be doing in Arduino C, but for the Paper and the eventual Waveshare based reader, I can stick with Micropython and not run into any tight limits.

[hobnail]

I'm still unclear on how the PSRAM can be used. Can you load code in it and run the code from it?

[stevenaleach]

Originally Posted by hobnail

I'm still unclear on how the PSRAM can be used. Can you load code in it and run the code from it?

It's just ram. In Micropython you need do nothing special at all to use it - it's just available memory which will be allocated and used by your code. In Arduino C, you call ps_malloc, but what you get back is just a pointer like any other, it's just ram. As to whether it's executable memory you could put code in, I don't know - but for the most part you would never load code into RAM at all - your code will usually be in flash and thus doesn't occupy any of the available RAM - most boards (including the M5Paper) seem to have 16MB of flash.

So in Micropython:
----------------------------------------------------------------------------------------------------
>>> import gc
>>> gc.mem_free()
4096944
>>> bar = bytearray([0]*1024*750)
>>> len(bar)
768000
>>> gc.mem_free()
252224
----------------------------------------------------------------------------------------------------
So... there's some overhead for a byte array in Python, it seems, because creating the 750k buffer above uses over 3MB of memory... *BUT* it's also more memory than the ESP32 has internally, so that tells us that MicroPython is making use of the PSRAM.

In Arduino C: (https://thingpulse.com/esp32-how-to-use-psram/)
----------------------------------------------------------------------------------------------------
#include <Arduino.h>

void logMemory() {
log_d("Used PSRAM: %d", ESP.getPsramSize() - ESP.getFreePsram());
}

void setup() {
logMemory();
byte* psdRamBuffer = (byte*)ps_malloc(500000);
logMemory();
free(psdRamBuffer);
logMemory();
}

void loop() {}
----------------------------------------------------------------------------------------------------

So there's some C code that allocates and then frees 500,000 bytes of memory in PSRAM with ps_malloc - it returns a memory pointer like any other, you don't need to worry about whether it's in internal ram or PSRAM, it's just ram. Free it with free() when you're done - the same as if you'd allocated it with malloc().

So... in short, in MicroPython, there is absolutely nothing different about PSRAM as opposed to RAM. You don't need to worry about it at all. In Arduino C, you use ps_malloc() instead of malloc().... that's it, it's just ram.

Now in Python, if you're entering code at the prompt, the resulting bytecode will occupy RAM (whether internal, PSRAM, or a combination of both). But when you compile and upload C code, it lives in flash memory and doesn't use RAM.

[stevenaleach]

And... my Python example was terrible... the absurd overhead on the byte array came from creating a list first unnecessarily... so here's a less bone-headed example that just allocates 2MB of ram.... yay.. nothing special needed be done, it just allocates a block of memory roughly four times what the ESP-32 has on tap sans SPRAM.

>>> import gc
>>> gc.mem_free()
4096944
>>> buff = bytearray(1024*1024*2)
>>> len(buff) / (1024)
2048.0
>>> gc.mem_free()
1999216

[stevenaleach]

And here's a Reddit comment explaining PSRAM under Arduino:

"Yes, PSRAM is supported including in ESP32 Arduino Core v1.0.1 provided you choose a Board which has attached PSRAM in the Tools menu.

Replace any malloc() call with ps_malloc() and it will allocate the buffer from PSRAM instead of internal memory. That's the only thing you need to do.

If you want to go one layer deeper then ESP-IDF has a "heap capabilities" layer which lets you do other fancy things, but for most use cases ps_malloc() will work fine."

I notice that you have to select a checkbox under Tools in the current version of the Arduino IDE to enable PSRAM. I haven't actually tried using it yet, I'm still playing with MicroPython now that I've finally got enough memory to support it and have more than 64k left to play with.

[hobnail]

I'm old school and my knowledge comes from the days when code ran from either ram (DRAM) or rom. Typically code was loaded from a drive into ram where it was executed. Reading some of the Espressif docs it sounds like code is executing from the flash. My wee brain is having a hard time with that idea. Anyhow, I received my "Freenove Ultimate Starter Kit for ESP32-WROVER" today and it contains a cornucopia of devices and components, including the wrover. And I can't believe how clever Linux is; you just plug its usb into the wrover development board's usb socket and on the fly linux makes a serial device with the appropriate node in /dev. It's magic I tell ya.

[stevenaleach]

Originally Posted by hobnail

I'm old school and my knowledge comes from the days when code ran from either ram (DRAM) or rom. Typically code was loaded from a drive into ram where it was executed. Reading some of the Espressif docs it sounds like code is executing from the flash. My wee brain is having a hard time with that idea. Anyhow, I received my "Freenove Ultimate Starter Kit for ESP32-WROVER" today and it contains a cornucopia of devices and components, including the wrover. And I can't believe how clever Linux is; you just plug its usb into the wrover development board's usb socket and on the fly linux makes a serial device with the appropriate node in /dev. It's magic I tell ya.

Same here - flash and microcontrollers in general are new to me, but it's basically the equivalent of EEPROM -- it seems it's just mapped somewhere into the memory-space, just like ROM. The M5Paper has 16MB, the Lolin board I just got, 4MB. Can be used for code and data - when running MicroPython, the interpreter and libraries live in flash, along with a writable FAT filesystem with whatever room is left -- not much different than an old 8080/z80/etc machine with BASIC in ROM, except that it's re-writable. Shouldn't be used for high frequency data-logging because it's only "guaranteed" for about 10,000 rewrites and there may or may not be wear-leveling... but yea, for most purposes the flash is just a ROM region of memory.

[stevenaleach]

I just got an update from DigiKey.. it seems I'll have my M5Paper by about the 7th of April.

Soo... I've got more parts on order from Adafruit, including two rotary-encoder/push-buttons and a 400x240 2.7" diagonal "Sharp Memory Display". I finally decided that my eventual WaveShare tablet will have a small UI/status display underneath the e-ink canvas above. The memory-display is a pretty neat device with extremely low power consumption similar to e-ink (the display does need to be refreshed, but only once a second or so and only needs power sent to a single GPIO briefly to carry out the refresh of current display contents), and like e-ink it's a reflective daylight readable display with no back-light or self-luminescence. Unlike e-ink, it's fast - it updates instantly allowing for animations and quick UI drawing and there's no ghosting to worry about.

So my plan is for this roughly 1/2 credit-card sized little display to be situated between two knobs and right below the ~9" x ~6.5" (10.3" diagonal) WaveShare e-ink display - which I think will work out nicely, visually. The e-ink is to act as a canvas/page only, without being asked to display menus, dialogues, or file mangers as well. Meanwhile, the memory-display will provide all interactive and real-time information - and should alleviate a lot of the inherent frustration resulting from the slow update time of e-ink. With a page displayed and the ESP-32 in deep sleep, turning the scroll knob a click forward to turn the page should result in the little screen waking immediately and displaying the next page number along with a progress bar/animation, along with battery status, tracking the updating of the page above and should then, after a five-second or so time-out fade to grey as the device goes back to sleep (with said animation being achieved by just going to sleep and no longer hitting the refresh pin for the display). One knob would be enough (up/down/select), but two opens up a lot more possibilities (hey, we've got up/down/left/right/A, and B) for zoom and pan, etc.. and it still keeps the interface down to just two knobs.

I've still not ordered an actual WaveShare display yet, but probably will soon - I wonder what my chances are of having my DIY reader finished and in some kind of case before the M5Paper that stared me on this whole obsession actually arrives?

[stevenaleach]

One-Bit video playing on the memory-display: https://youtu.be/zzJjE1VPKjI?t=73

Black and White-ish grey only, but very crisp and readable. They're used in a lot of smart-watches, low-power instrumentation, etc. And it's sooooooo tiny. For a second screen on an e-ink tablet, I like the fact that it's a perfectly usable UI area but won't compete with the main screen or be that noticeable when it's blank - it's just a bit of rectangular space appropriately sized for a small information tag below the "printed image" above on the canvas -- something like a museum tag set between two small knobs, a blank space where information appears when needed and only when needed.

A nice video demonstrating and explaining the little displays: https://www.youtube.com/watch?v=eAoC818Mxy4

[hobnail]

He says "being converted in 1 bit" but I'm wondering if the video is really being converted on the fly. Scroll down to video 22 in the following playlist and see what he did with an OLED display; he explains how he converted the video to a bunch of still images and then blasts them to the screen.

https://www.youtube.com/playlist?lis...cytic4DfBe1Dep

[stevenaleach]

Originally Posted by hobnail

He says "being converted in 1 bit" but I'm wondering if the video is really being converted on the fly. Scroll down to video 22 in the following playlist and see what he did with an OLED display; he explains how he converted the video to a bunch of still images and then blasts them to the screen.

https://www.youtube.com/playlist?lis...cytic4DfBe1Dep

Oh I'm sure he means video converted to one-bit and then put on the device. The videos aren't actually a very good demonstration since they're dithered and horribly pixelated, but it's a good way to show off the fast update speed.