M5Paper e-ink device for DIY

[murraypaul]

Arrived at 09:30 this morning, having only ordered it at 18:30 on the 25th. And that was with free delivery, very impressed by DigiKey.

Not going to have a chance to have much of a play with it until Friday, but initial impressions are that this is a very good value bit of development/prototyping kit, at only 60 quid.

I would echo the warnings above, do not buy this thinking it is an eReader, it is not. Out of the box it doesn't do anything at all. This is for people who want to do some eInk development, and are comfortable programming in C++, which is currently the only option.

Edit: Add photo.

[Adoby]

Just read on the M5stack community forum that UIFlow for the M5Paper is expected in a couple of weeks. Two weeks was said, but the Chinese New Year was also mentioned, so...

Who knows, my M5Paper from China may arrive to Sweden just in time?

[hobnail]

Look in the sidebar on this site; he has some nice tips for the esp32 (listed as ESP8266/ESP32). https://techoverflow.net/

[hobnail]

Originally Posted by murraypaul

This is for people who want to do some eInk development, and are comfortable programming in C++, which is currently the only option.

Since it's using an ESP32 shouldn't you be able to use any of the available ESP32 stuff? For example, scroll down to the Development gray bar at


http://esp32.net/


Or is the issue of how well a language interfaces with / supports the display?

[murraypaul]

Originally Posted by hobnail

Or is the issue of how well a language interfaces with / supports the display?

Currently the only provided interfaces to the touchscreen and display are through C++.

UIFlow/MicroPython is meant to be available at some point.

[hobnail]

Originally Posted by murraypaul

Currently the only provided interfaces to the touchscreen and display are through C++.

UIFlow/MicroPython is meant to be available at some point.

They do make a lot of gizmos, so not some fly-by-night company so there's hope.

[Adoby]

Originally Posted by hobnail

Since it's using an ESP32 shouldn't you be able to use any of the available ESP32 stuff? For example, scroll down to the Development gray bar at


http://esp32.net/


Or is the issue of how well a language interfaces with / supports the display?

Yes, all the usual stuff for Esp32 will work, including the screen. I have a couple of Esp32 boards. And they are quite nice to use with C/C++. But doing GUI programming I would prefer doing a little more high-level in a graphical design environment. If given a choice...

[hobnail]

Originally Posted by Adoby

Yes, all the usual stuff for Esp32 will work, including the screen. I have a couple of Esp32 boards. And they are quite nice to use with C/C++. But doing GUI programming I would prefer doing a little more high-level in a graphical design environment. If given a choice...

I've never played with one but it sounds like fun. Which board do you recommend? I was thinking of getting this one; with the idea that the display might make it easier to debug stuff.

Oops; forgot to include this link:

https://www.amazon.com/gp/product/B076CLVD8Y/

[stevenaleach]

Allright... So I just ordered one off of Digi-Key (along with a CardKB keyboard for its first accessory). I can't wait to start working on software for it - I'm rusty as hell in C, but have been long itching to re-acquaint myself with it anyway (I live in Python these days).

For a reader, I can at least get a head-start now because I plan to convert ePub/Mobi to a 'native' markdown with tags for inline images and possibly internal hyperlinks. That way images can be resized approprely and converted to 4bpp greyscale on my computer and the text otherwise optimized for this particular screen.

Second use will be for sheet music - Being able to put a full lead-sheet with treble staff and chord symbols on the screen would be great. That too I can get a head-start on - some Python and Lilypond and I should be able to generate nice 960x540 sheet music pages in lovely black and white. Now there's some neat possibilities there - I just started playing saxophone, an instrument like many others with a standard attachment point for a music holder for use in marching band and etc... I'd never imagined actually using that holder, but this device is just about the perfect size. With a button (or few) added (perhaps attached to the bell of the sax where they can be easily reached) that could be *VERY* useful - the simplest case just being a next-page button to compensate for the tiiiinny screen and the limitations thereof, but more interesting might be adding a visual metronome and score animation (highlighting and counting off the beats in the current bar, basically) that could auto-scroll... and it would even be possible, with a second device as a midi-synthesizer, for it to act as a midi-player (able to transpose, adjust timing, etc.) while displaying the animated lead-sheet on screen.

Then it'll need a nice editor - that's part of why I ordered the CardKB with it which, while the tiny keyboard is probably not especially practical, it is good enough for prototyping, compact, and absurdly cheap. Paired with a nice PS/2 keyboard, though (like this one: https://www.adafruit.com/product/857 ), this little screen could make for a very nice distraction-free writing environment. So it needs a nice little markdown/text-editor that can both offer an on-screen keyboard as needed, and ditch it for full-screen editing with a physical keyboard attached.

FINALLY, a hackable usable piece of e-ink hardware! I've been looking at Waveshare screens for a couple years and keep thinking about building a device around one - probably would have by now if any were touchscreen. But this thing - about the same price as Wavshare's slightly larger but lower resolution displays, with a case, battery, microcontroller, and three physical buttons... Hell Yea.

[stevenaleach]

I'm actually dreaming of two of these little screens in a folding binder-case with a serial connection and some wake/control pins connected between them. They could work together (displaying two consecutive pages of the text), separately (with a text open on one screen and a note window with on-screen keyboard on the other, for instance), or in combination, for instance with one screen devoted entirely to an on-screen keyboard and UI controls, and the other as a full-screen editor window. I'll have to behave and stick with getting some basic software running on one screen first ;-)

But depending on how nice the screen and especially the touchscreen turn out to be, I'm 99% sure I'll eventually have to have a pair of these things lashed together - as soon as I can justify it with software ready to start using the second screen ;-)

I've not messed with MicroPython at all, but I just came across this: https://towardsdatascience.com/micro...er-6f366ff5ed9 It seems you can run a Jupyter Notebook with a MicroPython kernel connected to a device... wait.... what?! The more I look at MicroPython, the more impressed I am - I definitely can't wait to start playing with it.

[Adoby]

Originally Posted by hobnail

Which board do you recommend?

My favorite is the Wemos esp32 d1 mini board. There are a lot of "shields" for various purposes that plugin and are easy to use. Sensors, relays, displays and more. And it is cheap. But perhaps a bit old now...

Also check out the devices offered by M5stack. More polished and less need for soldering.

All can be used with C/C++ or MicroPython. You can start small and cheap to see if you can figure it out.

(I don't recommend the board you linked to. It has a long range low bandwidth radio transmitter and is intended for communication purposes. Sensor networks, for instance.)

[hobnail]

Ok, thanks. I'll look at the M5stack offerings again. I had glanced at them.

[andyh2000]

The M5Stack devices really are a nice ecosystem and easy to program in blockly (uiflow) or straight micropython. I've got an Atom Matrix that talks to a Core via local mqtt broker. The Atom acts as a visual remote control and the Core is a free/busy sign for my study door when I'm on work video calls.

I'd been holding off getting an M5Paper as I have drawers full of unused microcontrollers but I feel myself weakening now.



Atom Matrix code (from uiflow):

from m5stack import *
from m5ui import *
from uiflow import *
from m5mqtt import M5mqtt

rgb.set_screen([0,0,0,0,0,0,0xffffff,0,0xffffff,0,0,0,0,0,0,0xffffff,0,0,0,0xffffff,0,0xffffff,0xffffff,0xffffff,0])


current_state = None




# Describe this function...
def set_lights_blue():
  global current_state
  rgb.set_screen([0,0x0000ff,0x0000ff,0,0,0,0,0,0x0000ff,0,0,0,0x0000ff,0,0,0,0,0,0,0,0,0,0x0000ff,0,0])

# Describe this function...
def set_lights_green():
  global current_state
  rgb.set_screen([0,0,0,0,0,0,0,0,0,0x00ff00,0,0,0,0x00ff00,0,0x00ff00,0,0x00ff00,0,0,0,0x00ff00,0,0,0])

# Describe this function...
def set_lights_red():
  global current_state
  rgb.set_screen([0xff0000,0,0,0,0xff0000,0,0xff0000,0,0xff0000,0,0,0,0xff0000,0,0,0,0xff0000,0,0xff0000,0,0xff0000,0,0,0,0xff0000])


def fun__freebusy_check_(topic_data):
  global current_state
  current_state = int(topic_data)
  if current_state == 0:
    set_lights_green()
  else:
    if current_state == 1:
      set_lights_red()
    else:
      set_lights_blue()
  pass

def buttonA_wasPressed():
  global current_state
  if current_state == 0:
    m5mqtt.publish(str('/freebusy'),str('on'))
  else:
    if current_state == 1:
      m5mqtt.publish(str('/freebusy'),str('off'))
    else:
      m5mqtt.publish(str('/freebusy'),str('check'))
  pass
btnA.wasPressed(buttonA_wasPressed)


current_state = -1
m5mqtt = M5mqtt('m5atom_remote', '192.168.1.226', 1883, '', '', 300)
m5mqtt.subscribe(str('/freebusy_check'), fun__freebusy_check_)
m5mqtt.start()
set_lights_blue()
m5mqtt.publish(str('/freebusy'),str('check'))
while True:
  wait_ms(2)

Core code:

from m5stack import *
from uiflow import *
from m5ui import *
import wifiCfg
import socket
from m5mqtt import M5mqtt

want_check = False

def on_msg(payload):
  global want_check
  global state
  led_on = payload.find('on')
  led_off = payload.find('off')
  check = payload.find('check')

  if led_on == 0:
    state = 1
    rgb.setColorAll(0xFF0000)
    setScreenColor(0xFF0000)
    lcd.setBrightness(30)
    rectangle0.show()
    busylabel.show()
    want_check = True
  if led_off == 0:
    state = 0
    rgb.setColorAll(0x000000)
    setScreenColor(0x000000)
    lcd.setBrightness(0)
    rectangle0.hide()
    busylabel.hide()
    want_check = True

  if check == 0:
    want_check = True

state = 0 #state variable for the leds

ip = wifiCfg.wlan_sta.ifconfig()

rectangle0 = M5Rect(0, 0, 318, 240, 0xff0000, 0xFFFFFF)
busylabel = M5TextBox(61, 81, "BUSY", lcd.FONT_DejaVu72,0xFFFFFF, rotate=0)

rgb.setColorAll(0x000000)
setScreenColor(0x000000)
lcd.setBrightness(0)
rectangle0.hide()
busylabel.hide()

m5mqtt = M5mqtt('m5core_free_busy', '192.168.1.226', 1883, 'user', 'pw', 300)
m5mqtt.subscribe("/freebusy", on_msg)
m5mqtt.start()

while True:
  if want_check:
    m5mqtt.publish("/freebusy_check", str(state))
    want_check = False
  wait(1)

Andrew

[hobnail]

Originally Posted by andyh2000

...
Andrew

A mentor of mine once told me that a mentor of his said it can be useful to get rid of nested if else statements when you can because it can make the code less convoluted. So take this with a grain of salt. For example,

if current_state == 0:
    set_lights_green()
    return

if current_state == 1:
    set_lights_red()
    return

set_lights_blue()

But often the code doesn't lend itself to this treatment.

[Quoth]

if current_state == 0:
set_lights_green()
return

if current_state == 1:
set_lights_red()
return

set_lights_blue()

That sort of structure is for junk compilers, or pseudo code for assembler for some sort of very primitive microcontroller. Easy to get wrong too.

if then else is perfectly readable, more readable. Nested IFs can be perfectly readable.
For more options you want a select or case table or state machine. Admittedly some languages only allow a single test and then each option is indexed by a simple scalar type like an integer. But there are readable ways to have bigger IF chains and ways to preprocess the conditions.