zerowriter / zerowriter1 Goto Github PK

I'm building a port of the codebase to run on the Inkplate series of displays. These are higher quality, higher resolution displays from a cool company.

In theory this means support for Inkplate 5, 6, Motion, and beyond as they use a common peripheral mode library.

Hi,
I tried to use the zerowriter1 with a Keychron V4 ISO Ger and figured out, that the key what typically used for - and _ is not matching. Means when you are using a Keyboard with the Minus (-) and Underline (_) key with a shift the python script freezes with a traceback. Instead the Numpad Minus (-) is in use. On a US keyboard with QMK/VIA this is not a big deal, there you can easily replace the origin key on the first layer by the Numpad Minus. But on something like the German layout there is a Language specific symbol on it what would confuse the OS Keymapping.
Workaround for my setup is to use a Macro with Shift and the Keypad Minus and use it on a different layer.
Kind Regards
SierraX369

As I'm coming from a different direction other than distraction free writing:

This devices also has all components for a nice standalone raspberry pi with keyboard and display, uconsole style :).

And wouldn't that permit its use also as a quite powerful macro-programmable keyboard, incl. a settings display de-luxe and say local setting editing / phrase editing, etc pp.

Are there known examples for this kind of "ab"use for the zerowriter, or sketches for an raspberry pi to enable similar features (beyond that old wired rpi-zero-based macropad, from I believe pimoroni in the pre-rp2040 days)?

And could this repo or a zerowriter homepage offer a contrib directory / page to collect such samples?

(Question issue can be closed with a link to such a collection is added; or retained if it makes more sense to use this issue as my requested brainstorming collection :).

I love this project, I've been playing around with this for several hours and look forward to the v2 waveshare drivers.

One small nit - this repo contains .DS_Store and ._.DS_Store files in each directory, presumably written by the OS X filesystem you're working on (this happens to me all the time). If you add these to a global .gitignore file they won't be passed on for everyone to see.

This will add a global ignore to your local projects
git config --global core.excludesfile "~/.gitignore" && echo *.DS_Store >> ~/.gitignore

Thanks!

More STL questions, I see the display housing has these four cylinders that house screw threads

Yet in the YouTube video with your demo device it appears that the eink display is directly underneath the display housing and flush with it.

Did you cut off those cylinders after printing the STL file, or am I missing something? Thanks!

Hi
I found an issue in generating QR Codes. When there is one Ampersand inside the text file the great feature of creating a QR code for mailto is just creating a body with content before this Ampersand.
Kind Regards
SierraX369

So after contacting waveshare to order some more displays... I have learned that the 2.1v display I used is no longer available (as of a month ago)

Which means -- unless you are a lucky person who snagged a 2.1 display -- you'll be working with a lesser performant display board. You can tell by looking at the back of your display board, it will have a version number (rev 2.1 or 2.2)

I'm no expert at display drivers, but I am pretty confident that this could be cracked. The panel seems to be the same, but the flashed firmware on the driver board itself is different. In particular, it looks like the partial update lookup tables are hidden / built in to the firmware. Which is probably by design from waveshare for panel life/stability.

The original 2.1 software let me get at the partial update lookup tables, and that was the trick to squeezing the extra performance.

I've got my hands on a 2.2 display now and have started working with it -- some small modifications have it running well enough to be pretty reasonable. But I am very picky, since I've spent so much time working and iterating on the 2.1 driver. I like fast.

Not sure if anyone out there is in to this kind of thing, but it would be great to have other people digging in to this.

I've opened another repository for dumping stuff related to Goodisplay. The short of it: they are the display manufacturer for waveshare. They have been cooperative so far with engineering help and have sent me some panels to test out, including a very nice looking 5.79" display.

The goodisplay panels are raw eink panels and require special driver boards and a MCU to run them. I've been testing with a pi pico and micropython code.

The nice thing here is we can get at some of the good stuff, like the waveform tables.

If I can get these panels to work at a reasonable speed, they would be an inexpensive alternative and appropriate for the project. I think all-in, they would be around $45-50 per 5.79" display. Likely would mean setting up something to send people finished displays, since it might be too much work for people to configure on their own.

In current version, the zerowriter1 (in my case waveshare_2.2 branch) is saving the lines after hitting return, in the same way it showed on the 35x13 lines framed display.
This makes it a little difficult to edit the text afterwards.
Old typewriters should have around 60 types per line. Old Computer around 80. On modern computers, typists write entire paragraphs without using the return button.
Wouldn't it make sense to save the stuff 2 times? One time in the Displayversion and one time in the raw typed version?

Hello,

First, thanks for your work on zerowriter! I recently purchased https://www.amazon.com/dp/B074NR1SW2?psc=1&ref=ppx_yo2ov_dt_b_product_details and received a unit that only works with the 4in2_V2 examples from waveshare. I've updated the code to load the 4in2_V2 EPD code, but obviously that doesn't make use of the faster LUT updates.

I'm going to continue to work on this to hopefully get this version to a useable state as well; I wanted to leave this issue here in case anyone else was working on it and wanted to share advice or code.

Thanks!

How feasible would it be, to include standard lithium cell batteries?
maybe one line (3 cells?), between the keyboard and where the wrists reside on the table, or behind the keyboard, or on the sides of the keyboard, ...

basic electronics considerations seem to be here (though I am not sure if this works for bare cells too):
https://www.circuitbasics.com/how-to-power-your-raspberry-pi-with-a-lithium-battery/

Hi there - two (perhaps related) questions.

1. I'm starting to print out the STL files, and I can't seem to tell where circled part in your YouTube video is from.

It appears to be a hinge, plus some other plate with two screw holes that I can't find in the STL files. I can see that there are two screw holes in a similar location in Bottom.STL, but there isn't the plate visible in the YouTube video.

2. Hinge1.STL and Hinge2.STL appear to be identical. I printed them out and I can't tell the difference between the two of them. Is this on purpose? Part of me was wondering if one of these Hinge files was meant to be the part I can't appear in the above question.

Thanks! Images for 1 below

I can't find this in the STL files, comparing them to your from YouTube video

Here is Bottom.STL, doesn't appear to match the YouTube video

Sometimes the display misfires and doesn't push the updates via the display driver.

• activate the menu with ESC a bunch of times really fast. Sometimes, the menu will be active but the screen will not match up until an input happens)
• when scrolling with arrow keys through your document, sometimes the display does not catch up to the input correctly. Same issue as above I think, just in a different context

This isn't really that bad or devastating, but kind of annoying. I think what is happening is the screen update is being called while another update is still active / happening. I have some failsafe stuff for blocking out updates if one is in progress, but they aren't applied to the menu system or the 2.2 code in general.

Easiest fix is applying a latency delay (150ms / time.sleep(.150) BEFORE calling the display update, that would give time for the previous update to finish. Or writing in something that delays updates until the previous update is complete.

These kinds of issues would be non-existant with a lower latency display...

Is this something that can be done easily?
Can you give guidance on what needs to be changed in the code?

Thanks in advance!

I haven't looked in to this yet, but would it be feasible to just make a raspberry pi imager file that does all the configuration beforehand? Include all the packages and setup and stuff.

And then it boots and the user connects to wifi and we are done? Could make things easier for people who just want to get going.

The code executes, but nothing happens on the display. I deleted the old branch and cloned this one. Maybe I'm doing something wrong?

EDIT: got this error>

epd.config loaded Traceback (most recent call last): File "/home/writer/zerowriter1-waveshare_2.2/e-Paper/RaspberryPi_JetsonNano/python/examples/main.py", line 23, in <module> from zerowriter import ZeroWriter File "/home/writer/zerowriter1-waveshare_2.2/e-Paper/RaspberryPi_JetsonNano/python/examples/zerowriter.py", line 3, in <module> import qrcode ModuleNotFoundError: No module named 'qrcode'

Wifi list does not load on fresh installs. This is because the linux NetworkManager is not being loaded "inactive (dead)". I think maybe the pi imager bypasses the network manager entirely, kind of a strange issue.

You can check this with:

sudo systemctl status NetworkManager
solved with:

sudo systemctl enable NetworkManager

maybe I will just add this to the setup steps... or I could have the applicaiton automatically run that command line if network manager is not loaded. Might be solve by going into raspi-config and doing the wireless setup there (not sure)

I am working on developing a ported version of the Zerowriter that runs on the IT8951 series of display boards from waveshare. These are much higher resolution, speed, and quality. In theory, this could open up more display options like 6", 7.8", etc.

These IT8951 panels operate at a MUCH faster refresh rate than the 4.2" panels.

Unfortunately they cost about 3-4x the price