Although the most popular e-reader by far is the Kindle, some argue that its primary use isn’t even as an e-reader at all but rather as a storefront for one of the world’s richest companies. For those who want user-focused consumer electronics instead, we’ll often reach for something more untethered, like an off-brand ebook that’s nothing more than an Android tablet with an e-paper display or even a jailbroken Kindle freed from the chains of Amazon. But as our 555 enthusiast community continually points out, even these are overkill for reading books. Enter the ZEReader.
The ZEReader started out as a bachelor’s engineering thesis project by [Anna-Lena Marx], whose goal was an open-source, microcontroller-based e-reader instead of the Linux or Android ones most commonly available. She’s based the firmware around the Zephyr Real-Time Operating System, which is an RTOS geared towards embedded devices. With this as a backbone, it’s trivially easy to implement the e-reader on different microcontrollers as well as use a wide variety of screens. Although the firmware is a work-in-progress, it’s already mature enough to support all of the basics of an e-reader, such as reading .epub files, navigating through the book, and saving progress. It even includes basic HTML parsing.
As for the rest of the hardware, there are considerations made for a charging circuit for a lithium battery, a booster circuit for the display, a microSD card slot, and four control buttons. Some planned future improvements include solar charging capability, more advanced power management, and the potential of additional PSRAM. With the core in place and its open-source nature, though, it could be the basis of many e-paper projects as well. If you’re having a hard time deciding on an e-paper display for your e-book, though, you can always make your own from scratch. We’ve seen an Arduino solar book reader before, by the way.
Just because you can, doesn’t mean you should.
For a static screen hanging on the wall, I get it. But for a consumer device like this, why? Cost optimalization? The software development effort will be huge. All the stuff you have to write yourself, not allowing you to stand on the shoulders of others.
So we start off with basic epub parsing (its based ish on html afaik). But then reading pdf’s would be nice too. Doing a pdf parser on a micro? Good luck, but yes, possible maybe. Graphics rendering for comics? Same.Then, hmm maybe we want to sync over wifi with calibre. Oh but also think of wpa3, enterprise auth, etc. Possible, yes, but also effort. Support sd cards and usb drives? Decent GUI? The list goes on.
While I applaud the effort and if thats an itch that needs scratching, great by all means scratch it. But avoiding Linux/android because it’s overkill? I suppose it depends on your scope of course, but I strongly believe it usually isn’t.
Disclaimer, been an ’embedded’ engineer for 20 years now and have done a few ‘let’s use linux for this’ projects, often in a combination with a micro (due to realtime/isolationbof concerns) where the discussion also often was ‘but the micro could also do this.
That seems a bit harsh given that this was an engineering bachelor project, and is now a hobby.
Isn’t this how most open source projects get started? As something not worth the time and effort, not being able to stand on other’s shoulders? Even Linux itself started that way. With the work SHE puts in NOW, she might give other people some nice shoulders to stand on.
And as Grant points out, it’s a hobby. Most of us do useless stuff as a hobby. I do photography among other things, and I never ask myself if the world really needs another picture of a landscape or still life or whatever.
May I ask why you even follow Hackaday? I’d say 99.9% of the projects posted here are useless and not worth the effort by your standards.
Just because you can write a comment, doesn’t mean you should.
In many cases here, a project is for the fun of it and to learn something from it. I’ve been a “amateur” commentist for about 20+ years now and I’ve learned that there so many other people who commented as well and so many other that can comment so much better. I’ve read plenty of books and/or columns by people who claim to understand the art of writing and many of which others say their work is of a high intellectual level that deserves to be read. Instead, they do not seem to comment here and/or their comments do not meet my requirements regarding content. I refuse to borrow from their “work” and stand on their shoulders in order to create a better comment as that would not result in an improvement of my personal development as a commenter, it would only prove that I’m able to build upon the work of others while I feel the need to lay my own foundation to the things I comment about. Now this comment is not my best of comments, but it is mine and mine alone. I’m proud about it and even though I’ve learned from it that I should not have made this comment, I’m glad I did, because my next comment will be so much better. Or at least I like to think that.
Been there, never going back unless paid extremely well. Last year I embarked on a voyage of writing my own IT8951 USB kernel display driver. Found that APIs are not only poorly documented but mostly undefined. Passing a pointer? What about its nullability, lifecycle, and allowed places it can point to (stack or which of various variously managed structures on various heaps?)
Documentation sporadically mentions these things but mostly you are just told it’s institutionalized knowledge and you need to put in the effort and it is weeding out nonserious programmers.
But it is BS as Rust in Linux shows that those APIs are truly undefined and often working by a chance under presumed but not well defined conditions. It was uncovered because Rust devs usually encodes these things in types (with zero overhead). And Rust devs when writing bindings then ask questions about the APIs without placing any other burdens on C devs like having to know Rust syntax. And they get then publicly attacked with semitruths or outright lies (which Linus called out a few times) and also called woke for reasons I can’t understand (while I myself am against any DEI nonmerit based things and can’t see anything woke there).
Just look at existing code. If all other drivers pass a static const struct to a function, check the source code of that function before you attempt to allocate the struct on the stack.
That’s a good way to copy other people’s memory leaks into your own code, just assume someone else got the ownership right
Thank you for talking the time to write this Mr Bezos. You make lots of great points.
“Just because you can, doesn’t mean you should.”
It was a learning exercise and for their degree project! This project has infinite more value than your comment. We’re lucky that Linus did not feel the same all those years ago, else we’ll all be suffering under the windows monopoly.
This is awesome as a project.
I’m just not sure about the Amazon avoidance premise. You can use a Kindle without Amazon services.
I haven’t connected my Kindle to Wi-Fi in months, and only read sideloaded ebooks from places like project Gutenberg and Standard Ebooks.
In fact, I used my Kindle for over a month before I ever set it up with my Amazon account.
It’s a cool project, but I don’t think hacker projects need to be substitutes for corporate products to be cool.
Hacker projects are just cool as is.
i think i agree with the thrust of your comment in some sense…when i looked at this article i had zero interest in the actual project…i was just interested in the fact that you can buy naked eink these days — though i think the price still goes up rather quickly with the size.
but specifically i’m gonna counter your claim that the software effort is huge. over the decades, i’ve used off the shelf ereader software, as well as written my own. today i’m using coolreader for android, which is the best i’ve used yet in combining flexibility, ease of use, and a huge featureset. but before coolreader, i would say generally the effort of using off the shelf software was comparable to the effort of writing my own. for me, anyways.
one thing is, you don’t need to support everything. you can use any number of converters on the input. for years, i would run html books (epubs) through “lynx -print” to create a text file. i had a 10 line C program i used to normalize whitespace. if i wanted to decode PDFs on a proper embedded processor, i’d probably pre-convert them to a sequence of bitmaps on my big PC, using imagemagick. since your output is eink (both low resolution and low colors), you’d really rather one extreme of bitmap or plain text over PDF in every case. and if you get dragged down the rabbit hole of the cheapest way to compress a bitmap…that’s a great afternoon’s amusement!
i wrote a PDF viewer for my PC. after 5 years of development, it is only 2560 lines of C, because i used libpoppler to decode the PDF for me. i just had the idea that in this century, the UI thread should never ever block. i can’t believe how pervasive it is these days for apps to be written with a separate UI thread (Android basically mandates this, for example) and yet still go unresponsive / unpredictably responsive whenever the ‘background thread’ is doing any work! as a user, i am extremely satisfied with my PDF viewer. i get immediate and predictable / comprehensible response to all my keypresses while i’m reading the PDF viewer, even if the background thread hasn’t caught up to it. and it was really a pretty small amount of effort.
yeah there’s a little pathology in ‘not invented here’ but you can definitely productively and pleasurably re-solve parts of the problem space without repeating an intolerable quantity of work.
anyways, i have come to rather enjoy having my ‘nook’ ereader as a passive display on my wall. and i want to reinvent the whole thing because that particular consumer product crashes about once a week, on top of a zillion other infelicities it had as an actual ereader back in the day. lots of reasons to want to reinvent a consumer product!
Any commercial implementation of Android is going to have built-in advertising, it’s going to have its own telemetrics, and it’s also most likely going to meet obsolete via firmware long before the hardware fails.
All I want is a screen to display the thing I want to read. without the involvement of multi-billion dollar companies.
Exactly.
Why would you write an entire operating system from scratch, when DOS already exists?
If only someone told Linus that 30 something years ago.
Thanks to your comment I understand better how much effort she put to that project. I hope she will remain rebel and continue doing things she shouldn’t… as long as they are legal of course.
That’s very reasonable advise for most people, but this is Hackaday. That’s like going to a model making forum and asking “why don’t you just buy premade models?”
Very cool project, always cool portable tech
Not sure the kind of battery performance you would get with a pi pico but
Also Zephyr…I had some terrible experience with that. Wouldn’t want to ever use it if I don’t have multiple networking stacks or I’m not using the meagre amount of provided drivers
Completely unoptimized, the battery enables around 100 hours actively reading while refreshing the sceen constantly. That’s not too bad!
Zephyr is hard to start, but gave me portability, good abstraction and flexibility as well as drivers for the major components. I would not have come that far during the time of the thesis with FreeRTOS.
There’s something missing in current commercial devices – I’m not sure what it is. I have both a Kindle and Kobos. I run Calibre, I’ve sideloaded KOReader and EVERY TIME I see a someone building a reader I click on the link: is this the one? So it’s cool to see a different take.
On the light processing capabilities provided by the the Pico – I could see a plugin for Calibre pre-processing books.
Amazing that dual 133mhz+ ARM or RISC is considered ‘low processing power’ when we are talking about ebook rendering. For text on a low refresh rate e-ink display it should be 10x more than needed, even for a single CPU.
The real problem is the UI is going backwards. Physical buttons, or even a simple wireless protocol for page turning is much more useful.
Kindle also added a backlight which is not terrible on its own; but then made the battery 1/4 a reasonable size given the space they had. Also it seems to drain itself for no reason, its always dead. It’s fairly obvious if I need to keep it on a charger and it won’t last a trip without charging that they are pushing us to a platform that we can shop from. Ugh Amazon.
It would be great to see ultra cheap eReaders for education in developing regions. They might also be good in places where Android devices cause too much distraction.
Hackaday, a place for hobbyists to show off their really cool work, and other engineers to complain it’s not a product. This is awesome, thank you for sharing! Does flexible mean physically flexible?
It’s flexible as in easily portable, using Zephyr allows switching to e.g. another display without touching any code besides the device tree.
That’s what I wanted to know. Does it roll up or fold?
I believe anything usable, reusable, affordable, scalable and adaptable (like her project) should be supported regardless of anything else
That’s what caught my eye, too, as I would love some decently sized flexible epaper for a project I’ve had in mind. Sadly, I see no mention of flexibility on the original page, so I believe the usage in the headline is referring to metaphorical flexibility.
looks great.
commercial ereaders all suck. all of them. android blows.
epub is the only format I want. backlight. save the current page. I don’t need any other features.
good wishes to the creator.
This. 100%. So much! I have an old kobo, where the backlight broke (need to fix it) and a new tolino that is so sensitive to handling that now the screen is f’d up. The kobo I could just throw in my bag, I really used (abused?) it, just the light broke, it still is usable.
Thanks @Anna for doing this. It’s a cool project, and likely extremely educational (i.e. very frustrating at times).
Forgot to add: those readers were never and willnever be connected to any network. The books are pushed via USB from Calibre. Never set up an account on the readers. I only need this to display my books so I don’t have to shlepp all my reading in addition to the other stuff when going on holidays (disadvantage of trains: shlepp your stuff, limits stuff you can bring, advantage of trains: I can sit and read, walk around, get a coffee, play games with the kids sitting at a table – yay for SBB!)