Open Book Abridged: OSHW E-Reader Now Simplified, Pico-Driven

Two e-readers side to side. On the left, you can see the frontal view, showing text on the e-ink screen. On the right, you can see the backside with a semi-transparent 3D-printed cover over it, and two AAA batteries inside a holder in the center.

If you ever looked for open-source e-readers, you’ve no doubt seen [Joey Castillo]’s Open Book reader, but you might not yet have seen the Abridged version he’s building around a Raspberry Pi Pico.

The Open Book project pairs a 4.2″ E-Ink screen with microprocessors we all know and love, building a hacker-friendly e-reader platform. Two years ago, this project won first place in our Adafruit Feather contest — the Feather footprint making the Open Book compatible with a wide range of MCUs, giving hackers choice on which CPU their hackable e-reader would run. Now, it’s time for a RP2040-based reboot.

three PCBs being shown - one soldered-together version with a Pico on it, and two upopulated PCBs, showing front and back, on the populated PCB, you can see the Raspberry Pi Pico and other components soldered on. On the unpopulated PCBs, you can see there's a lot of text helping you understand and assemble this e-reader.This project is designed so that you can assemble it on your own after sourcing parts and PCBs. To help you in the process, the PCB itself resembles a book page – on the silkscreen, there is explanations of what each component is for, as well as information that would be useful for you while hacking on it, conveying the hardware backstory to the hacker about to dive into assembly with a soldering iron in hand. There’s simple but quite functional software to accompany this hardware, too – and, as fully open-source devices go, any missing features can be added.

Joey has recorded a 30-minute video of the Pi Pico version for us, assembling and testing the newly ordered boards, then showing the software successfully booting and operational. The Pi Pico-based revision has been greatly simplified, with a number of self-assembly aspects improved compared to previous versions – the whole process really does take less than half an hour, and he gets it done with a pretty basic soldering iron, too!

If you’re looking for updates on this revision as development goes on, following [Joey] on Twitter is your best bet. He’s no stranger to making devices around us more free and then sharing the secret sauce with all of us! During the 2021 Remoticon he showed off a drop-in replacement mainboard for the Casio F-91W wristwatch, and told us all about reverse-engineering its controller-less segment LCD — worth a listen for any hacker who’s ever wanted to bend these LCDs to their will.

 

17 thoughts on “Open Book Abridged: OSHW E-Reader Now Simplified, Pico-Driven

      1. I use a Kobo mini for long tramping trips. I got it because it was cheap, but have found that the small size is perfectly functional for reading, and much, much, easier to carry in a pack (and far more likely to survive)

    1. It might be! It would require some clever driving of the display though. You can do fast partial updates as long as whatever you’re updating lines up with an 8×8 grid, but after a while (or if you need to update the whole display, like when the terminal scrolls) you’d need to do a full update, which takes about a second.

  1. Does it support many ebook formats so conversion isn’t required? Some time ago I came up with a name for ebook software that would ideally work with all non-DRM formats. One Ultimate Reader Software as in OUR Software, Not Theirs. If you want to use that name it’s fine with me.

    Getting even more idealistic, I wanted it to be compilable to run on Windows, Mac, Linux, PalmOS, WinCE and more to bring support for newer ebook formats to older platforms. Adding Unicode support to older platforms like PalmOS would also be nice, or as an alternate, automatically on the fly replacing all Unicode characters with their equivalents in the Extended ASCII character set. For all languages that use the same character set as English plus additional characters, all but one rarely used character in Norwegian is in Extended ASCII. There is no reason to use a multi-byte version of (for example) a lowercase a with an umlaut, left and right quotes (single or double), question mark etc.

    When my ebook readers were PalmOS PDAs I had a program written (IIRC in Microsoft Visual C 2005) that could swap text in a file. First line was the string to look for, one character to I don’t know how many. Second line was what to replace the first line with. 3rd and 4th lines likewise, continuing through many more. The swap file is a plain text file so it’s easy to create and edit and have more than one swap file.

    But the program has a bug where when too many swap pairs are used it’ll trash the file being worked on instead of doing the text swaps. How many pairs is too many? The limit isn’t enough to have one swap file with the full Unicode to Extended ASCII equivalent list. The person who wrote the program did it for free while learning the language, and wasn’t interested in debugging further.

    I have the compiled program for Windows and the source code if anyone wants it.

    It could be used for enciphering and deciphering text files with one time pad codes. Just have a series of swap files at each end of the communication, with the files used in a pre-set sequence, one time each. It would be easy to encipher a text file two or more times to further scramble it. For example have a ROT13 swap file then some other transposition cipher. Add on a third layer that swaps a couple dozen pairs of randomly generated n letter groups. To make deciphering easier it would need a function or separate program to create inverted versions of the swap files, or a switch to use the even lines as the source and odd lines as the replacement.

  2. Sadly, I don’t know how to solder and I don’t think I could get a solder machine. All I have is my Raspberry Pi Zero 2 W which is now refusing to boot right into forced hdmi mode. But hey, this E Ink screen book idea is amazing.

  3. So contacting the JLCPCB they completely blanked my request to produce the PCB.

    I went to the git hub, followed the Readme,

    “If you plan to use JLCPCB’s economic PCBA service, upload all three files in OSO-BOOK-C2-01 to JLCPCB. Opt for a 1 mm thick lead-free HASL finish. Note that the board is slightly wider than it needs to be, just to meet the minimum size requirements for this service.”

    Going to OSO-BOOK-C2-01, following the instructions to use the “3” files there, and “6” are listed.

    When you select the 3 files that appear to be correct from that list of 6, JLCPCB had not a clue what to do with the files. Needless to say, some clarification is needed on this step.

    So that a person with basic soldering skills, may order this and get to work without further delay, readme improvements are needed and some consistency between listed files, and posted instructions. Unless of course, this is an intentional obstacle to satisfy publishing interests and to cover your glutus M.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.